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.

• Agile Requirements Change Management

• 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