referencias - Ingeniería de Sistemas | Pontificia Universidad Javeriana

CIS0830IS16
GUÍA PARA INTERACTUAR CON STAKEHOLDERS EN EL PROCESO DE INGENIERÍA DE
REQUERIMIENTOS
http://pegasus.javeriana.edu.co/~CIS0830IS16
CARLOS ALEJANDRO MERA AMEZQUITA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
BOGOTÁ, D.C
2010
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
CIS0830IS16
GUÍA PARA INTERACTUAR CON STAKEHOLDERS EN EL PROCESO DE INGENIERÍA DE
REQUERIMIENTOS
http://pegasus.javeriana.edu.co/~CIS0830IS16
Autor:
Carlos Alejandro Mera Amezquita
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS
REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS
Director:
Ingeniero Rafael José Barros Barrios
Jurados del Trabajo de Grado
Mónica Cepero Uribe
Juan Carlos Aldana
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
BOGOTÁ, D.C.
Mayo, 2010
II
Ingeniería de Sistemas
ISTAR - CIS0830IS16
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Luis Carlos Díaz Chaparro
Director Departamento de Ingeniería de Sistemas
Ingeniero César Julio Bustacara Medina
III
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica
y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos
el anhelo de buscar la verdad y la Justicia
IV
Ingeniería de Sistemas
ISTAR - CIS0830IS16
AGRADECIMIENTOS
Agradezco a Lucila Amezquita mi madre y a Carlos Mera mi padre, por su eterno apoyo y esfuerzo,
su valentía y paciencia para enfrentar la vida, me dieron fuerzas para enfrentar este reto y tener
claro que todo en la vida se logra con esfuerzos. A ellos infinitas gracias.
A la familia Álvarez Rodríguez por su gran apoyo y acogida en su familia, y en especial a Andrea
Álvarez (Mi muñeca) por su amor, entendimiento, oraciones y apoyo incondicional para enfrentar
todo este proceso.
A la Familia Sánchez Torres, Don Nelson (Q.E.P.D), Doña Myriam, Dani, Arthurito y Nilson por
su eterna confianza y apoyo, Muchas gracias.
Agradezco especialmente a mi director de trabajo de grado Ingeniero Rafael Barros, por su
paciencia y regaños a su manera; lo cuales hicieron que a la distancia observara la investigación de
este trabajo de grado de manera sencilla y así lograra alcanzar los objetivos. Sin sus apreciaciones
esta investigación y trabajo no se hubiera podido culminar.
Por último agradezco a cada uno de mis amigos y compañeros, por creer en mí y por cada uno de
los consejos que recibí de parte cada uno de ellos cuando tuve un inconveniente, mil gracias.
V
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
CONTENIDO
LISTADO DE FIGURAS ............................................................................................................... IX
LISTADO DE TABLAS ................................................................................................................... X
ABSTRACT ..................................................................................................................................... XI
RESUMEN....................................................................................................................................... XI
RESUMEN EJECUTIVO ............................................................................................................. XII
INTRODUCCIÓN ...............................................................................................................................1
1.
2.
DESCRIPCION GENERAL DEL TRABAJO DE GRADO .......................................................2
1.2
Oportunidad o Problemática. ...............................................................................................2
1.3
Formulación .........................................................................................................................6
DESCRIPCIÓN DEL PROYECTO.............................................................................................7
2.1
Visión Global .......................................................................................................................7
2.2
Justificación .........................................................................................................................7
2.3
Objetivo General ..................................................................................................................7
2.4
Objetivos Específicos...........................................................................................................7
2.5 Metodología Propuesta ..............................................................................................................8
3.
MARCO TEÓRICO ...................................................................................................................11
3.1
Ingeniería de Requerimientos ............................................................................................11
3.1.1
¿Qué es un Requerimiento? .......................................................................................12
3.1.2
Tipos o clases de Requerimientos ..............................................................................12
3.1.3
Proceso de Ingeniería de Requerimientos ..................................................................13
3.1.4
Obtención de requerimientos .....................................................................................17
3.1.6
Especificación de Requerimientos .............................................................................25
VI
Ingeniería de Sistemas
3.1.7
ISTAR - CIS0830IS16
Validación de Requerimientos ...................................................................................25
3.2
Tecnologías de Información...............................................................................................25
3.3
Trabajos relacionados ........................................................................................................26
3.3.1
Metodología DoRCU para la Ingeniería de Requerimientos .....................................26
3.3.2
Definición de una metodología ágil de ingeniería de requerimientos para empresas
emergentes de desarrollo de software del sur-occidente colombiano ........................................27
4.
5.
3.3.3
Guía Metodológica para la recolección de requerimientos a distancia ......................28
3.3.4
La negociación en la obtención de requisitos y el proceso de análisis ......................29
3.3.5
Otros...........................................................................................................................29
PROCESO..................................................................................................................................30
4.1
Desarrollo de la investigación ............................................................................................30
4.2
Reflexión Metodológica.....................................................................................................31
RESULTADOS Y RECOMENDACIONES .............................................................................32
5.1
Plantilla para describir herramientas o técnicas de levantamiento de información ...........32
5.2
Descripción de 7 Técnicas de levantamiento de información con la plantilla ...................33
5.3
Estrategias de negociación .................................................................................................37
5.4
Guía para identificar y negociar requerimientos con Stakeholders....................................37
5.4.1
INTRODUCCIÓN .....................................................................................................37
5.4.2
Conocimiento de la Organización y el Proyecto ........................................................38
5.4.3
Identificación de Stakeholders ...................................................................................42
5.4.4
Selección de técnicas de levantamiento de información ............................................45
5.4.5
Identificación de intereses y conflictos. .....................................................................53
5.4.6
Selección de la técnica o estrategia de negociación ...................................................58
5.5
Caso de estudio ..................................................................................................................60
5.5.1
Escenario ....................................................................................................................60
VII
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
6.
5.5.2
Desarrollo ...................................................................................................................60
5.5.3
Proceso .......................................................................................................................62
CONCLUSIONES Y TRABAJOS FUTUROS .........................................................................64
6.1
Conclusiones ......................................................................................................................64
6.2
Trabajos Futuros ................................................................................................................65
GLOSARIO .......................................................................................................................................66
REFERENCIAS .................................................................................................................................67
ANEXOS ...........................................................................................................................................74
VIII
Ingeniería de Sistemas
ISTAR - CIS0830IS16
LISTADO DE FIGURAS
Figura 1 – Proceso de Ingeniería de Requerimientos según Sommerville y Kotonya tomado de [58]
...........................................................................................................................................................14
Figura 2 - Áreas de Conocimiento de Requerimientos de Software tomado de [51] .........................14
Figura 3 - Proceso de Ingeniería de Requerimientos según Macaulay tomado de [58] .....................15
Figura 4 - Proceso de Ingeniería de Requerimientos según Loucopoulos y Karakostas tomado de
[58] .....................................................................................................................................................15
Figura 5 - Proceso de Ingeniería de Requerimientos según Volere tomado de [61] ..........................16
Figura 6 - Proceso de Ingeniería de Requerimientos según Sommerville tomado de [38] ................17
Figura 7 - Relación entre los interesados y el proyecto según PMBOK tomado de [17] ..................19
Figura 8 - Clasificación según Wiegers tomada de [66] ....................................................................20
Figura 9- Potenciales Stakeholders según Contrux tomado de[67] ...................................................20
Figura 10 - Elementos principales en la identificación de personas interesadas tomado de [8] .......21
Figura 11 - Modelo de cebolla de las relaciones de las persona interesadas tomado de [9] .............22
Figura 12 - Modelos de cebolla desde la perspectiva de Volere tomado de [61] ..............................23
Figura 13 - Esquema Metodológico propuesto por DoRCU tomado de [63] ....................................27
Figura 14 - Estructura de la metodología ágil para el proceso de ingeniería de requerimientos
tomado de [64] ...................................................................................................................................28
Figura 15 - Plantilla de descripción de técnicas de levantamiento de información ...........................33
Figura 16 - Apprenticing en BPMN ...................................................................................................34
Figura 17 - Card Sorting en BPMN ...................................................................................................34
Figura 18 - Domain Anlysis ...............................................................................................................35
Figura 19 - Sesiones JAD en BPMN .................................................................................................35
Figura 20 - Protocol Analysis ............................................................................................................36
Figura 21 - Task Analysis en BPMN .................................................................................................36
Figura 22 -ViewPoints en BPMN ......................................................................................................37
Figura 23- Pasos de la Guía ...............................................................................................................38
IX
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
LISTADO DE TABLAS
Tabla 1- Objetivos en contraste con la Metodología # 1 .....................................................................8
Tabla 2 - Objetivos en contraste con la Metodología # 2 ....................................................................9
Tabla 3 - Objetivos en contraste con la Metodología # 3 ..................................................................10
Tabla 4 - Clasificación de requerimientos según [19] .......................................................................13
Tabla 5 - Selección de Técnicas de acuerdo al tiempo y tipo de Persona o Grupo............................47
Tabla 6 - Ejemplo lista de general de intereses ..................................................................................55
Tabla 7 - Ejemplo de agrupación de intereses ...................................................................................56
Tabla 8 - Identificación de conflictos ................................................................................................57
X
Ingeniería de Sistemas
ISTAR - CIS0830IS16
ABSTRACT
Information Technologies are an important place in the development of the economic activities
worldwide, reason for which the industries and governments face to diary the project development
in this area. In this type of projects it is found that one of the reasons of failure is the poor
specification of requirements, is because of it that a guide proposes the following work of degree to
identify and to negotiate requirements in this type of projects. The aims guide is to help
requirements analysts who do not have enough experience in such projects, guiding them specially
in the use of technologies of compilation of information and the forms and methods that they can
use in the activities of negotiation of requirements.
RESUMEN
Las tecnologías de la información y comunicación ocupan un lugar importante en el desarrollo de
las actividades económicas a nivel mundial, razón por la cual las industrias y gobiernos enfrentan a
diario el desarrollo de proyectos en esta área. En este tipo de proyectos se establece que una de las
razones de fracaso es la pobre especificación de requerimientos, es por eso que el siguiente trabajo
de grado propone una guía para identificar y negociar requerimientos en este tipo de proyectos. La
guía tiene el objetivo de ayudar a los analistas de requerimientos que no posean la suficiente
experiencia en este tipo de proyectos, guiándolos especialmente en el uso de técnicas de recolección
de información y las formas y métodos de las que pueden hacer uso en las actividades de
negociación de requerimientos.
XI
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
RESUMEN EJECUTIVO
El desarrollo a nivel mundial de las tecnologías de información y comunicación ha impulsado a las
organizaciones a hacer uso de estas, en pro de buscar la unificación de los procesos de negocio que
hacen parte de la misma. El flujo de información dentro de las organizaciones está en aumento y las
restricciones de espacio y tiempo están dejando de ser un obstáculo para el desarrollo de las
actividades propias de la organización gracias al uso de la tecnología[45]. A su vez el mundo
enfrenta cada día obstáculos de carácter económico que afectan directamente a las organizaciones,
debido a que estas buscan la manera de enfrentar dichos impactos con el uso de sistemas de
información que contribuyan a desarrollar estrategias que impacten en las finanzas de las
organizaciones y genere nuevas oportunidades de negocio o el balance económico, que se desea
para afrontar los obstáculos.
En ese orden de ideas las organizaciones están desarrollando cada día proyectos donde las
tecnologías de información son la pieza fundamental para enfrentar las necesidades de las
organizaciones o gobiernos, estas saben que el estar bajo la vanguardia de la tecnología le permitirá
estar conectando con este mundo que busca estar cada vez más globalizado.
El desarrollo de estos proyectos se logra gracias a la intervención de las personas, que logran
identificar cuáles son las necesidades o problemas que requieren ser resueltos a través de las
tecnologías de información. Para ello se denota que cada vez, se desarrollan nuevos sistemas de
información o sistemas de software que permitan darle solución a las necesidades o problemáticas,
pero así como se inician cada vez más proyectos, se denota según [13], que el 13.1% de los
proyectos no logran el objetivo y son cancelados; debido a requerimientos incompletos, también
los proyectos son cambiados en un 12.3 % debido a una incompleta especificación de
requerimientos. Se sabe de antemano que dichos requerimientos son basados en las necesidades e
intereses de las personas que integran las organizaciones, es por eso que el siguiente trabajo de
grado se enfoca en guiar a los analistas de requerimientos en las etapas de obtención y negociación
de requerimientos que hacen parte del proceso de ingeniera de requerimientos usado en la ingeniería
de software.
XII
Ingeniería de Sistemas
ISTAR - CIS0830IS16
El objetivo es proponer una guía que ayude a las personas que no tienen la suficiente experiencia en
levantamiento de requerimientos, para poder hacer mejor uso de las técnicas de levantamiento de
información que se usan comúnmente en este tipo de proyectos y el poder enfrentar la etapa de
negociación de requerimientos, que de cómo resultado una ayuda en la especificación de
requerimientos.
Para poder concebir esta guía se procedió a realizar una investigación acerca de la forma en que se
obtiene la información acerca de las organizaciones, sus procesos de negocio y sus problemas, lo
cual llevo a que se indagara lo referente a las diferentes técnicas de levantamiento de información
usadas por la industria y la academia. En ese orden ideas se propuso una plantilla para la
descripción de las técnicas de levantamiento de información, en donde se puede explicar la manera
y forma en que se deben desarrollar una técnica de levantamiento de información. Para la
elaboración de la plantilla se hizo con un Mapa Mental y la ayuda de BPMN 1 para la explicación de
la forma en que debe ser desarrollada la misma. Concebida la plantilla, se procedió a realizar la
descripción de algunas técnicas, esto con el objetivo de profundizar el conocimiento en algunas
técnicas de levantamiento de información no convencionales.
Tras el análisis de las técnicas de levantamiento de información, se investigo acerca de la manera y
forma en que se negocian los requerimientos en los proyectos. En donde se desarrolló un
documento que describe la importancia de la negociación en la fase de análisis de requerimientos.
Este documento resume la importancia de los principales métodos y modelos usados para el
desarrollo de esta actividad.
Seguido se desarrolló y probo una guía enfocada en los analistas de requerimientos que no tienen la
experiencia necesaria en la recopilación de información y negociación de requerimientos, la cual
ayuda a una buena especificación de requerimientos de software, esta propone una clasificación de
proyectos que conduce y aconseja al analista de requerimientos hacer uso de las diferentes técnicas
de requerimientos y propone el uso de determinadas estrategias para la negociación de conflictos e
intereses.
1
BPMN: Business Process Management Notation, para mayor información remítase a http://www.bpmn.org/
XIII
Ingeniería de Sistemas
ISTAR - CIS0830IS16
INTRODUCCIÓN
El estudio y la investigación en áreas como la Gerencia de proyectos, la Ingeniería de Software
entre otros han permitido que se desarrollen todo tipo de proyectos, que ayuden a las organizaciones
desarrollar sistemas que contribuyan a mejorar los procesos de trabajo y comunicación de las
mismas.
A medida que surgen nuevos sistemas, estos buscan la satisfacción de las necesidades de personas
que forman parte de los procesos de la organización. Cambiar dichas necesidades de acuerdo al
desarrollo de nuevas tecnologías y de los nuevos desafíos que presentan las organizaciones a nivel
mundial. Dichas necesidades son las bases más importantes en el desarrollo de proyectos, es por eso
que la Ingeniería de Software ha contemplado la necesidad de hacer una buena administración a
través de la Ingeniería de Requerimientos.
La ingeniería de requerimientos contempla aspectos como la obtención o recolección, análisis,
especificación y validación. Pero se ha evidenciado que un alto porcentaje de proyectos fracasa por
una mala especificación de requerimientos[14], que es debida en gran parte a una mala recolección
de requerimientos y pobre levantamiento de información.
Con el objetivo de contribuir a una buena recolección y negociación de requerimientos en la
primera fase de los proyectos, el trabajo que se desarrolla a continuación propone una guía para
ayudar a los analistas de requerimientos que no tengan la suficiente experiencia, para saber y hacer
buen uso de las técnicas y herramientas de recolección de información y estrategias de negociación
de requerimientos.
1
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
1. DESCRIPCION GENERAL DEL TRABAJO DE GRADO
En esta sección se expone la problemática, a la cual este trabajo de grado pretende aportar una
ayuda, basándose en la Gestión de Proyectos, la Ingeniería de Software y la Ingeniería de
Requerimientos, explicando una manera sencilla de entender las diferentes técnicas de
levantamiento de información y negociación para interactuar con los diferentes Stakeholders o
personas involucradas.
1.2 Oportunidad o Problemática.
El mundo actualmente está pasando por una etapa de adaptación tecnológica. La industria de
desarrollo de software tiene el potencial necesario para convertirse en una de las industrias de alta
tecnología más dispersas y de mayor consumo a nivel mundial [11]. Por tal razón se observa a nivel
económico, que en el mundo las TIC se han convertido en un nuevo paradigma el cual sobrelleva
consecuencias para la innovación y afecta las políticas de desarrollo de los países[16]. Debido a esto
los gobiernos, instituciones o personas hacen uso del software para el manejo de la información a
todo nivel. Las últimas dos décadas nos demuestran lo anteriormente expuesto; las tasas de
crecimiento en este sector se elevaron considerablemente, así como el aumento en la propagación de
programas informáticos a nivel mundial[11]. “En la actualidad, se reconoce el impacto de estas
tecnologías en la competitividad, su potencial para apoyar su inserción en la economía globalizada
e impulsar el desarrollo económico y social de los países. Estos beneficios sólo pueden convertirse
en resultados concretos a medida que la sociedad se apropie de estas tecnologías y las haga parte
de su desempeño cotidiano”[12].
Las Tecnologías de Información y Comunicaciones han desencadenado un cambio organizado en la
forma de producir dentro de la sociedad. El uso de estas tecnologías ha generado cambios en la
forma como se produce, divulga y utiliza la información en la sociedad[1][7][12]. Debido a esto las
necesidades que tiene un gobierno, una organización o una persona específica son muy diferentes y
determinadas entre sí, dependiendo del objetivo que se quiera alcanzar.
El desarrollo de tecnologías de información avanza a pasos agigantados, cada día los diferentes
mercados presentan exigencias más altas, las cuales deben ser enfrentadas de manera acuciosa y
ordenada. Un pilar para enfrentar estos retos es el desarrollo de sistemas software que cumplan las
exigencias que nos exponen los diferentes mercados. A raíz de esto la Ingeniería de Software ha
2
Ingeniería de Sistemas
ISTAR - CIS0830IS16
contribuido para el desarrollo de sistemas software de calidad, capaces de enfrentar los retos que
actualmente presentan los mercados. Pero debido a que las necesidades cambian constantemente por
diferentes factores, que algunas veces son controlables, es aquí donde la Ingeniería de
Requerimientos contribuye a la gestión, organización y formulación de las necesidades que los
mercados pretenden resolver basados en las tecnologías de información.
Los Sistemas de Información son la herramienta de solución a muchas de las problemáticas en las
organizaciones o Gobiernos, se debe tener en cuenta que para la construcción de estos se hace uso
de conceptos, técnicas y herramientas, para el conocimiento de la organización y la información que
se piensa modelar con dichos sistemas, es aquí donde la Ingeniería de Software toma toda la
información y la convierte en software, basándose en la Ingeniería de requerimientos, con el fin de
que el software quede acorde a la información y datos de la empresa, dando cumplimiento a las
necesidades. Por ende debemos saber que un requerimiento es un atributo necesario en un sistema,
el cual identifica una capacidad, característica, o factor de calidad de un sistema para que tenga
valor y utilidad para un cliente o usuario. Su vital importancia radica en que proporcionan la base
para todo el desarrollo del trabajo, que sigue, después de su levantamiento. Una vez que han sido
establecidos, los desarrolladores y demás personas involucradas en el proceso, continúan con los
trabajos técnicos: sistema de diseño, desarrollo, ensayo, aplicación, y funcionamiento[2].
De acuerdo con lo anteriormente expuesto los requerimientos de negocio y de software que se
logren obtener, son cruciales para cada proyecto, ya que cada uno de estos proyectos tiene éxito o
no de acuerdo a la calidad de los requerimientos que se planteen.
Las exigencias son promovidas por las personas, las cuales en el contexto de la Ingeniería de
software son la base para la elaboración de los requerimientos. Las personas son la principal fuente
de información para entender y llevar a cabo el desarrollo de sistemas de software, que cumplan con
estas exigencias. Es donde la Ingeniería de Requerimientos juega un papel importante; que es la de
la elaboración de requerimientos claros, completos, consistentes, factibles y verificables, que son la
hoja de ruta para el desarrollo de dichos sistemas de software.
Los requerimientos establecen el alcance del trabajo posterior y definen lo que el cliente necesita.
Sin un buen planteamiento de ellos, los proyectos fracasan, no se desarrollan en el tiempo que se
estableció, se salen del presupuesto propuesto, o producen sistemas que nunca se van a usar, y si no
3
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
son planteados de forma temprana, los problemas causados por la falta de requerimientos tienden a
ser descubiertos en el diseño y son difíciles de remediar después.
Bajo este aspecto la Ingeniería de Software da el nombre de Stakeholders a todas las personas que
se encuentren afectadas por el sistema a desarrollar. Es por esto que en la fase de Ingeniería de
Requerimientos se contempla la “elicitation” u Obtención de requerimientos[13], la cual contempla
la identificación de Stakeholders, que son la pieza más importante para una correcta elaboración de
requerimientos. Al ser personas sabemos que estas actúan y piensan de manera diferente, los cual
genera que así como tiene su forma de pensar, poseen maneras diferentes de aportar información
para una buena elaboración de requerimientos, es aquí donde se concentra la problemática, ya que
los Stakeholders son tratados de manera genérica por su rol y se deja a un lado su manera de pensar
y de interactuar con los demás Stakeholders o personas.
"La INGENIERIA DE REQUERIMIENTOS es la rama de la ingeniería de software relacionada
con los objetivos del mundo real, funciones, y limitaciones de los programas informáticos. También
se ocupa de la relación de estos factores a especificaciones precisas de comportamiento de
software, y su evolución a lo largo del tiempo y a través de las familias de software"[13]. A
continuación es indispensable mencionar a grandes rasgos el proceso de INGENIERIA DE
REQUERIMIENTOS, el cual se compone de las siguientes fases:
-
Obtención o Recolección de Requerimientos: se caracteriza por la identificación de
Stakeholders, que son todas las personas interesadas en el sistema o en alguno de
sus procesos para una necesidad en particular. También se conocen las necesidades
de los usuarios con los sistemas y sus expectativas. De la misma manera se
Identifican y formalizan los requerimientos encontrados desde las perspectiva del
analista a partir de la información recolectada.[47]
-
Análisis de requerimientos: Su principal objetivo es entender la naturaleza del
problema a modelar y comprender las relaciones con el mundo real. También es la
fase donde se evidencian los conflictos generados entre las diferentes necesidades y
requerimientos encontrados en la fase anterior. A su vez se realiza una clasificación
de las mismas. También se realiza la negoción de los requerimientos basados en los
conflictos generados entre las diferentes necesidades encontradas.[47]
4
Ingeniería de Sistemas
-
ISTAR - CIS0830IS16
Especificación de requerimientos: es la fase en la que se desarrolla los documentos
o artefactos donde se establezcan y organicen los requerimientos, con el objetivo de
revisar, evaluar y aprobar los mismos para el desarrollo de los proyectos.
Documentación formal de los requerimientos.[47]
-
Validación de requerimientos: es la fase donde se valora si los requerimientos
definen de manera adecuada las necesidades de los clientes, para la elaboración de
de sistema o solución adecuado. Es decir se realiza el proceso de evaluación por
parte de los involucrados o Stakeholders de todos los documentos y artefactos
producidos en las fases anteriores.
Dentro de este proceso, nos centramos en las fases de Obtención y Análisis de requerimientos,
requerimientos, entendiendo la importancia de la identificación de personas involucradas o
Stakeholders. Los participantes más importantes son las personas que tienen la información del
negocio o de la organización, en inglés son los llamados “Stakeholders”, dichas personas son las
que en el proceso de ingeniería de software aportan sus intereses, necesidades o requerimientos, de
tal forma que poseen a su vez la información necesaria para que dichos requerimientos sean
cumplidos a satisfacción [3]. Formalmente se definen como las personas u organizaciones que
influyen o están interesados en el proyecto, o aquellas personas que se ven afectadas por el sistema
a desarrollar[2][4]. Dicha actividad es una de las más importantes para la obtención de
requerimientos, porque la primera tarea que se debe cumplir es, mostrar los resultados que los
interesados quieren. Ellos deben estar informados y documentados, ya que de no ser así; es posible
que se cambien los puntos de vista, el alcance y los objetivos del proyecto durante su desarrollo [6].
Otra razón por la cual este proceso es importante es que las partes interesadas manifiesten la
oportunidad de decir lo que quieren o esperan del proyecto.
Todas las partes interesadas en un proyecto, sean usuarios o no, tienen necesidades sobre el
proyecto [6]. Normalmente en la identificación de personas interesadas, se consideran los clientes,
los usuarios finales del proyecto en curso, los asesores, y los grupos que están desarrollando el
sistema, a veces este paso se considera como demasiado obvio, por lo que suele ser ignorado, o no
se hace con el debido proceso, pero generalmente hay más personas interesadas de las que se piensa
que existen en un principio y no son tenidas en cuenta [3]. Aunque se dice que este proceso de
5
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
identificación es muy importante, no se describe un modelo o un enfoque concreto para la correcta
identificación de las partes interesadas para un proyecto [8].
En dicho proceso se pueden encontrar una serie de enfrentamientos entre las personas que levantan
la información y las personas que poseen la información, muchas de las técnicas usadas para el
levantamiento de información no son lo suficientemente efectivas para determinado grupo de
personas; como si lo son para otro grupo de personas, esto puede llegar a ser contraproducente para
el desarrollo del software, ya que por algún detalle en la información recolectada que haga falta, el
proyecto, puede deteriorase, puede acabarse o simplemente no puede llegar a un buen cierre. Se
presentan además otro tipo de inconvenientes; como el desperdicio de
tiempo en reuniones
periódicas, que no son productivas, las personas adecuadas no siempre están presentes, no es
suficiente el tiempo de preparación, no hay un enfoque en los temas reales y el tiempo de las
personas no siempre se usa de forma efectiva[3].
La investigación del Standish Group muestra que un 31,1% de los proyectos serán cancelados antes
de completarse. Otros resultados indican que el 52,7% de los proyectos tendrá un costo del 189% de
su estimación original. Por otro lado, el promedio de éxito de un proyecto es de sólo el 16,2% para
proyectos de software que se han completado a tiempo y según el presupuesto inicial. En las
grandes empresas sólo el 9% de sus proyectos están sobre el tiempo y según el presupuesto inicial.
Aun cuando estos proyectos se han completado, no reflejan ni un 10% de la especificación original
de los requerimientos[14]. Debido a esto, se observa las necesidades que se tienen en el desarrollo
de proyectos de tecnologías de información, donde se visualiza la necesidad de organizar las
técnicas y guías para un buen levantamiento de requerimientos, en base a la problemática que
observamos. Se observa que se puede diseñar una guía que contribuya a un buen levantamiento de
requerimientos enfocados en una buena recolección de información y una buena negociación de
requerimientos, con el fin generar una buena gestión de la información que provean las personas
interesadas para contribuir a un buen desarrollo de los proyectos.
1.3 Formulación
¿Cómo identificar y negociar requerimientos con Stakeholders de un proyecto de tecnologías de
información?
6
Ingeniería de Sistemas
ISTAR - CIS0830IS16
2. DESCRIPCIÓN DEL PROYECTO
2.1 Visión Global
El siguiente trabajo de investigación propone el estudio de las diferentes técnicas de recolección de
información y de las estrategias de negociación, con el objetivo de generar una serie de pasos que
oriente a las personas sobre el uso de las mismas en las fases de obtención y análisis de
requerimientos de un proyecto de tecnologías de información.
2.2 Justificación
El auge y la velocidad con la que las tecnología de información crecen, está dejando a un lado la
importancia que tiene un buen levantamiento de información y un buen manejo de conflictos, que se
generan en las primeras etapas de los proyectos y que son la base fundamental para la consecución
del mismo. Esto aduce que no se está realizando un correcto uso de la gran cantidad de técnicas,
métodos y estrategias para elaborar una correcta especificación de requerimientos.
2.3 Objetivo General
Diseñar una guía para identificar y negociar los requerimientos con Stakeholders en un proyecto de
tecnología de información
2.4 Objetivos Específicos
1. Diseñar una plantilla para describir herramientas de levantamiento de información en
proyectos de tecnologías de información.
2. Utilizar la plantilla para describir por lo menos siete (7) herramientas de levantamiento de
información
3. Describir estrategias de negociación basados en los roles principales en proyectos de
tecnologías de información indicando las implicaciones del uso de las diferentes
herramientas de levantamiento de información
4. Seleccionar un proceso de ingeniería de requerimientos y construir una guía que integre el
uso apropiado de las herramientas de levantamiento de información y realizar una prueba
piloto de la guía
7
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
2.5 Metodología Propuesta
Al ser este un proyecto de investigación y basados en la definición de los objetivos se deslumbra la
necesidad de levantar información. Estos requieren de una investigación que contribuya a plasmar
el contexto con la mayor objetividad en pro de llegar a un conocimiento de gran validez que aporte,
en llevar a cabo nuestro objetivo general. Para esto daremos uso a la metodología cualitativa que
plasma las cualidades, con el fin de entender algunos elementos que componen la realidad. No se
trata de probar la realidad sino de abarcar la mayor cantidad de cualidades posibles y cómo
intervienen, ayudando a comprender la problemática que planteamos.
Objetivos Específicos Relacionados
Fases seleccionadas de la metodología
en esta Metodología
cualitativa para cumplir con estos
Técnicas de investigación
objetivos

Diseñar un plantilla para
describir las herramientas de
levantamiento de información en
proyectos
de
tecnologías
de
información

Utilizar la plantilla para
describir por lo menos 5 herramientas
en los procesos de levantamiento de
información
- Comprensión
- Observación
- Observación de los participantes en
- Conversación con
el proceso de identificación de
expertos
Stakeholders
- Gestión de documentos
- Especificación de la Problemática
- Cruce de información
- Establecer la pregunta de
- Obtención de información
investigación
a través de entrevistas,
- Entrevistas a personas que se
cuestionarios
enfrentan al proceso todos los días
- Análisis de información
- Síntesis
- Revisión de Literatura
- Haciendo una revisión profunda de
literatura en las variables
identificadas en la pregunta
- Entender los datos y convertirlos en
información
Finalidad: realizar un estudio global de todos los factores que contribuyen en la problemática, con el
fin de comprender y analizar todos los conceptos, herramientas, datos y técnicas que puedan
contribuir en una solución o mejoramiento de la misma.
Tabla 1- Objetivos en contraste con la Metodología # 1
8
Ingeniería de Sistemas
ISTAR - CIS0830IS16
A continuación el objetivo mencionado forma parte de los artefactos que se piensan entregar a partir
de las fases y objetivos mencionados anteriormente.
Objetivos
Específicos
Relacionados
en
esta
Fases seleccionadas de la metodología cualitativa
Metodología
para cumplir con estos objetivos

Analizar y diseñar el proceso, detallando sus
entradas y salidas.
- Teoretización
- Acoplamiento de datos, información e ideas para
construir nuevo conocimiento.
- Recontextualización
-
Análisis de la información
-
Seguimiento
Finalidad: Construir a partir de la información recolectada el análisis, diseño y proceso de la guía.
Tabla 2 - Objetivos en contraste con la Metodología # 2
Los siguientes objetivos proponen una prueba piloto de lo desarrollado con el fin de observar el
comportamiento para realizar una iteración a partir de las críticas constructivas de personas que
tengan un bagaje en el tema y poder realizar un mejoramiento de la guía.
Objetivos
Específicos
Relacionados
en
esta
Metodología
Fases seleccionadas de la metodología cualitativa
para cumplir con estos objetivos

Describir estrategias de negociación basadas
en los roles principales en proyectos de
tecnologías de información
- Críticas constructivas

Realizar una prueba piloto de la guía
piloto
- Construcción de información a partir de la prueba
- Desarrollar el trabajo de aplicación del modelo
- Presentar resultados
- Ajustar a lo visto en la prueba piloto
- Retroalimentación
- Aterrizar conceptos y consejos de las personas con
el bagaje en el tema.
9
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
- Analizar los datos que arroje la prueba piloto
- Conclusión de la investigación
Finalidad: desarrollar un informe con los resultados obtenidos, con el fin de observar la operabilidad
de la misma.
Tabla 3 - Objetivos en contraste con la Metodología # 3
10
Ingeniería de Sistemas
ISTAR - CIS0830IS16
3. MARCO TEÓRICO
En el siguiente numeral de esta memoria se mencionaran todos los elementos y temas relacionados
para el desarrollo del trabajo de grado, se empezará enunciando la importancia del proceso de
Ingeniería de Requerimientos, los modelos de negociación, las actividades en el proceso de
ingeniería de requerimientos, la definición del proyecto, las tecnología de información, entre otros;
los cuales permitirán entender los fundamentos que contribuirán a relacionar trabajos con el
desarrollo de la Guía para interactuar con Stakeholders en el proceso de ingeniería de
requerimientos.
3.1 Ingeniería de Requerimientos
La ingeniería de requerimientos ha evolucionado en gran medida en las últimas décadas, cada vez
toma más importancia las técnicas y métodos desarrollados para la recolección de requerimientos en
proyectos de software. Hoy en día está tomado fuerza la idea de hacer un proceso de entendimiento
del problema y la importancia que tiene la satisfacción del cliente, que es uno de los factores que
mide la calidad de los productos de software, por tal razón se está haciendo caer en cuenta a las
personas y a la industria; que el software no solo depende de la parte de programación y de la
pericia de los programadores, para resolver el problema. Adicionalmente se creía que el proceso de
ingeniería de requerimientos debe ser un proceso rápido y no debía consumir tiempo y dinero, pero
a través de los años se generado la conciencia y la importancia de hacer un buen proceso de
ingeniería de requerimientos.
La ingeniería de requerimientos nace gracias a la necesidad de gestionar o administrar los
requerimientos de los clientes cuando se realizaban especificaciones de productos, en la década de
los 70, donde simplemente se le llamaba ingeniería. Entre los años 1980 y 1990, paso de llamarse
simplemente ingeniería a llamarse Gerencia de requerimientos, en donde se conoció el término
Stakeholder para referirse a los clientes y donde también se empezaron a establecer sistemas de
especificación de requerimientos. Hacia el año 2000 el “HOOD Group” introdujo el término
“Gerencia y Ingeniería de requerimientos” según [54],en donde se reafirmó el uso de sistemas de
especificación de requerimientos y la especificación de requerimientos del cliente. Estas razones
11
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
promovieron a la Ingeniería de Software, a hacer uso del término, por tal razón el SWEBOK2 en su
capítulo dos marca la importancia que tiene la gestión sistemática de las necesidades, donde aclara
que el término se tratara como requerimientos de software[51]. Para el contexto de este trabajo de
grado haremos uso del término ingeniería de requerimientos, gracias a la definición dada por el
diccionario de ingeniería como “el proceso de identificar y articular necesidades para aplicaciones
y la tecnología”[62], permitiendo que sea el término más adecuado para tratar en los proyectos de
tecnologías de información.
3.1.1
¿Qué es un Requerimiento?
La real academia de la lengua Española lo define como la acción y efecto de requerir3, donde
requerir se refiere a la solicitud, pretensión o explicación del deseo de una persona. Se hace la
salvedad en lo anterior, ya que la palabra requerimiento se tiende a confundir con “requisito”, que
según la real academia española la define como Circunstancia o condición necesaria para algo,
dejando claro que son palabras diferentes y que se ha prestado para malas interpretaciones en la
literatura en lengua castellana, ya que se encuentran traducciones por ejemplo de “Requirements
Engineering” como Ingeniería de Requisitos. Por lo tanto los requerimientos se definen, según
IEEE, “como la condición o capacidad que necesita un usuario o persona para resolver un
problema o alcanzar un objetivo”[53], en contraste Somerville y Sawyer lo definen como “Los
requerimientos son ... una especificación de lo que debe aplicarse. Son descripciones de cómo el
sistema debe comportarse, o de una propiedad del sistema o un atributo. Pueden ser un obstáculo
para el proceso de desarrollo del sistema.” Razón por la cual y para el contexto de este trabajo lo
definiremos como un conjunto de necesidades de personas, grupos, organizaciones o naciones que
describen el comportamiento de un sistema.[52][19].
3.1.2
Tipos o clases de Requerimientos
Al ser los requerimientos considerados como descripciones del comportamiento de los sistemas, se
hace necesario que los mismos se clasifiquen de acuerdo a sus características, existen diversos tipos
de clasificación de los requerimientos de diferentes autores, como es el caso de Sommerville que
clasifica a los requerimientos como: Funcionales, No Funcionales y de Dominio[38]. En el caso de
2
Swebok - Guide to the Software Engineering Body of Knowledge (SWEBOK), disponible en
http://www.computer.org/portal/web/swebok/htmlformat
3
RAE- Real Academia Española – Diccionario en línea de la lengua española, disponible en
http://www.rae.es/rae.html
12
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Wiegers el cual se basa en la clasificación de Sommerville, ya que aduce que los requerimientos
están clasificados en: Requerimientos de Negocio, Requerimientos de Usuario, Requerimientos de
Sistema, Requerimientos Funcionales y Requerimientos No funcionales (reglas del negocio,
atributos de calidad, interfaces externas, restricciones) [52], el cual especializa y detalla mejor la
clasificación de Sommerville. Al existir diversas clasificaciones, Aybüke y Wohlim los enuncia y
explica brevemente para que sean tenidos en cuenta, en la siguiente tabla:
Tabla 4 - Clasificación de requerimientos según [19]
Para la investigación haremos uso de la clasificación propuesta por Sommerville, la cual describe
los tipos de requerimientos de manera genérica y más afable para cumplir con el propósito de esta
investigación.
3.1.3
Proceso de Ingeniería de Requerimientos
Cuando se discute respecto al proceso de ingeniería de requerimientos, se habla de todo el
compendio de actividades que permiten las actividades que permiten la elaboración de documentos
donde se albergan y entienden los requerimientos. Existen diferentes percepciones acerca del
proceso de Ingeniería de Requerimientos, uno de ellos es el propuesto por Sommerville y Kotonya
13
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
los cuales proponen un modelo lineal compuesto de cuatro fases que son: Obtención
de
Requerimientos, Análisis y negociación de requerimientos, Documentación de requerimientos y
validación de requerimientos[57], que trabaja como lo muestra la siguiente figura.
Figura 1 – Proceso de Ingeniería de Requerimientos según Sommerville y Kotonya tomado de [58]
Este modelo propuesto por Sommerville y Kotonya que son la base de la guía SWEBOK en lo que a
requerimientos de software propone las mismas, como lo muestra la siguiente figura
Figura 2 - Áreas de Conocimiento de Requerimientos de Software tomado de [51]
14
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Otro modelo es el propuesto por Macaulay, que también propone un modelo lineal, pero que no
contempla interacción entre las actividades[59], el cual trabaja como lo muestra la siguiente figura.
Figura 3 - Proceso de Ingeniería de Requerimientos según Macaulay tomado de [58]
Otro es el propuesto Loucopoulos y Karakostas, los cuales proponen un proceso iterativo y cíclico,
que relaciona las actividades y genera relaciones de causa y efecto entre las mismas[58], el cual
trabaja como lo muestra la siguiente figura.
Figura 4 - Proceso de Ingeniería de Requerimientos según Loucopoulos y Karakostas tomado de [58]
15
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
Otra propuesta es la de Volere4, la cual es producto de las experiencias de consultores que forman
las personas que forman parte del este grupo[60], como lo muestra la siguiente figura.
Figura 5 - Proceso de Ingeniería de Requerimientos según Volere tomado de [61]
El modelo propuesto por Volere radica en hacer procesos de requerimientos más agiles y acoplados
las circunstancias de la vida, el mismo es la interacción de una serie de actividades que han
contribuido a desarrollar levantamiento de requerimientos, trabajando con todas las metodologías
existentes.[61]
Por último miraremos la propuesta de Sommerville en su libro de Ingeniería de software, que está
basada en su primera propuesta hecha con Kotonya, a la cual agrega una actividad más, que es la un
Volere – Grupo de Consultores especialistas en manejo de requerimientos, donde se pueden encontrar
templates, cursos, servicios de consultoría, entre otros, para mayor información consulte
4
16
Ingeniería de Sistemas
ISTAR - CIS0830IS16
estudio viabilidad y unificando el análisis y la obtención, en una sola actividad en el proceso[38],
esta trabaja como se observa en la siguiente figura
Figura 6 - Proceso de Ingeniería de Requerimientos según Sommerville tomado de [38]
Basados en los modelos observados y analizando los planteado para esta investigación, que el
modelo a usar es el propuesto por la guía SWEBOK, ya que es más general y permitiendo que sea
aplicable a proyectos de tecnología de información, pero resaltando los propuestos por Volere y
Somerville en su libro de Ingeniería de Software, dejando este último una grata sorpresa con el
estudio de viabilidad, el cual puede ser tenido encuentra en los trabajos futuros de esta
investigación.
3.1.4
Obtención de requerimientos
La obtención de requerimientos proviene de lo que en ingles se dice “Requirements Elicitation”,
Elicitation no tiene traducción en lengua castiza, pero que significa en ingles obtención, esta
palabra se ha usado como si tuviera acogida en la lengua española, por el momento no la tiene, así
que cuando se encuentre a ella se debe hacer referencia a obtención. Por lo tanto se entiende que la
obtención de requerimientos hace referencia a la manera como un analista de requerimientos,
conoce de donde provienen y que medios tiene para recogerlos, esto según SWEBOK, en la que se
realiza un entendimiento o comprensión del problema a partir de la comunicación y relaciones que
el analista con las personas.[51]. Por lo tanto para el contexto de esta investigación, se define la
17
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
obtención de requerimientos como el conjunto de actividades que permiten la educción de las
necesidades y deseos que tiene una persona o grupo.
3.1.4.1 Stakeholders
En el proceso de Obtención de requerimientos está fundamentado en las personas, ya que son las
que forman parte de la organización y poseen la información referente a ella y al negocio. En ese
orden ideas aparece un término, que surgió de la necesidad de unificar un término que denote, tanto
a usuarios como a clientes, según [3], se denominaron como Stakeholders que según este mismo
autor. Por lo tanto se define a un Stakeholder como “una persona o organización que influencia o
impacta a un sistema”, que también “posee interés y deseos en el cambio de un negocio” [3]. Según
Sommerville se entiende que un Stakeholders es cualquier persona o grupo que se ve afectado por el
sistema directa o indirectamente[38]. En el desarrollo de la investigación todas las definiciones son
válidas.
3.1.4.2 Tipos de Stakeholders
Como se definió en el numeral anterior, los Stakeholders son todas aquellas personas que se ven
afectados por el sistema, en el contexto de esta trabajo son todas aquellas personas que se vean
afectadas por el proyecto y que según el PMBOK también son las personas que pueden ejercer
influencia en el proyecto, al Guía PMBOK clasifica a los Stakeholders como[17]:
-
Cliente/Usuarios: que son las personas u organizaciones que darán uso al producto o
servicio resultante del proyecto. Aclarando que los mismos pueden ser internos y externos
respecto a la organización que ejecutara el proyecto.[17]
-
Patrocinador: la cual es definida como la persona que presta le respaldo o recurso
económico. Normalmente es de las primeras personas que definen las necesidades que
dieron vida al proyecto.[17]
-
Directores del portafolio/Comité de revisión del portafolio: Son personas que ejercen
cargos de alto nivel, y cuyo objetivo es de ejercer control en los proyectos, evaluando
constante el retorno de la inversión que genera el mismo.[17]
-
Directores de Programa: son personas que tiene bajo su mando la gestión de proyectos que
se relacionen, los cuales interactúan directamente con cada director de proyecto.[17]
-
Oficina de dirección de proyectos (PMO): Es una entidad o cuerpo dentro de la
organización que ejerce un control central de los proyectos en la organización.[17]
18
Ingeniería de Sistemas
-
ISTAR - CIS0830IS16
Directores del proyecto: son las personas que tiene el poder y toma decisiones respecto al
proyecto, de la misma manera es la encargada de planificar, mantener y hacer seguimiento
de todo el proyecto.[17]
-
Equipo del proyecto: es el grupo de personas, encabezado por el director del proyecto y
otros, los cuales son los encargados de ejecutar las actividades y tareas planeadas para el
desarrollo del proyecto.[17]
-
Gerentes funcionales: Son las personas encargadas de facilitar labores administrativas o
funcionales dentro de la organización, que permiten proporcionar servicios al proyecto.[17]
-
Gerentes de Operaciones: Son las personas que conocen directamente y tiene que ver con
la producción y mantenimiento de productos en la empresa, dependiendo del proyecto
estarán encargados de suministrar y documentar información técnica.[17]
-
Vendedores / Socios de Negocio: Son las personas encargadas de proveer de proyectos a la
compañía a través de la venta de sus productos y servicios, estos también se pueden ver
como organizaciones o compañías amigas.[17]
En la siguiente figura se muestra la manera en que se relacionan según PMBOOK.
Figura 7 - Relación entre los interesados y el proyecto según PMBOK tomado de [17]
19
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
Otro tipo de clasificación es la que presenta Wiegers en [66], el cual clasifica a los Stakeholders
como los clientes; los cuales tiene similar interpretación a la hecha por el PMBOK, los mismo para
también el director del proyecto y el usuario, también tiene en su clasificación al probador, al
desarrollador, al analista y a otros Stakeholders, que son los que normalmente aparecen en el
proceso de identificación de los mismos. En la siguiente figura se muestra el esquema de
clasificación de Wiegers.
Figura 8 - Clasificación según Wiegers tomada de [66]
Otra clasificación es que se propone Contrux[67] en su Requirememts ToolBoxWeB, la cual está
catalogada como el listado Potenciales Stakeholders en su Herramienta “Stakeholder Analisys”, los
cuales se muestran en la siguiente tabla.
Figura 9- Potenciales Stakeholders según Contrux tomado de[67]
Basado en lo anterior y para el desarrollo de nuestra investigación es válida cualquier clasificación;
ya que en los proyectos de tecnologías de información existe la posibilidad de interactuar con todo
20
Ingeniería de Sistemas
ISTAR - CIS0830IS16
tipo de personas, solo se debe tener en cuenta que cualquiera que sea clasificación que se adopte,
siempre debe prevalecer el respeto por las personas.
3.1.4.3 Identificación de Stakeholders
Desde el comienzo de esta investigación hemos dado cabida a la identificación de Stakeholders, tal
como lo muestra los siguientes artículos, y que fueron citados en la propuesta de esta investigación.
-
Una aproximación a la identificación de personas interesadas en ingeniería de
requerimientos
El punto de partida de esta aproximación consiste en un conjunto de partes interesados a la
cual se refieren como la línea base de referencia de Stakeholders y su interacción como se
muestra en la siguiente figura.
Sistema
Satélite
Satélite
Afecta
Interactúa
Interactúa
Línea
Base
Apoya
Proveedor
Produce
Cliente
Figura 10 - Elementos principales en la identificación de personas interesadas tomado de [8]
21
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
De estos, se reconoce al proveedor y al cliente como partes interesadas: el primero
proporciona información o tareas de apoyo a la línea base de referencia y el segundo
inspecciona los procesos o los productos de la línea base. Otros interesados los llaman
satélites que son los que interactúan con la línea base de referencia en una variedad de
maneras. La interacción puede implicar la comunicación, la lectura de un conjunto de
normas o directrices, la búsqueda de información y así sucesivamente. Este enfoque se
centra en las interacciones entre las partes interesadas en lugar de las relaciones entre el
sistema y los interesados, porque son más fáciles de trazar [8].
-
Comprensión de la sociología del proyecto modelando STAKEHOLDERS
Dentro de este artículo se hace un modelado de las partes interesadas y sus diferentes
implicaciones. Esto mediante un diagrama de “cebolla” (por las diferentes capas que se
manejan) como se muestra en la siguiente figura.
Figura 11 - Modelo de cebolla de las relaciones de las persona interesadas tomado de [9]
22
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Figura 12 - Modelos de cebolla desde la perspectiva de Volere tomado de [61]
Este diagrama, presenta una vista del proyecto, al cual se le llama kit, el equipo, o el
producto para distinguirlo del sistema, el cual incluye distintas franjas para las personas que
operan, mantienen el equipo y entregan sus resultados, así como cualquier norma o
procedimientos que utilizan para su operación [9][10].
Se hace una principal distinción entre los beneficiarios internos del producto: operadores, y
los beneficiarios funcionales externos: usuarios finales los cuales se consideran pasan la
frontera del sistema. Los operadores operan el equipo para enviar los resultados a los
beneficiarios funcionales, que a su vez trabajan para otras personas interesadas que afectan
la toma de decisiones en el sistema. Se puede ver el sistema como una herramienta[9].
3.1.4.4 Levantamiento de Información
La obtención o levantamiento de información se logra haciendo uso de la pericia que ha
desarrollado el hombre para interrelacionarse con los individuos, a través de los procesos
comunicativos donde se logra transmitir datos que el hombre convierte en información. El proceso
comunicativo y la observación son el pilar para el desarrollo de las técnicas que el hombre ha
desarrollado para lograr obtener información.
23
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
3.1.4.4.1
Técnicas de Levantamiento de información
A continuación se listara las técnicas que se estudiaron para el desarrollo de esta investigación y que
están basadas en la investigación hecha por [19]. En el Anexo A encontrara el mismo listado pero
con una breve explicación de las mismas, en caso de alguna profundización remítase a este.
-
Entrevistas.
-
Cuestionarios.
-
Task Analysis (Grupos de análisis o Análisis de Tareas) .
-
Domain Analysis (Análisis de dominio).
-
Repertory Grids
-
Card Sorting.
-
Laddering.
-
Group Work.
-
Lluvia de ideas.
-
Joint Application Development (JAD) .
-
Requirements Workshops.
-
Etnografía.
-
Observación.
-
Protocol Analysis.
-
Apprenticing.
-
Prototyping.
-
Goal Based Approaches.
-
Escenarios
-
Viewpoints.
3.1.5
Análisis de requerimientos
Según SWEBOK consiste básicamente en hacer un análisis de las necesidades, buscando
priorizarlas y por ultimo buscar conflicto entre los mismos. Lo que implica que se desarrollen
proceso de negociación de requerimientos. Esto es clave ya que es más económico mediar en los
conflictos entre requisitos en las etapas tempranas de los proyectos y no cuando se está finalizando
los mismos.[51]
24
Ingeniería de Sistemas
ISTAR - CIS0830IS16
3.1.5.1 Intereses y conflictos
El proceso de Ingeniería de requerimientos esta, basado en el alto grado de interacción de las
personas, que en para contexto de este trabajo de grado mencionaremos como Stakeholders. Estas
como su definición lo dice posee intereses o deseos, o en su defecto ejerce alguna influencia en el
sistema o proyecto. La real academia de la lengua define deseo como “la conveniencia o beneficio
en el orden moral o material” por lo tanto los interese, por general de tipo personal conlleva a que
se genere los conflictos, los cuales han de ser dirimidos a través de técnicas o estrategias de
negociación.
3.1.5.2 Negociación de requerimientos.
La Guía SWEBOK la define como la solución de conflictos cuando se presenta incompatibilidad en
los requerimientos de uno o más individuos[51]. Para el contexto de este trabajo se elaboró el
Anexo B, en donde se contempla los modelos y estrategias para hacer una negociación de
requerimientos.
3.1.6
Especificación de Requerimientos
Básicamente se define como el conjunto de herramientas, estándares y buenas prácticas para
escribir y denotar requerimientos. La guía SWEBOOK se refiere a esto como la producción de un
documento o artefacto que pueda ser sistemáticamente revisado, evaluado y aprobado[51]. Para
efectos de esta investigación solo se tomara como la etapa que se beneficiará de los productos
elaborados por este trabajo.
3.1.7
Validación de Requerimientos
Consiste en el proceso de verificación de los requerimientos y que estos describen a cabalidad los
deseos de las personas y al sistema o proyecto. La guía SWEBOK lo define como el proceso de
examinar el documento de requisitos para garantizar que se define el software adecuado (es decir,
el software que los usuarios esperan). Para efectos de esta investigación solo se tomará como la
etapa que se beneficiará de los productos elaborados por este trabajo.
3.2 Tecnologías de Información
Esta se define como el conjunto de aplicaciones, sistemas, herramientas, técnicas y metodologías
que permiten la administración de señales analógicas, señales digitales, sonidos, textos e imágenes
dentro de una organización o gobiernos según [68]. Las tecnologías de información fomentan el
25
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
desarrollo de económico y social de los países, el cual se verá reflejado a medida que la sociedad las
acoja y las haga parte de su vida cotidiana según [11].
El crecimiento de la economía globalizada conlleva a que las organizaciones confié en el desarrollo
de nuevas tecnologías que le permitan estar a la vanguardia del manejo de la información en la
organización. De la misma manera las tecnologías de información busca cada la unificación de los
sistemas en las organizaciones.
3.3 Trabajos relacionados
El crecimiento que ha tenido el desarrollo de software en el mundo ha logrado que las personas y
las organizaciones realicen desarrollos, acogiéndose a los estándares internacionales y a las buenas
prácticas. Debido a esto se han elaborado gran cantidad de ayudas, con el objetivo de contribuir en
la elaboración de productos de software más acordes con las necesidades. Si bien es cierto que el
auge de las tecnologías de información ha hecho más complejo el desarrollo de proyectos de
tecnología de información, debido a que esta busca la unificación y masificación de la información,
dando uso a tecnologías como el internet.
La recopilación de requerimientos es la parte esencial para el desarrollo de proyectos, ya que sin
una buena definición de estos, el mismo no puede llegar a desarrollarse, es por eso que se han
desarrollado los siguientes trabajos, los cuales serán los referentes para el desarrollo de esta
investigación.
3.3.1
Metodología DoRCU para la Ingeniería de Requerimientos
Es una metodología de documentación de requerimientos Centrada en el usuario, la cual está
compuesta por las siguientes etapas:
-
Obtención de Requerimientos
-
Análisis de Requerimientos
-
Especificación de Requerimientos
-
Validación y Certificación de los Requerimientos
La misma se detalla en la siguiente figura
26
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Figura 13 - Esquema Metodológico propuesto por DoRCU tomado de [63]
Esta metodología pretende hacer entender con detalle la Ingeniería de requerimientos, dando
flexibilidad al uso de herramientas para lograr los objetivos de cada etapa. De la misma manera
insta al usuario de la misma realizar documentos de requerimientos isomorficos, uno orientado al
usuario y el otro orientado a requerimientos técnicos.
3.3.2
Definición de una metodología ágil de ingeniería de requerimientos para empresas
emergentes de desarrollo de software del sur-occidente colombiano
Es una metodología ágil de Ingeniería de requerimientos, la cual se fundamenta en el modelo de
madurez CMMI y el estándar ISO/IEC 12207[64], seleccionando las mejores prácticas en el
contexto de las empresas emergentes de desarrollo de software en Colombia, en especial en la
industria de desarrollo de software del suroccidente colombiano. Esta metodología está compuesta
tres grades fases:
-
Fase 1: Elicitacion5 de Requerimientos
-
Fase 2: Especificación de requerimientos
5
Remítase al numeral 3.1.4 en donde se explica el uso de la palabra elicitacion, y que esta no existe en la
lengua castiza
27
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
-
Fase3: Gestión de requerimientos
En la figura a continuación, se muestra el detalle de actividades de la metodología en cada una
de sus fases.
Figura 14 - Estructura de la metodología ágil para el proceso de ingeniería de requerimientos tomado de [64]
El uso de esta metodología facilita el desempeño de la empresa desarrolladora de software en
Colombia, en especial para el desarrollo de software a medida y el desarrollo de ideas de
negocio[64].
3.3.3
Guía Metodológica para la recolección de requerimientos a distancia
Este fue el trabajo de grado propuesto, elaborado y aprobado por el Ingeniero Álvaro Andrés
Miranda Forero, para optar por el título de Ingeniería de Sistemas en la Pontificia Universidad
Javeriana y dirigido por el Ingeniero Miguel Torres, la cual probo y brindo una alternativa para la
recolección de requerimientos cuando se posee la limitante geográfica en el desarrollo de una
28
Ingeniería de Sistemas
ISTAR - CIS0830IS16
proyecto, para que así los costos del proceso de recolección no se eleven[44]. Esta guía está
compuesta por Cinco grandes pasos:
-
Paso 1 - Preparación del entono de trabajo y consideraciones iniciales
-
Paso 2 - Información Básica de la Organización
-
Paso 3 - Selección de Stakeholders
-
Paso 4 – Recolección de requerimientos
-
Paso 5 – Validación de Requerimientos
Esta guía está fundamentada en el Proceso de Ingeniería de Requerimientos propuesto por
SWEBOK y se enfatiza en la recolección de requerimientos, con el objetivo de obtener una buena
especificación de requerimientos a pesar de las limitantes territoriales.
3.3.4
La negociación en la obtención de requisitos y el proceso de análisis
El estudio realizado Sabrina Ahmadm [65]manifiesta la importancia de la negociación en los
procesos de obtención, recalcando la incidencia que tienen los conflictos y su manejo, para la
obtención de mejores requisitos de software, esto debido a los interés de cada una de las personas,
que son evidenciados en las etapas de obtención y análisis de requerimientos. De esta manera
induce el modelo en espiral de negociación para: identificar conflictos, seguido establecer
alternativas de solución, elaborar soluciones, Entender y ceder, Evaluar y analizar los acuerdos.
Donde finalmente recalca los tres criterios para la negoción, que son: Ambiente, el criterio de
entendimiento y la estrategia de solución. Este estudio provee la base para el desarrollo de esta
investigación y ratifica el enfoque para el desarrollo de la guía, que es la Obtención y análisis de
requerimientos.
3.3.5
Otros
Existe gran número de investigaciones que se encuentran consignados en libros, artículos,
bibliotecas digitales entre otros que contribuyen a en la Ingeniería de requerimientos; los cuales van
desde modelos matemáticos, herramientas de groupware para la ejecución y administración del
proceso, hasta el desarrollo de frameworks que aportan y se especializan en determinados sectores
de tecnología o computación, los cuales abarcan la problemática de manera genérica, lo cual fue ya
contemplado en el componente teórico de este trabajo.
29
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
4. PROCESO
4.1 Desarrollo de la investigación
Para el desarrollo de la metodología propuesta en el numeral 4.1 se realizó este compendio de
actividades, que se comentan a continuación:
-
Se efectuó una investigación de la literatura en libros especializados en ingeniería de
software e ingeniería de requerimientos y en bibliotecas digitales tales como IEEExplore de
IEEE, ACM Digital Library de ACM, Springerlink, EbscoHost y ProQuest con el objetivo
de adquirir información referente a las técnicas de recolección de información, trabajos
existentes relacionados con la problemática y técnicas de negociación.
-
Luego se analizó la manera en que debía ser representada la plantilla y sus componentes,
para ello se valoraron opciones como: plantillas para ser diligenciadas en procesadores de
texto, templates hechos en software para hacer presentaciones, plantilla hecha en Adobe
flash y los mapas mentales. De los cuales se seleccionó elaborarla en base a un mapa mental
y en especial se dio uso al software de MindManager 8; que permite la exportación en
diferentes formatos y la relación de diferentes vínculos visuales y multimediales. De la
misma manera se establecieron los principales parámetros que debía albergar la misma.
-
Se desarrolló el listado con las técnicas de levantamiento de información en base a la
investigación hecha por Aybüke et al. [19], de la cual se eligieron siete para ser descritas
con la plantilla que se elaboró en base a un mapa mental.
-
Al finalizar la descripción de las dos primeras técnicas, se observó y analizo que esta podría
ser enriquecida en su parte descriptiva, haciendo uso de BPMN a través del Software libre
TIBCO Busisness Studio propuesto por el director de este trabajo de grado. Seguido se
procedió a aprender la notación y las bondades de la herramienta. Con las que se obtuvo
una documentación de la descripción en BPMN que ese encuentra disponible en línea para
el público.
-
En una revisión de trabajo se concluyó, que el tener una documentación en línea no instaría
a la personas a observarla, por ende se optó por la elaboración de videos explicativos; en los
cuales se mostrara cada una de las descripciones hechas en BPMN, las cuales no
sobrepasaron los dos minutos y que incentivan a las personas a observar la documentación
30
Ingeniería de Sistemas
ISTAR - CIS0830IS16
si se desea profundizar. Los videos fueron subidos en YouTube [50] y están disponibles
para el público.
-
Una vez completados los dos primeros objetivos propuestos y basados en la investigación
realizada acerca de los modelos y estrategias de negación, se elaboró un documento con la
información necesaria y clara, para que fuese interpretada de manera rápida y utilizada por
la guía que se desarrollaría.
-
Buscando aglutinar el conocimiento adquirido y fundamentado en las bases teóricas que
brinda la investigación realizada se construyó la guía, la cual se enfoca en las etapas de
obtención y análisis de requerimientos, la cual se apadrina y alinea con los productos
realizados hasta el momento.
-
Finalmente la prueba de la guía desarrollada en el numeral anterior no se pudo realizar por
diferentes razones, quedando esta para ser experimentada en trabajos futuros, pero con la
firme convicción de su sustento teórico alto y el uso de los principales productos elaborados
en el desarrollo del trabajo de grado.
4.2 Reflexión Metodológica
El hacer uso de la propuesta metodológica propuesta de tipo cualitativo para el desarrollo de este
trabajo de grado se observó lo siguiente:
-
Al ser una metodología cualitativa, permitió que la mayoría de actividades planeadas en el
cronograma se ejecutaran, permitiendo que estas se les pudieran agregar, eliminar o
modificar detalles, debido a la flexibilidad que caracteriza esta metodología. Por lo tanto es
necesario hacer un seguimiento riguroso y objetivo al cronograma de actividades,
documentando cada cambio hecho al mismo, cuando se haga uso de esta metodología.
-
El planteamiento de las actividades en la metodología permitieron elaborar y validar los
productos que validaron la consecución de los objetivos específicos.
-
El plantear tres etapas llevo a que la investigación adquiriera en su primera parte el
componente teórico base necesario para entender las entradas necesarias que llevaron a las
siguientes etapas, a un análisis y discusión en su segunda etapa y a la construcción de un
producto final de fácil utilización y apoyo teórico, en su tercera etapa.
-
Debido al poco tiempo que se tiene para el desarrollo de la investigación, se evidencio que
esta metodología está diseñada para ser usada por más de una persona.
31
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
5. RESULTADOS Y RECOMENDACIONES
En este capítulo se evidenciaran cada uno de los resultados y productos, desarrollados para la
consecución de los objetivos de este trabajo de grado. Las siguientes son el producto de la
investigación que se desarrolló, comenzando desde la elaboración de una plantilla que permitiera la
descripción de las técnicas de levantamiento de información, seguido del uso de la misma para las
descripción de algunas técnicas de levantamiento, donde también se desarrolló una investigación
acerca de las técnicas de negociación, entre otros que formaron las base para el desarrollo de la
guía.
5.1 Plantilla para describir herramientas o técnicas de levantamiento de
información
Existen diversas herramientas y técnicas para el levantamiento de información, algunas de ellas son
de fácil dominio entre las personas, ya que son utilizadas a diario. Pero al tener una gran cantidad de
ellas se observó la necesidad de tener una plantilla que contribuya en el conocimiento de las mismas
y que permita describir sus principales características. Razón por la cual se decidió hacer uso de los
mapas mentales, ya que permite describir las técnicas haciendo uso de la creatividad y el lenguaje
gráfico. Para la elaboración de la plantilla se hizo del Software MindManager 86 producido por
Mindjet, el cual permite que la plantilla pueda ser visualizada con la tecnología de Adobe flash. En
caso de hacer uso de la misma se debe tener el software instalado en un ordenador. Para mayor
información remítase al Anexo G.
6
MindManager 8 Software para la elaboración de mapas mentales, para mayor información remítase a
http://www.mindjet.com/products/mindmanager-8-win/overview
32
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Figura 15 - Plantilla de descripción de técnicas de levantamiento de información
5.2 Descripción de 7 Técnicas de levantamiento de información con la
plantilla
Basados en los objetivos del trabajo de grado se procedió a hacer uso de la plantilla para la
descripción, acordando hacer uso de las misma en 7 oportunidades, las cuales fueron elegidas de
mutuo acuerdo, buscando describir técnicas que no fueran tan populares, pero que sirvieran para
hacer una buena prueba de la plantilla, en ese orden ideas se describieron las siguientes técnicas:
-
Sesiones JAD
-
Domain Analysis
-
Card Sorting
-
Apprenticing
-
Protocol Analysis
-
Task Analysis
-
ViewPoints
Cuyas descripciones están disponibles en el Anexo H, en las mismas también se dio uso de BPMN
[49] para poder describir como era el proceso de desarrollo de las mismas. Para hacer esto se hizo
33
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
uso de la TIBCO Bussines Studio7, que es un software libre que permite la diagramación de
procesos bajo el estándar de BPMN; este software también permitió la documentación de los
mismos en formato HTML. Basado en lo anterior se realizaron videos que explicaban el proceso en
BPMN de cada técnica. Para mayor información acerca de estos productos remítase a Anexo C,
Anexo D y Anexo E.
Figura 16 - Apprenticing en BPMN
Figura 17 - Card Sorting en BPMN
TIBCO Business Studio – Software libre que permite la diagramación de procesos bajo el estándar BPMN
1.2, disponible en http://developer.tibco.com/business_studio/default.jsp
7
34
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Figura 18 - Domain Anlysis
Figura 19 - Sesiones JAD en BPMN
35
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
Figura 20 - Protocol Analysis
Figura 21 - Task Analysis en BPMN
36
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Figura 22 -ViewPoints en BPMN
5.3 Estrategias de negociación
La negociación hace parte de las actividades diarias del ser humano, en la mayoría de las
actividades sin saberlo actuamos haciendo uso de las negoción, para lograr la satisfacción de
intereses personales o grupales. En el proceso de ingeniería de requerimientos la negociación es
indispensable para una buena concertación entre las partes involucradas en este proceso, es por eso
que se elaboró un documento donde se encuentran alojadas y descritos los principales métodos,
técnicas y estrategias para la negociación, para mayor información remitirse al Anexo B.
5.4 Guía para identificar y negociar requerimientos con Stakeholders
5.4.1
INTRODUCCIÓN
La siguiente guía es una herramienta que ayuda en la primer etapa de los proyectos de tecnologías
información, específicamente en las etapas de Obtención y Análisis de requerimientos,
fundamentada en el proceso de ingeniería de requerimientos propuesto por SWEBOK 8. Esta guía
puede contribuir en la elaboración y aprobación de los documentos iniciales del proyecto, como
pueden ser el documento de requerimientos del proyecto (SRS), el Project Charter del mismo entre
otros.
Esta guía pretende ayudar a las personas que no tienen la experiencia en el inicio de proyectos de
tecnologías de información. Principalmente va enfocada a las personas que se inician formalmente
8
SWEBOK: Guide to the Software Engineering Body of Knowledge (SWEBOK) disponible en
http://www.computer.org/portal/web/swebok/htmlformat
37
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
en proyectos, que poseen el Rol de analistas de requerimientos, analistas de sistemas o si fuese el
caso para cargos con enfoque comercial, los cuales no tienen la suficiente experiencia en la
recolección de requerimientos.
Esa no pretende establecer una única manera de realizar la etapa de Obtención y Análisis de
requerimientos, esta pretende ser una ayuda para enfrentar las primeras etapas de los mismos, con el
objetivo de contribuir en el desarrollo y éxito en los proyectos de tecnologías de información. La
concepción de la misma, va dirigida a poder desarrollarse mancomunadamente con las
metodologías de recolección de requerimientos existentes y enfatizándose en las etapas de
Obtención y Análisis de Requerimientos.
Esta guía está dirigida a las personas encargadas de ejecutar las primeras fases de los proyectos, por
lo general las personas que deben interactuar con las personas designadas por parte del cliente para
el desarrollo del proyecto.
Conocimiento
de la
organización y
el Proyecto
Identificación
de
Stakeholders
Selección de
técnicas de
levantamiento de
Información
Identificación
Intereses y
conflictos
Selección de la
técnica o estrategia
de negociación
Figura 23- Pasos de la Guía
5.4.2
Conocimiento de la Organización y el Proyecto
Para el inicio de todo proyecto se debe entender la importancia de conocer y comprender la
organización y el proyecto que afectara esta. Este entendimiento debe lograrse de manera clara y
38
Ingeniería de Sistemas
ISTAR - CIS0830IS16
concisa, a través de la mayor cantidad de fuentes de información. Para lograr ello se debe realizar
una investigación a fondo, si la restricción de tiempo del proyecto lo permite. Se debe tener muy
claro en esta etapa del proyecto el conocimiento del equipo del proyecto por parte del cliente no está
completamente definido, de la misma manera el tamaño, alcance y objetivos del mismo no están
definidos a cabalidad, es por ello que se debe acudir como primera medida a:
-
Amigos o conocidos
-
Documentos públicos, periódicos o RFP públicos
-
Internet o bases de datos publicas
Que conlleve al analista de requerimientos a obtener información de alto nivel referente a la
organización y acerca del proyecto, la cual brinde un panorama general al analista para el comienzo
del proyecto.
5.4.2.1 Información del Cliente o Organización
Es de vital importancia para el analista de requerimientos del proyecto conocer la naturaleza de la
organización, la cual será la mayor beneficiaria del proyecto y la que finalmente recibirá a cabalidad
el producto o servicio. Es por ello que es aconsejable conocer la siguiente información, tanta como
sea posible:
a. Estructura de la organización: conocer la manera en que está constituida; saber si es una
jerarquía, una junta directiva, una corporación entre otras. Del mismo modo conocer la
mayor cantidad de relaciones de autoridad y saber cuáles son las personas que toman las
decisiones cruciales en la organización, también es aconsejable el documentar nombres,
cargos y la influencia de los mismos, en la medida de las posibilidades y alcance que tenga
nuestras fuentes de información.
b.
Propósito: conocer los objetivos de la organización, si es posible investigue acerca de la
naturaleza de la misma, conociendo su visión, misión, valores y políticas.
c. Productos y servicios: para tener información y conocimiento referente al negocio, se puede
averiguar acerca de sus principales productos y servicios, si es posible indague, cuál es la
posición en los mercados en el que se desenvuelve la organización.
d. Tamaño: tener la información referente a su influencia en el mundo en el que se desempeña,
conocer la cantidad de personal que la integra y el tipo de trabajadores que contrata, esto es
39
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
muy aconsejable; ya que brinda una mirada al tipo de perfiles ocupacionales con que el
analista tendrá que interactuar en el desarrollo del proyecto.
e. Políticas: conozcas los ideales de la organización en cuanto a competencia y a la gente que
pertenece o trabaja con la misma.
5.4.2.2 ¿Por qué conocer la organización?
Se debe aclarar que la información que se recolecte en esta fase debe ser tanta como sea posible y
está ligada a la calidad de las fuentes de información. Su objetivo principal es dar una mirada de
alto nivel acerca de la organización, la cual contribuirá en los contactos iniciales que se tengan con
el cliente o con el equipo, que el mismo designe. Al contar con la información acerca de la
organización brinda al analista de requerimientos la seguridad, para poder efectuar acercamientos y
así poder contribuir a la creación de ambientes de confianza en futuras reuniones, ya que esto
demostrara el interés y conocimiento por la organización.
5.4.2.3 Cuando existe un RFP9
Existe la posibilidad que un proyecto se lleve a cabo, gracias a un proceso de adjudicación, cuya
base es un RFP (Request for Proposal). En este documento está establecida gran parte de la
información necesaria de la organización y gran parte de los datos e información que puede ser
utilizada para el desarrollo del proyecto. Cabe resaltar que el tener un RFP no garantiza la
información total y necesaria para llevar a cabo el proyecto, esto depende de la claridad y
especificidad que tenga el mismo. Por lo tanto es una buena fuente de información para llevar a
cabo el proceso de Obtención y Análisis de requerimientos.
5.4.2.4 Identificación del tipo de proyecto
Los proyectos de tecnologías de Información presentan diferentes tipos de características,
restricciones, alcances entre otros, que permiten que su objetivo e influencia cambien; es por eso
que a continuación se propone una clasificación de los proyectos de tecnologías de información de
acuerdo a sus principales características. Es de resaltar que la siguiente clasificación no es
restrictiva y única, por el contrario es una forma de clasificación de los proyectos que ayude en
principio al analista y al grupo del proyecto a determinar el alcance y objetivos del proyecto.
9
RFP: Request for Proposal cuya traducción es solicitud de propuesta, normalmente se usan para la búsqueda
de proveedores de productos y servicios por parte de las grandes organizaciones.
40
Ingeniería de Sistemas
ISTAR - CIS0830IS16
5.4.2.5 Objetivo general del proyecto
El objetivo de un proyecto es la de llevar a cabo la creación de un producto o servicio, el cual por su
naturaleza tiene un comienzo y un fin definidos[16], basado en esto los proyectos de tecnologías de
información se pueden clasificar de la siguiente manera:
-
Proyectos de Desarrollo: son todos aquellos proyectos que se crean a partir de las
necesidades o problemas de las organizaciones, las cuales no poseen algún tipo de solución
sistemática o de software. Las cuales son creadas de ceros y a la medida de las necesidades
que enmarca el problema, lo cual implica procesos de Análisis, Diseño, Desarrollo e
implementación, como es el caso de sistemas de software a la medida.
-
Proyectos de implantación: son los proyectos que se desarrollan partir del uso de productos
de tipo genérico, los cuales son utilizados para el diseño de soluciones a los problemas o
necesidades de un cliente u organización. La finalidad de estos proyectos es la
configuración y adaptación, para la solución de problemas en la organización, como por
ejemplo, es el caso de una interconexión de la red de datos, ya que usted necesita la
instalación y configuración de determinados productos.
-
Proyectos de integración: son los proyectos en los que se busca la interacción de sistemas
existentes o nuevos en la organización, como por ejemplo, fuentes de datos externas que
sean de vital importancia para la organización entre otras. También puede ser un proyecto
en el que se necesite hacer un desarrollo de ceros y se necesite que el mismo interactué con
un producto que ha de ser configurado, por lo tanto es una mezcla de los dos anteriores.
Es importante aclarar que en un proyecto se pueden presentar los tres tipos a la vez, ya que no es
una clasificación única, o simplemente una mezcla de los tipos anteriormente expuestos. Es
recomendable desde el punto de vista de la Gerencia de proyectos el dividir el proyecto en fases en
caso de presentarse dichos casos y tomar así cada fase como un proyecto.
Esta clasificación ayuda a guiar al analista de requerimientos a dilucidar con qué tipo de roles en la
organización tendrá que confrontar.
5.4.2.6 Incidencia del proyecto
Todos los proyectos tienen la característica de incidir o influenciar algún estamento o proceso en la
organización, por lo general, los proyectos de tecnología de información inciden en los
41
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
procedimientos que efectúan los miembros de la misma, dichas incidencias pueden ser perceptibles
por parte de los usuarios finales de los productos y servicios, que se logran en el desarrollo del
proyecto. En base a lo anterior se puede clasificar la incidencia y el impacto de los proyectos de
tecnologías de información de acuerdo a la información de la siguiente manera:
a. Alta: Se presenta cuando se conoce que el proyecto afectara los procedimientos y
actividades de tipo crítico, en gran número a los miembros de la organización, por lo tanto
puede que se afecte los procesos de negocio.
b. Medio: Se presenta cuando la influencia del proyecto, afecta en un porcentaje medio las
actividades de los miembros de la organización, es decir que no afectan en gran número la
cadena de producción de los productos y servicios de la organización cliente.
c. Baja: Se presenta cuando el proyecto afecta en lo más mínimo las actividades y
procedimientos de la organización, por lo general la influencia de estos no deben ser
perceptibles a los miembros de la organización.
5.4.3
Identificación de Stakeholders
Al contar con información relevante acerca de la Organización o Cliente y la identificación del tipo
de proyecto con el que el analista de requerimientos se va enfrentar. Es relevante entender la
importancia de la identificación y conocimiento de las principales fuentes de información en las
organizaciones, estas son las personas o miembros de la organización, que generalmente para los
proyectos TI son los llamados Stakeholders o Interesados. En esta etapa de los proyectos
normalmente se ve el involucramiento de roles de tipo comercial, gerentes de tecnología,
arquitectos de software, administradores de sistemas, gerentes generales, presidentes entre otros.
Lamentablemente en este proceso es muy poco el involucramiento de cargos operativos o de
usuarios finales de los productos o servicios que se producirán en el ejercicio del proyecto. Es por
eso que este tipo de roles con los que se interactuara y para el ejercicio de esta guía los llamaremos
Stakeholders de alto nivel. Conforme a esto y de acuerdo al tamaño, impacto y tipo de proyecto
debemos tener una buena identificación y conocimiento de los mismos.
5.4.3.1 Consideraciones Éticas y legales
Al interactuar con personas en los procesos de Obtención y Análisis de requerimientos se hace
necesario tener claras las consideraciones éticas y legales, las cuales son especificadas y bien
recomendadas en [43], en donde se destacan:
42
Ingeniería de Sistemas
-
-
ISTAR - CIS0830IS16
Los derechos y deberes de los Stakeholders
o
Derechos a estar informado
o
Permiso de Grabación
o
Derecho al anonimato
o
Derecho a retirarse
o
Proveer información válida y confiable
Consideraciones legales
o
Acuerdos de confidencialidad
o
Acuerdos legales
El saber y promulgar estas consideraciones, contribuirá a que se desarrolle un mejor proceso de
comunicación con los Stakeholders, en especial los de alto nivel, que finalmente contribuirá a un
mejor conocimiento de los mismos, si se considera tener un conocimiento más a fondo, remítase a
[43] en especial al numeral “4.1.2 Consideraciones Éticas y legales del Analista de
Requerimientos”.
5.4.3.2 Primer Contacto
El primer contacto con el cliente, es el producto de la preparación del equipo por parte de la
dirección del proyecto, en este caso prima la información que se le debe dar al analista de
requerimientos por parte del director del proyecto ó la parte comercial, para el conocimiento de las
personas como los Stockholders o Stakeholders, con los que la dirección del proyecto acordó la
consecución del mismo, esto con el objetivo de especificarle y aclararle al analista de
requerimientos roles, cargos y funciones de las personas con que el analista de requerimientos
interactuara en los contactos iniciales. Esto contribuye para que el analista, prepare su primer
contacto y cause una buena impresión, que abra una vía de buena comunicación para el desarrollo
del proyecto y el desarrollo de los procesos de Obtención y Análisis de requerimientos.
De esta manera el analista de requerimientos debe preparar una serie de preguntas que contribuya a
indagar acerca de los siguientes aspectos:
-
Designación y Descripción (aclare qué se debe especificar datos de contacto y la
disponibilidad de tiempo para el desarrollo de este proyecto) por parte del cliente, del
equipo de trabajo para el proceso Obtención y Análisis de requerimientos.
43
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
-
Descripción del problema a solucionar, es claro que tiene que ser la percepción que posee el
cliente
-
Descripción de las restricciones como tiempo y presupuesto que puedan tener los
Stakeholders de alto nivel respecto al proyecto.
-
Hora y fecha de las próximas reuniones a efectuarse entre el analista de requerimientos y las
personas que a bien designen los Stockholders o Stakeholders de alto nivel.
Debe ser claro que el éxito del primer contacto radica en el interés y la claridad que demuestre el
Analista de requerimientos para el desarrollo de la misma, por lo tanto este debe realizar preguntas
claras y sencillas de responder por parte de los Stakeholders de alto nivel. Esto con el fin de no
sostener reuniones largas y dispendiosas. Si algunas de las preguntas no son respondidas en las
reuniones, coméntele a los mismos que hagan llegar la información en el menor tiempo posible,
dejando claro y dándoles a entender que un proyecto cada minuto es vital y más cuando hubiere
restricciones de tiempo.
En el mundo de hoy, donde las Tecnologías de información y telecomunicación, posibilitan un
sinnúmero de posibilidades de comunicación entre las personas, se debe tener presente y hacer uso
de:
-
Video conferencias
-
Llamadas por internet o la telefonía IP
-
Wikis
-
Herramientas de Groupware
-
Mensajería instantánea.
-
Correo electrónico
Para posibilitarlos primeros contactos, a pesar de que es recomendable que se sostenga una reunión
persona a persona para que estos puedan generar un ambiente de cordialidad e interés entre las
partes.
5.4.3.3 ¿Cómo identificarlos?
Existen un sinnúmero de teorías y técnicas que fundamentan la identificación de Stakeholders en la
Ingeniería de Software, enumerarlas para la identificación de Stakeholders no tendría sentido y no
44
Ingeniería de Sistemas
ISTAR - CIS0830IS16
es el objetivo de esta investigación. Pero es importante dejar en claro la importancia que tiene para
el desarrollo de esta guía, ya que una incorrecta identificación de generar especificación de
requerimientos pobres, incorrectos y de baja calidad[48]. Razón la cual se propone una serie de
concejos para ser practicados de acuerdo al tipo de proyecto e impacto que puede ser consultadas en
el Anexo I, el cual no es obligatorio su uso y dejamos al criterio del lector su utilización, debido a
que existe un una amplia gama de métodos y técnicas.
5.4.4
Selección de técnicas de levantamiento de información
El conocimiento acerca de la organización es la base para el desarrollo de un proyecto, seguido a
esto es el conocimiento de los procesos de la organización que se afectaran por la puesta en marcha
del mismo. El analista de requerimientos ya debe contar con datos, información y conocimiento de
la principal fuente de información, que son las personas. Es bien conocido que las personas no son
iguales, razón por la cual se muestra las técnicas que son aconsejables aplicar, de acuerdo a las
restricción de tiempo del proyecto
5.4.4.1 Personas o grupos Cerrados, Abiertos o Bipolares
El analista de requerimientos cuneta con la información necesaria acerca de los Stakeholders por
parte del cliente, de igual forma cuenta con cierto conocimiento referente a ellos; basados en el
conjunto de actividades que ha desarrollado con cada uno de los Stakeholders.
A continuación se propone una clasificación de Stakeholders, que permitirá al analista de
requerimientos en base a la información recolectada y el conocimiento de la misma, clasificarlos en
tres tipos. El primero es el tipo de Persona o Grupos cerrados, el segundo el tipo de Persona o
Grupos abiertos y el tercero el tipo de Persona o Grupo Bipolares.
a. Persona o Grupos Cerrados.
Es la persona o grupo que se caracteriza por tener comportamientos Obstinados y se
caracterizan por ser tímidos, lo cual no permite una buena comunicación con las personas.
También es característico en este tipo, el trato seco que tienen hacia las otras personas,
generalmente a este tipo de personas no se les facilita la expresión. Por último se
caracterizan por ser herméticos, muy prudentes y no abiertos a compartir información.
Cuando se habla de grupo, se hace referencia a que la mayoría de personas que lo
componen tiene la mayoría de las características que distingue a los tipos que se enuncian.
45
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
b. Persona o Grupo Abierto
Es la persona o grupo que se caracteriza por tener la disposición de trabajar en grupo, son
amables y atentos con el trato hacia las otras personas. Es característico en ellos la sencillez,
lo cual les facilita su capacidad de expresión, esto contribuye al proceso de levantamiento
de información y más aún cuando es un grupo de personas en el que predomina estas
características.
c. Persona o Grupo bipolar
Es la persona o Grupo que posee las características tanto de los grupos o personas
considerados para esta guía, como Cerrados y Abiertos. A estas también se les puede
denominar persona o grupos impredecibles; ya que pueden en un momento pueden ser la
persona o grupo más natural y en otro momento ser la persona o grupo más parco y
obstinado. Para encasillar a personas o grupos en este tipo evalué que estos posean
características de las que en esta guía calificamos como cerradas y abiertas en un 50%
aproximadamente cada una.
Una vez explicamos el tipo de personas o grupos, el analista de requerimientos cuenta con la
información para poder encasillar a las personas o grupos de Stakeholders en algunos de estos tipos.
5.4.4.2 Selección de la técnica de recolección de información
La recolección de información es el fundamento de la especificación de requerimientos para los
proyectos de tecnologías de información, esta se adquiere o recolecta a través de las personas, que
son las encargadas de desarrollar las diferentes actividades en las organizaciones. Existen un sin
número de formas, maneras, estrategias y técnicas para obtener la información.
En el Anexo A se encuentra un listado de las técnicas más usadas para el levantamiento de
información de manera grupal e individual, estas fueron usadas para clasificarlas de acuerdo a las
restricciones y los tipos de Stakeholders que se proponen en esta guía. Esto con el objetivo de
ofrecerle al analista de requerimientos el conocimiento de la técnica, que puede aplicar de acuerdo a
las restricciones y tiempos de los proyectos. De esta forma cabe aclarar que esta clasificación no es
restrictiva y las mismas pueden ser utilizadas de acuerdo al criterio del Analista, en ese orden ideas
la clasificación que se propone en la siguiente tabla se usa de acuerdo al tiempo que se tiene para
desarrollar el proyecto de TI y al tipo de Stakeholders propuestos.
46
Ingeniería de Sistemas
ISTAR - CIS0830IS16
. Tiempo del
Tipo de Persona
Técnicas de levantamiento de
Proyecto
o Grupo
Información
Corto
Cerrado
Cuestionarios, Puntos de Vista
Abierto
Entrevistas, Escenarios
Bipolar
Talleres, Requirements Workshops ,
Lluvia de ideas
Mediano
Cerrado
Introspección,
Análisis
de
Documentos, Análisis de Dominio
Abierto
Card Sorting, Análisis de tareas,
Repertory Grids
Largo
Bipolar
Laddering , Etnografía
Cerrado
Observación,
Apprenticing
Prototyping
Abierto
JAD, Análisis de protocolos
Bipolar
Grupos de Trabajo
Tabla 5 - Selección de Técnicas de acuerdo al tiempo y tipo de Persona o Grupo
El uso de la tabla es aplicable a grupos o personas, basándose en los criterios dados. El analista de
requerimientos puede optar por hacer uso de las herramientas si a criterio personal considera
hacerlo, pero se debe tener en cuenta siempre las restricciones de tiempo, ya que es recomendable
tener un tiempo prudencial para la planificación y aplicación de las técnicas. También es relevante
tomarse un tiempo prudencial para prepararlas, recordando que una de las principales fallas en los
proyectos de TI es una mala especificación de requerimientos [14] y normalmente se da por una
defectuosa recolección de información.
A continuación se explicara la clasificación de las técnicas, invitando al lector a hacer uso de los
siguientes anexos:
47
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
- Anexo A – Listado de técnicas de levantamiento de información
- Anexo C – Descripción de en BPMN de 7 técnicas de levantamiento de información
- Anexo D – Documentación HTML de la descripción de las 7 técnicas de levamiento de
información en BPMN
- Anexo E- Videos de explicación de la descripción en BPMN de las 7 técnicas de levantamiento de
información en BPMN
- Anexo G – Plantilla para la descripción de las técnicas de levantamiento de información.
- Anexo H – Descripción de 7 herramientas de levantamiento de información usando la plantilla del
Anexo G.
Con el objetivo de brindar al lector y al analista de requerimientos, información adicional y
herramientas para la profundización acerca de las técnicas de recolección de información.
5.4.4.3 Proyectos con restricción de tiempo corto
Las restricciones de tiempo en un proyecto juegan un papel importante en la elaboración del mismo,
esta limita el tiempo de cada una de las actividades a desarrollar en el mismo. Cuando el proyecto
presenta una limitante o restricción de tiempo corto, en la que este se debe administrar de la mejor
manera. Por lo general las actividades que más se resienten por esta limitante, es la de recolección
de información y especificación de requerimientos.
Basado en esto el analista se puede enfrentar a proyectos con poco tiempo para su realización, pero
a su vez se enfrenta, a la interacción con las personas o grupos, lo cuales forman parte de la
organización. Para realizar las actividades de levantamiento de información.
Para hacer uso de la clasificación de Stakeholders, los analistas en proyectos de corto tiempo se
pueden enfrentar a personas de tipo cerrado. Si se presenta esta situación el analista puede hacer uso
de las técnicas como “Cuestionarios” y “Puntos de vista”, los cuales tiene como primordial
característica, su desarrollo en corto tiempo. En el caso de los cuestionarios, son usados debido a
que son rápidos de ejecutar, pero que deben ser bien elaborados y específicos; ya que las personas o
grupos cerrados, son muy obstinados y renuentes a brindar información. Debido a que se cuenta con
48
Ingeniería de Sistemas
ISTAR - CIS0830IS16
poco tiempo para su desarrollo es una técnica que facilita al analista, una buena recolección de
información, ya que se centra en los puntos concretos para la especificación de requerimientos del
proyecto. Otra técnica de levantamiento de información es la de los puntos de vista; la cual permite
recolectar información desde la percepción que tiene cada Stakeholders referente al proyecto y la
organización, esta puede desarrollarse en corto tiempo y no limita a los Stakeholders para su
desarrollo. El tiempo de análisis de información en la técnica puede llegar a ser largo, pero el
analista debe tomar las partes más relevantes de los puntos de vistas, esta técnica es recomendada
para este tipo de situaciones ya que permite a los Stakeholders se expresen libremente, combatiendo
la obstinación y renuencia que caracteriza a las personas o grupos cerrados.
Cuando en los proyectos, el analista se enfrenta a grupos o personas de tipo Abierto y con la
restricción de tiempo corto, se recomienda que el analista haga uso de técnicas como lo son las
“Entrevistas” y los “Escenarios”; ya que estas permiten al analista recopilar información, debido a
que son técnicas que tiene un alto grado de interacción entre el analista y el Stakeholders, como los
Stakeholders son de un tipo abierto, se les facilita la comunicación y están dispuestos a colaborar.
En el caso de las entrevistas, las mismas necesitan una gran elaboración, pero al tener una limitante
de tiempo el analista debe preparar las mismas con preguntas de tipo abierto, con el objetivo de
poder explotar el carisma que caracteriza a estas personas o grupos de tipo abierto, limitando el
tiempo de intervención por parte de las personas, logrando así recopilar información relevante para
las especificación de los requerimientos. Cuando se hace uso de escenarios, el analista de
información puede observar casos de la vida real que pueden ser descritos por este tipo de personas,
de esta manera, sabemos que las personas de tipo abierto se les facilita la expresión, logrando así
aportar una mayor cantidad detalles acerca del proyecto o la problemática que el mismo desea
solucionar, de esta manera el analista de requerimientos puede recopilar buena información en corto
tiempo.
Con esta restricción de corto tiempo, el analista de requerimientos también se puede enfrentar a
personas o grupos de tipo bipolar. Para este tipo de personas o grupos se recomienda hacer uso de
técnicas como los “Talleres” o “Requirements Workshops” y “Lluvia de ideas”, ya que este permite
una interacción con personas que son muy variables en su comportamiento y humor, ya que
generalizan sus procedimientos en la integración y participación de las personas sin prejuicios de
cualquier tipo, adicional a esto pueden ser ejecutadas en muy poco tiempo, a pesar de que su tiempo
49
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
de preparación puede en algunos casos ser extenso en el caso de los talleres y Requirements
Workshops. Cuando se habla acerca de talleres o Requirements Workshops, se recomienda su uso,
ya que estos son desarrollados para que participen la mayor cantidad de personas sin ningún tipo de
restricción, lo cual permite que las personas o grupos con una característica bipolar se haga
participe del proceso de levantamiento de información, la preparación de estos debe ser muy
específica y limitada en el tiempo para su ejecución, por tal razón debe tener objetivos claros y
actividades que permitan levantar la mayor cantidad de información en el menor tiempo posible. En
el caso de la lluvia de ideas es una actividad muy recomendada cuando se tiene poco tiempo, ya que
esta permite que todas las personas participen de manera equilibrada y mancomunadamente,
logrando que se aporte la mayor cantidad de información, sin generar controversia entre las
personas, sin llegar a establecer discusiones de fondo que cree controversias entre los participante
de ellas. Esta puede lograrse en poco tiempo y aporta gran información al analista.
5.4.4.4 Proyectos con restricción de tiempo mediano
Las restricciones de tiempo pueden llevar al analista de requerimientos a enfrentarse a proyectos
con un mediano tiempo para su ejecución, lo que permite al analista contar con más tiempo para el
levantamiento de información. En ese orden de ideas el analista también estará enfrentado al tipo de
personas abiertas, cerradas y bipolares.
En el caso en que el analista de requerimientos se enfrente a personas de tipo cerrado, este ya
contara con mucho más tiempo para poder desarrollar actividades que le permitan levantar
información, en este caso se recomienda hacer uso de técnicas como son la “Introspección”,
“Análisis de Documentos” y “Análisis de Dominio”, ya que estas se caracterizan por tener baja
interacción con las personas, pero si contiene un alto grado de observación por parte del analista
requerimientos y son realizables gracias a que se dispone del tiempo para poder efectuarlas. En el
caso de la introspección, es recomendable su uso debido a que la interacción con las personas no es
tan alta como es el caso de una entrevista, ya que este solo busca documentar cada una de las
actividades que realizan los Stakeholders en la organización, con el objetivo de observar flujos de
información y necesidades de las mismas, esta permite que las personas de tipo cerrado no se
molesten, ya que no se van a sentir interrogadas. En el caso de análisis de documentos, es
recomendable su uso por la misma razón del anterior, ya que la interacción con las personas es muy
baja y cuando es necesaria la interacción, es de carácter específico y no logra molestar a las
50
Ingeniería de Sistemas
ISTAR - CIS0830IS16
personas; esta técnica se fundamente en la observación de información física de documentos en la
cual solo se solicitara por parte del analista explicaciones especificas por parte de los Stakeholders.
En el caso de la técnica de Domain Analysis, se recomienda su uso, ya que logra hacer interacciones
con la personas de manera más específica y especializada, con el objetivo, que el analista de
observe; flujos de información y procesos que puedan ser reutilizados para el desarrollo del
proyecto, la cual brinda baja interacción con las personas y promueve el análisis en el analista,
producto de la observación y el contacto especifico que se mantiene con las personas de tipo
cerrado.
También analista se puede enfrentar con personas de tipo abierto, en un proyecto con la limitante de
tiempo medio o mediano, para este caso se recomienda el uso de técnicas como “Card Sorting”,
“Análisis de tareas” y “Repertory Grids”, debido a que estas se caracterizan por tener un alto grado
interacción con las personas. En el caso del Card Sorting, es recomendado su uso ya que está
permite que los participantes propongan la organización y el modelo mental de la información en la
organización de manera individual y sin ningún tipo de restricción, esta técnica aprovecha el sentido
de colaboración que caracteriza a las personas de tipo abierto, dando al analista de requerimientos,
gran cantidad de información cuantitativa y cualitativa. En el caso del análisis de tareas, es
recomendable su uso ya que esta permite que el analista interactué en alto grado con las personas,
con el objetivo de priorizar las tareas desempeñadas por las personas en la organización, brindando
al analista datos e información relevante para las especificación de requerimientos. En el caso de los
Repertory Grids, es recomendado por su alto grado de interacción con las personas, ya que la base
de esta es una entrevista, que asigna valores a conjunto de entidades para lograr una modelación del
problema o del proyecto para observar semejanzas y diferencias, esta necesita de un alto grado de
preparación y análisis, lo cual permitirá al analista observar detalles y controversias en la
información.
También el analista se enfrentara a personas de tipo bipolar en un proyecto con tiempo medio o
mediano, es por eso que es recomendable hacer uso de técnicas como el “Laddering” y la
“Etnografía” ya que estas logran un nivel medio de interacción con las personas y se caracterizan
más por su análisis, haciendo que se haga más uso del tiempo en el análisis que en su ejecución. En
el caso de la etnografía, es recomendado su uso ya que se fundamenta en la observación de las
actividades que desempeñan los Stakeholders y en algunos casos en la participación de las mismas,
51
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
para así lograr analizar la mayor cantidad de información. En el caso del Laddering, se recomienda
su uso ya que incentiva a las personas a realizar sondeos por medio de preguntas, en que los
Stakeholders, en la mayoría de los casos participan en su elaboración, con el objetivo de desarrollar
por parte del analista una estructura organizada con las respuestas de las personas de tipo bipolar,
para realizar un proceso de análisis de información que necesita de mediano tiempo para su
realización.
5.4.4.5 Proyectos con restricción de tiempo largo
Cuando las restricciones de tiempo, apuesta por un proyecto a largo plazo, permite que las
actividades del proyecto tengan más tiempo para su realización. Esto permite que la etapa de
obtención y análisis de requerimientos pueda ejecutarse de manera más metódica y sin la presión
que implica el tiempo, de la misma manera el analista se verá enfrentado a personas Cerradas,
abiertas y bipolares.
Cuando el analista se enfrente a personas de tipo cerrado y sin la presión de tiempo tras su espalda
para realizar levantamiento de información es recomendable hacer uso de técnicas como la
“Observación”, “Apprenticing” y “Prototyping” ya que se caracterizan por su alto grado de
Observación y análisis, en donde el analista mantiene una baja interacción con los Stakeholders. En
el caso de la observación se recomienda su uso debido a que el tiempo para efectuarla es largo y el
contacto con las personas es bajo, por ende el componente de análisis que esta posee y que está a
cargo del analista; implica de tiempo para su ejecución, ya que el mismo implica la no intervención
en los procedimientos que realizan los Stakeholders, simplemente implica educir información a
través de la observación. En el caso del Apprentincing, es recomendado para interactuar con
personas cerradas debido al bajo grado de interrelación con las personas, ya que el analista se limita
a aprender y a imitar las actividades de los Stakeholders en la organización, el mismo en su rol de
aprendiz solo interactúa con las personas para saber lo necesario y para poder ejecutar su rol, esta
técnica puede llegar a tomar bastante tiempo en su ejecución y otro más largo para hacer el
respectivo análisis. En el caso del Prototyping, es recomendado ya que fomenta entre los
Stakeholders, el tener un papel más activo en la especificación de requerimientos, logrando que
estos participen, cuestionado prototipos; los cuales les permitan establecer necesidades y brindan
información al analista. Al estar ligado a prototipos, la ejecución y análisis de los mismos conlleva
52
Ingeniería de Sistemas
ISTAR - CIS0830IS16
un gasto alto de tiempo, pero permitirá incentivar a las personas de tipo cerrado a interactuar mejor
con el analista y el proyecto.
El analista se enfrentara a personas de tipo abierto, de la mismas manera dispondrá de mucho
tiempo para poder interactuar con ellos, es debido a eso que se deben usar técnicas como las
“sesiones JAD” y el “Análisis de protocolos”, la cuales se caracterizan por interactuar y
interrelacionarse mucho con los Stakeholders, permitiendo explotar las bondades de las personas de
tipo abierto para un buen levantamiento de información, estas técnicas también necesitan de mucho
tiempo y debido a eso se acoplan muy bien a las restricciones de tiempo y personas. En el caso de
las sesiones JAD es recomendado su uso, ya que esta permite que una gran cantidad de personas de
la organización contribuyan, en este caso una gran cantidad de Stakeholders de tipo abierto, a
establecer necesidades y flujos de información mancomunadamente, de manera que el analista actué
como un guía y un observador permitiendo que las personas generen mucha información relevante
para el analista, esta técnica necesita de mucho tiempo para su preparación, ejecución y análisis. En
el caso del análisis de protocolos, se recomienda su uso debido al alto grado de interacción que se
establece entre las personas abiertas y el analista, ya que las personas se dedican a narrar sus
actividades mientras las realizan, permitiendo que analista pregunte en cualquier momento, con el
objetivo de resolver inquietudes o dudas, al ser una actividad que se ejecuta con cada persona, el
análisis puede durar mucho tiempo y cuando se tiene un grupo de personas grande lo es más aún.
Finalmente el analista se enfrentará a personas o grupos bipolares, la cuales se caracterizan por no
tener un comportamiento definido y al contar con el tiempo para el desarrollo de técnicas de
levantamiento de información es recomendable el uso de los “Grupos de trabajo” ya que esta
permite que los Stakeholders interactúen y se interrelacionen con todo tipo de personas. Esta
promueve una cooperación directa para lograr un entendimiento entre diferentes tipos de
personalidad. Esta técnica requiere de gran preparación y análisis, que le permitan al analista
manejar situaciones de enfrentamiento que tengan tinte político, además el analista de propender
por el dialogo franco y abierto, lo cual le permitan recoger la mayor cantidad de información.
5.4.5
Identificación de intereses y conflictos.
Los intereses y conflictos forman parte del desarrollo de todo proyecto, normalmente los conflictos
se generan en las etapas finales de los proyectos, cuando ya se ha desarrollado gran parte de las
actividades. Normalmente los conflictos se generan producto del choque de intereses de las
53
Personal
Memoria de Trabajo de Grado – Proyecto de Investigación
personas. Con el firme objetivo de promover la identificación de intereses de manera temprana, en
pro de guiar al analista para resolver los posibles conflictos y sacar provecho del uso de las técnicas
de levantamiento de información, se desarrolló una manera en que se le puede dar manejo a los
mismos.
5.4.5.1 Preparación de las técnicas a usar
En analista cuenta con técnicas que está en capacidad de estudiar y ejecutar con cada uno de los
Stakeholders identificados. El analista debe tener claras las restricciones de tiempo y lugar, las
herramientas a usar, además debe contar con la disponibilidad de tiempo de las mismas, ya que es
muy diferente la disposición a colaborar; al tiempo que tengan las personas para el desarrollo de las
actividades. Es por eso que se recomienda hacer un proceso de planificación de la aplicación de las
mismas, esto para que la preparación de cada una de las técnicas se facilite y se enfoque a preparar
los objetivos de cada una de las técnicas que se aplicara con cada uno Stakeholders o grupos de
Stakeholders.
Es indispensable que en el proceso de preparación de las técnicas, se plantee el objetivo de educir
los intereses personales y grupales que tienen los Stakeholders con la ejecución del proyecto de TI.
Es importante tener en cuenta el tiempo que se dispuso para la ejecución de las técnicas, ya que no
se puede gastar todo el tiempo que se planifico, en la ejecución de las mismas, en dilucidar los
intereses. Para ello plantee una pregunta de manera clara y sencilla, en la que se manifieste que se
desea conocer el interés o intereses personales e identificar los intereses grupales respecto al
proyecto de TI. Dependiendo de la técnica de levantamiento de información y su dinámica, dejamos
a criterio del Analista, el momento en que esta pregunta se debe realizar, además también el
momento y forma en que deban ser tomadas cada una de las apreciaciones acerca de los intereses.
Es aconsejable que se documente la mayor cantidad de información en la ejecución de las técnicas,
cada nota o dato puede representar un mejor entendimiento del contexto y del problema, lo cual
lleva a una buena especificación de requerimientos.
5.4.5.2 Identificando intereses
Identificar los intereses de las personas puede llegar a ser una tarea bastante dispendiosa y
engorrosa. Es por eso que se propone una manera sencilla de organizar dichos intereses, para poder
identificar conflictos entre los intereses.
54
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Asumimos que el analista ha elaborado una planificación y ejecución de las técnicas, por lo cual ya
dispone de datos e información que le permita elaborar un listado de intereses personales y grupales
que poseen los Stakeholders con los que aplico las técnicas de levantamiento de información.
Seguido el analista debe elaborar un listado de intereses generales, enumerándolos y organizándolos
como lo muestra un ejemplo en la siguiente tabla.
# Interés
Descripción del Interés
Nombre de la persona o grupo al que se
asocia el interés
P1
Mejorar la eficiencia de su trabajo
Arturo Peniche
P2
Desarrollar tareas más rápido, para poder salir
más temprano de su trabajo
Edilberto Sanchez
G1
Mejorar la comunicación entre las distintas
dependencias de la organización
Gerencia de Recurso Humanos
G2
Conocer los secretos de la competencia
Gerencia General
…
……………………………….
……………………………
…
……………………………….
……………………………
Pn
……………………………………..
…………………………….
Gn
…………………………………..
…………………….
Tabla 6 - Ejemplo lista de general de intereses
En la numeración de la tabla, la “G” significa grupal y la “P” significa personal, esto con el objetivo
de diferenciar unos con otros.
Los siguiente que el analista puede hacer es tomar los intereses que son similares o parecidos y
sintetizarlo en uno; es necesario que estos intereses sean escritos de manera genérica, sean claros y
de tal manera que agrupe a los intereses que el analista ha creído son parecidos o similares; de esta
manera el analista está procediendo y está pasando de tener intereses personales a tener intereses
55
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
generales, logrando así una depuración en los mismos. El analista no debe preocuparse si no
encuentra intereses parecidos o similares, ya que entre más diversidad de intereses se tengan, mejor
será la especificación de los requerimientos. Los siguiente a realzar por parte del analista, es
clasificar los intereses como realizables o no realizables. Cuando hablamos de realizables; se refiere
acerca de todos aquellos deseos de las personas o grupos que sean lógicos, tengan sentido y sean
alcanzables por el proyecto, los cuales se desea que sean satisfechos por la ejecución del proyecto,
NO Realizable
Realizable
una manera de hacer esto es como lo sugiere el ejemplo de la siguiente tabla.
# Interés
Descripción del Interés
Nombre de la persona o grupo al que se
asocia el interés
P1
Mejorar la eficiencia de su trabajo
Arturo Peniche
G1
Mejorar la comunicación entre
dependencias de la organización
…………
……………………………………..
…………………………
Gn
…………………………………..
…………………….
P2
Desarrollar tareas más rápido, para poder salir más
temprano de su trabajo
Edilberto Sanchez
G2
Conocer los secretos de la competencia
Gerencia General
…………..
…………………………………….
……………………………….
Pn
……………………………………..
…………………………….
las
distintas
Gerencia de Recurso Humanos
Tabla 7 - Ejemplo de agrupación de intereses
Una vez hecha esta clasificación, se le sugiere al analista tomar los intereses que se catalogaron
como realizables y efectué un priorización, teniendo en cuenta el tiempo que se tiene para poder
satisfacerlo, siempre teniendo en cuenta las restricciones de tiempo que tiene el proyecto TI.
56
Ingeniería de Sistemas
ISTAR - CIS0830IS16
Al tener el analista organizados todos los intereses tanto personales y grupales es conveniente
guardarlos ya que servirán en las etapas de negociación, por eso es indispensable no borrar o perder
ninguno de los listados de intereses que se han planteado.
5.4.5.3 Identificando conflictos
La razón principal de todo conflicto es el roce y contradicción de intereses de las personas, a través
de la historia humana; estos han generado todo tipo de inconvenientes y han sido una de las
principales razones para que se desarrollaran guerras en el mundo. En el ámbito de los proyectos
consideramos que es una de las principales razones en la mortandad de los mismos. Se cree que una
temprana identificación de conflictos de intereses, contribuye al desarrollo del proyecto y a una
buena especificación de los requerimientos. El hombre ha desarrollado teorías y métodos para la
mediación y la solución de los mismos, por tal razón se debe guiar al analista de requerimientos en
su identificación.
Basados en los intereses recolectados y con los tipos de personas se sugiere al analista realizar un
cruce entre todos los intereses con el objetivo de observar algún tipo de contradicción o roce, para
poder diligenciar la tabla que se muestra a continuación.
P1
P1
P2
.
.
P2
A,C,(+)
.
.
.
.
Pn
A,B,(-)
G1
A,A,(+)
G2
A,C,(-)
.
.
.
.
Gn
A,B,(+)
.
.
C,B,(-)
C,A,(+)
C,C,(+)
.
.
C,B,(-)
.
.
.
.
.
.
.
.
.
.
.
.
B,A,(-)
B,C(-)
.
.
B,B,(+)
A,C,(+)
.
.
A,B,(-)
.
.
C,B,(+)
.
.
.
Pn
G1
G2
.
.
.
Gn
Tabla 8 - Identificación de conflictos
P – Interés Personal
G – Interés Grupal
A – Abierto, C – Cerrado, B – Bipolar
(+) Conflicto, (-) NO Conflicto
57
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
En la tabla se muestra que están referenciados cada uno de los conflictos tanto grupales, como
personales en donde muestra el tipo de persona que lo posee y señala la posibilidad de conflicto
entre los mismos. En la tabla la “A” significa que la persona o grupo con ese interés es de tipo
abierto, la “B” que es de tipo bipolar y la “C” que es de tipo cerrado. En la tabla el (+) significa que
existe un posible conflicto entre los intereses y el (-) que no existe un conflicto. Por lo tanto la
interpretación que se da las parejas consignadas en las casillas de las tablas, es que la primera letra
aduce el tipo de persona del interés vertical, la segunda letra el tipo de persona del interés horizontal
y por último, el signo significa si existe algún tipo de conflicto entre los intereses.
Diligenciar esta tabla puede llegar a ser algo engorroso si se poseen muchos intereses, por ende es
recomendable hacer priorizaciones más minuciosas como por ejemplo, realizándolas para los
intereses grupales y otra para los personales, o para los intereses más importantes entre grupales y
personales.
La tabla de identificación de conflictos guiará al analista de requerimientos en el proceso de
negociación ya que brindara al analista la información necesaria para poder elegir la técnica o
método de negociación para lograr un acuerdo entre las partes, ya que le proporcionara con qué tipo
de personas deberá mediar.
5.4.6
Selección de la técnica o estrategia de negociación
La naturaleza de la negociación radica en la búsqueda de acuerdos para la satisfacción de las partes
en conflicto. En el caso de los proyectos el analista debe tomar el rol de mediador para lograr un
acuerdo que se verá reflejado en la especificación de requerimientos y a largo plazo en la
culminación del proyecto.
Se asume que el analista cuenta con gran cantidad de información, entre ella los intereses y los
conflictos que se generan entre ellos, estos se encuentran consignados en la tabla de identificación
de conflictos que se aconseja diligenciar.
Basados en la tabla de identificación de conflictos, el analista debe observar que cantidad de
conflictos debe mediar para su solución, por lo tanto de los conflictos encontrados el analista debe
observar que tipo de personas o grupos generan el conflicto. En este Contexto el analista puede
enfrentarse a situaciones de choque entre personas Abiertas y Cerradas, entre Abiertas y Bipolares,
58
Ingeniería de Sistemas
ISTAR - CIS0830IS16
entre Cerradas y Bipolares, entre Cerradas y Cerradas, Bipolares y Bipolares y finalmente entre
Abiertas y Abiertas.
En el caso de enfrentarse que en su mayoría son (Abiertas – Abiertas) y (Abiertas – Bipolares), el
analista debe entender que se puede ver una situación Gana-Gana, en la que la que la mayoría de las
personas tienden a colaborar para llegar a un mutuo acuerdo entre las partes; por tal razón es
recomendable hacer uso de metodologías como EasyWinWin, la cual busca acuerdos mutuamente
satisfactorios, para mayor información remítase al Anexo B.
En el caso de presentarse en su gran mayoría como (Cerradas – Cerradas) y (Cerradas - Bipolares),
el analista debe entender que se presenta una situación Pierde-Pierde, en la que las partes pueden
asumir una orientación competitiva que haga sentir a la otra que no satisfacen sus intereses; por ello
es recomendable hacer uso de la teoría W, que insta porque todo el mundo sea ganador, para mayor
información remítase al Anexo B.
En el caso de presentarse en su gran mayoría como (Abiertas- Cerradas) y (Bipolares - Bipolares),
el analista debe entender que se presenta ante una situación Gana-Pierde, en la que las partes buscan
obtener su beneficio propio a costillas de los demás; por ello es recomendable hacer uso de del
modelo WinWin, el cual procura generar situaciones de ganancia y acuerdos, para mayor
información remítase al Anexo B.
Finalmente se ha brindado al analista de requerimientos una serie de consejos que le permiten
desarrollar técnicas de levantamiento de información, lo cual lo conducen a conocer la organización
y sus miembros, logrado saber en qué situaciones pude utilizar las técnicas de levantamiento de
información y las de negociación de conflictos en un proyecto de tecnologías de información.
Contribuyendo en la elaboración de las bases que permitan al analista realizar un proceso de
especificación más claro y conciso, para que al final de proyecto, se efectuara una ágil validación de
los requerimientos. Seguido se deja a conveniencia del analista el uso de los medios o plantillas
para la especificación de los requerimientos que a bien prefiera usar. Dejando en claro que la
anterior guía aporta una buena base de para su elaboración, teniendo en cuenta que la información
recolectada permitirá realizar una especificación con requerimientos que sean Completos,
59
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
Correctos, Feasibles, Necesarios, Priorizables, No Ambiguos, Verificables, Consistentes,
Modificables y permitan ser trazables [52].
5.5 Caso de estudio
5.5.1
Escenario
Una empresa diseñadora e integradora de soluciones de telecomunicaciones, con presencia en
Latinoamérica y Estados Unidos; la cual cuenta con representación y distribución de marcas
reconocidas de soluciones a nivel empresarial, decide ampliar su fuerza de trabajo, integrando a su
equipo un ingeniero de sistemas recién graduado; cuyo principal objetivo es apoyar a la
organización en una de sus sedes a nivel Latinoamérica; en todo lo relacionado con el levantamiento
de requerimientos de los proyectos que se desarrollan en dicha sede; con el objetivo a largo plazo de
ayudar y contribuir a toda la organización en general.
Dicho ingeniero se verá enfrentado a las siguientes situaciones:
-
Los procesos a nivel organizacional no se encuentran levantados, por tal razón los mismos
no se están documentados y dependen de las personas que hacen parte de la organización.
-
Los proyectos en la organización van desde el diseño de soluciones hasta integraciones con
otros sistemas, estos sufren de muchos cambios en el desarrollo del mismo, los cuales
representan incrementos en tiempo y costo, también en el alcance del mismo. Para la fase
inicial, simplemente se acuden a técnicas de levantamiento de información convencionales
la cuales brindan información para los proyectos, pero no en todos la necesaria para el
desarrollo de los mismos; lo cual se ve reflejado en el cambio de los mismos y en su
alcance.
5.5.2
Desarrollo
Llamaremos Juan al estudiante recién graduado de ingeniería de sistemas, que en su primer día
observa a nivel general como es el flujo de trabajo en la sede en la cual fue contratado, de igual
manera observa las personas y los roles que desarrollan las mismas en la organización. Seguido
evidencia y comienza a entender su rol dentro de la organización. En este primer día se da cuenta
que todos los miembros de la organización hacen parte de todos los procesos que le permiten a las
mismas desarrollar su labor cada día. Ese mismo día Juan pregunta fuentes de información que
60
Ingeniería de Sistemas
ISTAR - CIS0830IS16
pueda indagar y donde se pueda guiar para ambientarse con la organización, finalmente evidencia
que la principal fuente de información son las personas con las que tendrá que trabajar.
Juan es consciente de su trabajo, también que hace parte del equipo técnico en la organización, el
cual tendrá como principal objetivo satisfacer cada una de las necesidades del cliente interno y
externo, razón por la cual en pocos días tendrá como meta organizar y documentar el flujo de
información de la organización, por esta razón fue contratado Juan.
Juan lleva ocho días de labores en la empresa y su jefe le ha pedido que de manera general realice
un informe de su proceso y lo que ha visto en la organización. Juan al tener mediano conocimiento
de la organización comenta lo siguiente:
-
Se observa que dentro de la organización todos los involucrados forman parte de la base
del conocimiento, pero no existe evidencia o documentación respecto a la labor de cada una
de las personas.
-
El flujo de información se limita a los permitidos por los medios electrónicos, en este caso
al correo electrónico.
-
De la misma manera observa que el manejo de los requerimientos se hace de manera
genérica tanto para los clientes externos e internos, esto se debe a la experiencia que tiene
cada una de las personas que forman parte del equipo técnico.
Al evidenciar lo anterior el jefe, aduce que es consiente de este tipo de falencias, razón por la cual
se ha tomado la decisión de permitir que Juan aporte desde su punto de vista como ingeniero de
sistemas a la solución de esta problemática. Para el desarrollo de esta labor su jefe le da
aproximadamente un periodo de dos meses, para que este evidencie el resultado de su trabajo.
Seguido Juan propone implementar el desarrollo de un proyecto que involucre a la totalidad de los
miembros de la compañía, razón por la cual hace uso de la ingeniería de requerimientos para diseñar
este, buscando en que cada uno de sus miembros estén satisfechos y le permita desarrollar cada una
de sus actividades dentro de la compañía, con el principal objetivo de hacer más eficiente el trabajo
de todos los miembros.
61
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
Para el desarrollo de este proyecto en su etapa de ingeniería de requerimientos; el estudiante decide
hacer uso de la “Guía para interactuar con Stakeholders en el proceso de ingeniería de
requerimientos”.
5.5.3
Proceso
La guía enmarca como primer proceso, hacer un conocimiento del proyecto y de la organización;
para ello Juan ya ha abonado un gran terreno; debido a que se ha valido de la poca información que
ha encontrado en sus días de labores dentro de la organización. De esto Juan puede concluir que es
una organización jerárquica que se encuentra distribuida en diferentes países de latino américa;
donde cuyo principal objetivo es la venta de productos y servicios que ayude a las organizaciones a
mejorar y bajar los costos de sus comunicaciones , que está dividida en tres grandes secciones,
llámese comercial, administrativa y técnica. En ese orden de ideas Juan evidencia que se debe crear
un sistema que le permita a la organización mejorar el flujo de información de la misma, por lo
tanto se clasifica como un proceso de desarrollo que tiene una incidencia alta en la organización.
Como segundo gran proceso, la guía aduce que se deben identificar cada uno de los involucrados o
Stakeholders. En este caso, al ser esta una oficina pequeña, Juan tiene en cuenta a todas las
personas; entendiendo cuál es su papel en la sección y dentro de la organización, ya que contribuyen
en los flujos de información en la organización. En este momento Juan debe tiene claro que va ser
partícipe de mucha información, por lo cual la guía le ha ayudado a hacer y tener un buen manejo
de la ética y las implicaciones legales, dejando en claro cuáles son los acuerdos legales que posee la
organización. A este punto Juan ha tenido muy en cuenta el acercamiento a las personas y ha
generado ambientes de tertulia, comprensión y compañerismo ; lo cual le permitirá tener un mejor
acercamiento de a la información.
En ese orden ideas juan tiene un conocimiento de la organización y sus integrantes, por lo tanto
evidencia que existe un 40% de personas, las cuales Juan cataloga como bipolares y en un 35%,
juan las cataloga como abiertas, quedando un 25 % de personas cerrados. En este punto Juan sabe
que su restricción de tiempo es corta por lo tanto sabe que tiene que usar técnicas como los
cuestionarios y los puntos de vista para las personas de tipo cerrado dentro de la organización. En
el caso de las personas de tipo abierto puede usar entrevistas y los escenarios para levantar
información y por último en el caso de las personas bipolares hacer uso de técnicas como los
62
Ingeniería de Sistemas
ISTAR - CIS0830IS16
talleres, requirements wokshops o la lluvia de ideas que le permitan recolectar información de
manera más eficaz.
En este momento Juan ya ha experimentado cada una las técnicas que la guía aconseja de acuerdo a
la situación particular y posee la información necesaria para construir un análisis de la información
que posee, en este punto Juan debe tener identificadas cuales son las principales necesidades y
cuáles de estas son comunes, por ende se deben catalogar las necesidades como individuales y
grupales. Una vez hechas estas se debe identificar los conflictos que se generan entre las
necesidades. Seguido Juan procedió a plasmar dichas necesidades en la matriz de identificación de
conflictos de acuerdo al tipo de persona y al conflicto en el que se encuentra con las demás
necesidades.
Hecho esto, Juan observo que existían muchas necesidades, pero más personales que grupales
razón por la cual genero muchos conflictos, por lo tanto opta por implementar el modelo de
negociación WinWin en donde cada una de las personas llegan acuerdos en pro de un beneficio
general, en este punto Juan considera que tiene las bases suficientes para generar unos
requerimientos claros que le permitan el diseño de un sistema que contribuya a la mejora y
evolución de la organización. Una vez realizado esto, Juan implemento la guía para desarrollar el
proceso interno a nivel de cada sección de la compañía.
63
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
6. CONCLUSIONES Y TRABAJOS FUTUROS
6.1 Conclusiones
Después de culminar el desarrollo de este trabajo de grado se puede concluir lo siguiente:
-
La plantilla para la descripción de técnicas de levantamiento de información agrupa los
elementos que permiten lograr una descripción técnica, afable y especializada de las
técnicas, dejando vincular elementos visuales que permiten una descripción completa de las
técnicas. El usar el software de MindManager permitió que la misma pueda ser observada
en diferentes formatos, lo cual facilita su publicación.
-
El hacer uso de la plantilla para la descripción de por lo menos 7 técnicas o herramientas
para el levantamiento de información, permitió que se pudiera vincular a la misma el uso de
notaciones graficas como es el de BPMN, que contribuyo para enriquecer y describir él
COMO se desarrollan cada una de las actividades que hacen parte de las 7 técnicas.
-
La investigación acerca de las Técnicas de levantamiento de información y de las
estrategias de negociación, forjaron las base para el desarrollo de la guía que enfoca a los
analistas de requerimientos de proyectos de tecnologías de información en la relevancia que
tiene el confeccionar un buen levantamiento de información y un buen manejo de los
conflictos de intereses para ejecutar un muy buen proceso de Ingeniería de requerimientos.
-
Al estar ubicada la guía en las primeras fases tanto del proyecto, como del proceso de
ingeniería de requerimientos, centra al analista de requerimientos en la importancia que
tiene el contacto con las personas y el manejo de las relaciones con las mismas.
-
El desarrollo de la investigación completo más de un año, este comenzó mirando hacia
objetivos completamente diferentes y guiado en principio por un capitán diferente, después
de muchos altibajos se logró elaborar una serie de productos que comienzan desde una
agradable página web donde se alberga resultado de esta investigación y una gran cantidad
de productos, pasando por un repositorio de información que a la fecha cuenta con más de
135 revisiones, lo cual indica que se realizó un buen trabajo al comando de un gran capitán
y un marinero que colaboro para llevar esta investigación a buen destino.
-
A pesar de haber contado con gran cantidad de tiempo en la investigación el objetivo de
realizar una prueba piloto de la guía no se pudo llevar a cabo por dos razones; la primera
fue por no haber estado terminada a tiempo mientras me encontraba laborando y la segunda
64
Ingeniería de Sistemas
ISTAR - CIS0830IS16
fue porque no se contó con la aprobación por parte de alguna organización después de estar
terminada para su prueba. Sin embargo, la guía propone pasos fáciles de realizar que se
fundamentan en la investigación realizada.
-
El crecimiento agigantado de las organizaciones en la adaptación tecnológica insta a
elaborar proyectos tecnológicos en corto tiempo, que satisfaga a cabalidad las necesidades
de las personas es por esto que la guía brinda un aporte a metodologías de requerimientos,
enfatizándose en el las etapas de Obtención y análisis de requerimientos.
6.2 Trabajos Futuros
El siguiente trabajo de grado puede ser tomado como la base para el desarrollo de una metodología
que unifique y generalice el proceso de ingeniería de requerimientos en los proyectos de tecnologías
de información.
De la misma manera puede ser completada, para ser convertida en una guía metodológica en la que
las fases de especificación y validación de requerimientos deben ser desarrolladas, logrando así
ampliar y completar todas las fases.
Describir y publicar el restante de técnicas con la plantilla, dejando accesible las mismas en un sitio
público, en donde puedan ser evaluadas, criticadas y enriquecidas tanto la plantilla como la
descripción del restante de técnicas de levantamiento de información.
Enriquecer el proceso de ingeniería de requerimientos con el uso de BPMN para fomentar un mejor
entendimiento de cada una de las actividades que compone el mismo, basándose en la descripción
del COMO, realizado en la descripción de las 7 herramientas de levantamiento de información.
Desarrollar un modelo matemático de fácil entendimiento, que ayude a evaluar los conflictos de
interés que se generan en los proyectos, para poder tomar decisiones acerca de la estrategia a usar
para la negociación y solución de los mismos.
65
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
GLOSARIO
-
Stakeholders: son las personas que están involucradas y tienen intereses en el proyecto, se
les puede nombra como los interesados y generalmente son las personas que influencian los
requerimientos de acuerdo a sus intereses.
-
Stockholder: es la persona que se encuentra en un nivel superior al de los Stakeholders, sin
dejar este uno. Normalmente es el dueño del negocio o los altos cargos de la organización
poseen un poder decisión alto.
-
TI: este es el acrónimo de Tecnologías de Información.
-
TIC: este es el acrónimo de Tecnologías de Información y Comunicación.
-
Interés: es la ganancia o beneficio que puede obtener un grupo o individuo de alguna
acción en particular.
-
BPMN: Business Process Management Notation
66
Ingeniería de Sistemas
ISTAR - CIS0830IS16
REFERENCIAS
[1] Chaves, M. A., La ingeniería de requerimientos y su importancia en el desarrollo de
proyectos de software, Revista InterSedes © Universidad de Costa Rica, Volumen VI,
Número 10, (2005).
[2] Young, R. R., The Requirements Engineering, Handbook, Artech House, (2004).
[3] Glinz, M., y Wieringa. R. J., Stakeholders in Requirements Engineering, IEEE, Software,
Vol 24, No. 2, (2007).
[4] Bin, M., y Zur, M., Information Requirements of Process Stakeholders: A Framework to
Evaluate Process Monitoring and Controlling Applications, Howe School of Technology
Management, Stevens Institute of Technology, (2004).
[5] Mella, O., Naturaleza y orientaciones teórico – metodológicas de la investigación
cualitativa,(1998),
Disponible
en:
http://www.epiclin.unicauca.edu.co/archivos/Naturaleza%20de%20la%20Investigacion%20
cualitativa.pdf
[6] Alexander, I., y Stevens, R., Writing Better Requirements, Pearson Education Limited,
(2002).
[7] Giné, J., y Prats, J., ¿Nuevas tecnologías para el desarrollo humano?, UOC (2001),
Disponible en: http://www.uoc.edu/web/esp/art/uoc/0107027/desarrollo.html
[8] Sharp, H., Finkelstein, A., Galal, G., Stakeholder Identification in the Requirements
Engineering
Process,
IEEE,
(1999),
Disponible
en:
http://eprints.ucl.ac.uk/744/1/1.7_stake.pdf
[9] Alexander, I., y Robertson S., Understanding Project Sociology by Modeling Stakeholders,
IEEE, (2004)
[10]
Alexander, I., y A. Farncombe, JBA, Stakeholder Analysis Template, Systems
Engineering Foundation Course, (2003).
[11]
y
Ministerio de telecomunicaciones, Plan Nacional de Tecnologías de la Información
las
Comunicaciones,
(2008),
Disponible
en:
http://www.colombiaplantic.org.co/medios/docs/PLAN_TIC_COLOMBIA.pdf
67
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
[12]
Imobix, II Encuentro Iberoamericano Sobre Objetivos Del Milenio de Naciones
Unidas y Tecnologías de la Información y Comunicaciones, la Brecha de Paradigma,
(2007),
Disponible
en:
http://www.ahciet.net/portales/comun/pags/agenda/eventos/161/Imobix_Final.pdf
[13]
Nuseibeh, B., y Easterbrook, S., Requirements Engineering: A Roadmap, IEEE,
Disponible en: http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf
[14]
Standish Group Report, CHAOS, (1995), Propósitos Académicos, Disponible en:
http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
[15]
Bruegge, B., y Dutoit, A., Object-Oriented Software Engineering: Conquering
Complex and Changing Systems, Prentice Hall (1999).
[16]
Naciones Unidas, INFORME SOBRE LA ECONOMÍA DE LA INFORMACIÓN,
Ciencia y tecnología para el desarrollo: El nuevo paradigma de las TIC, Nueva York y
Ginebra, (2007)
[17]
Project Management Institute, GUÍA DE LOS FUNDAMENTOS PARA LA
DIRECCIÓN DE PROYECTOS (GUÍA DEL PMBOK®) Cuarta edición, Newtown Square,
Pennsylvania: Project Management Institute, Inc, 2008.
[18]
H. Guerra, “La negociación y el manejo de conflictos en las organizaciones”,
Episteme # 13, enfoque Interdisciplinario, Universidad del Valle de México, 2008, [en
línea].
Disponible
en:
http://www.uvmnet.edu/investigacion/episteme/numero13_09/enfoque/a_negociacion.asp ,
[Consultado: Agos. 20, 2009].
[19]
A. Aybüke, y C. Wohlin, Engineering and Managing Software Requirements,
Berlín: Springer, 2005.
[20]
lAAP, “¿Qué es la negociación?”, Mejores Proyectos, [en línea]. Disponible en:
http://iaap.wordpress.com/2007/05/17/%C2%BFque-es-la-negociacion/
[21]
B. Boehm, R. Ross, “Theory-W software project management: a case study”, ICSE
'88: Proceedings of the 10th international conference on Software engineering, IEEE
Computer Society Press, Abril, 1988.
[22]
S, McConnell, “Rapid development: taming wild software schedules”, Redmond,
Washington, Microsoft Press, 1996.
68
Ingeniería de Sistemas
[23]
ISTAR - CIS0830IS16
J, Schekkerman, B.Sc. “The (Enterprise) Architecture Process Cycle”, Institure for
Enterpirse Architecture Develpments, January , 2001, [en línea].
Disponible en :
http://www.enterprisearchitecture.info/Images/WEB%20Architecture%20Process%20Cycle/WEB%20Architectu
re%20Process%20Cycle%202001-02-01.htm
[24]
M, Moreno, “TEMA 1 - Visión general de la administración de proyectos”,
Administración de proyectos Informáticos, Departamento de Informática y Automática,
Universidad
de
Salamanca,
[en
línea].
Disponible
en:
http://avellano.usal.es/~mmoreno/APITema1.pdf
[25]
P, Grünbacher y B, Boehm, “EasyWinWin: a groupware-supported methodology
for requirements negotiation”, ESEC/FSE-9: Proceedings of the 8th European software
engineering conference held jointly with 9th ACM SIGSOFT international symposium on
Foundations of software engineering, ACM, 2001.
[26]
B. Boehm, y H. Kitapci, “The WinWin Approach: Using a Requirements
Negotiation Tool for Rationale Capture and Use”, Rationale Management in Software
Engineering, Springerlink
[27]
DACS,”
REQUIREMENTS
TRADE-OFFS/NEGOTIATIONS”,
SOFTWARE
ACQUISITION GOLD PRACTICE, DACS Golds Practice Website, [en línea]. Disponible
en : http://www.goldpractices.com/practices/rto/index.php
[28]
K.Thomas. “Conflict and Conflict Management” In Handbook of Industrial and
Organizational Psychology, ed. M.D. Dunnette. Chicago: Rand McNally, 1976
[29]
X. Ferré, “Marco de Integración de la Usabilidad en el Proceso de Desarrollo
Software”,[en línea]. Disponible en: http://oa.upm.es/440/1/XAVIER_FERRE_GRAU.PDF
, [Consultado: Jul. 26, 2009].
[30]
The Software Engineering Institute (SEI), “Domain Analysis”, Carnegie Mellon
University, Jan. 11, 2007, [en linea]. Disponible en: http://www.sei.cmu.edu/domainengineering/domain_anal.html, [Consultado: Jul. 26, 2009].
[31]
J. Goguen y C. Linde, “Techniques for Requirements Elicitation”, Proceedings,
Requirements Engineering '93, pp. 152-164, 1993, [en línea]. Disponible en:
http://www.cs.brown.edu/courses/cs190/2006/assignments/goguen[1].pdf, [Consultado: Jul.
26, 2009].
69
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
[32]
B. Gonzales, M. Laguna y J. Sampaio, “Aplicaciones de la Teoría de Constructos
Personales
a
la
Elicitación
de
Requisitos”,
[en
línea].
Disponible
en:
http://www.giro.infor.uva.es/Publications/2004/GLL04/AplicaTCPaGoal.pdf, [Consultado:
Jul. 26, 2009].
[33]
N. Niu y S. Easterbrook, “Discovering Aspects in Requirements with Repertory
Grid”, [en linea]. Disponible en: http://www.cs.toronto.edu/~sme/papers/2006/NiuEA06.pdf, [Consultado: Jul. 26, 2009].
[34]
“Card Sorting: A cuántos usuarios se necesita evaluar”, ProyectoWeb - Comunidad
Profesional sobre Diseño de Experiencia de Usuario, Oct, 2001. [en línea]. Disponible en:
http://www.proyectoweb.org/boletin/card-sorting-a-cuantos-usuarios-se-necesitaevaluar.html, [Consultado: Jul. 26, 2009].
[35]
“Lluvia
de
ideas
(Brainstorming)”,
[en
línea].
Disponible
en:
http://cv.uoc.edu/UOC/a/moduls/90/90_156/programa/main/viu/tecniques/viu30.htm#inici,
[Consultado: Jul. 26, 2009].
[36]
M. Escalona y N. Koch, “Ingeniería de Requisitos en Aplicaciones para la Web –
Un estudio comparativo”, Universidad de Sevilla, Dic, 2002, [en línea]. Disponible en:
http://www.lsi.us.es/docs/informes/LSI-2002-4.pdf, [Consultado: Jul. 26, 2009].
[37]
EBG Consulting, Inc, “Requirements Workshops”,2005, [en linea]. Disponible en:
http://www.ebgconsulting.com/Services/MoreInfoOnWorkshops-EBG.pdf,
[Consultado:
Jul. 26, 2009].
[38]
I. Sommerville, Ingeniería de Software, Séptima edición, Madrid, Pearson
Educación, 2005.
[39]
L. Nguyen y G. Shanks, “Using Protocol Analysis to Explore the Creative
Requirements
Engineering
Process”,
[en
Linea].
Disponible
en:
http://epress.anu.edu.au/info_systems02/mobile_devices/ch07.html, [Consultado: Jul. 26,
2009].
[40]
Xplore
U. Akbar, “Empirical Studies of Requirements ValidationTechniques”, IEEE
Digital
Library.
[en
línea].
Disponible
en:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4909209&isnumber=4909154,
[Consultado: Jul. 27, 2009]
70
Ingeniería de Sistemas
[41]
ISTAR - CIS0830IS16
K. Kendall y J. Kendall, “Análisis y diseño de sistemas”, Sexta Edición, México,
Pearson Educación, 2005, pp. 151-160.
[42]
J. Lee y K, Hsu, “Modeling Requirements with Goals in Virtual University
Environment
*”,
IEEE
Xplore
Digital
Library.
[en
línea].
Disponible
en:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=897227&isnumber=19427,
[Consultado: Jul. 27, 2009]
[43]
IEEE
A. Sutcliffe, “RE 2003 Mini-tutorial: Scenario-based Requirements Engineering”,
Xplore
Digital
Library.
[en
línea].
Disponible
en:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1232776&isnumber=27626,
[Consultado: Jul. 27, 2009]
[44]
A. Miranda, “Guía Metodológica para la recolección de requerimientos a
distancia”, Trabajo de Grado para optar el título de Ingeniero de Sistemas, Pontificia
Universidad Javeriana, 2006, Pág. 58-86
[45]
Vol
M, Barry, “SMART requirements”, Napier University, Software Engineering Notes,
20
#
2,
ACM
SIGSOFT,
[en
línea].
Disponible
en:http://www.win.tue.nl/~wstomv/edu/2ip30/references/smart-requirements.pdf.
[46]
M, González. “Importancia de la tecnología en el mundo actual”, 1996, [en línea].
Disponible en: http://www.sg.inter.edu/lisc/students/mgonzalez.html
[47]
Guide to the Software Engineering Body of Knowledge (SWEBOK), CHAPTER 2
SOFTWARE
REQUIREMENTS,
IEEE,
Computer
Society,
Disponible
en
http://www.computer.org/portal/web/swebok/htmlformat
[48]
C, Pacheco. “Identificación de Stakeholders en la ingeniería de requisitos”, Trabajo
de Investigación tutelado, Universidad Politécnica – Madrid, 2005, [en línea] Disponible
en: http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Pacheco_Aguero.pdf.
[49]
BPMN 1.2, “Business Process Modeling Notation (BPMN)”, Object Management
Group, Disponible en: http://www.omg.org/spec/BPMN/1.2/PDF.
[50]
YouTube, Sitio Web de intercambio de videos, “Canal con videos de la explicación
de los procesos en BPMN”, Disponible en: http://www.youtube.com/user/meragars#p/u
[51]
SWEBOK, Guide to the Software Engineering Body of Knowledge, 2004 Version,
IEEE, Disponible en: http://www.computer.org/portal/web/swebok
[52]
Wiegers, K, “Software Requirements”, Second Edition, 2003, Microsoft Press
71
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
[53]
IEEE Std610.12-1990, IEEE Standard Glossary of Software Engineering,
Terminology, IEEE, 1990.
[54]
Hood. C, Wiedemann. S, Fichtinger.S y Pautz. U, “Requirements Management”,
Berlin, 2007, Springer.
[55]
Sommerville, I, y Sawyer.P, “Requirements Engineering: A Good Practice Guide”.
Chichester, England: John Wiley & Sons, 1997
[56]
Goldsmith R, “Discovering Real Business Requirements For Software Project
Success”, Artech House,2004
[57]
Sommerville, I. y Kotonya, G. “Requirements Engineering – Processes and
Techniques”, John Wiley & Sons, UK. 1998
[58]
Martin.S, Aybüke. A, Jeffery.R y Paech3.B, “Requirements Engineering Process
Models in Practice”, School of Information Systems, Technology and Management,
University of New South Wales.
[59]
Macaulay, L. A. “Requirements Engineering”, Springer-Verlag, 1996.
[60]
Suzanne.W y Robertson.J, “The Volere requirements process model”, Volere,
disponible en: http://www.volere.co.uk/processdesign.htm.
[61]
Suzanne.W y Robertson.J, “Mastering the Requirements Process”, Second Edition,
Addison Wesley Professional, 17 de Marzo de 2006.
[62]
Dictionary of Engineering, Second Edition, McGraw-Hill, 2003.
[63]
Báez, G y Barba. S, “Metodología DoRCU para la Ingeniería de Requerimient”, Instituto
Superior Politécnico "José Antonio Echeverría", La Habana, CU, Facultad de Ciencia y Tecnología,
Universidad Autónoma de Entre Ríos, AR.
[64]
Merchán.L, Urrea. A y Rebollar.R, “Definición de una metodología ágil de
ingeniería de requerimientos para empresas emergentes de desarrollo de software del suroccidente colombiano”, Universidad de San Buenaventura, Cali, Colombia.
[65]
Ahmad, S, “Negotiation in the Requirements Elicitation and Analysis Process”,
School of Computer Science and Software Engineering The University of Western
Australia.
[66]
Wiegers.K , “More About Software Requirements: Thorny Issues and Practical
Advice” , Microsoft Press © 2006
72
Ingeniería de Sistemas
[67]
ISTAR - CIS0830IS16
Construx Software, “Requirements Toolbox”, Version 6, Construx Software, Inc.,
2003-2007
[68]
De Vita.N, “TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN PARA LAS
ORGANIZACIONES DEL SIGLO XXI”, Instituto Universitario de Tecnología de
Maracaibo. 2008.
73
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
ANEXOS
Anexo A. Listado de Técnicas de Levantamiento de Información
En formato DOC, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_1Listado_de_Tecnicas_de_levantamiento_de_Informacion.docx
En formato PDF, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_1Listado_de_Tecnicas_de_levantamiento_de_Informacion.pdf
Anexo B. Modelos y métodos de Negociación de requerimientos
En formato DOC, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_AListado_de_Tecnicas_de_levantamiento_de_Informacion.docx
En formato PDF, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_AListado_de_Tecnicas_de_levantamiento_de_Informacion.pdf
Anexo C. Descripción en BPMN de las 7 técnicas de levantamiento de información
seleccionadas, elaboradas en TIBCO estudio (Archivos XPDL). Disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_CTecnicas%20con%20BPMN.zip
Anexo D. Documentación HTML de la descripción en BPMN de las 7 técnicas de recolección
disponible para descargar en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_DDocumentacion_Tecnicas_BPMN.zip
Disponible para ver en línea en:
JAD (Joint Application Development)
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/JAD.html
Domain Analysis
74
Ingeniería de Sistemas
ISTAR - CIS0830IS16
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/DomainAnalysis.html
Card Sorting
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/CardSorting.html
Apprenticing
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/Apprenticing.html
Protocol Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/ProtocolAnalysis.html
Task Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/TaskAnalysis.html
Viewpoints
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Tecnicas%20con%20B
PMN/Exports/Process%20Documentation/ViewPoints.html
Anexo E. Videos de descripción en formato AVI de los procesos BPMN, Explicación de las
técnicas 7 técnicas seleccionadas, disponible para descargar en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_EVideos_descripcion_BPMN.zip
Disponible para observar en:
JAD (Joint Application Development)
http://pegasus.javeriana.edu.co/~CIS0830IS16/JADVideo.html
Domain Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/ADOMAINVideo.html
Card Sorting
http://pegasus.javeriana.edu.co/~CIS0830IS16/CSORTINGVideo.html
Apprenticing
http://pegasus.javeriana.edu.co/~CIS0830IS16/APPRENTICINGVideo.html
Protocol Analysis
75
Memoria de Trabajo de Grado – Proyecto de Investigación
Personal
http://pegasus.javeriana.edu.co/~CIS0830IS16/PANALYSISVideo.html
Task Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/TANALYSISVideo.html
Viewpoints
http://pegasus.javeriana.edu.co/~CIS0830IS16/VIEWPOINTSVideo.html
Anexo F.
Referencias en formato BIB, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/propuesta_guia/Referencias[CAMA]
.bib
Anexo G. Plantilla de descripción de técnicas de levantamiento de información en formato
MMAP y en formato SWF, disponible para descargar en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_GPlantilla_Descripcion_Tecnicas_de_levantamiento_de_Informacion_V2.zip
Disponible para observar en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/plantillas.html
Anexo H. Descripción de las 7 técnicas de levantamiento de información, basado en la
plantilla de descripción en formato MMMAP y en formato SWF disponible para
descargar en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_HDescripcion_Tecnicas_de_levantamiento_de_informacion_con_plantilla.zip
Disponible para observar en:
JAD (Joint Application Development)
http://pegasus.javeriana.edu.co/~CIS0830IS16/JAD.html
Domain Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/ADOMAIN.html
Card Sorting
http://pegasus.javeriana.edu.co/~CIS0830IS16/CSORTING.html
Apprenticing
http://pegasus.javeriana.edu.co/~CIS0830IS16/APPRENTICING.html
Protocol Analysis
http://pegasus.javeriana.edu.co/~CIS0830IS16/PANALYSIS.html
Task Analysis
76
Ingeniería de Sistemas
ISTAR - CIS0830IS16
http://pegasus.javeriana.edu.co/~CIS0830IS16/TANALYSIS.html
Viewpoints
http://pegasus.javeriana.edu.co/~CIS0830IS16/VIEWPOINTS.html
Anexo I.
Estrategias para identificar y conocer Stakeholders.
En formato DOC, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_IEstrategias_para_identificar_y_conocer_stakeholders.docx
En formato PDF, disponible en:
http://pegasus.javeriana.edu.co/~CIS0830IS16/anexos_guia/Anexo_IEstrategias_para_identificar_y_conocer_stakeholders.pdf
77