Propuesta para Trabajo de Grado - Trabajos de Grado de la ...pegasus.javeriana.edu.co/~CIS0830IS16/propuesta_guia/Propuesta... · Por tal razón se observa a nivel económico, que

Ingeniería de Sistemas

5/25/2009

PROPUESTA PARA TRABAJO DE GRADO TÍTULO

Guía para interactuar con STAKEHOLDERS en el proceso de Ingeniería de Requerimientos

MODALIDAD

Proyecto de Investigación

OBJETIVO GENERAL

Diseñar una guía para identificar y negociar los requerimientos con STAKEHOLDERS en un proyecto de tecno-logías de información

ESTUDIANTE(S)

Carlos Alejandro Mera Amezquita Documento Celular Teléfono fijo Correo Javeriano

CC. 80041336 3125708873 4381065 [email protected]

DIRECTOR

Ing. Rafael Barros Documento Celular Teléfono fijo Correo Javeriano; Correo 2 Empresa donde trabaja y cargo

[email protected] Pontificia Universidad Javeriana; Profe-

sor de Cátedra Departamento de Inge-

niería de Sistemas. TIBCO

ASESORES

Ing. Lina Marcela Rojas Villafañe Documento Celular Teléfono fijo Correo Javeriano; Correo2 Empresa donde trabaja y cargo

CC. 52.968.976 3006781823 4731526 [email protected] Pontificia Universidad Javeriana; Profe-

sor de Cátedra Departamento de Inge-niería de Sistemas. Edesa S.A. Líder de

Proyectos.

VoBo. Coordinador de Trabajos de Grado: ________________________

Código: TG-20071-xxx

mailto:[email protected]

Pontificia Universidad Javeriana Propuesta para Trabajo de Grado – Proyecto de Investigación

Página i Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/02/2007

Contenido

1 OPORTUNIDAD O PROBLEMÁTICA........................................................................................... 1

1.1 DESCRIPCIÓN DEL CONTEXTO ............................................................................................... 1

1.2 FORMULACIÓN .................................................................................................................. 5

2 DESCRIPCIÓN DEL PROYECTO ................................................................................................. 6

2.1 OBJETIVO GENERAL ............................................................................................................ 6

2.2 OBJETIVOS ESPECÍFICOS ...................................................................................................... 6

3 MARCO TEÓRICO / ESTADO DEL ARTE .................................................................................... 7

3.1 TRABAJOS IMPORTANTES EN EL ÁREA .................................................................................... 7

3.2 GRAFO DE IDEAS REFERENCIADAS ....................................................................................... 10

3.3 GLOSARIO....................................................................................................................... 10

4 PROCESO ........................................................................................................................... 11

4.1 METODOLOGÍA ............................................................................................................... 11

4.2 ACTIVIDADES ................................................................................................................... 13

4.1 PRESUPUESTO ................................................................................................................. 15

4.2 CRONOGRAMA ................................................................................................................ 16

5 REFERENCIAS Y BIBLIOGRAFÍA .............................................................................................. 18

5.1 REFERENCIAS................................................................................................................... 18

5.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO ............................... 19

6 ANEXO 1. GRAFO DE IDEAS REFERENCIADAS .......................................................................... 20


Página 1 Preparado por Carlos Alejandro Mera Amezquita

1 Oportunidad o Problemática

1.1 Descripción del contexto

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 indus-

trias 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 desa-

rrollo 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 de-

muestran 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 organiza-

do 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 dife-

rentes mercados presentan exigencias más altas, las cuales deben ser enfrentadas de ma-

nera acuciosa y ordenada. Un pilar para enfrentar estos retos es el desarrollo de sistemas

software que cumpla las exigencias que nos exponen los mercados. A raíz de esto la Inge-

niería de Software ha contribuido para el desarrollo de sistemas software de calidad, capa-

ces de enfrentar los retos que actualmente presentan los mercados. Pero debido a que las

necesidades cambian por diferentes factores que algunas veces son controlables, es donde

aparece la Ingeniería de Requerimientos la cual gestiona, ordena y formula las necesidades

que los mercados pretenden resolver basados en las tecnologías de información.



Basados en el papel que tienen las TIC, en donde los Sistemas de información son la

herramienta de solución a muchas de las problemáticas en los países o empresa, se tienen

en cuenta que para las construcción de estos se hace uso de conceptos, técnicas y herra-

mientas, 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 de trabajo que sigue, después de su levanta-

miento. Una vez que han sido establecidos, los desarrolladores y demás personas involucra-

das en el proceso, continúan con los trabajos técnicos: sistema de diseño, desarrollo, ensa-

yo, 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. Estas personas son la princi-

pal fuente de información para entender y llevar a cabo el desarrollo de sistemas de soft-

ware que cumpla con estas exigencias. Es aquí donde la Ingeniería de requerimientos juega

un papel importante; que es la de la elaboración de requerimientos claros, completos, con-

sistentes, factibles y verificables, que son la hoja de ruta para el desarrollo de dichos siste-

mas 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 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 [5].

Bajo este aspecto la Ingeniería de Software da el nombre de Stakeholders a todas las perso-

nas que se encuentren afectadas por el sistema a desarrollar. Es por esto que en la fase de

Ingeniería de Requerimientos se contempla la elicitacion requerimientos, la cual contempla

la identificación de Stakeholders , que son la pieza más importante para una correcta elabo-



ración de requerimientos pero estos 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 Skateholders 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 comporta-

miento de software, y su evolución a lo largo del tiempo y a través de las familias de softwa-

re" [13]. El proceso de INGENIERIA DE REQUERIMIENTOS se compone de las siguientes acti-

vidades dentro de su ciclo de vida:

Identificación de STAKEHOLDERS, que son todas las personas interesadas en el sis-

tema o en alguno de sus procesos para una necesidad en particular.

Obtener un entendimiento de los clientes y las necesidades de los usuarios en el sis-

tema y sus expectativas, es aquí donde se incluyen todos los tipos de requerimien-

tos que se pueden obtener.

Identificación de requerimientos, formalización de los requerimientos encontrados;

Aclarar y reafirmar los requerimientos, iteración del anterior donde se evalúan los

requerimientos previamente establecidos;

Analizar requerimientos, se hace para asegurar que los requerimientos se definieron

bien, es decir, que cumplen con los criterios de un buen requerimiento;

Definición de los requerimientos de forma tal que signifique lo mismo para todos los

STAKEHOLDERS.

Especificación de requerimientos: Documentación formal de los requerimientos;

Priorizar requerimientos, no todos los requerimientos tienen la misma importancia,

algunos requerimientos son más críticos que otros.

Realizar seguimiento a los requerimientos: un requerimiento debe tener la capaci-

dad de ser trazado en el sistema en cualquier momento dado.

Administrar los requerimientos, un requerimiento se debe poder añadir, eliminar

y/o modificar en cualquier fase de DISEÑO DEL SISTEMA.

Probar y verificar los requerimientos, este es el proceso de comprobación de los re-

querimientos, diseños, código, planes de prueba, y productos del sistema para ga-

rantizar que se cumplen.

Validación de requerimientos, este es el proceso para confirmar que los requeri-

mientos planteados en las actividades anteriores se aplican en el sistema de entre-



ga. Al orden de validación de las necesidades se le debe dar una prioridad, ya que

hay un monto de financiación limitado por la organización [5].

Dentro de este ciclo de vida, nos centramos en las actividades que contemplen identifica-

ción y negociación de requerimientos, dando uso de la identificación de personas involucra-

das 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 necesida-

des o requerimientos, de tal forma que poseen a su vez la información necesaria para que

sus 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 per-

sonas que se ven afectadas por el sistema a desarrollar [2] [4]. Este proceso en el ciclo de

vida es de los más importantes para la obtención de requerimientos, porque la primera ta-

rea que se debe cumplir es, mostrar los resultados que los interesados quieren. Ellos deben

estar documentados, porque si no es 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 des-

arrollando 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 perso-

nas 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 identificación es muy importante, no se describe un

modelo o un enfoque concreto para la identificación de las partes interesadas para un pro-

yecto específico [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 de-

terminado grupo de personas; como si lo son para otro grupo personas, esto puede ser

contraproducente para el desarrollo del software, y por algún detalle de información que

haga falta el proceso, este puede deteriorase, puede acabarse o simplemente no puede

llegar a un buen cierre. Se presentan además otro tipo de inconvenientes; como el desper-

dicio 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 cancela-

dos 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. Y, aun cuando estos proyectos se han completado, no

reflejan ni un 10% de la especificación original de los requerimientos. Debido a esto y mi-

rando las necesidades que se tienen en el desarrollo de software, se observa la necesidad

de organizar las técnicas y guías para un buen levantamiento de requerimientos en base a

la problemática que observamos. Vemos que podemos aportar una nueva guía que contri-

buya para un buen levantamiento de requerimientos enfocados en una buena gestión de la

información que provean las personas interesadas

Es aquí donde la teoría de colores entra a jugar un papel de mediador para conocer la mane-

ra en que dichos stakeholders piensan e interactúan con el fin de saber cuál es la mejor ma-

nera de interactuar y poder una mejor materia prima para la elaboración de los requeri-

mientos.

1.2 Formulación

¿Cómo identificar y negociar requerimientos con stakeholders de un proyecto de tecnolog-

ías de información?



2 Descripción del Proyecto

2.1 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.2 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 levanta-

miento 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 in-

tegre el uso apropiado de las herramientas de levantamiento de información y reali-

zar una prueba piloto de la guía



3 Marco Teórico / Estado del Arte

3.1 Trabajos importantes en el área

La INGENIERIA DE REQUERIMIENTOS comprende todas las tareas y actividades correspon-

dientes a la identificación de necesidades, ya sea para la implantación o implementación de

un nuevo sistema dentro de una organización [13] (VER SECCION 1.1 ¡Error! No se encuen-

tra el origen de la referencia.). El éxito o fracaso del proyecto subyace en que los requeri-

mientos planteados estén acordes a las necesidades y completos, la participación de los

STAKEHOLDERS acordes al problema sea constante y la que los requerimientos se puedan

trazar de forma tal que si se presenta un cambio se fácil realizarlo. Este proceso consta de

actividades definidas como se citó anteriormente, dentro de las cuales nos centraremos en

la identificación de STAKEHOLDERS, para la obtención de información relevante para el pro-

yecto.

En el desarrollo de un proyecto de construcción de software, se tienen diferentes fases que

se comprenden de acuerdo al proceso de desarrollo escogido. Dentro de cualquier proceso

de desarrollo es necesario realizar un modelado de negocio, es decir, el equipo de trabajo

debe familiarizarse con el funcionamiento de la empresa: Conocer sus Procesos, de forma

tal que entiende la estructura y la dinámica de la organización, entender el problema actual

en la organización, identificar las personas involucradas en los procesos para identificar las

aquellas que contienen información para el desarrollo de la solución, de forma tal que se

pueda asegurar que todos los STAKEHOLDERS identificados tengan un entendimiento

común de la organización objetivo [15]. También es necesario hacer el levantamiento de

requerimientos, de forma tal que se establezcan las necesidades del sistema como ante-

riormente se explicó. La INGENIERIA DE REQUERIMIENTOS es el proceso que comprende las

actividades que se involucran dentro de estas dos fases, ya sea en un proyecto de construc-

ción de software o el análisis y diseño de un sistema de información, de modo que antes

realizar el diseño del sistema todas las partes involucradas deben conocer las necesidades

del sistema y para todos tiene un mismo significado [13].

En la investigación que hemos realizado hasta el momento de realizar la propuesta de traba-

jo de grado, varios textos citan y hemos podido concluir que se presta poca atención a los

participantes dentro del proceso de INGENIERIA DE REQUERIMIENTOS (aunque recalcan que

es de vital importancia), por ejemplo, en términos de cómo hacer trazabilidad a los partici-

pantes en todo el proceso de ingeniería de requerimientos y cómo identificar las partes

interesadas dentro del mismo [8]. Por tal razón los trabajos específicos e importantes en el

área son pocos.



1. Una aproximación a la identificación de personas interesadas en ingeniería de re-

querimientos

El punto de partida de esta aproximación consiste en un conjunto de partes intere-

sadas a la cual se refieren como la línea base de referencia de STAKEHOLDERS y su

interacción (véase Ilustración 1). De estos, se reconoce al proveedor y al cliente co-

mo 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].

Ilustración 1. Elementos principales en la identificación de personas interesadas [8]

2. 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 diferen-

tes implicaciones. Esto mediante un diagrama de “cebolla” (por las diferentes capas

que se manejan) (véase Ilustración 2). Este diagrama, presenta una vista del proyec-

to, 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].



Ilustración 2. Modelo de cebolla de las relaciones de las persona interesadas [9]

Se hace una principal distinción entre los beneficiarios internos del producto: ope-radores, y los beneficiarios funcionales externos: usuarios finales los cuales se con-sideran 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 per-sonas interesadas que afectan la toma de decisiones en el sistema. Se puede ver el sistema como una herramienta [9].



3.2 Grafo de ideas referenciadas

(Ver Sección ¡Error! No se encuentra el origen de la referencia.)

3.3 Glosario

Stakeholders: cualquier grupo o individuo que puede afectar o se ve afectada por la conse-cución de los objetivos de la organización.

Ingeniería de requerimientos: es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.

Requerimiento: Una declaración en un Lenguaje Natural incluye los diagramas de los servi-cios del sistema y sus límites operacionales. Escrito para clientes.

Elicitacion: palabra no castiza que significa búsqueda o indagación en ingles.

Plantilla: Esquema que provee la generación de un artefacto o documento.



4 Proceso

4.1 Metodología

Al ser este un proyecto de investigación y basados en la definición de los objetivos se des-

lumbra la necesidad de levantar información. Estos requieren de una investigación que con-

tribuya 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 ele-

mentos que componen la realidad. No se trata de probar la realidad sino de abarcar la ma-

yor cantidad de cualidades posibles y cómo intervienen, ayudando a comprender la pro-

blemática que planteamos.

Objetivos Específicos Rela-cionados en esta Metodo-logía

Fases seleccionadas de la metodología cualitativa para cumplir con estos objetivos

Técnicas de investi-gación

Diseñar un plantilla para describir las herramientas de le-vantamiento de información en proyectos de tecnologías de in-formación

Utilizar la plantilla para describir por lo menos 5 herra-mientas en los procesos de le-vantamiento de información

- Comprehensión - Observación de los participan-tes en el proceso de identificación de Stakeholders

- Especificación de la Problemáti-ca

- Establecer la pregunta de inves-tigación

- Entrevistas a personas que se 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 identifi-cadas en la pregunta - Entender los datos y convertir-los en información

- Observación - Conversación con expertos - Gestión de documen-tos - Cruce de información - Obtención de informa-ción a través de entre-vistas, cuestionarios

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 mejo-ramiento de la misma.

A continuación el objetivo mencionado forma parte de los artefactos que se piensan entre-gar a partir de las fases y objetivos mencionados anteriormente

Objetivos Específicos Relacionados en esta Metodología

Fases seleccionadas de la metodología cualitativa para cumplir con estos obje-tivos

Analizar y diseñar el proceso, detallan-do 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.

Los siguientes objetivos proponen una prueba piloto de lo desarrollado con el fin de obser-var 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 obje-tivos

Describir estrategias de negociación ba-sadas en los roles principales en proyec-tos de tecnologías de información

Realizar una prueba piloto de la guía

- Críticas constructivas

- Construcción de información a partir de la prueba piloto

- Desarrollar el trabajo de aplicación del mo-delo

- Presentar resultados

- Ajustar a lo visto en la prueba piloto



- Retroalimentación

- Aterrizar conceptos y consejos de las perso-nas con el bagaje en el tema.

- Analizar los datos que arroje la prueba piloto

- Conclusión de la investigación

Finalidad: desarrollar un informe con los resultados obtenidos y una iteración de la guía, con el fin de observar la operabilidad de la misma.

4.2 Actividades

Enumeración de las actividades a realizar en nuestro proceso basado

Objetivo Actividad Resultados

Diseñar un plantilla para

describir las herramien-

tas de levantamiento de

información en proyectos

de tecnologías de in-

formación

- Levantamiento de la infor-mación referente a problemá-ticas en la Ingeniería de reque-rimientos respecto a sktake-holders y al levantamiento de información.

- Organización y marcación de las fuentes de información en el contexto de la problemáti-ca

- Documento base del estado del arte o de la información encontrada

- Anexo, un mapa de referen-cias dirigidas al contexto de la problemática

- Plantilla para descripción de herramientas de levanta-miento de información

Utilizar la plantilla para

describir por lo menos 5

herramientas en los proce-

sos de levantamiento de

información

- Levantar la información ne-cesaria referente a todo el conjunto de técnicas y activi-dades para el levantamiento de requerimientos.

- Realizar un análisis de la información obtenida en las actividades anteriores, con el fin de depurara las actividades y técnicas que contribuyan al mejoramiento de la problemá-tica

- Capitulo en donde se evi-dencie la organización y cate-gorización de técnicas y actividades desarrolladas en el proceso de ingeniería de requerimientos.

- Plantillas con la descripción de por lo menos 5 herramien-tas

Describir estrategias de

negociación basadas en

los roles principales en

Conceptualización y aplicación de la información recolectada, en todo el proceso

Capitulo, en donde se en-cuentre la información con los perfiles y las estrategias que contribuye a mejorar la



proyectos de tecnologías

de información

Estudio y análisis del conjunto de técnicas que ofrece al teor-ía de Colores y la Literatura de NED HERRMANN para la inter-acción con los stakeholders

Realizar la guía basándonos en cada una de las plantillas des-arrolladas.

interacción de personas que tiene la información en un proceso de levantamiento de información

Primera iteración de la guía con un conjunto de pasos a seguir para el mejoramiento de la problemática

Realizar una prueba pilo-

to de la guía

- Esquematizar, diagramar y evidenciar todo lo observado en la prueba piloto de la guía.

- Conglomerar cada una de las actividades realizadas, con el fin de refinar todo el proceso

- Informe de las actividades y pruebas realizadas en el con-texto del caso de estudio.

- plan o protocolo de la prue-ba piloto.

- Entrega formal del docu-mento de trabajo de grado, que contenga la segunda iteración de la guía, con su respectivo anexo de informe de prueba piloto de la guía y todos los anexos que se con-sideren importantes.



4.1 Presupuesto

Ingresos en miles $ Egresos en miles $

Aportes Pontificia Universi-dad Javeriana

$0 Libros, Fotocopias Papers y papelería

$300.000

Recursos propios:

$ 30.000 hr

Tiempo de trabajo

12 hrs semanales * 19 sema-nas = 228 Horas Persona * 1 persona = 228 Horas

$6.840.000 Medios Impresos $100.000

Internet $300.000

Otros Gastos, incluida licencia MINDMANAGER 8

$1.200.000

Recurso Humano

$50.000 hora de asesoría

Tiempo de trabajo

2 hrs semanales * 19 se-manas = 38 Horas

$1.900.000

Total $6.840.000 Total $3.800.000



4.2 Cronograma

Las actividades descritas anteriormente por cada objetivo específico están establecidas en un cronograma detallado que se muestra en el Archivo de Project anexo a este documento. Apoyado en ese cronograma se definen las siguientes fechas para los entregables que tendrán que ser desarrollados y entregados en las siguientes fechas:

Resultados parciales Trabajo de Grado

o Documento Propuesta corregido: 27 de Julio de 2009

o Documento base del estado del arte Final 28 de Agosto de 2009

o Levantamiento de toda la información referente a la problemática

o Organización y marcación de las fuentes de información en el contexto de la problemática

o Mapa de Referencias dirigidas a La Problemática

o Levantar la información necesaria referente a todo el conjunto de técnicas y actividades para el levantamiento de requerimientos.

o Estudio y análisis del conjunto de técnicas que ofrece al teoría de Colores y la Literatura de NED HERRMANN para la inter-acción con los stakeholders

o Plantilla para descripción de herramientas de levantamiento de información

o Primera iteración de la guía con un conjunto de pasos a seguir para el mejoramiento de la problemática 11 Septiembre de 2009

o Realizar un análisis de la información obtenida en las actividades anteriores, con el fin de depurara las actividades y técnicas que contribuyan al mejora-miento de la problemática"

o Conceptualización y aplicación de la información recolectada, en todo el proceso"

o Plantillas con la descripción de por lo menos 5 herramientas

o Entrega Formal de la guia y capitulo del documento: Septiembre 23 de 2009

o Capitulo, en donde se encuentre la información con los perfiles y las estra-tegias que contribuye a mejorar la interacción de personas que tiene la in-formación en un proceso de levantamiento de información

o Entrega formal del documento de trabajo de grado, que contenga la segunda itera-ción de la guía, con su respectivo anexo de informe de prueba piloto de la guía y to-dos los anexos que se consideren importantes 17 de Noviembre de 2009

o Elaborar plan para prueba piloto



o Ejecutar prueba piloto

o Esquematizar, diagramar y evidenciar todo lo observado en la prueba piloto de la guía.

o Conglomerar cada una de las actividades realizadas, con el fin de refinar to-do el proceso

o Informe de las actividades y pruebas realizadas en el contexto del caso de estudio

o Hacer Conclusiones y Organización del Documento y artefactos Finales



5 Referencias y Bibliografía

5.1 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, Soft-ware, Vol 24, No. 2, (2007).

[4]. Bin, M., y Zur, M., Information Requirements of Process Stakeholders: A Frame-work 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%20cualitativa.pdf

[6]. Alexander, I., y Stevens, R., Writing Better Requirements, Pearson Education Li-mited, (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 Stake-holders, IEEE, (2004)

[10]. Alexander, I., y A. Farncombe, JBA, Stakeholder Analysis Template, Systems Engi-neering Foundation Course, (2003).

[11]. Ministerio de telecomunicaciones, Plan Nacional de Tecnologías de la Información y las Comunicaciones, (2008), Disponible en: http://www.colombiaplantic.org/docs/080409-Plan%20Nacional%20de%20TIC.pdf

[12]. Imobix, II Encuentro Iberoamericano Sobre Objetivos Del Milenio de Naciones Uni-das 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

http://www.epiclin.unicauca.edu.co/archivos/Naturaleza%20de%20la%20Investigacion%20cualitativa.pdf

http://www.epiclin.unicauca.edu.co/archivos/Naturaleza%20de%20la%20Investigacion%20cualitativa.pdf

http://www.uoc.edu/web/esp/art/uoc/0107027/desarrollo.html

http://eprints.ucl.ac.uk/744/1/1.7_stake.pdf

http://www.colombiaplantic.org/docs/080409-Plan%20Nacional%20de%20TIC.pdf

http://www.ahciet.net/portales/comun/pags/agenda/eventos/161/Imobix_Final.pdf

http://www.ahciet.net/portales/comun/pags/agenda/eventos/161/Imobix_Final.pdf



[13] Nuseibeh, B., y Easterbrook, S., Requirements Engineering: A Roadmap, IEEE, Dis-ponible 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 Com-plex 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 Gine-bra, (2007)

5.2 Bibliografía Propuesta para el desarrollo del Trabajo de Grado

(Ver archivo anexo BibText Referencias [AAD-CAMA])

.

http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf

http://net.educause.edu/ir/library/pdf/NCP08083B.pdf



6 Anexo 1. Grafo de ideas referenciadas

Documents

Propuesta para Trabajo de Grado - Trabajos de Grado de la ...pegasus.javeriana.edu.co/~CIS0830IS16/propuesta_guia/Propuesta... · Por tal razón se observa a nivel económico, que