RESUMEN CAPITULO 7 (Pressman) 1

RESUMEN CAPITULO 7
MATERIA: Ingeniería de software
DOCENTE: Lic. Roxana Laurel Rodríguez
ESTUDIANTES:
 Omar Rodrigo Choque Conde
 Gregori Dawillmar Mamani Mendoza
 Selene Villarpando Vásquez
 Iver Josué Coquendo Mendoza
FECHA DE ENTREGA: 25/09/2021

INGENIERIA DE REQUISITOS.
La ingeniería de requisitos surge por la capacidad de resolver los problemas y necesidades que
tienen los clientes, ya que estos pueden ir cambian en el transcurso del desarrollo del proyecto
o después de ser elaborado. El ingeniero de software debe de adaptarse a los cambios.
7.1. Un puente del diseño hacia la construcción.
El diseño y construcción del software suele evaluarse en el transcurrí dl desarrollo, pero lo
idóneo es hacer un análisis para luego desarrollarlo, teniendo de esta manera una base solida.
La ingeniería de requisitos en el proceso d software comienza en la actividad de comunicación
y continua en la actividad de desarrollo.
Se debe entender los requisitos antes de resolver el problema.
El puente entre el diseño y la construcción esta entre los requisitos, necesidades, escenarios,
características y funciones que puede haber en el software.
7.2. Tareas de la ingeniería de requisitos.
La ingeniería de requisitos proporciona un mecanismo de negociación razonable, análisis de
factibilidad, evaluación de factibilidad y especificaciones. El proceso d la ingeniería de
métodos consta de 7 el cual pueden ser paralelos o adaptarse las necesidades.
7.2.1. Inicio.
Se hace una conversación informal donde se detallan todas las necesidades y especificación
que se quiere.
Se hace la comprensión del problema para tener a naturaleza de la solución.
7.2.2. Obtención.
Par obtener información Christel y Kang identifica una serie de problemas:
- Problemas de ámbito.
Los limites de sistemas están mal definidos, se tiene información innecesaria y confunde.
- Problemas de comprensión. Los usuarios no están seguro de cuales son sus necesidades,
dudas de la capacidades y limites del sistema.
- Problemas de volatilidad. Los problemas cambian en el transcurso del desarrollo.
7.2.3. Elaboración.
Se concentra en el modelado, creación y refinamiento de los escenarios, funciones,
características.
Identificar los atributos de cada clase de análisis y la identificación de servicios.
El resultado final será el dominio de la información, las funciones y el comportamiento del
problema.
7.2.4. Negociación.
Es conciliar conflictos que podría suceder por algunos requisitos, o señalar los costos de
proyecto y tiempo de entrega, hacer estimaciones del proceso.
7.2.5. Especificación.
Es poder establecer un documento escrito el cual especifique las funcionalidades. Sino
plantillas estándar. En caso de ser programas pequeños solo plantear escenarios. Describe la
funcionalidad y desempeño.
7.2.6. Validación.
Examina la especificación de cada requisito, para corregir errores y demás, donde pueda estar
estandarizado. Es una revisión técnica formal.
7.2.7. Gestión de requisitos.
Es un conjunto de actividades que ayudan al proyecto a identificar
, controlar y rastrear requisitos y cambios que pudiesen hacerse.
Se inicia con la identificación para luego haber la tabla de rastreabilidad que pueden ser:
- Tabla de rastreabilidad de características.
- Tabla de rastreabilidad de la fuente.
- Tabla de rastreabilidad de dependencia.
- Tabla de rastreabilidad de subsistema.
- Tabla de rastreabilidad de interfaz.
7.3. Inicio del proceso de la ingeniería de requisitos.
Para dar inicio al proceso de ingeniera de requisitos se segura los siguientes pasos que
mantendrán un movimiento hacia una solución exitosa.
- Identificación de los interesados.
Son todos aquellos que se benefician del sistema tanto directa como indirectamente, ya que
cada uno tendrá una visión diferente del sistema, para ello es necesario hace una lista de
personas que contribuirán.
- Reconocimiento de diferentes puntos de vista.
Es categorizar la información de los interesados para que los que tomen decisiones tengan un
conjunto d requisitos que sean consistentes para l sistema.
- Trabajo con respecto a la colaboración.
Es identificar áreas en común con los diferentes interesados, teniendo visión de ellos, el cual el
gerente tomara la decisión final
- Formulación de las preguntas.
Son preguntas libres de contexto. El primer conjunto de preguntas se enfoca en los clientes e
interesados, metas genérale y beneficios. Se identifica que tan medible es.
7.3.1 IDENTIFICAR LOS EVENTOS CON EL CASO DE USO
Un caso de uso se estudia para efectos del intercambio de información.

Un ejemplo sería que de un evento común considere la frase subrayada en el caso del propietario para
escribir una contraseña de cuatro dígitos, tal vez el modelo se llame propietario de casa que transmite
un evento al objetivo, esa información que se transfiere es de la contraseña. Una vez identificados
todos los eventos se asignan los objetos involucrados.
7.3.2 REPRESENTACIONES DE ESTADO
Deben considerarse dos características diferentes a los estados:

1) estado de cada clase cuando el sistema ejecuta su función.
2) el estado del sistema según se observa desde el exterior realiza su función.
El estado de una clase tiene características pasivas y activas.
El estado pasivo es el estado actual de todos los atributos de un objeto.
El estado activo indica el estado actual del objeto conforme pasa por una transformación o
procesamientos continuos.
Diagrama de estado para clases de análisis.- es un componente de modelo de comportamiento es un
diagrama de estado UML que esto representa estados activos para cada clase y los eventos que
causan cambios en dichos estados activos. Aparte de especificar el evento que hace que hace que la
transición ocurra, puede especificarse una guardia y una acción. Guardia es una condición booleana
que debe satisfacerse para que tenga lugar una transición.
Diagrama de secuencia.- es el segundo tipo de representación del comportamiento, llamado diagrama
de secuencia en UML, este indica la forma en la que los eventos provocan transiciones de un objeto a
otro, una vez que estén identificados estos objetos por medios de análisis del caso de uso el
modelador crea un diagrama de secuencia representando del modo en el que los eventos causan el
flujo de uno a otro como función del tiempo.
El primer evento es el sistema listo, que se deriva del ambiente externo y canaliza el comportamiento
al objeto propietario, el propietario introduce una contraseña.
Otro evento es sistema de observación pasa al SISTEMA, que este observa la contraseña en una base
de datos sencilla y devuelve un resultado a Panel de Control
7.4 PATRONES PARA EL MODELADO DE REQUERIMIENTOS
Estos patrones de software son un mecanismo para capturar conocimiento del dominio, en una forma
que permita que devuelva a aplicarse cuando se encuentre un problema nuevo, el autor original de un
patrón de análisis no crea el patrón, sino que lo descubre a medida que se realiza el trabajo de
ingeniería de requerimiento, una vez que haya descubierto el patrón se documenta describiendo.
7.4.1 Descubrimiento de patrones de análisis
El modelo de requerimiento está formado por una amplia variedad de elementos basados en el
escenario, orientados a datos, basado en clases, orientados al flujo y del comportamiento.
El elemento más fundamental en la descripción de un modo de requerimientos es el caso de uso, es

un conjunto coherente de casos de uso que sirve como base para descubrir uno o más patrones de
análisis.
7.4.2 Ejemplo de patrón de requerimientos: Actuador-Sensor
Uno de los requerimientos de la función de seguridad es la capacidad de vigilar sensores de

seguridad, las extensiones basadas en Internet requerirán la capacidad de controlar el movimiento.
El patrón Actuador-Sensor da una guía útil para modelar este requerimiento dentro del software.
Restricciones
• Cada sensor pasivo debe tener algún método para leer la entrada de un sensor y los
atributos que representan al valor del sensor.
• Cada sensor activo debe tener capacidades para emitir mensajes actualizados cuando su valor
cambie.
• Cada sensor activo debe enviar un latido de vida, mensaje de estado que se emite cada
cierto tiempo para detectar fallas.
• Cada actuador debe tener un método para invocar la respuesta apropiada determinada
por el Cálculo de Componente.
• Cada sensor y actuador deben tener una función implementada para revisar su propio estado de
operación.
• Cada sensor y actuador debe ser capaz de someter a prueba la validez de los valores
recibidos o enviados y fijar su estado de operación si los valores se encuentran fuera de
las especificaciones.
Aplicabilidad. Es útil en cualquier sistema en el que haya varios sensores y actuadores.

Participantes. Esta sección de la descripción de patrones “clasifica las clases u objetos incluidos en el
patrón de requerimientos” y describe las responsabilidades de
• Actuador Complejo: Los actuadores complejos también tienen la funcionalidad básica de la clase
abstracta Actuador, pero se requiere especificar métodos y atributos adicionales más elaborados.
Colaboraciones. -Esta sección describe cómo interactúan los objetos y clases entre sí, y cómo
efectúa cada uno sus responsabilidades.
Consecuencias
1. Las clases sensor y actuador tienen una interfaz común.
2. Sólo puede accederse a los atributos de clase a través de mensajes y la clase decide si se aceptan o
no.
Por ejemplo, si se establece el valor de un actuador por arriba del máximo, entonces la clase actuador
tal vez no acepte el mensaje, o quizá emplee un
valor máximo preestablecido.
3. La complejidad del sistema es potencialmente reducida debido a la uniformidad de las interfaces

para los actuadores y sensores.
La descripción del patrón de requerimientos también da referencias acerca de otros requerimientos y

patrones de diseño relacionados.

RESUMEN CAPITULO 7 (Pressman) 1

Cargado por

Copyright:

Formatos disponibles

RESUMEN CAPITULO 7 (Pressman) 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

RESUMEN CAPITULO 7 (Pressman) 1

Cargado por

Copyright:

Formatos disponibles

RESUMEN CAPITULO 7

MATERIA: Ingeniería de software

DOCENTE: Lic. Roxana Laurel Rodríguez

FECHA DE ENTREGA: 25/09/2021

Un caso de uso se estudia para efectos del intercambio de información.

Deben considerarse dos características diferentes a los estados:

El elemento más fundamental en la descripción de un modo de requerimientos es el caso de uso, es

7.4.2 Ejemplo de patrón de requerimientos: Actuador-Sensor

Uno de los requerimientos de la función de seguridad es la capacidad de vigilar sensores de

Aplicabilidad. Es útil en cualquier sistema en el que haya varios sensores y actuadores.

3. La complejidad del sistema es potencialmente reducida debido a la uniformidad de las interfaces

La descripción del patrón de requerimientos también da referencias acerca de otros requerimientos y

También podría gustarte