RUP, Requerimientos

Resumen

El objetivo principal es establecer lo que un sistema debe hacer, brindar una guía para encontrar, organizar, documentar, y seguir los cambios de los requerimientos funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los requerimientos; cuando este término es empleado en la metodología RUP se dice que son las necesidades de un usuario para resolver un problema o alcanzar un objetivo, basándose este hecho a una condición primordial presente en un sistema o componente del mismo para satisfacer una especificación dada. Cuando se inicia el proceso de desarrollo de software, se debe comenzar con la recolección de requerimientos de usuario. Para lograr un mayor acercamiento y entendimiento a éstos requerimientos, se deben analizar y describir diferentes enfoques, logrando así un diagnóstico de la situación actual del negocio.

Palabras Claves: Metodologías; Procesos; Enfoques; Requerimientos, RUP.

ABSTRACT

The main objective is to establish what a system should do, provide guidance to find, organize, document, and track changes of functional requirements and constraints. It uses a notation of use case and scenarios to represent the requirements, when this term is used in the RUP methodology is said to be the needs of a user to solve a problem or achieve an objective basis this to a primordial condition present in a system or component thereof to meet a given specification. When the software development process starts, begin with gathering user requirements. To achieve reconciliation and understanding to these requirements, they must analyze and describe different approaches, achieving a diagnosis of the current business situation.

Key words: Methodologies, Processes, Approaches, Requirements, RUP.

Introducción

La importancia que hoy en día se le da al software radica en que prácticamente todas las organizaciones dependen de éste para realizar sus funciones diarias, también se considera la Tecnología Informática como estrategia para obtener ventaja competitiva. Por éstas razones y muchas más, el desarrollo de proyectos de software se ha convertido en una de las áreas con mayor campo de acción dentro de las disciplinas tecnológicas.

Pero el desarrollo de software no es sencillo, ya que por medio de éste se modelan las principales funcionalidades ofrecidas por el negocio, se abstrae el funcionamiento de la organización y por lo mismo, se vuelve más complejo en tanto más compleja sea la organización.

Según, (Zavala, J), para trabajar en el desarrollo de un software, existen metodologías que se dividen en varias etapas que proporcionan procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a crear software de calidad.

La metodología indica cómo hay que obtener los distintos productos parciales y finales. Entre las metodologías más importantes se encuentran la Metodología de Rational Unified Process (RUP), Extreme Programing (XP), Microsoft Solution Framework (MSF), el modelo en espiral, en cascada, espiral, prototipos y Método en V.

(Gary, K. 2002), menciona que a pesar de la aplicación de las metodologías y estrategias de la ingeniería en el desarrollo de software, se observa, con el pasar de los años que el desarrollo de los proyectos de software en la mayoría de los casos no culmina exitosamente. El 75 % de los productos de software grandes se entregaron a los clientes pero tienen fallas, son un fracaso porque no se usan o no cumplen los requerimientos del cliente. Lo que provoca grandes tasas de fracasos por la indefinición precisa de las necesidades o requerimientos. Esto se puede notar a partir del origen de los errores en el software; se estima que el 56% de los errores en los proyectos se da por el mal desarrollo en la etapa del Estudio y Análisis, 10% en el diseño, 7% en el código y el 27% en errores varios. Las anteriores cifras muestran la realidad de los fracasos de proyectos software, por eso es indispensable que se reconozca la importancia de cada una de las etapas de las metodologías de desarrollo de software.

Resulta indispensable tomar en cuenta de que la parte fundamental para el desarrollo de software es la identificación de requerimientos, la cual se constituye como una disciplina de la Ingeniería de Software llamada Ingeniería de Requerimientos (IR). La IR, es una etapa en la que el usuario define lo que quiera que haga el sistema; identifica las funciones principales del sistema, el alcance del modelamiento del mundo y documenta los procesos principales y las políticas que el sistema va a soportar.

Desarrollo del tema

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.

• Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer más todas las restricciones sobre la funcionalidad.

• Los requerimientos forman un modelo completo, representando el sistema total a algún nivel de abstracción.

Fig. 1 ciclo de vida del RUP.

2.1 Clasificación de los requerimientos

2.1.1 Requerimientos funcionales

Según (James, A. 2000). Son aquellos servicios que el usuario espera del sistema. En general, al usuario no le interesa cómo se aplican esos servicios, así que el ingeniero de software debe evitar la inclusión de conceptos de aplicación en esta sección del documento de los requisitos. En principio, los requisitos funcionales de un sistema deben ser completos y consistentes. Por completo se entiende que todos los servicios requeridos por el usuario deben especificarse, y la consistencia significa que ninguna definición de requisitos debe contradecir a otra. En la práctica, y para sistemas grandes y complejos, es casi imposible lograr que los requisitos sean consistentes y completos en la versión inicial del documento. A medida que se descubren los problemas durante las revisiones o en las etapas posteriores del ciclo de vida, el documento debe modificarse en consecuencia, hay tres maneras de expresar los requisitos funcionales de un sistema:

1. En lenguaje natural

2. En un lenguaje estructurado o en un formato que tenga algunas reglas, pero no una especificación sintáctica o semántica rigurosa,

3. En un lenguaje formal de especificación con una sintaxis y semántica definidas.

2.1.2 Requerimientos no funcionales

Son restricciones u obligaciones impuestas al servicio de éste. Ejemplos de requisitos no funcionales son las obligaciones impuestas a los tiempos de respuesta del sistema, las limitaciones en la cantidad de memoria que ocupará el software y las restricciones en la representación de los datos del sistema.

Aunque tanto los requisitos funcionales como los no funcionales están sujetos a cambios, los requisitos no funcionales se ven especialmente afectados por los cambios en la tecnología de hardware, (James, A. 2000).

Rendimiento del sistema: fiabilidad, tiempo de respuesta, disponibilidad

Interfaces: dispositivos de E/S, usabilidad, interoperabilidad.

Proceso de desarrollo: estándares, herramientas, plazo de entrega.

2.2 Etapas de la fase de requerimientos

• Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés.

• Análisis: comprobación de la consistencia y completitud de los requerimientos.

• Verificación: constatación de que los requerimientos especificados son correctos.

2.3 Administración de requerimientos

• Licitar, organizar, y documentar la funcionalidad y restricciones requeridas.

• Llevar un registro y documentación de cambios y decisiones.

• Los requerimientos de negocio son fácilmente capturados y comunicados a través de casos de uso.

• Los casos de uso son instrumentos importantes de planeación.

2.4 Análisis de requerimientos en RUP

Markus R, and Wirkungsforschung, (2007). Dice que el análisis da como resultado un modelo del sistema que pretender ser correcto, completo, consistente y verificable. Los desarrolladores formalizan la especificación del sistema producida durante la obtención de requerimientos y examinan con mayor detalle las condiciones de frontera y los casos excepcionales. El cliente y el usuario están involucrados, por lo general, en esta actividad, en especial cuando se necesita cambiar la especificación del sistema y cuando se necesita recopilar la información adicional.

2.5 De donde provienen los requerimientos

Fuente: Monografías.com

2.6 Características que deberían cumplir los requerimientos

• Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.

• Cohesión: el requerimiento debe dirigirse a solo una única cosa.

• Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.

• Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.

• Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.

• Factible/viable: el requerimiento debe poder ser implementado.

• No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única manera.

• Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada.

• Observable externamente:

El requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.

• Verificable/demostrable:

La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba

2.7 Ingeniería de Requerimientos vs. Administración de Requerimientos

(Rumbaugh, J.), define que el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para: Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.

Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar. Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.

Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema de ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma más adecuada posible.

2.8 SEMEJANZAS CONCEPTUALES: RUP and PMBOK

El PMBOK (Project Management Body of Knowledge) (cuerpo de conocimientos de gerenciamiento de proyectos) del PMI (Project Management Institute) representa las mejores prácticas en gestión de proyectos; El PMBOK documenta la información necesaria para iniciar, planificar, ejecutar, supervisar y controlar, y cerrar un proyecto individual, e identifica los procesos de la dirección de proyectos que han sido reconocidos como buenas prácticas para la mayoría de los proyectos, la mayor parte del tiempo. Estos procesos se aplican globalmente y en todos los grupos de negocios o industriales.

• a. Jerarquías de Proceso

Fuente: PAGE Technologies

Ambos recomiendan dividir proyectos en varias fases

• b. Diferencias entre RUP and PMBOK

• El PMBOK se describen directrices basadas en las mejores prácticas de la industria.

• RUP ayuda a los equipos de desarrollo de software implementar las mejores prácticas de la industria de software. Mientras que RUP es una herramienta independiente, cuando se utiliza en combinación con las herramientas de desarrollo de software de IBM, puede mejorar significativamente la productividad, la integridad, la reutilización, y más.

• El PMBOK describe un ciclo de vida del proyecto genérico.

• RUP prescribe un ciclo de vida de desarrollo de software genérico dentro de un ciclo de vida del proyecto.

• PMBOK describe las directrices para proyectos de cualquier tamaño.

• RUP se puede adaptar para implementar cualquier proyecto de software.

Fuente: PAGE Technologies

• c. Fases del RUP and PMBOK

Fuente: PAGE Technologies

• APORTE SOCIAL

El cliente lo que busca es satisfacer sus prioridades haciendo sus tareas más fáciles, por tal motivo cuando se hace un sistema debe ser en lenguaje natural, sin dar complicaciones al usuario, caso contrario daríamos realce a lo que dice "Las soluciones de hoy son los problemas de mañana". Los principales requerimientos para una sociedad limpia son los valores.

• APORTE ESPIRITUAL

En la vida espiritual; el requerimiento principal es el Bautismo. En la vida diaria de cada persona se debe realizar diferentes tipos de procesos para alcanzar la vida eterna, un análisis a nuestra vida es lo primordial que debemos hacer; cuando diseñamos un sistema tiene diferentes requerimientos para satisfacción del usuario; tan igual Dios nos brindó los requerimientos necesarios para heredar las mansiones celestiales y las normas son tan claras que no hay complicaciones para perdernos de esta maravillosa esperanza la segunda venida de Jesús.

Conclusiones

• Se cuenta con una visión sobre el proceso de desarrollo de software y se debe asumir el compromiso de establecer los requerimientos del sistema como parte esencial en el éxito de los proyectos.

• Lo importante de los requerimientos al transmitirlos es que sean claros, únicos (no redundante o que se tengan conflictos con otros), que sean concretos y que ante todo se alineen al objetivo o visión inicial.

• Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software. 

• Uno de los requerimientos más importantes (y que muchas veces se nos olvida) es el personal con el que se cuenta para llevar a cabo el proyecto.

Referencias

• James A. Senn, Análisis y Diseño de Sistemas de Información, Segunda Edición, Mc Graw Hill, Abril 2000.

• Metodologías de Desarrollo de Software, disponible en, http://alarcos.inf-cr.uclm.es/doc/ SOFTWAREI/ Tema04.pdf.

• IBM. (2003). Rational Unified Process. Europa: Rational Unified Process.zip

• Ingeniería de software, disponible en http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software.

• Ingeniería de software, disponible en http://www.monografias.com/trabajos12/ingreq/ingreq.

• http://www.agilemodeling.com/essays/changeManagement.htm

• Jesús María Zavala Ruiz, ¿Por Qué Fracasan los Proyectos de Software?; Un Enfoque Organizacional, 2004 disponible en, http://www.consol.org.mx/2004/material/63/por-que-fallan-los-proy-de soft.pdf.

• PAGE Technologies, Inc., Proprietary, 2002 www.pagetechnologies.com

Autor:

Joyse Baldwin Huamán Labán1,

Herdy Jioberth Osorio Palacios2

Autor – Estudiante de la Universidad Peruana Unión