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

VALIDACIÓN Y APLICACIÓN DE TÉCNICAS

DE PRIORIZACIÓN DE REQUISITOS

JHONNY GÓMEZ CHALACÁN

UNIVERSIDAD DE SAN BUENAVENTURA

CALI- COLOMBIA

FACULTAD DE INGENIERÍA

PROGRAMA INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI,

2012




Trabajo de Grado presentado como requisito para optar

al título de INGENIERO DE SISTEMAS

Director

Ingeniero Luis Merchán Paredes

UNIVERSIDAD DE SAN BUENAVENTURA

CALI - COLOMBIA


PROGRAMA INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI

2012

3

DEDICATORIA

A la ingeniería de requisitos

Jhonny Gómez Chalacán

4

AGRADECIMIENTOS

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

Jhonny Gómez Chalacán

5

CONTENIDO

Pág.

GLOSARIO 13

RESUMEN 13

RESUMEN DEL PROYECTO 15

INTRODUCCIÓN 16

1. PLANTEAMIENTO DEL PROBLEMA 18

2. OBJETIVOS DEL PROYECTO 20

2.1 OBJETIVO GENERAL 20

2.2 OBJETIVOS ESPECÍFICOS 20

3. REFERENTE TEÓRICO 21

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

3.2 TÉCNICA DE ASIGNACIÓN DE PESO NUMÉRICO (NUMERAL

ASSIGNMENT TECHNIQUE) 27

3.3 JUEGO DE LA PLANIFICACIÓN (PLANNING GAME) 27

3.4 MÉTODO DE LOS 100 PUNTOS (100-POINT METHOD) 27

6

3.5 TEORÍA W (THEORY-W) 28

3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE) 29

3.7 WIEGERS' METHOD 29

3.8 FRAMEWORK DE PRIORIZACIÓN DE REQUISITOS

(REQUIREMENTS PRIORITIZATION FRAMEWORK) 29

3.9 CONJOINT 30

3.10 ANALYTIC HIERARCHY PROCESS (AHP) 31

3.11 ANÁLISIS KANO (KANO ANALYSIS) 31

4. DESARROLLO METODOLÓGICO DEL PROYECTO 33

4.1. RECOPILACIÓN Y DOCUMENTACIÓN DE LAS TÉCNICAS DE

PRIORIZACIÓN 33

4.1.1 Marco descriptivo de la técnica 34

4.1.2 Caracterización detallada de las Técnicas 35

4.1.3 Actividades del método 36

5. ANÁLISIS DE APROPIACIÓN Y USO DE LAS TÉCNICAS POR LA

INDUSTRIA DEL SOFTWARE. 58

5.1 FICHA TÉCNICA DE LA ENCUESTA 58

5.2 RESULTADOS DE LA EVALUACIÓN 59

5.2.1 Sección 1: Información general. 60

5.2.1.1 Pregunta 1. 60

7

5.2.1.2 Pregunta 2. 61

5.2.1.3 Pregunta 3. 63

5.2.1.4 Pregunta 4. 64

5.2.1.5 Pregunta 5. 65

6. CONCLUSIONES DE LA EVALUACIÓN 67

7. ANÁLISIS DE HERRAMIENTAS DE ADMINISTRACIÓN DE

REQUISITOS 69

7.1 RESULTADOS DE LA EVALUACIÓN 69

7.1.1 Pregunta 1. 69

7.1.2 Pregunta 2. 70

8. PROPUESTA; NUEVA TÉCNICA 71

9. RESULTADOS DE APLICACIÓN DE LAS TÉCNICAS 81

9.1 CASO CMSOFTLUTIONS 81

9.1.1 Primero, Listar Requisitos. 81

9.1.2 Segundo, Categorizar requisitos 81

9.1.3 Tercero, Beneficio Relativo 82

9.1.4 Cuarto, Penalidad Relativa 84

9.1.5 Quinto, Valor Total 86

8

9.1.6 Sexto, Costo Relativo 88

9.1.7 Séptimo, Riesgo relativo 90

9.1.8 Octavo, Calculo de Prioridades 92

9.1.9 Noveno, Ordenar 94

9.2 CASO COOMEVA 96

10. TRABAJOS FUTUROS 97

11. CONCLUSIONES 98

BIBLIOGRAFIA 100

ANEXOS 104

9

LISTA DE TABLAS

Pág.

TABLA 1. TÉCNICAS DE PRIORIZACIÓN 33

TABLA 2. EJEMPLO DE UNA MATRIZ DE COMPARACIÓN POR PARES

CON 8 REQUISITOS 37

TABLA 3. INTERPRETACION DE LOS VALORES EN LA MATRIZ 38

TABLA 4. INTERPRETACIÓN DE LOS COSTOS EN LA MATRIZ 38

TABLA 5. MATRIZ NORMALIZADA 39

TABLA 6. COLUMNA DE PUNTUACIÓN. 40

TABLA 7. RANDOM INDEX VALUES - ÍNDICE DE VALORES

ALEATORIOS 42

TABLA 8. RATIO 42

TABLA 9. SEGÚN EL NÚMERO DE REQUISITOS, PARA ESTE EJEMPLO

EL INDICE ALEATORIO(RI) ES 1,41 42

TABLA 10. FICHA TÉCNICA DEL ESTUDIO ADELANTADO 59

TABLA 11. INGENIEROS DE SISTEMAS EN LAS EMPRESAS 60

TABLA 12. NÚMERO DE PRODUCTOS SOFTWARE POR EMPRESA. 61

TABLA 13. EQUIVALENCIAS DE TAMAÑO CON RANGOS EN

ENCUESTA. 63

TABLA 14. ACTIVIDADES PRINCIPALES POR EMPRESA 63

TABLA 15. MODELOS IMPLEMENTADOS POR LAS EMPRESAS 64

10

TABLA 16. APLICACIÓN DE MÉTODOS DE PRIORIZACIÓN DE

REQUISITOS EN LAS EMPRESAS. 65


REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE

HECHO A LA MEDIDA) . 66


REQUISITOS EN LAS EMPRESAS (DESARROLLO DE SOFTWARE

GENÉRICO). 66


REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE

HECHO A LA MEDIDA Y GENÉRICO). 66

TABLA 20. HERRAMIENTAS DE ADMINISTRACIONES 70

TABLA 21. CATEGORÍAS E INFLUENCIAS 81

TABLA 22. BENEFICIO RELATIVO (CORE) 82

TABLA 23. BENEFICIO RELATIVO (INSIDENTES) 82

TABLA 24. BENEFICIO RELATIVO (NTH) 83

TABLA 25. BENEFICIO RELATIVO (SOFTWARE) 83

TABLA 26. PENALIDAD RELATIVA (CORE) 84

TABLA 27. PENALIDAD RELATIVA (INSIDENTES) 84

TABLA 28. PENALIDAD RELATIVA (NTH) 85

TABLA 29. PENALIDAD RELATIVA (SOFTWARE) 85

TABLA 30. VALOR TOTAL (CORE) 86

TABLA 31. VALOR TOTAL (INSIDENTES) 86

11

TABLA 32. VALOR TOTAL (NTH) 87

TABLA 33. VALOR TOTAL (SOFTWARE) 87

TABLA 34. COSTO RELATIVO (CORE) 88

TABLA 35. COSTO RELATIVO (INSIDENTES) 88

TABLA 36. COSTO RELATIVO (NTH) 88

TABLA 37. COSTO RELATIVO (SOFTWARE) 89

TABLA 38. RIESGO RELATIVO (CORE) 90

TABLA 39. RIESGO RELATIVO (INSIDENTES) 90

TABLA 40. RIESGO RELATIVO (NTH) 90

TABLA 41. RIESGO RELATIVO (SOFTWARE) 91

TABLA 42. CALCULO DE PRIORIDAD (CORE) 92

TABLA 43. CALCULO DE PRIORIDAD (INSIDENTES) 92

TABLA 44. CALCULO DE PRIORIDAD (NTH) 93

TABLA 45. CALCULO DE PRIORIDAD (SOFTWARE) 93

TABLA 46. REQUISITOS ORDENADOS (CORE) 94

TABLA 47. REQUISITOS ORDENADOS (INISIDENTES) 94

TABLA 48. REQUISITOS ORDENADOS (NTH) 94

TABLA 49. REQUISITOS ORDENADOS (SOFTWARE) 95

12

LISTA DE FIGURAS

Pág.

FIGURA 1. MODELO: MATRIZ DE PRIORIZACIÓN 56

FIGURA 2. INGENIEROS DE SISTEMAS EN LAS EMPRESAS 61

FIGURA 3. RELACIÓN TAMAÑO DE LA EMPRESA VS NÚMERO DE

PRODUCTOS. 62

FIGURA 4. ACTIVIDADES DE LAS EMPRESAS 64

FIGURA 5. CONCLUSIONES DE LA EVALUACIÓN 67

FIGURA 6. MODELO: MATRIZ DE PRIORIZACIÓN 80

13

GLOSARIO

Término Descripción

IEEE Institute of Electrical and Electronics Engineers

CMMI Capability Maturity Model Integration

RAE Real academia de la lengua española

Stakeholder “Quienes pueden afectar o son afectados por las actividades de una empresa” R.

E. Freeman en su obra: “Strategic Management: A Stakeholder Approach”

RAD Rapid Application Development

SW-CMM Capability Maturity Model for Software

SP Specific Practices

SG Specific Goal

CRUD Por sus siglas en ingles Create, Read, Update, Delete

http://es.wikipedia.org/w/index.php?title=R._E._Freeman&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=R._E._Freeman&action=edit&redlink=1

14

RESUMEN

El tema de la ingeniería de requisitos es un subconjunto relativamente nuevo de la

ingeniería de software. La ingeniería de requisitos intenta agregar rigor a la

reunión y análisis de requisitos mediante el uso de métodos formales de

elicitación, análisis, y también en la creación de modelos de aplicación y validación

de los requisitos [1].

Por medio del trabajo exploratorio se pudo identificar un grupo de técnicas muy

utilizadas en la industria del software para priorización de requisitos, con la

investigación se validaron esas técnicas y su uso, luego se realizó un estudio a las

empresas Colombianas, buscando resolver cuál técnica es más precisa para los

proyectos que se presentan en el contexto actual de la industria del software,

como conclusión se aprovechan algunas técnicas dándoles otra forma y

aplicándolas en una nueva, esto según las necesidades de las diversas empresas

del país.

ABSTRACT

The topic of requirements engineering is a fairly new subset of software

engineering. Requirements engineering attempts to add rigor to requirements

gathering and analysis by using formal methods of elicitation, analysis, and also by

creating models of the application and validating the requirements[1].

Through the exploration it could identify a group of widely used techniques in the

software industry for prioritization of requirements, with research techniques and

their use were validated, then conducted a study to Colombian companies, seeking

to resolve which technique is most accurate for the projects presented in the

context of the industry, in conclusion exploit some techniques and

applying them otherwise in a new, this according to the needs of the

various companies.

15

RESUMEN DEL PROYECTO

Actualmente las empresas que desarrollan software comprenden que en su

proceso de administración de requisitos deben priorizar, lo que no saben aún, es

cómo hacerlo, en su mayoría las empresas usan la experiencia del encargado de

la priorización como factor determinante de este proceso; por eso se realiza una

exploración identificando las diferentes técnicas que nos ayudan a saber el cómo

priorizar y no caer más en la metodología de lo informal.

A partir de una caracterización1, se identifica un grupo de técnicas factibles para la

priorización de requisitos, de ahí se seleccionan algunas técnicas candidatas que

puedan aportar en la industria del software para dicha priorización, luego se

validan cuales de estas son reconocidas como formales, por último se propone y

aplica una técnica que sea efectiva para administrar los requisitos que se

demandan actualmente en los proyectos software.

1 Determinar los atributos peculiares de alguien o de algo, de modo que claramente se distinga de

los demás.

16

INTRODUCCIÓN

La priorización de requisitos2 [3][4][5] es una actividad muy importante en el

desarrollo de productos cuando las expectativas del usuario y del producto son

altas, existe limitaciones de tiempo, los recursos son limitados y el producto debe

cumplir las funciones más esenciales lo antes posible [6].

En el desarrollo de productos software, la totalidad de los requisitos no pueden ser

implementados por limitaciones de los recursos (tiempo y costos), esto nos hace

decidir qué requisitos deben ser implementados y de ahí la necesidad de priorizar.

De acuerdo a Wiegers [3] la información para la priorización de los requisitos es

extremadamente necesaria, no tanto para ignorar los requisitos menos

importantes o desarrollar los más importantes, sino que ayuda al administrador del

proyecto a resolver conflictos entre los requisitos, planear las entregas, etc. Esto

hace que la actividad de priorización de requisitos se convierta en una actividad

desafiante, compleja [7][8] y sea un factor de éxito o fracaso de los proyectos.

En la literatura se pueden encontrar distintas técnicas para la priorización de

requisitos, estas técnicas pueden clasificarse dependiendo del enfoque en tres

categorías: a) Agrupación de prioridades, b) Técnicas que combinan aspectos que

afectan las prioridades y c) Técnicas de votación e inversión, pero cada técnica

tiene sus ventajas y desventajas.

De igual manera los distintos enfoques y técnicas no especifican en qué etapa del

desarrollo del proyecto deben o pueden ser usados, se dejan a disposición de los

lideres de desarrollo o del proyecto para su utilización. El no tener una claridad

acerca del uso de la técnica y más aún en que etapa usarla, hace más ambiguo y

confuso el uso de una u otra técnica en el proceso de desarrollo de software,

inclinando a los líderes de proyectos a utilizar la regla del costo-beneficio [9],

donde el líder de desarrollo o del proyecto conjuga las restricciones de los

recursos del proyecto buscando el mayor beneficio al menor costo [10].

2 Requisito, Circunstancia o condición necesaria para algo [2].

17

El desarrollo de una propuesta que permita la implementación y que responda al

¿qué… y el ¿cómo…hacer para poder realizar una planificación del desarrollo de

los requisitos de software, basándose en una optimización de la priorización de los

requisitos, aporta al proceso de desarrollo de software para entregar productos

que cuentan con limitaciones de tiempo y de recursos, y ayuda a que se cumpla

con las necesidades del producto de una mejor manera.

18

1. PLANTEAMIENTO DEL PROBLEMA

El proceso que se sigue para construir, entregar y evolucionar el software, desde

la concepción, hasta la entrega y mantenimiento del mismo, tiene una etapa

fundamental, que en el modelo CMMI [11] es llamada en el área de procesos

como “Desarrollo de Requisitos”3 [11]. Esta etapa del proceso de desarrollo de

software trata de determinar desde un principio con total claridad lo que se desea

construir con el nivel de detalle requerido, de tal manera que el equipo de

desarrollo en las etapas subsiguientes del proceso, pueda fabricar con efectividad

las funcionalidades que implementan los requisitos de la solución software.

Esta problemática no es ajena en los proyectos de fabricación de software [6],

considerando que en lo absoluto se generan costosos re-procesos de implantación

e incluso de la misma elicitación [12] de los requisitos; es en este proceso donde

se hace muy importante poder trabajar sobre métodos más efectivos que permita

disminuir esta brecha de incertidumbre (requisitos ambiguos o mal entendidos) y

de re-procesos al momento de la fabricación de software, trayendo como

consecuencia favorable un producto con menos inconformidades de fabricación.

Contar con métodos colaborativos que nos ayuden a entender los requisitos,

ayuda también a que esa brecha de inconformidades sea más pequeña [13].

En el desarrollo de requisitos de software un factor determinante es la gestión de

los mismos y a su vez la priorización y planificación [6], dicha priorización es un

factor de éxito que determina la óptima utilización de los recursos tiempo, costos y

factor humano para una efectiva culminación del producto esperado.

La evidente necesidad de contar con un método que permita realizar una optima

priorización y planificación de los requisitos de software, abre las puertas para

aportar en el proceso de ingeniería de software una propuesta metodológica, la

cual llene el vació que hoy no cobijan algunas metodologías ó estándares [11] en

los cuales se aborda el tema de la priorización como una actividad del desarrollo

de requisitos de software pero no se enfatiza en el ¿cómo?, es decir, se plantea el

3 Es en esta área de desarrollo donde se identifican, entienden, documentan y planifican los

requisitos

19

hecho de priorizar, pero no se deja claro el cómo se debe priorizar, dejando de

alguna manera al libre albedrío del líder de desarrollo (o del proyecto) , una

actividad tan importante como la priorización y planificación de los requisitos,

donde en ultimas, se utiliza más que la técnica su propia experticia.

20

2. OBJETIVOS DEL PROYECTO

2.1 OBJETIVO GENERAL

Validar técnicas de priorización de requisitos y proponer una técnica que haga

parte del proceso de desarrollo de requisitos que permita optimizar la priorización

de estos.

2.2 OBJETIVOS ESPECÍFICOS

Caracterización de las diferentes técnicas de priorización de requisitos de

software.

Identificar factores en los requisitos que determinan y permiten su priorización.

Validar y aplicar la técnica propuesta en empresas reales.

21

3. REFERENTE TEÓRICO

Existen dos tendencia básicas en el modelo de ciclo de vida de desarrollo de

software: el secuencial o modelo en cascada [14], y el modelo de desarrollo

iterativo incremental. La diferencia entre estos dos modelos es que en el desarrollo

secuencial, el desarrollo se realiza por una serie de etapas que se siguen una de

otra relacionándose entre sí y en el iterativo incremental se va desarrollando en

pequeños incrementos y en varias iteraciones posteriores.

Sommerville [15] establece las etapas de desarrollo de software secuencial. Estas

etapas son la definición de requisitos, diseño del sistema y del software,

implementación, pruebas unitarias, integración y pruebas del sistema, operación y

mantenimiento.

Según Schach [16], el desarrollo de software iterativo consiste en un conjunto de

iteraciones seguidas unas tras otras. Las fases de cada interacción incluyen la

especificación, diseño, implementación y pruebas, las cuales pueden llegar a

sobreponerse en algunos casos.

Las ventajas y desventajas de ambos modelos han sido discutidas en todos estos

años, sin embargo lo que sí se puede ganar es una visión global de estos

enfoques entendiendo las diferentes actividades las cuales son comunes en

ambos. Un aspecto importante es que independiente del modelo que se utilice

para el ciclo de vida del desarrollo de software, la definición y selección de los

requisitos del software es necesario por cualquiera de los dos caminos que se

tome.

Según James Senn [17], existen tres estrategias para el desarrollo de sistemas: a)

El método clásico del ciclo de vida de desarrollo de sistemas, b) El método de

desarrollo por análisis estructurado y c) El método de construcción de prototipos

de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de

los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas

de manera adecuada.

22

Consecuente a Schach, se concluye que el ciclo de vida de un sistema de

información es un enfoque por fases que sostiene que los sistemas son

desarrollados de mejor manera mediante el uso de un ciclo especifico de

actividades del analista, diseñador, desarrollador y del usuario.

Como complemento a lo que James Senn afirma, se puede decir que la ingeniería

de requisitos es un área de investigación que procura atacar un punto fundamental

en el proceso de desarrollo de software [18], definiendo lo que se quiere producir.

Jackson [19] ratifica que la ingeniería de requisitos se ubica en el punto de

encuentro entre lo informal y lo formal del desarrollo de software. La ingeniería de

requisitos debe cubrir todas las actividades relacionadas con la elicitación,

especificación y mantenimiento [4].

Wiegers [3] define un requisito como una propiedad que un producto debe tener

para ofrecer valor a un usuario. Sin embargo, "requisito" no es un término sin

ambigüedades, ya que diferentes autores lo definen de manera diferente y hacen

hincapié en diferentes puntos de vista en sus definiciones. Por ejemplo, el

estándar IEEE define el término [20] como:

Condición, capacidad ó necesidad de un usuario para resolver un problema ó

alcanzar un objetivo.

Condición ó capacidad que debe tener un sistema para satisfacer un contrato,

norma, especificación o de otro tipo impuesta por un documento formal.

Una representación documentada de una condición o capacidad como en las

dos primeras.

Davis [21] complementa la definición de la IEEE, mediante la definición de un

requisito como "una necesidad del usuario ó una característica necesaria, función

o un atributo de un sistema que puede ser detectado desde una posición externa a

ese sistema”. Kotonya y Sommerville [4] afirman que el requisitos define lo que el

sistema debe hacer y las circunstancias que se requieren para funcionar.

http://www.monografias.com/trabajos16/proyecto-inversion/proyecto-inversion.shtml#CICLO

http://www.monografias.com/trabajos11/norma/norma.shtml

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

23

Es así como un aspecto fundamental del análisis de sistemas es comprender

todas las facetas, partes, componentes, etc., importantes del problema que se

encuentra bajo estudio. Los analistas, al trabajar con los usuarios interesados,

deben estudiar los procesos o problemas para dar respuesta a las siguientes

preguntas claves: ¿Qué es lo que hace?, ¿Cómo se hace?, ¿Con que frecuencia

se presenta?, ¿Qué tan grande es el volumen de transacciones o decisiones? ,

¿Cuál es el grado de eficiencia con el que se efectúan las tareas? , ¿Existe algún

problema?, ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

El proceso de ingeniería de requisitos se puede definir como un conjunto

estructurado de actividades que se siguen para calcular, validar y mantener un

documento de requisitos del sistema [4]. Según Kotonya y Sommerville [4], la

secuencia básica del proceso de ingeniería de requisitos incluye la obtención de

requisitos, análisis de requisitos y negociación de los mismos, la documentación y

validación de los requisitos. Sin embargo, no existe un proceso único en la

ingeniería de requisitos que esté adecuado para todas las organizaciones.

Además, la descripción del proceso secuencial de por sí no es suficiente .La

ingeniería de requisitos hace hincapié en un enfoque de colaboración para el

desarrollo de los productos [13], con la participación de múltiples perspectivas de

los interesados que participan en un proyecto [3].

La ingeniería de requisitos es generalmente vista como la primera fase del ciclo

desarrollo del producto. Por ejemplo, Jackson [19] sostiene que la ingeniería de

requisitos y el diseño son actividades separadas, debido a que los requisitos son

en su mayoría relacionados con el problema a resolver y el diseño tiene que ver

con la solución al problema. Sin embargo, Kotonya y Sommerville [4], por ejemplo,

sostienen que estas dos son actividades interrelacionadas.

Sin embargo la ingeniería de requisitos suele ser vista como una actividad al inicio

del ciclo vida de desarrollo de software. La ingeniería de requisitos es necesaria a

través del ciclo de vida del desarrollo incluyendo las iteraciones que sean

necesarias cuando se utiliza un enfoque incremental iterativo.

Si bien es cierto CMMI es un referente importante para los procesos de desarrollo

de software por ende es importante anotar que CMMI también trata algunas

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

http://www.monografias.com/trabajos5/volfi/volfi.shtml

http://www.monografias.com/trabajos11/veref/veref.shtml

24

prácticas especificas donde se plantean actividades dentro del ciclo de desarrollo

del software donde se gestionan los requisitos pero no define el cómo se deben

priorizar los requisitos. [22]

El nivel 2 requiere que hayamos considerados las siguientes cosas:

Gestión de requisitos,

Plan de Proyecto,

Monitorización y control del proyecto,

Gestión de acuerdos con proveedores,

Medida y análisis,

Medidas de calidad en el proceso y producto,

Gestión de la configuración

A continuación podemos ver las actividades detalladas, definidas por CMMI a

realizar en el primer punto del nivel de madurez 2 en la gestión de requisitos.

SG Gestionar Requisitos (SG – Meta especifica)

SP 1.1 Obtener y comprender requisitos (SP - Práctica Especifica)

SP 1.2 Obtener la aprobación de los requisitos.

SP 1.3 Gestionar los cambios en requisitos

SP 1.4 Mantener una trazabilidad bidireccional de requisitos

SP 1.5 Identificar inconsistencias entre el trabajo real a realizar y los

requisitos.

Otro referente es el modelo Requirements Management Maturity (RMM) [23],

donde también se expone la idea de identificar atributos y características de los

requisitos para luego priorizarlos. En este modelo tampoco se encuentra algo

explicito que indique el cómo priorizar aunque si se sugiere el hecho de tomar

métricas e identificar la importancia de cada requisito en el proyecto.

25

En un artículo publicado por IBM en el 2003, “The Five Levels of Requirements

Management Maturity” se afirma textualmente en el nivel 3 de RMM,

“Level Three – Structure, You need to understand how the requirements will be

used in order to understand what attributes are necessary. What reports and

queries will you need to support? What metrics must you keep? Getting answers to

these questions up front will help you start on the right foot” [23]

Por lo anterior, si en la fabricación de software el punto de partida se encuentra en

el desarrollo de requisitos previamente identificados, lo normal es que se quieran

priorizar. Debido a limitaciones de tiempo y presupuesto, puede ser difícil de

implementar todos los requisitos que se han suscitado para un sistema de

información. Además, los requisitos deberían ser implementados en etapas, y la

priorización puede ayudar a determinar cuáles deben implementarse en primer

lugar. Seguramente muchas fabricas desarrollan los requisitos de más bajo costo

en su implementación [9], sin tener en cuenta su importancia. Otros desarrollan los

requisitos que son más “fáciles” primero, seguramente basados en su propia

experiencia. La cuestión es, ¿Estos enfoques empíricos tienen posibilidades de

lograr los objetivos del producto o solución esperada? Para dar prioridad a los

requisitos de software, se recomienda un enfoque sistémico de priorización [3].

Si se tiene en cuenta un enfoque sistémico algunas técnicas de priorización

podrían ser potencialmente utilizadas en la ingeniería de requisitos como apoyo al

proceso de priorización o como ayuda a los líderes de desarrollo de software, de

tal forma que se acerque un poco esta actividad a una realidad basada en

ingeniería y no en un enfoque empírico.

Sommerville [15] Define la priorización de requisitos como la actividad en la cual

se identifican los requisitos más importantes para el sistema. Harwell et al. [24]

describe la prioridad como una característica del requisito que puede ser utilizada

para diferentes efectos de la solución y de la necesidad de la compañía. Otro

como Karlsson y Ryan [7]; Jung [25] definen la priorización como la característica

que identifica a un requisito que tiene mayor ponderación en importancia y menor

costo.

26

Podríamos mencionar técnicas como [26]:

Binary Search Tree,

Numeral Assignment Technique,

Planning Game, the 100-Point Method,

Theory-W,

Requirements Triage,

Wiegers' Method,

Requirements Prioritization Framework,

Conjoint analysis y

AHP

Kano Analysis

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

Este algoritmo es usado comúnmente en la búsqueda de información y puede ser

usado para la priorización de requisitos [27]. El enfoque básico para ser usado en

requisitos es el siguiente:

Ponga todos los requisitos en una pila.

Tome uno de los requisitos como raíz del árbol.

Tome otro de los requisitos y compárelo con el raíz.

Si el requisito es menos importante que el nodo raíz, se compara con el nodo

hijo izquierdo. Si el requisito es más importante que el nodo raíz, se compara

con el nodo hijo derecho. Si el nodo no tiene nodos secundarios, introducir el

nuevo requisito como nuevo nodo secundario a la derecha o izquierda,

dependiendo de si el requisito es más o menos importante.

Repita los pasos 3-4 hasta que todos los requisitos han sido comparados e

insertados en el árbol.

Para efectos de presentación recorra el árbol binario y ponga los requisitos en

una lista tomando el de menos importancia al final y el más importante al inicio.

27

3.2 TÉCNICA DE ASIGNACIÓN DE PESO NUMÉRICO (NUMERAL

ASSIGNMENT TECHNIQUE)

Esta técnica asigna un valor (escala) a cada requisito, adicionalmente los

requisitos se dividen en tres grupos: Obligatorios, deseables y no esenciales [5].

Los participantes asignan a los requisitos un número dentro de la escala de 1 a 5

indicando la importancia de cada uno de ellos [28]. Los números en la escala

tienen el siguiente significado:

El cliente no lo necesita.

No es importante.

Bastante importante (Si lo tiene el cliente lo agradece).

Es muy importante (El cliente lo desea).

Es obligatorio (El cliente no puede prescindir de él).

La clasificación final es el promedio de las clasificaciones de todos los

participantes para cada uno de los requisitos.

3.3 JUEGO DE LA PLANIFICACIÓN (PLANNING GAME)

Es una técnica utilizada por el Método de desarrollo de software Extreme

Programming [29, 29A] y se utiliza con los clientes para priorizar los requisitos

basado en historias. Esta es una variación de la técnica de asignación numérica

donde el cliente distribuye los requisitos en tres grupos, a) aquellos sin los cuales

el sistema no funcionará, b) los que son menos esenciales, pero proporcionan un

importante valor empresarial, y c) los que sería bueno tener.

3.4 MÉTODO DE LOS 100 PUNTOS (100-POINT METHOD)

El método de los 100 puntos [30] es básicamente un esquema de tipo votación

que es usada en ejercicios de lluvia de ideas. A cada interesado se le dan 100

puntos que puedan utilizar para votar por los requisitos que considere más

importantes, el interesado puede usarlos de la manera que él considere más

pertinente. Por ejemplo si existen cuatro requisitos que él considera son igual de

prioritarios, entonces el podrá darle a cada uno 25 puntos. Si existe un requisito

que él considera de importancia primordial podría darle los 100 puntos. Sin

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Brackett

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Karlsson95

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Leff

28

embargo, este tipo de esquema sólo funciona para una votación inicial. Si una

segunda votación se toma, la gente tiende a redistribuir sus votos para conseguir

que sus favoritos avancen en el esquema de prioridades.

3.5 TEORÍA W (THEORY-W)

Teoría-W fue inicialmente desarrollado en la Universidad del Sur de California [31,

32]. También se conoce como "Win-Win" (“Ganar-Ganar”). Un punto importante es

que soporta la negociación para resolver los desacuerdos acerca de los requisitos,

de manera que cada actor tiene una "victoria". Cuenta con dos principios:

Plan the flight and fly the plan (Plan de vuelo y volar el plan).

Identificar y administrar sus riesgos.

El primer principio tiene por objeto la construcción de planes bien estructurados

que cumplen con los estándares predefinidos para un fácil desarrollo, clasificación

y consulta. "Vuela el plan" asegura que el progreso sigue el plan original. El

segundo principio, "Identificar y administrar sus riesgos", implica la evaluación y

manejo de riesgos. En las negociaciones de ganar-ganar, cada usuario debe

clasificar los requisitos de forma privada antes de comenzar las negociaciones. En

el proceso de clasificación individual, el usuario considera si existen requisitos que

él está dispuesto a renunciar y que conoce completamente los riesgos e

implicaciones de ello. La Teoría-W tiene cuatro pasos:

Separe las personas del problema.

Centrarse en los intereses, no posiciones.

Invertir opciones para beneficio mutuo.

Insistir en el uso de un criterio objetivo.

29

3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE)

Requisitos Triage [33] es un proceso de varios pasos que incluye el

establecimiento de prioridades relativas a los requisitos, la estimación de recursos

necesarios para satisfacer cada necesidad, y la selección de un subconjunto de

los requisitos para optimizar la probabilidad de éxito del producto en el mercado en

cuestión. Esto está claramente dirigido a los desarrolladores de productos de

software en el mercado comercial. Es un enfoque único que vale la pena revisar, a

pesar de que claramente va más allá de los requisitos de asignación de

prioridades tradicionales, teniendo en cuenta los factores de negocio también

[33A].

3.7 WIEGERS' METHOD

Este método se relaciona directamente con el valor de cada requisito para un

cliente [3]. La prioridad se calcula dividiendo el valor de una obligación por la suma

de los costos y riesgos técnicos asociados a su aplicación [3]. El valor de una

obligación se considera como función tanto en el valor proporcionado por el cliente

para el cliente y la pena que se produce si el requisito falta. Esto significa que los

desarrolladores deben evaluar el costo de la exigencia y sus riesgos de

implementación, así como la penalidad si el requisito falta. Los atributos son

evaluados en una escala de 1 a 9.

3.8 FRAMEWORK DE PRIORIZACIÓN DE REQUISITOS (REQUIREMENTS

PRIORITIZATION FRAMEWORK)

El framework de priorización de requisitos asocia herramientas que incluyen [34,

35] las actividades de elicitación y priorización. Este framework intenta direccionar

lo siguiente:

Elicitar con ayuda de los interesados del negocio los objetivos del proyecto.

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Mois00

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Mois01

30

Permitir que los interesados en el proyecto puedan dar puntajes a los

requisitos y objetivos del proyecto mediante una escala de calificación grafica

difusa.

Calificar los requisitos basándose en una medida objetiva.

Encontrar las dependencias entre requisitos y agrupación de requisitos tanto

que la priorización de los mismos sea más efectiva.

Usar técnica de análisis de riesgos que permitan identificar entre los

interesados las desviaciones de apreciaciones o calificaciones subjetivas y la

asociación entre los aportes de los interesados y las calificaciones finales.

3.9 CONJOINT

Es una técnica estadística que permite medir el valor relativo de cada atributo de

un producto, con lo cual se puede determinar qué combinación de estos atributos

maximiza la probabilidad de elección por parte del consumidor. Inicialmente fue

desarrollada para su uso en modelos matemáticos de psicología y su aplicación al

marketing fue ideada en 1974 por Paul Green, profesor en The Wharton School

[36]. La técnica se desarrolla implementando lo siguiente:

Elegir los atributos más valiosos para posicionar una marca.

Al tener que elegir entre varios productos potenciales, identificar al que tendrá

mayor nivel de ventas

Decidir cuál es el precio adecuado para un producto

Estimar la cuota de mercado de un producto nuevo antes de su lanzamiento

Segmentar el mercado de acuerdo a los atributos de un producto

31

3.10 ANALYTIC HIERARCHY PROCESS (AHP)

AHP es una método para la toma de decisiones en situaciones donde existen

múltiples objetivos presentes [37][38][7] . Este método utiliza dos matrices para

calcular el valor y los costos relativos de los requisitos entre sí. Mediante el uso

de AHP el ingeniero de requisitos puede confirmar la consistencia de los

resultados. AHP puede ayudar a evitar errores generados de juicios subjetivos e

incrementar la probabilidad de que los resultados sean fiables. AHP puede ser

soportada por una herramienta independiente preferiblemente computacional. El

método AHP consta de 5 pasos:

Revisar los requisitos candidatos y completarlos enteramente.

Aplicar el método de comparación por pares para evaluar el valor relativo de

cada uno de los requisitos candidatos.

Aplicar el método de comparación por pares para evaluar el costo relativo de

los requisitos candidatos.

Calcular el valor relativo de cada requisito candidato y el costo de su

implementación y poder hacer seguimiento en un diagrama de costo – valor.

Usar el diagrama de costo – valor como un mapa que permita analizar los

requisitos candidatos.

3.11 ANÁLISIS KANO (KANO ANALYSIS)

Análisis Kano proporciona un medio poderoso y fácil de usar para clasificar

requisitos. Podemos utilizar esa clasificación para manejar nuestras decisiones de

priorización, asegurándonos de entregar todos los requisitos que deben estar en la

primera versión. Kano también nos ayuda a centrarnos en las necesidades que

diferencian a nuestro software, identificando y contrastando los requisitos

esenciales para el cliente. [39]

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Saaty


32

Kano definió cuatro categorías en las que se puede cada característica o requisito

pueden ser clasificados:

Sorpresa y deleite: capacidades que diferencian a un producto de la

competencia (por ejemplo, el iPod nav-wheel).

Más es mejor: dimensiones a lo largo de un continuo con una dirección clara de

utilidad incremental (por ejemplo, duración de la batería o la capacidad de la

canción).

Debe ser: las barreras funcionales de acceso al mercado, sin estas

capacidades, los clientes no utilizaran el producto (por ejemplo, la aprobación

de UL).

Mejor no ser: Representa las cosas que los clientes no les satisface (por

ejemplo, imposibilidad de aumentar la capacidad de la canción a través de

actualizaciones).

Aunque existen algunas técnicas de priorización que podrían ser usadas en

proyectos no solo de construcción de software sino de otra índole, realmente

no es fácil encontrar dentro de las empresas desarrolladoras de software,

estándares, métodos o técnicas evolucionadas con respecto a la priorización y

planificación de los requisitos de software [40]; existe más bien una tendencia a

utilizar la experiencia como instrumento principal para realizar esta actividad; No

obstante, algunas fabricas podrían estar usando alguna técnica en particular [6]

pero la verdad es que en un alto porcentaje las mismas no involucran en su

proceso ninguna , es por esto que la priorización “es uno de las actividades más

difíciles a la que se enfrentan los lideres de proyectos o desarrollo de software "

[41].

Podemos concluir entonces que la necesidad de poder contar con una

propuesta metodológica aliviaría de alguna manera esta falencia y aportaría

directamente al proceso de desarrollo software.

33

4. DESARROLLO METODOLÓGICO DEL PROYECTO

4.1. RECOPILACIÓN Y DOCUMENTACIÓN DE LAS TÉCNICAS DE

PRIORIZACIÓN

A partir de la investigación se han identificado algunas de las técnicas de

priorización de requisitos más reconocidas por la industria. Previamente en este

documento, estas técnicas se exponen en breve dando una introducción a las

mismas.

Tabla 1. Técnicas de priorización

Técnicas Acrónimo Autor Tipo

Analytic Hierarchy Process AHP Thomas L. Saaty Combinatorio

Binary Search Tree BST Adelson-Velskii y Landis.

Numeral Assignment Technique Brackett, J.W Combinatorio

Planning Game PG BECK, K. Agrupación

100-Point Method 100P Votación

Theory-W

University of Southern

California Combinatorio

Conjoint analysis Paul Green

Requirements Triage

Wiegers' Method Karl E. Wiegers Combinatorio

Requirements Prioritization

Framework Combinatorio

Kano Analysis Noriaki Kano

La caracterización de las técnicas tiene el objetivo de identificar cuál de estas,

según sus procesos y metas, pudiera ajustarse más a los diferentes tipos de

industria del software y sus diversos proyectos; a continuación se hace una

descripción más detallada de las técnicas que se listan en la Tabla 1.

Para presentar el detalle de las técnicas se ha diseñado un marco sobre el cual

éstas se documentan.

34

4.1.1 Marco descriptivo de la técnica

Nombre de la Técnica

Descripción de la técnica

Proceso de la Técnica

Entradas

Atributos

Requisitos

Actividades

Procesos

Tareas

Salidas

Logros

Entradas

ACTIVIDADES DEL MÉTODO

# Actividad Título de la actividad

Propósito Para qué y por qué tiene relevancia la actividad en la

totalidad de la técnica.

Descripción Breve descripción de la Actividad

Roles Aquellos roles encargados de realizar la actividad

Técnica

Prácticas o procedimientos para obtener el resultado y lograr el propósito de la

técnica.

Salidas

Resultado (Logros, metas) de la técnica

35

4.1.2 Caracterización detallada de las Técnicas

AHP - Analytical Hierarchy Process

Thomas L. Saaty

AHP es un método para la toma de decisiones en situaciones donde se presentan

múltiples objetivos. Este método utiliza una matriz de comparación por pares para

calcular el valor y los costos relativos de los requisitos. Mediante el uso de AHP,

el ingeniero de requisitos puede también confirmar la coherencia de los

resultados. Con AHP se pueden evitar errores de juicio subjetivo e incrementar la

probabilidad de que los resultados sean fiables. Hay cinco pasos en el método

AHP:

1. Revisar los requisitos del candidato a la integridad.

2. Aplicar el método de comparación por pares para evaluar el valor relativo de

los requisitos candidatos.

3. Aplicar el método de comparación por pares para evaluar el costo relativo de la

implementación de cada requisito candidato.

4. Calcular el valor relativo de cada requisito candidato y los costos de

implementación, y la trama de cada uno en un diagrama de costo-valor.

5. Utilice el diagrama de costo-valor, como un mapa para el análisis de los

requisitos candidatos.

Proceso

ENTRADAS

Requisitos candidatos.

Valor relativo.

Costo Relativo

SALIDAS

Gráfica Valor.

Gráfica Costo.

Gráfica Valor vs Costo.

ACTIVIDADES

S-1: Revisión de requisitos candidatos para la integridad. S-2: Comparación por pares S-3: Determinar la prioridad de los requisitos S-4: Columna de puntuación S-5: Verificar la consistencia.

36

ENTRADAS AL MÉTODO

Las entradas corresponden a los requisitos que el analista ha recolectado

previamente en el proceso de elicitación. Estos requisitos deben estar en un

mismo nivel de abstracción4 y estar claramente documentados, sin

ambigüedades.

Lo que ocurre es que en ocasiones los requisitos no se encuentran en un “estado

puro”, es decir, hay situaciones donde se presentan requisitos que a su vez son

composición y resultado de una conglomeración de requisitos. Por esto, y para

que AHP sea lo más preciso posible, se espera que los requisitos se encuentren

en un mismo nivel de abstracción.

Requisitos candidatos.

Valor relativo de cada requisito en el producto.

Costo relativo que se genera por la implementación de cada requisito.

4.1.3 Actividades del método

S - 1 REVISIÓN DE REQUISITOS CANDIDATOS PARA LA

INTEGRIDAD

Propósito Revisar que los requisitos estén claros y completos.

Descripción Se revisa y se re-analiza los requisitos para asegurarse que

estén correctos, completos y claros.

Roles

Rol Responsabilidades

Jefe del proyecto Lidera el proceso.

Stakeholder Acompaña en la

ponderación de los

requisitos.

Técnicas

Después de reunirse con el cliente, se revisan los requisitos basados en la

retroalimentación recibida, de esta forma se pueden identificar problemas de

ambigüedades, de falta de información o mala interpretación.

4 Según la RAE, Abstraer significa, separar por medio de una operación intelectual las cualidades

de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o noción.

37

S - 2 COMPARACIÓN POR PARES

Propósito Obtener una comparación cardinal del valor y costo de los

requisitos.

Descripción

En este paso, los interesados implementan el método de

comparación por pares de AHP. Se hacen dos matrices una

para el valor relativo y otra para el costo relativo. Suponiendo

que el número de requisitos sea n, el número de celdas

resultantes será de n x n. La calificación para el costo y valor

relativo se da en una escala de 1 a 9.

Tabla 2. Ejemplo de una matriz de comparación por pares

con 8 requisitos

SR-1 SR-2 SR-3 SR-4 SR-5 SR-6 SR-7 SR-8

SR-1 1 0,1 0,2 0,3 0,5 0,3 0,3 0,3

SR-2 9 1 0,3 0,3 0,2 0,2 0,2 0,1

SR-3 6 3 1 0,5 0,5 0,5 0,5 0,3

SR-4 3 4 2 1 0,3 0,3 0,3 0,3

SR-5 2 5 2 3 1 0,2 0,2 0,1

SR-6 3 5 2 3 5 1 0,2 0,2

SR-7 3 6 2 3 6 5 1 0,3

SR-8 3 7 4 3 7 5 3 1

Roles



Stakeholder

Acompaña en la

ponderación de los

requisitos.

Técnica

Una entrada arbitraria en la fila i y la columna j de la matriz, con la etiqueta aij,

indica la diferencia que tiene un requisito i sobre otro j, ya sea valor o costo, según

la medida que se tome en función de la comparación.

Como en un producto cartesiano, la comparación se realiza para la totalidad de los

requisitos en la matriz. En realidad no hay que llenar la matriz completamente, con

solo llenar la matriz diagonal superior (o inferior) se sabe que el restante de la

matriz contiene los mismos valores invertidos, es decir 1/aij. Ver Tabla 2

38

Tabla 3. Interpretacion de los valores en la matriz

Intensidad del

valor Interpretación

1 Requisitos i y j son de igual valor.

3 Requisito i tiene un valor ligeramente superior a j.

5 Requisito i tiene un valor superior a j.

7 Requisito i tiene un valor muy superior a j.

9 Requisito i tiene un valor absolutamente superior a j.

2, 4, 6, 8 Estas son las escalas intermedias entre dos juicios

adyacentes.

Recíprocos Si el requisito i tiene menor valor que j

Tabla 4. Interpretación de los costos en la matriz

Intensidad del

valor Interpretación

1 Requisitos i y j son de igual costo.

3 Requisito i tiene un costo ligeramente superior a j.

5 Requisito i tiene un costo superior a j.

7 Requisito i tiene un costo muy superior a j.

9 Requisito i tiene un costo absolutamente superior a j.

2, 4, 6, 8 Estas son las escalas intermedias entre dos juicios

adyacentes.

Recíprocos Si el requisito i tiene menor valor que j

S - 3 DETERMINAR LA PRIORIDAD DE LOS REQUISITOS

Propósito Hallar la matriz de comparación normalizada.

Descripción

Se promedian los datos sobre las columnas normalizadas

para calcular el vector propio de la matriz que representa la

distribución del criterio.

39

Roles



Stakeholder

Acompaña en la

validación de los

requisitos.

Técnica

Primero, se hace la sumatoria de los valores para cada columna de la matriz.

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

= am(j+1) + am+1(j+1) + am+2(j+1) + … + an(j+1) = Columna j+1

= amn + a(m+1)n + a(m+2)n + … + ann = Columna n

A continuación, se divide cada valor de la matriz por la suma de su respectiva

columna.

Tabla 5. Matriz Normalizada

SR-1 SR-2 SR-3 SR-4 SR-5 SR-6 SR-7 SR-8

SR-1 0,03333333 0,00357143 0,01234568 0,02366864 0,02435065 0,0265252 0,05847953 0,12184508

SR-2 0,3 0,03214286 0,02469136 0,01775148 0,00974026 0,01591512 0,02923977 0,05221932

SR-3 0,2 0,09642857 0,07407407 0,03550296 0,02435065 0,0397878 0,0877193 0,09138381

SR-4 0,1 0,12857143 0,14814815 0,07100592 0,01623377 0,0265252 0,05847953 0,12184508

SR-5 0,06666667 0,16071429 0,14814815 0,21301775 0,0487013 0,01591512 0,02923977 0,05221932

SR-6 0,1 0,16071429 0,14814815 0,21301775 0,24350649 0,0795756 0,03508772 0,07310705

SR-7 0,1 0,19285714 0,14814815 0,21301775 0,29220779 0,39787798 0,1754386 0,12184508

SR-8 0,1 0,225 0,2962963 0,21301775 0,34090909 0,39787798 0,52631579 0,36553525

jain

mi

n

mi

jai )1(

n

mi

ain

40

S - 4 COLUMNA DE PUNTUACIÓN

Propósito Hallar la columna de puntuación de los requisitos.

Descripción La puntuación de cada requisito es el porcentaje que el requisito

suma al valor total de los requisitos.

Roles



Técnica

Para determinar la puntuación de cada requisito, se halla el promedio de la fila de la

matriz normalizada, dividiendo la suma de cada fila por el número de requisitos, el

resultante de esta operación es una nueva columna definida aquí como

PUNTUACIÓN.

Promedio para una fila i:

Promedio( =Nim + Ni(m+1) + Ni(m+2) + … + Nin = Fila i), donde Nij es el

valor normalizado de la etiqueta aij.

Tabla 6. Columna de Puntuación.

Puntuación

0,03801494

0,06021252

0,0811559

0,08385113

0,09182779

0,13164463

0,20517406

0,30811902

n

mj

Nij

41

S - 5 VERIFICAR LA CONSISTENCIA

Propósito Verificar que los resultados sean coherentes y fiables.

Descripción

El punto de vista de la coherencia en AHP se basa en la idea de

transitividad cardinal. Por ejemplo, si el requisito A es considerado

como dos veces más importante que B y el requisito B se considera

que es tres veces más importante que el requisito C, la consistencia

cardinal perfecta entonces implicaría que el requisito A se

considerará seis veces más importante que el requisito C. De esta

manera, si los participantes juzgan el requisito A menos importante

que el requisito C, esto implica que un error de juicio existe y la

matriz de priorización es inconsistente.

Roles



Técnica

Se utiliza el índice de consistencia / índice aleatorio (CI / RI) para verificar la

consistencia de los resultados.

Calcular el producto entre la matriz de comparación (ver tabla 1.) y el vector de

puntuaciones (ver tabla 5.). Esto genera una nueva columna denominada aquí,

PRODUCTO.

Calcular los ratios; Para esto se crea una nueva columna definida aquí como

RATIO. En la primera celda de esta nueva columna se registra el ratio el cual se

halla dividiendo la primera celda de la columna PRODUCTO entre la primera celda

de la columna PUNTUACIÓN. En la segunda celda de la nueva columna se registra

el ratio que se halla dividiendo la segunda celda de la columna PRODUCTO entre

la segunda celda de la columna PUNTUACIÓN, respectivamente esto se repite

para cada celda subsiguiente.

Calcular el valor de CI; Calcular el índice de consistencia con la fórmula "=

(promedio (columna Ratio) - n) / n - 1" donde n es el número de requisitos.

Calcular la puntuación de CI / RI. Si la puntuación de CI / RI es suficientemente

pequeña, entonces las comparaciones de los participantes son probablemente lo

suficientemente consistentes como para ser útil. Thomas Saaty sugiere que si el CI

/ RI es menor que 0.10, entonces el grado de consistencia es satisfactorio, sin

42

embargo, si el CI / RI es mayor que 0.10, hay incoherencias y el método AHP no

puede dar resultados significativos. Para calcular la puntuación de CI / RI, se

obtiene el valor de RI estándar de la información de Saaty, algunos de los valores

de RI están listados en la Tabla 6.

Tabla 7. Random index values - Índice de valores aleatorios

Tabla 8. Ratio

Tabla 9. Según el número de requisitos, para este ejemplo el indice

aleatorio(RI) es 1,41

Numero de requisitos 2 3 4 5 6 7 8 9 10

RI 0 0,58 0,9 1,12 1,24 1,32 1,41 1,45 1,51

Producto Ratio

0,3470747 9,12995502

0,5732689 9,52075945

0,8231617 10,1429684

0,8466463 10,0970171

0,9873271 10,7519415

1,5224148 11,5645799

2,4062555 11,7278736

3,3363684 10,8281805

CI 0,35291563

CI/RI 0,25029478

SALIDAS DEL MÉTODO

Las salidas del método deben contener dos tipos de diagramas que muestren el

comportamiento de cada requisito según el valor y costo. Debe mostrar una tercera

gráfica, donde se exponen las prioridades para cada requisito del proyecto.

Gráfica 1; Distribución del Valor de los requisitos.

Gráfica 2; Distribución del Costo de los requisitos.

43

Gráfica 3; Diagrama Costo vs Valor, este diagrama está dividido en tres

grupos.

a) Alto ratio valor-costo de los requisitos (mayor de 2,0).

b) Medio ratio valor-costo de los requisitos (entre 2,0 y 0,5).

c) Bajo ratio valor-costo de los requisitos (menos de 0,5).

Binary Search Tree (BST) – Árbol Binario de Búsqueda

Adelson-Velskii y Landis

El Árbol de búsqueda binaria es un algoritmo que se utiliza normalmente en la

búsqueda y/o recuperación de información y se puede escalar fácilmente para ser

utilizado en la priorización de requisitos. Se recomienda que el árbol siempre este

equilibrado para una inserción más rápida. A este tipo de árbol equilibrado se le

llama Árbol AVL.

En los árboles AVL el factor de equilibrio de un nodo es la altura de su subárbol

izquierdo menos la altura de su subárbol derecho (a veces lo contrario) y un nodo

con un factor de equilibrio 1, 0 o -1 se considera equilibrado. Un nodo con

cualquier otro factor de equilibrio se considera desequilibrado y requiere

reequilibrar el árbol. El factor de equilibrio se almacena directamente en cada

nodo o es calculado a partir de las alturas de los subárboles.

Proceso

ENTRADAS

Lista de

requisitos.

SALIDAS

Requisitos

priorizados.

ACTIVIDADES

B-1: Listar requisitos

B-2: Comparación de

nodos (inserción)

ENTRADAS AL MÉTODO

Lista de requisitos

44


B - 1 LISTAR REQUISITOS

Propósito Listar los requisitos.

Descripción

Identificar los items que se van a priorizar en este proceso de

análisis. Todos los ítems deben estar al mismo nivel de

abstracción; no se deben mezclar requisitos con algo tan general

como las características.

Roles


Jefe del Proyecto Lidera el proceso.

Técnica

Los requisitos identificados se organizan en una lista.

B - 2 COMPARACIÓN DE NODOS

Propósito Identificar los requisitos que según el valor/importancia de cada

uno, tengan mayor prioridad en el proyecto.

Descripción

Para la comparación, se elije de la lista de requisitos un nodo, el

cual lleva el nombre de Raiz, los nodos secundarios a la derecha

tienen un mayor valor | importancia que el nodo raíz, y los nodos

secundarios a la izquierda tienen menos valor | importancia que

el nodo raíz. Cada nodo hijo es en sí mismo un nodo raíz a su

porpio nodo hijo. Si un nodo no tiene ningún hijo, este se llama

hoja.

45

Roles


Principales

representantes de los

desarrolladores

Líder del equipo técnico.

Suministra las

puntuaciones para el

valor | importancia.

Principales

representantes del

cliente

Suministra las


valor | importancia.

Técnica

Arbitrariamente se toma uno de los requisitos y se hubica como nodo raíz. Se

toma otro de los requisitos y se compara con el nodo raíz, si el requisito es menos

importante (valor|importancia), entonces el nodo raíz, se compara con el hijo de la

izquierda. Si el requisito es más importante (valor|importancia) que el nodo raíz, se

compara con el hijo de la derecha. Si el nodo no tiene ningún nodo

secundario(hijo) apropiado, introduzca el nuevo requisito como el nuevo nodo

secundario a la derecha o a la izquierda, dependiendo de si el requisito es más o

menos importante.

Lo anterior se repite hasta que todos los requisitos hayan sido comparados.

SALIDAS DEL MÉTODO

Luego de situar en una nueva lista los requisitos, y según el orden jerárquico que

esta representado en el árbol final; para la salida de este método se debe tener la

priorización de los requisitos, ordenados de mayor a menor según su grado de

prioridad.

Planning Game (PG)

Planning Game (PG) es una función de programación extrema (XP) y se utiliza

con los clientes para dar prioridad a las características basadas en “historias”. El

cliente distribuye los requisitos en tres grupos, "aquellos sin los cuales el sistema

no funcionará", "los que son menos esenciales, pero proporcionan un importante

valor empresarial", y "los que seria agradable tener.”(nice to have).

46

Proceso

ENTRADAS

Lista de

requisitos.

SALIDAS

Lista de los

requisitos con la

mayor prioridad.

ACTIVIDADES

PG-1: Categorizar

requisitos

ENTRADAS AL MÉTODO

Lista de requisitos.


PG - 1 CATEGORIZAR REQUISITOS

Propósito Identificar aquellos requisitos con los cuales se debe empezar el

desarrollo del proyecto.

Descripción

Los requisitos se distribuyen en tres grupos "aquellos sin los cuales

el sistema no funcionará", "los que son menos esenciales, pero

proporcionan un importante valor empresarial", y "los que sería

agradable tener.”(nice to have).

Roles


Principales

representantes del

cliente

Cataloga los requisitos,

según el valor que estos

tengan en el proyecto.

Técnica

A partir de una estimación subjetiva, se aprecia el valor que cada requisito, con su

implementación, otorga al producto. Según esta apreciación se decide a cual de las

tres categorias pertenece el requisito.

El sistema se debe empezar a desarrollar con aquellos requisitos que han sido

catalogados como, "aquellos sin los cuales el sistema no funcionará".

47

SALIDAS DEL MÉTODO

Luego de situar en una nueva lista los requisitos, según su clase y valor que le

aporta al producto final. Para la salida de este método se debe tener los requisitos

organizados por categorías.

Categorías:

a) Aquellos sin los cuales el sistema no funcionará.

b) Los que son menos esenciales, pero proporcionan un importante valor

empresarial

c) Los que seria agradable tener (nice to have).

100 Point Method - 100P

El método de los 100 puntos es básicamente un sistema de votación parecido a el

que se utiliza en los ejercicios de lluvia de ideas. Cada actor dispone de 100

puntos que él o ella puede utilizar para votar a favor de los requisitos más

importantes. Los 100 puntos se pueden distribuir de cualquier forma que el

interesado desee. Por ejemplo, si hay dos requisitos que el actor considera con la

misma prioridad, se le puede poner 50 puntos a cada uno. Sin embargo, este tipo

de esquema sólo funciona para una votación inicial. Después que los resultados

han sido publicados, todos los participantes podrán ver como han sido las

votaciones de los demás, por lo que si una segunda votación se toma, la gente

tiende a redistribuir sus votos para conseguir que sus favoritos avancen en el

esquema de prioridades.

Proceso

ENTRADAS

Lista de

requisitos.

SALIDAS

Priorización de

cada individuo.

Gráfica 2.

ACTIVIDADES

P-1: Asignación de

puntaje

P-2: Calculo de

prioridades

ENTRADAS AL MÉTODO

Las entradas corresponden a los requisitos que el analista ha recolectado

previamente en el proceso de elicitación.

Lista de requisitos.

48


P - 1 ASIGNACIÓN DE PUNTAJE

Propósito Asignar puntajes a los requisitos.

Descripción Dividir los puntos entre todos los requisitos, de acuerdo a cuál de

los requisitos es más importante para el sistema.

Roles


Desarrolladores

Suministra las

puntuaciones de los

requisitos.

Técnica

A partir de una estimación subjetiva, se aprecia el valor que cada requisito, con su

implementación, otorga al producto. Según esta apreciación se asigna un puntaje a

cada requisito.

P - 2 CALCULO DE PRIORIDADES

Propósito Obtener las prioridades de cada requisito.

Descripción

Después de que cada uno de los integrantes del grupo han

asignado puntos a los requisitos, se calcula el valor total de cada

uno de ellos.

Roles



49

Técnica

Se recolectan los puntajes que cada participante le ha asignado a cada uno de los

requisitos. Se suman estos puntajes de manera independiente, es decir,

respectivamente para cada requisito. Así, el puntaje del requisito 1 del participante

A se suma con el puntaje del requisito 1 del participante B, C, D, etc. Esto se

repite para todos los requisitos.

SALIDAS DEL MÉTODO

Para la salida de este método se debe tener la priorización que cada uno de los

desarrolladores le asigno a los requisitos y la priorización global de los mismos.

Wiegers’ Method – Metodo de Wiegers

Karl E. Wiegers

Priorización basada en valor, costo, y riesgo relativo.

Este método se relaciona directamente con el valor de cada requisito.

La prioridad se calcula dividiendo el valor de un requisito por la suma de los

costos y riesgos técnicos asociados con su implementación. El valor de un

requisito se considera como función tanto en el valor proporcionado por el cliente

para el cliente y la pena que se produce si el requisito falta. Esto significa que los

desarrolladores deben evaluar el costo de las necesidades y los riesgos de

implementación, así como la pena impuesta si el requisito falta. Los atributos son

evaluados en una escala del 1 al 9.

50

Proceso

ENTRADAS

Influencia relativa.

Beneficio relativo.

Penalidad

relativa.

Costo relativo.

Riesgo relativo

SALIDAS

Prioridad de los

requisitos

ACTIVIDADES

W-1: Listar requisitos

W-2: Beneficio relativo

W-3: Penalidad relativa

W-4: Valor total

W-5: Costo relativo

W-6: Riesgo relativo

W-7: Calculo de

prioridades

W-8: Ordenar

ENTRADAS AL MÉTODO

Las entradas en este método corresponden a los requisitos de carácter

negociable, aquellos que no se encuentran en la cima de la lista de priorización.

Es decir, no se debe incluir en este análisis, aquellos requisitos que

corresponden al núcleo del producto, aquellos que se definan como claves, parte

esencial o aquellos que sean necesarios para el cumplimiento de las regulaciones

gubernamentales. Una vez identificados estos requisitos, que definitivamente

deben ser desarrollados para que el producto pueda ser entregado, se usa el

Modelo (ver Figura 1) para determinar la prioridad de los requisitos restantes.

Lista de requisitos, características o casos.

Influencia relativa: Es el peso de cada factor en el proyecto.

Factores:

Beneficio relativo: Valor relativo que se le da a cada requisito según el

beneficio que con su implementación este otorga al producto.

Penalidad Relativa: Valor relativo que se estima por la no implementación

de un requisito.

Costo relativo: El costo relativo se refiere a la extensión de tiempo o trabajo

que los desarrolladores estiman se presentara en la implementación de

cada requisito.

Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los

requisitos. (Riesgo de negocio, técnico, de estimación, etc.).

51

Actividades y proceso del método

W - 1 LISTAR REQUISITOS

Propósito Listar los requisitos, características o casos que se desean

priorizar.

Descripción


análisis. Todos los ítems deben estar al mismo nivel de abstracción;

no se deben mezclar requisitos con algo tan general como las

características.

Roles


Jefe del Proyecto

Lidera el proceso.

Arbitra conflictos.

Ajusta el aporte de los

otros participantes si es

necesario.

Técnica

Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas

inherentes a los propios, por ejemplo; Una norma sería; si algunos requisitos estan

conectados logicamente: - se implementaria un requisito B solo si el requisito A

fuera implementado – para este caso solo se lista el requisito conductor.

W - 2 BENEFICIO RELATIVO

Propósito Estimar el beneficio relativo que cada requisito provee al cliente o al

negocio.

Descripción En una escala del 1 al 9 se valora el beneficio relativo del requisito,

donde 1 indica “Beneficio despreciable” y 9 significa “Enorme valor”.

Roles


Principales

representantes del

cliente

Suministra las


beneficio y la penalidad.

52

Técnica

A partir de una estimación subjetiva, se valora el beneficio que cada requisito con

su implementación otorga al producto.

W - 3 PENALIDAD RELATIVA

Propósito Estimar la penalidad relativa que el cliente o el negocio sufriría si el

requisito no es implementado.

Descripción En una escala del 1 al 9 se valora la penalidad relativa del requisito,

donde 1 indica “ningun inconveniente” y 9 significa “sanción grave”.

Roles


Principales

representantes del

cliente

Suministra las



Técnica

A partir de una estimación subjetiva, se valora la penalidad que cada requisito con

la omisión de su implementación otorga al producto

W - 4 VALOR TOTAL

Propósito

Calcular el valor total de las puntuaciones en los requisitos respecto

a penalidad y beneficio. Calcular el valor porcentual de cada

requisito.

Descripción

A partir de las estimaciones de beneficio relativo y penalidad

relativa se llega a calcular el valor total y posteriormente el valor

porcentual que cada requisito otorga al total (Valor %).

53

Roles



Técnica

Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la

valorización en cada requisito por la influencia relativa del respectivo factor

(Beneficio relativo, Penalidad relativa). Por defecto los beneficios y las penalidades

tienen una influencia equitativa, como un refinamiento de la tecnica se pueden

cambiar las influencias para cada factor.

Luego se suman estos resultados para cada requisito, se totalizan los valores de

los requisitos y se calcula el porcentaje (Valor %) que cada requisito tiene en este

total.

Suponiendo que;

Valor Total para un requisito(VTi)

Beneficio Relativo de un Requisito(BRRi)

Penalidad Relativa de un Requisito(PRRi)

Influencia Relativa del Beneficio(IB)

Influencia Relativa de la Penalidad(IP)

Se puede decir que;

VTi = (BRRi *IB) + (PRRi *IP)

Valori % = , donde n es el número de requisitos

n

i

VTi1

100 * VTi

54

W - 5 COSTO RELATIVO

Propósito Estimar el costo relativo que conlleva la implementación de cada

requisito.

Descripción

Se valora el costo que cada requisito con su implementación

otorga al producto. Este costo se mide según la extensión de

tiempo o trabajo que cada requisito le agregue al proyecto.

Roles


Principales


desarrolladores


Técnica

Se valora el costo relativo de la implementación de los requisitos en una escala de

1 (bajo) a 9 (alto). Luego se calcula el porcentaje que cada requisito contribuye en

el costo total. Hallar el costo total es similar a calcular el valor total. Los

desarrolladores pueden estimar los costos basados en la complejidad del

requisito, el trabajo que requiere hacer la interfaz de usuario, la habilidad para la

reutilizacion de codigo existente, la cantidad de pruebas y documentación que se

necesitara, etc.

Suponiendo que;

Costo Relativo para un requisito(CRi)

Se puede decir que;

Costo Total = , donde n es el número de requisitos.

Costo % =

iCRn

i

1

n

i

CRi1

100 * CRi

55

W - 6 RIESGO RELATIVO

Propósito Estimar el grado relativo de riesgo que conlleva la implementación

de cada requisito.

Descripción

Similar al costo relativo, los desarrolladores deben estimar el

grado relativo de cualquier tipo de riesgo asociado a cada requisito

en una escala de 1 a 9. Un puntaje de 1 significa que el requisito

se puede programar con un bajo nivel de concentración, mientras

que 9 indica serias preocupaciones sobre la viabilidad.

Roles


Principales


desarrolladores


Técnica

Se calcula el porcentaje del riesgo total que proviene de cada requisito. Por

defecto, beneficio, penalidad , costo y riesgo tienen una influencia equitativa, pero

estas pueden ser ajustadas. Si no se quiere considerar el riesgo en el total del

Modelo, este puede cambiarse a cero.

Suponiendo que;

Riesgo Relativo para un requisito(RRi)

Se puede decir que;

Riesgo Total = , donde n es el número de requisitos.

Riesgo % =

iRRn

i

1

n

i

RRi1

100 * RRi

56

W - 7 CALCULO DE PRIORIDADES

Propósito Obtener la prioridad de cada requisito.

Descripción Una vez estimado todo los factores anteriores, se calcula la

prioridad para cada requisito.

Roles


Principales


desarrolladores


Técnica

Con la siguiente formula se calculan las prioridades de cada requisito:

Figura 1. Modelo: Matriz de priorización

Influencias

relativas:

1 1 1 1

Requisitos Benefici

o

Relativo

Penalid

ad

Relativa

Valor

Total

Valor % Costo

Relativo

Costo

%

Riesgo

Relativo

Riesgo

%

Priorida

d

1.

2.

3.

4.

5.

6.

7.

n.

)inf*%()cosinf*%(

%

RiesgoluenciaDelriesgotoluenciaDelCosto

Valorprioridad

57

W - 8 ORDENAR

Propósito Ordenar la lista para tener mejor visibilidad de las prioridades.

Descripción Ordenar la lista de características en orden decreciente de

prioridad.

Roles


Principales


desarrolladores


SALIDAS DEL MÉTODO

Para la salida de este método se debe tener la priorización de los requisitos que

fueron candidatos, ordenados de mayor a menor según su grado de prioridad.

58

5. ANÁLISIS DE APROPIACIÓN Y USO DE LAS TÉCNICAS POR LA

INDUSTRIA DEL SOFTWARE.

Para el estudio del contexto de las empresas Colombianas en relación a sus

procesos y prácticas de priorización de requisitos en proyectos software, se realizó

una caracterización a las empresas del Sur Occidente Colombiano según los

siguientes objetivos:

Tener un diagnóstico de los procedimientos, técnicas, métodos y herramientas

que utilizan como soporte a los procesos de administración de requisitos en

proyectos software.

Obtener una idea global de los atributos organizacionales de las empresas del

contexto.

Asociar tipos de empresas a tipos de procedimientos, técnicas, métodos y

herramientas para priorizar requisitos en proyectos software.

La estrategia seleccionada para adelantar el estudio, fue utilizar la encuesta como

instrumento de recolección de información.

5.1 FICHA TÉCNICA DE LA ENCUESTA

La muestra de este estudio consta de 16 empresas pequeñas desarrolladoras de

software del sur occidente Colombiano.

Las empresas fuentes de información para la encuesta se escogieron bajo el

criterio aleatorio. En lo que respecta al componente aleatorio, cada empresa tenía

la misma probabilidad de ser escogida.

Las encuestas se aplicaron a empresas ubicadas en la capital del Valle del Cauca

y Bogotá.

59

Tabla 10. Ficha técnica del estudio adelantado

Universo en estudio Empresas desarrolladoras de software e integradoras de sistemas.

Tamaño de muestra 16 empresas

Distribución de la

muestra 93,8 % Cali, 6,2 % Bogotá

Cobertura Geográfica

Cali (15 empresas)

Bogotá (1 empresa)

Error muestral + 4.02%

Nivel de Confianza 95,5%

Tipo de muestreo Aleatorio, Mixto

Recolección de la

información Entrevistas personales en empresas

Fecha del trabajo de

campo 26 de febrero de 2011 – 30 de Marzo de 2012

Se realizaron entrevistas guiadas a los ingenieros involucrados en las actividades

de desarrollo de software de cada una de las empresas de la muestra a través de

un cuestionario conformado por dos secciones para un total de 7 preguntas (ver

Anexo A: Encuesta para el estudio de contexto):

Sección 1: Información general de la organización de la empresa.

Sección 2: Información sobre la aplicación de métodos de priorización de

requisitos.

5.2 RESULTADOS DE LA EVALUACIÓN

A continuación se presentan los resultados para las preguntas de cada sección.

Sólo se consideran aquellas pertinentes al proyecto de mejora a adelantar, y el

número de la pregunta referenciado corresponde al número en el instrumento

completo (ver Anexo A).

60

5.2.1 Sección 1: Información general. En esta sección de información general se

buscaba entender aspectos organizacionales, administrativos, financieros, de

comercialización y características del mercado al cual proveen productos y

servicios. Se recolectó información mediante 5 preguntas.

Para el interés particular se analizan cuatro de las preguntas (1, 2, 3 y 5 del Anexo

A).

5.2.1.1 Pregunta 1. Marque con una X el tamaño de su empresa de acuerdo a:

Ingenieros relacionados con las actividades de desarrollo de software. Se ofrecían

los rangos 1-3, 4-7, 8-15, 16 – 40, 40 ó más.

Tabla 11. Ingenieros de sistemas en las empresas

Número

de Ingenieros

Frecuencia Porcentaje

1 – 3 3 18,75 %

4 – 7 4 25 %

8 – 15 2 12,5 %

16 – 40 4 25%

40 ó más 3 18,75 %

61

Figura 2. Ingenieros de sistemas en las empresas

18,75%

25%

12,50%

25%

18,75%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

1 – 3 4 – 7 8 – 15 16 – 40 40 ó más

Nú

me

ro d

e e

mp

resa

s (%

)

Número de Ingenieros de sistemas

Los anteriores porcentajes nos dan una idea del tamaño de la empresa en lo que

respecta a recursos humanos directamente relacionados con desarrollo de

productos software. Con esta medida podemos saber de cuán compleja puede ser

la organización y administración en una empresa.

5.2.1.2 Pregunta 2. ¿Cuántos productos de software tiene su empresa?

Tabla 12. Número de productos software por empresa.

Empresa Nº de productos

1 5

2 0

3 5

4 0

5 8

6 0

7 8

8 3

9 3

62

Tabla 12. (Continua)

Empresa Nº de productos

10 1

11 3

12 0

13 10

14 5

15 3

16 0

Según el número de productos software de cada empresa se puede hacer una

idea de la experiencia de estas empresas en cuestión de métodos de

administración de proyectos y técnicas de priorización, partimos del hecho de que

se aprende de las experiencias y se supone por cada desarrollo un refinamiento

de las técnicas.

Figura 3. Relación Tamaño de la empresa vs Número de productos.

La Figura 3 muestra el tamaño de la empresa por número de desarrolladores

vinculados directamente en los proyectos software con relación al número de

productos por empresa. Para que se pueda leer de una forma más clara la anterior

figura, a continuación las equivalencias de los tamaños diagramados en la Figura

3 según los datos en la encuesta.

5

1

5 4

1

3

1 2 2 2

3 4 4

2

4

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Empresas

Nº de productos

Tamaño

63

Tabla 13. Equivalencias de tamaño con Rangos en encuesta.

Tamaño Rangos

1 1-3

2 4-7

3 8-15

4 16-40

5 40-más

5.2.1.3 Pregunta 3. ¿Cuál es su actividad principal? Para este caso se

ofrecían las opciones:

Desarrollo de software hecho a la medida

Desarrollo de software genérico

Tabla 14. Actividades principales por empresa

Empresa Software a la medida Software genérico

1 x

2 x

3 x

4 x

5 x

6 - -

7 x

8 x x

9 x x

10 x

11 x

12 x

13 x

14 x

15 x

16 x

64

Figura 4. Actividades de las empresas

5.2.1.4 Pregunta 4. ¿Cuáles de los siguientes modelos ha implementado su

organización en los últimos 3 años?

Tabla 15. Modelos implementados por las empresas

CMM-SW CMMI SPICE ISO 9001 PSP/TSP NA No sabe Otros

1 x

2 x

3 x

4 x

5 x

6 x

7 x

8 RAD

9 x

10 x SCRUM

11 x

12 x

13 x

14 x x

15 x

16 x

56,25%

25%

12,50%

6,25%

0

1

2

3

4

5

6

7

8

9

10

Software a la medida Sofware genérico Sofware genérico y a la medida

ninguno

Nú

me

ro d

e e

mp

resa

s

Actividades de las empresas

65

La mayoría de las empresas hace uso de un modelo de procesos para el

desarrollo y mantenimiento de sistemas de software. De la Tabla 15 se puede

concluir que las empresas buscan la organización y madurez de sus procesos.

Sección 2: Información sobre la aplicación de los métodos de priorización de

los requisitos.

5.2.1.5 Pregunta 5. De la cartilla adjunta cuál(es) método(s) de priorización de

requisitos aplica.

Métodos combinatorios.

Métodos mixtos combinatorios.

Método

s de votación.

Tabla 16. Aplicación de métodos de priorización de requisitos en las

empresas.

Combinatorio Mixto Votación Otros, ¿Cuál(es)?

1 x

2 x x

3 na

4 x

5 x

6 x

7 x

8 x

9 x x

10 x x

11 x

12 x

13 x

14 Propio

15 x

16 x

66

La Tabla 16 da una visión global de la metodología de cada empresa respecto a

priorización de requisitos.


empresas(Desarrollo de software hecho a la medida) .


1 x

2 x x

3

4 x

5 x

7 x

10 x x

12 x

16 x


empresas (Desarrollo de software genérico).


11 x

13 x

14 Propio

15 x


empresas(Desarrollo de software hecho a la medida y genérico).


8 x

9 x x

De la tabla 17 a la 19 se dividen las empresas en 3 grupos; Desarrollo de software

hecho a la medida, genérico y hecho a la medida y genérico, de estos 3 grupos se

hace una categorización de las empresas respecto a la aplicación de métodos de

priorización de requisitos.

67

6. CONCLUSIONES DE LA EVALUACIÓN

Se pudo saber cómo las empresas implementan modelos de desarrollo de

software entre los cuales algunos, como el CMMI, sugieren la priorización de

requisitos. El estudio indica que las empresas, según sus modelos de desarrollo,

de alguna forma sí aplican priorización de requisitos.

A través de una caracterización de las empresas se pudieron obtener tres tipos de

organizaciones, las cuales al evaluarlas por separado, pero en un mismo

concepto, han arrojado datos similares (ver Tablas 17 - 19); es decir;

Figura 5. Conclusiones de la evaluación

Al parecer los métodos combinatorios son ciertamente preferidos por las empresas

o bien son de los más conocidos, ya que el indicador arroja mayor porcentaje de

uso de este tipo de técnicas para la priorización de requisitos.

Ya que la teoría indica que tanto el ambiente organizacional como la naturaleza de

los proyectos definen la técnica que se debe usar para la priorización de los

68

requisitos, en un principio se pensó que por cada tipo de empresa (categorizadas

según la actividad principal, a) Desarrollo de software a la medida, b) genérico o,

c) genérico y a la medida), se practicaría de forma distinta la priorización, sin

embargo para la mayoría de casos las empresas utilizan los métodos

combinatorios, donde la técnica más conocida y practicada es Numeral

Assignment Technique.

Lo que hacen estas empresas es simplemente asignar valores a cada requisito

basándose en experiencias de otros proyectos, ocasionando que la priorización en

el caso de Numeral Assignment Technique sea subjetiva y poco precisa.

69

7. ANÁLISIS DE HERRAMIENTAS DE ADMINISTRACIÓN DE REQUISITOS

El análisis consta de un grupo de herramientas usadas en la administración de

proyectos software. Este análisis quiere determinar cuáles de las técnicas se

utilizan más en los procesos de gestión de requisitos. Es importante saber cual

técnica implementan estas herramientas en su proceso de priorización ya que son

productos muy usados y reconocidos en la industria.

Para la elección de estas empresas y sus herramientas se usó el método

aleatorio. En lo que respecta al componente aleatorio, cada herramienta tenía la

misma probabilidad de ser escogida.

7.1 RESULTADOS DE LA EVALUACIÓN

7.1.1 Pregunta 1. ¿Su herrramienta usa algunas de las siguientes técnicas:

Binary Search Tree, Numeral Assignment Technique, Planning Game, the 100-

Point Method, Theory-W, Requirements Triage, Wiegers' Method, Requirements

Prioritization Framework, y AHP? Listelas.

70

7.1.2 Pregunta 2. ¿Usa algún otra técnica? ¿Cuál?

Tabla 20. Herramientas de administraciones

Herramientas Distribuidor

Bin

ary

Se

arc

h T

ree

Nu

mera

l A

ssig

nm

en

t

Tech

niq

ue

Pla

nn

ing

Gam

e

100

-Po

int

Meth

od

Th

eo

ry-W

Req

uir

em

en

ts T

riag

e

Wie

ge

rs' M

eth

od

Req

uir

em

en

ts

Pri

ori

tizati

on

Fra

mew

ork

AH

P

otr

os

Nin

gu

no

Acclaro DFSS Axiomatic Design

Solutions x

Aligned

Elements Aligned x

ReqMan RequirementOne x

IRqA Visure Solutions x x x x x x KAN

O

Cognition

Cockpit Cognition x

RaQuest SparxSystems x x x

De nuevo el estudio arroja que una mayoría, en este caso 50%, implementa en su

proceso de administración de requisitos, los métodos combinatorios para priorizar,

más que nada la técnica Numeral Assigment Technique.

71

8. PROPUESTA; NUEVA TÉCNICA

La diversificación de técnicas de priorización es una práctica muy común para

mejorar procesos ajustando metodologías a cada proyecto y contexto. Haciendo

caso a esta premisa que plantea la diversificación de técnicas, se ha ajustado una

técnica apartándola de su estado único y uniforme para acoplarla a otra esperando

que de esta asociación se complemente una técnica con la otra. El fin de esta

mezcla es refinar una idea y presentar una nueva opción, una nueva técnica.

Antes se ha propuesto la unión de técnicas para la priorización, tomando lo mejor

de cada una y desarrollar una idea mejor. Tomando un ejemplo formal, la unión de

las técnicas AHP y PG, PGcAHP [42], otro ejemplo no tan formal sería la

estrategia de las empresas que priorizan con técnicas propias que en realidad son

una diversificación de otras ya conocidas. Para esta oportunidad la propuesta es la

combinación de las técnicas Planning Game (PG) y Wieger’s Method, PGcWs.

Aunque en una primera instancia se pensó en implementar PGcAHP hoy

pensamos que una técnica como PGcWs se acerca más a la realidad de las

empresas del contexto; se dice “del contexto” porque según cada proyecto y

empresa, varia la técnica a implementar y la técnica per se. Aun cuando PGcAHP

es una técnica bastante precisa y útil, se hace muy exhaustivo el proceso de

valuar en dos matrices distintas cada requisito contra todos los demás, la

metodología cartesiana demanda tiempo y no es rentable para el negocio.

72

PG with Wiegers’ Method – PGcWs

Priorización basada en atributos, valor, costo, y riesgo relativo.

Identificar atributos de los requisitos es importante en este método, ya que a

diferencia de la técnica PG, en PGcWs primero se deben categorizar los

requisitos para priorizar por categoría.

Al igual que en el método de Wieger la prioridad se calcula dividiendo el valor de

un requisito por la suma de los costos y riesgos técnicos asociados con su

implementación. El valor de un requisito se considera como función tanto en el

valor proporcionado por el cliente para el cliente y la pena que se produce si el

requisito falta. Esto significa que los desarrolladores deben evaluar el costo de las

necesidades y los riesgos de implementación, así como la pena impuesta si el

requisito falta. Los atributos son evaluados en una escala del 1 al 9.

Proceso

ENTRADAS

Influencia relativa

Beneficio relativo

Penalidad relativa

Costo relativo

Riesgo relativo

SALIDAS

Prioridad de los

requisitos

ACTIVIDADES

PGWs-1: Listar requisitos

PGWs-2: Categorizar

requisitos

PGWs-3: Beneficio relativo

PGWs-4: Penalidad relativa

PGWs-5: Valor total

PGWs-6: Costo relativo

PGWs-7: Riesgo relativo

PGWs-8: Calculo de

prioridades

PGWs-9: Ordenar

ENTRADAS AL MÉTODO

Las entradas en este método corresponden a todos los requisitos de una

categoría específica. Una vez identificados estos requisitos, se usa el Modelo

(ver Figura 1) para determinar la prioridad de los requisitos en la categoría.

Lista de requisitos, características o casos.

73

Influencia relativa: Es el peso de cada factor en el proyecto.

Factores:

Beneficio relativo: Valor relativo que se le da a cada requisito según el beneficio

que con su implementación este otorga al producto.

Penalidad Relativa: Valor relativo que se estima por la no implementación de un

requisito.

Costo relativo: El costo relativo se refiere a la extensión de tiempo o trabajo que

los desarrolladores estiman se presentara en la implementación de cada

requisito.

Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los

requisitos. (Riesgo de negocio, técnico, de estimación, etc.).

Actividades y proceso del método

W - 1 LISTAR REQUISITOS

Propósito Listar los requisitos, características o casos que se desean

priorizar.

Descripción


análisis. Todos los ítems deben estar al mismo nivel de abstracción;

no se deben mezclar requisitos con algo tan general como las

características.

Roles


Jefe del Proyecto

Lidera el proceso.

Arbitra conflictos.



necesario.

74

Técnica

Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas

inherentes a los propios, por ejemplo; Una norma sería; si algunos requisitos estan

conectados logicamente: - se implementaria un requisito B solo si el requisito A

fuera implementado – para este caso solo se lista el requisito conductor.

PGWs - 2 CATEGORIZAR REQUISITOS

Propósito

Identificar atributos de los requisitos. Dividir en categorías los

requisitos, dejando en cada categoría requisitos un mismo nivel de

abstracción.

Descripción

Los requisitos se distribuyen en grupos según sus características.

Tres grupos base podrían ser "aquellos sin los cuales el sistema no

funcionará", "los que son menos esenciales, pero proporcionan un

importante valor empresarial", y "los que sería agradable

tener.”(nice to have).

Roles


Jefe del Proyecto

Lidera el proceso.

Arbitra conflictos.



necesario.

Técnica

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

según las similitudes en los atributos y características. Se nombra cada grupo

haciendo alusión a las características de los requisitos que ahí se alojan.

PGWs - 3 BENEFICIO RELATIVO

Propósito Estimar el beneficio relativo que cada requisito provee al cliente o al

negocio.

75

Descripción En una escala del 1 al 9 se valora el beneficio relativo del requisito,

donde 1 indica “Beneficio despreciable” y 9 significa “Enorme valor”.

Roles


Principales

representantes del

cliente

Suministra las



Técnica

A partir de una estimación subjetiva, se valora el beneficio que cada requisito con

su implementación otorga al producto.

PGWs - 4 PENALIDAD RELATIVA

Propósito Estimar la penalidad relativa que el cliente o el negocio sufriría si el

requisito no es implementado.

Descripción En una escala del 1 al 9 se valora la penalidad relativa del requisito,

donde 1 indica “ningun inconveniente” y 9 significa “sanción grave”.

Roles


Principales

representantes del

cliente

Suministra las



Técnica

A partir de una estimación subjetiva, se valora la penalidad que cada requisito con

la omisión de su implementación otorga al producto.

76

PGWs - 5 VALOR TOTAL

Propósito

Calcular el valor total de las puntuaciones en los requisitos respecto

a penalidad y beneficio. Calcular el valor porcentual de cada

requisito.

Descripción

A partir de las estimaciones de beneficio relativo y penalidad

relativa se llega a calcular el valor total y posteriormente el valor

porcentual que cada requisito otorga al total (Valor %).

Roles


Jefe del Proyecto

Lidera el proceso.

Arbitra conflictos.



necesario.

Técnica

Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la

valorización en cada requisito por la influencia relativa del respectivo factor

(Beneficio relativo, Penalidad relativa). Por defecto los beneficios y las penalidades

tienen una influencia equitativa, como un refinamiento de la tecnica se pueden

cambiar las influencias para cada factor.

Luego se suman estos resultados para cada requisito, se totalizan los valores de

los requisitos y se calcula el porcentaje (Valor %) que cada requisito tiene en este

total.

Suponiendo que;

Valor Total para un requisito(VTi)

Beneficio Relativo de un Requisito(BRRi)

Penalidad Relativa de un Requisito(PRRi)

Influencia Relativa del Beneficio(IB)

Influencia Relativa de la Penalidad(IP)

Se puede decir que;

VTi = (BRRi *IB) + (PRRi *IP)

77

Valori % =

n

i

VTi1

100 * VTi , donde n es el número de requisitos.

PGWs - 6 COSTO RELATIVO

Propósito Estimar el costo relativo que conlleva la implementación de cada

requisito.

Descripción

Se valora el costo que cada requisito con su implementación otorga

al producto. Este costo se mide según la extensión de tiempo o

trabajo que cada requisito le agregue al proyecto.

Roles


Principales


desarrolladores


Suministra las


costo y el riesgo.

Técnica

Se valora el costo relativo de la implementación de los requisitos en una escala de

1 (bajo) a 9 (alto). Luego se calcula el porcentaje que cada requisito contribuye en

el costo total. Hallar el costo total es similar a calcular el valor total. Los

desarrolladores pueden estimar los costos basados en la complejidad del requisito,

el trabajo que requiere hacer la interfaz de usuario, la habilidad para la reutilizacion

de codigo existente, la cantidad de pruebas y documentación que se necesitará,

etc.

Suponiendo que;

Costo Relativo para un requisito(CRi)

Se puede decir que;

Costo Total = iCRn

i

1

, donde n es el número de requisitos.

78

Costo % =

n

i

CRi1

100 * CRi

PGWs - 7 RIESGO RELATIVO

Propósito Estimar el grado relativo de riesgo que conlleva la implementación

de cada requisito.

Descripción

Similar al costo relativo, los desarrolladores deben estimar el grado

relativo de cualquier tipo de riesgo asociado a cada requisito en una

escala de 1 a 9. Un puntaje de 1 significa que el requisito se puede

programar con un bajo nivel de concentración, mientras que 9

indica serias preocupaciones sobre la viabilidad.

Roles


Principales

representantes del

cliente


Suministra las


costo y el riesgo.

Técnica

Se calcula el porcentaje del riesgo total que proviene de cada requisito. Por defecto,

beneficio, penalidad , costo y riesgo tienen una influencia equitativa, pero estas

pueden ser ajustadas. Si no se quiere considerar el riesgo en el total del Modelo,

este puede cambiarse a cero.

Suponiendo que;

Riesgo Relativo para un requisito(RRi)

Se puede decir que;

Riesgo Total = iRRn

i

1

, donde n es el número de requisitos.

79

Riesgo % =

n

i

RRi1

100 * RRi

PGWs - 8 CALCULO DE PRIORIDADES

Propósito Obtener las prioridades de cada requisito.

Descripción Una vez estimado todo los factores anteriores, se calcula la

prioridad para cada requisito.

Roles


Principales

representantes del

cliente


Suministra las


costo y el riesgo.

Técnica

Con la siguiente formula se calculan las prioridades de cada requisito:

)inf*%()cosinf*%(

%

RiesgoluenciaDelriesgotoluenciaDelCosto

Valorprioridad

80

Figura 6. Modelo: Matriz de priorización

Influencias relativas: 1 1 1 1

Requisitos Beneficio

Relativo

Penalidad

Relativa

Valor

Total

Valor % Costo

Relativo

Costo % Riesgo

Relativo

Riesgo % Prioridad

1.

2.

3.

4.

5.

6.

7.

n.

PGWs - 9 ORDENAR

Propósito Ordenar la lista para tener mejor visibilidad de las prioridades

Descripción Ordenar la lista de características en orden decreciente de

prioridad.

SALIDAS DEL MÉTODO

Para la salida de este método se debe tener la priorización de los requisitos que

fueron candidatos, ordenados de mayor a menor según su grado de prioridad.

81

9. RESULTADOS DE APLICACIÓN DE LAS TÉCNICAS

9.1 CASO CMSOFTLUTIONS

CMSOFTLUTIONS es una empresa colombiana que tiene como actividad principal

el desarrollo de software genérico. En enero de 2012 en una reunión con el

director de desarrollo de dicha empresa, se expuso un grupo de técnicas, entre

ellas; 100P, AHP, BST, PG, Wieger’s Method, esta reunión con el motivo de

validar técnicas y posteriormente aplicar alguna en esa organización. Haciendo

uso de Excel se hizo un ejercicio de priorización ajustado con las técnicas AHP y

Wieger´s Method respectivamente, al término de la reunión se concluyó que el

caso más adecuado para la clase de proyectos que CMSOFTLUTIONS construye,

sería Wieger´s Method por la capacidad que esta técnica tiene para tomar

diversas formas según el tipo de proyecto.

Para este caso se aplicará la técnica PGcWs:

9.1.1 Primero, Listar Requisitos. CMSOFTLUTIONS proporcionó 47 requisitos

de un proyecto que actualmente se encuentra desarrollando. Por motivos de

confidencialidad no se expondrá la descripción de estos requisitos.

9.1.2 Segundo, Categorizar requisitos

Tabla 21. Categorías e influencias

CATEGORÍAS Beneficio Penalidad Costo Riesgo

CORE5 4 4 2 0

NTH6 1 1 1 4

SOFTWARE7 2 2 1 1

INSIDENTES8 4 4 1 1

5 CORE, requisitos básicos del sistema, aquellos sin los cuales el sistema no podría funcionar.

6 NTH, nice to have.

7 SOFTWARE, requisitos funcionales.

8 INSIDENTES, errores que pudieran presentar las aplicaciones desarrolladas

82

9.1.3 Tercero, Beneficio Relativo

Tabla 22. Beneficio relativo (CORE)


Relativo

1 9

2 9

3 9

4 9

5 9

6 9

7 9

8 9

9 9

10 9

11 9

12 9

13 9

Tabla 23. Beneficio relativo (INSIDENTES)


Relativo

14 4

15 3

16 7

17 5

18 9

19 9

20 8

83

Tabla 24. Beneficio relativo (NTH)


Relativo

21 7

22 7

23 5

Tabla 25. Beneficio relativo (SOFTWARE)


Relativo

24 9

25 9

26 9

27 9

28 9

29 9

30 9

31 9

32 9

33 9

34 9

35 9

36 7

37 4

38 9

39 9

40 9

41 9

42 9

43 9

44 9

45 8

46 7

47 4

84

9.1.4 Cuarto, Penalidad Relativa

Tabla 26. Penalidad relativa (CORE)

Requisitos Penalidad

Relativa

1 9

2 9

3 9

4 9

5 9

6 9

7 9

8 9

9 9

10 9

11 9

12 9

13 9

Tabla 27. Penalidad relativa (INSIDENTES)


Relativa

14 4

15 3

16 7

17 5

18 9

19 9

20 8

85

Tabla 28. Penalidad relativa (NTH)


Relativa

21 7

22 7

23 5

Tabla 29. Penalidad relativa (SOFTWARE)


Relativa

24 9

25 9

26 9

27 9

28 9

29 9

30 9

31 9

32 9

33 9

34 9

35 9

36 7

37 4

38 9

39 9

40 9

41 9

42 9

43 9

44 9

45 8

46 7

47 4

86

9.1.5 Quinto, Valor Total

Tabla 30. Valor Total (CORE)

Influencia

relativa:

4 4


Relativo

Penalidad

Relativa

Valor Total Valor %

1 9 9 72 7,6923

2 9 9 72 7,6923

3 9 9 72 7,6923

4 9 9 72 7,6923

5 9 9 72 7,6923

6 9 9 72 7,6923

7 9 9 72 7,6923

8 9 9 72 7,6923

9 9 9 72 7,6923

10 9 9 72 7,6923

11 9 9 72 7,6923

12 9 9 72 7,6923

13 9 9 72 7,6923

Total 936

Tabla 31. Valor Total (INSIDENTES)

Influencia

relativa:

4 4


Relativo

Penalidad

Relativa

Valor Total Valor %

14 4 2 24 6,8182

15 3 1 16 4,5455

16 7 9 64 18,182

17 5 5 40 11,364

18 9 9 72 20,455

19 9 9 72 20,455

20 8 8 64 18,182

Total 352

87

Tabla 32. Valor Total (NTH)

Influencia

relativa:

1 1


Relativo

Penalidad

Relativa

Valor Total Valor %

21 7 4 11 35,484

22 7 3 10 32,258

23 5 5 10 32,258

Total 31

Tabla 33. Valor Total (SOFTWARE)

Influencia

relativa:

2 2


Relativo

Penalidad

Relativa

Valor Total Valor %

24 9 9 36 4,401

25 9 9 36 4,401

26 9 9 36 4,401

27 9 9 36 4,401

28 9 9 36 4,401

29 9 9 36 4,401

30 9 9 36 4,401

31 9 9 36 4,401

32 9 9 36 4,401

33 9 9 36 4,401

34 9 9 36 4,401

35 9 6 30 3,6675

36 7 9 32 3,912

37 4 7 22 2,6895

38 9 9 36 4,401

39 9 9 36 4,401

40 9 9 36 4,401

41 9 9 36 4,401

42 9 9 36 4,401

43 9 9 36 4,401

44 9 9 36 4,401

45 8 8 32 3,912

46 7 7 28 3,423

47 4 9 26 3,1785

Total 818

88

9.1.6 Sexto, Costo Relativo

Tabla 34. Costo Relativo (CORE)

Requisitos Costo

Relativo Costo %

1 5 8,62069

2 3 5,17241

3 6 10,3448

4 8 13,7931

5 8 13,7931

6 5 8,62069

7 5 8,62069

8 3 5,17241

9 3 5,17241

10 6 10,3448

11 2 3,44828

12 2 3,44828

13 2 3,44828

Tabla 35. Costo Relativo (INSIDENTES)

Requisitos Costo

Relativo Costo %

14 3 21,4286

15 1 7,14286

16 1 7,14286

17 2 14,2857

18 2 14,2857

19 4 28,5714

20 1 7,14286

Tabla 36. Costo Relativo (NTH)

Requisitos Costo

Relativo Costo %

21 2 15,3846

22 9 69,2308

23 2 15,3846

89

Tabla 37. Costo Relativo (SOFTWARE)

Requisitos Costo

Relativo Costo %

24 4 5,33333

25 2 2,66667

26 3 4

27 3 4

28 5 6,66667

29 5 6,66667

30 1 1,33333

31 3 4

32 3 4

33 7 9,33333

34 7 9,33333

35 4 5,33333

36 4 5,33333

37 4 5,33333

38 2 2,66667

39 2 2,66667

40 2 2,66667

41 2 2,66667

42 2 2,66667

43 2 2,66667

44 2 2,66667

45 2 2,66667

46 2 2,66667

47 2 2,66667

90

9.1.7 Séptimo, Riesgo relativo Tabla 38. Riesgo Relativo (CORE)

Requisitos Riesgo

Relativo Riesgo %

1 4 9,09

2 3 6,82

3 6 13,64

4 4 9,09

5 4 9,09

6 4 9,09

7 4 9,09

8 3 6,82

9 3 6,82

10 3 6,82

11 2 4,55

12 2 4,55

13 2 4,55

Tabla 39. Riesgo Relativo (INSIDENTES)

Requisitos Riesgo

Relativo Riesgo %

14 8,33 8,33

15 8,33 8,33

16 8,33 8,33

17 16,67 16,67

18 16,67 16,67

19 33,33 33,33

20 8,33 8,33

Tabla 40. Riesgo Relativo (NTH)

Requisitos Riesgo

Relativo Riesgo %

21 2 15,38

22 9 69,23

23 2 15,38

91

Tabla 41. Riesgo Relativo (SOFTWARE)

Requisitos Riesgo

Relativo Riesgo %

24 3 4,6875

25 2 3,125

26 2 3,125

27 2 3,125

28 4 6,25

29 4 6,25

30 1 1,5625

31 2 3,125

32 2 3,125

33 6 9,375

34 6 9,375

35 2 3,125

36 4 6,25

37 4 6,25

38 2 3,125

39 2 3,125

40 2 3,125

41 2 3,125

42 2 3,125

43 2 3,125

44 2 3,125

45 2 3,125

46 2 3,125

47 2 3,125

92

9.1.8 Octavo, Calculo de Prioridades

Tabla 42. Calculo de prioridad (CORE)

Influencia relativa: 4 4 2 0


Relativo

Penalidad

Relativa

Valor

Total

Valor % Costo

Relativo

Costo % Riesgo

Relativo

Riesgo % Prioridad

1 9 9 72 7,6923 5 8,62069 4 9,09 0,45

2 9 9 72 7,6923 3 5,17241 3 6,82 0,74

3 9 9 72 7,6923 6 10,3448 6 13,64 0,37

4 9 9 72 7,6923 8 13,7931 4 9,09 0,28

5 9 9 72 7,6923 8 13,7931 4 9,09 0,28

6 9 9 72 7,6923 5 8,62069 4 9,09 0,45

7 9 9 72 7,6923 5 8,62069 4 9,09 0,45

8 9 9 72 7,6923 3 5,17241 3 6,82 0,74

9 9 9 72 7,6923 3 5,17241 3 6,82 0,74

10 9 9 72 7,6923 6 10,3448 3 6,82 0,37

11 9 9 72 7,6923 2 3,44828 2 4,55 1,12

12 9 9 72 7,6923 2 3,44828 2 4,55 1,12

13 9 9 72 7,6923 2 3,44828 2 4,55 1,12

Totales 936 58 44

Tabla 43. Calculo de prioridad (INSIDENTES)



Relativo

Penalidad

Relativa

Valor

Total

Valor % Costo

Relativo

Costo % Riesgo

Relativo

Riesgo % Prioridad

14 4 2 24 6,8182 3 21,4286 1 8,33 8,65

15 3 1 16 4,5455 1 7,14286 1 8,33 8,97

16 7 9 64 18,182 1 7,14286 1 8,33 10,88

17 5 5 40 11,364 2 14,2857 2 16,67 17,46

18 9 9 72 20,455 2 14,2857 2 16,67 18,10

19 9 9 72 20,455 4 28,5714 4 33,33 34,05

20 8 8 64 18,182 1 7,14286 1 8,33 10,88

Totales

352

14

12

93

Tabla 44. Calculo de prioridad (NTH)



Relativo

Penalidad

Relativa

Valor

Total

Valor % Costo

Relativo

Costo % Riesgo

Relativo

Riesgo % Prioridad

21 7 4 11 35,484 2 15,3846 2 15,38 63,84

22 7 3 10 32,258 9 69,2308 9 69,23 277,39

23 5 5 10 32,258 2 15,3846 2 15,38 63,64

Totales

31

13

13

Tabla 45. Calculo de prioridad (SOFTWARE)

Influencia

relativa:

4 4 2 0

Requisitos Benefici

o

Relativo

Penalida

d

Relativa

Valo

r

Total

Valor

%

Costo

Relativ

o

Costo

%

Riesgo

Relativ

o

Riesgo

%

Priorida

d

24 9 9 36 4,401 4 5,33333 3 4,69 5,51

25 9 9 36 4,401 2 2,66667 2 3,13 4,78

26 9 9 36 4,401 3 4 2 3,13 4,23

27 9 9 36 4,401 3 4 2 3,13 4,23

28 9 9 36 4,401 5 6,66667 4 6,25 6,91

29 9 9 36 4,401 5 6,66667 4 6,25 6,91

30 9 9 36 4,401 1 1,33333 1 1,56 4,86

31 9 9 36 4,401 3 4 2 3,13 4,23

32 9 9 36 4,401 3 4 2 3,13 4,23

33 9 9 36 4,401 7 9,33333 6 9,38 9,85

34 9 9 36 4,401 7 9,33333 6 9,38 9,85

35 9 6 30 3,6675 4 5,33333 2 3,13 3,81

36 7 9 32 3,912 4 5,33333 4 6,25 6,98

37 4 7 22 2,6895 4 5,33333 4 6,25 6,75

38 9 9 36 4,401 2 2,66667 2 3,13 4,78

39 9 9 36 4,401 2 2,66667 2 3,13 4,78

40 9 9 36 4,401 2 2,66667 2 3,13 4,78

41 9 9 36 4,401 2 2,66667 2 3,13 4,78

42 9 9 36 4,401 2 2,66667 2 3,13 4,78

43 9 9 36 4,401 2 2,66667 2 3,13 4,78

44 9 9 36 4,401 2 2,66667 2 3,13 4,78

45 8 8 32 3,912 2 2,66667 2 3,13 4,59

46 7 7 28 3,423 2 2,66667 2 3,13 4,41

47 4 9 26 3,1785 2 2,66667 2 3,13 4,32

Totales 818 75 64

94

9.1.9 Noveno, Ordenar Tabla 46. Requisitos ordenados (CORE) Requisitos Prioridad

11 1,12

12 1,12

13 1,12

2 0,74

8 0,74

9 0,74

1 0,45

6 0,45

7 0,45

3 0,37

10 0,37

4 0,28

5 0,28

Tabla 47. Requisitos ordenados (INISIDENTES) Requisitos Prioridad

19 34,05

18 18,10

17 17,46

16 10,88

20 10,88

15 8,97

14 8,65

Tabla 48. Requisitos ordenados (NTH)

Requisitos Prioridad

22 277,39

21 63,84

23 63,64

95

Tabla 49. Requisitos ordenados (SOFTWARE)

Requisitos Prioridad

33 9,85

34 9,85

36 6,98

28 6,91

29 6,91

37 6,75

24 5,51

30 4,86

25 4,78

38 4,78

39 4,78

40 4,78

41 4,78

42 4,78

43 4,78

44 4,78

45 4,59

46 4,41

47 4,32

26 4,23

27 4,23

31 4,23

32 4,23

35 3,81

El ejercicio de aplicación de la técnica PGcWs ha arrojado la priorización para

cada una de las categorías (CORE, INSIDENTES, NTH, SOFTWARE), no se

podría hacer una comparación contra la priorización de CMSOFTLUTIONS ya

que, para este proyecto, esa empresa no realizó.

El orden para el desarrollo de cada categoría es; CORE, SOFTWARE,

INSIDENTES, NTH, INSIDENTES9.

9 Los INSIDENTES en este caso aparecen dos veces en el orden, ya que luego del desarrollo de

los requisitos NTH se podrían presentar nuevos errores en la aplicación.

96

9.2 CASO COOMEVA

COOMEVA es una organización Colombiana que realiza proyectos a la medida e

insourcing. En diciembre de 2011 se hizo contacto con esta empresa la cual

estuvo muy interesada en la aplicación de una técnica de priorización en sus

procesos de administración de requisitos.

En cada proyecto software, COOMEVA maneja extensas listas de requisitos, lo

cual hace necesario el agrupamiento de estos según sus características, es decir,

definir categorías especificas en las cuales se distribuyan los diferentes requisitos

con el objetivo de priorizar las categoría por separado. Por lo anterior, se infiere

que Planning Game (PG) es la técnica más adecuada, aunque para hacer de la

aplicación algo más completo se pensó en unir PG con Wieger´s Method

aprovechando de esta última su capacidad para priorizar de manera distinta en

cada proyecto (Ver anexo B).

97

10. TRABAJOS FUTUROS

Para CMSOFTLUTIONS y COOMEVA se construirá un software que permita

priorizar requisitos basado en una combinación de las técnicas Wieger`s Method y

Planning Game (ver Anexo B), CMSOFTLUTIONS posee una herramienta propia

de administración de requisitos a la cual se le añadirá el módulo de priorización.

Este trabajo será complemento en la presentación de un método que busca

integrarse con los procesos de la Ingeniería de requisitos. La propuesta

metodológica indicará el momento y la forma para la implementación de prácticas

de priorización de requisitos en un instante del ciclo de vida del proyecto. A partir

de la investigación aquí datada se podrán identificar las características que

enmarcan la priorización de requisitos, lo que será útil para entender en que fase

de la ingeniería de requisitos se puede ubicar este avance de la administración de

requisitos. Se pretende formalizar la tarea de la priorización y agregarle valor a

este tipo de ingeniería, con un nuevo proceso aportar en la madurez de la

ingeniería.

98

11. CONCLUSIONES

Aunque las empresas implementen metodologías que suponen la priorización de

requisitos, esta priorización no es formal, lo que hacen las empresas es

simplemente asignar valores a cada requisito basándose en experiencias de otros

proyectos, ocasionando que la priorización en el caso de Numeral Assignment

Technique sea subjetiva y poco precisa.

Para elegir una técnica de priorización de requisitos la técnica misma debe hacer

manejo de dos aspectos muy importantes:

Atributos de los requisitos10

Roles11

Manejar atributos y hacer participes a los Stakeholders para la evaluación de los

atributos, hace que la priorización sea precisa, objetiva y confiable. Algunos

atributos que pueden ser útiles en el proceso son; Valor relativo para el cliente,

Costo de implementación, riesgo de implementación, penalidad por no

implementación.

Si se quieren obtener mejores resultados existen técnicas formales, reconocidas y

recomendadas para priorizar, aunque se pueden usar técnicas propias siempre y

cuando hagan caso a esos dos aspectos.

Aquellos proyectos software que posean un número considerable de requisitos,

deberían crear grupos en los cuales se puedan distribuir estos requisitos según

10

Se refiere a identificar características de los requisitos y valorar según la influencia de estas

características en el proyecto. 11

Implicar varios participantes en las diferentes actividades de la priorización, esto disminuye la

subjetividad.

99

sus características, lo que permitirá una gestión más fácil del proyecto y de la

priorización.

Un proceso formal, a diferencia de uno informal, ayuda a llevar el trazo de lo

aplicado en dicho proceso, lo que es muy útil en un refinamiento, además de dar

un horizonte al proyecto y plantear metas claras. Formalizar12 procesos es

importante, es así como se puede corroborar qué tanto se ha avanzado hacia el

objetivo.

12

Formalidad, exactitud, puntualidad y consecuencia en las acciones.

100

BIBLIOGRAFIA

[1] CAPERS JONES. “Software Engineering best practices”.

[2] Definición Requisito, Real Academia Español, [en línea]. Disponible en:

http://buscon.rae.es/dpdI/SrvltConsulta?requisito. [Consulta: Noviembre 2011].

[3] WIEGERS, K. “Software Requirements”, second edition. Redmond, WA:

Microsoft Press, 2003.

[4] KOTONYA, G. and SOMMERVILLE, I. “Requirements Engineering: Processes

and Techniques”. Chichester, England: John Wiley & Sons Ltd, 1998.

[5] BRACKETT, J. W. “Software Requirements” (SEI-CM-19-1.2, ADA235642).

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990.

[6] LEHTOLA, L. "Providing value by prioritizing requirements throughout software

product development State of practice and suitability of prioritization methods."

Tesis, Helsinki University of Technology, May 2006.

[7] KARSLSSON, J. & Ryan, K. "A Cost-Value Approach for Prioritizing

Requirements." IEEE Software 14, 5 (September/October 1997): 67-74.

[8] MOISIADIS, F. “The Fundamentals of Prioritizing Requirements. [En linea] .

Proceedings of Test and Automation Conference” (September 2002). [Consulta:

Noviembre 2011] Disponible en:

http://www.seecforum.unisa.edu.au/Sete2002/ProceedingsDocs/05P-Moisiadis.pdf

[9] Herrmann, A., M. Daneva, ”Requirements Prioritization Based on Benefit and

Cost Prediction: A Method Classification Framework”, Technical Report

SWEHDTR-2008-01, University Heidelberg

[10] FAVARO, J. “Managing Requirements for Business Value”. IEEE Software

14, 5 (Marzo/Abril 2002) ; 23 -24.

[11] “Capability Maturity Model® Integration (CMMI) is a process improvement

approach”, [En Linea]. [Consulta: Noviembre 2011]. Disponible en:

http://www.sei.cmu.edu/cmmi/.

http://es.wikipedia.org/wiki/requisito

http://es.wikipedia.org/wiki/requisito

101

[12] Definición Elicitar, Real Academia Española, [en línea]. [Consulta: Noviembre

2010]. Disponible en :http://buscon.rae.es/dpdI/SrvltConsulta?lema=elicitar

[13] GEISSER , M & HILDENBRAND , T. ”A Method for collaborative

Requeriments Elicitation and Decision-Supported Requeriments Analisys”, Paper,

University of Mannheim, Germany.

[14] ROYCE, W.W. “Managing the Development of Large Software Systems:

Concepts and Techniques”. Proceedings of Wescon, pp. 1-9, 1970.

[15] SOMMERVILLE, I. “Software Engineering”, fifth edition. Wokingham, England:

Addison-Wesley, 1996.

[16] SCHACH, S.R. “Object-Oriented and Classical Software Engineering”, fifth

edition.Boston: McGraw-Hill, 2002.

[17] JAMES A SENN, “Análisis y Diseño de Sistema de Información”, Mc Graw Hill,

Enero 1990.

[18] LEHTOLA, L. & Patrik Berander *, Kashif Ahmed Khan. “Towards a Research

Framework on Requirements Prioritization”. Paper, Helsinki University of

Technology.

[19] JACKSON, M. “Software Requirements and Specifications”, Addison-Wesley,

2001.

[20] IEEE Std 610.12.-1990 IEEE “Standard Glossary of Software Engineering

Terminology”.

[21] DAVIS, A. M. “Software Requirements: Objects, Functions, and States”.

UpperSaddle River, NJ:Prentice Hall, 1993.

[22] CMMI Product Team, “CMMI® for Development”, Version 1.3. Carnegie

Mellon, 2010.

[23] JIM HEUMAN. “The Five Levels of Requirements Management Maturity”,

2003.

102

[24] HARWELL, R., ASLAKSEN, E., HOOKS, I., MENGOT, R., PTACK, K.: “What

is a requirement?” Proceedings of the Third International Symposium of the

NCOSE. (1993) 17–24.

[25] JUNG, H. “Optimizing Value and Cost in Requirements Analysis”. IEEE

Software 15,4 (1998), 74-78.

[26] NANCY R., “Requirements Prioritization Introduction”, paper, Software

Engineering Institute, Carnegie Mellon University, September 2008.

[27] AHL, V. "An Experimental Comparison of Five Prioritization Methods."

Master's Thesis, School of Engineering, Blekinge Institute of Technology,

Ronneby, Sweden, 2005.

[28] KARSLSSON, J. "Towards a Strategy for Software Requirements Selection.

Licentiate." Thesis 513, Linköping University, October 1995.

[29] “Extreme Programming Rules.” [En Linea]. Disponible en:

http://www.extremeprogramming.org/rules.html. [Consulta: 22-Marzo-2012].

[29A] BECK, K. & Andres, C. “Extreme Programming Explained: Embrace

Change”, 2nd ed. Boston, MA: Addison-Wesley, 2004.

[30] LEFFINGWELL, D. & WIDRIG, D., “Managing Software Requirements: A Use

Case Approach”, 2nd ed. Boston, MA: Addison-Wesley, 2003.

[31] BOEHM, B. & ROSS, R. "Theory-W Software Project Management: Principles

and Examples." IEEE Transactions on Software Engineering 15, 4 (July 1989):

902-916.

[32] PARK, J.; PORT, D.; & BOEHM, B. "Supporting Distributed Collaborative

Prioritization for Win-Win Requirements Capture and Negotiation," 578-584.

Proceedings of the International Third World Multi-conference on Systemics,

Cybernetics and Informatics (SCI'99) Vol. 2. Orlando, FL, July 31-August 4, 1999.

Orlando, FL: International Institute of Informatics and Systemics (IIIS), 1999.

[33] DAVIS, A. "The Art of Requirements Triage." IEEE Computer 36, 3 (March

2003): 42-49.

103

[33A] DAVIS, A. “Just Enough Requirements Management: Where Software

Development Meets Marketing”. New York: Dorset House, 2005 (ISBN 0-932633-

64-1).

[34] MOISIADIS, F. "Prioritising Scenario Evolution." International Conference on

Requirements Engineering (ICRE 2000). June 2000.

[35] MOISIADIS, F. "A Requirements Prioritisation Tool." 6th Australian Workshop

on Requirements Engineering (AWRE 2001). Sydney, Australia, November 2001.

[36] “Marketísimo: ¿Qué es y cómo se usa el análisis conjoint?” [En linea].

Disponible en: http://marketisimo.blogspot.com/2008/06/qu-es-y-cmo-se-usa-el-

anlisis-conjoint.html. [Consulta: 29-Apr-2012].

[37] SAATY , T. L. “The Analytic Hierarchy Process”. New York, NY: McGraw-Hill,

1980.

[38] KARSLSSON, J. "Software Requirements Prioritizing," 110-116. Proceedings

of the Second International Conference on Requirements Engineering (ICRE'96).

Colorado Springs, CO, April 15-18, 1996. Los Alamitos, CA: IEEE Computer

Society, 1996.

[39] “Kano.” [En linea]. Disponible en:

http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss. [Consulta:

22-Apr-2012].

[40] PATRIK, B & ANNELIESE,A. “Engineering and Managing Software

Requirements”. Berlin, Blekinge Institute of Technology, p.p 69-94, 2005.

[41] YEH, A. Requirements Engineering Support Technique (REQUEST): A Market

Driven Requirements Management Process. Proceedings of the Second

Symposium of Quality Software Development Tools, IEEE Computer Society

Press, pp. 211-223, 1992

[42] VIGGO AHL. An experimental comparison of five prioritization methods.

Master Thesis, August 2005.

104

ANEXO A. ENCUESTA PARA EL ESTUDIO DE CONTEXTO; DIAGNOSTICO

DE PROCESOS PARA PRIORIZACIÓN DE REQUISITOS.

UNIVERSIDAD DE SAN BUENAVENTURA CALI


PROGRAMA INGENIRIA DE SISTEMAS

DIAGNÓSTICO DE PROCESOS PARA PRIORIZACIÓN DE REQUISITOS

De manera especial se agradece su colaboración para responder este cuestionario. Este

instrumento hace parte de una investigación sobre la aplicación de métodos y técnicas de

priorización de requisitos en las empresas de la industria del software, con el fin de hacer una

caracterización en cuanto a la investigación mencionada. La información suministrada será

tratada con la confidencialidad pertinente.

Fecha (dd/mm/aaaa)

Nombre de la Empresa

Nombre del encuestado

Cargo

e-mail

Telefono(s)

I. Información general de la organización de la empresa

1. Marque con una X el tamaño de su empresa de acuerdo a: a. Ingenieros relacionados con las actividades de desarrollo de software

a. 1 a 3 b. 4 a 7

c. 8 a 15 d. 16 a 40

e. 40 ó más

2. ¿Cuántos productos de software tiene su empresa? _____________________________________

105

3. ¿Cuál es su actividad principal?

a. Desarrollo de software genérico

b. Desarrollo de software hecho a la medida

4. ¿Cuántos clientes tiene actualmente la empresa? ____________

5 ¿Cuál(es) de los siguientes modelos ha implementado su organización en los últimos 3 años?

Seleccione todos los que aplican.

a. CMM-SW b. CMMI c. SPICE d. ISO 9001 e. PSP/TSP f. No ha implementado g. No sabe h. Otros, ¿Cuál?____________

II. Información sobre la aplicación de métodos de priorización de requisitos

6. De la cartilla adjunta identifique cuál(es) método(s) de priorización de requisitos aplica. Marque con una X.

a. ____ b. ____ c. ____

¿Aplica alguno(s) en especial que no están en la cartilla?

________________________________________

________________________________________

________________________________________

¿De los métodos de la cartilla cuál(es) en particular le gustaría aplicar?

________________________________________

________________________________________

________________________________________

7. ¿Conoce algún método distinto a los nombrados en la cartilla que sea utilizado por alguna compañía y que haya tenido éxito?

106

a. NO b. SI

Si su respuesta es SI, por favor descríbala a continuación.

MUCHAS GRACIAS POR SU VALIOSA PARTICIPACIÓN

107

CARTILLA DE DOCUMENTACION DE LOS DIFERENTES METODOS DE PRIORIZACIÓN

DE REQUISITOS

METODOS DE AGRUPACIÓN

Método Descripción

Priorización por Agrupación.

Técnica de Asignación de

Peso Numérico (Numeral

Assignment Technique)

[Brackett]

Esta técnica asigna un valor (puntuación) a cada requisito,

adicionalmente los requisitos se dividen en 3 grupos:

Obligatorios, deseables y no esenciales [Brackett]. Los

participantes asignan a los requisitos un número dentro de la

escala de 1 a 5 indicando la importancia de cada uno de ellos

[Karlsson]. Los números en la escala tienen el siguiente

significado:

El cliente no lo necesita.

No es importante.

Bastante importante (Si lo tiene el cliente lo agradece).

Es muy importante (El cliente lo desea).

Es obligatorio (El cliente no puede prescindir de él).

La clasificación final es el promedio de las clasificaciones de todos

los participantes para cada uno de los requisitos.

Top Ten Requirement Cada interesado selecciona los 10 requisitos más importantes

desde su punto de vista. Los requisitos seleccionados por todos

los Stakeholders en su lista de 10, son también considerados los

más importantes.

METODOS MIXTOS COMBINATORIOS


AHP

Este método utiliza 2 matrices para calcular el valor y los costos

relativos de los requisitos entre si. Mediante el uso de AHP el

ingeniero de requisitos puede confirmar la consistencia de los

resultados. AHP puede ayudar a evitar errores generados de

juicios subjetivos e incrementar la probabilidad de que los

resultados sean fiables. El método AHP consta de 5 pasos :

Revisar los requisitos candidatos y completarlos enteramente.

Aplicar el método de comparación por pares para evaluar




108

el valor relativo de cada uno de los requisitos candidatos.

Aplicar el método de comparación por pares para evaluar el costo relativo de los requisitos candidatos.

Calcular el valor relativo de cada requisito candidato y el costo de su implementación y poder hacer seguimiento en un diagrama de costo – valor.

Usar el diagrama de costo – valor como un mapa que permita analizar los requisitos candidatos.

a. Bastante importante (Si lo tiene el cliente lo agradece).

b. Es muy importante (El cliente lo desea). c. Es obligatorio (El cliente no puede prescindir de

él).

La clasificación final es el promedio de las clasificaciones de todos los participantes para cada uno de los requisitos.

Hierarchy AHP Es una modificación del AHP, en el cual solo los requisitos del

mismo nivel de jerarquía son comparados con los demás.

Cost Value Approach Está basado en el Método AHP, donde todos los requerimientos

son comparados de acuerdo a su importancia y costo de

implementación.

Ordinal Cost Value Approach Los requisitos son puesto en 3 grupos de acuerdo a la importancia

del cliente y en 3 grupos de acuerdo al costo de implementación.

Los resultados son presentados en un diagrama de dispersión de

costo-valor.

Planing Game [Beck] Es una técnica utilizada por el Método de desarrollo de software

Extreme Programming [Beck] y se utiliza con los clientes para

priorizar los requisitos basado en historietas. Esta es una

variación de la técnica de asignación numérica donde el cliente

distribuye los requisitos en tres grupos, "aquellos sin los cuales el

sistema no funcionará", "los que son menos esenciales, pero

proporcionan un importante valor empresarial", y "los que sería

bueno tener. "

Wieger´s Method [Wiegers]. Este método se relaciona directamente con el valor de cada

requisito de un cliente [Wiegers]. La prioridad se calcula

dividiendo el valor de una obligación por la suma de los costos y

riesgos técnicos asociados a su aplicación [Wiegers]. El valor de

una obligación se considera como función tanto en el valor

proporcionado por el cliente para el cliente y la pena que se

produce si el requisito falta. Esto significa que los desarrolladores

deben evaluar el costo de la exigencia y sus riesgos de

implementación, así como la penalidad si el requisito falta. Los

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Beck

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Beck

109

atributos son evaluados en una escala de 1 a 9.

Impact Validation El impacto que cada requerimiento propuesto tiene sobre el logro

en el nivel más alto del proyecto es evaluado sobre una escala

definida, los requerimientos con mayor impacto son vistos como

los más importantes.

METODOS DE VOTACIÓN


$100 Test (Acumulative

Mtehod) [Leffingwell]

El método de los 100 puntos es básicamente un esquema de tipo

votación que es usada en ejercicios de lluvia de ideas. A cada

interesado se le dan 100 puntos que él o ella puedan utilizar

para votar por los requisitos que considere más importantes, el

interesado puede usarlos de la manera que él considere más

pertinente. Por ejemplo si existen 4 requisitos que él considera

son igual de prioritarios, entonces el podrá darle a cada uno 25

puntos. Si existe un requisito que él considera que de

importancia primordial podría darle los 100 puntos.

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/545-BSI.html#dsy545-BSI_Leff

110

ANEXO B. DOCUMENTO DE ANÁLISIS Y DISEÑO DE LA APLICACIÓN

“PGWITHWIEGER”.




111

ÍNDICE GENERAL

Pág.

INTRODUCCIÓN 113

1. DEFINICIÓN DEL PROBLEMA 114

2. ACTORES DEL SISTEMA 115

2.1 JEFE DEL PROYECTO 115

2.2 REPRESENTANTE DE LOS DESARROLLADORES 115

2.3 REPRESENTANTE DE LOS CLIENTES 115

2.4 SISTEMA 115

3. REQUISITOS FUNCIONALES 116

3.1 LISTA DE REQUISITOS 116

3.1.1 EL SISTEMA DEBE PERMITIR 116

4. CASOS DE USO DEL SISTEMA 117

4.1 LISTADO DE CASOS DE USO 117

5. CASOS DE USO EXPANDIDOS 119

5.1 CASOS DE USO 119

112

6. DIAGRAMA DE CASOS DE USO DEL SISTEMA 130

6.1 REPRESENTANTE DE LOS CLIENTES 130

6.2 JEFE DEL PROYECTO 130

6.3 SISTEMA 133

6.4 PANTALLAS DEL SISTEMA 134

7. MODELO DE ENTIDAD DE RELACIÓN 138

113

Universidad de San Buenaventura

Cali - Colombia.

Documento de análisis y diseño de la aplicación “PGwithWieger”.

INTRODUCCIÓN

El presente es el documento de análisis y diseño para la construcción de un

sistema de priorización de requisitos que combina dos técnicas (PG, Wieger´s

Method) reconocidas por la industria y validadas en el documento base “Validación

y Aplicación de técnicas de priorización de requisitos”.

Versión Fecha Autor(es) Descripción

1.0 05/03/2012 Jhonny Gómez

Chalacán

Construcción del documento de análisis y diseño

para el sistema PGwithWieger.

2.0 30/04/2012 Jhonny Gómez

Chalacán

Modificación y desarrollo de última versión del

documento de análisis y diseño para el sistema

PGwithWieger.

114

1. DEFINICIÓN DEL PROBLEMA

En el Desarrollo de requisitos de software un factor determinante es la gestión de

los mismos y a su vez la priorización y planificación, dicha priorización es un factor

de éxito que determina la óptima utilización de los recursos tiempo, costos y factor

humano para una efectiva culminación del producto esperado.

La evidente necesidad de contar con un método que nos permita realizar una

optima priorización y planificación de los requisitos de software, abre las puertas

para aportar en el proceso de ingeniería de software una propuesta metodológica,

la cual llene el vació que hoy no cobijan algunas metodologías ó estándares en

los cuales se aborda el tema de la priorización como una actividad del desarrollo

de requisitos de software pero no se enfatiza en el ¿cómo?, es decir, se plantea el

hecho de priorizar, pero no se deja claro el cómo se debe priorizar, dejando de

alguna manera al libre albedrío del líder de desarrollo (o del proyecto) , una

actividad tan importante como la priorización de los requisitos, donde en ultimas,

se utiliza más que la técnica su propia experticia.

115

2. ACTORES DEL SISTEMA

2.1 JEFE DEL PROYECTO

Gestionar usuarios y sus roles.

Gestiona requisitos y ajusta los aportes de los demás participantes en la

priorización.

2.2 REPRESENTANTE DE LOS DESARROLLADORES

Gestiona requisitos y ajusta los aportes de los demás participantes en la

priorización.

Suministra las puntuaciones para el costo y el riesgo.

2.3 REPRESENTANTE DE LOS CLIENTES

Suministra las puntuaciones para el beneficio y la penalidad.

2.4 SISTEMA

Se encarga de listar automáticamente los requisitos, usuarios, categorías,

roles, tipos de requisitos, proyectos.

116

3. REQUISITOS FUNCIONALES

Un requisito funcional es aquel que permite de cierta manera saber que funciones

debe realizar el software a realizar; Además de saber los límites del mismo.

3.1 LISTA DE REQUISITOS

3.1.1 El sistema debe permitir

1. Gestionar proyectos.

2. Gestionar requisitos.

3. Gestionar usuarios.

4. Gestionar cuentas de usuario.

5. Gestionar tipo de cuentas

6. Gestionar categorías de requisitos.

7. Gestionar tipos de requisitos.

8. Catalogar requisitos.

9. Asignar valores a los requisitos (Costo relativo, Penalidad relativa, Riesgo

relativo, Beneficio Relativo).

10. Asignar peso (o influencia) que cada factor de valorización tiene en el proyecto.

11. Priorizar requisitos por categoría.

12. Listar los requisitos priorizados.

13. Listar requisitos.

117

4. CASOS DE USO DEL SISTEMA

4.1 LISTADO DE CASOS DE USO

1. Modificar Proyecto.

2. Crear proyecto

3. Inactivar Proyecto

4. Activar Proyecto

5. Consultar Proyecto

6. Listar Proyectos

7. Crear Requisitos

8. Modificar Requisitos

9. Eliminar Requisitos

10. Consultar Requisitos

11. Listar requisitos

12. Crear categorías de requisitos

13. Modificar categorías de requisitos

14. Eliminar categorías de requisitos

15. Consultar categorías de requisitos

16. Listar Categorías de requisitos

17. Crear tipos de requisitos

18. Modificar tipos de requisitos

19. Eliminar tipos de requisitos

20. Consultar tipo de requisitos

21. Listar tipos de requisitos

22. Calcular valor total

23. Calcular Costo total

24. Calcular riesgo total

25. Calcular valor porcentual

26. Calcular Costo Porcentual

27. Calcular riesgo porcentual

28. Configurar influencias

29. Consultar configuración de influencias

30. Modificar configuración de influencias

31. Listar requisitos priorizados.

32. Priorizar Requisitos

33. Crear Usuario

34. Modificar Usuario

118

35. Consultar Usuario

36. Inactivar usuario

37. Activar usuario

38. Listar usuarios

39. Crear rol de usuario

40. Consultar rol de usuario

41. Listar rol de usuario

42. Eliminar rol de usuario

43. Crear cuenta

44. Modificar cuenta

45. Consultar cuenta

46. Inactivar cuenta

47. Activar cuenta

48. Log In

49. Log Out

119

5. CASOS DE USO EXPANDIDOS

A continuación se exponen 5 guiones los cuales se definen como un CRUD y un

caso de uso del negocio.

5.1 CASOS DE USO

7 Crear requisito

8 Modificar requisito

9 Eliminar requisito

10 Consultar requisito

32 Priorizar requisitos

No. 1 CU_07_CREAR_REQUISITO

Nombre Crear requisito

Descripción Crea un nuevo requisito asociado a un proyecto

Actores Jefe del proyecto, Representante de los desarrolladores

Fase Análisis

Guión

Actor Sistema

1 Ingresa el código del

proyecto

2 Consulta si existe el proyecto

3 Ingresa código del requisito 4 Consulta si el requisito existe.

5 Ingresa nombre del requisito

6 Ingresa el código del Tipo

de requisito

7 Consulta si existe el tipo de

requisito.

8 Ingresa el código de la

categoría de requisito.

9 Consulta si existe la categoría.

10 Ingresa la descripción

11 Ingresa valor del beneficio

relativo.

12 Valida que sea numérico, mayor a

cero y se encuentre en un rango de

1 a 10.

120

13 Ingresa valor del Costo

relativo.



1 a 10.

15 Ingresa valor de la

penalidad relativa.



1 a 10.

17 Ingresa valor del Riesgo

relativo.



1 a 10.

19 Almacena información del

requisito.

Excepciones

1. Proyecto no existe

Nombre Mensaje

Paso 2

1. Si no existe un proyecto con el código

digitado. Se despliega el siguiente

mensaje “No existe un proyecto con el

código xxxxx”.

2. Se despliega el mensaje “¿Desea

crear un nuevo proyecto?”

3. si la respuesta es afirmativa,; Llama al

caso de uso CREAR PROYECTO.

4. Vuelve al paso 1.

2. El requisito existe.

Nombre Mensaje

Paso 4

1. Se despliega la información del

requisito.

3. Tipo de requisito no existe.

Nombre Mensaje

Paso 7

1. Si no existe un tipo de requisito con el

código digitado. Se despliega el

siguiente mensaje “No existe un tipo

de requisito con el código xxxxx”.


crear un nuevo tipo de requisito?”


caso de uso CREAR TIPO DE

REQUISITO.


4. Categoría no existe.

121

Nombre Mensaje

Paso 9

1. Si no existe una categoría con el


siguiente mensaje “No existe una

categoría con el código xxxxx”.


crear una nueva categoría?”


caso de uso CREARCATEGORIA.


5. Valor no numérico, no mayor a cero.

Nombre Mensaje

Paso 12,14,16,18

1. Si el valor ingresado no es numérico,

menor o igual a cero. Se despliega el

mensaje “El valor debe ser numérico

mayor a cero.”

2. Vuelve al paso 11,13,15,17

respectivamente

6. Valor fuera del rango.

Nombre Mensaje

Paso 12,14,16,18

1. Si el valor ingresado se encuentra

fuera del rango. Se despliega el

mensaje “El valor debe tener valores

entre 1 - 10.”


respectivamente

Casos de uso

relacionados

Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de

requisito, consultar categoría, Crear Categoría, Consultar requisito.

Documentos

Relacionados

Especificación de requisitos.

Requerimiento

Fuente

Gestionar requisitos

Autor Jhonny Gómez Chalacán

Revisado por

Fecha

Creación

Marzo 06 de 2012

Fecha de

Ultima

Modificación

122

No. 2 CU_08_MODIFICAR_REQUISITO

Nombre Modificar requisito

Descripción Modifica un requisito asociado a un proyecto


Fase Análisis

Guión

Actor Sistema


proyecto



5 Ingresa nombre del requisito

6 Ingresa el código del Tipo

de requisito

7 Consulta si existe el tipo de

requisito.

8 Ingresa el código de la


9 Consulta si existe la categoría.

10 Ingresa la descripción

11 Ingresa valor del beneficio

relativo.


cero y se encuentre en un rango

de 1 a 10.

13 Ingresa valor del Costo

relativo.



de 1 a 10.

15 Ingresa valor de la

penalidad relativa.



de 1 a 10.

17 Ingresa valor del Riesgo

relativo.



de 1 a 10.

19 Actualiza información del requisito.

123

Excepciones


Nombre Mensaje

Paso 2




código xxxxx”.



3. si la respuesta es afirmativa; Llama al



2 El requisito no existe.

Nombre Mensaje

Paso 4

1. No se despliega ningún tipo de

información.


Nombre Mensaje

Paso 7



siguiente mensaje “No existe un tipo

de requisito con el código xxxxx”.


crear un nuevo tipo de requisito?”

3. si la respuesta es afirmativa; Llama al


REQUISITO.



Nombre Mensaje

Paso 9

1. Si no existe una categoría con el


siguiente mensaje “No existe una

categoría con el código xxxxx”.


crear una nueva categoría?”




124

5. Valor no numérico, no mayor a cero.

Nombre Mensaje

Paso 12,14,16,18

1. Si el valor ingresado no es numérico,

menor o igual a cero. Se despliega el

mensaje “El valor debe ser numérico

mayor a cero.”


respectivamente

6. Valor fuera del rango.

Nombre Mensaje

Paso 12,14,16,18

1. Si el valor ingresado se encuentra

fuera del rango. Se despliega el

mensaje “El valor debe tener valores

entre 1 - 10.”


respectivamente

Casos de uso

relacionados

Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de

requisito, consultar categoría, Crear Categoría, Consultar requisito.

Documentos

Relacionados


Requerimiento

Fuente



Revisado por

Fecha

Creación

Marzo 06 de 2012

Fecha de

Ultima

Modificación

No. 3 CU_9_ELIMINAR_REQUISITO

Nombre Eliminar requisito

Descripción Elimina un requisito asociado a un proyecto


125

Fase Análisis

Guión

Actor Sistema


proyecto



5 Borra información del requisito.

6 Actualiza información.

Excepciones


Nombre Mensaje

Paso 2




código xxxxx”.






2. El requisito no existe.

Nombre Mensaje

Paso 4


información.

Casos de uso

relacionados

Consultar proyecto, Crear Proyecto, Consultar requisito.

Documentos

Relacionados


Requerimiento

Fuente



Revisado por

Fecha

Creación

Marzo 06 de 2012

Fecha de

Ultima

Modificación

126

No. 4 CU_10_CONSULTAR_REQUISITO

Nombre Eliminar requisito

Descripción Consulta un requisito asociado a un proyecto


Fase Análisis

Guión

Actor Sistema


proyecto


3 Ingresa código del requisito 4 Despliega la información del

requisito.

Excepciones


Nombre Mensaje

Paso 2




código xxxxx”.






2. El requisito no existe.

Nombre Mensaje

Paso 4


información.

Casos de uso

relacionados

Consultar proyecto, Crear Proyecto.

Documentos

Relacionados


Requerimiento

Fuente



127

Revisado por

Fecha

Creación

Marzo 06 de 2012

Fecha de

Ultima

Modificación

No. 5 CU_32_PRIORIZAR_REQUISITOS

Nombre Priorizar requisitos

Descripción A partir de los valores en beneficio relativo, costo relativo, penalidad relativa,

riesgo relativo, se debe calcular la prioridad de cada uno de los requisitos en el

proyecto.


Fase Análisis

Guión

Actor Sistema

1. Ingresa el código del

proyecto

2. Consulta si existe el proyecto

3. Ingresa el código del Tipo

de requisito

4. Consulta si existe el tipo de

requisito.

5. Ingresa el código de la


6. Consulta si existe la categoría.

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

128

multiplicaciones en el

paso 14 y 15.

17. Actualizar información

18. Listar Requisitos priorizados.

Excepciones


Nombre Mensaje

Paso. 2




código 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 código xxxxx”.


un nuevo tipo de requisito?”



REQUISITO.



Nombre Mensaje

Paso 6

5. Si no existe una categoría con el código


mensaje “No existe una categoría con

el código xxxxx”.


una nueva categoría?”




129

Casos de uso

relacionados

1. Consultar requisitos







8. Consultar Proyectos

9. Consultar Categorías

10. Consultar Tipos de requisito

Documentos

Relacionados

Especificación de requerimientos.

Requerimiento

Fuente

Priorizar requisitos


Revisado por

Fecha Creación Marzo 06 de 2012

Fecha de Ultima

Modificación

130

6. DIAGRAMA DE CASOS DE USO DEL SISTEMA

6.1 REPRESENTANTE DE LOS CLIENTES

6.2 JEFE DEL PROYECTO

133

Nota: El Representante de los desarrolladores tiene relacionados los mismos

casos de uso que el Jefe del Proyecto, a diferencia que no puede crear nuevos

usuario, cuentas, ni roles.

6.3 SISTEMA

134

6.4 PANTALLAS DEL SISTEMA

Gestión de categorías

Priorización

135

Gestión de proyectos

136

Gestión de requisitos

137

Gestión de requisitos

138

7. MODELO DE ENTIDAD DE RELACIÓN

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

Documents

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