lunes, 11 de marzo de 2013

UNIDAD II - INGENIERIA DE REQUISITOS

Con el paso de los años se ha podido constatar que los requerimientos o requisitos son esenciales en un proyecto de desarrollo de software, ya que es el mecanismo que permite entender lo que el cliente quiere, analizar sus necesidades, evaluar la factibilidad, especificar las necesidades de manera no ambigua, validarlas, y administrar estos requerimientos conforme evoluciona el desarrollo del proyecto.
Gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos.  La administración inadecuada puede desencadenar problemas como la falta de participación del usuario, requerimientos incompletos y una rastreabilidad errada de los mismos.  
Con el paso de los años se ha podido constatar que los requerimientos o requisitos son esenciales en un proyecto de desarrollo de software, ya que es el mecanismo que permite entender lo que el cliente quiere, analizar sus necesidades, evaluar la factibilidad, especificar las necesidades de manera no ambigua, validarlas, y administrar estos requerimientos conforme evoluciona el desarrollo del proyecto.
Gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos.  La administración inadecuada puede desencadenar problemas como la falta de participación del usuario, requerimientos incompletos y una rastreabilidad errada de los mismos.   

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que se enfoca en 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, las necesidades de los usuarios o clientes, minimizando problemas originados por la mala gestión de los requerimientos en el desarrollo de sistemas.
“La Ingeniería de requerimientos se entiende como el proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas necesidades”

Según IEEE  un “Requerimiento” es:  
“Una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado”. (Std 610.12-1900, IEEE: 62).  Por extensión el término requisito se aplica a las condiciones “que debe cumplir  o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especialización”
Estos pueden dividirse en 2 categorías: requerimientos funcionales y requerimientos no funcionales. 
Los requerimientos funcionales: son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema.  
Los requerimientos no funcionales: son características que de una u otra forma puedan limitar el sistema, por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, etc.  

2.1 TAREAS DE LA INGENIERIA DE REQUISITOS

En el proceso de la ingeniería de requisitos se ejecutan las tareas de inicio, obtención, elaboración, negociación, especificación, validación y gestión.  Dichas funciones deben adaptarse a las necesidades y particularidades de cada proyecto.
·         Inicio: tiene por objetivo identificar el ámbito general del proyecto.  Comienza con una serie de conversaciones informales entre los participantes del mismo (cliente, usuarios, grupo de desarrollo).
·         Esta fase suele estar acompañada de los documentos de definición de la visión global y la visión de dominio del sistema.
·         Obtención: Sugiere a los ingenieros actividades de recopilación de requisitos de manera organizada.
·         Elaboración: Los ingenieros de software crean un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención.   El modelo de análisis define el dominio de la información, las funciones y el compartimiento del problema 
·         Negociación: Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema.  De forma iterativa los requisitos se priorizan, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes.
·         Especificación: Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema.  La formalidad y especificación varían dependiendo de la complejidad del proyecto.
·         Validación: Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de los requisitos. 
Gestión de requisitos: Ayuda al equipo de proyecto a rastrear los requisitos según las características de los mismos, el código fuente relacionado, de dependencia entre requisitos, subsistemas e interfaces internas y externas; de forma que pueda identificarse con rapidez para entender cómo afectará una modificación diferentes aspectos del sistema a construir.

BIBLIOGRAFIA
http://www.google.com.mx/url?sa=t&rct=j&q=tareas%20de%20la%20ingenier%C3%ADa%20de%20requisitos&source=web&cd=9&cad=rja&ved=0CGIQFjAI&url=http%3A%2F%2Fgimnasioblc.googlecode.com%2Ffiles%2FArticulo.doc&ei=II86UbObEKjk2AXs8oDICQ&usg=AFQjCNG8--qP5QyBOvtTcb8kYhVCpPZ6KA&bvm=bv.43287494,d.b2U

2.2 TECNICAS DE LA INGENIERIA DE REQUERIMIENTIOS

Entrevistas y cuestionarios: estos son empleados para reunir información proveniente de personas o de grupos.  Durante la entrevista, el analista conversa con el encuestado.
El cuestionario es una serie de preguntas relacionadas con varios aspectos de un sistema. 
Los encuestados son usuarios de los sistemas existentes o usuarios en potencia del  sistema a desarrollar. Estos pueden ser gerentes o empleados que proporcionan datos para el sistema a desarrollarse  o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma. 
Sistemas existentes: esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser implementado.  En ellos se observan las interfaces de usuario, el  tipo de información que se maneja y cómo es manejada, así mismo,  se  analizan las distintas salidas que los sistemas producen como son: listados, consultas, etc., estos brindan nuevas ideas sobre cómo presentar la información. 
Lluvia de ideas (Brainstorm): este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable",  "imposible", etc. 
Las reglas básicas a seguir son:
·  Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas. 
·  Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque si no se crea un ambiente hostil que no alienta la generación de ideas.
·  Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil. 
·  A veces ocurre que una idea resulta en otra idea, y otras veces se puede relacionar varias ideas para generar una nueva. 
·  Escribir las ideas sin censura
Casos de Uso: los casos de uso son una técnica para especificar el comportamiento de un sistema. Estos ayudan a capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje, en palabras del IVAR JACOBSON "Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario"[1] 
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. 
“Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos pendencia entre requisitos, subsistemas e interfaces internas y externas; de forma que pueda identificarse con rapidez para entender cómo afectará una modificación diferentes aspectos del sistema a construir.

BIBLIOGRAFIA
http://www.google.com.mx/url?sa=t&rct=j&q=tareas%20de%20la%20ingenier%C3%ADa%20de%20requisitos&source=web&cd=9&cad=rja&ved=0CGIQFjAI&url=http%3A%2F%2Fgimnasioblc.googlecode.com%2Ffiles%2FArticulo.doc&ei=II86UbObEKjk2AXs8oDICQ&usg=AFQjCNG8--qP5QyBOvtTcb8kYhVCpPZ6KA&bvm=bv.43287494,d.b2U

2.3 MODELADO DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario.
El modelo de requisitos es el primer modelo en desarrollarse y es la base para formar todos los demás

modelos en el desarrollo de software.  En la metodología Objectory (Jacobson), el modelo de requisitos consta de tres modelos: 
  • Modelo de Comportamiento
El modelo de comportamiento, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario. Este modelo está basado directamente en el Modelo de Casos de Uso. 
  • Modelo de Casos de Uso
El Modelo de Casos de Uso describe las funcionalidades del sistema a partir de las interacciones del usuario.
Actores:
  •  Primaros: Son la razón principal de existencia del problema y rigen la secuencia lógica de ejecución del sistema
  • Secundarios: Actores que supervisan y apoyan al sistema y por lo general son máquinas o sistemas externos.
Casos de Uso:  
Los casos de uso representan las funcionalidades del sistema. Cada caso de uso define una forma particular de usar el sistema. Un caso de uso constituye un flujo completo de eventos que especifican la interacción entre el actor y el sistema. Las diferentes instancias de los casos de uso se denomina escenario.
Para identificar los casos de uso se parte de la descripción del problema, donde surgen preguntas como:
·         ¿Cuáles son las tareas principales de cada actor?
·         ¿Tendrá el actor que consultar y modificar información del sistema?
·         ¿Deberá el actor informar al sistema sobre cambios externos?
·         ¿Desea el actor ser informado sobre cambios inesperados?

  • Modelo de Presentación
El modelo de presentación o modelo de interfaces especifica como interactúa el sistema con los actores externos al ejecutar los casos de uso.

  • Modelo de Interfaces
El modelo de interfaces describe la presentación de la información entre los actores y el sistema. Se especifica en detalle cómo se verán las interfaces de usuario al ejecutar uno de los casos de uso. Una
estrategia interesante es un prototipo del sistema.

  •   Modelo de Información
El modelo de información o modelo del dominio del problema, especifica los aspectos estructurales de la aplicación en términos de objetos.
Este modelo permite identificar cuáles son los objetos relevantes del sistema, que permitirán guardar información de forma temporal o permanente. 
  • Modelo del Dominio del Problema
El modelo del dominio del problema define un modelo de clases del sistema. El modelo de clases consiste en los objetos del dominio del problema.
El propósito principal de este modelo es formar una base común de entendimiento del desarrollo y no definir el sistema completo.

domingo, 10 de marzo de 2013

2.4 HERRAMIENTAS CASE PARA LA INGENIERIA DE REQUISITOS


Cuando se habla del proceso de desarrollo de software se enfatiza en las necesidades de los usuarios, traducidas en requisitos de software, y estos a su vez son transformados en diseño directamente convertido  en la implementación del código, debidamente probado, documentado y certificado para su uso operativo.
Con el ánimo de facilitar las tareas del desarrollo de software, surgen herramientas informáticas que agilizan la labor en la IR. Dichas herramientas son denominadas CASE (Ingeniería de software asistida por computador), y sirven de apoyo para los desarrolladores, desde el principio hasta el final del proceso.
Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a  editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:

*        IRQA 4
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo.
Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente.

*        RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema;  básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.
Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Mo delo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información en el segundo prototipo.

*       CONTROLA
Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos.
Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.



*        OSRMT (Open Source Requirements Management Tool)
Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en  arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

*        JEREMIA
Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.
Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL.

*       RAMBUTAN
Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona.
Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos. Comparada con otras herramientas de gestión de requisitos, Rambután ofrece las siguientes ventajas competitivas: Aplicación cliente para palm (PDAclass), portabilidad entre plataformas, es independiente de cualquier metodología de especificación de requisitos, y permite distribución libre.

Existen otras herramientas en estudios para la gestión de requisitos como lo son:
CaliberRM, REM, SMART TRACE, SoftREQ, Analyst Real Team System (ARTS), CARE 3.2, CORE 5.1, Cradle 5.2, Envision VIP, Gatherspace, IBM Rational RequisitePro, KollabNet Editor 2005, PACE, RaQuest 3.0, RMTrak, RTM, SLATE REquire 6.5, SoftREQ, UGS Teamcenter 2005, truereq product desktop, XTie-RT, Specification Analysis Tool (SAT), ECM, Banyan2.2, Contour, Projectricity 3.5, FeaturePlan 2.6, analyst pro, ChangeWare 2.0, aligned elements, Dassault Systemes CSE 4.0, Polarion ALM for Subversion 3.0, Telelogic DOORS, Accept 360.

La ingeniería de requisitos es una tarea que aún tiene mucho por explorar para optimizar sus tareas y cumplir a cabalidad los objetivos propuestos. Igualmente, es necesario realizar una evaluación de  funcionalidad y rendimiento de las herramientas existentes, con el fin de depurarlas, ya que al aumentar su número se hace más difícil la elección para la gestión de recursos.

BIBLIOGRAFIA
http://www.revistasjdc.com/main/index.php/ccient/article/download/37/36