Modelado de requisitos

  • 4,799 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,799
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
153
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. INSTITUTO TECNOLÓGICO DE TUXTEPEC ING. EN SISTEMAS COMPUTACIONALES “FUNDAMENTOS DE INGENIERÍA DEL SOFTWARE”UNIDAD II: INGENIERÍA DE REQUISITOS ACTIVIDAD“INVESTIGACIÓN 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
  • 2. CONTENIDOEn este trabajo se presenta un enfoque de Ingeniería de Requisitos para elmodelado conceptual de sistemas de información. Su principal objetivo esproporcionar un conjunto de técnicas y guías para capturar los requisitos delsoftware, analizarlos y expresarlos en un esquema conceptual de OO-Methodgarantizando la trazabilidad entre éstos. El enfoque se basa en un marcoreferencial de herramientas de especificación de requisitos (TRADE) y unmétodo gráfico orientado a objetos para el modelado conceptual concapacidades de generación automática de código (OO-Method). Se define laestructura y técnicas para la construcción de un Modelo de Requisitosfuncionales del sistema y a partir de este modelo, un Proceso de Análisis deRequisitos (PAR) define constructores que permiten representar dichosrequisitos en elementos del Modelo Conceptual de OO-Method. Utilizando esteproceso cada elemento del Modelo de Requisitos tiene una representaciónperfectamente identificable en el Modelo Conceptual OO-Method y cadaelemento del Modelo Conceptual tiene su origen en el Modelo de Requisitos.
  • 3. INTRODUCCIÓNEn este tema nos damos cuenta que a menudo los diseñadores de sistemascometen el error de comenzar a diseñar e implementar soluciones que no hansido completamente especificadas y que corresponden a problemas a los queles falta delimitación, lo cual conduce a la construcción de sistemas que nosatisfacen las necesidades de los clientes y que incurren en el aumento de loscostos y en el incumplimiento de los plazos establecidos.Más aún, generalmente estos métodos carecen de directrices adecuadas parael desarrollo de modelos conceptuales derivados de las especificaciones yposteriormente de código que sea funcionalmente equivalente a dichosmodelos conceptuales.Como un esfuerzo para la superación de estas limitaciones, en este trabajo sepresenta un enfoque sistemático de Ingeniería de Requisitos que define unproceso que posibilita la descomposición sistemática y repetitiva de losrequisitos de software hasta obtener una detallada especificación queconstituirá el modelo conceptual del sistema deseado. Este enfoque pretendemejorar la calidad del proceso de producción de software:  Proporcionando predecibilidad mediante la construcción de un modelo conceptual como una precisa, estructurada y bien definida representación de los requisitos de los usuarios.  Aumentando la productividad al establecer vínculos precisos entre el modelo conceptual y los requisitos de los usuarios. Esto facilitará la incorporación en el modelo conceptual de cambios en los requisitos. En consecuencia, tales modificaciones quedarán reflejadas también en el sistema de software desarrollado.
  • 4. DESARROLLOEl modelado de requisitos nos sirve y tiene como propósito comprendercompletamente el problema y todo lo que éste implica y conlleva. Su objetivoprincipal es delimitar el sistema y capturar la funcionalidad que debe ofrecerdesde la perspectiva del usuario.Además el modelo de requisitos captura las principales características delsistema de software que se desea construir. Por medio de él representamos losrequisitos del sistema de forma sencilla, para que de esta manera cualquierusuario pueda revisarlo y además entenderlo, sin necesidad de tenerconocimientos previos al modelo e información. Intervienen en el los modelosde caso de uso, que desempeñan un papel importante de gran relevancia.En el estudio del modelo de requisitos se encuentran los funcionales y nofuncionales.Cabe mencionar que los requisitos determinan lo que hará el sistema, es decir,como funcionará además, las restricciones sobre su operación eimplementación. La elicitación, análisis y especificación de requisitos es elproceso del estudio de las necesidades de los usuarios para llegar a unadefinición de los requisitos del sistema.Un requisito es una condición o capacidad que necesita el usuario pararesolver un problema o conseguir un objetivo determinado. Puede verse comouna declaración abstracta de alto nivel de un servicio que el sistema debeproporcionar.Los requisitos funcionales: son la característica requerida del sistema queexpresa una capacidad de acción del mismo, una funcionalidad; generalmenteexpresada en una declaración en forma verbal. No todo lo que necesitaremosen nuestro sistema es funcionalidad pura; por el contrario a veces se necesitanotras cualidades, si se quieren generalidades, que no son objeto decodificación si bien es cierto que pueden llegar a afectar a esta. Pueden serfrases muy generales sobre lo que el sistema debería hacer. Se suelenexpresar como objetivos del sistema. Deben describir los servicios que hay queproporcionar con todo detalle (casos de uso).Requisitos no funcionales: característica requerida del sistema, del procesode desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo,que señala una restricción del mismo. Son todas las exigencias de cualidadesque se imponen al proyecto: exigencias de usar un cierto lenguaje deprogramación o plataforma tecnológica, por ejemplo, Un requisito no funcional
  • 5. es una característica ya sea del sistema, del proyecto o del servicio de soporte,que nos es requerida junto con la especificación del sistema pero que como yadije, no se satisface añadiendo código, sino cumpliendo con esta como si deuna restricción se tratara.Los requisitos no funcionales pueden clasificarse en:Requisitos del producto: especifican el comportamiento del productoobtenido.Requisitos organizacionales: son una consecuencia de las políticas yprocedimientos existentes en la organización.Requisitos externos: presentan factores externos al sistema y a su procesode desarrollo.Además, existen los requisitos de usuarios, que nos dice que el sistema debepermitir representar y acceder a archivos externos creados por otrasherramientas. Los requisitos del sistema asociado nos dice que el usuariodeberá 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 funcionalessuelen ser muy difíciles de expresar con exactitud, ya que los requisitosimprecisos pueden ser difíciles de verificar, como por ejemplo: un deseogeneral 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 conexactitud, por ejemplo, los requisitos expresados de forma ambigua se puedeninterpretar de manera diferente por los desarrolladores y por los usuarios.Por tal motivo se busca como objetivo que la especificación debe ser completay consistente, completa en el sentido de que todos los servicios solicitados porel usuario estén definidos. Y consistente en que los requisitos no tengandefiniciones contradictorias.El proceso de análisis de requisitos, considera los aspectos relativos al análisisde las funcionalidades y la traducción al modelo conceptual.Existen tres técnicas que nos permiten generar el modelo de requisitos:  Misión del sistema: describe cual es el propósito del sistema, sus responsabilidades y el alcance que tendrá. A través de él podemos determinar, en términos generales, que hará y que no hará el sistema. Aunque es una técnica sencilla es de vital importancia para el desarrollo del sistema.
  • 6.  Árbol de refinamiento de funciones: descompone el sistema en interacciones externas, de acuerdo a algún criterio preestablecido. Cabe mencionar que las interacciones externas son organizadas en funciones que forman una jerarquía a manera de árbol, en cuyo nivel más alto (raíz) se ubica la misión del sistema. Esta Misión del Sistema es refinada hasta obtener otras funciones elementales representadas en la jerarquía a través de los nodos hoja. Este proceso descendente de refinamiento funcional puede generar distintos niveles de nodos. Aquellos que están entre la raíz 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 raíz del árbol, representa toda la funcionalidad relativa a un área o actividad de la organización, según el criterio de descomposición utilizado. Modelo de casos de uso: El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso. De esta forma, la especificación 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 especificación 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 satisfacción de los requisitos.Describe un sistema en término de sus distintas formas de utilización, cadauna de esas formas es conocida como un caso de uso. Cada caso de uso oflujo se compone de una secuencia de eventos iniciada por el usuario.Los actores son entidades distintas a los usuarios, representan un ciertopapel que una persona real puede jugar. Modelan cualquier entidad externaque necesite intercambiar información con el sistema. No están restringidosa ser personas físicas, pudiendo representar otros sistemas externos alactual. Lo esencial es que representen entidades externas al sistema. Cadauno de los actores podrá ejecutar una o más tareas del sistema.El flujo de eventos que se desarrolla entre el actor y el sistema para el logrodel objetivo del caso de uso es narrado en la especificación, a manera deconversación, a través de una secuencia numerada de pasos. Esta
  • 7. clasificación separa las acciones del actor de las ejecutadas por el sistemay las distingue de aquellas relativas al contexto donde se desarrolla el casode uso.A medida que se alcanza un mayor conocimiento del dominio, este textocrece en tamaño y detalle adquiriendo formas complejas que limitan sucomprensión y posterior uso en las distintas etapas de la construcción delsistema. Con el propósito de minimizar el impacto de estos problemas, ladescripción de los casos de uso es estructurada precisándose su nivel dedetalle en términos de las necesidades del modelado y del momento dedesarrollo del sistema.El nivel de abstracción de un caso de uso está vinculado al contenidoinformativo relevante o significativo que se desea expresar en el caso deuso.El propósito principal de este proceso es identificar las responsabilidadesmás significativas del sistema en desarrollo. Las responsabilidadesconllevan a la definición de operaciones, esto es, a la especificación de losservicios de una clase.Con el propósito de describir las responsabilidades detectadas en elcontexto de un Caso de Uso se utilizan Diagramas de Secuencia connotación UML. En estos diagramas se representan las responsabilidades,identificando el objeto que la invoca (objeto cliente) y el objeto al que éstapertenece (objeto servidor).Para mostrar las decisiones sobre asignación de responsabilidades entrelos objetos, el Proceso de Análisis de Requisitos prevé la especificación deDiagramas de Secuencia pero a muy alto nivel y como herramienta pararepresentar estas responsabilidades.Un escenario es una secuencia específica de las acciones que describe uncaso de uso. Así, un caso de uso puede ser considerado como lacompilación de múltiples escenarios algunos de los cuales, los primarios,describen su trayectoria normal mientras que otros, los secundarios, serefieren a sus trayectorias alternas.Los diagramas de secuencia permiten describir patrones de interacciónentre objetos o clases. A través de estos diagramas se muestra lasecuencia ordenada en el tiempo de los mensajes que envían y recibengenéricamente los objetos durante la ejecución de un escenario. Unestímulo es una comunicación entre dos objetos que se transmiteninformación con la finalidad de que se ejecute una actividad. Un mensajeespecifica los roles que deben cumplir tanto el objeto emisor (el cliente)como el objeto receptor del estímulo (el servidor) así como la acción que
  • 8. será ejecutada. De esta forma, a través de los mensajes se expresan las responsabilidades que cumplirán los objetos en el sistema. En el Proceso de Análisis de Requisitos, es posible utilizar dos tipos de diagramas de secuencia, que va a depender del momento y estrategia de desarrollo seguida así como también del nivel de detalle deseado. 1) OO-Method: hace énfasis en la interacción, en términos 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 especificación de Casos de Uso con sus pasos se obtiene automáticamente donde cada paso se convierte en un auto-mensaje). 2) La evolución 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 también las clases de objetos clientes y servidores. El Proceso de Análisis de Requisitos consiste, básicamente, en la construcciónde los diagramas de secuencia OO-Method a partir del Modelo de Requisitosdel sistema.Los diagramas de secuencia, además de expresar en detalle los resultados delProceso de Análisis de Requisitos, constituyen un recurso de muchaimportancia para la construcción del Modelo de Objetos. Con esta finalidad, seha incorporado en estos diagramas cierta información que resulta de interéspara identificar elementos de este modelo. Esta información se expresaestereotipando los mensajes del diagrama de secuencia con el propósito dedistinguirlos según la clasificación.El modelo de trazabilidad es utilizado para relacionar los distintos elementosdel Enfoque de Ingeniería de Requisitos con los elementos del ModeloConceptual, se caracteriza por ser estructural y estar basado en referenciascruzadas. Esto significa, que la relación establecida entre estos elementos esestructural. En segundo lugar, se establecen explícitamente referencias entrelos elementos a diferentes niveles de abstracción.Por otra parte, la trazabilidad en el enfoque de Ingeniería de Requisitos puedeser estudiada desde dos perspectivas:
  • 9.  Internamente.- la trazabilidad es establecida entre los elementos de las distintas técnicas del Modelo de Requisitos y entre éstos y los que pertenecen al Proceso de Análisis de Requisitos.  Externamente, la trazabilidad queda determinada por los vínculos establecidos entre los elementos de dicho proceso y los constructores del Modelo Conceptual.Encontramos dentro de éste proceso la validación y gestión de requisitos, queconsiste en demostrar que los requisitos definen el sistema que los clientesdesean. Y por lo tanto los costes de los errores en los requisitos son muy altospor lo que la validación funge como un factor muy importante en dicho proceso.La gestión de los requisitos es el proceso de manejar los requisitos quecambian durante el desarrollo del sistema. Los requisitos pueden serinevitablemente inconsistentes e incompletos.Dentro de las aplicaciones del modelado de requisitos encontramos: losprocesos de negocio de la organización se identifican partiendo de sus propiosobjetivos, y se describen mediante flujos de actividades que se representanmediante diagramas de actividades UML. De este modo, los casos de uso delsistema se obtienen a partir de las actividades de los procesos del negocio, seorganizan jerárquicamente y se facilita su desarrollo iterativo e incremental.Las clases del modelo conceptual se obtienen a partir de los objetos deinformación que fluyen entre las actividades. A la vez que se realiza elmodelado del negocio y de los requisitos, las reglas del negocio de laorganización se recogen en un glosario, en forma de especificación de lasactividades y de los casos de uso asociados, así como de los objetos deinformación y de las clases que los implementan. Esto permite mantener lascorrespondientes relaciones de trazabilidad entre los diferentes artefactos delmodelado.Además, el hecho de que los requisitos surjan de la descripción de losprocesos del negocio, y que éstos sean el resultado del análisis de los objetivosde la organización, posibilita que los requisitos del sistema sean validados yverificados contra los objetivos del negocio.Además también encontramos su utilización en aplicaciones web. Los sitiosWeb, por lo general, son complejos y enormemente dinámicos. Requierenfases de desarrollo cortas con la finalidad de tener listo el producto y ejecutarlorápidamente. Con frecuencia, los desarrolladores van directo hacia la fase decodificación sin comprender que están tratando de construir o como quierenconstruirlo. La codificación respecto del servidor con frecuencia se hace adhoc, las tablas de bases de datos se agregan conforme se necesitan y laarquitectura evoluciona en una forma a veces no intencional.
  • 10. El análisis de requisitos para las WebApps abarca tres grandes tareas:Formulación, recopilación de requisitos, y modelado de análisis. Durante laformulación se identifica la motivación (metas) y los objetivos básicos para laWebApp, y también se define las categorías de usuario. Los requisitos decontenido y funcionales se enlistan y se desarrollan los escenarios deinteracción (casos de uso) descritos desde el punto de vista del usuario final.La jerarquía de usuario.Las categorías de usuario finales que interactuarán con la WebApp seidentifican como parte de las tareas de formulación y de recopilación derequisitos.En la mayoría de los casos las categorías de usuario son relativamentelimitadas y no necesitan de representación UML.Desarrollo de casos de usoLos casos de uso se desarrollan par cada categoría de usuario descrita en lajerarquía de usuario. En el contexto de ingeniería Web, el caso de uso en símismo es relativamente informal: un párrafo narrativo que describe unainteracción específica entre un usuario y la WebApp.
  • 11. CONCLUSIÓNRecordemos que el objetivo de la ingeniería del software es el desarrollo desistemas apegados a las necesidades del cliente, pero también ajustados aotros criterios, como el modelo de negocio, los recursos disponibles y el tiempode entrega. Es obvio espero, que la ingeniería del software no solo ha decumplir con la funcionalidad (escribir código ajustado a los requisitosfuncionales) sino también con las cualidad suplementarias (requisitos nofuncionales) o de lo contrario no cumplirá con su misión: desarrollar el softwareque se necesita en el momento y condiciones que se tienen disponibles; odicho de otra manera, desarrollar software de calidad.También nos damos cuenta que el modelado de requisitos nos sirve comopropósito para comprender completamente el problema y todo lo que ésteimplica. El objetivo principal del sistema es capturar la funcionalidad que debeofrecer desde la perspectiva del usuario.Aprendimos que el modelo de requisitos de divide en funcionales y nofuncionales lo que nos lleva a darnos cuenta cómo es que funcionara el modeloy las diferentes restricciones que se tiene.
  • 12. REFERENCIAShttp://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88205.PDFhttp://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88021.PDFhttp://www.slideshare.net/msch/modelo-requistoshttp://docencia.udea.edu.co/ingenieria/ArquitecturaSoftware/documentos/Del%20Modelo%20Del%20Negocio%20Al%20Modelo%20De%20Requisitos.pdfhttp://es.scribd.com/doc/32677971/36/Modelado-de-analisis-para-aplicaciones-webhttp://www.infor.uva.es/~mlaguna/is1/apuntes/2-requisitos.pdf