Gestin de Requerimientos como disciplina en el modelamiento del negocio basado en la metodologa del Rational Unified Process

Lucio Csar Rodrguez Reyes1*, Danher Huamn Camas2,

1,2

Facultad de Ingeniera y Arquitectura, Universidad Peruana Unin

Corresponde autor:

Direccin: Universidad Peruana Unin, , Jr. Los Mrtires 218 , Morales, San Martin, San Martin E-mail: sheshin93@gmail.com, E-mail: da4846@gmail.com. Telfono: 976284351

Resumen La presente investigacin tiene como propsito mostrar los fundamentos tericos de la gestin de requerimientos en el modelamiento del negocio bajo metodologa del RUP. Entindase como un requerimiento una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. Una representacin documentada de una condicin o capacidad. (Senn, 1992). Cmo influyen los requerimientos en el modelamiento del negocio? Los requerimientos ayudan a definir un acuerdo formal de lo que se debe hacer, fronteras del proyecto, proporciona las bases para la planificacin de las iteraciones y definir interfaces basndose en las necesidades. Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales. Los Requerimientos cumple un papel

primordial en el proceso de produccin de software, ya que enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas (fowler, 1999).

Palabras clave: requerimiento; software; casos de uso; sistema.

1.

Introduction

Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Esta situacin ha llevado a comprender que, debido a la complejidad y exigencia de los procesos a automatizar, se requiere de grandes cambios en el proceso de produccin de los software y se ha hecho imprescindible la prctica de nuevos mtodos, que permitan coordinar, supervisar y establecer el trabajo en equipo entre el grupo de desarrollo de cada proyecto de software y sus clientes, como va para lograr que los requisitos identificados sean viables, adecuados y permitan decidir, con el mayor por ciento de exactitud posible, qu se desea y qu es posible automatizar en definitiva (Bracker, 1990). Estas prcticas se hacen efectivas por medio de las etapas de Modelado del negocio y Gestin de requisitos, las fases primarias del proceso de desarrollo de un sistema automatizado. En general, cada vez, existe un reconocimiento mayor de su importancia y los riesgos en que se incurre si estas se cumplen de manera incorrecta o insuficiente. Son estas actividades las que definen la direccin y el alcance del proyecto y se realizan segn los intereses de la entidad encargada del desarrollo del producto final, es por ello que, amn de la existencia de metodologas reconocidas, como RUP (Rational Unified Process), algunas organizaciones dedicadas a la actividad de informatizacin han creado metodologas propias internas segn sus intereses de captura de informacin (Saiedian, 1999).

Con el modelado de negocio se logra "conocer" la organizacin: misin, funciones, estructura, expertos, tecnologa, debilidades, fortalezas; comprender el entorno en el que va a funcionar el sistema, identificar sus procesos, la informacin, los actores participantes en dichos procesos y los papeles que representan cada uno de ellos, con respecto a cada porcin de la informacin (Oberg, 1998). Una vez identificados los procesos y flujo de actividades para producir un resultado de valor, es posible determinar su viabilidad, si son los correctos o si necesitan alguna modificacin, claro, sin llegar a un anlisis tan amplio como el que pudiera comprender una consultora de procesos. Igualmente, es posible determinar la localizacin de la informacin; si existe duplicidad en ella; as como el acceso innecesario a la informacin que no corresponde o la carencia de otra que s es necesaria; se puede conocer tambin la responsabilidad de cada actor la funcin que asume una persona, sistema o entidad que interacta con el sistema con respecto a la informacin que utiliza para realizar su

actividad laboral y el rol de conjunto de funciones, normas, comportamientos y derechos definidos para un cliente registrado que desempea en el sistema. Con la disciplina de Requerimientos el beneficio ser uniforme, tendr un aporte tecnolgico, social y Espiritual. Adems se presenta el fundamento terico de la disciplina de gestin de requerimientos, metodologa, tipos formas de adquirir requerimientos, aportes y conclusiones.

2.

Metodologa El RUP se divide en varias disciplinas de ingeniera y de soporte como se muestra en la tabla 1. Tabla 1- Metodologa Rational Unified Process.

Disciplinas de ingeniera: 1.Disciplina de modelaje del negocio 2.Disciplina de requerimientos 3.Disciplina de anlisis y diseo 4.Disciplina de implementacin 5.Disciplina de pruebas 6.Disciplina de despliegue

Disciplinas de soporte: 1. Disciplina de administracin de la configuracin y control de cambios 2. Disciplina de administracin de proyectos 3. Disciplina de entorno y soporte del ambiente de desarrollo

En este artculo nos enfocaremos especialmente en la disciplina de requerimientos. 2.1. Tipos de Requerimientos 2.1.1. Funcionales Los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que sera bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema (Quispe, 2011) . 2.1.2. No Funcionales La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados

(desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indican cmo tiene que ser construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema (Approach 2007). 2.2. Forma Adquirir los Requerimientos 2.2.1. Entrevistas y Cuestionarios Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Las preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema.

Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas. Del Usuario: Quin es el cliente?, Quin es el usuario?, Son sus necesidades diferentes?, Cules son sus habilidades, capacidades, ambiente? Del Proceso: Cul es la razn por la que se quiere resolver este problema?, Cul es el valor de una solucin exitosa?, Cmo usted resuelve el problema actualmente?, Qu retrasos ocurren o pueden ocurrir? Del Producto: Qu problemas podra causar este producto en el negocio?, En qu ambiente se usar el producto?, Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento?, Qu obstculos afectan la eficiencia del sistema? El xito de esta tcnica combinada, depende de la habilidad del entrevistador y de su preparacin para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cmo tratar con problemas potenciales. Asimismo, necesitan considerar no slo la informacin que adquieren a travs del cuestionario y la entrevista, sino tambin, su significancia.

2.3. Aporte de los Requerimientos 2.3.1. Aporte Tecnolgico La documentacin de requerimientos es una de las ms importantes partes del proceso de desarrollo de software, pero es, a la vez, una de las que cuenta con pocas herramientas de soporte tecnolgico en la actualidad, aumentando el tiempo y costos del proyecto. A su vez es una etapa donde inevitablemente existe contradicciones y ambigedad que atentan contra el correcto comienzo de la vida del software (European Software Process Improvement Training Initiative, 1996). Las causas primarias de realizar una incorrecta conceptualizacin del problema es cuando el desarrollador de software tiene situaciones en que es escaso el conocimiento acerca del dominio de aplicacin y el dominio de aplicacin, donde se implantar el software, puede ser complejo. 2.3.2. Aporte Social Involucrar al grupo para compartir sus experiencias. Mejorar las dificultades que puede tener una persona, hasta una organizacin, observando las debilidades y dificultades que tiene, dando opiniones de solucin, pasando por un proceso, lo que el cliente quiere, pasando a formar unos requerimientos ms del sistema. Del mismo modo organiza mejor el tiempo y costo de presupuesto.

2.3.3. Aporte Espiritual A travs de la historia el ser humano se ha preocupado desde el punto de vista moral y espiritual. Como aceptar lo bueno, lo justo, lo bello etc., y como contraposicin a esto lo malo, lo injusto, lo feo, lo perjudicial lo que ha sido una interrogante desde que el hombre comenz a organizarse en las sociedades para mejorar este aspecto tan importante. Los requerimientos ayudan en los siguientes aspectos. - La organizacin es una muestra de ella, el buen trabajo en equipo, tiempos establecidos, La equidad de trabajo, La disposicin para ayudar al cliente de la mejor manera posible y sobre todo dan un producto de buena calidad. Todo lo mencionado ayuda a la formacin del buen carcter del ser humano y da un buen testimonio del mismo.

3.

Conclusiones A pesar de la importancia que tiene la Ingeniera de Requerimientos, ha costado mucho

que se le preste la atencin adecuada a esta actividad. An quedan muchos desafos que deben ser mejorados, tales como la integracin de requerimientos funcionales y no funcionales, la evaluacin de especificaciones alternativas. Cada actividad y tcnica de Requerimientos utilizada individualmente, dar diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el rea del problema son el mismo. Por esta razn, considero que no existe un modelo de proceso ideal para los Requerimientos; encontrar el mtodo o la tcnica perfecta es una ilusin, pues cada mtodo y tcnica ofrece diferentes soluciones ante un problema. Debemos recordar que la Ingeniera de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de Requerimientos no depende solamente de la forma en cmo se percibe el problema, sino tambin, del nivel de experiencia que tengan los involucrados.

Referencias

Senn, A. (Ed.,1992). Anlisis y Diseo de Sistemas de Informacin. Mxico: McGraw Hill.. Fowler, M. (1999). UML Gota a Gota. Madrid: Addison Wesley Longman. Brackett, J W. (1990). Software Requirements and Software Engineering Institute Education Program. Estados Unidos: Washinton Saiedian, H.; Dale, R. (1999) "Requirements Engineering: Making the connection between the software developer and customer". Department of Computer Science University of Nebraska. Oberg, R; Probasco L; Ericsson, M. (1998). Applying Requirements Management with Use Cases. Rational Software Corporation. Hofmann, H. (1993) . Requirements Engineering. Institute for Informatics University of Zurich. Malan, R.(1999). Functional Requirements and Use Cases. Hewlette-Packard Company. Lutor.-K.-(2008)IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html. (consultado el 25 de noviembre de 2013) Smith, F. Software Engineering Resources by Roger S. Pressman & Associates Inc. http://www.rspa.com/spi/index.html. (consultado el 25 de noviembre de 2013) Wilian, G. Ingeniera de Software. http://www.soi.city.ac.uk/gespan/sw_group_pub.html. (consultado el 28 de noviembre de 2013)