INGENIERÍA DEL

SOFTWAREUnidad 1: Requerimientos del Software.

Trimestre I

Ing. Noretsys Rodríguez

¿QUÉ SON LOS REQUISITOS O REQUERIMIENTOS?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

Una representación documentada de una condición o necesidad.

QUE SE CONSIDERA COMO UN REQUISITO

Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe

incluir un verificador de ortografía y un comando de corrección’

Una propiedad muy general del sistemaEj.: ‘el sistema debe asegurar que la

información personal nunca se haga disponible sin autorización’

Una restricción específica del sistema Ej.: ‘el sensor debe ser activado 10 veces

por segundo’ Una restricción para el desarrollo del sistema

Ej.: ‘el sistema debe ser desarrollado usando Ada’

Cómo llevar a cabo algún cálculo Ej.: ‘la nota final debe ser calculada

sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada’

QUE SE CONSIDERA COMO UN REQUISITO

Propiedades del dominio: “Cosas” en el dominio de aplicación que son verdaderas independientemente que se construya o no el sistema de software

Requisitos: “Cosas” en el dominio de aplicación que se desean sean verdaderas mediante la construcción del sistema de software

Especificación: descripción de comportamiento (y datos) que el programa tiene que tener para cumplir los requisitos• Sólo puede ser descrito en términos de los

fenómenos compartidos por la máquina y el dominio de aplicación

ACTORES RELACIONADOS CON EL SISTEMA

Llamados Stakeholder. Entidad que será afectada por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema.

Usuarios finales del sistema Gerentes involucrados en los procesos organizacionales influenciados o que influencian al sistema Ingenieros responsables por el desarrollo y mantenimiento del sistema, Clientes de la organización Cuerpos externos tales como autoridades reguladoras o de certificación.

LEVANTAMIENTO DE REQUISITOS

Definición de requisitos Expresa en lenguaje natural o con

diagramas los servicios y restricciones operacionales del sistema. Se genera con la información proporcionada por el cliente.

Especificación de Requisitos Documento estructurado que describe

con detalle los servicios del sistema. A veces llamado especificación funcional. Escrito como contrato con el cliente.

Especificación de software Escrito para los diseñadores. Sirve de

base para el diseño y desarrollo del sistema.

DOCUMENTO DE REQUISITOS

El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software. Nombres:

Especificación funcional, Definición de requisitos, Especificación de los requisitos de software

DOCUMENTO DE REQUISITOS

El documento describe: Los servicios y funciones que el sistema

debería proveer. Las restricciones bajo las cuales el sistema

debe operar Las propiedades generales del sistema, es

decir, restricciones sobre las propiedades emergentes del sistema

Definiciones de otros sistemas con los cuales el sistema se debe integrar.

Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.

Restricciones sobre el proceso usado para desarrollar el sistema

glosario

USUARIOS DEL DOCUMENTO DE REQUISITOS

Clientes del sistemaEspecifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.

Gerentes Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema

y planificar el proceso de desarrollo.

Ingenieros de sistemas Usan los requisitos para entender qué sistema tiene que ser desarrollado.

Ingenieros de prueba de sistemas

Usan los requisitos para desarrollar pruebas de validación para el sistema.

Ing. de mantenimiento de sistemas

Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.

MODELO IEEE/ANSI 830-1998 Introducción

• 1.1.Propósito del documento de requisitos• 1.2.Alcance del proyecto• 1.3.Definiciones, acrónimos y abreviaturas• 1.4.Resumen del resto del documento

Descripción General• 2.1.Perspectiva del producto• 2.2.Funciones del producto• 2.3.Características de los usuarios• 2.4.Limitaciones generales• 2.5.Suposiciones y dependencias

Requisitos Específicos• 3.1.Requisitos funcionales, no funcionales

Apéndices Índice

INGENIERÍA DE REQUISITOS (RE)

RE trata la identificación del propósito de un sistema de software y el contexto en el cual será usado.

RE actúa como un puente entre las necesidades del mundo real de los clientes y otros actores afectados

Trata sobre los objetivos del mundo real para los sistemas de software, servicios provistos y restricciones.

Trata sobre el comportamiento del sistema y su evolución a través del tiempo.

IMPORTANCIA DE LA RE EN EL DESARROLLO DE SOFTWARE Cuanto más tarde en el ciclo de vida se detecta un error,

más cuesta repararlo. Muchos errores permanecen latentes y no son

detectados hasta bastante después de la etapa en que se cometieron. Muchos podrían detectarse tempranamente

Se cometen muchos errores de requisitos

Impacto de los errores en la etapa de requisitos El software resultante puede no satisfacer a los usuarios. Las interpretaciones múltiples de los requisitos pueden

causar desacuerdos entre clientes y desarrolladores. Es imposible que a través del testeo el software

satisfaga sus requisitos. Puede gastarse tiempo y dinero construyendo el sistema

erróneo.

ACTIVIDADES DEL PROCESO DE LA RE

Elicitación

Modelado Análisis Gestión

I dentificación de Fuentes I nform.

Representación Verificación I dentificación de cambios

Recolección de hechos

Organización Validación Análisis de cambios

Comunicación Almacenamiento (registración)

Negociación Realización de cambios

TÉCNICA JAD (JOINT APLICATION DESIGNER)

Permite a los usuarios, diseñar sistemas en forma conjunta, en sesiones grupales.

Gibson y Jackson afirman que los resultados aumentan de un 20% a un 60%.

Promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos de usuarios.

ROLES DEL JAD

Líder de la sesión. Representante de los usuarios. Especialista. Analista. Representante de SS. Patrocinador (sponsor) ejecutivo o dueño del

sistema.

LÍDER DE SESIÓN

Facilitador de JAD. Dirige el proceso. Facilita el debate y la preparación de

documentos. Trata con el sponsor de JAD para acordar

quién debe asistir las reuniones. Acordar la agenda con los participantes.

PLAN JAD

Dura entre uno y cinco días. El líder de la sesión guía a los participantes a

lo largo de ocho tareas predefinidas. Ellas son: Orientación. Definición de requerimientos de alto nivel . Límites y alcances del sistema . Identificar y estimar tiempos de los Diseños JAD. Identificar los participantes de los Diseños JAD. Programar días y horarios para los Diseños JAD. Acordar los puntos y consideraciones de la

documentación a generar del Plan JAD. Concluir la sesión.

DISEÑO JAD. SESIÓN DE DISEÑO

Dura aproximadamente entre tres y diez días. El líder de la sesión guía a los participantes a

lo largo de las siguientes tareas: Orientación. Revisión y refinación de los requerimientos y

alcance del Plan JAD. Desarrollar diagrama de flujo del trabajo. Desarrollar descripción del flujo de trabajo. Identificar funciones y grupos de datos del

sistema. Especificar los requerimientos de procesamiento. Acordar los puntos y consideraciones de la

documentación a generar del Diseño JAD. Concluir la fase de sesión.

LIBROS DE TRABAJO

Formas predefinidas para los grupos, para que sean completadas durante la sesión.

Formularios de participantes. Formularios de resultados. Formularios de estimaciones. Formularios de salidas por pantalla. Formularios de reportes. Formularios de descripción de interfaces y de

descripción de funciones.

JAD Y EL PROCESO DE REQUERIMIENTOS

La articulación del concepto de producto, requerimientos, medición de resultados.

Análisis de problemas. Estudios de factibilidad y análisis de opciones

de costo-beneficio. Análisis y modelado. La documentación de requerimientos.

JAD Y LA COMUNICACIÓN HUMANA

La identificación de varios puntos de vista. La conciliación de los puntos de vista. La revisión por parte del usuario de los

modelos desarrollados. El análisis de los propios problemas del

usuario y la identificación de la necesidad de cambio.

ANÁLISIS DE PUNTOS DE FUNCIÓN (FPA)

Mide el tamaño del software desde el punto de vista del usuario. Medir la funcionalidad del producto.

Es independiente de la tecnología usada para el desarrollo e implementación.

Se aplica a partir de los documentos de requerimientos y a lo largo del ciclo de vida del software.

Los enfoques para estimar Puntos Función (Function Points - FP) facilitan la estimación temprana de un proyecto de software (costo, esfuerzo, cronograma) cuando los requerimientos no están completamente definidos.

MEDICIÓN

Es una práctica de administración Probada en el tiempo.

No se puede administrar lo que no se puede medir.

Un 40% de proyectos fracasan por falta de administración,

Herramienta para determinar el tamaño del requerimiento, extrapolar la productividad y la calidad.

Se mide para entender y mejorar procesos.

CLASES DE MEDICIÓN

Medición: Cuantificación directa. Estatura de una persona.

Cálculo: Cuantificación indirecta. A partir de la combinación de medidas se

obtiene el valor del atributo de interés. Ejemplo: medir la velocidad a partir de la

distancia y el tiempo.

MEDICIÓN DEL SOFTWARE

Se miden las características para saber si los requerimientos son consistentes y completos.

Los administradores de proyectos miden procesos y productos para determinar tiempos de entrega y costos.

Incluyen las siguientes actividades: Estimación de costo y esfuerzo. Medidas de productividad. Recolección de datos. Medidas de calidad y confiabilidad. Performance. Complejidad. Métodos y herramientas.

BENEFICIOS DE LA MEDICIÓN

Entender que está ocurriendo en el desarrollo y mantenimiento para mejorar las relaciones entre actividades.

Control de lo que ocurre en el proyecto, para predecir lo que ocurrirá y los cambios a realizar.

Mejorar los procesos y productos, aumentando las revisiones del diseño se incrementa la calidad.

MEDICIÓN DEL TAMAÑO DEL SISTEMA

Tamaño del procesamiento de información• Entradas• Salidas.• Otros

Tamaño del sistema desde los requerimientos del

usuario

Requerimientos técnicos.• Performance.• Facilidad de

uso.• otros

BENEFICIOS DEL FPA

Mejorará la definición de los requerimientos. Comunicar requerimientos funcionales. Estimar esfuerzo, agenda y costos basado

en requerimientos. Evaluar la factibilidad de un proyecto. Administrar los cambios. Mejorará el mantenimiento y soporte. Medir la productividad. Verificar la completitud.

RESUMEN DE OBJETIVOS

¿Qué son los requerimientos o Requisitos? Necesidades, objetivos y actores

relacionados con los requerimientos Importancia de la Ingeniería de Requisitos en

la práctica Levantamiento y Recolección de

Requerimientos. Técnicas más usadas: Método JAD y FPA