La introducción y los conceptos básicos de Ingeniería ... · básicos de Ingeniería de Sofware ... ¿Cómo haría para solucionar el problema? ... Los requisitos expresan lo que

1

La introducción y los conceptos básicos de Ingeniería de Sofware los vemos una vez el curso esté

más adelantado

Por lo pronto, me interesa darles las herramientas mínimas y necesarias

para comenzar a trabajar en el producto

“Pre-portada” (-3)

2

Ninguna de las ideas expresadas en este curso debe considerarse una verdad absoluta que es aplicable a

todos los escenarios existentes

Por el contrario, la aplicabilidad de estas ideas depende del contexto

en el que se apliquen, del proyecto a desarrollar, del proceso de

desarrollo, etc.


3

Olvide usted que está en un curso de Ingeniería del Software, imagine que tiene a un cliente enfrente, y que este cliente necesita un

software...

Asumo que usted sabe programar al menos.Imagine y describa todo lo que ocurre desde

que usted conoce al cliente hasta que termina el trabajo y le entrega su software

¿Cómo haría para solucionar el problema?


4

¿Cómo haría para solucionar el problema?

Para crear una solución, primero es necesario tener clarotener claro y comprendercomprender el problema...

“Pre-portada” (0)

5

Requisitos / Requerimientos(!Todo lo que el cliente quiere,

exactamente lo que quiere,a como de lugar y a cualquier precio!)

Universidad de los AndesDemián Gutierrez

Marzo 2011

6

Requisitos / Requerimientos

¿Qué es un requisito?

7


Los requisitos expresan lo que el sistema debe hacer para satisfacer las necesidades de sus clientes o

usuarios

“es un aspecto de un sistema o una descripción de aquello que el sistema es capaz de hacer a fin de

cumplir su propósito”[Pfleeger, 1998]

“Un requerimiento es un servicio que el sistema de software debe satisfacer o una restricción bajo la

cual el sistema debe operar”[Sommerville 2002]

Si me lo preguntan, en lo personal, pienso que...

8

...es algo que el sistema debe ser capaz de hacer (o una restricción que debe cumplir) para que pueda cumplir su propósito y satisfacer a

sus usuarios

Un requisito...

9

Lo que el cliente quiere que haga...

Todo lo que el cliente quiere que haga...

Nada más que lo que el cliente quiere que haga...

Los requerimientos se concentran en el cliente y el problema a resolver


Definen (o deberían) sobre el sistema:

10

Es decir, dejen de pensar por los momentos en cómo lo van a programar o implementar...

¡Los requisitos se concentran en “qué”

debe hacer el sistema, no en

“cómo” debe hacerlo!


11

¿Qué Definen los Requisitos?

Las funciones que debe ejecutar

Los datos que debe capturar y

almacenar

La información que debe producir

La interfaz gráfica usuario-sistema (GUI)

La plataforma de operación del sistema (Hardware / Software)

La tecnología de información que debe usar

Las interfaces con otros sistemas

Seguridad, facilidad de uso, documentación,

utilidad, etc.

Aplicación

Interacción Usuario / Sistema

Restricciones de Operación

Atributos de Calidad

Requisitos

12

De Usuario

De Sistema

Tipos de Requisitos

Funcionales

No Funcionales

Dependiendo si definen o no funcionalidad

Dependiendo de a quienes están

dirigidos

¿Qué Tipos de Requisitos?

13

Requerimientos Funcionales / No Funcionales

La funcionalidad o los servicios que se espera que el sistema de software proveerá

La interacción entre el sistema de software y su ambiente o contexto

Como el sistema deberá actuar bajo ciertos estímulos o eventos

Los requerimientos Funcionales Describen:

14


R-010:

El sistema debe permitir el registro de nuevos usuarios en el foro, los nuevos usuarios deben ser aprobados o rechazados

por un moderador antes de poder publicar mensajes

Ejemplos de Requerimientos Funcionales:

R-200:

Los usuarios deben poder intercambiar mensajes y comunicarse por medio del foro, toda la comunicación debe

estar moderada para evitar conductas inapropiadas por parte de los usuarios, mensajes basura y publicidad no deseada

15


No se refieren directamente a las propiedades funcionales del sistema, sino a sus propiedades emergentes o a

restricciones adicionales en el sistema o en el proyecto de desarrollo de software.

Definen restricciones adicionales al sistema, tales como: Proceso de desarrollo a utilizar, herramientas, lenguaje de programación, limitaciones de presupuesto, de tiempo, de

interfaz, etcétera

Los requerimientos no Funcionales:

¿Propiedades Emergentes?

16


Son aquellas que resultan del sistema como un todo y que es muy difícil o imposible atribuirle a un componente particular de

éste.

Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad, capacidad de almacenamiento, etcétera

Propiedades Emergentes:

El todo no siempre es la simple suma de sus partes...

17


R-430:

El sistema debe ser utilizable por medio de una interfaz WEB

Ejemplos de Requerimientosno Funcionales:

R-233:

Se debe utilizar RUP como proceso de desarrollo del software

R-230:

El tiempo de respuesta del sistema al solicitar un reporte nunca debe ser mayor a 10 segundos

18

Clasificación de Requerimientos no funcionales(no interpretar literalmente, es sólo a modo de referencia)

Fuente: Sommerville 2002


19

Tipos de Requisitos (Clasif icaciones)

De Usuario

De Sistema

Tipos de Requisitos

Funcionales

No Funcionales

Dependiendo si definen o no funcionalidad

Dependiendo de a quienes están

dirigidos

20

Requerimientos de Usuario / de Sistema

Requerimientos de Usuario:

Son aquellos que están dirigidos a los usuarios y clientes (interesados en general) del sistema. Se

redactan usando lenguaje natural (generalmente) de forma “no técnica” con el objetivo de que el personal

no técnico los pueda entender

Requerimientos de Sistema:

Son aquellos dirigidos a personal técnico: analistas, programadores, arquitectos, ingenieros, etcétera.

Generalmente están escritos en un lenguaje mucho más técnico pero mucho más preciso que los

requerimientos de usuario

21

Requerimientos de Usuario / de Sistema

Documento de Especificación de Requerimientos (DER)

Es el documento en el que usualmente se especifican los requerimientos de usuario

Documento de Definición de Requerimientos (DDR)

Es el documento en el que usualmente se especifican los requerimientos de sistema

22


Nuevamente...

¿Por qué son importantes los

requisitos?

23

Requisitos

Requisitos incompletos

Falta de participación del usuario

Expectativas poco realistas

Cambios en los requisitos y las especificaciones

El sistema dejó de ser necesario

Se estima que un alto porcentaje de proyectos de desarrollo de software fallan por:

24

Requisitos

Hoy en día la Ingeniería de Requisitos se considera una etapa clave en el

desarrollo de software

Actualmente, se considera que la satisfacción de los clientes es la mejor

métrica de calidad de un sistema

25

El Costo del Cambio (de requisitos)

Fase

Requerimientos 0

1

2

Codificación 3

5

Validación 20

100

Costo($)

DiseñoArquitectónico

DiseñoDetallado

Pruebasde Unidades

Puestaen Marcha /Operación

Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006

26

Más adelante, veremos que hay métodos de gestión y desarrollo de software que hasta cierto

punto desafían este punto de vista...

Sin embargo...

27

¿Por qué t ienen éxito losproyectos de software?

Tomado del Standish Group Report (1995)

¡¡¡Dos de las tres primeras causas están asociadas a los requisitos!!!

Factores de éxito en el Proyecto % Respuestas

1 Usuarios involucrados con el proyecto 15,90%

2 Soporte de los Ejecutivos 13,90%

3 Requerimientos Claros 13,00%

4 Planificación Adecuada 9,60%

5 Expectativas Realistas 8,20%

6 Hitos pequeños y poco espaciados en el tiempo 7,70%

7 Personal competente 7,20%

8 Control sobre el proyecto por parte del personal 5,30%

9 Visión clara y objetivos 2,90%

10 Trabajo duro, personal enfocado y comprometido 2,40%

11 Otras 13,90%

100,00%

Encuesta realizada a Gerentes Ejecutivos del área deDesarrollo de Software y TICs

28

¿Cuáles han sido las mayoresamenazas en un proyecto de software?

Tomado del Standish Group Report (1995)

Nuevamente:¡¡¡Dos de las tres primeras causas están asociadas a los

requisitos!!!


Factores que amenazaron el Proyecto % Respuestas

1 Falta de información de los usuarios 12,80%

2 Especificación de requerimientos incompleta 12,30%

3 Requerimientos y especificación compleja 11,80%

4 Falta de soporte ejecutivo 7,50%

5 Mala tecnología, mal uso de la tecnología 7,00%

6 Falta de recursos 6,40%

7 Expectativas poco realistas 5,90%

8 Objetivos poco claros 5,30%

9 Tiempos de desarrollo poco realistas (planificación) 4,30%

10 Tecnología nueva (desconocimiento) 3,70%

11 Otras 23,00%

100,00%

29Tomado del Standish Group Report (1995)

¡¡¡Nuevamente!!!¡¡¡Dos de las tres primeras causas están asociadas a los

requisitos!!!

¿Por qué fal lan losproyectos de software?

Factores que acabaron/cancelaron el Proyecto % Respuestas

1 Falta de información de los usuarios 13,10%

2 Especificación de requerimientos incompleta 12,40%

3 Falta de recursos 10,60%

4 Expectativas poco realistas 9,90%

5 Falta de soporte ejecutivo 9,30%

6 Requerimientos cambiantes 8,70%

7 Falta de planificación 8,10%

8 El proyecto no se necesito más 7,50%

9 Falta de gestión adecuada de IT 6,20%

10 Problemas tecnológicos 4,30%

11 Otras 9,90%

100,00%


30


Bien... pero...¿Cómo se obtienen

los requisitos?

31

Requisitos

Proceso de establecimiento de los servicios que debe proporcionar un

sistema, así como de las restricciones sobre las cuales debe operar

Ingeniería => Enfoque Sistemático

¿Ingeniería de Requisitos?

32

Procesos de la Ingeniería de Requisitos

Captura Análisis ValidaciónEspecificación

Una visión:

Otra visión (Según Pfleeger):

... y hay otras...(ver Sommerville cap. 6 / Pressman cap. 7)

Análisisdel

Problema

Descripcióndel

ProblemaPrototipado

Documentacióny Validación

Elicitación y Análisis Definición yEspecificación

33


Es la actividad por medio de la cual se obtienen (capturan) los requerimientos

ObservaciónDirecta

EntrevistasModelo deNegocios

Lectura /Análisis de

DocumentosOtras...Prototipos


34


¿Quién está detrás de la solicitud de este trabajo? (Clientes)

¿Quién usará la solución? (Usuarios)

¿Cuál será el beneficio económico de una solución exitosa?

¿Existe otra fuente para la solución requerida?

Tomado de Pressman 2005 / cap 7

35


¿Cómo podría caracterizarse un buen resultado generado por una solución? (¿Cómo sé que una

solución es buena?)

¿Cuáles problemas debería atacar la solución?

¿Podría usted mostrar o describir el ambiente de negocios en el que se utilizará la solución?

¿Hay aspectos o restricciones especiales del rendimiento que afecten la manera de enfocar la

solución?


36


En este punto, cuando el cliente ya está hablando, uno se transforma en “pepito

preguntón”:

¿Por qué?¿Y por qué?

¿Qué es esto?¿Y esto otro?

¿Cómo hacen esto?¿Y esto otro?

¿Quién hace esto?...

Opinión personal

37


¿Es usted la persona adecuada para contestar esta pregunta? ¿Sus respuestas son oficiales?

¿Mis preguntas son relevantes para su problema?

¿Estoy haciendo demasiadas preguntas?

¿Alguien más puede proporcionar información adicional?

¿Debería preguntarle alguna otra cosa?


38


¿Cómo se soluciona el problema actualmente?

¿Entre que bandas de costos se debería mover una solución para ser rentable?

... otras de seguro ...¿Se le ocurre alguna?

Opinión personal

39


Recuerde:

Una vez que comprenda algo, repitalo al cliente con sus propias

palabras, y si éste lo entiende, entonces usted estará seguro de que

lo ha entendido correctamente

Opinión personal

40


Consejo:Nunca vaya a una reunión de negocios o a una entrevista de requerimientos sólo.

¡Dos es un número mágico!¿Por qué cree usted que esto es así?

Consejo:Tome notas / grabe la entrevista de ser posible, y mantenga las grabaciones

para futuras referencias

Opinión personal

41


Es la actividad por medio

de la cual se extiende el

modelo de requisitos, se

buscan y localizan

errores, inconsistencias,

limitaciones, carencias,

etcétera...

Discusiones,Entrevistas,

Talleres

Inspeccionesde Documentos

Muchas de lastécnicas de la actividad

de captura

Desarrollo deprototipos


42



Es la actividad por medio de la cual se documentan (escriben / se ponen en “blanco y

negro”) los requerimientos

Documentode Definición deRequerimientos

Documentode Especificación de

Requerimientos

¡Si los requerimientos no están por escrito(de alguna manera), entonces NO SIRVEN!

43



Es la actividad por medio de la cual se VALIDAN los requerimientos con el cliente

Discusiones /Entrevistas /

Talleres

Inspeccionesde Documentos

Muchas de lastécnicas de la

actividadde captura

!Esta actividad es crítica. Si los requerimientos no se han validado, entonces NO SIRVEN!

44


¿Quiénes participan en la Ingeniería de Requerimientos?

45

Participantes en el Desarrol lo de Software

CLIENTE /EJECUTIVO /

USUARIO (Patrocina el desarrollo del

sistema y utiliza el sistema)

DESARROLLADOR(Construyeel Sistema)

¿Seránel cliente y

el usuario lo mismo en todos

los casos?

46


CLIENTEEJECUTIVOS(Patrocina el

desarrollodel sistema)

USUARIO(Utiliza elSistema)


TieneObligacionesContractuales

ProporcionaFinanciamiento

ProporcionaSistemas de

Software

TieneNecesidades

Pfleeger(1998)

47


Clientes

Usuarios

Otros entes, personas,

instituciones, afectadas o

interesadas en el sistema


Otros desarrolladores y participantes en el

proyecto

A todas las personas

involucradas o interesadas se

les llama Stakeholder

48

Interesados / Actores / Protagonistas(Stakeholders)

Líderes deproyecto

diseñadores

InstitucionesGubernamentales

Gerentes

analistas

Consultores /asesores

EmpresaContratante

Usuarios

programadores

Consumidores

Clientes

arquitectosClientes dela Empresa

Proveedores

Comunidad

49


¿ProblemasCon los Requisitos?

¡Dilbert!

50

Requisitos (Problemas de los)

¡Para poder desarrollar software senecesitan usuarios, comprometidos,

disponibles (e involucrados en el desarrollo)!

51


El cliente / usuario no siempre sabe o tiene claro lo que quiere

El cliente / usuario no se compromete con el proyecto

Se dan malas interpretaciones en los requerimientos¿Ha jugado usted alguna vez al “telefonito”?Usuario -> Cliente /Ejecutivo -> Analista ->

-> Especificación -> Diseño -> Implementación -> Usuario

Los requisitos cambian constantemente(El cliente / usuario cambia de idea constantemente)

Fenómeno del “analista sabelotodo”: El analista cree que sabe que es lo que necesita el cliente y por lo tanto no le consulta

52


El cliente / usuario no entiende a los analistas(Lenguaje técnico del analista)

Los analistas no entienden al cliente / usuario(Lenguaje asociado al dominio del cliente / usuario)

¿Qué es el dominio del cliente?¿Dominio de aplicación?

Requisitos que: No reflejan las necesidades reales del cliente, son inconsistentes, incompletos, no factibles, etcétera

Requisitos que el cliente no necesita realmente

53

Requisitos (Tres Leyes)(Según Demián Gutierrez)

Primera Regla:El usuario siempre tiene la razón

(Aunque se le puede intentar convencer de lo contrario)

Segunda Regla:El cliente siempre tiene la razón, siempre y cuando esto no

contradiga lo establecido en le primera regla

Tercera Regla:Usted (el desarrollador) tiene la razón, siempre y cuando esto

no contradiga la segunda o la primera regla

¿Conoce usted las tres leyes de la robótica de Asimov?

54

¡Ley Cero!

Ante la duda, siempre consulte al usuario / cliente involucrado

¡Nunca dé nada por sentado!

Requisitos (Tres Leyes)(Según Demián Gutierrez)

55


¿Cómo se documentan los

requisitos?

56

¿Qué necesito saber / definir sobre un sistema?

Los involucrados

Los objetivos de negocios que se desean satisfacer con el sistema (esto viene del modelo de negocio del cliente)

La visión general del sistema¿Usted qué cree?

El propósito del sistema¿Para qué lo necesito?

Los objetivos del proyecto(y como mido si se cumplieron o no)

Fundamentado en base a la plantilla Volere, edición 14, Enero 2009

57


Otros hechos relevantes

El alcance del proyecto

El alcance del producto

Los requisitos (evidente)Y los hay de muchos tipos (ver la plantilla Volere)

Restricciones impuestas (por el cliente o el entorno)


58


Ideas de posibles soluciones

Riesgos (Ojo, algunos tratan la “gestión de riesgos como algo completamente aparte y distinto)

Soluciones ya existentes

Costos estimados (Valoración inicial)

Otros aspectos


59

¿Cómo se definen los requerimientos?Descripciones en Lenguaje Natural

Usted tiene que desarrollar un sistema de software para la “Policía del Estado Mérida”.

Entre los requerimientos, hay un proceso que consiste en la gestión de las armas ymuniciones de la armería de la policía. El proceso contempla la entrega de armas a losagentes policiales, la devolución de las armas al parque, las pruebas y validaciones de leyque se realizan a las armas después de la entrega y finalmente, cualquier proceso deinvestigación posterior en caso de que el armamento haya sido disparado.

Después de conversar con el comisario sobre el funcionamiento del proceso en discusión, sepuede resumir la conversación de la siguiente forma:

Es necesario un proceso que sirva para gestionar la entrega de armamento del parque dearmas a los “Agentes Policiales”. En general, los Agentes se presentan al “Encargado delParque de Armas” y solicitan cierto armamento. El Encargado del Parque busca elarmamento solicitado en el inventario y si éste se encuentra disponible se lo entrega alAgente. Si el armamento no se encuentra disponible el proceso termina. La entrega ocurresólo luego de que el Agente llene y firme una “Planilla de Retiro de Armamento”. Laplanilla tiene información sobre la fecha en que se entrega el arma al Agente, el serial delarma y la cantidad y tipo de munición entregada. Luego de llenar la planilla, el Encargadoentrega el arma y las municiones al Agente, quien debe revisarlas y poner en la planillacualquier observación o desacuerdo que corresponda al estado de las mismas en caso de sernecesario.

60

¿Cómo se definen los requerimientos?Listas de “Features” (Características)

61


62


63

Discusión

¿Qué ventajas / desventajas tendrán las listas de “Features” sobre las descripciones

textuales en lenguaje natural?


64

¿Cómo se definen los requerimientos?Planti l las para Definir Requerimientos

Tomado de la plantilla Volere, edición 14, Enero 2009

65

# deRequisito:

045 Tipo deRequisito:

Funcional Caso deUso / EventoRelacionado:

054

Descripción: Los usuarios deben poder intercambiar mensajes y comunicarse pormedio del foro, toda la comunicación debe estar moderada paraevitar conductas inapropiadas por parte de los usuarios, mensajesbasura y publicidad no deseada.

Justificación: Esta es la razón de ser del sistema, el objetivo principal de un foroWEB es permitir intercambiar mensajes entre usuarios.

Origen(Interesado):

Pedro Moreno

Criterio deAceptación /Validación:

El usuario debe poder publicar un mensaje.El mensaje no debe aparecer hasta que un moderador lo acepte.Si un moderador acepta el mensaje entonces éste aparece publicado.Si un moderador rechaza el mensaje entonces éste no es publicado.

Nivel desatisfacción delInteresado:

5 Nivel deinsatisfacción delInteresado:

5

Prioridad: 5 Requisitos enConflicto:

055, 034, 040

Material deSoporte:

ÚltimaModificación:

Modificado 15/08/2009 – Gloria LinaresCreado 12/02/2009 – Luis Gutierrez

Ejemplo de un requisito del foro WEB


66

Planilla VOLERE para Documentación de Requisitos

Identificador del Requisito: 45

Tipo de Requisito: Funcional Caso de Uso/Evento: 4.2.1

Descripción: Calcular el promedio diario, mensual y anual de precipitación en cada una de las estaciones climatológicas del país Justificación del requisito Es necesario para elaborar los reportes diarios, mensuales y anuales de precipitación.

Fuente (que interesado lo propone): Juan Peña

Unidad en la que se origina: División de Climatología

Criterios de validación: Los valores obtenidos se compararán con los obtenidos en años pasados para determinar si hay inconsistencias. Grado de satisfacción del interesado: 3

Grado de insatisfacción del interesado: 5

Dependencias (qué requisitos depende de este):35, 48

Conflictos (qué requisitos son incompatibles o inconsistentes con este):

Documentos de soporte: Manual de Precipitación

Histórico de cambios: 20-Mayo-2006

Proyecto: Sistema de Información Climatológica Analista: Julia Monsalve

Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006Ejemplo con algunas modificaciones de la plantilla Volere


67

Recuerde siempre, que los requerimientos se pueden “priorizar”, es decir, algunos requerimientos

siempre serán mas importantes para el cliente o más críticos para el negocio que otros

En función de estas prioridades se puede decidir cuales requerimientos entregar, cuales no y así jugar con los costos y los tiempos de desarrollo (afectando lo menos posible la satisfacción del cliente / usuario)


68


Cuadro Resumen de Requerimientos(índice, importante)

69

Plantillas Volere*http://www.volere.co.uk/

*Gracias a James Robertson de Atlantic System Guild por facilitame una copia gratuita de las plantillas para uso académico

MeRinde**http://merinde.rinde.gob.ve/

**MeRinde es más que un grupo de plantillas de apoyo, es una metodología de desarrollo de software basada en el Proceso Unificado (UP)

IEEE Std 830-1993http://standards.ieee.org/reading/ieee/std_public/description/se/830-1993_desc.html

¿Otras? Sin duda alguna...


http://www.volere.co.uk/

http://merinde.rinde.gob.ve/

http://standards.ieee.org/reading/ieee/std_public/description/se/830-1993_desc.html

Historias de Usuarios(Modelos ágiles – XP, SCRUM)

Los requisitos del producto se capturan teniendo en cuenta la visión del cliente y del usuario

Se recoge en unas sencillas tarjetas de forma esquemática y en un lenguaje claro QUÉ una historia

que describe una interacción entre el usuario y el sistema

Generación de Factura

El usuario introduce la información del cliente. Si el cliente ya está registrado con sólo introducir la cédula se deben cargar sus datos. Luego se ingresan los elementos a facturar y las cantidades de cada elemento.Finalmente el sistema registra la factura y es capaz de imprimirla en la impresora local asociada al terminal del usuario

Historias de Usuarios(Modelos ágiles – XP, SCRUM)

Las historias de usuario sirven de “recordatorio” de una un grupo de características que es necesario

implementar en el sistema.

Antes de implementar la característica se produce una discusión con el usuario, se refina y extiende la

información de la historia de usuario

Generación de Factura

El usuario introduce la información del cliente. Si el cliente ya está registrado con sólo introducir la cédula se deben cargar sus datos. Luego se ingresan los elementos a facturar y las cantidades de cada elemento.Finalmente el sistema registra la factura y es capaz de imprimirla en la impresora local asociada al terminal del usuario

72

Caso de Uso

Actor

Generalización / Especialización

de Actores

Límites delSistema

Colaboración entre casos

de uso

AsociaciónCaso de

Uso / Actor

¿Cómo se definen los requerimientos?Lenguajes / Notaciones Gráficas

73

Lenguajes / Notaciones Gráficas.. .. . . y su respectiva descripción textual

Nombre: Crear mensaje foro

Autor:

Fecha: 21/04/09

Descripción:

Permite crear un nuevo mensaje (hilo) en el foro de discusión.

Actores:

Usuario / Moderador

El usuario debe de estar autenticado en el sistema.

Flujo Normal:

Flujo Alternativo:

El mensaje ha sido almacenado en el sistema y fue publicado.

Pedro Pérez

Precondiciones:

1.- El actor pulsa sobre el botón para crear un nuevo mensaje.2.- El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje.3.- El actor introduce el título del mensaje y el cuerpo del mismo.4.- El sistema comprueba la validez de los datos y los almacena.5.- El moderador recibe una notificación de que hay un nuevo mensaje.6.- El moderador acepta y el sistema publica el mensaje si éste fue aceptado por el moderador.

4.A.- El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole que los corrija.

6.B.- El moderador rechaza el mensaje, de modo que no es publicado sino devuelto al usuario.Poscondiciones:

74

Discusión

¿Cual es la diferencia entre la plantilla anterior (Caso de Uso), una Historia de Usuario y la

ficha Volere para definir requerimientos?

(Ademas de las diferencias evidentesde formato y campos)


75

¿Cómo se definen los requerimientos?Lenguajes Formales

Ejemplo de “Notación Z”

No cuenten conmigo... (opinión personal)

76

Otros...

Muchas veces la diferencia entre los requerimientos y el diseño (o el modelo de

análisis en RUP) no resulta lo suficientemente clara

(El qué con el cómo)

¿Cómo se definen los requerimientos?

77

Gestión de Requerimientos

¿Cómo se pone orden en los

requerimientos?¿Gestión de

requerimientos?

78


¿Qué usuario definió qué requerimiento?

¿Qué requerimientos satisfacen qué objetivos de negocio?

¿Qué requerimiento afecta a qué otro requerimiento?

¿Dónde están diseñados e implementados los requerimientos?

79


¿Qué sucede si un usuario quiere cambiar un requerimiento?

¿Cómo se manejan los cambios, cuál es el proceso para manejar los

cambios?

...etcétera

80


Interesados

Objetivos del Negocio

(O1, O2, O3...)

R1

R2

R3

Requisitos Casos de Uso

CU1

CU2

CU3

CU4

CU5

Diseño,Componentes

Implementación,Pruebas

X1

X2

X3

X4

X5

X6

X7

...

¿Seráimportante

también tenertrazas

con losdesarrolladores?

¿Por qué?

81

Gestión de RequerimientosEjemplo de una matriz de rastreo

R1 R2 R3 R4 R5 ...R1 XR2 X XR3 X XR4 X XR5 X X

...

X X X

Rn

RnU1 U2 U3 U4 U5 ... Un

R1 XR2 X X XR3 X X R4 X X R5 X X X

...

X X XRn

Requerimientoscon

Requerimientos(Dependencias /

Conflictos)

Requerimientoscon

Interesados

82

Requerimientos con Casos de Uso

Requerimientos con Objetivos de Negocio

Casos de uso con “artefactos” u otros componentes en diseño ...(Gestión de Configuración)

Cualquier otra cosa en la que sea necesario tener trazas o poder rastrear

¿qué va con qué? ¿qué me influencia a qué?


83

Herramientas para hacerGestión de Requerimientos*

CaliberRM (Borland) (Propietario)http://www.borland.com/us/products/caliber/index.html

DOORS (IBM / Rational) (Propietario)http://www-01.ibm.com/software/awdtools/doors/productline/

IRQA (Visure) (Propietario)http://www.visuresolutions.com/

*Requirements Management

84

Herramientas para hacerGestión de Requerimientos*

RMTOO (Flonatel GmbH & Co. KG.) (Libre)http://www.flonatel.de/projekte/rmtoo/

*Requirements Management

¡Si alguien consigue otra buena herramienta en software libre me avisa!

85

Calidad de los Requisitos

¿Cómo sé que tengo requisitos de calidad?

86


Se expresan de manera cuantitativa (Los NF)(No diga que algo debe ser rápido; mejor diga qué

tan rápido debe ser)

Cada requisito debe identificarse de manera única e inequívoca (Uso de un sistema de numeración)

Deben ser correctos y validados por el cliente(muy importante)

Los requisitos se expresan de una manera sencilla, clara y sin ambigüedades

87


Deben ser completos (deben describir todos los estados, entidades, entradas y salidas posibles)

¿Cómo sé que son completos?

Deben ser realistas o alcanzables(Soñar no cuesta nada... ¡pero hacer realidad los

sueños puede llegar a salir muy caro!)

Deben ser consistentes entre sí(No debe haber conflictos o

incompatibilidad entre requisitos)

88


Se les debe poder puede hacer un seguimiento(Deben estar organizados)

Deben ser verificables(medibles y sin ambigüedad, ¿se implementó o no?)

Deben estar redactados en un lenguaje correcto, simple, sencillo y contundente

(no está escribiendo una novela o un poema)

Deben describir algo que cliente o usuario necesita( resuelven los problemas del cliente¿que sentido tiene si no lo hace? )

89

Gracias

¡Gracias!

Documents

La introducción y los conceptos básicos de Ingeniería ... · básicos de Ingeniería de Sofware ... ¿Cómo haría para solucionar el problema? ... Los requisitos expresan lo que