Ingeniería de Sistemas
PROPUESTA PARA TRABAJO DE GRADO
TÍTULO
Guía Metodológica para el levantamiento y análisis de requerimientos de Software con base en procesos de negocio.
MODALIDAD
Proyecto de investigación formativo. OBJETIVO GENERAL
Desarrollar una guía metodológica que permita el desarrollo del proceso de análisis de requerimientos teniendo en cuenta el proceso de levantamiento de los mismos por medio de procesos de negocio planteados por las arquitec-turas empresariales.
ESTUDIANTE(S)
José Miguel Martínez Guerrero __________________________________________ Documento Celular Teléfono fijo Correo Javeriano
c.c. 1136879130 300-676-8160 3482180 [email protected]
ESTUDIANTE(S)
Camilo Andrés Silva Delgado __________________________________________ Documento Celular Teléfono fijo Correo Javeriano
c.c. 80928036 300-201-5285 2505071 [email protected]
DIRECTOR
Ing. Miguel Eduardo Torres Moreno __________________________________
Documento Celular Teléfono fijo Correo Empresa donde trabaja y cargo cc. 79789331 311- 2311935 Tel. 3208320
Ext. 5316
[email protected] PONTIFICIA UNIVERSIDAD JAVERIANA.
Profesor Investigador
Contenido
1OPORTUNIDAD O PROBLEMÁTICA ...1
1.1 DESCRIPCIÓN DEL CONTEXTO ...1
1.2 FORMULACIÓN ...4
1.3 JUSTIFICACIÓN ...4
2DESCRIPCIÓN DEL PROYECTO ...5
2.1 OBJETIVO GENERAL ...5
2.2 OBJETIVOS ESPECÍFICOS ...5
3PROCESO ...6
3.1 METODOLOGÍA ...6
3.2 ACTIVIDADES ...7
3.3 ENTREGABLES O RESULTADOS ESPERADOS ...10
3.4 CRONOGRAMA ...11
3.5 PRESUPUESTO ...12
4REFERENCIAS Y BIBLIOGRAFÍA ...13
1 Oportunidad o Problemática
1.1 Descripción del contexto
El diseño de aplicaciones empresariales ha sido uno de los campos con mas extensión para las empresas actualmente. Una empresa es una entidad compleja compuesta de personas y procesos, los cuales producen productos o servicios para sus clientes. Para simplificar y mejorar la dimensión y complejidad de estos procesos, teniendo como base la visión completa del sistema empresa, nace el concepto de Arquitectura Em-presarial, la cual identifica los componentes principales de la organización y sus rela-ciones para conseguir los objetivos del negocio. [1][2]
La arquitectura empresarial actúa como un ente que integra aspectos como son los de planificación, operación y aspectos tecnológicos del negocio. Consideramos ahora como marco o Framework aquella estructura que permite almacenar y comunicar todos los elementos que conforman la arquitectura empresarial [2]. Para Zackman, el framework es una estructura lógica para clasificar y organizar la representación des-criptiva de una empresa [3].
Entre uno de los elementos que podría tener un framework se encuentra la arquitectu-ra del negocio, la cual reúne aspectos relativos a la estarquitectu-rategia del negocio, identifi-cando los procesos del negocio y su interacción para poder satisfacer a los clientes. Es usual que pueda ser complementada iterativamente por usuarios y analistas que ten-gan conocimiento de las actividades de la empresa [2].
Entre uno de los frameworks que da más importancia a la arquitectura del negocio se encuentra el Framework Arquitectónico del Open Group (o TOGAF por sus siglas en ingles). Fue desarrollada por los miembros del Open Group a mediados de la década del noventa y se fundamenta en una buena arquitectura del negocio, ya que lo consi-deran un requisito previo para trabajar en la arquitectura empresarial en los demás componentes (datos, aplicaciones, tecnología)[2]. Este framework se basa en cuatro categorías [4], las cuales son:
Arquitectura del negocio. Arquitectura de la aplicación. Arquitectura de datos.
Arquitectura técnica o de tecnología.
Ilustración 1. Fases del ADM [4]
La fase preliminar es donde se inicia la aplicación de ADM al interior de la organiza-ción, dando a conocer a todos los que la conforman los beneficios de su aplicación y, a su vez, se recolecta información y personas necesarias para comenzar con la aplica-ción.
La fase A, visión de la arquitectura, define los límites que permitirán medir el alcance del proyecto y la estrategia para lograrla.
La fase B, arquitectura del negocio, busca tener clara la arquitectura del negocio y las metas que quiere cumplir para revisar si es viable o no complementarla con TI.
La fase C, arquitectura de sistemas de información contempla las arquitecturas parti-culares para datos y aplicaciones.
La fase D, arquitectura tecnológica, define la arquitectura integrada para el desarrollo de las fases posteriores.
La fase F, plan de migración, prioriza los proyectos paralelos y gestiona un plan de migración de la empresa al sistema construido.
La fase G, control de la implementación, es la ejecución de los proyectos para cons-truir las soluciones de TI.
La fase H, administración del cambio de la arquitectura, monitorea y evalua los sis-temas existentes para determinar cuándo iniciar un nuevo ciclo de ADM.
Habiendo analizado lo anterior se observa la importancia de un buen proceso de Ingeniería de Requerimientos por parte de ADM.
Un requerimiento es una declaración que identifica las capacidades, características o factores de calidad de un sistema, a fin que tenga valor y utilidad para el cliente o usuario1.
Los procesos de Ingeniería de Requerimientos son fundamentales dentro del desarro-llo de aplicaciones de software. Sobre este ejercicio está determinado el éxito de un proyecto, en base a su nivel de abstracción del problema por medio de los requeri-mientos y un efectivo entendimiento del negocio.
Hacer un estudio de la documentación con la que se cuenta dentro del negocio para iniciar el levantamiento de requerimientos es una práctica efectiva para disminuir aquellos riesgos que se presentan en este proceso, entre los cuales se destacan [6]: Procesos sueltos en la organización. Lo ideal es que el levantamiento de requeri-mientos encierre el total de procesos que se ejecutan (o ejecutarían) en el desarrollo de la aplicación.
No todos los involucrados en la organización están presentes. Muchas veces en el proceso de levantamiento de requerimientos se tiene que tener en cuenta el tiempo no solo del analista sino también de los clientes o stakeholders involucrados en los pro-cesos. Esto afecta sustancialmente dependiendo el método que se use para la identifi-cación de requerimientos.[7][8].
No hay objetivos claros. Se puede producir cuando varios stakeholders no se ponen de acuerdo en llegar a un requerimiento que sea válido para todos.
1
1.2 Formulación
Desarrollar una guía metodológica que permita el desarrollo de los procesos de levan-tamiento y análisis de requerimientos de software teniendo en cuenta los procesos de de negocio dentro del marco de la arquitectura empresarial.
1.3 Justificación
Una de las principales desventajas con las que cuentan algunas arquitecturas de soft-ware es la comunicación con la lógica del negocio en el momento de su aplicación. En estos casos muchas veces estas arquitecturas reflejan el negocio de la organiza-ción, mas no interactúan con éstas. Se crean servicios para el cliente los cuales pue-den estar basados en un pobre levantamiento y análisis de requerimientos de negocio. Un análisis de requerimientos insuficiente puede, durante el desarrollo de la aplica-ción, causar incrementos tanto en dinero como en horas de trabajo a la organización. También se vuelve difícil hacer seguimiento paralelo a los requerimientos frente a los procesos de negocio si estos no fueron tenidos en cuenta previamente.
En el caso específico de SOA se construyen las aplicaciones en base a las necesidades del cliente, pero no se tiene en cuenta las necesidades de la organización, produciendo así muchas veces inconsistencia entre lo que quiere el cliente contra lo que brinda la empresa.
Lo adecuado es que las aplicaciones que una organización proporciona al cliente sean siempre acordes a los requerimientos levantados desde la lógica del negocio.
2 Descripción del Proyecto
2.1 Objetivo general
Desarrollar una guía metodológica que permita el desarrollo del proceso de análisis de requerimientos teniendo en cuenta el proceso de levantamiento de los mismos por medio de procesos de negocio planteados por las arquitecturas empresariales.
2.2 Objetivos Específicos
1. Estudiar y analizar los conceptos de procesos de negocio.
2. A partir de los componentes que brinda la arquitectura empresarial en cuanto a procesos de negocio, identificar los que pueden ser usados para el levanta-miento y análisis de requerilevanta-mientos de Software.
3. Investigar sobre trabajos existentes que se basen en modelos de procesos para hacer análisis y negociación de requerimientos de software.
4.
Diseñar una guía metodológica que defina los pasos fundamentales para el proceso de levantamiento de requerimientos de Software en base a los proce-sos de negocio, con el fin de hacer seguimiento en el proceso de análisis de la Ingeniería de Requerimientos.5. Por medio de una lista de chequeo y expertos en arquitecturas empresariales, validar la guía metodológica planteada dentro de un proceso de levantamiento y análisis de requerimientos.
3 Proceso
3.1 Metodología
La metodología que será aplicada será la investigativa, la cual está dividida en cinco (5) fases, donde cada fase representa una metodología diferente y tiene sus propias características. La primera fase será la de investigación sobre procesos de negocio y el proceso de ingeniería de requerimientos de software. La segunda fase se encarga de la identificación y caracterización de los componentes de las arquitecturas empresa-riales para el proceso de análisis de requerimientos. La tercera fase es investigar sobre la arquitectura SOA, más específicamente en el proceso de “orquestar” las funciona-lidades con los requerimientos levantados. La cuarta es la elaboración de la guía me-todológica para el levantamiento y análisis de requerimientos de Software en base a procesos de negocio. Y por último en la quinta se realiza pruebas a la guía metodoló-gica bajo la observación de expertos en el tema, en un caso de estudio existente donde se esté iniciando el proceso de ingeniería de requerimientos. Entonces de acuerdo a la especificación inicial a continuación se explica con mayor detalle cada una de las fases:
FASE 1: Investigación profunda sobre los procesos de ingeniería de requerimientos de software, más específicamente en el levantamiento y análisis, con el fin de deter-minar posibles fallos existentes en cada uno de ellos. Consecuentemente los procesos de negocio serán investigados a fondo para poder conocer las herramientas y compo-nentes necesarios para el desarrollo de la guía metodológica.
FASE 2: Revisión de la investigación para así definir y determinar los componentes de las arquitecturas empresariales relacionadas con el proceso de levantamiento de requerimientos de software, de manera que se pueda continuar con el proceso de aná-lisis de requerimientos y utilizar esta información para poder elaborar la guía meto-dológica en la siguiente fase.
FASE 3: Análisis actual de SOA, haciendo énfasis en la orquestación de funcionali-des con requerimientos tomados del cliente, en el proceso de levantamiento de reque-rimientos de Software.
FASE 4: A partir del análisis resultado de las fases 2 y 3 se crea la guía metodológica enfocada a los procesos de levantamiento y análisis de requerimientos de software basado en procesos de negocio propuestos por las arquitecturas empresariales, los cuales también fueron investigados y analizados para su uso correcto.
3.2 Actividades
Objetivo específico Actividades a realizar Resultados obtenidos
Estudiar y analizar los conceptos de procesos
de negocio.
Realizar una revisión general sobre procesos.
Documento de estado del arte sobre procesos de ne-gocio, arquitecturas
empre-sariales y los procesos de levantamiento y análisis de
requerimientos.
Fichas bibliográficas de la información recopilada. Efectuar una revisión
gene-ral sobre los procesos de levantamiento y análisis de
requerimientos Indagar sobre proyectos ya aplicaciones que estén cons-truidos con base procesos
de negocio. Análisis y construcción de fichas bibliográficas basados en la información recopilada A partir de los
componen-tes que nos brindan la arquitectura empresarial
en cuanto a procesos de negocio identificar los que pueden ser usados para el análisis de
reque-rimientos de Software
Identificar los procesos aso-ciados para el proceso de levantamiento de
requeri-mientos
Cuadro con los componentes necesarios para poder co-menzar el proceso de análi-sis de requerimientos a par-tir de los planteados en los
procesos del negocio. Identificar los componentes
para el proceso de análisis de requerimientos
Investigar sobre trabajos existentes que se basen en modelos de procesos para hacer análisis y
ne-gociación de requeri-mientos de software
Identificar trabajos existen-tes basados en modelos de
procesos
Cuadro con los posibles tra-bajos que puedan ayudar o contradecir el trabajo con respecto a los modelos de procesos en la especificación
y negociación de requeri-mientos de software. Generar un procedimiento
adecuado para definir el desarrollo del proceso de análisis de requerimientos con arquitecturas
empresa-riales.
Exponer los diferentes pro-blemas en la integración de
Diseñar una guía meto-dológica, definiendo los pasos fundamentales pa-ra el proceso de levanta-miento de requerimien-tos de Software en base a
los procesos de negocio, para hacerles seguimien-to en los procesos de aná-lisis de Ingeniería de
Re-querimientos.
Seleccionar una herramienta para llevar a cabo el
segui-miento a los procesos de negocio.
Guía Metodológica para el levantamiento y análisis de requerimientos de Software en base a procesos de
nego-cio. Generar un procedimiento,
con una serie de pasos deta-llados, donde se analiza un proyecto de software en su proceso de ingeniería de
requerimientos
Por medio de una lista de chequeo y expertos en arquitecturas empresa-riales, validar la guía
me-todológica planteada de-ntro de un proceso de levantamiento y análisis
de requerimientos
Seleccionar una lista de che-queo válida y aprobada para verificar la guía previamente
diseñada
Validación de la guía meto-dológica previamente
dise-ñada
Por medio de un caso de estudio, aplicar la
meto-dología planteada a un proyecto que este ini-ciando con sus procesos de Ingeniería de
Reque-rimientos
Ejecutar el proceso descrito en la guía metodológica anteriormente desarrollada
sobre un proyecto de soft-ware
Guía Metodológica para el levantamiento y análisis de requerimientos de Software en base a procesos de nego-cio ajustada de acuerdo a
resultados obtenidos. Analizar resultados y
conclu-siones obtenidas Ajustar la guía metodológica
anteriormente desarrollada de acuerdo a los resultados
obtenidos
3.3 Análisis de riesgos.
De 0 a 5: Riesgo mínimo De 5 a 7: Riesgo medio. De 8 a 10: Riesgo máximo Id Clasificación Probabili-dad Im-pacto Valor de ries-go 1 El tiempo designado para la investigación no es
sufi-ciente.
4 4 8
2 Mala planeación en la calendarización. 4 4 8
3 Reuniones no suficientes y poco productivas. 3 3 6 4 Inhabilidad o incapacidad durante el desarrollo de la
guía por parte de un integrante del grupo.
2 4 6
5 Falta de respuesta en el trabajo asignado. 3 4 7
6 Conflictos frecuentes y mal ambiente de trabajo al interior del grupo.
2 3 5
7 Priorización errónea de las actividades a realizar por cada uno de los integrantes.
3 4 7
8 Falta de comunicación con el Director. 2 4 6
9 Baja disponibilidad por parte del Director. 4 4 8
10 Falla general de los equipos 3 3 6
11 Poca o nula disponibilidad de los equipos. 2 4 6
12 Falta de información. 2 4 6
13 Manejo de información errada. 3 5 8
14 Perdida de documentación. 2 4 6
16 Mal control de los documentos a subir al repositorio. 1 3 4
17 La disponibilidad de los expertos en arquitecturas empresariales es poca.
4 4 8
18 No se encuentra caso de estudio para aplicar la guía. 5 5 10
Tabla 1. Clasificación de riesgos
Se toma los riesgos mas relevantes durante el desarrollo de la tesis y se propone opciones de mitigación.
Accion / Numero del riesgo 1 2 9 13 17 18
Redefinir los tiempos de planeación para que se pueda cumplir con las actividades propuestas
X X
Consultar con el director sus posibles tiempos críticos, t tenerlos en cuenta a la hora de la calendarización.
X
Compartir la información obtenida con el grupo y el director, para así tener la certeza de que es información confiable
X
Concretar con un lapso holgado de tiempo al experto que se vaya a consultar y preguntarle su disponibilidad de tiempo para dedi-carle a la validación de la guía metodológica.
X X
Concretar con un lapso holgado de tiempo al caso de estudio. Si no se puede encontrar alguno se planteara como trabajo futuro la aplicación de la guía.
X
Tabla 2. Planes de mitigación de riesgos.
3.4 Entregables o Resultados Esperados
1. Informe de presentación o reporte general de la ejecución de la guia. Reporte de objetivos cumplidos.
2. Resultados de cada fase planteada.
3.5 Cronograma
Task Name Duration Start Finish
Guía Metodológica para el levantamiento y análisis requerimientos de Software en base a procesos de negocio.
96 days Tue 27-07-10
Sat 04-12-10
FASE 1 INVESTIGACIÓN 25 days Tue
27-07-10
Sun 29-08-10
Investigar sobre el contexto general de la ingeniería de
requeri-mientos 5 days Tue 27-07-10 Sun 01-08-10
Realizar una revisión general sobre procesos de negocio. 5 days Mon 02-08-10 Sun 08-08-10
Efectuar una revisión general sobre los procesos de
levantamien-to, análisis y verificación de requerimientos 5 days Mon 09-08-10 Sun 15-08-10
Indagar sobre proyectos ya aplicaciones que estén construidos
con base a procesos de negocio. 5 days Mon 16-08-10 Sun 22-08-10
Análisis y construcción de fichas bibliográficas basados en la
información recopilada 5 days Mon 23-08-10 Sun 29-08-10
FASE 2 ESTADO DEL ARTE Y MARCO TEÓRICO 20 days Mon 30-08-10
Sun 26-09-10
Identificar los procesos de arquitecturas empresariales para el
proceso de levantamiento de requerimientos 5 days Mon 30-08-10 Sun 05-09-10
Identificar los componentes de arquitecturas empresariales para
el proceso de análisis de requerimientos 5 days Mon 06-09-10 Sun 12-09-10
Identificar los componentes de arquitecturas empresariales para
el proceso de especificación de requerimientos 5 days Mon 13-09-10 Sun 19-09-10
Identificar trabajos existentes basados en modelos de procesos 5 days Mon 20-09-10 Sun 26-09-10
FASE 3 GUÍA METODOLÓGICA 25 days Mon 27-09-10
Sun 31-10-10
Realizar una revisión general sobre los problemas existentes en
los procesos de ingenieria de requerimientos 5 days Mon 27-09-10 Sun 03-10-10
Indagar sobre los modelos de investigación existentes para el
proceso de ingenieria de requerimientos 5 days Mon 04-10-10 Sun 10-10-10
Exponer los diferentes problemas en la integración de los
proce-sos de levantamiento y análisis de requerimientos 5 days Mon 11-10-10 Sun 17-10-10
Realizar un cuadro comparativo de las diferentes herramientas
teniendo de acuerdo a criterios específicos 5 days Mon 18-10-10 Sun 24-10-10
Generar un procedimiento adecuado para definir el desarrollo de
los procesos de levantamiento y análisis de requerimientos. 5 days Mon 25-10-10 Sun 31-10-10
FASE 4 PRUEBA DE LA GUÍA METODOLÓGICA 26 days Mon 01-11-10
Sat 04-12-10
Seleccionar una herramienta para llevar a cabo el seguimiento a
los procesos de negocio. 5 days Mon 01-11-10 Sun 07-11-10
Ejecutar el proceso descrito en la guía metodológica
anteriormen-te desarrollada sobre un proyecto de software 5 days Mon 08-11-10 Sun 14-11-10
Analizar resultados y conclusiones obtenidas 6 days Mon 15-11-10 Sun 21-11-10
Ajustar la guía metodológica anteriormente desarrollada de
acuerdo a los resultados obtenidos 5 days Mon 22-11-10 Sun 28-11-10
3.6 Presupuesto
Guía Metodológica para el levantamiento y análisis de requerimientos de Software en base a procesos de negocio.
Presupuesto Integrado
Rubros Total
PUJ Estudiante 1 Estudiante 2
3, Personal 11,520.00
0
6,512.000 6,512.000 24,544.00
0
4, Equipo 130.000 0.0 0.0 130.0
5. Equipo propio Uso 0.0 1,800.000 1,800.000 3,600.000
4
Referencias y Bibliografía
4.1 Referencias
[1] Molpeceres, A.; Perez M. (2002). “Arquitectura Empresarial y Software Libre, J2EE”. Artículo publicado por www.javahispano.org.
[2] Gonzalez, Ll; Boza, Andrés. (2005). “Arquitectura de Empresa. Visión General”. Ponencia en IX Congreso de Ingeniería de Organización. (Gijón, España).
[3]Zackman, J. (1997). "The Zachman Framework: The Official Concise Definition". Disponible en< http://www.zachmaninternational.com/concise%20definition.pdf> [4] Sessions, R (2007). “Comparison of the top four Enterprise Architecture Meto-dologies”. ObjectWatch Newsletter. 2007.
[5] Opengroup. TOGAF. V9, disponible en <http://www.omg.org >
[6] Karl. Wiegers. First Things First: Prioritising Requirements. Published in
Soft-ware Development Magazine, 1999.
[7] Evan Windsor. Integrating nominal group technique and joint application devel-opment: impacts on the effectiveness of systems requirements determination. Georgia State University, 1998.
