Henry cachicatari.pdf

Elicitacin de Requirimientos .

Por:

Cachicatari Mamani Perfecto Henrry.

[email protected]

Ingeniera de Software II.

Univesidad Nacional Jorge Basadre Grohmann.

mircoles 29 de abril de 2015

Facilitador:

Ing Geanfraco Mlaga Tejada.

[email protected]

Ingeniera de Software II. 2

Tabla de contenido

1. Introduccin.................................................................................................................................32. Objetivos......................................................................................................................................43. Marco terico...............................................................................................................................4

3.1 Tareas recomendadas.............................................................................................................43.1.1 Obtener informacin sobre el dominio del problema y el sistema actual.....................43.1.2 Preparar y realizar las sesiones de elicitacin/negociacin...........................................43.1.3 Identificar/revisar los objetivos del sistema..................................................................53.1.4 Identificar/revisar los requisitos de almacenamiento de informacin...........................53.1.5 Identificar/revisar los requisitos funcionales.................................................................53.1.6 Identificar/revisar los requisitos no funcionales............................................................5

3.2 Productos Entregables...........................................................................................................73.2.1 Documento de requisitos del sistema............................................................................7

3.3 Tcnicas de elicitacin..........................................................................................................83.3.1 Partiendo de los interesados..........................................................................................83.3.2 Anlisis de objetivo y meta............................................................................................93.3.3 Escenarios......................................................................................................................93.3.4 Anlisis de formularios..................................................................................................93.3.5 Lenguaje natural..........................................................................................................103.3.6 Reuso de requerimientos.............................................................................................103.3.7 Anlisis de tareas.........................................................................................................10

Bibliografa....................................................................................................................................12


1. Introduccin.

La Ingeniera de Software tradicional ofrece una serie de herramientas y procesos para la

elicitacin de requerimientos software que son utilizadas en proyectos de creacin de sistemas de

informacin automatizados. Se entiende por requerimientos a la especificacin de lo que debe

ser implementado. Ellos son descripciones de cmo debe comportarse el sistema

Tradicionalmente, los proyectos de desarrollo de software comienzan por obtener un

entendimiento del dominio del negocio y de las reglas que lo rigen. El entendimiento del

dominio permite diferenciar requerimientos, a nivel producto o a nivel dominio del negocio, que

delimitan el producto a construir respecto del contexto donde ser utilizado. Modelos como el

Diagrama de Contexto, Diagramas de flujos de datos, diagramas de secuencia, entre otros, sirven

para representar grficamente los procesos de negocio relevado y son utilizados como

herramientas para la validacin de los mismos. El analista funcional, que define los

requerimientos del producto software a construir, utiliza estas herramientas con el objetivo de

definir qu es lo que debe hacer el sistema software y no el cmo hacerlo. Adems, la

recopilacin de la informacin est orientada a los datos de entradas y salidas de los productos a

desarrollar y cmo esa informacin ser transformada por el sistema. En etapas posteriores del

proyecto, se trabaja en el cmo hacer para que el producto software satisfaga las necesidades

planteadas por el negocio y en la construccin del mismo. El producto obtenido es, entonces, un

sistema software que cumple con las caractersticas esperadas para el contexto en que ser

utilizado.

Las herramientas tradicionales de elicitacin de la Ingeniera en Software se enfocan en la

descripcin de los diferentes tipos de requerimientos, haciendo hincapi en las caractersticas que

debe cumplir el producto final. Tradicionalmente, los Proyectos de Desarrollo de Software

comienzan por obtener un entendimiento del dominio del negocio y de las reglas que lo rigen. El

entendimiento del dominio permite diferenciar requerimientos a nivel producto o a nivel dominio

del negocio [3] que delimitan el producto a construir respecto del contexto donde ser utilizado.

Modelos como el diagrama de contexto, diagramas de flujos de datos, diagramas de secuencia,

entre otros, sirven para representar grficamente los requerimientos relevados y ser utilizados

como herramientas para la validacin de los mismos. El Analista Funcional, que define los

requerimientos del producto software a construir, utiliza estas herramientas con el objetivo de

definir qu es lo que debe hacer el sistema software y no el cmo hacerlo. Adems, la


recopilacin de informacin est orientada a los datos de entradas y salidas de los productos a

desarrollar y cmo se transformar esa informacin en el sistema.

2. Objetivos

Entender el mbito y entorno de un proyecto en particular.

3. Marco terico

3.1 Tareas recomendadas

3.1.1 Obtener informacin sobre el dominio del problema y el sistema actual

Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es

fundamental conocer el dominio del problema y los contextos organizacional y operacional, es

decir, la situacin actual. Enfrentarse a un desarrollo sin conocer las caractersticas principales ni

el vocabulario propio de su dominio suele provocar que el producto final no sea el esperado por

clientes ni usuarios. Por otro lado, mantener reuniones con clientes y usuarios sin conocer las

caractersticas de su actividad har que probablemente no se entiendan sus necesidades y que su

confianza inicial hacia el desarrollo se vea deteriorada enormemente. Esta tarea es opcional, ya

que puede que no sea necesario realizar, si el equipo de desarrollo tiene experiencia en el

dominio del problema y el sistema actual es conocido.

3.1.2 Preparar y realizar las sesiones de elicitacin/negociacin

Teniendo en cuenta la informacin recopilada en la tarea anterior, en esta tarea se deben

preparar y realizar las reuniones con los clientes y usuarios participantes con objeto de obtener

sus necesidades y resolver posibles conflictos que se hayan detectado en iteraciones previas del

proceso. Esta tarea es especialmente crtica y ha de realizarse con especial cuidado, ya que

generalmente el equipo de desarrollo no conoce los detalles especficos de la organizacin para

la que se va a desarrollar el sistema y, por otra parte, los clientes y posibles usuarios no saben

qu necesita saber el equipo de desarrollo para llevar a cabo su labor.


3.1.3 Identificar/revisar los objetivos del sistema

A partir de la informacin obtenida en la tarea anterior, en esta tarea se deben identificar qu

objetivos se esperan alcanzar una vez que el sistema software a desarrollar se encuentre en

explotacin o revisarlos en funcin de los conflictos identificados. Puede que los objetivos hayan

sido proporcionados antes de comenzar el desarrollo.

3.1.4 Identificar/revisar los requisitos de almacenamiento de informacin

A partir de la informacin obtenida en la tareas 1 y 2, y teniendo en cuenta los objetivos

identificados en la tarea 3 y el resto de los requisitos, en esta tarea se debe identificar, o revisar si

existen conflictos, qu informacin relevante para el cliente deber gestionar y almacenar el

sistema software a desarrollar. Inicialmente se partirn de conceptos generales para

posteriormente ir detallndolos hasta obtener todos los datos relevantes.

3.1.5 Identificar/revisar los requisitos funcionales

A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuenta los objetivos

identificados en la tarea 3 y el resto de los requisitos, en esta tarea se debe identificar, o revisar si

existen conflictos, qu debe hacer el sistema a desarrollar con la informacin identificada en la

tarea anterior. Inicialmente se identificarn los actores que interactuarn con el sistema, es decir

aquellas personas u otros sistemas que sern los orgenes o destinos de la informacin que

consumir o producir el sistema a desarrollar y que forman su entorno. A continuacin se

identificarn los casos de uso asociados a los actores, los pasos de cada caso de uso y

posteriormente se detallarn los casos de uso con las posibles excepciones hasta definir todas las

situaciones posibles.

3.1.6 Identificar/revisar los requisitos no funcionales

A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuenta los objetivos

identificados en la tarea 3 y el resto de los requisitos, en esta tarea se deben identificar, o revisar

si existen conflictos, los requisitos no funcionales, normalmente de carcter tcnico o legal.

Algunos tipos de requisitos que se suelen incluir en esta seccin son los siguientes:


Requisitos de comunicaciones del sistema

Son requisitos de carcter tcnico relativos a las comunicaciones que deber soportar

el sistema software a desarrollar. Por ejemplo: el sistema deber utilizar el protocolo

TCP/IP para las comunicaciones con otros sistemas.

Requisitos de interfaz de usuario

Este tipo de requisitos especifica las caractersticas que deber tener el sistema en su

comunicacin con el usuario. Por ejemplo: la interfaz de usuario del sistema deber ser

consistente con los estndares definidos en IBMs Common User Access.

Se debe ser cuidadoso con este tipo de requisitos, ya que en esta fase de desarrollo

todava no se conocen bien las dificultades que pueden surgir a la hora de disear e

implementar las interfaces, por esto no es conveniente entrar en detalles demasiado

especficos.

Requisitos de fiabilidad

Los requisitos de fiabilidad deben establecer los factores que se requieren para la

fiabilidad del software en tiempo de explotacin. La fiabilidad mide la probabilidad del

sistema de producir una respuesta satisfactoria a las demandas del usuario. Por ejemplo:

la tasa de fallos del sistema no podr ser superior a 2 fallos por semana.

Requisitos de entorno de desarrollo

Este tipo de requisitos especifican si el sistema debe desarrollarse con un producto

especfico. Por ejemplo: el sistema deber desarrollarse con Oracle 7 como servidor y

clientes Visual Basic 4.

Requisitos de portabilidad

Los requisitos de portabilidad definen qu caractersticas deber tener el software para

que sea fcil utilizarlo en otra mquina o bajo otro sistema operativo. Por ejemplo: el

sistema deber funcionar en los sistemas operativos Windows 95, Windows 98 y

Windows NT 4.0, siendo adems posible el acceso al sistema a travs de Internet usando

cualquier navegador compatible con HTML 3.0.


3.2 Productos Entregables

El nico producto entregable que se contempla en esta metodologa es el Documento de

Requisitos del Sistema (DRS).

3.2.1 Documento de requisitos del sistema

En las siguientes secciones se describe con detalle cada seccin del DRS.

Figura 1: Estructura del Documento de Requisitos del Sistema


3.3 Tcnicas de elicitacin

3.3.1 Partiendo de los interesados

El ms intuitivo de los enfoques

Razones de las dificultades:

Poca claridad del usuario

Dificultad del usuario para transmitir su conocimiento

Diferencias entre usuario y analista

El usuario puede no querer el sistema

Se dispone de una serie de tcnicas

Entrevista de comienzo y final abierto

Entrevistas estructuradas

Brainstorming

Cada tcnica se desarrolla en la siguiente seccin:

Entrevistas de comienzo y final abierto

Forma ms simple de interaccin analista-usuario

El analista deja que el usuario hable de su tarea

Ambiente informal

tiles para obtener visiones generales

No son tiles para obtener informacin detallada

Entrevistas estructuradas

Direcciona al usuario hacia aspectos especficos de requerimientos a elicitar

Son tiles para informacin detallada

Preguntas cerradas, abiertas, de sondeo y de gua

Informacin para obstculos y soporte

Brainstorming

Se utiliza para resolver la falta de consenso entre usuarios

Es til combinarlo con la toma de decisiones

Ayuda a entender el dominio del problema


Encara la dificultad del usuario para transmitir

Reduce la falta de consenso

Ayuda a entender: al usuario y al analista

3.3.2 Anlisis de objetivo y meta

Propsito:

colocar los requerimientos en un contexto mayor

comprender la relacin de ese problema con los problemas y objetivos del sistema mayor (la jerarqua sistmica vale para los SBC)

tener los requerimientos adecuados

Analizar la organizacin y el ambiente externo

Crear una jerarqua meta-submeta consistente en: objetivos organizacionales, metas y restricciones y sus relaciones (soporte, conflicto, restriccin)

Validar y consensuar el modelo

Identificar la parte de la jerarqua meta-submeta que modeliza la parte de procesamiento de la informacin de la organizacin

Eliminar los casos de conflictos en el modelo anterior con los stakeholders

Seleccionar tareas (requerimientos) por eliminacin de alternativas

Permite una clara comprensin del dominio del problema

Requerimientos del problema en un contexto mayor

Considerar soluciones potenciales

3.3.3 Escenarios

Los usuarios encuentran ms fcil transmitir su experticia a travs de contar una historia

Es una solucin prometedora al problema de la comunicacin

3.3.4 Anlisis de formularios

Formulario = coleccin estructurada de variables que est formateada para soportar ingreso de datos y su recuperacin

Es una fuente importante pues:

es un modelo formal

es un modelo de datos

a menudo contienen informacin sobre la organizacin


sus instrucciones de uso encierran conocimiento sobre el dominio

su anlisis puede automatizarse

3.3.5 Lenguaje natural

Forma ms habitual de representacin del conocimiento

La mayora de lo que vale la pena conocer sobre el dominio del problema puede formularse en NL

Categoras de elicitacin en NL:

enfoques que interactan con el usuario

enfoques que elicitan desde un texto en NL

Su atractivo reside en:

vocabulario preexistente

informalidad

sintaxis

3.3.6 Reuso de requerimientos

Idea de base: los requerimientos capturados para alguna aplicacin pueden usarse en otra similar

Razones que la hacen interesante:

mejora global del proceso

similitud en sistemas

calidad

3.3.7 Anlisis de tareas

til en la interaccin hombre-mquina.

describe la tarea de los usuarios en trminos:

de actividades que ejecutan y cmo estn estructuradas

del conocimiento requerido para ejecutar esas actividades

opcin: anlisis jerrquico de tareas, en resumen, el anlisis de tareas:

es un valioso input el proceso de RE

el conocimiento sobre el dominio del problema se refiere al viejo sistema

es una base para el futuro sistema


Bibliografa

[1] Daft, R. L., "Teora y diseo organizacional.", (2005), Mxico: Tomson.

1. Introduccin.2. Objetivos3. Marco terico3.1 Tareas recomendadas3.1.1 Obtener informacin sobre el dominio del problema y el sistema actual3.1.2 Preparar y realizar las sesiones de elicitacin/negociacin3.1.3 Identificar/revisar los objetivos del sistema3.1.4 Identificar/revisar los requisitos de almacenamiento de informacin3.1.5 Identificar/revisar los requisitos funcionales3.1.6 Identificar/revisar los requisitos no funcionales

3.2 Productos Entregables3.2.1 Documento de requisitos del sistema

3.3 Tcnicas de elicitacin3.3.1 Partiendo de los interesados3.3.2 Anlisis de objetivo y meta3.3.3 Escenarios3.3.4 Anlisis de formularios3.3.5 Lenguaje natural3.3.6 Reuso de requerimientos3.3.7 Anlisis de tareas

Bibliografa

Henry cachicatari.pdf

Documents

Transcript of Henry cachicatari.pdf