INSTITUTO TECNOLGICO DE TUXTEPEC

ING. EN SISTEMAS COMPUTACIONALES FUNDAMENTOS DE INGENIERA DEL SOFTWARE

UNIDAD II: INGENIERA DE REQUISITOS

ACTIVIDAD INVESTIGACIN SOBRE LAS APLICACIONES DEL MODELADO Y SUS ESPECIFICACIONES

PROFE:
MARIA DE LOS ANGELES MARTINEZ MORALES

ALUMNOS:
ANTONIO GOMEZ MARIA DEL ROSARIO JORGE RAFAEL CLEOTILDE MARTINEZ HERRERA KEREN ARADI CONTI SANCHEZ CRISTHIAN JOAQUIN VICENTE MENDOZA ANTONIO

19/SEPTIEMBRE/2012

CONTENIDO

En este trabajo se presenta un enfoque de Ingeniera de Requisitos para el modelado conceptual de sistemas de informacin. Su principal objetivo es proporcionar un conjunto de tcnicas y guas para capturar los requisitos del software, analizarlos y expresarlos en un esquema conceptual de OO-Method garantizando la trazabilidad entre stos. El enfoque se basa en un marco referencial de herramientas de especificacin de requisitos (TRADE) y un mtodo grfico orientado a objetos para el modelado conceptual con capacidades de generacin automtica de cdigo (OO-Method). Se define la estructura y tcnicas para la construccin de un Modelo de Requisitos funcionales del sistema y a partir de este modelo, un Proceso de Anlisis de Requisitos (PAR) define constructores que permiten representar dichos requisitos en elementos del Modelo Conceptual de OO-Method. Utilizando este proceso cada elemento del Modelo de Requisitos tiene una representacin perfectamente identificable en el Modelo Conceptual OO-Method y cada elemento del Modelo Conceptual tiene su origen en el Modelo de Requisitos.

INTRODUCCIN

En este tema nos damos cuenta que a menudo los diseadores de sistemas cometen el error de comenzar a disear e implementar soluciones que no han sido completamente especificadas y que corresponden a problemas a los que les falta delimitacin, lo cual conduce a la construccin de sistemas que no satisfacen las necesidades de los clientes y que incurren en el aumento de los costos y en el incumplimiento de los plazos establecidos. Ms an, generalmente estos mtodos carecen de directrices adecuadas para el desarrollo de modelos conceptuales derivados de las especificaciones y posteriormente de cdigo que sea funcionalmente equivalente a dichos modelos conceptuales. Como un esfuerzo para la superacin de estas limitaciones, en este trabajo se presenta un enfoque sistemtico de Ingeniera de Requisitos que define un proceso que posibilita la descomposicin sistemtica y repetitiva de los requisitos de software hasta obtener una detallada especificacin que constituir el modelo conceptual del sistema deseado. Este enfoque pretende mejorar la calidad del proceso de produccin de software: Proporcionando predecibilidad mediante la construccin de un modelo conceptual como una precisa, estructurada y bien definida representacin de los requisitos de los usuarios. Aumentando la productividad al establecer vnculos precisos entre el modelo conceptual y los requisitos de los usuarios. Esto facilitar la incorporacin en el modelo conceptual de cambios en los requisitos. En consecuencia, tales modificaciones quedarn reflejadas tambin en el sistema de software desarrollado.

DESARROLLO

El modelado de requisitos nos sirve y tiene como propsito comprender completamente el problema y todo lo que ste implica y conlleva. Su objetivo principal es delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Adems el modelo de requisitos captura las principales caractersticas del sistema de software que se desea construir. Por medio de l representamos los requisitos del sistema de forma sencilla, para que de esta manera cualquier usuario pueda revisarlo y adems entenderlo, sin necesidad de tener conocimientos previos al modelo e informacin. Intervienen en el los modelos de caso de uso, que desempean un papel importante de gran relevancia. En el estudio del modelo de requisitos se encuentran los funcionales y no funcionales. Cabe mencionar que los requisitos determinan lo que har el sistema, es decir, como funcionar adems, las restricciones sobre su operacin e implementacin. La elicitacin, anlisis y especificacin de requisitos es el proceso del estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema. Un requisito es una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Puede verse como una declaracin abstracta de alto nivel de un servicio que el sistema debe proporcionar. Los requisitos funcionales: son la caracterstica requerida del sistema que expresa una capacidad de accin del mismo, una funcionalidad; generalmente expresada en una declaracin en forma verbal. No todo lo que necesitaremos en nuestro sistema es funcionalidad pura; por el contrario a veces se necesitan otras cualidades, si se quieren generalidades, que no son objeto de codificacin si bien es cierto que pueden llegar a afectar a esta. Pueden ser frases muy generales sobre lo que el sistema debera hacer. Se suelen expresar como objetivos del sistema. Deben describir los servicios que hay que proporcionar con todo detalle (casos de uso). Requisitos no funcionales: caracterstica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que seala una restriccin del mismo. Son todas las exigencias de cualidades que se imponen al proyecto: exigencias de usar un cierto lenguaje de programacin o plataforma tecnolgica, por ejemplo, Un requisito no funcional

es una caracterstica ya sea del sistema, del proyecto o del servicio de soporte, que nos es requerida junto con la especificacin del sistema pero que como ya dije, no se satisface aadiendo cdigo, sino cumpliendo con esta como si de una restriccin se tratara. Los requisitos no funcionales pueden clasificarse en: Requisitos del producto: especifican el comportamiento del producto obtenido. Requisitos organizacionales: son una consecuencia de las polticas y procedimientos existentes en la organizacin. Requisitos externos: presentan factores externos al sistema y a su proceso de desarrollo. Adems, existen los requisitos de usuarios, que nos dice que el sistema debe permitir representar y acceder a archivos externos creados por otras herramientas. Los requisitos del sistema asociado nos dice que el usuario deber poder definir el tipo de un nuevo archivo externo, el usuario deber poder definir el icono que representa un tipo de archivo externo. Encontramos as mismo los requisitos verificables, los requisitos no funcionales suelen ser muy difciles de expresar con exactitud, ya que los requisitos imprecisos pueden ser difciles de verificar, como por ejemplo: un deseo general del usuario es la facilidad de uso. Un requisito no funcional verificable, una frase que incluye alguna medida que puede ser objetivamente probada. Derivado de esto aparecen problemas cuando los requisitos no se precisan con exactitud, por ejemplo, los requisitos expresados de forma ambigua se pueden interpretar de manera diferente por los desarrolladores y por los usuarios. Por tal motivo se busca como objetivo que la especificacin debe ser completa y consistente, completa en el sentido de que todos los servicios solicitados por el usuario estn definidos. Y consistente en que los requisitos no tengan definiciones contradictorias. El proceso de anlisis de requisitos, considera los aspectos relativos al anlisis de las funcionalidades y la traduccin al modelo conceptual. Existen tres tcnicas que nos permiten generar el modelo de requisitos: Misin del sistema: describe cual es el propsito del sistema, sus responsabilidades y el alcance que tendr. A travs de l podemos determinar, en trminos generales, que har y que no har el sistema. Aunque es una tcnica sencilla es de vital importancia para el desarrollo del sistema.

rbol de refinamiento de funciones: descompone el sistema en interacciones externas, de acuerdo a algn criterio preestablecido. Cabe mencionar que las interacciones externas son organizadas en funciones que forman una jerarqua a manera de rbol, en cuyo nivel ms alto (raz) se ubica la misin del sistema. Esta Misin del Sistema es refinada hasta obtener otras funciones elementales representadas en la jerarqua a travs de los nodos hoja. Este proceso descendente de refinamiento funcional puede generar distintos niveles de nodos. Aquellos que estn entre la raz y los nodos hoja son denominados nodos intermedios. Un nodo intermedio es un sumario de funciones elementales. En general, una rama completa de nodos con origen en la raz del rbol, representa toda la funcionalidad relativa a un rea o actividad de la organizacin, segn el criterio de descomposicin utilizado.

Modelo de casos de uso: El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso. De esta forma, la especificacin de actores y casos de uso as como el establecimiento de las relaciones entre stos, constituye el objetivo fundamental del Modelo de Casos de Uso. El principal insumo requerido para el desarrollo de este modelo son las funciones elementales identificadas como nodos hoja en el rbol de Refinamiento Funcional del sistema. Cada una de estas funciones elementales es considerada en el modelo como un caso de uso. Luego de identificar sus actores, la especificacin de los casos de uso describe en lenguaje natural la secuencia completa y ordenada de las acciones que el sistema debe ejecutar, incluyendo todas sus posibles variantes, al interactuar con los actores para la satisfaccin de los requisitos.

Describe un sistema en trmino de sus distintas formas de utilizacin, cada una de esas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Los actores son entidades distintas a los usuarios, representan un cierto papel que una persona real puede jugar. Modelan cualquier entidad externa que necesite intercambiar informacin con el sistema. No estn restringidos a ser personas fsicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que representen entidades externas al sistema. Cada uno de los actores podr ejecutar una o ms tareas del sistema. El flujo de eventos que se desarrolla entre el actor y el sistema para el logro del objetivo del caso de uso es narrado en la especificacin, a manera de conversacin, a travs de una secuencia numerada de pasos. Esta

clasificacin separa las acciones del actor de las ejecutadas por el sistema y las distingue de aquellas relativas al contexto donde se desarrolla el caso de uso. A medida que se alcanza un mayor conocimiento del dominio, este texto crece en tamao y detalle adquiriendo formas complejas que limitan su comprensin y posterior uso en las distintas etapas de la construccin del sistema. Con el propsito de minimizar el impacto de estos problemas, la descripcin de los casos de uso es estructurada precisndose su nivel de detalle en trminos de las necesidades del modelado y del momento de desarrollo del sistema. El nivel de abstraccin de un caso de uso est vinculado al contenido informativo relevante o significativo que se desea expresar en el caso de uso. El propsito principal de este proceso es identificar las responsabilidades ms significativas del sistema en desarrollo. Las responsabilidades conllevan a la definicin de operaciones, esto es, a la especificacin de los servicios de una clase. Con el propsito de describir las responsabilidades detectadas en el contexto de un Caso de Uso se utilizan Diagramas de Secuencia con notacin UML. En estos diagramas se representan las responsabilidades, identificando el objeto que la invoca (objeto cliente) y el objeto al que sta pertenece (objeto servidor). Para mostrar las decisiones sobre asignacin de responsabilidades entre los objetos, el Proceso de Anlisis de Requisitos prev la especificacin de Diagramas de Secuencia pero a muy alto nivel y como herramienta para representar estas responsabilidades. Un escenario es una secuencia especfica de las acciones que describe un caso de uso. As, un caso de uso puede ser considerado como la compilacin de mltiples escenarios algunos de los cuales, los primarios, describen su trayectoria normal mientras que otros, los secundarios, se refieren a sus trayectorias alternas. Los diagramas de secuencia permiten describir patrones de interaccin entre objetos o clases. A travs de estos diagramas se muestra la secuencia ordenada en el tiempo de los mensajes que envan y reciben genricamente los objetos durante la ejecucin de un escenario. Un estmulo es una comunicacin entre dos objetos que se transmiten informacin con la finalidad de que se ejecute una actividad. Un mensaje especifica los roles que deben cumplir tanto el objeto emisor (el cliente) como el objeto receptor del estmulo (el servidor) as como la accin que

ser ejecutada. De esta forma, a travs de los mensajes se expresan las responsabilidades que cumplirn los objetos en el sistema. En el Proceso de Anlisis de Requisitos, es posible utilizar dos tipos de diagramas de secuencia, que va a depender del momento y estrategia de desarrollo seguida as como tambin del nivel de detalle deseado. 1) OO-Method: hace nfasis en la interaccin, en trminos de los actores y el sistema, mostrando el flujo de eventos que ocurren en el dominio del problema. Este tipo de diagrama de secuencia muestra las responsabilidades pero no los objetos clientes ni los objetos servidores (dada una especificacin de Casos de Uso con sus pasos se obtiene automticamente donde cada paso se convierte en un auto-mensaje). 2) La evolucin del primero: representa de manera precisa y detallada las interacciones entre los actores y el sistema pero, esta vez, indicando el intercambio de mensajes entre las clases de objetos participantes. Se muestran las responsabilidades y tambin las clases de objetos clientes y servidores. El Proceso de Anlisis de Requisitos consiste, bsicamente, en la construccin de los diagramas de secuencia OO-Method a partir del Modelo de Requisitos del sistema. Los diagramas de secuencia, adems de expresar en detalle los resultados del Proceso de Anlisis de Requisitos, constituyen un recurso de mucha importancia para la construccin del Modelo de Objetos. Con esta finalidad, se ha incorporado en estos diagramas cierta informacin que resulta de inters para identificar elementos de este modelo. Esta informacin se expresa estereotipando los mensajes del diagrama de secuencia con el propsito de distinguirlos segn la clasificacin.

El modelo de trazabilidad es utilizado para relacionar los distintos elementos del Enfoque de Ingeniera de Requisitos con los elementos del Modelo Conceptual, se caracteriza por ser estructural y estar basado en referencias cruzadas. Esto significa, que la relacin establecida entre estos elementos es estructural. En segundo lugar, se establecen explcitamente referencias entre los elementos a diferentes niveles de abstraccin. Por otra parte, la trazabilidad en el enfoque de Ingeniera de Requisitos puede ser estudiada desde dos perspectivas:

Internamente.- la trazabilidad es establecida entre los elementos de las distintas tcnicas del Modelo de Requisitos y entre stos y los que pertenecen al Proceso de Anlisis de Requisitos. Externamente, la trazabilidad queda determinada por los vnculos establecidos entre los elementos de dicho proceso y los constructores del Modelo Conceptual.

Encontramos dentro de ste proceso la validacin y gestin de requisitos, que consiste en demostrar que los requisitos definen el sistema que los clientes desean. Y por lo tanto los costes de los errores en los requisitos son muy altos por lo que la validacin funge como un factor muy importante en dicho proceso. La gestin de los requisitos es el proceso de manejar los requisitos que cambian durante el desarrollo del sistema. Los requisitos pueden ser inevitablemente inconsistentes e incompletos. Dentro de las aplicaciones del modelado de requisitos encontramos: los procesos de negocio de la organizacin se identifican partiendo de sus propios objetivos, y se describen mediante flujos de actividades que se representan mediante diagramas de actividades UML. De este modo, los casos de uso del sistema se obtienen a partir de las actividades de los procesos del negocio, se organizan jerrquicamente y se facilita su desarrollo iterativo e incremental. Las clases del modelo conceptual se obtienen a partir de los objetos de informacin que fluyen entre las actividades. A la vez que se realiza el modelado del negocio y de los requisitos, las reglas del negocio de la organizacin se recogen en un glosario, en forma de especificacin de las actividades y de los casos de uso asociados, as como de los objetos de informacin y de las clases que los implementan. Esto permite mantener las correspondientes relaciones de trazabilidad entre los diferentes artefactos del modelado. Adems, el hecho de que los requisitos surjan de la descripcin de los procesos del negocio, y que stos sean el resultado del anlisis de los objetivos de la organizacin, posibilita que los requisitos del sistema sean validados y verificados contra los objetivos del negocio. Adems tambin encontramos su utilizacin en aplicaciones web. Los sitios Web, por lo general, son complejos y enormemente dinmicos. Requieren fases de desarrollo cortas con la finalidad de tener listo el producto y ejecutarlo rpidamente. Con frecuencia, los desarrolladores van directo hacia la fase de codificacin sin comprender que estn tratando de construir o como quieren construirlo. La codificacin respecto del servidor con frecuencia se hace ad hoc, las tablas de bases de datos se agregan conforme se necesitan y la arquitectura evoluciona en una forma a veces no intencional.

El anlisis de requisitos para las WebApps abarca tres grandes tareas: Formulacin, recopilacin de requisitos, y modelado de anlisis. Durante la formulacin se identifica la motivacin (metas) y los objetivos bsicos para la WebApp, y tambin se define las categoras de usuario. Los requisitos de contenido y funcionales se enlistan y se desarrollan los escenarios de interaccin (casos de uso) descritos desde el punto de vista del usuario final.

La jerarqua de usuario. Las categoras de usuario finales que interactuarn con la WebApp se identifican como parte de las tareas de formulacin y de recopilacin de requisitos.

En la mayora de los casos las categoras de usuario son relativamente limitadas y no necesitan de representacin UML.

Desarrollo de casos de uso Los casos de uso se desarrollan par cada categora de usuario descrita en la jerarqua de usuario. En el contexto de ingeniera Web, el caso de uso en s mismo es relativamente informal: un prrafo narrativo que describe una interaccin especfica entre un usuario y la WebApp.

CONCLUSIN

Recordemos que el objetivo de la ingeniera del software es el desarrollo de sistemas apegados a las necesidades del cliente, pero tambin ajustados a otros criterios, como el modelo de negocio, los recursos disponibles y el tiempo de entrega. Es obvio espero, que la ingeniera del software no solo ha de cumplir con la funcionalidad (escribir cdigo ajustado a los requisitos funcionales) sino tambin con las cualidad suplementarias (requisitos no funcionales) o de lo contrario no cumplir con su misin: desarrollar el software que se necesita en el momento y condiciones que se tienen disponibles; o dicho de otra manera, desarrollar software de calidad.

Tambin nos damos cuenta que el modelado de requisitos nos sirve como propsito para comprender completamente el problema y todo lo que ste implica. El objetivo principal del sistema es capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario.

Aprendimos que el modelo de requisitos de divide en funcionales y no funcionales lo que nos lleva a darnos cuenta cmo es que funcionara el modelo y las diferentes restricciones que se tiene.

REFERENCIAS

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88205.PDF

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88021.PDF

http://www.slideshare.net/msch/modelo-requistos

http://docencia.udea.edu.co/ingenieria/ArquitecturaSoftware/documentos/Del% 20Modelo%20Del%20Negocio%20Al%20Modelo%20De%20Requisitos.pdf

http://es.scribd.com/doc/32677971/36/Modelado-de-analisis-para-aplicacionesweb

http://www.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf