recordamos … anÁlisis y diseÑo sistemascs.uns.edu.ar/~td/ayds2012/downloads/clases/ads_04_2012-...
Post on 05-Nov-2018
221 Views
Preview:
TRANSCRIPT
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 [mvitturi@cs.uns.edu.ar]
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: …
AyDS2012 - Clase 4- MMV 4
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.
AyDS2012 - Clase 4- MMV 5
¿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
6 AyDS2012 - Clase 4- MMV
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
2
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.
AyDS2012 - Clase 4- MMV 7
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
AyDS2012 - Clase 4- MMV 8
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)
9 AyDS2012 - Clase 4- MMV
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
AyDS2012 - Clase 4- MMV 10
AyDS2012 - Clase 4- MMV 11
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
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
3
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.
Ingeniería de Requerimientos
“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.
13 AyDS2012 - Clase 4- MMV
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$
14 AyDS2012 - Clase 4- MMV
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
Ingeniería de Requerimientos
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.
17 AyDS2012 - Clase 4- MMV
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.
AyDS2012 - Clase 4- MMV 18
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
4
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.
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
Ingeniería de Requerimientos
AyDS2012 - Clase 4- MMV 20
Fuente: Software Engineering – Ed 8 I.Sommerville
AyDS2012 - Clase 4- MMV 21
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
AyDS2012 - Clase 4- MMV 22
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
AyDS2012 - Clase 4- MMV 23
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.
AyDS2012 - Clase 4- MMV 24
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.
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
5
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.
AyDS2012 - Clase 4- MMV 25
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.
AyDS2012 - Clase 4- MMV 26
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
AyDS2012 - Clase 4- MMV 27
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
AyDS2012 - Clase 4- MMV 28
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
AyDS2012 - Clase 4- MMV 29
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.
AyDS2012 - Clase 4- MMV 30
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
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
6
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.
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
AyDS2012 - Clase 4- MMV 33
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.
AyDS2012 - Clase 4- MMV 34
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
AyDS2012 - Clase 4- MMV 35
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.
AyDS2012 - Clase 4- MMV 36
Ejem
plo
: Req
ue
rim
ien
to d
el S
iste
ma
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
7
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.
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.
37 AyDS2012 - Clase 4- MMV
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
38 AyDS2012 - Clase 4- MMV
Ingeniería de requerimientos
• El proceso de IR no es un proceso lineal.
39 AyDS2012 - Clase 4- MMV
Necesidades
del cliente
Requerimientos del Sistema
AyDS2012 - Clase 4- MMV 40
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.
top related