Necesidad vs. Soluciónmgoncalves/IS2/sd07/clase5.pdf · 2007-10-03 · “Una condición o...

1

Necesidad vs. SoluciónNecesidad vs. Solución

2

Referencias

“El Proceso unificado de desarrollo de Software”I. Jacobson, G. Booch y J.RumbaughAddison Wesley - Pearson Education 1999

“The Rational Unified Process”Ph. KruchtenAddison Wesley 2000

“Applying UML and Patterns. An Introduction to Object-OrientedAnalysis and Dessign and the Unified Process”C. LarmanPrentice Hall. Second Edition. 2002

3

Referencias

“El Lenguaje Unificado de Modelado: Manual de Referencia”J.Rumbaugh, I. Jacobson y G. BoochAddison Wesley - Pearson Education 2000

“Software Engineering”M. Dorfman and R. Thayer, IEEE Computer Society Press,Los Alamitos, CA, 1997 pp. 79.

“RUP”Herramienta de RationalVersión 2003.06.12.01

4

Referencias

“Applying Requirements Management with Use Cases”R. Oberg, L. Probasco and M. EricssonRational Software White Paper

5

Disciplina de Requerimientos en Rational Unified Process

Modelado del Negocio

ImplementaciónPrueba

Entrega

Análisis y Diseño

Fundamentales

Requerimientos

Gerencia de ProyectoAmbiente

Fases

Iteraciones

Elaboración Construcción Transición

Gerencia de Configuración y Cambio

InicioDisciplinas

6

Disciplina de Requerimientos

7

Requerimientos

¿Qué son?

¿Para qué sirven?

¿Cómo se clasifican?

¿A través de qué artefactos pueden describirse?

8

Requerimientos: ¿Qué son?

¿Qué deberá hacer el sistema?¿Con qué condiciones y restricciones deberá hacerlo?

¿Qué cualidades o atributos deberá poseer el sistema?

9

Requerimientos: ¿Qué son?

Rational define requerimiento como:“Una condición o capacidad que el sistema (a construir) debe cumplir”

Merlin Dorfman and Richard H. Thayer lo definencomo:•“Una capacidad de software necesaria para el usuariocon el fin de resolver un problema o alcanzar un objetivo.”• “Una capacidad de software que debe ser alcanzada o poseer para satisfacer un contrato, especificación, estándar u otra formalidad impuesta por la documentación.”

10

Requerimientos: ¿Para qué sirven?

Requerimientos

11

Requerimientos: Tipos

12

Requerimientos: Clasificación de uso común

Especifican acciones que el sistema debe poder realizar, sin tomar en cuenta restricciones

físicas.

Se describen generalmente en un Modelo de Casos de Uso y

en Casos de Uso.

Describen las entradas y el comportamiento resultante del

sistema

13

Requerimientos: Categorías FURPS+

14


15Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

16Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

•Factores Humanos•Estética•Consistencia de Interfaz de Usuario•Ayuda en línea o “context-sensitive”•“wizards” y agentes•Documentación de Usuario•Materiales de Capacitación/Entrenamiento

17Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

•Frecuencia y severidad de fallas•Facilidades de recuperación•Posibilidades de predicción

18Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

Condiciones impuestas a otros requerimientos y son tales como:•Velocidad•Eficiencia•Disponibilidad•Tiempo de Respuesta•Tiempo de Recuperación•Uso de recursos

19Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

•Adaptabilidad•Mantenibilidad•Compatibilidad•Configurabilidad•Instalabilidad•Localizabilidad (Internacionalización)

20Req

uerim

ient

os o

A

tribu

tos d

e C

a lid

adRequerimientos:

Categorías FURPS+

21


Especifica restricciones de codificación o de construcción del sistema:•Estándares requeridos•Lenguajes de implementación•Políticas para la integridad de Bases de Datos•Límite de recursos•Ambientes de Operación

22


Especifica:• Elemento externo con el que

el sistema debe interactuar• Restricciones o formatos,

tiempos u otros factores usados en tales interacciones

23


Restricciones de Diseño

24

Ingeniería de Requerimientos

• Es el proceso de descubrir, analizar, documentar y verificar los requisitos del software.• Pasos:

– Levantamiento de Requerimientos: Es el proceso de descubrir, normalmente en circunstancias difíciles, lo que se debe construir.

• ¿Cuáles son los objetivos del sistema?• ¿Qué debe lograr el sistema?• ¿Cómo ayuda el sistema en las necesidades del negocio?• ¿Cómo usaría el sistema en el día a día?

25

Ingeniería de Requerimientos -Pasos

•Análisis de los requerimientos:– Los requerimientos son analizados, clasificados y

organizados.– Se exploran atributos como consistencia, completitud,

ambigüedad y prioridad•Especificación de requerimientos:

– Puede contener: un documento escrito, un modelo gráfico, un modelo formal, una colección de casos de uso y un conjunto de prototipos

•Modelado del sistema•Validación de los requerimientos

26

Ingeniería de Requerimientos -Pasos

•Administración de requerimientos:– Control de identificación y trazabilidad de los requerimientos.– Maneja cambios en los requerimientos– Es un enfoque sistemático para elicitar, organizar y documentar los

requerimientos del sistema– Es un enfoque sistemático para establecer y mantener acuerdo entre el

cliente y el equipo sobre cambios en los requerimientos.

27

Stakeholders

• Se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requisitos del sistema. • Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización se que verán afectados por dicho sistema. • Los stakeholders también son los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los administradores del negocio, los expertos en el dominio del sistema, los representantes de los trabajadores, etc.

28

6 Mejores Prácticas

MEJORES PRACTICAS

Desarrollar Iterativamente

Administrar RequerimientosUsar Arquitecturas basadas en Componentes

Modelar Visualmente (UML)Verificar Continuamente la Calidad

Administrar el Cambio

MEJORES PRACTICAS

Desarrollar Iterativamente

AdministrarAdministrar RequerimientosRequerimientosUsar Arquitecturas basadas en Componentes

Modelar Visualmente (UML)Verificar Continuamente la Calidad

Administrar el Cambio

29

Administración de Requerimientos

El CHAOS Report del Standish Group indica que el 72% de los proyectos falla y que una de las principales causas de la falla de los proyectos está relacionada con los requerimientos (1994-1997).

Computer Industry Daily indicó que el 76% de los gerentes de proyecto han tenido experiencias de proyectos fallidos y la causa mas frecuentemente nombrada fue “el cambio en los requerimientos del usuario” (Diciembre 1997).

30


Los requerimientos:•No siempre son obvios y provienen de muchas fuentes

•No siempre son fáciles de describir

•Hay muchos tipos de requerimientos y en diferentes niveles de detalle

•Se relacionan entre si y con otros documentos de diferentes formas

•El número de requerimientos se torna inmanejable si no se controlan

•Los requerimientos tienen su propias propiedades con sus propios valores

•Hay muchos interesados y responsables

•Son cambiantes

•Pueden ser sensibles en el tiempo

31


Mantener una clara descripción del requerimiento, Trabajar con atributos para cada tipo de requerimiento Mantener la trazabilidad con otros artefactos del proyecto

32

Requerimientos: descripción

• La Especificación de Requerimientos de Software (SRS) captura los requerimientos de sistema completo o de una porción de éste.

• SRS es un documento que contiene la descripción completa del comportamiento externo de un producto de software.

33


• Atributos de una SRS de alta calidad:– Correctitud, sin errores– No Ambigüedad– Verificable: Si existe algún proceso finito de coste

razonable que pueda probar que el producto software cumple con los requisitos.

– Consistencia– Comprensible– Facilidad de modificación– Comentado

34


• Atributos de una SRS de alta calidad:– Trazable: el origen de cada requisito está claro y

se posibilita la referencia de cada uno de estos requisitos en desarrollos futuros o incrementos de la documentación.

– Completitud: • Externamente completa si contiene todas las

propiedades deseadas por el cliente.• Internamente completa si no existen referencias no

definidas.

35


• Estándar IEEE 830 para SRS– Introducción (Propósito; alcance; definición,

acrónimos y abreviaciones; referencias; vista general del resto de la SRS)

– Descripción general (Perspectiva del producto; funciones del producto; características del usuario; restricciones generales; suposiciones y dependencias)

– Requerimientos específicos• Requerimientos funcionales (introducción, entradas,

proceso, salidas)

36


• Estándar IEEE 830 para SRS– Requerimientos específicos

• Requerimientos externos de interfaz (interfaces de usuario, interfaces de hardware, interfaces de software e interfaces de comunicación)

• Requerimientos de rendimiento• Restricciones de diseño (conformidad con los estándares

y limitaciones de hardware)• Atributos (disponibilidad, seguridad, mantenibilidad, etc.)• Otros requerimientos (base de datos, operaciones, etc)

– Apéndices

37

Requerimientos: atributos

Atributos Multidimensionales

38


Los requerimientos y sus atributos permiten:•Administrar la información •Enlazar los elementos del proyecto •Planificar más adecuadamente el proyecto

39

IBM Rational RequisitePro

• Herramienta centrada en documentos, que almacena los requisitos asociándolos a documentos (aunque también permite guardarlos directamente en la base de datos).

• Auxilia especialmente en el control de cambio de requisitos, con trazabilidad para especificaciones de software y pruebas.

• Está muy unido a MS Word ya que es partner de Microsoft Development.

• La herramienta permite el uso de Oracle sobre Unix o Windows como “back-end database” y también soporta SQL Serversobre windows.

40


41

Característica B

Requerimiento C

Necesidad AAlto nivel(Necesidades)

Nivel intermedio(Características del Producto)

Bajo nivel(Caso de Uso, …)

+

-

Espacio del Problema

Espacio de la Solución


42


Una condición o una capacidad con las cuales el software que es construido debe cumplir.

Requiremientode software

Una capacidad o una característica de un sistema que satisface directamente una necesidad.

Característicadel Producto

El negocio o el problema operacional (oportunidad) que se deben satisfacer para justificar la compra o el uso. También conocido como meta u objetivo.

Necesidad

43

Ejemplo: Necesidad

• El rápido crecimiento del comercio electrónico ha causado la disminución de ventas en los almacenes de la compañía ABC, por lo que, ha visto la oportunidad de introducir la venta por Internet

44

Ejemplo: Características del Producto

• Venta por internet– Método seguro de pago– Consulta amigable de los títulos disponibles– Capacidad de confirmar el estatus de la órden– Notificación a los clientes por e-mail de los nuevos títulos en

el sitio.• Administración del Sistema

– Capacidad de agregar/borrar ofertas– Capacidad para verificar las órdenes de los clientes– Mantener la información del cliente– Generar reportes

45

Requerimientos – Estrategia de Trazabilidad

R e q u e rim ie n to s Fu n c io n a le s

R e q u e rim ie n to s n o Fu n c io n a le s

N e c e s id a d

C a ra c te r is tic a s d e l P ro d u c to

R e q u e rim ie n to s d e S o ftw a re

T ra za b le a

T ra za b le a

46

Requerimientos: trazabilidad

Característica B

Requerimiento C

Necesidad A

Diseño Prueba Documentación de Usuario

Diseño de SoftwareDescripcionesModelos de Objetos

Suites de PruebaPlan de Documentación

Alto nivel(Necesidades)

Nivel intermedio(Características del Producto)

Bajo nivel(Caso de Uso)

Traza

+

-

Traza

Espacio del Problema

Espacio de la Solución

47

Requerimientos: trazabilidad

48

Disciplina de Requerimientos en RUP

3-Oct-07

Los Diez Esenciales de RUP

Referencias básicas

“The Ten Essentials of RUP –The Essence of an Effective Development Process”Leslee ProbascoRational Software White Paper

Lista de 10 Esenciales de RUP

• Conjunto mínimo de ítems de un proyecto si verdaderamente se sigue la “esencia” de RUP:

– Visión (Desarrollar una Visión).– Plan (Manejar el Plan).– Riesgos (Identificar y Mitigar Riesgos).– Entregas (Asignar y Mantener las

Entregas).



– Caso del Negocio (Examinar el Caso de Negocio).

– Arquitectura (Diseñar una Arquitectura).– Producto (Construir y Probar el Producto

Incrementalmente).



– Evaluación (Evaluar Resultados Regularmente).– Cambio de Requerimientos (Manejar y Controlar

Cambios).– Soporte al Usuario (Proveer Asistencia al Usuario).


• Visión• Analizar el problema• Entender las necesidades de los usuarios• Definir el sistema y • Manejar requerimientos.


● El documento de Visión contiene:• Términos claves (Glosario).• Problema a resolver.• Stakeholders, usuarios y sus necesidades.• Características del producto.• Requerimientos no-funcionales.• Restricciones de diseño.


● ¿Por qué es esencial el documento de Visión?

● Se puede perder la pista hacia donde ir y desviarse.


● PlanEl plan de desarrollo de software tiene toda la información para manejar el proyectoActividades implicadas en la elaboración del software, en términos de las fases e iteraciones requeridas para implementar el sistema.

● ¿Por qué es esencial un Plan?• No serás capaz de mantener la pista del

progreso.


● Riesgos• Un precepto esencial de RUP es identificar y atacar los

más altos riesgos lo más pronto posible.• La lista de riesgos identifica los eventos, en orden

decreciente de prioridad, que podrían afectar el éxito del proyecto.

● ¿Por qué es esencial el documento de Riesgos?● Se podría enfocar en aspectos erróneos ahora y

explotar una mina insospechada cinco mesesmás tarde.


● Entregas• Identificar entregas con sus fechas y

responsables.● ¿Por qué es esencial las Entregas?

• Sin responsables, hay piedras en el camino al éxito.


● Caso de Negocio • Desarrollar un plan económico para llevar

a cabo la visión del proyecto.● ¿Por qué es esencial el Caso de

Negocio?• Existe el riesgo de perder tiempo y

dinero; el proyecto puede ser canceladoo ir hacia la bancarota.


● Arquitectura• Organización o estructura de los componentes

significativos interactuando a través de interfaces, con componentes formados por componentes e interfaces más pequeñas.

● ¿Por qué es esencial la Arquitectura?• Ser incapaz de manejar comunicación,

sincronización y aspectos de acceso a los datos; problemas con escabilidad y rendimiento.


● Producto• La esencia de la implementación y prueba en

RUP es codificar incrementalmente, construir y probar componentes del sistema, con versiones ejecutables.

● ¿Por qué es esencial el Producto(Prototipo)?

• Se obtiene mucho al trabajar con el cliente


● Evaluación• La evaluación de la iteración captura los

resultados de una iteración, las lesiones aprendidas y los cambios del proceso a ser implementado.

● ¿Por qué es esencial la Evaluación?• Porque es importante conocer realmente cuan

cerca se está del deadline, el presupuesto y la calidad alcanzadas.


● Manejo de Cambios• Manejar y controlar el alcance del

proyecto mientras los cambios ocurren en el ciclo de vida del proyecto.

● ¿Por qué es esencial el Manejo de Cambios?

• Sin solicitud de cambios, cómo mantenerpistas de ellos.


● Soporte al usuario• Guía al usuario, guía de instalación y notas de

versión.● ¿Por qué es esencial el Soporte al usuario?

• ¿Qué sucede cuando el usuario tiene unapreguntar o no sabe como usar el producto?.

• ¿Cuán fácil obtiene la ayuda?

Necesidad vs. Soluciónmgoncalves/IS2/sd07/clase5.pdf · 2007-10-03 · “Una condición o...

Documents

Transcript of Necesidad vs. Soluciónmgoncalves/IS2/sd07/clase5.pdf · 2007-10-03 · “Una condición o...