Ingeniería de Software

BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA

M.C. Luz A. Sánchez Gálvez

Contenido

IntroducciónIngeniería de RequisitosRequisitosUsuarios

2

Introducción

Ingeniería de Software: conjunto de metodologías que definen el ciclo de

vida y las diferentes actividades a realizar en el proceso de creación de un proyecto de software

3

Introducción

Análisis de Requisitos: Establecer solución, objetivos, características funcionales o no

funcionales (SRS –System Reuirements Specifications) Caso de uso (entrevistas y análisis de mercado)

Diseño Abstracción del análisis de requisitos representándolo con

modelos (UML 9 diagramas, de clase, de secuencia, etc.)

Implementación Codificar diseño con lenguajes de programación OO

Pruebas Verificar funcionamiento del sistema

Mantenimiento Actualizaciones y modificaciones

4

Es el proceso sistemático para obtener requisitos Proceso fundamental para el éxito de proyectos

de software Proceso crítico Metodologías y dispositivos apropiados son

necesarias

5

IR

73% de los proyectos de software no reúnen las expectativas requisitos equivocados

6

Usar IR

La falla e interrupción de CONFIRM (American Airlines, Budget-rent-a-car, Marriott, Hilton), sistema integrado de reservaciones de avión y hotel; y renta de autos cuyo costo fue de165 millones de dolares (1994).

Las fallas fueron relacionadas a: Errores iniciales de requerimientos. No involucrar al usuario. Incapacidad para manejar los cambios en los

requisitos.

7

Fallas

El costo de correción de requisitos incrementa, si la correción es realizada después de liberar el sistema

8

Impacto en los costos

Análisis cooperativo e iterativo del problema

Documentación de los resultados en un formato

de representación estándar

Control de la comprensión del problema que se

ha alcanzado

9

Extracción de requisitos

Realizado a través de charlas con las personas interesadas en el sistema (stakeholder)

Técnicas: Entrevistas a expertos y clientes del dominio Análisis de mercado

10

Refinamiento

Stakeholders

Stakeholders Un aspecto fundamental es identificar y considerar a

los stakeholders o partes interesadas en el proyecto, ya sean internas (personas y entidades involucradas en el proyecto) o externas (personas, grupos o entidades afectadas positiva o negativamente por sus resultados):

La gestión de Stakeholders

Gestión de Stakeholders Identificar a los stakeholders y categorizarlos Determinar sus necesidades y expectativas Incorporar las expectativas al diseño del proyecto Considerarlos en cada fase del proyecto

La gestión de Stakeholders

Stakeholders Coordinador/director del proyecto Investigadores, técnicos, gestores Colaboradores externos y colegas Instituciones participantes y servicios internos Oficina de gestión del proyecto Clientes, promotores, patrocinadores Beneficiarios, consumidores y usuarios Proveedores, competidores Colectivos y grupos sociales Grupos de presión Organismo financiador y órgano gestor Órganos normativos y reguladores

Identificación de Stakeholder Usuarios. Clientes. Expertos del dominio. Equipo de desarrollo

Realizar preguntas útiles para incrementar el entendimiento del problema.

Mejorar el análisis de información detectando conflictos e inconsistencias.

Control de la comprensión adquirida con stakeholders.

Escribir informalmente los requerimientos.14

Fases de elicitación de requisitos

Contenido

IntroducciónIngeniería de RequisitosRequisitosRequisitosUsuarios

15

Especifican qué debe hacer un sistema de

software y no cómo debe hacerlo.

Dilema el qué vs el cómo: qué para alguna personas y para otras es “cómo”.

16

Requisitos

Requerimientos Funcionales. especifican una función que el sistema debe ejecutar.

Requerimientos No-Funcionales. generalmente globales. desempeño, fiablilidad, eficiencia, portabilidad, modularidad,

escalabilidad, interoperabilidad, reusabilidad, adaptabilidad, integración, etc.

Requerimientos Inversos especifican operaciones que el sistema no debe ejecutar. están relacionados con la seguridad.

Especificaciones de Implementación/proyectos especifican la tecnología (WWW, XML, Java, etc.).

17

Tipos de requisitos

DEBE: los requisitos deben ser capaces de

proporcionar las funcionalidades del sistema.

DEBERÍA: los requisitos deberían proporcionar

un sistema mejor y más aceptable.

PODRÍA: los requisitos mejorarían el sistema y

podrían ser añadidos si lo permiten tanto el

tiempo como el trabajo.

18

Prioridades de los requisitos

Realizar un análisis de los requisitos obtenidos anteriormente para identificar ambigüedades y conflictos.

Realizar una negociación entre los diferentes stakeholders.

19

Análisis y negociación

Registrar los requisitos en un documento (SRS), que debe ser compartido entre los desarrolladores, usuarios y adminitradores.

Usar lenguajes formales o semiformales. Especificar relaciones (por ejemplo

dependencia) entre requisitos.

20

Formalización de los requisitos

Controlar los requisitos formalizados para

eliminar redundancias y ambigüedades.

Controlar la calidad de los requisitos.

Validar dependencias.

21

Validación

Contenido

IntroducciónIngeniería de RequisitosRequisitosUsuariosUsuarios

22

Los stakeholders mas importantes son los usuarios. conocen el dominio y lo que el sistema debe hacer,

tienen problemas para expresar los requisitos

no tienen todas las repuestas no tienen razones para expresar completamente los requisitos algunas dificultades pueden estar en hablar con los propietarios. a menudo no conocen la tecnología

23

Usuarios involucrados

Existen aspectos sociales y culturales.

Se esperan diferentes niveles de

involucramiento.

Diseño consultivo.

Diseño representativo.

Diseño consensuado.

24

Diseño de requisitos

Desarrolladores.

Usuarios = fuentes de información.

Herramientas.

Entrevistas.

Reuniones formales.

Elección de usuarios.

25

Diseño consultivo

Usuarios representativos están involucrados en todas las decisiones del proyecto.

Técnicas clásicas de requisitos. Diseño conjunto de la Aplicación (JAD). Calidad Funcional de Despliegue (QFD).

26

Diseño representativo

Usuarios.

El uso es una parte importante en todas las

decisiones del proyecto.

Técnicas clasicas.

Diseño participativo.

27

Diseño Consensuado

Cuando los requisitos se colectan, siempre se

deben estar actualizando.

La actualización llega a ser RFC (Request For

Change), que debe ser mostrada al comienzo de

cada iteración.

Gestión de requisitos cuida los cambios durante

el desarrollo.

28

Gestión

Analizar de manera individual en Internet 3

sistemas similares al que van a realizar. Objetivos

Ventajas

Desventajas

Clientes potenciales

Actores

Requisitos funcionales

Diseño de las Interfaces de Usuario

29

Tarea

Especificación funcional y de requisitos: En la que se describirán las funcionalidades del

sistema y los requisitos técnicos y de la interfaz de

usuario que tendrá que cumplir el producto final. Al

final de esta tarea se dispondrá de un documento de

especificación.

30

Tarea