Recordamos … ANÁLISIS Y DISEÑO SISTEMAScs.uns.edu.ar/~td/ayds2012/downloads/Clases/ADS_04_2012-...

Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.

1

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2012.

Mg. María Mercedes Vitturini [[email protected]]

Dpto. Cs. e Ingeniería de la Computación

Universidad Nacional del Sur

Primer cuatrimestre 2012

ANÁLISIS Y DISEÑO DE SISTEMAS

Clase 4: Requerimientos e

Ingeniería de Requerimientos

Recordamos …

• El objetivo de Ingeniería de Software es

favorecer el desarrollo de sistemas de software

de calidad, en los tiempos y costos estimados

• “ … construir un sistema que resuelve el problema

equivocado, que no funciona como se espera, o que

presenta dificultades para que los usuarios puedan

comprenderlo y utilizarlo resulta en un sistema

fracasado”

• Una parte importante del éxito de un proyecto

depende de la administración y gestión

adecuada de los requerimientos

2 AyDS2012 - Clase 4- MMV

AyDS2012 - Clase 4- MMV 3

Importancia de los requerimientos (lectura)

“ En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar cómo les estaba yendo. Los resultados son desencantadores. El 31% de los proyectos de software fueron cancelados antes de completarse. Es más, en las grandes compañías, sólo el 9% de los proyectos fue entregado en término y dentro del costo presupuestados; el 16% satisfizo esto, en pequeñas empresas. El 52,7% costó hasta el 189% más de lo estimado.

Para comprender el por qué, Standish (1995) pidió a los participantes en el estudio que explicaran las causas de los proyectos fallidos. Los principales factores fueron: …


Importancia de los requerimientos ...

Los principales factores fueron: …

• Requerimientos incompletos (13,1%).

• Falta de compromiso del usuario (12,4%).

• Falta de recursos (10,6%).

• Expectativas no realistas (9,9%).

• Falta de soporte ejecutivo (9,3%).

• Requerimientos y especificaciones cambiantes (8,7%).

• Falta de planeamiento (8,1%).

• Fin de la necesidad del sistema (7,5%).

• Ref: Problemas que se relacionan con la etapa de elicitación, análisis y especificación de requerimientos.


¿Por qué son importantes los requerimientos? (lectura) ...

Las etapas de la extracción, la definición, y la gestión del proceso de los requerimientos participaron en casi todas estas causas. La falta de cuidado en la comprensión, la documentación y la gestión de los requerimientos puede llevar a una gran cantidad de problemas: construir un sistema que resuelve el problema equivocado, que no funciona como se espera, o que presenta dificultades para que los usuarios puedan comprenderlo y utilizarlo. Es más un proceso de requerimientos mediocre puede en realidad resultar muy caro “

Requerimiento Un sistema basado en software tiene un propósito,

expresado como algo que el sistema debe hacer o

cumplir: los requerimientos del sistema.

Definición de requerimiento –

– Una descripción de algo que el sistema es capaz de

hacer con el objeto de satisfacer el propósito de

usuarios y clientes.

– Una restricción que debe ser satisfecha por un sistema

o componente de software para satisfacer un contrato,

estándar, especificación u otra documentación formal.

• Sinónimo: requisito



2



Tipos de requerimientos

Requerimientos Funcionales –

• Representan a los servicios que el sistema debe proveer,

incluye:

– cómo debe reaccionar ante los estímulos que recibe, y

– cómo el sistema debe comportarse en situaciones particulares.

Requerimientos NO Funcionales –

• Representan las restricciones sobre los servicios o

funciones ofrecidas por el sistema. Incluye

– Restricciones de tiempo, sobre el proceso de desarrollo y estándares a respetar.

• En general los requerimientos no funcionales expresan necesidades del sistema como un todo.

Clasificación de RNF


Performance

requir ements

Space

requir ements

Usa bility

requir ements

Efficiency

requir ements

Relia bility

requir ements

Portability

requir ements

Inter oper a bility

requir ements

Ethical

requir ements

Leg islative

requir ements

Implementa tion

requir ements

Standar ds

requir ements

Deli very

requir ements

Safety

requir ements

Pri vacy

requir ements

Product

requir ements

Organisational

requir ements

External

requir ements

Non-functional

requir ements

Ejemplo Sistema para una Obra Social

• ¿Requerimientos funcionales?

– Contar con servicios para agregar, borrar, suspender y/o modificar socios

– Asignar y/o cancelar órdenes de atención a asociados.

– Registrar pago a prestadores.

– … (muchos otros)

• ¿Requerimientos no funcionales?

– Debe estar desarrollado sobre en el ambiente .NET

– Debe funcionar con estaciones de trabajo distribuidas

geográficamente.

– Las prestaciones sobre órdenes de atención deben ajustarse a la reglamentación “Reglamento xyz.2010”.

– … (muchos otros)


Software Requirements Specification (SRS)

Documento SRS – Es el nombre

que recibe el documento que

contiene la descripción completa

del comportamiento esperado para

el nuevo sistema a desarrollar.

• IEEE Recommended Practice

for Software Requirements

Specifications (IEEE Std 830-

1998, Revision of IEEE Std 830-

1993)

Secciones IEEE Std 830-1998 • Introduction

– Purpose – Scope – Definitions – System overview – References

• Overall description – Product perspective – Product functions – User characteristics – Constraints, assumptions and

dependencies

• Specific requirements – External interface requirements – Functional requirements – Performance requirements – Design constraints – Logical database requirement – Software System attributes – Other requirements



Propósito de los requerimientos

• Los requerimientos sirven a distintos propósitos:

– Los analistas explican y modelan cómo han

entendido lo que los clientes pretenden del sistema.

– Los clientes validan que el equipo de desarrollo

comprendió las necesidades del sistema

– Indican a los diseñadores qué funcionalidad y

características va a tener el sistema resultante.

– Indican a los testeadores qué demostraciones llevar

a cabo para comprobar que el sistema que se le

entrega es lo que había solicitado.

El proceso de Ingeniería de Requerimientos

La IR comprende la determinación de las necesidades y condiciones a satisfacer por

un software en forma consistente

Extraer Analizar Organizar Validar Verificar


3



“Proporciona un mecanismo apropiado para entender lo que el cliente desea, 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 que se transforman en una sistema funcional”

Requerimientos en el tiempo:

• Los requerimientos se capturan en las primeras etapas del

ciclo de vida de un sistema.

• Se administran durante toda la vida del sistema.

• Para la mayoría de los sistemas, los requerimientos son

variables.


Razón Costo de Modificación/ Etapa Requerida

Requerimientos:

0.1$

Diseño: 0.5$

Codificación: 1$

Testeo de Unidad: 2$

Testeo de aceptación: 5$

Mantenimiento: 20$


Conclusión: es rentable

tomarse el tiempo que sea

necesario para

comprender el problema y

su contexto, y obtener los

requerimientos correctos

desde el primer momento.

Problemas con los Requerimientos

Problemas

• Los interesados (stakeholders) no saben lo que

realmente quieren.

• Los interesados expresan requerimientos en

términos propios, ambiguos e incompletos.

• Diferentes participantes pueden tener conflictos

con los requerimientos.

• Factores organizacionales y políticos pueden

influenciar sobre los requerimientos del sistema.

• Los requerimientos varían durante el proceso. 15 AyDS2012 - Clase 4- MMV AyDS2012 - Clase 4- MMV 16


Objetivos

• Extracción de los requerimientos, esto es, la

comprensión de lo que los clientes y usuarios

esperan que haga el sistema.

• Documentar y revisar con el cliente para

comprobar exactitud y completitud.

• Involucrar usuarios operativos, directivos,

ejecutivos, ingenieros, expertos de dominio, etc.

Extraer Analizar Organizar Documen

tar Validar Verificar

Ingeniería de requerimientos

Ingeniería de requerimientos – es una aproximación

sistemática para gestionar requerimientos. Incluye las

siguientes actividades:

• Además de un proceso establecido entre el cliente y el

grupo de desarrollo sobre gestionar los cambios a los

requerimientos del sistema.


Estudio de Factibilidad - Repaso

• Estudio corto del sistema (2 o 3 semanas!)

enfocado a determinar para el nuevo

sistema/modificación de software si:

– Contribuye a los objetivos de la organización.

– Es posible implementar con la tecnología

disponible y bajo las restricciones de costo y

planificación.

– El sistema podrá integrarse con otros

sistemas existentes.



4


Próximos pasos en la especificación

• Cómo sigue?

– Próxima actividad del CV del proyecto: eliciación

análisis y especificación de requerimientos.

– Primeros modelos del dominio.

19 AyDS 2011 - Lic. Mercedes

Vitturini - Clase 4

Estudio de

Factibilidad

1. Extracción,

2. Análisis

3. Organización

4. Documentación

5. Validación

Si el proyecto

sigue adelante



Fuente: Software Engineering – Ed 8 I.Sommerville


1. Extracción de Requerimientos

Trabajar con clientes y usuarios finales para:

1. Averiguar sobre el dominio del problema o

dominio de aplicación

– “Es problema de quien debe obtener los

requerimientos entender los problemas, cultura y

lenguaje del dominio para construir el sistema que

responde a las necesidades”.

2. Comprender lo que los clientes y usuarios

esperan que haga el sistema.

Necesidades

del Cliente


Extracción de requerimientos - Técnicas

• Se involucra a los interesados para identificar

los requerimientos del sistema:

– Formulando preguntas a los distintos usuarios del

sistema (entrevistas).

– Estudiando el sistema actual: puntos fuertes y

puntos débiles.

– Estudiando el comportamiento de sistemas

similares.

– Desarrollando prototipos.

• Sinónimo: Elicitación de requerimientos


Extracción de requerimientos

Consejos prácticos

• Revisar la situación actual.

• Trabajar en el ámbito del usuario para comprender el

contexto, los problemas y las relaciones.

• Entrevistar a los usuarios actuales y potenciales.

Realizar lluvia de ideas con los usuarios actuales y

potenciales.

• Hacer demostraciones de cómo podría funcionar el

sistema.

• Investigar documentación existente.

• Observar las estructuras y los patrones.


Entrevistas

Antes de la entrevista:

• Estudiar previamente el dominio del problema.

• Determinar el objetivo y contenido de la entrevista.

• Seleccionar a las personas que se va a entrevistar.

• Concertar la entrevista por anticipado e indicar la

duración de la entrevista.

• Fijar roles en el equipo: secretario de actas,

controlador de tiempos, moderador

• Ser puntual – Respetar tiempos.


5



Entrevistas

• Durante la entrevista:

– Mantener la entrevista en foco.

– Al finalizar, leer las conclusiones.

– Consensuar próximos pasos.

– Solicitar ejemplos de documentos fuentes,

salidas del sistema, pantallas.


2. Analizar los requerimientos

• Se debe analizar el problema antes de

considerar cualquier solución:

– Desglosar el problema en piezas más pequeñas y

fáciles de comprender.

• Análisis del problema:

– Identificar las personas, los procesos y recursos

involucrados.

– Documentar las relaciones entre ellos


Analizar los Requerimientos • ¿Los requerimientos son correctos?

– Cliente y analista deben revisarlos.

• ¿Los requerimientos son consistentes?

– No poseen inconsistencia ni ambigüedades.

• ¿Los requerimientos están completos?

– Todos los estados, cambios de estados, entradas, productos y restricciones están descriptos.

• ¿Los requerimientos son realistas?

– Es posible cumplir con los requerimientos.

• ¿Describe cada requerimiento algo que es necesario para el usuario?

– Existen requerimientos que se puedan eliminar

• ¿Los requerimientos son verificables?

– Se necesitan pruebas que los demuestren


3. Organizar los requerimientos

• Clasificar los requerimientos en:

– Los que deben ser absolutamente satisfechos

(mandatorios).

– Los que son muy deseables pero no indispensables

(deseables).

– Los que son posibles, pero que podrían eliminarse (no

prioritarios).

• La clasificación de requerimientos es útil para:

– Comprender lo que realmente se necesita.

– Cuando el proyecto está restringido en tiempo y

recursos, se eliminan los requerimientos de la tercera

categoría, y los de la segunda se negocian


Ejemplo • Supongamos una aplicación para proveer

servicios de correo electrónico:

– ¿Requerimientos mandatorios?

• Facilidades para enviar y recibir mensajes, crear

nuevos mensajes, responder mensajes, etc.

– ¿Requerimientos deseables?

• Contar con un libreta de direcciones, facilidades

filtrar mensajes, etc.

– ¿Requerimientos no prioritarios?

• Mostrar los mensajes con distinto color según el

remitente.


4. Documentar Requerimientos

• La extracción y el análisis de requerimientos

sirve a dos propósitos diferentes, pero

relacionados:

– La extracción permite escribir un

documento de definición de

requerimientos (términos que el cliente

entiende).

– La extracción y el análisis permiten escribir

la especificación de requerimientos

(términos técnicos, que habilita el diseño

del sistema).

• Frecuentemente un único documento sirve a

ambos propósitos.

Requerimientos de Usuario

Requerimientos de Sistema


6


Documentar los Requerimientos

Requerimientos de Usuarios

– Sentencias en lenguaje natural más algunos

diagramas que muestren los servicios del sistema.

– Están dirigidos a los usuarios.

Requerimientos de Sistema

– Documento estructurado con descripciones detalladas de las funcionalidades del sistema,

servicios y restricciones operativas.

– Define qué se implementará.

31 AyDS2012 - Clase 4- MMV AyDS2012 - Clase 4- MMV 32

Requerimientos de Usuario • Deben describir los requerimientos funcionales y no

funcionales de manera entendible para el usuario y

sin especificar conocimiento técnico.

• Usar lenguaje claro y simple, acompañado de tablas,

formularios y diagramas intuitivos.

• Problemas de los requerimientos de usuario:

– Falta de claridad: el lenguaje natural no es preciso.

– Confusión entre requerimientos funcionales y no funcionales.

– Requerimientos compuestos: varios requerimientos se

expresan como un único requerimiento


Requerimientos del Sistema

• Son más específicos y técnicos.

• Dependiendo de la criticidad del requerimiento,

no se aconseja la especificación en lenguaje

natural, que tiene los siguientes problemas:

– Confía que lectores y escritores usan las mismas

palabras para los mismos conceptos.

– Es demasiado flexible y existen muchas maneras de

decir lo mismo.

– Es difícil de modularizar y de mantener documentos

actualizados.


Requerimientos del sistema - Notación

Algunas variantes de notación:

• Lenguaje natural estructurado: definir patrones

para expresar la especificación de requerimientos.

• Usar notación gráfica: usar un lenguaje gráfico

acompañado con texto para definir los

requerimientos del sistema.

– Ejemplos: diagramas de casos de uso, diagramas de secuencia.

• Especificaciones matemáticas: notaciones basadas

en conceptos matemáticos, como máquinas de

estados o conjuntos.

Modelos del

sistema


Ejemplo: Un requerimiento del usuario

Definición de requerimientos de usuario

1. Un cliente tendrá facilidades para consultar el catálogo de libros disponibles. Contarán con mecanismos de búsqueda filtrada por ISBN, autor, título o área de interés.


Ejem

plo

: Req

ue

rim

ien

to d

el S

iste

ma


7


5. Validación de Requerimientos

• Se chequea con el cliente que los requerimientos

coinciden con lo que espera del sistema.

• El costo de un error en los requerimientos es

proporcional al tiempo en que se encuentra, de

allí la importancia de la validación (ver

transparencia #13). •

• Involucrar a los usuarios gerenciales, ejecutivos y

finales.


Consensuar !

6. Verificación

• Algunos requerimientos pueden necesitar que se

compruebe o demuestre que el producto

cumplen con la especificación.

• La verificación se realiza durante el testeo.

• En la etapa de requerimientos sólo se identifican

aquellos requerimientos que requieren

verificación


Ingeniería de requerimientos

• El proceso de IR no es un proceso lineal.


Necesidades

del cliente

Requerimientos del Sistema


Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB)

Objetivo: proveer un nuevo servicio de venta de libros vía Internet.

Descripción:

• La funcionalidad será de uso público, pero se requiere que los

clientes se registren previamente.

• Los clientes podrán consultar el catálogo de libros. Contarán con mecanismos de búsqueda por ISBN, autor, título o área de

interés. Opcionalmente podrán efectuar pedidos de compra de

libros.

• Si el cliente confirma un pedido de compra debe ingresar la forma

de pago y el domicilio de envío. El sistema responde con un mail que le informa el número de pedido y el detalle de la compra.

• El encargado de deposito contará con la facilidad de emitir un

informe con los pedidos de compra de un período informado.

Ejercicio

• Para el problema “Venta electrónica de material

bibliográfico”

– Encontrar requerimientos funcionales.

– Encontrar requerimientos no funcionales.

– Para reflexionar: ¿se encontraron todos los

requerimientos? ¿existen ambigüedades?

¿contradicciones?

AyDS2012 - Clase 4- MMV 41 AyDS2012 - Clase 4- MMV 42

Temas de la clase de hoy

• Requerimientos

– Extracción de requerimientos. Fases. Objetivos. Requerimientos Funcionales y No funcionales.

– Documentación de requerimientos.

– Análisis de Requerimientos.

• Bibliografía.

– Software Engineering – Ian Sommerville. Ed. 8. Capítulos 6 y 7

– Ingeniería de Software -Teoría y práctica” - Shari L. Pfleeger. Capítulos 1 y 4.

– Managing Software Requirements. 2nd Ed. D. Leffingwell. Capítulos 1 y 2.

Recordamos … ANÁLISIS Y DISEÑO SISTEMAScs.uns.edu.ar/~td/ayds2012/downloads/Clases/ADS_04_2012-...

Documents

Transcript of Recordamos … ANÁLISIS Y DISEÑO SISTEMAScs.uns.edu.ar/~td/ayds2012/downloads/Clases/ADS_04_2012-...