TEMA 2 INGENIERÍA DE SOFTWARE

[pic 1][pic 2]INSTITUTO TECNOLÓGICO DE PINOTEPA 
 
 

DOCENTE: EUGENIA TERESA LOZANO AGUIRRE

ASIGNATURA: INGENIERÍA DE SOFTWARE

ALUMNA:
BETANIA SINAI HERRERA SANTIAGO  
 
TRABAJO: TAREA 3

CARRERA: INGENIERÍA EN SISTEMAS COMPUTACIONLES

SEMESTRE: 3°

SANTIAGO PINOTEPA NACIONAL, OAXACA, AGOSTO-DICIEMBRE 2022

TEMA 3. INGENIERÍA DE REQUISITOS

TAREA 3. TEMA 1

1. OBJETIVO

TEMA 3.

• Hacer un resumen
• Hacer un mapa mental o conceptual o un cuadro sinóptico de la unidad 3.
• Presenta tus requisitos funcionales y no funcionales de tu proyecto (recuerda que vas a definir un problema y en esta unidad vas a definir los diferentes requerimiento de ese sistema o software).

Que el alumno obtenga conocimientos sobre la ingeniería de requisitos y se convierte en pieza clave para poder medir la calidad de un sistema informático, garantizando que éstas satisfacen los requisitos establecidos y por lo tanto el sistema sea válido y funcionalmente correcto.

2. MARCO TEÓRICO  

5.1 INGENIERÍA DE REQUERIMIENTOS

El diseño y construcción de software de computadora es difícil, creativo y sencillamente divertido. En realidad, elaborar software es tan atractivo que muchos desarrolladores de software quieren ir directo a él antes de haber tenido el entendimiento claro de lo que se necesita. En realidad, elaborar software es tan atractivo que muchos desarrolladores de software quieren ir directo a él antes de haber tenido el entendimiento claro de lo que se necesita. Desde la perspectiva del proceso del software, la ingeniería de requerimientos es una de las acciones importantes de la ingeniería de software que comienza durante la actividad de comunicación y continúa en la de modelado. La ingeniería de requerimientos tiende un puente para el diseño y la construcción. La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación y administrar los requerimientos a medida de que se transforman en un sistema funcional. Se adaptan a las necesidades del proyecto. ¿Existe un solo evento que se convierte en el catalizador de un nuevo sistema o producto basado en computadora o la necesidad evoluciona en el tiempo? se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el sistema o producto en las operaciones cotidianas. ocurre la indagación: Los clientes o usuarios no están completamente seguros de lo que se necesita, comprenden mal las capacidades y limitaciones de su ambiente de computación, no entienden todo el dominio del problema, tienen problemas para comunicar las necesidades al ingeniero de sistemas, omiten información que creen que es “obvia”, especifican requerimientos que están en conflicto con las necesidades de otros clientes o usuarios, o solicitan requerimientos ambiguos o que no pueden someterse a prueba. Problemas de volatilidad. Los requerimientos cambian con el tiempo. La elaboración está motivada por la creación y mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del dominio del negocio visibles para el usuario final. Puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.

5.2 ESTABLECER LAS BASES

En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo. En esas condiciones, la ingeniería de requerimientos tan sólo consiste en sostener conversaciones significativas con colegas que sean miembros bien conocidos del equipo, que en la realidad esto sea muy diferente. Ninguna de estas posibilidades es deseable, pero todas son muy comunes y es frecuente verse forzado a trabajar con las restricciones impuestas por esta situación. En las secciones que siguen se estudian las etapas requeridas para establecer las bases que permiten entender los requerimientos de software a fin de que el proyecto comience en forma tal que se mantenga avanzando hacia una solución exitosa.

5.2.1  IDENTIFICACIÓN DE LOS PARTICIPANTES

Sommerville y Sawyer definen participante como “cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo”. Ya se identificaron los candidatos habituales: Gerentes de operaciones del negocio, gerentes de producto, personal de mercadotecnia. Internos y externos, usuarios finales, consultores, ingenieros de producto. Ingenieros de apoyo y mantenimiento, entre otros. Cada participante tiene un punto vista diferente respecto del sistema, obtiene distintos beneficios cuando éste se desarrolla. Éxito y corre distintos riesgos si fracasa el esfuerzo de construcción.

5.2.2  RECONOCER LOS MÚLTIPLES PUNTOS DE VISTA

Debido a que existen muchos participantes distintos, los requerimientos del sistema se explorarán.

Por ejemplo, el grupo de mercadotecnia se interesa en funciones y características que estimularán el mercado potencial, lo que hará que el nuevo sistema sea fácil de vender. Los ingenieros de software quizá piensen en funciones invisibles para los participantes sin formación técnica, pero que permitan una infraestructura que dé apoyo a funciones y características más vendibles.

A medida que se recaba información procedente de múltiples puntos de vista, los requerimientos que surjan tal vez sean inconsistentes o estén en conflicto uno con otro. Debe clasificarse toda la información de los participantes (incluso los requerimientos inconsistentes y conflictivos) en forma que permita a quienes toman las decisiones escoger para el sistema un conjunto de requerimientos que tenga coherencia interna.

5.2.3  TRABAJAR HACIA LA COLABORACIÓN

En los primeros capítulos se mencionó que, para obtener un sistema exitoso, los clientes (y otros participantes) debían colaborar entre sí (sin pelear por insignificancias) y con los profesionales de la ingeniería de software.

El trabajo del ingeniero de requerimientos es identificar las áreas de interés común (por ejemplo, requerimientos en los que todos los participantes estén de acuerdo) y las de conflicto o incongruencia (por ejemplo, requerimientos que desea un participante, pero que están en conflicto con las necesidades de otro).

5.2.4  HACER LAS PRIMERAS PREGUNTAS

Las preguntas que se hacen en la concepción del proyecto deben estar “libres del contexto”. El primer conjunto de ellas se centran en el cliente y en otros participantes, en las metas y beneficios generales. Por ejemplo, tal vez se pregunte:

• ¿Quién está detrás de la solicitud de este trabajo?
• ¿Quién usará la solución?
• ¿Cuál será el beneficio económico de una solución exitosa?
• ¿Hay otro origen para la solución que se necesita?

Estas preguntas ayudan a identificar a todos los participantes con interés en el software que se va a elaborar. Además, las preguntas identifican el beneficio mensurable de una implementación exitosa y las posibles alternativas para el desarrollo de software personalizado.

Las preguntas siguientes permiten entender mejor el problema y hacen que el cliente exprese  sus percepciones respecto de la solución:

• ¿Cuál sería una “buena” salida generada por una solución exitosa?
• ¿Qué problemas resolvería esta solución?
• ¿Puede mostrar (o describir) el ambiente de negocios en el que se usaría la solución?
• ¿Hay aspectos especiales del desempeño o restricciones que afecten el modo en el que se enfoque la solución?

Las preguntas finales se centran en la eficacia de la actividad de comunicación en sí. Gause y Weinberg las llaman “metapreguntas” y proponen la siguiente lista (abreviada):

• ¿Es usted la persona indicada para responder estas preguntas? ¿Sus respuestas son “oficiales”?
• ¿Mis preguntas son relevantes para el problema que se tiene?
• ¿Estoy haciendo demasiadas preguntas?
• ¿Puede otra persona dar información adicional?
• ¿Debería yo preguntarle algo más?

Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la comunicación, que es esencial para una indagación exitosa. Pero una reunión de preguntas y respuestas no es un enfoque que haya tenido un éxito apabullante. En realidad, la sesión de preguntas y respuestas sólo debe  usarse para el primer encuentro y luego ser reemplazada por un formato de indagación de requerimientos que combine elementos de solución de problemas, negociación y especificación.

5.3 INDAGACIÓN DE LOS REQUERIMIENTOS

...