Validación Aplicación Técnicas Gómez 2012

VALIDACIN Y APLICACIN DE TCNICAS
DE PRIORIZACIN DE REQUISITOS
JHONNY GMEZ CHALACN
UNIVERSIDAD DE SAN BUENAVENTURA

CALI- COLOMBIA
FACULTAD DE INGENIERA
PROGRAMA INGENIERA DE SISTEMAS
SANTIAGO DE CALI,
2012

JHONNY GMEZ CHALACN
Trabajo de Grado presentado como requisito para optar

al ttulo de INGENIERO DE SISTEMAS
Director
Ingeniero Luis Merchn Paredes
UNIVERSIDAD DE SAN BUENAVENTURA

CALI - COLOMBIA
PROGRAMA INGENIERA DE SISTEMAS
SANTIAGO DE CALI
2012
DEDICATORIA
A la ingeniera de requisitos
Jhonny Gmez Chalacn
AGRADECIMIENTOS
Gracias a mi familia por el apoyo, la exigencia y la buena energa.
Jhonny Gmez Chalacn
CONTENIDO
Pg.
GLOSARIO
13
RESUMEN
13
RESUMEN DEL PROYECTO
15
INTRODUCCIN
16
1. PLANTEAMIENTO DEL PROBLEMA
18
2. OBJETIVOS DEL PROYECTO
20
2.1 OBJETIVO GENERAL
20
2.2 OBJETIVOS ESPECFICOS
20
3. REFERENTE TERICO
21
3.1 BUSQUEDA EN ARBOL BINARIO (BINARY SEARCH TREE (BST))
26
3.2 TCNICA DE ASIGNACIN DE PESO NUMRICO (NUMERAL

ASSIGNMENT TECHNIQUE)
27
3.3 JUEGO DE LA PLANIFICACIN (PLANNING GAME)
27
3.4 MTODO DE LOS 100 PUNTOS (100-POINT METHOD)
27
3.5 TEORA W (THEORY-W)
28
3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE)
29
3.7 WIEGERS' METHOD
29
3.8
FRAMEWORK
DE
PRIORIZACIN
DE
(REQUIREMENTS PRIORITIZATION FRAMEWORK)
REQUISITOS
29
3.9 CONJOINT
30
3.10 ANALYTIC HIERARCHY PROCESS (AHP)
31
3.11 ANLISIS KANO (KANO ANALYSIS)
31
4. DESARROLLO METODOLGICO DEL PROYECTO
33
4.1. RECOPILACIN Y DOCUMENTACIN DE LAS TCNICAS DE

PRIORIZACIN
33
4.1.1 Marco descriptivo de la tcnica
34
4.1.2 Caracterizacin detallada de las Tcnicas
35
4.1.3 Actividades del mtodo
36
5. ANLISIS DE APROPIACIN Y USO DE LAS TCNICAS POR LA

INDUSTRIA DEL SOFTWARE.
58
5.1 FICHA TCNICA DE LA ENCUESTA
58
5.2 RESULTADOS DE LA EVALUACIN
59
5.2.1 Seccin 1: Informacin general.
60
5.2.1.1 Pregunta 1.
60
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 EVALUACIN
67
7. ANLISIS
REQUISITOS
DE
HERRAMIENTAS
DE
ADMINISTRACIN
DE
69
69
7.1.1 Pregunta 1.
69
7.1.2 Pregunta 2.
70
8. PROPUESTA; NUEVA TCNICA
71
9. RESULTADOS DE APLICACIN DE LAS TCNICAS
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
9.1.6 Sexto, Costo Relativo
88
9.1.7 Sptimo, 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
LISTA DE TABLAS
Pg.
TABLA 1. TCNICAS DE PRIORIZACIN
33
TABLA 2. EJEMPLO DE UNA MATRIZ DE COMPARACIN POR PARES

CON 8 REQUISITOS
37
TABLA 3. INTERPRETACION DE LOS VALORES EN LA MATRIZ
38
TABLA 4. INTERPRETACIN DE LOS COSTOS EN LA MATRIZ
38
TABLA 5. MATRIZ NORMALIZADA
39
TABLA 6. COLUMNA DE PUNTUACIN.
40
TABLA 7. RANDOM
ALEATORIOS
INDEX
VALUES
NDICE
DE
VALORES
42
TABLA 8. RATIO
42
TABLA 9. SEGN EL NMERO DE REQUISITOS, PARA ESTE EJEMPLO

EL INDICE ALEATORIO(RI) ES 1,41
42
TABLA 10. FICHA TCNICA DEL ESTUDIO ADELANTADO
59
TABLA 11. INGENIEROS DE SISTEMAS EN LAS EMPRESAS
60
TABLA 12. NMERO DE PRODUCTOS SOFTWARE POR EMPRESA.
61
TABLA 13.
ENCUESTA.
EQUIVALENCIAS
DE
TAMAO
CON
RANGOS
EN
63
TABLA 14. ACTIVIDADES PRINCIPALES POR EMPRESA
63
TABLA 15. MODELOS IMPLEMENTADOS POR LAS EMPRESAS
64
TABLA 16. APLICACIN DE MTODOS DE PRIORIZACIN DE

REQUISITOS EN LAS EMPRESAS.
65

REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE
HECHO A LA MEDIDA) .
66

REQUISITOS EN LAS EMPRESAS (DESARROLLO DE SOFTWARE
GENRICO).
66

REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE
HECHO A LA MEDIDA Y GENRICO).
66
TABLA 20. HERRAMIENTAS DE ADMINISTRACIONES
70
TABLA 21. CATEGORAS 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
10
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
11
LISTA DE FIGURAS
Pg.
FIGURA 1. MODELO: MATRIZ DE PRIORIZACIN
56
FIGURA 2. INGENIEROS DE SISTEMAS EN LAS EMPRESAS
61
FIGURA 3. RELACIN TAMAO DE LA EMPRESA VS NMERO DE

PRODUCTOS.
62
FIGURA 4. ACTIVIDADES DE LAS EMPRESAS
64
FIGURA 5. CONCLUSIONES DE LA EVALUACIN
67
FIGURA 6. MODELO: MATRIZ DE PRIORIZACIN
80
12
GLOSARIO
Trmino
Descripcin
IEEE
Institute of Electrical and Electronics Engineers
CMMI
Capability Maturity Model Integration
RAE
Real academia de la lengua espaola

Quienes pueden afectar o son afectados por las actividades de una empresa R.
Stakeholder E. Freeman en su obra: Strategic Management: A Stakeholder Approach

RAD
SW-CMM
Rapid Application Development

Capability Maturity Model for Software
SP
Specific Practices
SG
Specific Goal
CRUD
Por sus siglas en ingles Create, Read, Update, Delete
13
RESUMEN
El tema de la ingeniera de requisitos es un subconjunto relativamente nuevo de la

ingeniera de software. La ingeniera de requisitos intenta agregar rigor a la
reunin y anlisis de requisitos mediante el uso de mtodos formales de
elicitacin, anlisis, y tambin en la creacin de modelos de aplicacin y validacin
de los requisitos [1].
Por medio del trabajo exploratorio se pudo identificar un grupo de tcnicas muy
utilizadas en la industria del software para priorizacin de requisitos, con la
investigacin se validaron esas tcnicas y su uso, luego se realiz un estudio a las
empresas Colombianas, buscando resolver cul tcnica es ms precisa para los
proyectos que se presentan en el contexto actual de la industria del software,
como conclusin se aprovechan algunas tcnicas dndoles otra forma y
aplicndolas en una nueva, esto segn las necesidades de las diversas empresas
del pas.
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.
14
RESUMEN DEL PROYECTO
Actualmente las empresas que desarrollan software comprenden que en su

proceso de administracin de requisitos deben priorizar, lo que no saben an, es
cmo hacerlo, en su mayora las empresas usan la experiencia del encargado de
la priorizacin como factor determinante de este proceso; por eso se realiza una
exploracin identificando las diferentes tcnicas que nos ayudan a saber el cmo
priorizar y no caer ms en la metodologa de lo informal.
A partir de una caracterizacin1, se identifica un grupo de tcnicas factibles para la

priorizacin de requisitos, de ah se seleccionan algunas tcnicas candidatas que
puedan aportar en la industria del software para dicha priorizacin, luego se
validan cuales de estas son reconocidas como formales, por ltimo se propone y
aplica una tcnica que sea efectiva para administrar los requisitos que se
demandan actualmente en los proyectos software.
Determinar los atributos peculiares de alguien o de algo, de modo que claramente se distinga de
los dems.
15
INTRODUCCIN
La priorizacin 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 ms 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 informacin para la priorizacin de los requisitos es

extremadamente necesaria, no tanto para ignorar los requisitos menos
importantes o desarrollar los ms importantes, sino que ayuda al administrador del
proyecto a resolver conflictos entre los requisitos, planear las entregas, etc. Esto
hace que la actividad de priorizacin 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 tcnicas para la priorizacin de

requisitos, estas tcnicas pueden clasificarse dependiendo del enfoque en tres
categoras: a) Agrupacin de prioridades, b) Tcnicas que combinan aspectos que
afectan las prioridades y c) Tcnicas de votacin e inversin, pero cada tcnica
tiene sus ventajas y desventajas.
De igual manera los distintos enfoques y tcnicas no especifican en qu etapa del

desarrollo del proyecto deben o pueden ser usados, se dejan a disposicin de los
lideres de desarrollo o del proyecto para su utilizacin. El no tener una claridad
acerca del uso de la tcnica y ms an en que etapa usarla, hace ms ambiguo y
confuso el uso de una u otra tcnica en el proceso de desarrollo de software,
inclinando a los lderes de proyectos a utilizar la regla del costo-beneficio [9],
donde el lder 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 condicin necesaria para algo [2].

16
El desarrollo de una propuesta que permita la implementacin y que responda al

qu y el cmohacer para poder realizar una planificacin del desarrollo de
los requisitos de software, basndose en una optimizacin de la priorizacin 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.
17
1. PLANTEAMIENTO DEL PROBLEMA
El proceso que se sigue para construir, entregar y evolucionar el software, desde

la concepcin, 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 Requisitos3 [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 solucin software.
Esta problemtica no es ajena en los proyectos de fabricacin de software [6],

considerando que en lo absoluto se generan costosos re-procesos de implantacin
e incluso de la misma elicitacin [12] de los requisitos; es en este proceso donde
se hace muy importante poder trabajar sobre mtodos ms efectivos que permita
disminuir esta brecha de incertidumbre (requisitos ambiguos o mal entendidos) y
de re-procesos al momento de la fabricacin de software, trayendo como
consecuencia favorable un producto con menos inconformidades de fabricacin.
Contar con mtodos colaborativos que nos ayuden a entender los requisitos,
ayuda tambin a que esa brecha de inconformidades sea ms pequea [13].
En el desarrollo de requisitos de software un factor determinante es la gestin de

los mismos y a su vez la priorizacin y planificacin [6], dicha priorizacin es un
factor de xito que determina la ptima utilizacin de los recursos tiempo, costos y
factor humano para una efectiva culminacin del producto esperado.
La evidente necesidad de contar con un mtodo que permita realizar una optima
priorizacin y planificacin de los requisitos de software, abre las puertas para
aportar en el proceso de ingeniera de software una propuesta metodolgica, la
cual llene el vaci que hoy no cobijan algunas metodologas estndares [11] en
los cuales se aborda el tema de la priorizacin como una actividad del desarrollo
de requisitos de software pero no se enfatiza en el cmo?, es decir, se plantea el
3
Es en esta rea de desarrollo donde se identifican, entienden, documentan y planifican los

requisitos
18
hecho de priorizar, pero no se deja claro el cmo se debe priorizar, dejando de

alguna manera al libre albedro del lder de desarrollo (o del proyecto) , una
actividad tan importante como la priorizacin y planificacin de los requisitos,
donde en ultimas, se utiliza ms que la tcnica su propia experticia.
19
2. OBJETIVOS DEL PROYECTO
2.1 OBJETIVO GENERAL
Validar tcnicas de priorizacin de requisitos y proponer una tcnica que haga

parte del proceso de desarrollo de requisitos que permita optimizar la priorizacin
de estos.
2.2 OBJETIVOS ESPECFICOS
Caracterizacin de las diferentes tcnicas de priorizacin de requisitos de

software.
Identificar factores en los requisitos que determinan y permiten su priorizacin.
Validar y aplicar la tcnica propuesta en empresas reales.
20
3. REFERENTE TERICO
Existen dos tendencia bsicas 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 relacionndose entre s y en el iterativo incremental se va desarrollando en
pequeos incrementos y en varias iteraciones posteriores.
Sommerville [15] establece las etapas de desarrollo de software secuencial. Estas

etapas son la definicin de requisitos, diseo del sistema y del software,
implementacin, pruebas unitarias, integracin y pruebas del sistema, operacin y
mantenimiento.
Segn Schach [16], el desarrollo de software iterativo consiste en un conjunto de

iteraciones seguidas unas tras otras. Las fases de cada interaccin incluyen la
especificacin, diseo, implementacin y pruebas, las cuales pueden llegar a
sobreponerse en algunos casos.
Las ventajas y desventajas de ambos modelos han sido discutidas en todos estos
aos, sin embargo lo que s se puede ganar es una visin 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 definicin y seleccin de los
requisitos del software es necesario por cualquiera de los dos caminos que se
tome.
Segn James Senn [17], existen tres estrategias para el desarrollo de sistemas: a)
El mtodo clsico del ciclo de vida de desarrollo de sistemas, b) El mtodo de
desarrollo por anlisis estructurado y c) El mtodo de construccin 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.
21
Consecuente a Schach, se concluye que el ciclo de vida de un sistema de

informacin 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, diseador, desarrollador y del usuario.
Como complemento a lo que James Senn afirma, se puede decir que la ingeniera
de requisitos es un rea de investigacin 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 ingeniera de requisitos se ubica en el punto de
encuentro entre lo informal y lo formal del desarrollo de software. La ingeniera de
requisitos debe cubrir todas las actividades relacionadas con la elicitacin,
especificacin 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 trmino sin
ambigedades, ya que diferentes autores lo definen de manera diferente y hacen
hincapi en diferentes puntos de vista en sus definiciones. Por ejemplo, el
estndar IEEE define el trmino [20] como:
Condicin, capacidad necesidad de un usuario para resolver un problema

alcanzar un objetivo.
Condicin capacidad que debe tener un sistema para satisfacer un contrato,
norma, especificacin o de otro tipo impuesta por un documento formal.
Una representacin documentada de una condicin o capacidad como en las
dos primeras.
Davis [21] complementa la definicin de la IEEE, mediante la definicin de un

requisito como "una necesidad del usuario una caracterstica necesaria, funcin
o un atributo de un sistema que puede ser detectado desde una posicin 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.
22
Es as como un aspecto fundamental del anlisis 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?, Cmo se hace?, Con que frecuencia
se presenta?, Qu tan grande es el volumen de transacciones o decisiones? ,
Cul es el grado de eficiencia con el que se efectan las tareas? , Existe algn
problema?, Qu tan serio es? Cul es la causa que lo origina?
El proceso de ingeniera 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]. Segn Kotonya y Sommerville [4], la
secuencia bsica del proceso de ingeniera de requisitos incluye la obtencin de
requisitos, anlisis de requisitos y negociacin de los mismos, la documentacin y
validacin de los requisitos. Sin embargo, no existe un proceso nico en la
ingeniera de requisitos que est adecuado para todas las organizaciones.
Adems, la descripcin del proceso secuencial de por s no es suficiente .La
ingeniera de requisitos hace hincapi en un enfoque de colaboracin para el
desarrollo de los productos [13], con la participacin de mltiples perspectivas de
los interesados que participan en un proyecto [3].
La ingeniera de requisitos es generalmente vista como la primera fase del ciclo

desarrollo del producto. Por ejemplo, Jackson [19] sostiene que la ingeniera de
requisitos y el diseo son actividades separadas, debido a que los requisitos son
en su mayora relacionados con el problema a resolver y el diseo tiene que ver
con la solucin al problema. Sin embargo, Kotonya y Sommerville [4], por ejemplo,
sostienen que estas dos son actividades interrelacionadas.
Sin embargo la ingeniera de requisitos suele ser vista como una actividad al inicio
del ciclo vida de desarrollo de software. La ingeniera de requisitos es necesaria a
travs 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 tambin trata algunas
23
prcticas especificas donde se plantean actividades dentro del ciclo de desarrollo

del software donde se gestionan los requisitos pero no define el cmo se deben
priorizar los requisitos. [22]
El nivel 2 requiere que hayamos considerados las siguientes cosas:
Gestin de requisitos,
Plan de Proyecto,
Monitorizacin y control del proyecto,
Gestin de acuerdos con proveedores,
Medida y anlisis,
Medidas de calidad en el proceso y producto,
Gestin de la configuracin
A continuacin podemos ver las actividades detalladas, definidas por CMMI a

realizar en el primer punto del nivel de madurez 2 en la gestin de requisitos.
SG Gestionar Requisitos
SP 1.1
SP 1.2
SP 1.3
SP 1.4
SP 1.5
requisitos.
(SG Meta especifica)
Obtener y comprender requisitos (SP - Prctica Especifica)

Obtener la aprobacin de los requisitos.
Gestionar los cambios en requisitos
Mantener una trazabilidad bidireccional de requisitos
Identificar inconsistencias entre el trabajo real a realizar y los
Otro referente es el modelo Requirements Management Maturity (RMM) [23],

donde tambin se expone la idea de identificar atributos y caractersticas de los
requisitos para luego priorizarlos. En este modelo tampoco se encuentra algo
explicito que indique el cmo priorizar aunque si se sugiere el hecho de tomar
mtricas e identificar la importancia de cada requisito en el proyecto.
24
En un artculo 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 fabricacin 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 difcil de
implementar todos los requisitos que se han suscitado para un sistema de
informacin. Adems, los requisitos deberan ser implementados en etapas, y la
priorizacin puede ayudar a determinar cules deben implementarse en primer
lugar. Seguramente muchas fabricas desarrollan los requisitos de ms bajo costo
en su implementacin [9], sin tener en cuenta su importancia. Otros desarrollan los
requisitos que son ms fciles primero, seguramente basados en su propia
experiencia. La cuestin es, Estos enfoques empricos tienen posibilidades de
lograr los objetivos del producto o solucin esperada? Para dar prioridad a los
requisitos de software, se recomienda un enfoque sistmico de priorizacin [3].
Si se tiene en cuenta un enfoque sistmico algunas tcnicas de priorizacin

podran ser potencialmente utilizadas en la ingeniera de requisitos como apoyo al
proceso de priorizacin o como ayuda a los lderes de desarrollo de software, de
tal forma que se acerque un poco esta actividad a una realidad basada en
ingeniera y no en un enfoque emprico.
Sommerville [15] Define la priorizacin de requisitos como la actividad en la cual

se identifican los requisitos ms importantes para el sistema. Harwell et al. [24]
describe la prioridad como una caracterstica del requisito que puede ser utilizada
para diferentes efectos de la solucin y de la necesidad de la compaa. Otro
como Karlsson y Ryan [7]; Jung [25] definen la priorizacin como la caracterstica
que identifica a un requisito que tiene mayor ponderacin en importancia y menor
costo.
25
Podramos mencionar tcnicas 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 comnmente en la bsqueda de informacin y puede ser

usado para la priorizacin de requisitos [27]. El enfoque bsico para ser usado en
requisitos es el siguiente:
Ponga todos los requisitos en una pila.

Tome uno de los requisitos como raz del rbol.
Tome otro de los requisitos y comprelo con el raz.
Si el requisito es menos importante que el nodo raz, se compara con el nodo
hijo izquierdo. Si el requisito es ms importante que el nodo raz, 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 ms o menos importante.
Repita los pasos 3-4 hasta que todos los requisitos han sido comparados e
insertados en el rbol.
Para efectos de presentacin recorra el rbol binario y ponga los requisitos en
una lista tomando el de menos importancia al final y el ms importante al inicio.
26
3.2 TCNICA DE ASIGNACIN

ASSIGNMENT TECHNIQUE)
DE
PESO
NUMRICO
(NUMERAL
Esta tcnica 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 nmero dentro de la escala de 1 a 5
indicando la importancia de cada uno de ellos [28]. Los nmeros 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 clasificacin final es el promedio de las clasificaciones de todos los
participantes para cada uno de los requisitos.
3.3 JUEGO DE LA PLANIFICACIN (PLANNING GAME)
Es una tcnica utilizada por el Mtodo de desarrollo de software Extreme

Programming [29, 29A] y se utiliza con los clientes para priorizar los requisitos
basado en historias. Esta es una variacin de la tcnica de asignacin numrica
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 sera bueno tener.
3.4 MTODO DE LOS 100 PUNTOS (100-POINT METHOD)
El mtodo de los 100 puntos [30] es bsicamente un esquema de tipo votacin

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 ms
importantes, el interesado puede usarlos de la manera que l considere ms
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 podra darle los 100 puntos. Sin
27
embargo, este tipo de esquema slo funciona para una votacin inicial. Si una
segunda votacin se toma, la gente tiende a redistribuir sus votos para conseguir
que sus favoritos avancen en el esquema de prioridades.
3.5 TEORA W (THEORY-W)
Teora-W fue inicialmente desarrollado en la Universidad del Sur de California [31,

32]. Tambin se conoce como "Win-Win" (Ganar-Ganar). Un punto importante es
que soporta la negociacin 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 construccin de planes bien estructurados

que cumplen con los estndares predefinidos para un fcil desarrollo, clasificacin
y consulta. "Vuela el plan" asegura que el progreso sigue el plan original. El
segundo principio, "Identificar y administrar sus riesgos", implica la evaluacin 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 clasificacin individual, el usuario considera si existen requisitos que
l est dispuesto a renunciar y que conoce completamente los riesgos e
implicaciones de ello. La Teora-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.
28
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 estimacin de recursos
necesarios para satisfacer cada necesidad, y la seleccin de un subconjunto de
los requisitos para optimizar la probabilidad de xito del producto en el mercado en
cuestin. 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 ms all de los requisitos de asignacin de
prioridades tradicionales, teniendo en cuenta los factores de negocio tambin
[33A].
3.7 WIEGERS' METHOD
Este mtodo se relaciona directamente con el valor de cada requisito para un

cliente [3]. La prioridad se calcula dividiendo el valor de una obligacin por la suma
de los costos y riesgos tcnicos asociados a su aplicacin [3]. El valor de una
obligacin se considera como funcin 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
implementacin, as como la penalidad si el requisito falta. Los atributos son
evaluados en una escala de 1 a 9.
3.8 FRAMEWORK DE PRIORIZACIN DE REQUISITOS (REQUIREMENTS

PRIORITIZATION FRAMEWORK)
El framework de priorizacin de requisitos asocia herramientas que incluyen [34,

35] las actividades de elicitacin y priorizacin. Este framework intenta direccionar
lo siguiente:
Elicitar con ayuda de los interesados del negocio los objetivos del proyecto.
29
Permitir que los interesados en el proyecto puedan dar puntajes a los

requisitos y objetivos del proyecto mediante una escala de calificacin grafica
difusa.
Calificar los requisitos basndose en una medida objetiva.
Encontrar las dependencias entre requisitos y agrupacin de requisitos tanto
que la priorizacin de los mismos sea ms efectiva.
Usar tcnica de anlisis de riesgos que permitan identificar entre los
interesados las desviaciones de apreciaciones o calificaciones subjetivas y la
asociacin entre los aportes de los interesados y las calificaciones finales.
3.9 CONJOINT
Es una tcnica estadstica que permite medir el valor relativo de cada atributo de
un producto, con lo cual se puede determinar qu combinacin de estos atributos
maximiza la probabilidad de eleccin por parte del consumidor. Inicialmente fue
desarrollada para su uso en modelos matemticos de psicologa y su aplicacin al
marketing fue ideada en 1974 por Paul Green, profesor en The Wharton School
[36]. La tcnica se desarrolla implementando lo siguiente:
Elegir los atributos ms valiosos para posicionar una marca.
Al tener que elegir entre varios productos potenciales, identificar al que tendr
mayor nivel de ventas
Decidir cul 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
30
3.10 ANALYTIC HIERARCHY PROCESS (AHP)
AHP es una mtodo para la toma de decisiones en situaciones donde existen

mltiples objetivos presentes [37][38][7] . Este mtodo 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
mtodo AHP consta de 5 pasos:
Revisar los requisitos candidatos y completarlos enteramente.
Aplicar el mtodo de comparacin por pares para evaluar el valor relativo de

cada uno de los requisitos candidatos.
Aplicar el mtodo de comparacin por pares para evaluar el costo relativo de

los requisitos candidatos.
Calcular el valor relativo de cada requisito candidato y el costo de su

implementacin 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 ANLISIS KANO (KANO ANALYSIS)
Anlisis Kano proporciona un medio poderoso y fcil de usar para clasificar

requisitos. Podemos utilizar esa clasificacin para manejar nuestras decisiones de
priorizacin, asegurndonos de entregar todos los requisitos que deben estar en la
primera versin. Kano tambin nos ayuda a centrarnos en las necesidades que
diferencian a nuestro software, identificando y contrastando los requisitos
esenciales para el cliente. [39]
31
Kano defini cuatro categoras en las que se puede cada caracterstica o requisito
pueden ser clasificados:
Sorpresa y deleite: capacidades que diferencian a un producto de la

competencia (por ejemplo, el iPod nav-wheel).
Ms es mejor: dimensiones a lo largo de un continuo con una direccin clara de
utilidad incremental (por ejemplo, duracin de la batera o la capacidad de la
cancin).
Debe ser: las barreras funcionales de acceso al mercado, sin estas
capacidades, los clientes no utilizaran el producto (por ejemplo, la aprobacin
de UL).
Mejor no ser: Representa las cosas que los clientes no les satisface (por
ejemplo, imposibilidad de aumentar la capacidad de la cancin a travs de
actualizaciones).
Aunque existen algunas tcnicas de priorizacin que podran ser usadas en
proyectos no solo de construccin de software sino de otra ndole, realmente
no es fcil encontrar dentro de las empresas desarrolladoras de software,
estndares, mtodos o tcnicas evolucionadas con respecto a la priorizacin y
planificacin de los requisitos de software [40]; existe ms bien una tendencia a
utilizar la experiencia como instrumento principal para realizar esta actividad; No
obstante, algunas fabricas podran estar usando alguna tcnica 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 priorizacin es uno de las actividades ms
difciles 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 metodolgica aliviara de alguna manera esta falencia y aportara
directamente al proceso de desarrollo software.
32
4. DESARROLLO METODOLGICO DEL PROYECTO
4.1. RECOPILACIN
PRIORIZACIN
DOCUMENTACIN
DE
LAS
TCNICAS
DE
A partir de la investigacin se han identificado algunas de las tcnicas de

priorizacin de requisitos ms reconocidas por la industria. Previamente en este
documento, estas tcnicas se exponen en breve dando una introduccin a las
mismas.
Tabla 1. Tcnicas de priorizacin

Tcnicas
Acrnimo
Autor
Tipo
Analytic Hierarchy Process

Binary Search Tree
Numeral Assignment Technique
Planning Game
100-Point Method
AHP
BST
Thomas L. Saaty
Adelson-Velskii y Landis.
Brackett, J.W
BECK, K.
Combinatorio
Theory-W
Conjoint analysis
Requirements Triage
Wiegers' Method
Requirements
Framework
Kano Analysis
PG
100P
University
California
Paul Green
of
Karl E. Wiegers
Combinatorio
Agrupacin
Votacin
Southern
Combinatorio
Combinatorio
Prioritization
Combinatorio
Noriaki Kano
La caracterizacin de las tcnicas tiene el objetivo de identificar cul de estas,

segn sus procesos y metas, pudiera ajustarse ms a los diferentes tipos de
industria del software y sus diversos proyectos; a continuacin se hace una
descripcin ms detallada de las tcnicas que se listan en la Tabla 1.
Para presentar el detalle de las tcnicas se ha diseado un marco sobre el cual

stas se documentan.
33
4.1.1 Marco descriptivo de la tcnica
Nombre de la Tcnica
Descripcin de la tcnica
Proceso de la Tcnica
Entradas
Atributos
Requisitos
Actividades
Procesos
Tareas
Salidas
Logros
Entradas
ACTIVIDADES DEL MTODO
# Actividad
Ttulo de la actividad
Para qu y por qu tiene relevancia la actividad en la
Propsito
totalidad de la tcnica.
Breve descripcin de la Actividad
Descripcin
Aquellos roles encargados de realizar la actividad
Roles
Tcnica
Prcticas o procedimientos para obtener el resultado y lograr el propsito de la
tcnica.
Salidas
Resultado (Logros, metas) de la tcnica
34
4.1.2 Caracterizacin detallada de las Tcnicas
AHP - Analytical Hierarchy Process

Thomas L. Saaty
AHP es un mtodo para la toma de decisiones en situaciones donde se presentan
mltiples objetivos. Este mtodo utiliza una matriz de comparacin por pares para
calcular el valor y los costos relativos de los requisitos. Mediante el uso de AHP,
el ingeniero de requisitos puede tambin 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 mtodo
AHP:
1. Revisar los requisitos del candidato a la integridad.
2. Aplicar el mtodo de comparacin por pares para evaluar el valor relativo de
los requisitos candidatos.
3. Aplicar el mtodo de comparacin por pares para evaluar el costo relativo de la
implementacin de cada requisito candidato.
4. Calcular el valor relativo de cada requisito candidato y los costos de
implementacin, y la trama de cada uno en un diagrama de costo-valor.
5. Utilice el diagrama de costo-valor, como un mapa para el anlisis de los
requisitos candidatos.
ENTRADAS
Requisitos
candidatos.
Valor relativo.
Costo Relativo
Proceso
ACTIVIDADES
S-1:
Revisin
de
requisitos
candidatos
para la integridad.
S-2: Comparacin por
pares
S-3:
Determinar
la
prioridad
de
los
requisitos
S-4:
Columna
de
puntuacin
S-5:
Verificar
la
consistencia.
35
SALIDAS
Grfica Valor.
Grfica Costo.
Grfica Valor vs
Costo.
ENTRADAS AL MTODO
Las entradas corresponden a los requisitos que el analista ha recolectado
previamente en el proceso de elicitacin. Estos requisitos deben estar en un
mismo nivel de abstraccin4 y estar claramente documentados, sin
ambigedades.
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
composicin y resultado de una conglomeracin de requisitos. Por esto, y para
que AHP sea lo ms preciso posible, se espera que los requisitos se encuentren
en un mismo nivel de abstraccin.
Requisitos candidatos.
Valor relativo de cada requisito en el producto.
Costo relativo que se genera por la implementacin de cada requisito.
4.1.3 Actividades del mtodo
S-1
Propsito
Descripcin
REVISIN DE REQUISITOS CANDIDATOS PARA LA

INTEGRIDAD
Revisar que los requisitos estn claros y completos.
Se revisa y se re-analiza los requisitos para asegurarse que
estn correctos, completos y claros.
Roles
Rol
Jefe del proyecto
Responsabilidades
Lidera el proceso.
Stakeholder
Acompaa
ponderacin
requisitos.
en
de
la
los
Tcnicas
Despus de reunirse con el cliente, se revisan los requisitos basados en la
retroalimentacin recibida, de esta forma se pueden identificar problemas de
ambigedades, de falta de informacin o mala interpretacin.
Segn la RAE, Abstraer significa, separar por medio de una operacin intelectual las cualidades
de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura
esencia o nocin.
36
S-2
Propsito
Descripcin
COMPARACIN POR PARES

Obtener una comparacin cardinal del valor y costo de los
requisitos.
En este paso, los interesados implementan el mtodo de
comparacin por pares de AHP. Se hacen dos matrices una
para el valor relativo y otra para el costo relativo. Suponiendo
que el nmero de requisitos sea n, el nmero de celdas
resultantes ser de n x n. La calificacin para el costo y valor
relativo se da en una escala de 1 a 9.
Tabla 2. Ejemplo de una matriz de comparacin por pares
con 8 requisitos
SR-1
SR-2
SR-3
SR-4
SR-5
SR-6
SR-7
SR-8
SR-1
1
9
6
3
2
3
3
3
SR-2
0,1
1
3
4
5
5
6
7
SR-3
0,2
0,3
1
2
2
2
2
4
Rol
Jefe del proyecto
SR-4
0,3
0,3
0,5
1
3
3
3
3
SR-5
0,5
0,2
0,5
0,3
1
5
6
7
SR-6
0,3
0,2
0,5
0,3
0,2
1
5
5
SR-7
0,3
0,2
0,5
0,3
0,2
0,2
1
3
SR-8
0,3
0,1
0,3
0,3
0,1
0,2
0,3
1
Responsabilidades
Lidera el proceso.
Acompaa
en
la
ponderacin
de
los
requisitos.
Roles
Stakeholder
Tcnica
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, segn
la medida que se tome en funcin de la comparacin.
Como en un producto cartesiano, la comparacin 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
37
Tabla 3. Interpretacion de los valores en la matriz

Intensidad
valor
del
Interpretacin
Requisitos i y j son de igual valor.
Requisito i tiene un valor ligeramente superior a j.
Requisito i tiene un valor superior a j.
Requisito i tiene un valor muy superior a j.
Requisito i tiene un valor absolutamente superior a j.
2, 4, 6, 8
Estas son las

adyacentes.
Recprocos
Si el requisito i tiene menor valor que j
escalas
intermedias
entre
dos
juicios
Tabla 4. Interpretacin de los costos en la matriz

Intensidad
valor
del
Interpretacin
Requisitos i y j son de igual costo.
Requisito i tiene un costo ligeramente superior a j.
Requisito i tiene un costo superior a j.
Requisito i tiene un costo muy superior a j.
Requisito i tiene un costo absolutamente superior a j.
2, 4, 6, 8
Estas son las

adyacentes.
Recprocos
Si el requisito i tiene menor valor que j
S-3
Propsito
Descripcin
escalas
intermedias
entre
dos
juicios
DETERMINAR LA PRIORIDAD DE LOS REQUISITOS

Hallar la matriz de comparacin normalizada.
Se promedian los datos sobre las columnas normalizadas
para calcular el vector propio de la matriz que representa la
distribucin del criterio.
38
Rol
Jefe del proyecto
Responsabilidades
Lidera el proceso.
Acompaa
en
la
validacin
de
los
requisitos.
Roles
Stakeholder
Tcnica
Primero, se hace la sumatoria de los valores para cada columna de la matriz.

n
ai j = amj + a(m+1)j + a(m+2)j + + anj = Columna j

i m
ai( j 1) = am(j+1) + am+1(j+1) + am+2(j+1) + + an(j+1)
= Columna j+1
i m
n
ain = amn + a(m+1)n + a(m+2)n + + ann
= Columna n
i m
A continuacin, se divide cada valor de la matriz por la suma de su respectiva

columna.
Tabla 5. Matriz Normalizada

SR-1
SR-1
SR-2
SR-3
SR-4
SR-5
0,03333333 0,00357143 0,01234568 0,02366864 0,02435065
SR-6
SR-7
SR-8
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
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
SR-7
0,1 0,19285714 0,14814815 0,21301775 0,29220779 0,39787798
SR-8
0,1
0,225
0,0877193 0,09138381
0,0795756 0,03508772 0,07310705

0,1754386 0,12184508
0,2962963 0,21301775 0,34090909 0,39787798 0,52631579 0,36553525
39
S-4
COLUMNA DE PUNTUACIN
Propsito
Hallar la columna de puntuacin de los requisitos.
Descripcin
La puntuacin de cada requisito es el porcentaje que el requisito

suma al valor total de los requisitos.
Rol
Responsabilidades
Jefe del proyecto
Lidera el proceso.
Roles
Tcnica
Para determinar la puntuacin de cada requisito, se halla el promedio de la fila de la
matriz normalizada, dividiendo la suma de cada fila por el nmero de requisitos, el
resultante de esta operacin es una nueva columna definida aqu como
PUNTUACIN.
Promedio para una fila i:
n
Promedio( Nij =Nim + Ni(m+1) + Ni(m+2) + + Nin = Fila i), donde Nij es el
j m
valor normalizado de la etiqueta aij.

Tabla 6. Columna de Puntuacin.
Puntuacin
0,03801494
0,06021252
0,0811559
0,08385113
0,09182779
0,13164463
0,20517406
0,30811902
40
S-5
VERIFICAR LA CONSISTENCIA
Propsito
Verificar que los resultados sean coherentes y fiables.
Descripcin
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 ms importante que B y el requisito B se considera
que es tres veces ms importante que el requisito C, la consistencia
cardinal perfecta entonces implicara que el requisito A se
considerar seis veces ms 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 priorizacin es inconsistente.
Roles
Rol
Responsabilidades
Jefe del proyecto
Lidera el proceso.
Tcnica
Se utiliza el ndice de consistencia / ndice aleatorio (CI / RI) para verificar la
consistencia de los resultados.
Calcular el producto entre la matriz de comparacin (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 PUNTUACIN. 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 PUNTUACIN, respectivamente esto se repite
para cada celda subsiguiente.
Calcular el valor de CI; Calcular el ndice de consistencia con la frmula "=
(promedio (columna Ratio) - n) / n - 1" donde n es el nmero de requisitos.
Calcular la puntuacin de CI / RI. Si la puntuacin de CI / RI es suficientemente
pequea, 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
41
embargo, si el CI / RI es mayor que 0.10, hay incoherencias y el mtodo AHP no

puede dar resultados significativos. Para calcular la puntuacin de CI / RI, se
obtiene el valor de RI estndar de la informacin de Saaty, algunos de los valores
de RI estn listados en la Tabla 6.
Tabla 7. Random index values - ndice de valores aleatorios
Numero de requisitos
RI
2
0
3
0,58
4
0,9
5
1,12
6
1,24
7
1,32
8
1,41
9
1,45
10
1,51
Tabla 8. Ratio
Producto
0,3470747
Ratio
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
Tabla 9. Segn el nmero de requisitos, para este ejemplo el indice

aleatorio(RI) es 1,41
CI
CI/RI
0,35291563
0,25029478
SALIDAS DEL MTODO

Las salidas del mtodo deben contener dos tipos de diagramas que muestren el
comportamiento de cada requisito segn el valor y costo. Debe mostrar una tercera
grfica, donde se exponen las prioridades para cada requisito del proyecto.
Grfica 1; Distribucin del Valor de los requisitos.

Grfica 2; Distribucin del Costo de los requisitos.
42
Grfica 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 Bsqueda

Adelson-Velskii y Landis
El rbol de bsqueda binaria es un algoritmo que se utiliza normalmente en la
bsqueda y/o recuperacin de informacin y se puede escalar fcilmente para ser
utilizado en la priorizacin de requisitos. Se recomienda que el rbol siempre este
equilibrado para una insercin ms rpida. 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 subrbol
izquierdo menos la altura de su subrbol 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 subrboles.
ENTRADAS
Lista
requisitos.
de
Proceso
ACTIVIDADES
B-1: Listar requisitos
B-2: Comparacin de
nodos (insercin)
ENTRADAS AL MTODO
Lista de requisitos
43
SALIDAS
Requisitos
priorizados.

B-1
LISTAR REQUISITOS
Propsito
Listar los requisitos.
Descripcin
Identificar los items que se van a priorizar en este proceso de

anlisis. Todos los tems deben estar al mismo nivel de
abstraccin; no se deben mezclar requisitos con algo tan general
como las caractersticas.
Rol
Responsabilidades
Jefe del Proyecto
Lidera el proceso.
Roles
Tcnica
Los requisitos identificados se organizan en una lista.
B-2
COMPARACIN DE NODOS
Propsito
Identificar los requisitos que segn el valor/importancia de cada

uno, tengan mayor prioridad en el proyecto.
Descripcin
Para la comparacin, 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 raz, y los nodos
secundarios a la izquierda tienen menos valor | importancia que
el nodo raz. Cada nodo hijo es en s mismo un nodo raz a su
porpio nodo hijo. Si un nodo no tiene ningn hijo, este se llama
hoja.
44
Rol
Responsabilidades
Lder del equipo tcnico.
Roles
Principales
representantes de los
Suministra
las
desarrolladores
puntuaciones para el
valor | importancia.
Principales
Suministra
las
representantes
del puntuaciones para el
cliente
valor | importancia.
Tcnica
Arbitrariamente se toma uno de los requisitos y se hubica como nodo raz. Se

toma otro de los requisitos y se compara con el nodo raz, si el requisito es menos
importante (valor|importancia), entonces el nodo raz, se compara con el hijo de la
izquierda. Si el requisito es ms importante (valor|importancia) que el nodo raz, se
compara con el hijo de la derecha. Si el nodo no tiene ningn 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 ms o
menos importante.
Lo anterior se repite hasta que todos los requisitos hayan sido comparados.
SALIDAS DEL MTODO
Luego de situar en una nueva lista los requisitos, y segn el orden jerrquico que
esta representado en el rbol final; para la salida de este mtodo se debe tener la
priorizacin de los requisitos, ordenados de mayor a menor segn su grado de
prioridad.
Planning Game (PG)

Planning Game (PG) es una funcin de programacin extrema (XP) y se utiliza
con los clientes para dar prioridad a las caractersticas 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).
45
ENTRADAS
Lista
requisitos.
de
Proceso
ACTIVIDADES
PG-1:
Categorizar
requisitos
SALIDAS
Lista
de
los
requisitos con la
mayor prioridad.
ENTRADAS AL MTODO
Lista de requisitos.

PG - 1
CATEGORIZAR REQUISITOS
Propsito
Identificar aquellos requisitos con los cuales se debe empezar el

desarrollo del proyecto.
Descripcin
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 sera
agradable tener.(nice to have).
Rol
Roles
Principales
representantes
cliente
Responsabilidades
Cataloga los requisitos,
del segn el valor que estos
tengan en el proyecto.
Tcnica
A partir de una estimacin subjetiva, se aprecia el valor que cada requisito, con su
implementacin, otorga al producto. Segn esta apreciacin 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".
46
SALIDAS DEL MTODO

Luego de situar en una nueva lista los requisitos, segn su clase y valor que le
aporta al producto final. Para la salida de este mtodo se debe tener los requisitos
organizados por categoras.
Categoras:
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 mtodo de los 100 puntos es bsicamente un sistema de votacin 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 ms
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 slo funciona para una votacin inicial. Despus que los resultados
han sido publicados, todos los participantes podrn ver como han sido las
votaciones de los dems, por lo que si una segunda votacin se toma, la gente
tiende a redistribuir sus votos para conseguir que sus favoritos avancen en el
esquema de prioridades.
ENTRADAS
Lista
requisitos.
de
Proceso
ACTIVIDADES
P-1: Asignacin de
puntaje
P-2: Calculo de
prioridades
SALIDAS
Priorizacin
de
cada individuo.
Grfica 2.
ENTRADAS AL MTODO
Las entradas corresponden a los requisitos que el analista ha recolectado
previamente en el proceso de elicitacin.
Lista de requisitos.
47

P-1
ASIGNACIN DE PUNTAJE
Propsito
Asignar puntajes a los requisitos.
Descripcin
Dividir los puntos entre todos los requisitos, de acuerdo a cul de

los requisitos es ms importante para el sistema.
Rol
Responsabilidades
Suministra
puntuaciones
requisitos.
Roles
Desarrolladores
de
las
los
Tcnica
A partir de una estimacin subjetiva, se aprecia el valor que cada requisito, con su
implementacin, otorga al producto. Segn esta apreciacin se asigna un puntaje a
cada requisito.
P-2
CALCULO DE PRIORIDADES
Propsito
Obtener las prioridades de cada requisito.
Descripcin
Despus 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.
Rol
Responsabilidades
Roles
Jefe del Proyecto
Lidera el proceso.
48
Tcnica
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 MTODO
Para la salida de este mtodo se debe tener la priorizacin que cada uno de los
desarrolladores le asigno a los requisitos y la priorizacin global de los mismos.
Wiegers Method Metodo de Wiegers

Karl E. Wiegers
Priorizacin basada en valor, costo, y riesgo relativo.

Este mtodo 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 tcnicos asociados con su implementacin. El valor de un
requisito se considera como funcin 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
implementacin, as como la pena impuesta si el requisito falta. Los atributos son
evaluados en una escala del 1 al 9.
49
ENTRADAS
Influencia relativa.
Beneficio relativo.
Penalidad
relativa.
Costo relativo.
Riesgo relativo
Proceso
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
SALIDAS
Prioridad de los
requisitos
ENTRADAS AL MTODO
Las entradas en este mtodo corresponden a los requisitos de carcter
negociable, aquellos que no se encuentran en la cima de la lista de priorizacin.
Es decir,
no se debe incluir en este anlisis, aquellos requisitos que
corresponden al ncleo 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, caractersticas 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 segn el

beneficio que con su implementacin este otorga al producto.
Penalidad Relativa: Valor relativo que se estima por la no implementacin
de un requisito.
Costo relativo: El costo relativo se refiere a la extensin de tiempo o trabajo
que los desarrolladores estiman se presentara en la implementacin de
cada requisito.
Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los
requisitos. (Riesgo de negocio, tcnico, de estimacin, etc.).
50
Actividades y proceso del mtodo

W-1
Propsito
Descripcin
LISTAR REQUISITOS
Listar los requisitos, caractersticas o casos que se desean
priorizar.
anlisis. Todos los tems deben estar al mismo nivel de abstraccin;
no se deben mezclar requisitos con algo tan general como las
caractersticas.
Rol
Responsabilidades
Lidera el proceso.
Roles
Arbitra conflictos.
Jefe del Proyecto
Ajusta el aporte de los

otros participantes si es
necesario.
Tcnica
Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas
inherentes a los propios, por ejemplo; Una norma sera; 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
Propsito
Estimar el beneficio relativo que cada requisito provee al cliente o al

negocio.
Descripcin
En una escala del 1 al 9 se valora el beneficio relativo del requisito,

donde 1 indica Beneficio despreciable y 9 significa Enorme valor.
Rol
Roles
Principales
representantes
cliente
Responsabilidades
Suministra
las
beneficio y la penalidad.
51
Tcnica
A partir de una estimacin subjetiva, se valora el beneficio que cada requisito con
su implementacin otorga al producto.
W-3
PENALIDAD RELATIVA
Propsito
Estimar la penalidad relativa que el cliente o el negocio sufrira si el

requisito no es implementado.
Descripcin
En una escala del 1 al 9 se valora la penalidad relativa del requisito,

donde 1 indica ningun inconveniente y 9 significa sancin grave.
Rol
Roles
Principales
representantes
cliente
Responsabilidades
Suministra
las
Tcnica
A partir de una estimacin subjetiva, se valora la penalidad que cada requisito con
la omisin de su implementacin otorga al producto
W-4
Propsito
Descripcin
VALOR TOTAL
Calcular el valor total de las puntuaciones en los requisitos respecto
a penalidad y beneficio. Calcular el valor porcentual de cada
requisito.
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 %).
52
Rol
Responsabilidades
Roles
Jefe del Proyecto
Lidera el proceso.
Tcnica
Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la
valorizacin 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 % =
VTi *100
n
VTi
, donde n es el nmero de requisitos
i 1
53
W-5
COSTO RELATIVO
Propsito
Estimar el costo relativo que conlleva la implementacin de cada

requisito.
Descripcin
Se valora el costo que cada requisito con su implementacin

otorga al producto. Este costo se mide segn la extensin de
tiempo o trabajo que cada requisito le agregue al proyecto.
Rol
Roles
Principales
representantes de
desarrolladores
Responsabilidades
los Lder del equipo tcnico.
Tcnica
Se valora el costo relativo de la implementacin 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 documentacin que se
necesitara, etc.
Suponiendo que;
Costo Relativo para un requisito(CRi)
Se puede decir que;
n
CRi , donde n es el nmero de requisitos.
Costo Total =
i 1
Costo % =
CRi *100
n
CRi
i 1
54
W-6
Propsito
Descripcin
RIESGO RELATIVO
Estimar el grado relativo de riesgo que conlleva la implementacin
de cada requisito.
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 concentracin, mientras
que 9 indica serias preocupaciones sobre la viabilidad.
Rol
Roles
Principales
representantes de
desarrolladores
Responsabilidades
Tcnica
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;
n
RRi , donde n es el nmero de requisitos.
Riesgo Total =
i 1
Riesgo % =
RRi *100
n
RRi
i 1
55
W-7
Propsito
Obtener la prioridad de cada requisito.
Descripcin
Una vez estimado todo los factores anteriores, se calcula la

prioridad para cada requisito.
Rol
Principales
representantes de
desarrolladores
Roles
Responsabilidades
Tcnica
Con la siguiente formula se calculan las prioridades de cada requisito:
Valor %
prioridad
(Costo% * inf luenciaDel cos to ) (riesgo% * inf luenciaDel Riesgo )
Figura 1. Modelo: Matriz de priorizacin

Influencias
relativas:
Requisitos
Benefici
o
Relativo
Penalid
ad
Relativa
1
Valor
Total
Valor %
1.
2.
3.
4.
5.
6.
7.
n.
56
Costo
Relativo
1
Costo
%
Riesgo
Relativo
Riesgo
%
Priorida
d
W-8
ORDENAR
Propsito
Ordenar la lista para tener mejor visibilidad de las prioridades.
Descripcin
Ordenar la lista de caractersticas en orden decreciente de

prioridad.
Rol
Roles
Principales
representantes de
desarrolladores
Responsabilidades
SALIDAS DEL MTODO

Para la salida de este mtodo se debe tener la priorizacin de los requisitos que
fueron candidatos, ordenados de mayor a menor segn su grado de prioridad.
57
5. ANLISIS DE APROPIACIN Y USO DE LAS TCNICAS POR LA

INDUSTRIA DEL SOFTWARE.
Para el estudio del contexto de las empresas Colombianas en relacin a sus

procesos y prcticas de priorizacin de requisitos en proyectos software, se realiz
una caracterizacin a las empresas del Sur Occidente Colombiano segn los
siguientes objetivos:
Tener un diagnstico de los procedimientos, tcnicas, mtodos y herramientas

que utilizan como soporte a los procesos de administracin 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, tcnicas, mtodos y

herramientas para priorizar requisitos en proyectos software.
La estrategia seleccionada para adelantar el estudio, fue utilizar la encuesta como

instrumento de recoleccin de informacin.
5.1 FICHA TCNICA DE LA ENCUESTA
La muestra de este estudio consta de 16 empresas pequeas desarrolladoras de

software del sur occidente Colombiano.
Las empresas fuentes de informacin para la encuesta se escogieron bajo el

criterio aleatorio. En lo que respecta al componente aleatorio, cada empresa tena
la misma probabilidad de ser escogida.
Las encuestas se aplicaron a empresas ubicadas en la capital del Valle del Cauca
y Bogot.
58
Tabla 10. Ficha tcnica del estudio adelantado

Universo en estudio
Tamao de muestra
Distribucin
de
muestra
Empresas desarrolladoras de software e integradoras de sistemas.

16 empresas
la
Cali
Bogot
Cobertura Geogrfica
Error muestral
Nivel de Confianza
Tipo de muestreo
Recoleccin
de
informacin
Fecha del trabajo
campo
93,8 % Cali, 6,2 % Bogot

(15 empresas)
(1 empresa)
+ 4.02%
95,5%
Aleatorio, Mixto
la
de
Entrevistas personales en empresas

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 travs de
un cuestionario conformado por dos secciones para un total de 7 preguntas (ver
Anexo A: Encuesta para el estudio de contexto):
Seccin 1: Informacin general de la organizacin de la empresa.
Seccin 2: Informacin sobre la aplicacin de mtodos de priorizacin de

requisitos.
A continuacin se presentan los resultados para las preguntas de cada seccin.

Slo se consideran aquellas pertinentes al proyecto de mejora a adelantar, y el
nmero de la pregunta referenciado corresponde al nmero en el instrumento
completo (ver Anexo A).
59
5.2.1 Seccin 1: Informacin general. En esta seccin de informacin general se

buscaba entender aspectos organizacionales, administrativos, financieros, de
comercializacin y caractersticas del mercado al cual proveen productos y
servicios. Se recolect informacin mediante 5 preguntas.
Para el inters 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 tamao de su empresa de acuerdo a:

Ingenieros relacionados con las actividades de desarrollo de software. Se ofrecan
los rangos 1-3, 4-7, 8-15, 16 40, 40 ms.
Tabla 11. Ingenieros de sistemas en las empresas

Nmero
de Ingenieros
13
47
8 15
16 40
40 ms
Frecuencia
Porcentaje
3
4
2
4
3
18,75 %
25 %
12,5 %
25%
18,75 %
60
Figura 2. Ingenieros de sistemas en las empresas

30,00%
25%
25%
Nmero de empresas (%)
25,00%
20,00%
18,75%
18,75%
15,00%
12,50%
10,00%
5,00%
0,00%
13
47
8 15
16 40
40 ms
Nmero de Ingenieros de sistemas
Los anteriores porcentajes nos dan una idea del tamao de la empresa en lo que
respecta a recursos humanos directamente relacionados con desarrollo de
productos software. Con esta medida podemos saber de cun compleja puede ser
la organizacin y administracin en una empresa.
5.2.1.2 Pregunta 2. Cuntos productos de software tiene su empresa?
Tabla 12. Nmero de productos software por empresa.

Empresa
1
2
3
4
5
6
7
8
9
N de productos
5
0
5
0
8
0
8
3
3
61
Tabla 12. (Continua)

Empresa
10
11
12
13
14
15
16
N de productos
1
3
0
10
5
3
0
Segn el nmero de productos software de cada empresa se puede hacer una

idea de la experiencia de estas empresas en cuestin de mtodos de
administracin de proyectos y tcnicas de priorizacin, partimos del hecho de que
se aprende de las experiencias y se supone por cada desarrollo un refinamiento
de las tcnicas.
Figura 3. Relacin Tamao de la empresa vs Nmero de productos.

12
10
8
6
5
N de productos
4
3
2
1
Tamao
0
1
10 11 12 13 14 15 16
Empresas
La Figura 3 muestra el tamao de la empresa por nmero de desarrolladores

vinculados directamente en los proyectos software con relacin al nmero de
productos por empresa. Para que se pueda leer de una forma ms clara la anterior
figura, a continuacin las equivalencias de los tamaos diagramados en la Figura
3 segn los datos en la encuesta.
62
Tabla 13. Equivalencias de tamao con Rangos en encuesta.

Tamao
1
2
3
4
5
Rangos
1-3
4-7
8-15
16-40
40-ms
5.2.1.3 Pregunta 3. Cul es su actividad principal? Para este caso se

ofrecan las opciones:
Desarrollo de software hecho a la medida

Desarrollo de software genrico
Tabla 14. Actividades principales por empresa

Empresa
Software a la medida
Software genrico
10
11
12
x
x
13
14
15
16
63
Nmero de empresas
Figura 4. Actividades de las empresas

10
9
8
7
6
5
4
3
2
1
0
56,25%
25%
12,50%
6,25%
Software a la medida
Sofware genrico
Sofware genrico y a
la medida
ninguno
Actividades de las empresas
5.2.1.4 Pregunta 4. Cules de los siguientes modelos ha implementado su

organizacin en los ltimos 3 aos?
Tabla 15. Modelos implementados por las empresas

CMM-SW
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CMMI
SPICE
ISO 9001
PSP/TSP
NA
No sabe
x
Otros
x
x
x
x
x
x
RAD
x
x
SCRUM
x
x
x
x
x
x
64
La mayora 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 organizacin y madurez de sus procesos.
Seccin 2: Informacin sobre la aplicacin de los mtodos de priorizacin de

los requisitos.
5.2.1.5 Pregunta 5. De la cartilla adjunta cul(es) mtodo(s) de priorizacin de

requisitos aplica.
Mtodos combinatorios.
Mtodos mixtos combinatorios.
Mtodo
s de votacin.
Tabla 16. Aplicacin de mtodos de priorizacin de requisitos en las

empresas.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Combinatorio
x
x
Mixto
Votacin
Otros, Cul(es)?
x
na
x
x
x
x
x
x
x
x
x
x
x
x
Propio
x
x
65
La Tabla 16 da una visin global de la metodologa de cada empresa respecto a

priorizacin de requisitos.

empresas(Desarrollo de software hecho a la medida) .
1
2
3
4
5
7
10
12
16
Combinatorio
x
x
Mixto
Votacin
Otros, Cul(es)?
x
x
x
x
x
x
x

empresas (Desarrollo de software genrico).
11
13
14
15
Combinatorio
x
x
Mixto
Votacin
Otros, Cul(es)?
Propio
x

empresas(Desarrollo de software hecho a la medida y genrico).
8
9
Combinatorio
x
x
Mixto
Votacin
Otros, Cul(es)?
De la tabla 17 a la 19 se dividen las empresas en 3 grupos; Desarrollo de software

hecho a la medida, genrico y hecho a la medida y genrico, de estos 3 grupos se
hace una categorizacin de las empresas respecto a la aplicacin de mtodos de
priorizacin de requisitos.
66
6. CONCLUSIONES DE LA EVALUACIN
Se pudo saber cmo las empresas implementan modelos de desarrollo de

software entre los cuales algunos, como el CMMI, sugieren la priorizacin de
requisitos. El estudio indica que las empresas, segn sus modelos de desarrollo,
de alguna forma s aplican priorizacin de requisitos.
A travs de una caracterizacin 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 evaluacin
Al parecer los mtodos combinatorios son ciertamente preferidos por las empresas
o bien son de los ms conocidos, ya que el indicador arroja mayor porcentaje de
uso de este tipo de tcnicas para la priorizacin de requisitos.
Ya que la teora indica que tanto el ambiente organizacional como la naturaleza de

los proyectos definen la tcnica que se debe usar para la priorizacin de los
67
requisitos, en un principio se pens que por cada tipo de empresa (categorizadas

segn la actividad principal, a) Desarrollo de software a la medida, b) genrico o,
c) genrico y a la medida), se practicara de forma distinta la priorizacin, sin
embargo para la mayora de casos las empresas utilizan los mtodos
combinatorios, donde la tcnica ms conocida y practicada es Numeral
Assignment Technique.
Lo que hacen estas empresas es simplemente asignar valores a cada requisito

basndose en experiencias de otros proyectos, ocasionando que la priorizacin en
el caso de Numeral Assignment Technique sea subjetiva y poco precisa.
68
7. ANLISIS DE HERRAMIENTAS DE ADMINISTRACIN DE REQUISITOS
El anlisis consta de un grupo de herramientas usadas en la administracin de

proyectos software. Este anlisis quiere determinar cules de las tcnicas se
utilizan ms en los procesos de gestin de requisitos. Es importante saber cual
tcnica implementan estas herramientas en su proceso de priorizacin ya que son
productos muy usados y reconocidos en la industria.
Para la eleccin de estas empresas y sus herramientas se us el mtodo

aleatorio. En lo que respecta al componente aleatorio, cada herramienta tena la
misma probabilidad de ser escogida.
7.1.1 Pregunta 1. Su herrramienta usa algunas de las siguientes tcnicas:

Binary Search Tree, Numeral Assignment Technique, Planning Game, the 100Point Method, Theory-W, Requirements Triage, Wiegers' Method, Requirements
Prioritization Framework, y AHP? Listelas.
69
7.1.2 Pregunta 2. Usa algn otra tcnica? Cul?
Acclaro DFSS
Axiomatic
Solutions
Aligned
Elements
Aligned
ReqMan
RequirementOne
IRqA
Visure Solutions
Cognition
Cockpit
Cognition
RaQuest
SparxSystems
Design
Ninguno
otros
AHP
Wiegers' Method
Theory-W
100-Point Method
Planning Game
Requirements
Prioritization Framework
Distribuidor
Requirements Triage
Herramientas
Numeral Assignment
Technique
Binary Search Tree
Tabla 20. Herramientas de administraciones
x
x
KAN
O
x
De nuevo el estudio arroja que una mayora, en este caso 50%, implementa en su
proceso de administracin de requisitos, los mtodos combinatorios para priorizar,
ms que nada la tcnica Numeral Assigment Technique.
70
8. PROPUESTA; NUEVA TCNICA
La diversificacin de tcnicas de priorizacin es una prctica muy comn para

mejorar procesos ajustando metodologas a cada proyecto y contexto. Haciendo
caso a esta premisa que plantea la diversificacin de tcnicas, se ha ajustado una
tcnica apartndola de su estado nico y uniforme para acoplarla a otra esperando
que de esta asociacin se complemente una tcnica con la otra. El fin de esta
mezcla es refinar una idea y presentar una nueva opcin, una nueva tcnica.
Antes se ha propuesto la unin de tcnicas para la priorizacin, tomando lo mejor
de cada una y desarrollar una idea mejor. Tomando un ejemplo formal, la unin de
las tcnicas AHP y PG, PGcAHP [42], otro ejemplo no tan formal sera la
estrategia de las empresas que priorizan con tcnicas propias que en realidad son
una diversificacin de otras ya conocidas. Para esta oportunidad la propuesta es la
combinacin de las tcnicas Planning Game (PG) y Wiegers Method, PGcWs.
Aunque en una primera instancia se pens en implementar PGcAHP hoy

pensamos que una tcnica como PGcWs se acerca ms a la realidad de las
empresas del contexto; se dice del contexto porque segn cada proyecto y
empresa, varia la tcnica a implementar y la tcnica per se. Aun cuando PGcAHP
es una tcnica bastante precisa y til, se hace muy exhaustivo el proceso de
valuar en dos matrices distintas cada requisito contra todos los dems, la
metodologa cartesiana demanda tiempo y no es rentable para el negocio.
71
PG with Wiegers Method PGcWs
Priorizacin basada en atributos, valor, costo, y riesgo relativo.

Identificar atributos de los requisitos es importante en este mtodo, ya que a
diferencia de la tcnica PG, en PGcWs primero se deben categorizar los
requisitos para priorizar por categora.
Al igual que en el mtodo de Wieger la prioridad se calcula dividiendo el valor de
un requisito por la suma de los costos y riesgos tcnicos asociados con su
implementacin. El valor de un requisito se considera como funcin 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 implementacin, as como la pena impuesta si el
requisito falta. Los atributos son evaluados en una escala del 1 al 9.
ENTRADAS
Influencia relativa
Beneficio relativo
Penalidad relativa
Costo relativo
Riesgo relativo
Proceso
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
SALIDAS
Prioridad de los
requisitos
ENTRADAS AL MTODO
Las entradas en este mtodo corresponden a todos los requisitos de una
categora especfica. Una vez identificados estos requisitos, se usa el Modelo
(ver Figura 1) para determinar la prioridad de los requisitos en la categora.
Lista de requisitos, caractersticas o casos.
72
Influencia relativa: Es el peso de cada factor en el proyecto.

Factores:
Beneficio relativo: Valor relativo que se le da a cada requisito segn el beneficio
que con su implementacin este otorga al producto.
Penalidad Relativa: Valor relativo que se estima por la no implementacin de un
requisito.
Costo relativo: El costo relativo se refiere a la extensin de tiempo o trabajo que
los desarrolladores estiman se presentara en la implementacin de cada
requisito.
Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los
requisitos. (Riesgo de negocio, tcnico, de estimacin, etc.).
Actividades y proceso del mtodo
W-1
Propsito
Descripcin
LISTAR REQUISITOS
Listar los requisitos, caractersticas o casos que se desean
priorizar.
anlisis. Todos los tems deben estar al mismo nivel de abstraccin;
no se deben mezclar requisitos con algo tan general como las
caractersticas.
Rol
Responsabilidades
Lidera el proceso.
Roles
Arbitra conflictos.
Jefe del Proyecto

necesario.
73
Tcnica
Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas
inherentes a los propios, por ejemplo; Una norma sera; 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
Propsito
Descripcin
CATEGORIZAR REQUISITOS
Identificar atributos de los requisitos. Dividir en categoras los
requisitos, dejando en cada categora requisitos un mismo nivel de
abstraccin.
Los requisitos se distribuyen en grupos segn sus caractersticas.
Tres grupos base podran ser "aquellos sin los cuales el sistema no
funcionar", "los que son menos esenciales, pero proporcionan un
importante valor empresarial", y "los que sera agradable
tener.(nice to have).
Rol
Responsabilidades
Lidera el proceso.
Roles
Arbitra conflictos.
Jefe del Proyecto

necesario.
Tcnica
Se identifican los atributos de cada requisito, luego estos se distribuyen en grupos

segn las similitudes en los atributos y caractersticas. Se nombra cada grupo
haciendo alusin a las caractersticas de los requisitos que ah se alojan.
PGWs - 3
Propsito
BENEFICIO RELATIVO
Estimar el beneficio relativo que cada requisito provee al cliente o al
negocio.
74
Descripcin
En una escala del 1 al 9 se valora el beneficio relativo del requisito,

donde 1 indica Beneficio despreciable y 9 significa Enorme valor.
Rol
Roles
Principales
representantes
cliente
Responsabilidades
Suministra
las
Tcnica
A partir de una estimacin subjetiva, se valora el beneficio que cada requisito con
su implementacin otorga al producto.
PGWs - 4
PENALIDAD RELATIVA
Propsito
Estimar la penalidad relativa que el cliente o el negocio sufrira si el

requisito no es implementado.
Descripcin
En una escala del 1 al 9 se valora la penalidad relativa del requisito,

donde 1 indica ningun inconveniente y 9 significa sancin grave.
Rol
Roles
Principales
representantes
cliente
Responsabilidades
Suministra
las
Tcnica
A partir de una estimacin subjetiva, se valora la penalidad que cada requisito con
la omisin de su implementacin otorga al producto.
75
PGWs - 5
Propsito
Descripcin
VALOR TOTAL
Calcular el valor total de las puntuaciones en los requisitos respecto
a penalidad y beneficio. Calcular el valor porcentual de cada
requisito.
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 %).
Rol
Responsabilidades
Lidera el proceso.
Roles
Arbitra conflictos.
Jefe del Proyecto

necesario.
Tcnica
Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la
valorizacin 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)
76
Valori % =
VTi *100
n
VTi
, donde n es el nmero de requisitos.
i 1
PGWs - 6
COSTO RELATIVO
Propsito
Estimar el costo relativo que conlleva la implementacin de cada

requisito.
Descripcin
Se valora el costo que cada requisito con su implementacin otorga

al producto. Este costo se mide segn la extensin de tiempo o
trabajo que cada requisito le agregue al proyecto.
Rol
Roles
Principales
representantes de
desarrolladores
Responsabilidades
las
los Suministra
costo y el riesgo.
Tcnica
Se valora el costo relativo de la implementacin 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 documentacin que se necesitar,
etc.
Suponiendo que;
Costo Relativo para un requisito(CRi)
Se puede decir que;

n
Costo Total =
CRi , donde n es el nmero de requisitos.

i 1
77
Costo % =
CRi *100
n
CRi
i 1
PGWs - 7
RIESGO RELATIVO
Propsito
Estimar el grado relativo de riesgo que conlleva la implementacin

de cada requisito.
Descripcin
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 concentracin, mientras que 9
indica serias preocupaciones sobre la viabilidad.
Rol
Roles
Principales
representantes
cliente
Responsabilidades
las
del Suministra
costo y el riesgo.
Tcnica
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;

n
Riesgo Total =
RRi , donde n es el nmero de requisitos.

i 1
78
Riesgo % =
RRi *100
n
RRi
i 1
PGWs - 8
Propsito
Descripcin
Obtener las prioridades de cada requisito.
Una vez estimado todo los factores anteriores, se calcula la
prioridad para cada requisito.
Rol
Principales
representantes
cliente
Roles
Responsabilidades
las
del Suministra
costo y el riesgo.
Tcnica
Con la siguiente formula se calculan las prioridades de cada requisito:

prioridad
Valor %
(Costo% * inf luenciaDel cos to ) (riesgo% * inf luenciaDel Riesgo )
79
Figura 6. Modelo: Matriz de priorizacin

Influencias relativas:
Requisitos
1
Beneficio
Relativo
1
Penalidad
Relativa
1
Valor
Total
Valor %
Costo
Relativo
1
Costo %
Riesgo
Relativo
Riesgo %
Prioridad
1.
2.
3.
4.
5.
6.
7.
n.
PGWs - 9
ORDENAR
Propsito
Ordenar la lista para tener mejor visibilidad de las prioridades
Descripcin
Ordenar la lista de caractersticas en orden decreciente de

prioridad.
SALIDAS DEL MTODO

Para la salida de este mtodo se debe tener la priorizacin de los requisitos que
fueron candidatos, ordenados de mayor a menor segn su grado de prioridad.
80
9. RESULTADOS DE APLICACIN DE LAS TCNICAS
9.1 CASO CMSOFTLUTIONS

CMSOFTLUTIONS es una empresa colombiana que tiene como actividad principal
el desarrollo de software genrico. En enero de 2012 en una reunin con el
director de desarrollo de dicha empresa, se expuso un grupo de tcnicas, entre
ellas; 100P, AHP, BST, PG, Wiegers Method, esta reunin con el motivo de
validar tcnicas y posteriormente aplicar alguna en esa organizacin. Haciendo
uso de Excel se hizo un ejercicio de priorizacin ajustado con las tcnicas AHP y
Wiegers Method respectivamente, al trmino de la reunin se concluy que el
caso ms adecuado para la clase de proyectos que CMSOFTLUTIONS construye,
sera Wiegers Method por la capacidad que esta tcnica tiene para tomar
diversas formas segn el tipo de proyecto.
Para este caso se aplicar la tcnica 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 descripcin de estos requisitos.
9.1.2 Segundo, Categorizar requisitos
Tabla 21. Categoras e influencias

CATEGORAS
5
CORE
6
NTH
7
SOFTWARE
8
INSIDENTES
Beneficio
4
1
2
4
Penalidad
Costo
4
1
2
4
2
1
1
1
Riesgo
0
4
1
1
CORE, requisitos bsicos del sistema, aquellos sin los cuales el sistema no podra funcionar.
NTH, nice to have.
7
SOFTWARE, requisitos funcionales.
8
INSIDENTES, errores que pudieran presentar las aplicaciones desarrolladas
6
81
9.1.3 Tercero, Beneficio Relativo
Tabla 22. Beneficio relativo (CORE)

Requisitos
Beneficio
Relativo
1
2
3
4
5
6
7
8
9
10
11
12
13
9
9
9
9
9
9
9
9
9
9
9
9
9
Tabla 23. Beneficio relativo (INSIDENTES)

Requisitos
Beneficio
Relativo
14
15
16
17
18
19
20
4
3
7
5
9
9
8
82
Tabla 24. Beneficio relativo (NTH)

Requisitos
Beneficio
Relativo
21
22
23
7
7
5
Tabla 25. Beneficio relativo (SOFTWARE)

Requisitos
Beneficio
Relativo
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
9
9
9
9
9
9
9
9
9
9
9
9
7
4
9
9
9
9
9
9
9
8
7
4
83
9.1.4 Cuarto, Penalidad Relativa
Tabla 26. Penalidad relativa (CORE)

Requisitos
Penalidad
Relativa
1
2
3
4
5
6
7
8
9
10
11
12
13
9
9
9
9
9
9
9
9
9
9
9
9
9
Tabla 27. Penalidad relativa (INSIDENTES)

Requisitos
Penalidad
Relativa
14
15
16
17
18
19
20
4
3
7
5
9
9
8
84
Tabla 28. Penalidad relativa (NTH)

Requisitos
Penalidad
Relativa
21
22
23
7
7
5
Tabla 29. Penalidad relativa (SOFTWARE)

Requisitos
Penalidad
Relativa
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
9
9
9
9
9
9
9
9
9
9
9
9
7
4
9
9
9
9
9
9
9
8
7
4
85
9.1.5 Quinto, Valor Total
Tabla 30. Valor Total (CORE)

Influencia
relativa:
Requisitos
Beneficio
Relativo
Penalidad
Relativa
Valor Total
Valor %
1
2
3
4
5
6
7
8
9
10
11
12
13
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
Total
72
72
72
72
72
72
72
72
72
72
72
72
72
936
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
7,6923
Valor Total
Valor %
24
16
64
40
72
72
64
352
6,8182
4,5455
18,182
11,364
20,455
20,455
18,182
Tabla 31. Valor Total (INSIDENTES)

Influencia
relativa:
Requisitos
Beneficio
Relativo
4
3
7
5
9
9
8
Penalidad
Relativa
2
1
9
5
9
9
8
Total
14
15
16
17
18
19
20
86
Tabla 32. Valor Total (NTH)

Influencia
relativa:
Requisitos
Beneficio
Relativo
7
7
5
Penalidad
Relativa
4
3
5
Total
21
22
23
Valor Total
Valor %
11
10
10
31
35,484
32,258
32,258
Valor Total
Valor %
36
36
36
36
36
36
36
36
36
36
36
30
32
22
36
36
36
36
36
36
36
32
28
26
818
4,401
4,401
4,401
4,401
4,401
4,401
4,401
4,401
4,401
4,401
4,401
3,6675
3,912
2,6895
4,401
4,401
4,401
4,401
4,401
4,401
4,401
3,912
3,423
3,1785
Tabla 33. Valor Total (SOFTWARE)

Influencia
relativa:
Requisitos
Beneficio
Relativo
9
9
9
9
9
9
9
9
9
9
9
9
7
4
9
9
9
9
9
9
9
8
7
4
Penalidad
Relativa
9
9
9
9
9
9
9
9
9
9
9
6
9
7
9
9
9
9
9
9
9
8
7
9
Total
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
87
9.1.6 Sexto, Costo Relativo
Tabla 34. Costo Relativo (CORE)

Requisitos
Costo
Relativo
1
2
3
4
5
6
7
8
9
10
11
12
13
5
3
6
8
8
5
5
3
3
6
2
2
2
Costo %
8,62069
5,17241
10,3448
13,7931
13,7931
8,62069
8,62069
5,17241
5,17241
10,3448
3,44828
3,44828
3,44828
Tabla 35. Costo Relativo (INSIDENTES)

Requisitos
Costo
Relativo
14
15
16
17
18
19
20
Costo %
3
1
1
2
2
4
1
21,4286
7,14286
7,14286
14,2857
14,2857
28,5714
7,14286
Tabla 36. Costo Relativo (NTH)

Requisitos
21
22
23
Costo
Relativo
Costo %
2
9
2
15,3846
69,2308
15,3846
88
Tabla 37. Costo Relativo (SOFTWARE)

Requisitos
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Costo
Relativo
Costo %
4
2
3
3
5
5
1
3
3
7
7
4
4
4
2
2
2
2
2
2
2
2
2
2
5,33333
2,66667
4
4
6,66667
6,66667
1,33333
4
4
9,33333
9,33333
5,33333
5,33333
5,33333
2,66667
2,66667
2,66667
2,66667
2,66667
2,66667
2,66667
2,66667
2,66667
2,66667
89
9.1.7 Sptimo, Riesgo relativo
Tabla 38. Riesgo Relativo (CORE)

Requisitos
Riesgo
Relativo
1
2
3
4
5
6
7
8
9
10
11
12
13
4
3
6
4
4
4
4
3
3
3
2
2
2
Riesgo %
9,09
6,82
13,64
9,09
9,09
9,09
9,09
6,82
6,82
6,82
4,55
4,55
4,55
Tabla 39. Riesgo Relativo (INSIDENTES)

Requisitos
Riesgo
Relativo
14
15
16
17
18
19
20
8,33
8,33
8,33
16,67
16,67
33,33
8,33
Riesgo %
8,33
8,33
8,33
16,67
16,67
33,33
8,33
Tabla 40. Riesgo Relativo (NTH)

Requisitos
Riesgo
Relativo
21
22
23
2
9
2
Riesgo %
15,38
69,23
15,38
90
Tabla 41. Riesgo Relativo (SOFTWARE)

Requisitos
Riesgo
Relativo
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
3
2
2
2
4
4
1
2
2
6
6
2
4
4
2
2
2
2
2
2
2
2
2
2
Riesgo %
4,6875
3,125
3,125
3,125
6,25
6,25
1,5625
3,125
3,125
9,375
9,375
3,125
6,25
6,25
3,125
3,125
3,125
3,125
3,125
3,125
3,125
3,125
3,125
3,125
91
9.1.8 Octavo, Calculo de Prioridades
Tabla 42. Calculo de prioridad (CORE)

Influencia relativa:
Requisitos
Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor %
Costo
Relativo
Costo %
Riesgo
Relativo
72
7,6923
8,62069
72
7,6923
5,17241
72
7,6923
10,3448
72
7,6923
13,7931
72
7,6923
13,7931
72
7,6923
8,62069
72
7,6923
8,62069
72
7,6923
5,17241
72
7,6923
5,17241
10
72
7,6923
10,3448
11
72
7,6923
3,44828
12
72
7,6923
3,44828
13
72
7,6923
3,44828
Totales
936
58
Riesgo %
Prioridad
9,09
0,45
6,82
0,74
13,64
0,37
9,09
0,28
9,09
0,28
9,09
0,45
9,09
0,45
6,82
0,74
6,82
0,74
6,82
0,37
4,55
1,12
4,55
1,12
4,55
1,12
44
Tabla 43. Calculo de prioridad (INSIDENTES)

Requisitos
Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor %
Costo
Relativo
Costo %
Riesgo
Relativo
Riesgo %
Prioridad
14
24
6,8182
21,4286
8,33
8,65
15
16
4,5455
7,14286
8,33
8,97
16
64
18,182
7,14286
8,33
10,88
17
40
11,364
14,2857
16,67
17,46
18
72
20,455
14,2857
16,67
18,10
19
72
20,455
28,5714
33,33
34,05
20
Totales
64
18,182
7,14286
8,33
10,88
352
14
92
12
Tabla 44. Calculo de prioridad (NTH)

Requisitos
Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor %
Costo
Relativo
Costo %
Riesgo
Relativo
Riesgo %
Prioridad
21
11
35,484
15,3846
15,38
63,84
22
10
32,258
69,2308
69,23
277,39
23
10
32,258
15,3846
15,38
63,64
Totales
31
13
13
Tabla 45. Calculo de prioridad (SOFTWARE)

Influencia
relativa:
Requisitos
Benefici
o
Relativo
Penalida
d
Relativa
Valo
r
Total
Valor
%
Costo
Relativ
o
Costo
%
Riesgo
Relativ
o
Riesgo
%
Priorida
d
24
36
4,401
5,33333
4,69
5,51
25
36
4,401
2,66667
3,13
4,78
26
36
4,401
3,13
4,23
27
36
4,401
3,13
4,23
28
36
4,401
6,66667
6,25
6,91
29
36
4,401
6,66667
6,25
6,91
30
36
4,401
1,33333
1,56
4,86
31
36
4,401
3,13
4,23
32
36
4,401
3,13
4,23
33
36
4,401
9,33333
9,38
9,85
34
36
4,401
9,33333
9,38
9,85
35
30
3,6675
5,33333
3,13
3,81
36
32
3,912
5,33333
6,25
6,98
37
22
2,6895
5,33333
6,25
6,75
38
36
4,401
2,66667
3,13
4,78
39
36
4,401
2,66667
3,13
4,78
40
36
4,401
2,66667
3,13
4,78
41
36
4,401
2,66667
3,13
4,78
42
36
4,401
2,66667
3,13
4,78
43
36
4,401
2,66667
3,13
4,78
44
36
4,401
2,66667
3,13
4,78
45
32
3,912
2,66667
3,13
4,59
46
28
3,423
2,66667
3,13
4,41
47
26
3,1785
2,66667
3,13
4,32
Totales
818
75
93
64
9.1.9 Noveno, Ordenar
Tabla 46. Requisitos ordenados (CORE)

Requisitos
Prioridad
11
12
13
2
8
9
1
6
7
3
10
4
5
1,12
1,12
1,12
0,74
0,74
0,74
0,45
0,45
0,45
0,37
0,37
0,28
0,28
Tabla 47. Requisitos ordenados (INISIDENTES)

Requisitos
Prioridad
19
18
17
16
20
15
14
34,05
18,10
17,46
10,88
10,88
8,97
8,65
Tabla 48. Requisitos ordenados (NTH)

Requisitos
Prioridad
22
21
23
277,39
63,84
63,64
94
Tabla 49. Requisitos ordenados (SOFTWARE)

Requisitos
Prioridad
33
34
36
28
29
37
24
30
25
38
39
40
41
42
43
44
45
46
47
26
27
31
32
35
9,85
9,85
6,98
6,91
6,91
6,75
5,51
4,86
4,78
4,78
4,78
4,78
4,78
4,78
4,78
4,78
4,59
4,41
4,32
4,23
4,23
4,23
4,23
3,81
El ejercicio de aplicacin de la tcnica PGcWs ha arrojado la priorizacin para

cada una de las categoras (CORE, INSIDENTES, NTH, SOFTWARE), no se
podra hacer una comparacin contra la priorizacin de CMSOFTLUTIONS ya
que, para este proyecto, esa empresa no realiz.
El orden para el desarrollo de cada categora 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 podran presentar nuevos errores en la aplicacin.

95
9.2 CASO COOMEVA
COOMEVA es una organizacin 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 aplicacin de una tcnica de priorizacin en sus
procesos de administracin de requisitos.
En cada proyecto software, COOMEVA maneja extensas listas de requisitos, lo

cual hace necesario el agrupamiento de estos segn sus caractersticas, es decir,
definir categoras especificas en las cuales se distribuyan los diferentes requisitos
con el objetivo de priorizar las categora por separado. Por lo anterior, se infiere
que Planning Game (PG) es la tcnica ms adecuada, aunque para hacer de la
aplicacin algo ms completo se pens en unir PG con Wiegers Method
aprovechando de esta ltima su capacidad para priorizar de manera distinta en
cada proyecto (Ver anexo B).
96
10. TRABAJOS FUTUROS
Para CMSOFTLUTIONS y COOMEVA se construir un software que permita

priorizar requisitos basado en una combinacin de las tcnicas Wieger`s Method y
Planning Game (ver Anexo B), CMSOFTLUTIONS posee una herramienta propia
de administracin de requisitos a la cual se le aadir el mdulo de priorizacin.
Este trabajo ser complemento en la presentacin de un mtodo que busca

integrarse con los procesos de la Ingeniera de requisitos. La propuesta
metodolgica indicar el momento y la forma para la implementacin de prcticas
de priorizacin de requisitos en un instante del ciclo de vida del proyecto. A partir
de la investigacin aqu datada se podrn identificar las caractersticas que
enmarcan la priorizacin de requisitos, lo que ser til para entender en que fase
de la ingeniera de requisitos se puede ubicar este avance de la administracin de
requisitos. Se pretende formalizar la tarea de la priorizacin y agregarle valor a
este tipo de ingeniera, con un nuevo proceso aportar en la madurez de la
ingeniera.
97
11. CONCLUSIONES
Aunque las empresas implementen metodologas que suponen la priorizacin de

requisitos, esta priorizacin no es formal, lo que hacen las empresas es
simplemente asignar valores a cada requisito basndose en experiencias de otros
proyectos, ocasionando que la priorizacin en el caso de Numeral Assignment
Technique sea subjetiva y poco precisa.
Para elegir una tcnica de priorizacin de requisitos la tcnica misma debe hacer
manejo de dos aspectos muy importantes:
Atributos de los requisitos10
Roles11
Manejar atributos y hacer participes a los Stakeholders para la evaluacin de los

atributos, hace que la priorizacin sea precisa, objetiva y confiable. Algunos
atributos que pueden ser tiles en el proceso son; Valor relativo para el cliente,
Costo de implementacin, riesgo de implementacin, penalidad por no
implementacin.
Si se quieren obtener mejores resultados existen tcnicas formales, reconocidas y

recomendadas para priorizar, aunque se pueden usar tcnicas propias siempre y
cuando hagan caso a esos dos aspectos.
Aquellos proyectos software que posean un nmero considerable de requisitos,

deberan crear grupos en los cuales se puedan distribuir estos requisitos segn
10
Se refiere a identificar caractersticas de los requisitos y valorar segn la influencia de estas

caractersticas en el proyecto.
11
Implicar varios participantes en las diferentes actividades de la priorizacin, esto disminuye la
subjetividad.
98
sus caractersticas, lo que permitir una gestin ms fcil del proyecto y de la

priorizacin.
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, adems 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.

99
BIBLIOGRAFIA
[1] CAPERS JONES. Software Engineering best practices.

[2] Definicin Requisito, Real Academia Espaol, [en lnea]. 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/.
100
[12] Definicin Elicitar, Real Academia Espaola, [en lnea]. [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, Anlisis y Diseo de Sistema de Informacin, 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.
101
[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) 1724.
[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, Linkping University, October 1995.
[29]
Extreme
Programming
Rules.
[En
Linea].
Disponible
http://www.extremeprogramming.org/rules.html. [Consulta: 22-Marzo-2012].
en:
[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.
102
[33A] DAVIS, A. Just Enough Requirements Management: Where Software

Development Meets Marketing. New York: Dorset House, 2005 (ISBN 0-93263364-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] Marketsimo: Qu es y cmo se usa el anlisis conjoint? [En linea].
Disponible en: http://marketisimo.blogspot.com/2008/06/qu-es-y-cmo-se-usa-elanlisis-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.
103
ANEXO A. ENCUESTA PARA EL ESTUDIO DE CONTEXTO; DIAGNOSTICO

DE PROCESOS PARA PRIORIZACIN DE REQUISITOS.
UNIVERSIDAD DE SAN BUENAVENTURA CALI

PROGRAMA INGENIRIA DE SISTEMAS
DIAGNSTICO DE PROCESOS PARA PRIORIZACIN DE REQUISITOS
De manera especial se agradece su colaboracin para responder este cuestionario. Este
instrumento hace parte de una investigacin sobre la aplicacin de mtodos y tcnicas de
priorizacin de requisitos en las empresas de la industria del software, con el fin de hacer una
caracterizacin en cuanto a la investigacin mencionada. La informacin suministrada ser
tratada con la confidencialidad pertinente.
Fecha (dd/mm/aaaa)
Nombre de la Empresa
Nombre del encuestado
Cargo
e-mail
Telefono(s)
I. Informacin general de la organizacin de la empresa
1.
Marque con una X el tamao de su empresa de acuerdo a:

a. Ingenieros relacionados con las actividades de desarrollo de software
a. 1 a 3
c. 8 a 15
e. 40 ms
2.
b. 4 a 7
d. 16 a 40
Cuntos productos de software tiene su empresa?

_____________________________________
104
3.
Cul es su actividad principal?
a. Desarrollo de software genrico
b. Desarrollo de software hecho a la medida
4.
Cuntos clientes tiene actualmente la empresa? ____________
Cul(es) de los siguientes modelos ha implementado su organizacin en los ltimos 3 aos?

Seleccione todos los que aplican.
a.
b.
c.
d.
e.
f.
g.
h.
CMM-SW
CMMI
SPICE
ISO 9001
PSP/TSP
No ha implementado
No sabe
Otros, Cul?____________
II. Informacin sobre la aplicacin de mtodos de priorizacin de requisitos

6. De la cartilla adjunta identifique cul(es) mtodo(s) de priorizacin de requisitos aplica.
Marque con una X.
a. ____
b. ____
c. ____
Aplica alguno(s) en especial que no estn en la cartilla?
________________________________________
________________________________________
________________________________________
De los mtodos de la cartilla cul(es) en particular le gustara aplicar?

________________________________________
________________________________________
________________________________________
7. Conoce algn mtodo distinto a los nombrados en la cartilla que sea utilizado por alguna
compaa y que haya tenido xito?
105
a. NO
b. SI
Si su respuesta es SI, por favor descrbala a continuacin.
MUCHAS GRACIAS POR SU VALIOSA PARTICIPACIN
106
CARTILLA DE DOCUMENTACION DE LOS DIFERENTES METODOS DE PRIORIZACIN

DE REQUISITOS
Mtodo
Priorizacin por Agrupacin.
Tcnica de Asignacin de
Peso Numrico (Numeral
Assignment Technique)
[Brackett]
METODOS DE AGRUPACIN
Descripcin
Esta tcnica asigna un valor (puntuacin) a cada requisito,
adicionalmente los requisitos se dividen en 3 grupos:
Obligatorios, deseables y no esenciales [Brackett]. Los
participantes asignan a los requisitos un nmero dentro de la
escala de 1 a 5 indicando la importancia de cada uno de ellos
[Karlsson]. Los nmeros 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 clasificacin final es el promedio de las clasificaciones de todos

los participantes para cada uno de los requisitos.
Top Ten Requirement
Mtodo
AHP
Cada interesado selecciona los 10 requisitos ms importantes

desde su punto de vista. Los requisitos seleccionados por todos
los Stakeholders en su lista de 10, son tambin considerados los
ms importantes.
METODOS MIXTOS COMBINATORIOS

Descripcin
Este mtodo 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 mtodo AHP consta de 5 pasos :
Revisar los requisitos candidatos y completarlos
enteramente.
Aplicar el mtodo de comparacin por pares para evaluar
107
Hierarchy AHP
Cost Value Approach
Ordinal Cost Value Approach
Planing Game [Beck]
Wiegers Method [Wiegers].
el valor relativo de cada uno de los requisitos candidatos.

Aplicar el mtodo de comparacin por pares para evaluar
el costo relativo de los requisitos candidatos.
Calcular el valor relativo de cada requisito candidato y el
costo de su implementacin 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 clasificacin final es el promedio de las clasificaciones de todos

los participantes para cada uno de los requisitos.
Es una modificacin del AHP, en el cual solo los requisitos del
mismo nivel de jerarqua son comparados con los dems.
Est basado en el Mtodo AHP, donde todos los requerimientos
son comparados de acuerdo a su importancia y costo de
implementacin.
Los requisitos son puesto en 3 grupos de acuerdo a la importancia
del cliente y en 3 grupos de acuerdo al costo de implementacin.
Los resultados son presentados en un diagrama de dispersin de
costo-valor.
Es una tcnica utilizada por el Mtodo de desarrollo de software
Extreme Programming [Beck] y se utiliza con los clientes para
priorizar los requisitos basado en historietas. Esta es una
variacin de la tcnica de asignacin numrica 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 sera
bueno tener. "
Este mtodo se relaciona directamente con el valor de cada
requisito de un cliente [Wiegers]. La prioridad se calcula
dividiendo el valor de una obligacin por la suma de los costos y
riesgos tcnicos asociados a su aplicacin [Wiegers]. El valor de
una obligacin se considera como funcin 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
implementacin, as como la penalidad si el requisito falta. Los
108
Impact Validation
atributos son evaluados en una escala de 1 a 9.

El impacto que cada requerimiento propuesto tiene sobre el logro
en el nivel ms alto del proyecto es evaluado sobre una escala
definida, los requerimientos con mayor impacto son vistos como
los ms importantes.
METODOS DE VOTACIN
Mtodo
Descripcin
$100
Test
(Acumulative El mtodo de los 100 puntos es bsicamente un esquema de tipo
Mtehod) [Leffingwell]
votacin 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 ms importantes, el
interesado puede usarlos de la manera que l considere ms
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 podra darle los 100 puntos.
109
ANEXO B. DOCUMENTO DE ANLISIS Y DISEO DE LA APLICACIN

PGWITHWIEGER.

JHONNY GMEZ CHALACN
110
NDICE GENERAL
Pg.
INTRODUCCIN
113
1. DEFINICIN 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
111
6. DIAGRAMA DE CASOS DE USO DEL SISTEMA
130
130
130
6.3 SISTEMA
133
6.4 PANTALLAS DEL SISTEMA
134
7. MODELO DE ENTIDAD DE RELACIN
138
112
Universidad de San Buenaventura

Cali - Colombia.
Documento de anlisis y diseo de la aplicacin PGwithWieger.
INTRODUCCIN
El presente es el documento de anlisis y diseo para la construccin de un

sistema de priorizacin de requisitos que combina dos tcnicas (PG, Wiegers
Method) reconocidas por la industria y validadas en el documento base Validacin
y Aplicacin de tcnicas de priorizacin de requisitos.
Versin
1.0
Fecha
05/03/2012
2.0
30/04/2012
Autor(es)
Jhonny Gmez
Chalacn
Jhonny Gmez
Chalacn
Descripcin
Construccin del documento de anlisis y diseo
para el sistema PGwithWieger.
Modificacin y desarrollo de ltima versin del
documento de anlisis y diseo para el sistema
PGwithWieger.
113
1. DEFINICIN DEL PROBLEMA
En el Desarrollo de requisitos de software un factor determinante es la gestin de

los mismos y a su vez la priorizacin y planificacin, dicha priorizacin es un factor
de xito que determina la ptima utilizacin de los recursos tiempo, costos y factor
humano para una efectiva culminacin del producto esperado.
La evidente necesidad de contar con un mtodo que nos permita realizar una
optima priorizacin y planificacin de los requisitos de software, abre las puertas
para aportar en el proceso de ingeniera de software una propuesta metodolgica,
la cual llene el vaci que hoy no cobijan algunas metodologas estndares en
los cuales se aborda el tema de la priorizacin como una actividad del desarrollo
de requisitos de software pero no se enfatiza en el cmo?, es decir, se plantea el
hecho de priorizar, pero no se deja claro el cmo se debe priorizar, dejando de
alguna manera al libre albedro del lder de desarrollo (o del proyecto) , una
actividad tan importante como la priorizacin de los requisitos, donde en ultimas,
se utiliza ms que la tcnica su propia experticia.
114
2. ACTORES DEL SISTEMA
Gestionar usuarios y sus roles.
Gestiona requisitos y ajusta los aportes de los dems participantes en la

priorizacin.
2.2 REPRESENTANTE DE LOS DESARROLLADORES
Gestiona requisitos y ajusta los aportes de los dems participantes en la

priorizacin.
Suministra las puntuaciones para el costo y el riesgo.
Suministra las puntuaciones para el beneficio y la penalidad.
2.4 SISTEMA
Se encarga de listar automticamente los requisitos, usuarios, categoras,

roles, tipos de requisitos, proyectos.
115
3. REQUISITOS FUNCIONALES
Un requisito funcional es aquel que permite de cierta manera saber que funciones
debe realizar el software a realizar; Adems de saber los lmites 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 categoras 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 valorizacin tiene en el proyecto.
11. Priorizar requisitos por categora.
12. Listar los requisitos priorizados.
13. Listar requisitos.
116
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 categoras de requisitos
13. Modificar categoras de requisitos
14. Eliminar categoras de requisitos
15. Consultar categoras de requisitos
16. Listar Categoras 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 configuracin de influencias
30. Modificar configuracin de influencias
31. Listar requisitos priorizados.
32. Priorizar Requisitos
33. Crear Usuario
34. Modificar Usuario
117
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
118
5. CASOS DE USO EXPANDIDOS
A continuacin 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
Descripcin
Crea un nuevo requisito asociado a un proyecto
Actores
Jefe del proyecto, Representante de los desarrolladores
Fase
Anlisis
Guin
1
3
5
6
8
10
11
Actor
Ingresa el cdigo del
proyecto
Ingresa cdigo del requisito
Ingresa nombre del requisito
Ingresa el cdigo del Tipo
de requisito
Ingresa el cdigo de la
categora de requisito.
Ingresa la descripcin
Ingresa valor del beneficio
relativo.
119
Sistema
Consulta si existe el proyecto
Consulta si el requisito existe.
Consulta si existe el tipo de

requisito.
Consulta si existe la categora.
12
Valida que sea numrico, mayor a

cero y se encuentre en un rango de
1 a 10.
13
Ingresa valor del Costo

relativo.
14
15
Ingresa valor de la
penalidad relativa.
16
17
Ingresa valor del Riesgo

relativo.
18
19
Excepciones
1. Proyecto no existe
Nombre
Paso 2

1 a 10.
1 a 10.
1 a 10.
Almacena informacin del
requisito.
Mensaje
1. Si no existe un proyecto con el cdigo
digitado. Se despliega el siguiente
mensaje No existe un proyecto con el
cdigo 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
Paso 4
Mensaje
1. Se despliega la informacin del
requisito.
3. Tipo de requisito no existe.

Nombre
Mensaje
Paso 7
1. Si no existe un tipo de requisito con el
cdigo digitado. Se despliega el
siguiente mensaje No existe un tipo
de requisito con el cdigo xxxxx.
crear un nuevo tipo de requisito?
caso de uso CREAR TIPO DE
REQUISITO.
4. Categora no existe.
120
Nombre
Paso 9
Mensaje
1. Si no existe una categora con el
siguiente mensaje No existe una
categora con el cdigo xxxxx.
crear una nueva categora?
caso de uso CREARCATEGORIA.
5. Valor no numrico, no mayor a cero.

Nombre
Mensaje
Paso 12,14,16,18
1. Si el valor ingresado no es numrico,
menor o igual a cero. Se despliega el
mensaje El valor debe ser numrico
mayor a cero.
2. Vuelve al paso 11,13,15,17
respectivamente
6. Valor fuera del rango.
Nombre
Paso 12,14,16,18
Mensaje
1. Si el valor ingresado se encuentra
fuera del rango. Se despliega el
mensaje El valor debe tener valores
entre 1 - 10.
respectivamente
Casos de uso
relacionados
Documentos
Relacionados
Requerimiento
Fuente
Autor
Revisado por
Fecha
Creacin
Fecha
de
Ultima
Modificacin
Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de

requisito, consultar categora, Crear Categora, Consultar requisito.
Especificacin de requisitos.
Gestionar requisitos
Jhonny Gmez Chalacn
Marzo 06 de 2012
121
No. 2
CU_08_MODIFICAR_REQUISITO
Nombre
Modificar requisito
Descripcin
Modifica un requisito asociado a un proyecto
Actores
Fase
Anlisis
Guin
1
3
5
6
8
10
Actor
proyecto
Ingresa nombre del requisito
Ingresa el cdigo del Tipo
de requisito
Ingresa el cdigo de la
Ingresa la descripcin
Sistema
Consulta si existe el tipo de

requisito.
Consulta si existe la categora.
11
Ingresa valor del beneficio

relativo.
12
13
Ingresa valor del Costo

relativo.
14
15
Ingresa valor de la
penalidad relativa.
16
17
Ingresa valor del Riesgo

relativo.
18
19
122

cero y se encuentre en un rango
de 1 a 10.
de 1 a 10.
de 1 a 10.
de 1 a 10.
Actualiza informacin del requisito.
Excepciones
Nombre
Paso 2
Mensaje
cdigo xxxxx.
3. si la respuesta es afirmativa; Llama al
2 El requisito no existe.
Nombre
Paso 4
Mensaje
1. No se despliega ningn tipo de
informacin.

Nombre
Mensaje
Paso 7
siguiente mensaje No existe un tipo
de requisito con el cdigo xxxxx.
crear un nuevo tipo de requisito?
3. si la respuesta es afirmativa; Llama al
REQUISITO.
Nombre
Paso 9
Mensaje
1. Si no existe una categora con el
siguiente mensaje No existe una
categora con el cdigo xxxxx.
crear una nueva categora?
123
5. Valor no numrico, no mayor a cero.

Nombre
Mensaje
Paso 12,14,16,18
1. Si el valor ingresado no es numrico,
menor o igual a cero. Se despliega el
mensaje El valor debe ser numrico
mayor a cero.
respectivamente
6. Valor fuera del rango.
Nombre
Paso 12,14,16,18
Mensaje
1. Si el valor ingresado se encuentra
fuera del rango. Se despliega el
mensaje El valor debe tener valores
entre 1 - 10.
respectivamente
Casos de uso
relacionados
Documentos
Relacionados
Requerimiento
Fuente
Autor
Revisado por
Fecha
Creacin
Fecha
de
Ultima
Modificacin
Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de

requisito, consultar categora, Crear Categora, Consultar requisito.
No. 3
CU_9_ELIMINAR_REQUISITO
Nombre
Eliminar requisito
Descripcin
Elimina un requisito asociado a un proyecto
Actores
Jhonny Gmez Chalacn
Marzo 06 de 2012
124
Fase
Anlisis
Guin
1
3
Actor
2
proyecto
Ingresa cdigo del requisito 4
5
6
Excepciones
Nombre
Paso 2
Sistema
Borra informacin del requisito.
Actualiza informacin.
Mensaje
cdigo xxxxx.
2. El requisito no existe.
Nombre
Paso 4
Mensaje
informacin.
Casos de uso
relacionados
Documentos
Relacionados
Requerimiento
Fuente
Autor
Revisado por
Fecha
Creacin
Fecha
de
Ultima
Modificacin
Consultar proyecto, Crear Proyecto, Consultar requisito.

Jhonny Gmez Chalacn
Marzo 06 de 2012
125
No. 4
CU_10_CONSULTAR_REQUISITO
Nombre
Eliminar requisito
Descripcin
Consulta un requisito asociado a un proyecto
Actores
Fase
Anlisis
Guin
1
3
Excepciones
Actor
proyecto
Nombre
Paso 2
2
4
Sistema
Despliega la informacin del
requisito.
Mensaje
cdigo xxxxx.
2. El requisito no existe.
Nombre
Paso 4
Mensaje
informacin.
Casos de uso
relacionados
Documentos
Relacionados
Requerimiento
Fuente
Autor
Consultar proyecto, Crear Proyecto.

Jhonny Gmez Chalacn
126
Revisado por
Fecha
Marzo 06 de 2012
Creacin
Fecha
de
Ultima
Modificacin
No. 5
CU_32_PRIORIZAR_REQUISITOS
Nombre
Priorizar requisitos
Descripcin
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
Fase
Anlisis
Guin
Actor
1. Ingresa el cdigo del
proyecto
3. Ingresa el cdigo del Tipo
de requisito
5. Ingresa el cdigo de la
7. Consultar requisitos
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
127
Sistema
2. Consulta si existe el proyecto
4. Consulta si existe el tipo de
requisito.
6. Consulta si existe la categora.
multiplicaciones en el
paso 14 y 15.
17. Actualizar informacin
18. Listar Requisitos priorizados.
Excepciones
Nombre
Paso.
Mensaje
2
cdigo xxxxx.
6. Se despliega el mensaje Desea crear
un nuevo proyecto?

Nombre
Mensaje
Paso
4
siguiente mensaje No existe un tipo de
requisito con el cdigo xxxxx.
un nuevo tipo de requisito?
REQUISITO.
Nombre
Paso
Mensaje
6
5. Si no existe una categora con el cdigo
mensaje No existe una categora con
el cdigo xxxxx.
una nueva categora?
128
Casos de uso 1. Consultar requisitos

relacionados
8. Consultar Proyectos
9. Consultar Categoras
10. Consultar Tipos de requisito
Documentos
Especificacin de requerimientos.
Relacionados
Requerimiento
Priorizar requisitos
Fuente
Autor
Jhonny Gmez Chalacn
Revisado por
Fecha Creacin Marzo 06 de 2012
Fecha de Ultima
Modificacin
129
6. DIAGRAMA DE CASOS DE USO DEL SISTEMA
130
131
132
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
133
6.4 PANTALLAS DEL SISTEMA
Gestin de categoras
Priorizacin
134
Gestin de proyectos
135
Gestin de requisitos
136
Gestin de requisitos
137
7. MODELO DE ENTIDAD DE RELACIN
138

Validación Aplicación Técnicas Gómez 2012

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Validación Aplicación Técnicas Gómez 2012

Загружено:

Авторское право:

Доступные форматы

VALIDACIN Y APLICACIN DE TCNICAS

JHONNY GMEZ CHALACN

UNIVERSIDAD DE SAN BUENAVENTURA

VALIDACIN Y APLICACIN DE TCNICAS

JHONNY GMEZ CHALACN

Trabajo de Grado presentado como requisito para optar

UNIVERSIDAD DE SAN BUENAVENTURA

Jhonny Gmez Chalacn

Gracias a mi familia por el apoyo, la exigencia y la buena energa.

Jhonny Gmez Chalacn

RESUMEN DEL PROYECTO

1. PLANTEAMIENTO DEL PROBLEMA

2. OBJETIVOS DEL PROYECTO

2.1 OBJETIVO GENERAL

2.2 OBJETIVOS ESPECFICOS

3.1 BUSQUEDA EN ARBOL BINARIO (BINARY SEARCH TREE (BST))

3.2 TCNICA DE ASIGNACIN DE PESO NUMRICO (NUMERAL

3.3 JUEGO DE LA PLANIFICACIN (PLANNING GAME)

3.4 MTODO DE LOS 100 PUNTOS (100-POINT METHOD)

3.5 TEORA W (THEORY-W)

3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE)

3.7 WIEGERS' METHOD

3.10 ANALYTIC HIERARCHY PROCESS (AHP)

3.11 ANLISIS KANO (KANO ANALYSIS)

4. DESARROLLO METODOLGICO DEL PROYECTO

4.1. RECOPILACIN Y DOCUMENTACIN DE LAS TCNICAS DE

4.1.1 Marco descriptivo de la tcnica

4.1.2 Caracterizacin detallada de las Tcnicas

4.1.3 Actividades del mtodo

5. ANLISIS DE APROPIACIN Y USO DE LAS TCNICAS POR LA

5.1 FICHA TCNICA DE LA ENCUESTA

5.2 RESULTADOS DE LA EVALUACIN

5.2.1 Seccin 1: Informacin general.

7.1 RESULTADOS DE LA EVALUACIN

8. PROPUESTA; NUEVA TCNICA

9. RESULTADOS DE APLICACIN DE LAS TCNICAS

9.1 CASO CMSOFTLUTIONS

9.1.1 Primero, Listar Requisitos.

9.1.2 Segundo, Categorizar requisitos

9.1.3 Tercero, Beneficio Relativo

9.1.4 Cuarto, Penalidad Relativa

9.1.5 Quinto, Valor Total

9.1.6 Sexto, Costo Relativo

9.1.7 Sptimo, Riesgo relativo

9.1.8 Octavo, Calculo de Prioridades

9.1.9 Noveno, Ordenar

9.2 CASO COOMEVA

10. TRABAJOS FUTUROS

TABLA 1. TCNICAS DE PRIORIZACIN

TABLA 2. EJEMPLO DE UNA MATRIZ DE COMPARACIN POR PARES

TABLA 3. INTERPRETACION DE LOS VALORES EN LA MATRIZ

TABLA 4. INTERPRETACIN DE LOS COSTOS EN LA MATRIZ

TABLA 5. MATRIZ NORMALIZADA

TABLA 6. COLUMNA DE PUNTUACIN.

TABLA 9. SEGN EL NMERO DE REQUISITOS, PARA ESTE EJEMPLO

TABLA 10. FICHA TCNICA DEL ESTUDIO ADELANTADO

TABLA 11. INGENIEROS DE SISTEMAS EN LAS EMPRESAS

TABLA 12. NMERO DE PRODUCTOS SOFTWARE POR EMPRESA.

TABLA 14. ACTIVIDADES PRINCIPALES POR EMPRESA

TABLA 15. MODELOS IMPLEMENTADOS POR LAS EMPRESAS

TABLA 16. APLICACIN DE MTODOS DE PRIORIZACIN DE

TABLA 17. APLICACIN DE MTODOS DE PRIORIZACIN DE

TABLA 18. APLICACIN DE MTODOS DE PRIORIZACIN DE

TABLA 19. APLICACIN DE MTODOS DE PRIORIZACIN DE