• Author / Uploaded
• jake muller

Citation preview

INGENIERÍA DE SOFTWARE

U1 Especificación de requisitos

BRENDA ESCAMILLA DOMINGUEZ

INGENIERÍA DE REQUERIMIENTOS

INGENIERÍA DE REQUERIMIENTOS

El proceso de adquisición y análisis de requerimientos 1. Descubrimiento de requerimientos Éste es el proceso de interactuar con los participantes del sistema para descubrir sus requerimientos, existen numerosas técnicas complementarias que pueden usarse para el descubrimiento de requerimientos. 2. Clasificación y organización de requerimientos Esta actividad toma la compilación no estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en grupos coherentes. La forma más común de agrupar requerimientos es usar un modelo de la arquitectura del sistema. 3. Priorización y negociación de requerimientos Esta actividad se preocupa por priorizar los requerimientos, así como por encontrar y resolver conflictos de requerimientos mediante la negociación. 4. Especificación de requerimientos Los requerimientos se documentan e ingresan en la siguiente ronda de la espiral. Pueden producirse documentos de requerimientos formales o informales.

1. Descubrimiento de requerimientos

ENTREVISTAS formales o informales con participantes del sistema son una parte de la mayoría de los procesos de ingeniería de requerimientos. Los requerimientos se derivan de las respuestas a dichas preguntas. Las entrevistas son de dos tipos: 1. Entrevistas cerradas: donde los participantes responden a un conjunto de preguntas preestablecidas. 2. Entrevistas abiertas: se explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades.

ESCENARIOS son particularmente útiles para detallar un bosquejo de descripción de requerimientos. Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos de información con diversos niveles de detalle acerca del sistema.

CASOS DE USO Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo por primera vez en el método Objectory (Jacobson et al., 1993). Ahora se ha convertido en una característica fundamental del modelado de lenguaje unificado. En su forma más sencilla, un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de interacción. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado.

CASOS DE USO En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas.  La historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una descripción basada en un formato o una representación diagramática.  Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del usuario final. El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán involucrados en la historia.

 Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el contexto de la función y comportamiento que va a describirse. Los actores representan los papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una definición más formal, un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el sistema. Es importante notar que un actor y un usuario final no necesariamente son lo mismo. Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que un actor representa una clase de entidades externas (gente, con frecuencia pero no siempre) que sólo tiene un papel en el contexto del caso de uso.

CASOS DE USO



El modelado de casos de uso fue desarrollado originalmente por Jacobson y sus colaboradores en la década de 1990, y se incorporó en el primer lanzamiento del UML.



El modelado de casos de uso se utiliza ampliamente para apoyar la adquisición de requerimientos. Un caso de uso puede tomarse como un simple escenario que describa lo que espera el usuario de un sistema.



Cada caso de uso representa una tarea discreta que implica interacción externa con un sistema. En su forma más simple, un caso de uso se muestra como una elipse, con los actores que intervienen en el caso de uso representados como figuras humanas.

CASOS DE USO Una vez identificados los actores, es posible desarrollar casos de uso. Jacobson sugiere varias preguntas que debe responder un caso de uso: •¿Quién es el actor principal y quién(es) el(los) secundario(s)? •¿Cuáles son los objetivos de los actores? •¿Qué precondiciones deben existir antes de comenzar la historia? •¿Qué tareas o funciones principales son realizadas por el actor? •¿Qué excepciones deben considerarse al describir la historia? •¿Cuáles variaciones son posibles en la interacción del actor? •¿Qué información del sistema adquiere, produce o cambia el actor? •¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo? •¿Qué información desea obtener el actor del sistema? •¿Quiere el actor ser informado sobre cambios inesperados?

2. Clasificación de requerimientos

REQUERIMIENTOS FUNCIONALES  Los requerimientos funcionales para un sistema refieren lo que el sistema debe hacer.  Tales requerimientos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización.  Los requerimientos funcionales del sistema varían desde requerimientos generales que cubren lo que tiene que hacer el sistema, hasta requerimientos muy específicos que reflejan maneras locales de trabajar o los sistemas existentes de una organización.

2. Clasificación de requerimientos

REQUERIMIENTOS NO FUNCIONALES Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden definir restricciones sobre la implementación del sistema.

3. Priorización de requerimientos

El proyecto de desarrollo de software al igual que cualquier otro proyecto tiene múltiples técnicas de priorización de requerimientos, restricciones presupuestarias y plazos ajustados. Por lo tanto, existe la necesidad de priorizar los requisitos de software ya que es imposible hacer todo a la vez, se deben tomar decisiones sobre qué conjunto de requisitos se deben implementar primero y cuáles se pueden retrasar hasta una versión posterior.

4. Especificación de requerimientos

USUARIOS DE UN DOCUMENTO DE REQUERIMIENTOS

Validación de requerimientos Se verifica que los requerimientos definan realmente el sistema que en verdad quiere el cliente. Se traslapa con el análisis, ya que se interesa por encontrar problemas con los requerimientos. La validación de requerimientos es importante porque los errores en un documento de requerimientos pueden conducir a grandes costos por tener que rehacer, cuando dichos problemas se descubren durante el desarrollo del sistema o después de que éste se halla en servicio.

Administración de requerimientos Los requerimientos para los grandes sistemas de software siempre cambian. Una razón es que dichos sistemas se desarrollaron por lo general para resolver problemas “horrorosos”: aquellos problemas que no se pueden definir por completo. Como el problema no se logra definir por completo, los requerimientos del software están condenados también a estar incompletos. Durante el proceso de software, la comprensión que los participantes tienen de los problemas cambia constantemente (figura 4.17). Entonces, los requerimientos del sistema también deben evolucionar para reflejar esa visión cambiante del problema.

Administración del cambio de requerimientos

DIAGRAMAS UML El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos.

DIAGRAMAS UML La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo.

Recordemos que un modelo es una representación simplificada de la realidad; el modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.

DIAGRAMAS UML

        

A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Estados Diagrama de Secuencias Diagrama de Actividades Diagrama de Colaboraciones Diagrama de Componentes Diagrama de Distribución

http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf

ESTUDIO DE FACTIBILIDAD

El estudio de factibilidad es un instrumento que sirve para orientar la toma de decisiones en la evaluación de un proyecto

ANÁLISIS COSTO-BENEFICIO La técnica de análisis costo/beneficio tiene como objetivo fundamental proporcionar una medida de los costos en que se incurre en la realización de un proyecto y comparar dichos costos previstos con los beneficios esperados de la realización de dicho proyecto. Esta medida o estimación servirá para: • Valorar la necesidad y oportunidad de acometer la realización del proyecto. • Seleccionar la alternativa más beneficiosa para la realización del proyecto. • Estimar adecuadamente los recursos económicos necesarios en el plazo de realización del proyecto.

Cabe destacar la necesidad cada vez mayor de guiarse por criterios económicos y no sólo técnicos para la planificación de trabajos y proyectos. Por ello se recomienda el uso de las técnicas y métodos de evaluación de conceptos económicos, con el fin de proporcionar a los profesionales criterios que les ayuden en la planificación de proyectos y evaluación de alternativas.