Investigacion requerimientos rup totalmente arreglado

325 views

Published on

2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total views
325
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Investigacion requerimientos rup totalmente arreglado

  1. 1. Gestión de Requerimientos como disciplina en el modelamiento del negocio basado en la metodología del Rational Unified Process Lucio César Rodríguez Reyes1*, Danher Huamán Camas2, 1,2 * Facultad de Ingeniería y Arquitectura, Universidad Peruana Unión Corresponde autor: Dirección: Universidad Peruana Unión, , Jr. Los Mártires 218 , Morales, San Martin, San Martin E-mail: sheshin93@gmail.com, E-mail: da4846@gmail.com. Teléfono: 976284351
  2. 2. Resumen La presente investigación tiene como propósito mostrar los fundamentos teóricos de la gestión de requerimientos en el modelamiento del negocio bajo metodología del RUP. Entiéndase como un requerimiento una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Una representación documentada de una condición o capacidad. (Senn, 1992). ¿Cómo 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 planificación de las iteraciones y definir interfaces basándose en las necesidades. Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales. Los Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, 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.
  3. 3. 1. Introduction Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Esta situación 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 producción de los software y se ha hecho imprescindible la práctica de nuevos métodos, que permitan coordinar, supervisar y establecer el trabajo en equipo entre el grupo de desarrollo de cada proyecto de software y sus clientes, como vía 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 prácticas se hacen efectivas por medio de las etapas de Modelado del negocio y Gestión 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 dirección y el alcance del proyecto y se realizan según los intereses de la entidad encargada del desarrollo del producto final, es por ello que, amén de la existencia de metodologías reconocidas, como RUP (Rational Unified Process), algunas organizaciones dedicadas a la actividad de informatización han creado metodologías propias internas según sus intereses de captura de información (Saiedian, 1999).
  4. 4. Con el modelado de negocio se logra "conocer" la organización: misión, funciones, estructura, expertos, tecnología, debilidades, fortalezas; comprender el entorno en el que va a funcionar el sistema, identificar sus procesos, la información, los actores participantes en dichos procesos y los papeles que representan cada uno de ellos, con respecto a cada porción de la información (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 modificación, claro, sin llegar a un análisis tan amplio como el que pudiera comprender una consultoría de procesos. Igualmente, es posible determinar la localización de la información; si existe duplicidad en ella; así como el acceso innecesario a la información que no corresponde o la carencia de otra que sí es necesaria; se puede conocer también la responsabilidad de cada actor la función que asume una persona, sistema o entidad que interactúa con el sistema con respecto a la información que utiliza para realizar su actividad laboral y el rol de conjunto de funciones, normas, comportamientos y derechos definidos para un cliente registrado que desempeña en el sistema. Con la disciplina de Requerimientos el beneficio será uniforme, tendrá un aporte tecnológico, social y Espiritual. Además se presenta el fundamento teórico de la disciplina de gestión de requerimientos, metodología, tipos formas de adquirir requerimientos, aportes y conclusiones.
  5. 5. 2. Metodología El RUP se divide en varias disciplinas de ingeniería y de soporte como se muestra en la tabla 1. Tabla 1- Metodología Rational Unified Process. Disciplinas de ingeniería: 1.Disciplina de modelaje del negocio Disciplinas de soporte: 2.Disciplina de requerimientos 1. Disciplina de administración de la configuración y control de cambios 3.Disciplina de análisis y diseño 2. Disciplina de administración de proyectos 4.Disciplina de implementación 3. Disciplina de entorno y soporte del ambiente de desarrollo 5.Disciplina de pruebas 6.Disciplina de despliegue En este artículo nos enfocaremos especialmente en la disciplina de requerimientos. 2.1. Tipos de Requerimientos 2.1.1. Funcionales Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema (Quispe, 2011) . 2.1.2. No Funcionales La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados
  6. 6. (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución 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 información 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 técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información 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.
  7. 7. 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: ¿Quién es el cliente?, ¿Quién es el usuario?, ¿Son sus necesidades diferentes?, ¿Cuáles son sus habilidades, capacidades, ambiente? Del Proceso: ¿Cuál es la razón por la que se quiere resolver este problema?, ¿Cuál es el valor de una solución exitosa?, ¿Cómo usted resuelve el problema actualmente?, ¿Qué retrasos ocurren o pueden ocurrir? Del Producto: ¿Qué problemas podría causar este producto en el negocio?, ¿En qué ambiente se usará el producto?, ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?, ¿Qué obstáculos afectan la eficiencia del sistema? El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su preparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan considerar no sólo la información que adquieren a través del cuestionario y la entrevista, sino también, su significancia.
  8. 8. 2.3. Aporte de los Requerimientos 2.3.1. Aporte Tecnológico La documentación de requerimientos es una de las más importantes partes del proceso de desarrollo de software, pero es, a la vez, una de las que cuenta con pocas herramientas de soporte tecnológico en la actualidad, aumentando el tiempo y costos del proyecto. A su vez es una etapa donde inevitablemente existe contradicciones y ambigüedad 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 conceptualización del problema es cuando el desarrollador de software tiene situaciones en que es escaso el conocimiento acerca del dominio de aplicación y el dominio de aplicación, 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 organización, observando las debilidades y dificultades que tiene, dando opiniones de solución, pasando por un proceso, lo que el cliente quiere, pasando a formar unos requerimientos más del sistema. Del mismo modo organiza mejor el tiempo y costo de presupuesto.
  9. 9. 2.3.3. Aporte Espiritual A través 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 contraposición 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 organización es una muestra de ella, el buen trabajo en equipo, tiempos establecidos, La equidad de trabajo, La disposición para ayudar al cliente de la mejor manera posible y sobre todo dan un producto de buena calidad. Todo lo mencionado ayuda a la formación del buen carácter del ser humano y da un buen testimonio del mismo.
  10. 10. 3. Conclusiones A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas. Cada actividad y técnica 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 razón, considero que no existe un modelo de proceso ideal para los Requerimientos; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema. Debemos recordar que la Ingeniería 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 cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.
  11. 11. Referencias Senn, A. (Ed.,1992). Análisis y Diseño de Sistemas de Información. México: 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. Ingeniería de Software. http://www.soi.city.ac.uk/gespan/sw_group_pub.html. (consultado el 28 de noviembre de 2013)

×