Transcript clase3 - Facultad de Ingeniería

Ingeniería de Software
Clase 3
Ingeniería de Requerimientos
(Toma, modelado, comunicación,
aceptación y mantenimiento)
Contenido Clase 3

Obtención de requerimientos






Técnicas tradicionales
Entrevistas y cuestionarios
Escenarios y casos de uso
Aproximación cognitiva
Aproximación contextual
Modelizando Empresas y
metas






Por que modelar  motivos
Tipos de modelo
Esquema conceptual
Diferentes modelos
conceptuales
Requerimientos no
funcionales
UNPSJB - 2005
Modelizando el comportamiento
funcional


Modelizar funcionalidad
Evolución del Análisis



AE
AOO
Técnicas formales


Especificación vs. Modelado de
requerimientos
Algunos ejemplos
(investigación)
 SCR


Ingeniería de Software - Clase 3
RML
RSML
2
Contenido Clase 3 (cont.)

Comunicando
requerimientos




UNPSJB - 2005
SRS (soft
requeriment
Specification)
Ambigüedades y
como evitarlas
Estándares
Trazabilidad de
requerimientos

Validación de
requerimientos




Usos filosóficos
Revisiones e inspecciones
Prototipación
Aceptando los
requerimientos


Negociación ante problemas
Solución de conflictos
Ingeniería de Software - Clase 3
3
Contenido clase 3 (cont.)

Evolucionando requerimientos




UNPSJB - 2005
Administración del cambio
Administración de inconsistencia
Rasgos de interacción
Familias de productos para Administración
de requerimientos
Ingeniería de Software - Clase 3
4
Contenido Clase 3

Bibliografía utilizada




UNPSJB - 2005
Ingeniería de Requerimientos
(Locoupulous)
Ingeniría de Requerimientos (Davis)
Ingeniería de software (Pressman,
Sommerville)
Papers Varios
Ingeniería de Software - Clase 3
5
Toma de Requerimientos

Punto de comienzo

Alguna notación que indique que hay un
problema que necesita resolverse
Oportunidad de negocios
 Necesidad de mercado
 Utilización de recursos



El Ing.Requerimientos debe

UNPSJB - 2005
El Ing. de requerimientos es una agente
del cambio
Identificar el problema / oportunidad
Ingeniería de Software - Clase 3
6
Toma de Requerimientos
Cual problema necesita ser resuelto? (identificar
límites)
 Donde está el problema? (el contexto o el dominio
del mismo)
 A Quienes involucra el problema? (identificar los
actores)
 Por qué necesita resolverse? (identificar las metas
de los actores)
 Como debería ayudar el soft? (tomar o colectar los
escenarios posibles)
 Para cuando debe estar resuelto? (identificar
limitaciones de desarrollo)
 Qué debemos tener en cuenta para resolverlo?
(identificar riesgos).
Adquirir suficiente conocimiento
Convertirse en un experto del dominio del problema

La técnica de
las 6 W:
What?
Where?
Who?
Why?
When?
How (Which)?


UNPSJB - 2005
Ingeniería de Software - Clase 3
7
Los cuatro mundos
Como el
sistema utiliza la
información
sobre el dominio
de la aplicación
Mundo del
sujeto
Mundo del
uso
Interfases de
usuario
Justificar las
metas de
desarrollo
Mundo del
desarrollo
UNPSJB - 2005
Ingeniería de Software - Clase 3
Como la máquina
representa
inforamción sobre el
dominio de
aplicación
Mundo del
sistema
Desiciones de
diseño
8
Dificultades para la adquisición

Criterios para definir el dominio del
conocimiento



Conocimiento tácito

UNPSJB - 2005
El conocimiento puede estar distribuido a lo largo
de muchos recursos
 Generalmente no está descrito en forma explícita
Puede existir conflicto entre diferentes fuentes
 Las metas pueden no ser las mismas entre
distintas personas
 Las personas pueden tener diferentes criterios para
entender un problema
Las personas encuentran difícil decir que necesitan
o complican mucho la explicación
Ingeniería de Software - Clase 3
9
Dificultades para la adquisición

Problemas en la comunicación

La gente puede estar imposibilitada para
decir lo que realmente necesita


Problemas políticos o de seguridad
La gente puede no querer decir que es lo
que necesita
Si digo algo luego quedo “pegado”
 “Si abro mi negocio y otro se entera pierdo”

UNPSJB - 2005
Ingeniería de Software - Clase 3
10
Técnicas para toma de requerimientos

Técnicas tradicionales

Introspección






UNPSJB - 2005
Mirar hacia dentro del
problema
Documentos existentes
Análisis de datos
Entrevistas



Agenda abierta
Estructuradas
Cuestionarios
Adquisición en grupos




Grupos enfocados
Brainstorming
JAD/RAD
Prototipación
Aproximación basada en
representación



Ingeniería de Software - Clase 3
Basada en objetivos
Basada en escenarios
Basadas en casos de
uso
11
Técnicas para toma de requerimientos

Aproximación
contextual (social)



UNPSJB - 2005
Técnicas etnográficas
 Observación de
participantes
 Etnometodología
Análisis de discurso
 Análisis de
conversación
 Análisis de
presentación
Diseño participatorio

Aproximaciones
cognitivas



Análisis de tareas
Análisis de protocolos
Técnicas de adquisición
de conocimiento



Ordenamiento de
tarjetas
Grillas de repertorio
Técnicas de escalado
de proximidad
Etnografía: ciencia que tiene por estudio y descripción de las
razas o pueblos, como también su lengua, sus creencias,
artesanías,
usos,
costumbres
Ingeniería
de Software
- Clase 3y formas de vida
12
Cuestionarios

Ventajas





Puede obtener información
rápidamente de muchas
personas
Puede administrarse
remotamente
Puede obtener actitudes y
características de los actores
Desventajas

Qué mirar?




Puede obtener un contexto
muy pobre del problema

UNPSJB - 2005
No hay entrevistas con
usuarios

Tendencias en la selección
de ejemplos
Tendencias en la selección
de respuestas
Ejemplos de tamaño chico
(con poca significancia
estadística)
Preguntas ambiguas
(muchos que no contestan la
misma pregunta)
El cuestionario debe ser
testeado
Ingeniería de Software - Clase 3
13
Entrevistas

Tipos

Estructuradas


Agenda abierta, no
hay temarios previos
Ricas en adquisición de
información
Desventajas

UNPSJB - 2005


Difícil la comparación de
respuestas
Administrar las
entrevistas no es una
tarea sencilla
Que mirar?

Ventajas


Existe una agenda
previa con temarios
Libres






Muchos datos
cualitativos difíciles de
analizar
Ingeniería de Software - Clase 3
Preguntas sin
respuestas
Conocimiento tácito
El contexto de discusión
Actitud de los
entrevistados respecto
de los temas abarcados
14
Técnicas de adquisición en grupo

Tipos




JAD o RAD
Enfoque en grupo
Brainstorming


Ventajas


Interacción más natural
entre la gente, mayor a
una entrevista formal
Se puede medir la
reacción ante material
de estímulo

Presentaciones,
maquetas, etc.
Desventajas




Que mirar?


UNPSJB - 2005
Puede crear grupos poco
naturales y hacer sentir
incómodos a los participantes
Peligro de llevar a una opinión
de grupo que no sea real
Pueden obtenerse respuestas
superficiales a cuestiones
técnicas
Se requiere de un facilitador
muy entrenado
Tendencias en los ejemplos
Dominancia y submisión
Ingeniería de Software - Clase 3
15
Colección de “datos complejos”

Identificar los grupos de
estos datos





Hechos y figuras,
información financiera, etc.
Reportes usados para toma
de decisiones,...
Resultados obtenidos,
información de marketing,..



Ejemplos

UNPSJB - 2005
Obtener datos
representativos del
conjunto de la población de
elementos

Ejemplos propuestos  tomar
aquellos considerados más
relevantes
Ejemplos aleatorios  tomar
cada n casos
Ej. Aleatorios por capas 
identificar capas del problema
y tomar un caso de cada uno
Ej. Aleatorios por cluster 
generar subconjuntos
relacionados y tomar un
ejemplo de él.
Tamaño del ejemplo

Balancear entre costo y
relevancia del ejemplo
Ingeniería de Software - Clase 3
16
Casos de uso

Que es un caso de uso?




UNPSJB - 2005
Cada forma diferente en que un actor interactúa
con el sistema
 Una descripción de una secuencia de acciones que
el sistema debe llevar a cabo para obtener un
resultado observable para un actor particular
[Booch]
 Todos los casos de uso deben ser numerados
Una descripción de un conjunto posible de
escenarios, con un propósito común
Se escriben, generalmente, en lenguaje natural
No hay descripción interna del sistema, solo la
interacción con el mismo
Ingeniería de Software - Clase 3
17
Casos de uso

Ventajas y desventajas




UNPSJB - 2005
Caracterización detallada de todas las posibles
interacciones con el sistema
Ayuda en el dibujo de los límites del sistema, y
con el alcance de los requerimientos
Los casos de uso no captura en dominio del
conocimiento
Un caso de uso no es especificación precisa, solo
es la representación de un problema puntual
Ingeniería de Software - Clase 3
18
Usando Casos de uso

Dibujar los límites


Identificar los actores  Para cada caso de uso
 Escribirlo
fuera de los límites del
sistema que
 Especificar reglas para
elección del mismo y para
interactúan con él
interacturar con él
Para cada factor
 Considerar alternativas
 Identificar los
 Ver posibles superposiciones
posibles casos de uso
de casos de uso


UNPSJB - 2005
Establecer escenarios
concretos para
ilustrar cada caso de
uso
Agrupar escenarios
similares en casos de
uso si son una
variación sobre un
tema
Ingeniería de Software - Clase 3
Template de caso de uso:
Nombre:
Resumen:
Actores:
Precondiciones:
Descripciones:
Excepciones:
Postcondiciones:
19
Un ejemplo de caso de uso



Nombre: Orden de pedido
Precondición: un usuario válido está conectado al sistema
Descripción:











Excepciones:


El caso de uso comienza con un pedido del cliente
El cliente entra su nombre y dirección
Si el cliente entra solo el código postal, el sistema debe agregar la ciudad y la
provincia.
El cliente entrará todos los código de los productos deseados y la cantidad
solicitada
El sistema indicará el nombre del producto y el precio unitario del mismo
Cliente
El sistema totalizará la cantidad de productos pedidos y el total de la venta
El cliente indicará la forma de pago, si es tarjeta el número de la misma
El cliente apretará la tecla enviar
El sistema verificará la información, guardará la orden de pedido como
pendiente y la forma de pago
Una vez confirmado el pago, la orden se cambiará a confirmada y se le indica
esto al cliente, el caso de uso finaliza
Tomar Estado
Enviar catálogo
Cancelar orden
Delivery
Enviar producto
En el paso 9, si hay información incorrecta, el sistema le preguntará al cliente
que quiso poner
Postcondiciones:

Orden de pedido
La orden fue salvada en el sistema y fue marcada como confirmada
UNPSJB - 2005
Ingeniería de Software - Clase 3
Re-Adquirir
producto
Proveedor
20
Escenarios

Definición



Secuencia específica de
interacciones entre
actores y sistemas
Tienden a ser cortos
Puede sen




Positivos
(comportamiento
requerido)
Negativos (interacción
no deseada)
Pueden estar en modo
indicativo u optativo
UNPSJB - 2005
Ventajas



Muy natural: se tratan
de usar de manera
expontánea
Los escenarios cortos
son muy buenos para
ilustrar interacciones
específicas
Desventajas

Falta de estructuración:
se necesitan casos de
uso o modelo de tareas
para proveer una visión
de alto nivel.
Ingeniería de Software - Clase 3
21
Modelado de tareas y Escenarios

Modelado de tareas:


Conjunto jerárquico de
actividades estereotípicas
Los subojetivos son
tareas (o casos posibles
de uso)



Escenarios


Son caminos a través del modelo
de tareas, tomando una secuencia
específica en tiempo de pasos
Puede ser usado para organizar
requerimientos
Puede incluir paralelismo
Pueden ocurrir en

secuencia, en paralelo o  Excepciones
como alternativas
 Son variantes de casos de uso
Pueden ocurrir
 No pueden ser modeladas como
periódicamente o en
escenarios en si mismo,
respuesta a
interactúan con múltiples
contingencias.
escenarios
UNPSJB - 2005
Ingeniería de Software - Clase 3
22
Aproximación basada en metas

Aproximación




Se enfoca en por que se
construye el sistema
Se expresa el por que como
un conjunto de metas
Se usa refinamiento de metas
para arribar a requerimientos
específicos
Análisis de metas


Documentos, organización y
clasificación de metas

Ventajas



Desventajas

Evolución de metas

UNPSJB - 2005
Razonablemente
intuitivo
La declaración explícita
de metas provee una
base para la solución de
conflictos
Difícil de seguir la
evolución
Refinar, elaborar y poner
operativos
Ingeniería de Software - Clase 3
23
Usando aproximación basadas en metas

Metas


Especificación de cómo una meta
debe estar en un nuevo sistema
Tipos




Objetivos de alto nivel de un
negocio u organización
Requerimiento



Metas de realización
Metas de mantenimiento
Metas soft

Consejos



Obstáculos y limitaciones

Los obstáculos son
comportamientos que
previenen la realización de
una meta dada
UNPSJB - 2005
Las limitaciones son condiciones
sobre la realización de una meta

Las metas se obtienen mejor de
múltiples fuentes
Asociar actores a cada meta
(revela puntos de vista y
conflictos)
Usar escenarios para explorar
como los objetivos pueden ser
alcanzados
Consideraciones explícitas sobre
obstáculos puede ayudar a
construir o definir excepciones.
Ingeniería de Software - Clase 3
24
Técnicas adquisición de conocimiento

Base:




La toma de
conocimiento está
ligada con el
descubrimiento
“experto” de
conocimiento
Ligado con el
crecimiento de los
sistemas expertos
Métodos formales
Problemas de modelado



Es muy frágil,
para pequeños casos
de uso
Problema de
representación


Inadecuado
epistemológicamente
Expresividad vs.
Facilidad de adquisición
KE es dura

UNPSJB - 2005

Separar el dominio del
conocimiento de la
performance del
conocimiento
Ingeniería de Software - Clase 3
25
Por que KE es tan difícil??

Expertos no se utilizan para
describir que hacen

Problemas de representación

Hay tres pasos para modelar el
aprendizaje





Cognitivo (descripción verbal
de las tareas)
Asociativo (reforzar las ideas
con repeticiones de dichos
verbales)
Autónomo (compilado, no son
concisos)
Los mecanismos procedurales y
declarativos son diferentes

El conocimiento declarativo se
torna procedural con
aplicación repetida, los
expertos no pueden hacer
esto fácilmente
UNPSJB - 2005
Los expertos no tienen un
lenguaje para describir el
conocimiento



Los lenguajes hablados no
tiene la suficiente precisión
diferentes representaciones de
conocimiento son buenas para
cosas diferentes
Ventaja

El conocimiento se crea, no se
extrae



Ingeniería de Software - Clase 3
Son abstracciones de la
realidad
Se crea través de
suposiciones simples
Tiende a tener menos errores
o problemas
26
Expresividad vs. Facilidad de adquisición

Son objetivos opuestos



UNPSJB - 2005
Lo más expresivo es más difícil de adquirir
y viceversa
Ej
 Las interfases con reglas de inducción son
fáciles de adquirir pero poco expresivas
 La lógica de un programa es muy
expresiva pero difícil de adquirir
La representación ideal intenta combinar lo
mejor de cada una
Ingeniería de Software - Clase 3
27
El nivel del conocimiento
Ver el modelado del
conocimiento como:


Actúa como si tuviera
conocimiento sobre el
ambiente que utiliza
Construir dos modelos


UNPSJB - 2005
Nivel simbólico: descripciones
del mecanismo del
comportamiento
Nivel de conocimiento:
descripciones del
conocimiento del agente del
mundo real
racionalización
Observar el comportamiento de
un agente como una caja negra
Ambiente
Observación
Observador
(modelador)
Agente
Ingeniería de Software - Clase 3
mecanizado

Modelo el nivel
de conocimiento
Comportamiento

Modelo de nivel
de símbolos
28
Algunas técnicas de toma de conocimiento

Análisis de protocolo


Basadas en vocalizar el
comportamiento
Ventajas






Forma verbal de las
actividades cognitivas
Dentro del contexto
No tienen dimensión social
Basada en introspección
Técnicas de escala de
proximidad


Desventajas



Dado un dominio, derivar un
conjunto de dimensiones para
clasificarlo
Ventajas:
UNPSJB - 2005
Desventajas



Ayuda a construir modelos
mentales,
Pueden adquirir conocimiento
tácito
Requiere una aceptación del
conjunto de objetos
Difícil de lograr
Ordenamiento de tarjetas


Para un conjunto de objetos de
dominio escribirlos en tarjetas para
ordenarlas en grupos
Ventajas


Simple y fácil de automatizar
Desventajas

Las entidades necesitan ser
identificadas dentro de semánticas
a lo largo del dominio
Ingeniería de Software - Clase 3
29
Abstracción vs. contextualismo

Abstracción:


Construye modelos
abstrayéndolos del dominio,
el modelo puede contestar
preguntas
 Decidir sobre la ontología
Contextualismo



UNPSJB - 2005
Se asume que el
conocimiento y el
entendimiento son
independientes del contexto
Utilizado normalmente por
científicos naturales e
ingenieros
Pone énfasis en los
detalles e idiosincrásia
del dominio

del fenómeno que se quiere
describir



Ontología: parte
de la metafísica,
que estudia el ser
en general y sus
propiedades
trascendentales
Obtener datos
naturales del dominio
de estudio
Usar los datos para
dar explicaciones
Asume que es imposible
construir modelos que
tengan comportamiento
cuando se remueven
del contexto
Usado por muchos
científicos sociales
Ingeniería de Software - Clase 3
30
Visión etnometodológica

La toma de requerimientos es
una actividad social




Porque involucra comunicación
entre personas (discusiones,
observación de la realidad, etc)
Porque involucra negociación
para lograr consensos
Porque afecta y cambia los
sistemas de actividad humana
El dominio de una aplicación es,
gralmente, un mundo social

Se necesitan técnicas que cubran el
orden del mundo social




Es construido a partir de acciones
de los participantes
No se puede tomar información de
categorías preestablecidas
Se necesita considerar


UNPSJB - 2005
Este puede no ser obvio o
describible
No se puede asumir con estructura
previa
El mundo social solo puede
entenderse si uno se mete en él


Etnología: ciencia que
estudia el origen, la
distribución y los
caracteres físicos de las
razas humanas
Como los significados se
desarrollan y evolucionan en el
contexto
Los métodos públicos utilizados
para que el contexto tenga sentido
Ingeniería de Software - Clase 3
31
Etnometodología


Bases:





El mundo social es ordenado
El orden social puede no ser
obvio y no descriptible
desde el sentido común
El orden social no puede
asumirse con estructura
previa
Se enfatiza la importancia
de las bases naturales.
UNPSJB - 2005
Categorías:


Las técnicas
convencionales suponen
categorías
preexistentes
La Etnografía intenta
utilizar sujetos con
categorías propias
Medidas

Ingeniería de Software - Clase 3
No tienen objetividad
científica, por ende los
sujetos deben crear su
propia fuente de
medición.
32
Observación de participantes

Bases:


Los observadores
pasan un tiempo con
los sujetos, tratando
de convertirse en un
miembro más del
grupo
Ventajas


UNPSJB - 2005

Desventajas



Contextualización
Se revelan detalles
que otros métodos no
pueden cubrir
Ingeniería de Software - Clase 3
Consume mucho
tiempo
Se tiene mucha
información que
puede resultar difícil
de analizar
No se puede decir
mucho de cambios
que se propongan
33
Por que modelar?

El modelado 



actividad de definición formal
de aspectos del mundo físico
y social que nos redea con el
propósito de entender y
comunicar

Modelado

Actividad de modelado

Combinar problemas


UNPSJB - 2005
Empíricos: especificaciones
ligadas al mundo real
Formales: abstracción,
estructura y representación
del conocimiento del
problema
se hace sobre los
cuatros dominios de
información
 Empresa




De ingeniería:
métodos formales de
construcción
Uso
Sistema
Desarrollo
Especificación
conceptual

Ingeniería de Software - Clase 3
Entender un dominio
específico de
información
34
Motivación del modelado

Suponga que se entrevistaron varios
actores de un problema relacionado
a una aerolínea



Cuando el vuelo está lleno, primero
se atiende a los VIP
Hay tickets de descuento para
políticos  podremos obtener
ventajas
La información debe resultar
clasificada para actores externos al
problema
Jefe de seguridad
Agente de viajes

Jefe ejecutivo





Un agente es responsable de
reservas y cancelaciones
Hay diferentes tickets ofrecidos
a las agencias de viaje
Jefe de Catering



La comida cargada está
relacionada con la número de
personas
Se debe conocer el número
aproximado de personas en el
vuelo 24 hs antes.
También 24 hs antes se debe
saber por comidas especiales
 Administrador de ventas
El número de valijas en el avión
debe corresponder al número de
 Solo se puede usar un ticket
personas que abordan
pago
 En algunos casos puede no
 Las listas de pasajeros son
confirmarse la reserva
información restringida
 Un tíckets de descuento no
 Solo se puede hacer el check in una
puede devolverse
UNPSJB vez
- 2005
Ingeniería de Software - Clase 3
35

Motivación del modelado


Como se obtiene de la transparencia anterior una
especificación acorde?
El modelado puede guiar la toma de requerimientos



El proceso de modelado puede ayudar a imaginarnos que
hacer?
Puede ayudarnos a investigar sobre requerimientos
ocultos?
 Ej: hice bien las preguntas?
El modelado puede ser una medida del progreso

La completitud del modelo implica la completitud de la
toma de req.?
UNPSJB - 2005
Ingeniería de Software - Clase 3
36
Motivación del modelado

El modelado puede ayudar a descubrir problemas

La inconsistencia de un modelo revela algo interesante




La modelización ayudará a chequear nuestro
entendimiento



UNPSJB - 2005
puede corresponder a requerimientos conflictivos o
inflexibles
puede significar confusión sobre terminologías, alcances,
etc.
Puede revelar desacuerdos entre actores
Podemos testear que el modelo tengas las propiedades
esperadas?
Se puede razonar sobre el modelo entendido y sus
consecuencias?
Podemos “animar” el modelo para ayudarnos a validar
requerimientos?
Ingeniería de Software - Clase 3
37
Tipos de modelo

Se puede elegir entre una variedad de
esquemas conceptuales



UNPSJB - 2005
Lenguaje natural
 Muy expresivo y flexible
 Pobre al intentar captar la semántica del modelo
 Mejor para la toma de requerimientos
Notación semi formal
 Captura estrutura y alguna semántica
 Puede llevar a cabo algún razonamietno, chequeo
de consistencia y animación
Notación formal
 Semántica muy precisa
 Muy complejos
Ingeniería de Software - Clase 3
38
Requerimientos para el esquema
conceptual

Independencia de implementación




Tomar solo aspectos principales
(cosas que no cambien)
Sintaxis no ambigua
Rico en semántica
Debe facilitar la comunicación
analista usuario
UNPSJB - 2005
Habilidad para seguir los
elementos del modelo
Ejecutabilidad


Para detectar ambigüedad,
inconsistencia, incompletitud
Trazabilidad


Constructibilidad

Fácil de analizar


Formalidad


No modelar representación de
datos, organización interna, etc.
Abstracción


Poder “animar” el modelo, para
comparar con la realidad
Minimalidad

No redundancia de conceptos
(cada cosa expresada de una
forma)
Ingeniería de Software - Clase 3
39
Técnicas de modelado
Modelado de información (DER)

Modelado de empresa





Modelado de requerimientos
funcionales




Metas y objetivos
Estructura organizacional
Actividades, procesos y productos
Roles y trabajos de agentes
Vistas estructurales (de datos)
Vistas de comportamiento
Requerimientos de tiempo
Modelado de req. no funcionales

De productos, de procesos y externos
UNPSJB - 2005
Ingeniería de Software - Clase 3
Modelado de organización (i*,
SSM, ISAC)
Modelado de metas: (KAOS)
Análsis estructurado (Yourdon,
Martin, etc)
Análisis OO (Coad, Boock,
UML)
Métodos formales (SCR, RSML,
Z)
QFD, Redes de petri
(performance), Modelo de
tareas (disponibilidad)
40
Modelado de requerimientos de empresa

Evolución en el tiempo

’70

Resolver los sistemas de soft




Técnicas: SSM, ISAC

Basdados en conocimiento
’80



Involucrando toda la organización
Sensitivo al contexto social y político para el cambio organizacional
Usar representación del conocimiento para construir modelos de dominio
ejecutables
Capturan aspectos estáticos y dinámicos del dominio

Técnicas: RML

Teleológicos
’90



Teleología: doctrina de
las causas finales
Los requerimientos son metas y se pueden modelizar jerarquías
Se enfocan en el por qué? Más que en el qué?
Ejemplos: KAOS, I*
UNPSJB - 2005
Ingeniería de Software - Clase 3
41
Revisión de modelos: ER, ISAC


ER  se obvia
ISAC (information
systems work & analysis
of Change)


Desarrollado en el ´70 en
Suecia
Pondera la cooperación
entre usuarios y
desarrolladores


Los desarrolladores son
facilitadores
Bueno para SI pero no
aplicable a problemas de
control

Proceso ISAC

Análisis de cambio



Estudio de actividad
 Que actividades deben reagruparse



Que entradas y salidas tienen cada
SI?
Qué son los requerimientos
cuantitativos del SI?
Implementación


UNPSJB - 2005
en sistemas de información?
Que prioridades tienen los sistemas
de información?
Análisis de información


Que quiere la organización?
Cuan flexible es la organización
respecto a cambios?
Que tecnología se utilizará para el SI
(hard, y soft)?
Que actividades del SI serán
automáticas o manuales?
Ingeniería de Software - Clase 3
42
Revisión de modelos: ISAC-Elementos

Lista de problemas

Insatisfacción con los sistemas
corrientes




Dibujar una matriz de problemas para
contrastarla con los propietarios de
los mismos
Análisis de problemas





Evitar soluciones orientadas a
problemas
Llevados a cabo por especialistas
Cuantificar el problema
Modelo de actividad corriente

Esquemas A (similar a diagramas de
flujo de datos)
UNPSJB - 2005
Sentencias declarativas de metas





Meta final  árbol de metas
Las metas deben explicar por qué
existe el problema
Generar alternativas de cambio
Modelo de situaciones deseadas


Resultado deseado, no como
obtenerlo
Definir necesidades de cambio


Análisis de causa efecto
Análisis de metas

Listar los problemas
Remover aquellos triviales o
imposibles
Lista de grupos de interés


Hacer paquetes de alternativas para
el cambio
Evaluar alternativas
Elegir una alternativa
Ingeniería de Software - Clase 3
43
Revision de modelos: SSM

Soft system methodology



Desarrollado al final del ’70
Los requerimientos no se toman objetivamente, orientado hacia
aspectos sociales
Rasgos:
 Situaciones no estructuradas
 El impacto puede ser negativo (una computadora reduce la
productividad y quita trabajo)
 Para una buena utilización se necesita una restructuración de base
muy amplia
 Analiza la situación del problema usando diferentes puntos de
vista
 Obtiene algo similar a una especificación en conjunto con

UNPSJB - 2005
Objetivos, estructuras de tareas, planes para la organización,
entendimiento del ambiente
Ingeniería de Software - Clase 3
44
Revision de modelos: SSM

Pasos de la metodología
1.
2.
Situación base (problema no
estructurado)
Análisis del problema
5.
Compara el modelo
conceptual con el paso 2
Preguntas ordenads sobre
el modelo
Reconstrucción de
eventos para compararlas
con el modelo
Comparación general para
mirar rasgos del modelo
diferentes de la situación
actual
“dibujo” del mismo
“temas” que abarca el problema
3.
Definir aspectos relevantes del
sistema y su raíz
Descripción de la actividad
humana
4.
Construir el modelo conceptual
Actividades del sistema
necesarias para llevar a cabo la
transformación
Modelo orientado al proceos, con
actividades y flujo de recursos
UNPSJB - 2005
6.
Debate sobre la factibilidad
del cambio
Tres tipos de cambio:
estructural, procedural y
de actitud
7.
Implementar los cambios
Ingeniería de Software - Clase 3
45
Revision de modelos: i*

Rasgos






Desarrollado en los ’90
Provee una estructura para
preguntar POR QUÉ
Modela el contexto de la
organización para SI
Basado en la notación de “actor”
Dos partes del modelo


Características

Modelo de dependencia
estratégica (relaciones entre
actores)
Modelo estratégico racional
(modela intereses e incumbencias
de actores)
UNPSJB - 2005
El modelo de dependencia
muestra las dependencias entre
actores  objetivo obtener un
mejor entendimiento de los por
qué?


Ingeniería de Software - Clase 3
Dependencia entre metas y
submetas (un actor depende
de otro actor para alcanzar
una meta)
Dependencia de recursos (un
actor necesita un recurso de
otro actor)
46
Revision de modelos: i*
Atte nds M e e ting
(p,m )

Dependencias de
tareas (un actor
necesita otro actor
para llevar a cabo la
tarea)
EJ: supongamos una
agenda para la
concurrencia a una
cita particular (ver
como evoluciona en
el paper
correspondiente)
UNPSJB - 2005
Exclus ionDate
(P)
D
Pre fe rre dDate
(P)
D
Iniciador
de l
e ncue ntro
D
participante
de l
e ncue ntro
D
D
Propos e dDate
(M )
D
D
Agre e m e nt
(M ,P)
D
ISA

D
D
X D
Atte nds M e e ting
(ip,m )
D
As s ure d(A
tte nds M e e t
ing (ip,m )
Ingeniería de Software - Clase 3
participante
im portante
de l
e ncue ntro
D
D
D
D
Dependencia de metas
D
D
dependencia de recueros
D
D
dependencia de tareas
D
D
Dependencia de metas
sof t
O Opend (uncommited)
X Criticas
47
Revision de modelos: i*

Modelo racional  muestra
interacciones entre metas
dentro de cada actor
Participante
del
encuentro
Iniciador
del
encuentro
D
Attends
Meeting
Muestra nivel más detallado
del modelado mirando
Low
Quick
MeetingBe
Effort
Schedule
dentro de los actores para
modelizar sus relaciones
Schedule
Exclusion
Meeting
Dates
D
Obtain
internas
AvailDate
Find
Preferred
Obtain
D
Suitable
Dates
 Muestra la descomposición
D
Agreement
Slot
Proposed
de tareas
Merge
Date
D
AvailDate
 Muestra los links entre
Agreemen
t
tareas y metas
 SR provee una forma de
modelar actores
interesados, como deben
encontrarse la forma de
evaluarlos
UNPSJB - 2005
Ingeniería de Software - Clase 3

Organize
meeting
ParticipateIn
Meeting
D
Attend
Meeting
+
Quality
(proposed
DAte)
+
D
D
D
D
Arrenge
Meeting
Conv enie
nt(meetin
g, Date)
Agreable
(meeting,
Date)
Find
Agreable
Date
Low
Effort
+
-
Min
Interrupt
ion
Agree To
Date
Meta
Cecurso
Meta Soft
T area
-+
+
User
Friendly
T area - link de descomposicón
Link means-end
contribución a meta soft
48
Revision de modelos: i*

Conclusiones sobre i*


Ganar entendimeinto en los
requerimientos del sistema
Mayor número de niveles de
análisis en término de
 Habilidad
 Viabilidad
 Credibilidad de
requerimientos
UNPSJB - 2005

Resumiendo
 Mejor representación y
razonamiento del
conocimiento
 Mayor nivel de
formalidad en las
expresiones
 Se incorpora
intencionalidad
 relaciones múltiples y
distribuidas de
intencionalidad
Ingeniería de Software - Clase 3
49
Revision de modelos: KAOS

Rasgos


UNPSJB - 2005
Desarrollado al principio de los ’90
 Primer lenguaje de modelado de requerimientos
orientado al desarrollo integral de los mismos
 Herramientas de soporte completas
 Aplicado en muchos casos de uso
 También centrado en el por qué, cómo y cuando.
Dos partes
 Modelado informal de metas
 Definición formal para cada entidad en lógica
temporal
Ingeniería de Software - Clase 3
50
Revision de modelos: KAOS

Características

El método se centra en
la elaboración de metas



Define un conjunto
inicial de metas y
objetivos de alto nivel
Define un conjunto
inicial de agentes y
acciones que estos
agentes pueden hacer

Luego iterativamente

UNPSJB - 2005

Refina las metas
usando una
descomposición
denominada AND OR
Ingeniería de Software - Clase 3

Identifica
obstáculos a las
metas y conflictos
entre metas
Lleva las metas a
limitaciones que
pueden ser luego
asignadas a
agentes
individuales
Refina y formaliza
las definiciones de
objetos y acciones
51
Modelado y análisis

Análisis de sistemas 
varias escuelas




UNPSJB - 2005
Análisis orientado a
datos
Análisis estructurado
Análisis OO
Modelos  se utilizan
para desarrollar una
comprensión del sistema
a realizar  tres vistas:



Ingeniería de Software - Clase 3
Una perspectiva
externa que modela el
contexto o entorno del
sistema
Una perspectiva de
comportamiento del
sistema
Una perspectiva
estructural que modela
la arquitectura del
sistema o la ED
procesados por este
52
Análisis estructurado

Definición





Se deben entender los
requerimientos necesarios para
continuar en la evolución del
sistema
Proveer un marco de trabajo
para modelar de forma
detallada el sistema como parte
 Debilidades
de la obtención y análisis de
 No provee métodos efectivos para
requerimientos (Sommerville)
tratar con requerimientos no
Aproximación al modelo
funcionales
conceptual orientada en los
 No ayuda al usuario a decirir el
datos
mejor método para cada caso
DFD es el elemento más
 Produce demasiada documentación
representativo
 Modelos muy detallados que son de
difícil comprensión por parte de los
Target principal de sistemas 
usuarios
SI
UNPSJB - 2005
Ingeniería de Software - Clase 3
53
Análisis estructurado

Conceptos centrales

Transformación de datos


Actividades que transforman
los datos

Indica el paso de datos de la
entrada del mismo hacia la
salida
Representa grupos de datos o
elementos de datos
Almacenamiento de datos


Lugar donde se deja info para
su uso posterior
Los almacenes de datos son
pasivos, no transforman los
datos
Entidad externa


Flujo de datos





Grupos de datos


Actividad fuera del
alcance del sistema
Fuente o destino de
info en los DFD
No pueden
interactuar
directamente con los
almacenes de datos
Clustes de datos
representados como
un flujo de dato
simple
Elemento de dato
 Unidad básica de
información
UNPSJB - 2005
Ingeniería de Software - Clase 3
54
Análisis estructurado

Herramientas de modelado


DFD




Diagrama de contexto
Diferentes niveles de
descomposición
Llegar hasta primitivas
funcionaels que no pueden
ser más descompuestas
Elementos




UNPSJB - 2005
Procesos
Flujos
Almacenes de datos
Entidades externar
Construcción
Diccionario de datos
 Define cada
elemento de dato
 Usa una notación
BNF para definir la
estructura de los
elementos
 Constructores
Notación
Significado
=
Está compuesto de
Secuencia
+
Y
Selección
[|]
O bien
Repetición
{ }n
N repeticiones de
()
Datos opcionales
**
Delimita comentarios
Ingeniería de Software - Clase 3
55
Análisis estructurado

Especificación de procesos



Evoluciones

UNPSJB - 2005
código en lenguajes narrativo o en algún
pseudo código
Define los rasgos procedurales escenciales
DFD evolucionó para poder representar TR
Ingeniería de Software - Clase 3
56
Análisis OO

Conceptos básicos





Se modela los requerimientos
en término de objetos y los
servicios que estos proveen
Representan los datos y su
procesamiento
Muestra de una forma clara
como se clasifican las entidades
del sistema y como se
componen (de otras entidades)
Son una forma natural de
reflejar al mundo real (objetos)
UNPSJB - 2005
Motivación

AOO es más natural




El sistema evoluciona  las
funciones que realiza tienden
a cambiar  los objetos
permanecen iguales
Esto no es representable con
AE (debe cambiarse)
El trabajo con OO es más
mantenible
Mayor énfasis en definir
correctamente interfases entre
objetos

Ingeniería de Software - Clase 3
Comparado con la
ambigüedad de los DFDs
57
Análisis OO

Primitivas de modelado

Objetos



Entidades con estados,
atributos o servicios
Forma de agrupar objetos
Abstracciones jerárquicas con
una relación ES_UN
Atributos
 Representan estados del

objeto
Pueden especificar: tipo,
visibilidad y modificacbilidad
UNPSJB - 2005
Relaciones

Clases



Dos tipos:



Todo parte
Es un
Métodos o servicios
 Operaciones que un objeto
puede llevar a cabo

Pasaje de mensajes


Forma de invocar los métodos o
servicios
Escenarios y casos de uso
 Secuencia de pasaje de

mensajes entre objetos
Representan interacciones
específicas
Ingeniería de Software - Clase 3
58
Análisis OO

Conceptos fudamentales

Herencia



Ocultamiento de información
Agregación

UNPSJB - 2005
Simple o múltiple
Puede describir relaciones entre las partes y el
todo
Ingeniería de Software - Clase 3
59
Análisis OO

Que cosas pueden ser objetos


Que interactúan con el
sistema a modelizar
(personas, dispositivos, otros
sistemas)


Ocurrencias o eventos

Que establecen el contexto
del problema
Estructuras


Que pueden ocurrir en el
contexto del sistema
(transferencias de recursos,
acciones de control)
UNPSJB - 2005

Relevante a la aplicación
(deptos, divisiones, equipos)
Lugares

Que son parte del dominio
que se modeliza (reportes,
señales)
Llevados por personas que
interactúan con el sistema
Unidades organizacionales

Cosas

Roles

Entidades externas



Que definen una clase
(sensores, computadoras)
Los procedimientos (imprimir,
copiar) y los atributos no son
objetos
Ingeniería de Software - Clase 3
60
Análisis OO

Características de selección
de objetos  deben

Retener información



atributos
Servicio necesario
 Operaciones identificables
Atributos múltiples



No tener uno solo
Atributos comúnes

UNPSJB - 2005
Aplicables a todas las
ocurrencias del objeto no
solo a uno

Requisitos esenciales
 Entidades externas
que aparecen en el
espacio del
problema y
producen o
consumen
información
Los objetos válidos
debe satisfacer
todas o casi todas
las propiedades
anteriores.
Ingeniería de Software - Clase 3
61
Análisis OO

Variantes para el AOO

Coad- Yourdon
 Década del ´80
 Cinco pasos de modelado



UNPSJB - 2005
Identificar los objetos y clases
Identificar estructuras (todo parte, es un )
Definir sujetos
 Vista más abstracta de una colección de objetos
(agrupamientos por puntos en común)
 Definir los atributos
 Definir los servicios y la conexión de mensajes
Ingeniería de Software - Clase 3
62
Análisis OO
Objeto
Paciente
Nombre
Fecha de nac
Altura
Peso
Atributos
Paciente
Nombre
Fecha de nac
Altura
Peso
Serv icio
Clasif icación
todo parte
1,m
Mandatario
Ingreso
paciente
Cama
Habitación
Alta paciente
medico
última visita
1,m
1,m
1
Class
1
Class
1
Class
Attribute
Attribute
Attribute
Service
Service
Service
Service
Service
UNPSJB - 2005
Ingeniería de Software - Clase 3
63
Análisis OO

AOO de Shlaer y Mellor

Proceso de seis pasos

Desarrollar un modelo de
información



Con objetos, relaciones y
atributos de objetos y
relaciones
Definir el ciclo de vida para
los objetos
Definir la dinámica de
relaciones


Modelo de estado para
relaciones entre objetos que
evolucionan en el tiempo
Definir la dinámica del
sistema


Desarrollar modelo de
procesos


Ingeniería de Software - Clase 3
Para cada acción un
diagrama de acción y
flujo de datos
Definir dominios y
subsistemas

UNPSJB - 2005
Producir un modelo de
tiempo y control a nivel
del sistema
Descomponer en partes
64
Análisis OO

UML



Unified Modeling Languaje
La última generacion de
métodos OO


Desarrollado pro Booch,
Rumbaugh y Jacobson



Aún en desarrollo
Trata de estandarizar los
conceptos de modelado OO que
manejan varios autores

Es una notación aceptada
como estándar

Tiene un meta modelo
estandarizado, compuesto por





UNPSJB - 2005
Diagramas de clases
Diagramas de casos
de uso
Diagramas de
caminos de mensajes
Diagramas de
mensajes de objeto
Diagramas de estados
Diagramas de
módulos
Diagramas de
plataformas
Lo desarrollaremos en la
clase 5 íntegramente.
Ingeniería de Software - Clase 3
65
Análisis OO

Evaluación de AOO


UNPSJB - 2005
Ventajas de OO para IR
 Se acomoda bien para el diseño y la
implementación  continúa una forma de
pensamiento y notación
 No pone énfasis en la función como lo hace AE
 Evita la fragmentación que produce el AE
Desventajas
 Complejo para rescatar características dinámicas
de los objetos
 No es claro que siempre se quiera modelar objetos,
servicios y relaciones
 Tendencia a pasar rápidamente al diseño
 No es la bala de plata pensada por muchos
Ingeniería de Software - Clase 3
66
Métodos formales en IR

Qué formalizar en IR?




Modelar el conocimiento de los
requerimientos (se puede
razonar sobre ellos)
Especificar requerimientos (se
puede hacer una
documentación precisa)
Por que formalizar?


Para remover ambigüedad y
mejorar precisión
Proveer una base para la
verificación de lo que los
requerimientos deben conocer
UNPSJB - 2005
Permitirnos razonar sobre los
requerimientos



Permitirnos animar y ejecutar los
requerimientos


Chequear propiedades
automáticamente
Testear consistencia, explorar
consecuencias
Ayuda en la visualización y validación
Se podrá formalizar eventualmente
cualquier cosa

IR es un puente desde el mundo
informal hacia el dominio formal de
máquina
Ingeniería de Software - Clase 3
67
Métodos formales en IR

Por qué no se formaliza?

Los método formales tienden
a ser de un nivel más
complejo que los otros
métodos



Incluyen mucho detalle
Tratan de concentrarse en la
consistencia y correctitud del
modelo

UNPSJB - 2005

Normalmente modelizamos
inconsistencias,
incompletitudes y cosa
incorrectas
Ingeniería de Software - Clase 3
La gente no sabe que
herramientas son
apropiadas
 Especificación de
comportamiento de
programa vs.
Modelado de
requerimiento
Los métodos formales
requieren un esfuerzo
mayor
 Y la remuneración
es la misma....
68
Métodos formales en IR

Que son los métodos formales?


Vista amplia
 Aplicación de matemática discreta a la IS
 Involucra modelado y análisis
 Con notación precisa matemática-like
Vista estrecha
 Uso de lenguajes formales


Razonamiento formal sobre formulismo en el
lenguaje

UNPSJB - 2005
Un conjunto de strings sobre un alfabeto bien definido
con reglas para distinguir que esos strings pertenecen
al lenguaje
Pruebas formales: usan axiomas y reglas de prueba
para demostar que alguna fórmula está en el lenguaje
Ingeniería de Software - Clase 3
69
Métodos formales en IR

Análisis formal  clases




UNPSJB - 2005
Análisis de consistencia y chequeo de tipos
Validación
Predecir comportamiento
Verificar refinamiento de diseño
Ingeniería de Software - Clase 3
70
Métodos formales en IR

Ventajas prácticas de los métodos formales 
se encuentra más errores



UNPSJB - 2005
Generalmente encontrados en la escritura de la
especificación formal que en el proceso de análisis
formal
El análisis formal encuentra menos errores pero
más sutiles
Errores típicos encontrados
 Interfases incorrectas
 Requerimientos incorrectos (en función de las
entradas que se disponen)
 Problemas de claridad y mantenibilidad
Ingeniería de Software - Clase 3
71
Métodos formales en IR

En que difieren los
métodos formales

Ontología



Lógica (predicado de
primer orden)
Otra (lenguajes
algebraicos o teoría
de conjuntos Z)
Tratamiento del tiempo
 Modelos estado
UNPSJB - 2005
Puede ser fija o
extensible
Base matemática



evento
Tiempo como una
objeto primario
Ingeniería de Software - Clase 3
Ejemplos
 SCR: fijo, lógica
temporal, modelo
estado evento
 RML: fijo, lógica de
predicado de
primer orden,
modelo estado
evento discreto
 Telos: extensible,
tiempo como un
objeto primario.
72
Métodos formales en IR

Tres tradiciones de lenguajes

Lenguajes formales de
especificación





Grueso del trabajo en
verificación de programas
Chequeo de tipos, prueba de
teoremas
Ej: Z, VDM



Modelado formal conceptual


Modelado de sistemas reactivos

Formalizan modelos dinámicos
de comportamiento de
sistemas


UNPSJB - 2005
Basados en sistemas reactivos
(TR)
Chequeo de consistencias,
chequeos de modelo
Ej: RSML, SCR
Ingeniería de Software - Clase 3
Capturar conocimiento del
mundo real
Pone énfasis en modelado de
entidades del dominio,
actividades, agentes y
aserciones
Motores de inferencia,
razonamiento por defecto
Ej: Telos, RML
73
Comunicando requerimientos
SRS (soft req. Specification)

El problema es  como  SRS
 Propósito
comunicar los
 Comunicar los requerimientos de
requerimientos al resto de
forma clara
los interesados
 Se explica el dominio de la aplicación


El SRS hace esto
Veremos



UNPSJB - 2005
y del sistema que se va a desarrollar

como construirlo,
los problema que
pueden surgir,
Estándares de
construcción
Contractual



Es un elemento legal
Expresa un acuerdo
Línea base para la subsecuente
evolución de productos


Soporta testeo, verificación y
validación de sistemas
Puede contener información para
verificar que se alcancen los
requerimientos
Ingeniería de Software - Clase 3
74
SRS (soft req. Specification)

Línea base para el control de
cambios



Cambio de requerimientos
Evolución del soft
Audiencia  a quien se dirige
 Usuario, clientes




Más interesados en los
requerimientos
No interesados en req. del soft



Escriben especificaciones que
interactúan
UNPSJB - 2005
Ingeniería de Software - Clase 3
Tienen que implementar
los requerimientos
Testers

Analistas de sistemas

Desarrolladores y
programadores
Determinan que
requerimientos han sido
alcanzados
Administradores de
proyectos

Miden y controlan el
proceso de análisis y
desarrollo del sistema
75
SRS (soft req. Specification)

Quién lo escribe
 El proveedor



El oferente



Debe ser específico para demostrar credibilidad y
competencia técnica
General para evitar sobre compromiso
El desarrollador seleccionado


UNPSJB - 2005
Debe ser general para tener una buena selección de
pedidos
Debe dejar de lado los pedidos no razonables
Refleja el entendimiento del desarrollador
Base del desarrollo
Ingeniería de Software - Clase 3
76
Como hacer una especificación

Considerar dos proyectos

Uno pequeño, 1 pgm, 6 meses (A)


El programador charla con el cliente y escribe hasta 5
páginas de requerimientos
Gran proyecto, 50 programadores, 2 años (B)

Equipo de analistas modelan requerimientos, SRS 500
páginas.
Proyecto A
Proyecto (B)
Propósito de la
Especificación
Representa el entendimiento del
programador, vuelve al cliente
Construye un documento, debe contener
mucho detalle para todos los pgmdor
Vista de
administración
La especificación es irrelevante, se
tiene alocados los recursos
Se debe usar la espec. para estimar recursos necesarios y plan de desarrollo.
lectores
1 autor de especificación
2 cliente
1 programadores, equipo V&V, adminis
2  clientes
UNPSJB - 2005
Ingeniería de Software - Clase 3
77
Como hacer una especificación

Aspectos 



Expresar los req. Actuales
Completitud
 Especificar todo lo que el

sistema necesita y debe
hacer
Responder a todas las
entradas posibles
Completitud estructural




No contradecirse
Usar términos de manera
consistente

Por especialistas no informáticos
Modificable

UNPSJB - 2005
Test de satisfacción por cada cliente 
debe existir
Cada req. Es especificado con
comportamiento
Entendible (claro)


Cada sentencia se lee de una sola
forma
Definir términos confusos en un
glosario
Verificable


No contener cosas que no se
requieren
No ambiguo

Consistencia

Necesario

Validez (correctitud)



Debe mantenerse actualizado
Ingeniería de Software - Clase 3
78
Las especificaciones  problemas

Que puede suceder





Redundantes
Ambiguas
No entendibles
Inconsistentes
incompletas
expandidas
ambiguas
expanden
condensadas
redundantes
reducen
agrega
explicación
formalizan
no
entendibles
inconsistentes
Resuelven
incompletas
UNPSJB - 2005
Ingeniería de Software - Clase 3
79
Errores típicos de especificación

Ruido


Ambigüedad



Texto que se interpreta de dos o más
formas diferentes
UNPSJB - 2005
Desparramar requerimientos por
todos lados y luego poner
referencias cruzadas
Requerimientos mal definidos


Texto que define un rasgo que no
puede ser validado
Puzzles


Utilizar un concepto aún no definido
Pensamiento deseado


Texto que define un rasgo de varias
formas incompatibles entre ellas
Referencia hacia delante

Texto que describe una solución más
que un problema
Contradicción


Rasgo importante no cubierto en el
texto
Sobre especificación


Tener texto poco relevante como
contenido
Silencio



No conforme a estándares
Terminología inventada o
inconsistente
Escribir de manera hostil para el
lector
Ingeniería de Software - Clase 3
80
No incluir en especificación

Planes de desarrollo del proyecto
Costo, staff, esquemas, métodos, herramientas,
etc.
El tiempo de vida del SRS es hasta el final de la
fase de operación
Tiempo de vida del plan desarrollo es más corto




Planes de aseguramiento del producto


Diseño


UNPSJB - 2005
Calidad, V&V, QA, test
Requerimientos y diseños pensados para gente
diferente
Análisis y diseño son áreas diferentes
Ingeniería de Software - Clase 3
81
Calidad de especificación

Análisis de texto

Se pueden hacer análisis textuales
del SRS
 Medir la forma de construcción





Imperativo






Identifica palabras como “debe”, “es
requerido”, etc.
Se mide cuan explícito es el SCR
Opción


Palabras como “sigue abajo”, “como
sigue”, etc.
Mide la estructura del SRS
Establecer normas para organismo  Palabras débiles
Ej; NASA usa nueve indicadores

Continuidad de los requerimientos
imperativos
Palabras como “puede”,
“opcional”,etc.
Mide las opciones que presenta SCR


Estadísticas de legibilidad

Número de estilos por palabra,
número de palabras por sentencia,
etc.
UNPSJB - 2005
Directivas

Indicación a tablas, figuras
Mide calidad del documento

Líneas de texto, párrafos, hojas

Mide el número de identificadores de
sentencias



Causan incertidumbre
Ej. Adecuado, aplicable
Tamaño
Estructura del texto
Especificación de profundidad


Mide profundidad de subsecciones
Marca la estructura del SRS
Ingeniería de Software - Clase 3
82
Ej. De texto ambiguo

El sistema deberá reportar al operador todas las fallas
que se originen en funciones críticas o que puedan
ocurrir durante la ejecución de secuencias críticas y
para las que no haya planes de recuperación
Originan en funciones críticas
V
F
V
F
V
F
V
F
Ocurren durante secuencias críticas
V
V
F
F
V
V
F
F
No hay planes de recuperación
V
V
V
V
F
F
F
F
Se avisa al operador?
UNPSJB - 2005
Ingeniería de Software - Clase 3
83
Como evitamos ambigüedad?

Revisar especificaciones en
lenguaje natural




Usar personal con diferentes
bases de conocimiento
Incluir gente de soft, gente
que entienda el problema, y
usuarios
El revisor debe ser diferente
al autor
Usar lenguajes de
especificación



Notación semiformal (tablas,
gráficos)
Lenguajes de especificación
formales
Explorar por redundancia



Conjunto restringido del
idioma
UNPSJB - 2005

Poner un requerimiento más de
una vez ayuda al lector a
comprender
Pero es redundancia
Se debe usar una notación más
formal y no repetir.
Ingeniería de Software - Clase 3
84
Características de un SRS

Modificabilidad




Trazabilidad



Bien estructurado, indexado, con referencias cruzadas
Sin redundancia
No es modificable si no es trazable
Cada requerimiento se puede rastrear hasta su fuente
Cada requerimiento se puede rastrear hasta su
implementación
Notación útil

Que lo haga fácilmente comprensible
UNPSJB - 2005
Ingeniería de Software - Clase 3
85
Estándar IEEE para SRS

IEEE introduce un estándar de
5 pasos:



Referencias
 A otros modelos IEEE
Definiciones


Describe aproximaciones
recomendadas para la
especificación de
requerimientos.
Conceptos básicos para la
práctica del modelo
Consideraciones para producir
un buen SRS
 Secuencia de 8 pasos para
lograr ese fín
UNPSJB - 2005
Partes de un SRC

Revisión




Está compuesto de
cuatro secciones cada
una con subsecciones
Leer cuidadosamente el
paper “IEEE práctica
recomendada para
especificación de Req.
De soft” (paper Q)
La especificación del
trabajo integrador
deberá hacerse
siguiendo esta
metodología
Ingeniería de Software - Clase 3
86
Trazabilidad de requerimientos

Definición





UNPSJB - 2005
El documento en cuestión contiene o implementa
todas las estipulaciones aplicables en el documento
predecesor
Un término dado, acrónimo o abreviación significa
la misma cosa en todos los documentos
Un ítem o concepto se referencia por le mismo
nombre o descripción en el documento
Todo el material en el documento sucesor tiene las
bases del predecesor, esto es, no se agrega
material que no se pueda trazar
Dos documentos no se contradicen
Ingeniería de Software - Clase 3
87
Trazabilidad de requerimientos

Resumiendo




Es una demostración de
completitud, necesidad y
consistencia
Una camino claro de
alocación y seguimiento
de flujo a través del
documento
Una derivación a través
de una jerarquía
Importancia

Para la verificación y validación







UNPSJB - 2005
Evaluar adecuadamente los test
disponibles
Evaluar la conformidad de
requerimientos
Evaluar la completitud,
consistencia y análisis de impacto
Evaluar el diseño hacia atrás y
hacia delante
Investigar como el
comportamiento de mayor nivel
impacta en la espeficación
detallada.
Detectar conflictos de
requerimientos
Chequear consistencia a través del
ciclo de vida
Ingeniería de Software - Clase 3
88
Trazabilidad de requerimientos

Mantenimiento
 Evaluar los pedido de


Acceso a documentos
 Habilidad de



Proveer posibilidad de
audición
Administración

De cambio
De riesgo
De control sobre el
proceso de desarrollo
Dificultades

Visibilidad de proceso

UNPSJB - 2005

cambio
Trazar un diseño
racional (lógico)
encontrar información
rápidamente en
grandes documentos


Habilidad para ver
como el soft se
desarrolla
Ingeniería de Software - Clase 3
Costo


Muy poco soporte
automatizado
Completa trazabilidad
es muy cara y
consumista de tiempo
89
Trazabilidad de requerimientos

Gratificación demorada
 La gente que define los
links de trazabilidad no
son gente que se
beneficie con ellos


Desarrollo vs V&V
Mucho del beneficio se
observa tarde en el ciclo
de vida

UNPSJB - 2005

Test, integración,
mantenimiento
Ingeniería de Software - Clase 3
Tamaño y diversidad



Gran rango de
documentos distintos,
herramientas,
decisiones,
responsabilidades
No hay esquemas
comunes para
clasificar y catalogar
requerimientos
En la práctica, la
trazabilidad se enfoca
en líneas base de
requerimientos.
90
Práctica corriente de trazabilidad

Cobertura





Links desde los
requerimientos hacia el
diseño, codificación y casos
de test
Links hacia atrás: desde
test, codificación y diseño a
requerimientos
Links entre requerimientos
en diferentes niveles



Proceso de trazabilidad

Asignar un único ID cada
sentencia o párrafo
Identificar manualmente
links
Usar tablas manuales para
grabar links en los
documentos
Usar la herramienta de
trazabilidad (BD) para la
trazabilidad de un gran
proyecto
Las herramientas tienen la
habilidad de



UNPSJB - 2005
Ingeniería de Software - Clase 3
Seguir los links
Encontrar links perdidos
Medir la trazabilidad total
91
Herramientas para trazabilidad

Cuales?


Hipertexto (links)
 Palabras clave que
identifican conceptos
asociados a ella



Identificadores únicos


Limitaciones
Cada requerimiento tiene un  Ej
ID único con una BD de
 Herramientas de BD (RTM,
referencias cruzadas
SLATE, DOORS)
Coeficientes de similaridad
sintáctica

UNPSJB - 2005
Todas requieren un gran
esfuerzo manual para definir
los links
Todas tienen información
puramente sintáctica, sin
contexto semántico
Busca la ocurrencias de
patrones de palabras


Herramientas de hipertexto
(document director, netscape
navigator)
Herramientas de desarrollo
general
Ingeniería de Software - Clase 3
92
Herramientas para trazabilidad

Limitaciones de herramientas


Comunicación informal
Problemas de información
 Fallan en rastrear

información de trazabilidad


Mala trazabilidad de prerequerimientos


por ej. No pueden decir
quien es el responsable de
determinado dato
UNPSJB - 2005

Desde donde vienen los
requerimientos?
Falta de convenio


Sobre la cantidad y tipo de
información trazada
Ingeniería de Software - Clase 3

La gente le da mucha
importancia la contacto
entre personas con
comunicación informal
Se suplementa lo que se
almacena en la BD de
trazabilidad
El resultado es una BD de
trazabilidad que solo da
parte de la historia
Aún con la herramienta no
es fácil encontrar las
personas que generaron el
requerimiento
93
Trazabildiad  Cuestiones problemáticas

Cuales son?

Intervención


Quién estuvo
involucrado en la
confección de los
requerimientos?

por este req?
Quién es el
responsable actual?
En que punto de ciclo
de vida el
responsable cambia?
Cambio


Responsabilidad
 Quien es responsable

UNPSJB - 2005

Notificación


Ingeniería de Software - Clase 3
En que punto del ciclo
de vida se produce un
cambio o evolución
de req?
Quien necesita ser
avisado por cambios
en los req?
Pérdida de
conocimiento

Cuales son las
ramificaciones
asociadas a la pérdida
de conocimiento?
94
Validación de requerimientos

Qué veremos

Dos problemas con la toma de
req.

El problema de la validación


Que es verdadero y que es
conocible?
El problema de la
negociación



Negociación sobre
requerimientos


Como reconciliar conflictos
entre metas en un contexto
social complejo

Validar requerimientos


UNPSJB - 2005
Inspecciones y revisiones
prototipeo
Ingeniería de Software - Clase 3
Conflictos y su
resolución
Técnicas para
negociar
requerimientos


Aproximaciones para
argumentar
Aproximaciones
basadas en
conocimiento
Priorización de
requerimientos
95
El problema de validar

Aproximación lógica
positivista


Hay un objetivo en el
mundo que puede ser
modelado construyendo un
cuerpo consistente de
conocimiento basado en
observación empírica
En IR se asume que hay un
problema objetivo que existe
en el mundo

UNPSJB - 2005



Usar herramientas que
testeen consistencia y
completitud del modelo
Usar revisiones, prototipos
etc para demostrar que el
modelo es válido
Modificación a la lógica
positivista (Popper)
Construir un modelo
consistente (validarlo con
observaciones empíricas)
Ingeniería de Software - Clase 3


Las teorías puede no
proveer cosas correctas,
se puede refutar
encontrando excepciones
Las teorías son científicas
si pueden ser refutadas
96
El problema de validar

En IR, diseñar modelos
de req para ser
refutables


Aproximación post
modernista


UNPSJB - 2005
Ver por evidencia que
muestre que el
modelo es erróneo
No hay punto de vista
privilegiado, todas las
valoraciones son
iguales


Usar actores para
que construyan sus
propios modelos de
requerimientos
Usar técnicas
etnográficas para
entender el
problema.
En IR, la validación
siempre es subjetiva y
contextualizada
Ingeniería de Software - Clase 3
97
Revisiones e inspecciones

Como tratarlos

Desde el punto de vista de
la formalidad
 Informal: en una charla de


café o en un reunión de
equipo
Formal:encuentros
programados,
participantes preparados,
agenda definida, formato
específico, salida de
documento acordado
Administradores de revisión

UNPSJB - 2005
Usados para proveer
certeza sobre el diseño
Ingeniería de Software - Clase 3


Asistido por clientes
Inspecciones




Proceso manejado
por herramientas
(formal)
Usado para mejorar
la calidad del proceso
de desarrollo
Junta datos por
defecto para analizar
al calidad del proceso
Rol principal:
entrenar personal
junior y expertos en
transferencias.
98
Beneficios de la inspección formal

Muy útil para la etapa de
programación

Programación de aplicaciones




Más efectiva que el testing
La mayoría de los
programas corren bien la
primera vez


Datos desde grandes
programas





UNPSJB - 2005
Efectos sobre competencia
del staff

El factor de reducción de
errores es 5.
Mejora la productividad en
un 15 a 25%.
Se encuentra entre un
60 y 80% de errores
durante la inspección
Reducción de costo entre
el 50 y 80% para V&V.
Incrementa la moral
Mejor estimación y
planificación
Mejor administración de
las habilidades del staff
Estos beneficios son útiles
para IR!!!!
Ingeniería de Software - Clase 3
99
Limitaciones de la inspección

Tamaño



Todos los ítem
evaluados deben estar
documentados

Duración



Suficiente gente de manera
que todos los expertos estén
disponibles
Mínimo 3 máximo 7 personas
Nunca más de 2 horas (se
pierde objetividad y
concentración)



Todos los revisores deben de
estar de acuerdo con los
resultados
UNPSJB - 2005
Alcance

Salidas

Reporte que resuma
el trabajo
Lista detallada de
aspectos relevantes
Tomar pequeñas partes,
nunca el todo
Timing

Examinar el producto
cuando el autor termina
con él.
Ingeniería de Software - Clase 3
100
Limitaciones de la inspección



Propósito

UNPSJB - 2005
No muy temprano
 El producto no está listo  se pueden encontrar
problemas que el autor se encuentra solucionando
No muy tarde
 El producto estará en uso  los errores serán muy
costosos de solucionar
Obtener datos que ayuden a no cometer el error en
el futuro
Ingeniería de Software - Clase 3
101
Guías para la revisión

Guías para la inspección

Antes de la revisión




Planificar las
revisiones formales
(RTF) en el plan del
proyecto
Entrenar a los
revisores
Asegurar que todos
los asistentes estén
preparados



Durante la revisión

Revisar el producto
no al autor

UNPSJB - 2005


Evitar comentarios
profesionales o
destructivos
Ingeniería de Software - Clase 3
Pegarse a la
agenda
Limitar el debate y
la refutación
Identificar
problemas pero no
tratar de
solucionarlos
Tomar notas
escritas
Luego de la revisión
 Revistar el proceso
de revisión
102
Elección de los revisores

Posibilidades






UNPSJB - 2005

Especialistas en revisión
(gente de QA)
Gente del mismo
equipo del autor
Gente invitada por ser
especialistas
Gente interesada en el
producto final
Gente que tenga algo
para contribuir
Gentes de otra parte de
la organzación
A quien excluir:





Ingeniería de Software - Clase 3
Cualquier responsable
directo o indirecto del autor
Cualquiera con problemas
personales declarados
contra el autor
Cualquiera que no esté
calificado en revisión
Todos los administradores
Cualquiera que tenga
conflicto de intereses
103
Estructuración de la inspección

Se puede hacer la
estructura de la revisión
de varias formas:


Revisiones activas
(escenarios)

Ad hoc:


Confiar en el experto
en revisión

Lista de chequeos


Cada revisor lee con un
propósito específico, usando
cuestionarios especializados
Diferentes revisores toman
diferentes perspectivas
 Diferencias
Usar una lista de
 Los escenarios encuentran
preguntas o casos a
mayores fallos que los otros
revisar
métodos
A lista se hace a
 No hay una diferencia
medida del
marcada entre los dos
documento evaluado
primeros
UNPSJB - 2005
Ingeniería de Software - Clase 3
104
Prototipación

Definición



Respecto de definición


UNPSJB - 2005
Un prototipo de soft es una implementación parcial
construida para permitir al cliente, usuario o
desarrollador aprender más sobre el problema o su
solución
Prototipar es el proceso de construir o trabajar
sobre el modelo del sistema
Primera  prototipo descartable
Segunda  prototipo evolucionable
Ingeniería de Software - Clase 3
105
Características de prototipos

Explicativo


Exploratorio


Evalúa propuestas y el comportamiento del modelo
Evolucionario

UNPSJB - 2005
Determina el problema, evalúa necesidades, clarifica
metas, examina alternativas y evalúa ideas, es informal,
no es estructurado
Experimental


Explica, demuestra e informa, luego se avanza
Elige y refina soluciones, se usa como producto
Ingeniería de Software - Clase 3
106
Clases de prototipos

Dos clases





Ventajas
Descartables
Evolucionables
Tercer opción: operacionales

Descartables

Propósito





Desventajas

Etapas tempranas o
posteriores
Aproximación

UNPSJB - 2005
Aprender más sobre el
problema o su solución
Obtener conocimiento
Uso



Aprender el medio de
trabajo para lograr una
mejor adaptación a las
necesidades y solución
Entrega temprana, test
temprano, menos costo
Bueno aún cuando falle

Rápida y sucia
Ingeniería de Software - Clase 3
Derrochar esfuerzo si
los requerimientos
cambian rápidamente
Generalmente el
prototipo reemplaza
documentos
107
Clases de prototipos

Evolucionables

Propósito



Ventajas

Aprender más sobre el
problema o su solución
Reducir el riesgo de
construir partes del sistema
en forma temprana
Uso






Incremental, evolucionable
Desventajas

Aproximación

Vertical: necesita desarrollo
riguroso e incremental


UNPSJB - 2005
Ingeniería de Software - Clase 3
Los requerimientos
no están congelados
Solo se retorna al
incremento anterior si
se encuentra un error
Flexible ?
Está en la otra punta
de los métodos
estructurados
No se garantizan las
soluciones más
efectivas
Poco control y
dirección
108
Clases de prototipos

Prototipos organizacionales


Ofrecen un balance entre los
casos anteriores
Pasos involucrados



Se crea un prototipo
evolucionable, basado en
una línea base usando
metodología clásica
(cascada)
La línea base se envía a
varios clientes junto con
prototipadores
experimentados
El prototipador evalúa al
cliente con el sistema
UNPSJB - 2005







El prototipador graba las
experiencias del usuario
El usuario le dice al prototipador
por necesidades faltantes
El prototipador hace cambios
rápidos en el prototipo
El usuario reutiliza el nuevo
prototipo
Se “gira” sobre el prototipo rápido
adaptándolo
Cada “cierto tiempo” el prototipo y
el prototipador retornan al
“laboratorio” para adaptar mejor el
prototipo (evolucionarlo)
Esto se repite indefinidamente
Ingeniería de Software - Clase 3
109
Acordando requerimientos

Aspectos



Definición de conflicto

UNPSJB - 2005
Negociación y resolución de conflictos
 Entre requerimientos encontrados
Priorización de requerimientos
En la psicología social, el foco es la
interdependencia y percepción
 La interacción de gente intedependiente que
percibe en forma opuesta metas, objetivos o
valores, y como ve a la otra parte como
interfiriendo sobre sus objetivos.
Ingeniería de Software - Clase 3
110
Acordando requerimientos


UNPSJB - 2005
En IR, el foco es la inconsistencia lógica
 El conflicto es una divergencia entre metas, hay
una condición límite que hace al objetivo
inconsistente
Nota:
 Los conflictos pueden ocurrir entre individuos,
grupos, organizaciones o roles diferentes jugados
por una sola persona
 No todas las partes del conflicto necesitan
necesariamente ser participantes en la solución
presentada
Ingeniería de Software - Clase 3
111
Modelo de resolución

Aproximación usada
para dirimir el conflicto

Los métodos incluyen






UNPSJB - 2005
Negociación
Competición
Arbitraje
Coerción
Educación
No todos los conflictos
necesitan un método de
resolución, así como no
todos los conflictos
necesitan ser resueltos

Trés modelos de
resolución



Ingeniería de Software - Clase 3
Cooperativo  involucra
negociación
Competición 
involucra combate,
coerción y competición
Resolución por terceras
partes  arbitraje y
apelar a una autoridad
112
Modelo de resolución

Negociación



UNPSJB - 2005

Competición
Exploración
cooperativa en el
rango de
posibilidades
Los participantes
tratan de encontrar
un punto común que
satisfaga a todas la
partes
Conocido como
integración constructiva
o negociación
constructiva




Ingeniería de Software - Clase 3
Alcanzar la máxima
satisfacción para el
participante
No tener en cuenta el
grado de satisfacción
de las otras partes
No ser
necesariamente
hostiles
Características

Si yo gano, alguien
tiene que perder
113
Modelo de resolución

Terceras Partes


Se busca un árbitro
para que decida
Tipos



UNPSJB - 2005
Judicial: cada parte
presenta tu base de
conocimiento
Extra judicial: se
determina una
decisión por factores
mas que por los casos
presentados
Arbitraria: tirar una
moneda

Licitar y negociar


Ingeniería de Software - Clase 3
Licitar
 Los participantes
establecen sus
términos deseados
Negociar
 Los participantes
buscan por la
integración
satisfactoria de sus
pedidos.
114
Conflictos en sicología social

Causas de conflictos


UNPSJB - 2005
Deutshc (1973)
 Control sobre los recursos
 Preferencias y estorbos (gustos o actividades de
una parte chocan contra otra)
 Creencias (disputas sobre hechos, información,
realidad)
 La naturaleza de relación entre partes
Robbins (1989)
 Comunicacional (intercambio insuficiente de
información, ruido, percepción selectiva)
 Estructural (compatibilidad de metas, claridad
jurisdiccional, estilo del líder)
 Factores personales (sistemas de valores
individuales, características de personalidad)
Ingeniería de Software - Clase 3
115
Experiencias  resultados

Algunos aspectos
observados



UNPSJB - 2005

(hacer un mea culpa
respecto de la
realidad de cada uno)
Los conflictos son
normales en pequeños
grupos que toman
decisiones
Más agresión y menos
cooperación si se
restringe la
comunicación

Ingeniería de Software - Clase 3
Los grupos
heterogéneos son más
conflictivos (aún si son
más experimentados),
los grupos homogéneos
son mejores para tomar
decisiones más
riesgosas
El efecto de la
personalidad es
eclipsado por factores
de situación o de
percepción
116
Severidad sobre el conflicto
B
A yB
combinados
Nuestra satisfacción
Satisfacción de otras partes
A
A yB
combinados
no
int erf irientes
Para dos posiciones
iniciales A y B, se
puede m edir la
sev eridad del
conf lic to exam inando
que sucede cuando
se com binan
B
int erf irientes
B
A
inclusiv os
B
Satisfacción de otras partes
UNPSJB - 2005
A yB
combinados
A
Satisfacción de otras partes
Nuestra satisfacción
Nuestra satisfacción
m utualm ente
ex clusiv os
Nuestra satisfacción
A
Satisfacción de otras partes
Ingeniería de Software - Clase 3
117
Clasificación de conflictos sociales
Unidades sociales
Igual vs igual
Jefe vs.
Subordinado
Todo vs. parte
Roles
Rol de familia vs.
Rol ocupacional
Rol ocupacional
vs. Rol de unidad
Personalidad social
vs. Rol de familia
Grupos
Chicos y chicas en
una clase escolar
Padre vs hijos
Familia núcleo vs
familia ampliada
Sectores
Fuerza aérea vs
ejército
Administración vs
unión
Departamento vs
facultad
Sociedades
Protestantes vs
católicos
Hombres libres vs
esclavos
Estado vs mafias
Relaciones supra
sociedades
Bloque soviético
vs primer mundo
URSS vs Hungria
CEE vs Reino
unido
UNPSJB - 2005
Ingeniería de Software - Clase 3
118
Teoría del juego

Teoría del juego en la
resolución de conflictos

Ej: dilema del prisionero
Prisionero B
Dados




Dos o más jugadores
Utilidades conocidas
para cada uno de los
jugadores
Puede calcular


UNPSJB - 2005
Cual estrategia
resulta en el mejor
resultado
Como interactúan las
estrategias de los
jugadores
No Confiesa
No Confiesa
Confiesa
un año a cada
uno
10 años para A
y 3 meses
para B
tres meses
para A y 10
años para B
8 años para
uno
Prisionero A

Pero



Confiesa
En IR, no sabemos cuales son las
utilidades
Se puede resolver conflictos
pidiendo a los participantes que
cambien sus utilidades
No sabemos ni siguiera que
movimientos son posibles
Ingeniería de Software - Clase 3
119
Argumentación

gIBIS



Desarrollado en 1989
Representa el proceso
de argumentación como
un grafo hipertextual
Proceso básico



UNPSJB - 2005
Identificar usos
Identificar posiciones
que se pueden
adoptar con respecto
a las posiciones
Linkear argumentos
que soporte o refuten
posiciones
Uso 1
responde a
Posición 1
objeto de
Argumento 1
soporte
generaliza
preguntas
Argumento 2
responde a
Uso 2
Argumento 3
Posición 2
preguntas
objeto de
objeto de
Argumento 4
es sugerido por
Uso 3
Ingeniería de Software - Clase 3
Argumento 5
Uso 4
120
Argumentación

Sinóptico



UNPSJB - 2005
Propuesto por Easterbrook (1991)
Herramienta que soporta la negociación
colaborativa enfocada en tareas
Proceso básico (ampliar el paper)
 Toma cada participante para exteriorizar sus
modelos conceptuales
 Encuentra correspondencias entre los modelos
 Clasifica los puntos de disidencias
 Genera opciones para resolver cada disidencia
Ingeniería de Software - Clase 3
121
Otros casos

Usando modelos pre-existentes

OZ



Desarrollado por Robinson
(1992)
Usa el modelo de dominio
preexistente para comparar
perspectivas de conflicto
Proceso básico




Identificar perspectivas
(colección de creencias)
Guardar perspectivas anotando
el modelo de dominio de metas
y objetivos
El modelo de dominio linkea
atributos del producto a metas
Elegir combinaciones de
atributos de productos para
maximizar la satisfacción de
participantes
UNPSJB - 2005

WinWin




Desarrollado por Bohem (1990)
Identifica condiciones de triunfo de
cada participante
Incorpora el conocimiento base del
dominio para calidad de
requerimientos y links de atributos
del producto
Proceso básico




Entrar las condiciones de triunfo básicas
de cada participante
Identificar estrategias de atributos para
condiciones de triunfo
Determinar efectos negativos para cada
estrategia sobre cada condición de
triunfo
Resolver manualmente las
desaveniencias
Ingeniería de Software - Clase 3
122
Evolución de Req.  guías

El soft evoluciona
porque los
requerimientos
evolucionan



UNPSJB - 2005
Familias de software


Guías
Administración de
configuración
Líneas de productos
Puntos de vista

Leyes de la evolución
del soft
Administración
tradicional del cambio





Ingeniería de Software - Clase 3
Como marco para el
entendimiento de la
evolución de
requerimientos
Administración de
inconsistencia
Razonamiento sobre el
cambio
Rasgos ppales de la
interacción
123
Tipos de programas

Programas
Especificables



Problemas que pueden
ser establecidos formal
y completamente
Aceptación: el
programa está acorde
con su especificación?
Este soft no evoluciona

UNPSJB - 2005
Un cambio en la
especificación define
un problema nuevo,
entonces hay un
programa nuevo
de rse
e
pu iona
lac con
re
Sentencias
formales del
problema
Mundo
Real
pue
de de se
inte
r
rés
Ingeniería de Software - Clase 3
pr con
od tro
uc la
ció la
n
de
Programa
e
e
ov
Pr
Solución
124
Tipos de programas

Programas para solución
de problemas



Sentencias imprecisas
del problema del mundo
real
Aceptación: el
programa es una
solución aceptable al
problema?
El soft evoluciona
continuamente


UNPSJB - 2005
Porque la solución
nunca es perfecta, y
puede ser mejorada
Porque el mundo real
cambia y entonces el
problema cambia
Mundo
Real
Cambia
Vista abstracta
del mundo real
Compara
Cambia
Especificación
de
requeriminetos
Solución
Ingeniería de Software - Clase 3
Programa
125
Tipos de programas

Programas
empotrados



Un sistema que es
parte del mundo al
que modeliza
Aceptación: depende
enteramente de una
opinión o un juez
Es inherentemente
evolcionario
 Los cambios en el
soft y el el mundo
real se afectan
entre sí
UNPSJB - 2005
Mundo Real
Cambia
Programa
Especificación
de
requeriminetos
Ingeniería de Software - Clase 3
Vista abstracta
del mundo real
Modelo
126
Leyes de la evolución de pgms.

Continuidad del cambio

Cualquier soft que refleje una
realidad externa está en
cambio continuo o se torna
progresivamente menos
utilizado


A medida que el soft
evoluciona, la complejidad se
incrementa
UNPSJB - 2005
Ley fundamental


El cambio continúa hasta
que se crea que es mejor
tirarlo y hacerlo de nuevo
Incremento de complejidad


Conservación de la estabilidad
Organizacional


La evolución del soft es regulada
con tendencias y variantes
estadísticas
Durante la vida activa del soft, el
trabajo de salida de proyecto de
desarrollo es constante
Conservación de la familiaridad

Durante la vida activa de un
programa el porcentaje de
cambios permanece constante
Ingeniería de Software - Clase 3
127
Crecimiento en requerimientos

Modelo de Davis

El usuario necesita
evolucionar
continuamente



UNPSJB - 2005
El gráfico presenta el
crecimiento de
necesidades en el
tiempo
Puede ser no lineal o
no continuo
El desarrollo tradicional
queda detrás de las
necesidades de
crecimiento
Ingeniería de Software - Clase 3




Solo se hacen parte
de los requerimientos
originales
Siempre se agrega
nueva funcionalidad
Eventualmente se
tornan en soft muy
costoso que necesita
planear sus cambios
Los reemplazos solo
implementan partes
de los requerimientos
128
Mantenimiento del software

Filosofía de
mantenimiento

Proceso de mantenimiento de Basili



Se pierden Inversiones
en conocimiento y
experiencia
El mantenimiento se
convierte en un desafio
de la Ing. Reversa
El equipo de desarrollo
hará un compromiso a
largo plazo para
mantener el soft
UNPSJB - 2005
Modelo fijo rápido

Alguien más es el
responsable del
mantenimiento




Modelo iterativo
 Cambios hechos en base al análisis


Los cambio hechos a nivel de
código, tan fácil como se pueda
Rápidamente degrada la estructura
del soft
de soft existente
Trata de controlar la complejidad y
mantener un buen diseño
Modelo de reuso total


Empieza con los requerimientos de
un nuevo sistema, reusando tanto
como se pueda
Necesita una cultura madura de
reuso para tener éxito
Ingeniería de Software - Clase 3
129
Adm. Tradicional de mantenimiento

Los administradores necesitan responder el
requerimiento de cambio



UNPSJB - 2005
Agregar nuevos requerimientos durante el
desarrollo
Modificar requerimientos durante el desarrollo
 Porque el desarrollo es parte del proceso de
aprendizaje
Remover requerimientos durante el desarrollo
 Quizá por problemas de costos
Ingeniería de Software - Clase 3
130
Adm. Tradicional de mantenimiento

Elementos de la administración
de cambio

Items de configuración




Cada producto diferente
durante el desarrollo es un
ítem de configuración
Control de versión para cada
ítem
Proceso de administración de
cambio


Líneas base


UNPSJB - 2005
Versión estable del documento
que puede ser compartida por
el equipo
Proceso de aprobación formal
para incorporación de cambios
Ingeniería de Software - Clase 3

Todos los cambios
propuestos son enviados
formalmente como pedidos
El equipo de revisión toma
los pedidos de cambio y
decide o no su aceptación
El equipo de revisión
considera la interacción
entre cambios de
requerimiento
131
“singularidad de productos”

La mayoría de las técnicas de  Lo anterior ignora la realidad
IR se enfocan a modelos
 La IR no termina en la
individuales
especificación

Pasos





Construir un modelo
Hacerlo consistente y
completo
Validarlo
Se asume que al IR es un
proceso con una salida simple

La salida es una
especificación completa,
consistente y válida
UNPSJB - 2005


Los requerimientos son
volátiles, se necesita
administración continua de
cambio
Las especificaciones nunca se
completan
No hay nunca solo un modelo


Hay múltiples versiones de
modelos en el tiempo
Hay múltiples variantes del
modelo que exploran diferentes
temas
Ingeniería de Software - Clase 3
132
“singularidad de productos”



UNPSJB - 2005
Hay múltiples
componentes de
modelos representando
diferentes
descomposiciones
Las familias de modelos
evolucionan con el
tiempo (agregando,
borrando, mezclando o
reestructurando la
familia)
La IR debe evolucionar
los requerimientos





Como se administra el cambio
incremental del modelo de req?
Como se pueden comparar
múltiples modelo?
Como afectan los cambios del
modelo a las propiedades
establecidas para él?
Como se puede capturar la
racionalidad del cambio?
Como tratar con las
inconsistencias e
incompletitudes del modelo
Ingeniería de Software - Clase 3
133
Familias de Software

El reuso del soft intenta achicar
costos

El desarrollo de soft es caro, el
reuso es ideal si los sistemas
son similares



Reusar conocimiento y
experiencia más que solo
productos de soft
El desarrollo de soft reusable
es más caro!!


Desarrollo de programas
(Java, C)
Ingeniería de dominio

Divide el desarrollo del soft en
dos partes
 Análisis del
Librerías de componentes
reusables

Específicas de dominio (librerías
del Math)
UNPSJB - 2005
Ingeniería de Software - Clase 3

dominio(identifica
componentes reusables del
dominio del problema
Desarrollo de aplicación
(usa componentes de
dominio para especificar
aplicaciones)
134
Familias de Software

Familias de soft

Muchas compañías ofrecen sistemas de
soft relacionados
Elegir una arquitectura estable para la familia
 Identificar las variaciones entre diferentes
miembros de la familia


UNPSJB - 2005
Representa una decisión estrategia de
negocio sobre que soft desarrollar
Ingeniería de Software - Clase 3
135
Puntos de Vista  Motivación

Múltiples
perspectivas




UNPSJB - 2005
Muchos actores
diferentes
Diversas clases de
conocimiento del
dominio
Vistas conflictivas (y
negociación)
Muchos esquemas de
representación

Modelado distribuido




Ingeniería de Software - Clase 3
Analistas y actores
colaborando
Métodos múltiples de
modelado
Evolución continua de
requerimientos
Links de
comunicación
imperfectos
136
Puntos de Vista  Motivación

Demoras en la resolución de
inconsistencias


Inconsistencias  causas






Conflicto entre fuentes de
conocimiento
Diferentes interpretaciones
Problemas de comunicación
entre desarrolladores
Diferentes velocidades de
desarrollo
Divergencias en los
métodos previstos
errores
Modelo simple con coerción de
consistencia es muy restrictivo



Inconsistencias se dan en situaciones de
incertidumbre



UNPSJB - 2005
Se transforman en cuellos de botella
para el proceso de modelado
distribuido
La coerción previene la divergencia de
ideas
Resolución prematura puede conllevar
decisiones de diseño prematuras
La inconsistencia implica que se
necesita más adquisición de
conocimiento
Algunas inconsistencias nunca serán
resueltas
Ingeniería de Software - Clase 3
137
Marco de trabajo básico

El modelo de requerimientos
es una colección de puntos
de vista

Para cada PV  identificar






Propietario
Dominio (que describe)
Estilo (notación o reglas
utilizadas)
Plan de trabajo
(obligaciones de
consistencia con otros PV)
Historia de los cambios
Especificación de contenido
UNPSJB - 2005

Los PV son instanciados desde
templates



Tiene un estilo y un plan de
trabajo
El desarrollo de templates es
una tarea separada
Un método provee un
conjunto de templates
designados para ser usados
juntos
Ingeniería de Software - Clase 3
138
Marco de trabajo básico

Los PV contienen reglas de consistencia



UNPSJB - 2005
Reglas de consistencia internas para
chequeo de especificación de PV
Reblas Consistencia externa para
chequeos entre PV
Plan de trabajo  provee guías para
cuando aplicar cada regla de consistencia
Ingeniería de Software - Clase 3
139
Ventajas de los PV

Actores y trazabilidad


Los propietarios de PV pueden
ser roles, personas, equipos...
Cada contribución de un actor
es modelizada en una
notación apropiada




Estructuración del
proceso de desarrollo


Cada actor puede validar e
identificar su propia
contribución
Se incrementa el concepto
de propiedad en el proceso
de requerimiento
Los requerimientos pueden
ser trazados hacia la fuente
de los mismos
UNPSJB - 2005
Ingeniería de Software - Clase 3
Cada PV es una “pieza”
independiente
No hay control global,
no hay esfuerzos
globales para
consistencia


Trabajo sincrónico o
asincrónico
Las reglas de
chequeo de
consistencia actúan
puntos explícitos de
sincronización
140
Ventajas de los PV

Estructuración de descripciones


UNPSJB - 2005
Las contribuciones de diferentes actores son
modelizadas por separado
 Separación de competencias
 Enriquece el modelo a través del uso de múltiples
estructuras de problemas
Resolución de inconsistencias puede verse
demorada
 Soporta negociación permitiendo comparación
detallada de PV
 Anima el modelado temprano y expresión de vistas
diferentes
Ingeniería de Software - Clase 3
141
PV  hacia adonde???

Método de ingeniería



Proceso de modelado


Un proceso de
modelado de grano fino
en cada PV
Administración de
consistencia

UNPSJB - 2005
Método de diseño 
definir un conjunto de
templates coherentes
PV como una
herramienta Meta CASE




Como grafos
Como predicados sobre
estructuras de objetos
Como expresiones de lógica
de primer orden
Cuando deberían ser
aplicadas


Como pude la inconsistencia
ser reparada una vez
detectada?
Cuales son las
consecuencias de no
repararlas?
Como presentar reglas  Trazabilidad de
requerimientos
de consistencia inter
 Los PV asociados a actores
PV?
con sus contribuciones
Ingeniería de Software - Clase 3
142
Administración de inconsistencia

Como aparece una
inconsistencia (como ya
vimos)






Conflicto entre fuentes de
conocimiento
Interpretaciones diferentes
Problemas de comunicación
entre desarrolladores
Diferentes velocidades de
desarrollo
Divergencias entre los
métodos utilizados
errores
UNPSJB - 2005

Definición de inconsistencia


Ingeniería de Software - Clase 3
Dos partes de las
especificación no obedecen la
misma relación que está
definida para ellos
Las relaciones pueden unir



Elementos sintácticos de
especificación parcial
Semántica de elementos en
especificaciones parciales
Subprocesos del proceso de
desarrollo
143
Administración de inconsistencia

Las relaciones surgen de:
Definición de métodos
 Experiencia práctica con el método
 Contingencias locales durante el desarrollo


UNPSJB - 2005
Las inconsistencias pueden solamente ser
detectadas automáticamente si las
relaciones están definidas formalmente
Ingeniería de Software - Clase 3
144
Inconsistencia

La inconsistencia está en la IS




Las descripciones de IS varian
mucho en formalidad y
precisión
Descripciones individuales
pueden ser formadas mal o
ser contradictorias
Las descripciones continúan
evolucionando durante el
desarrollo
El chequeo de consistencia de
un gran conjunto de
descripciones es muy caro en
términos computacionales
UNPSJB - 2005

Lecciones sobre inconsistencia
en la práctica

Algunas inconsistencias nunca
son solucionadas



Porque el costo de cambiar
documentos sobrepasa el
beneficio
Porque los humanos son
buenos inventando
“excusas”
Convivir con la inconsistencia
es una decisión riesgosa
Ingeniería de Software - Clase 3

Los factores de riesgo
cambian, el riesgo debe
reevaluarse continuamente
145
Inconsistencia

Algunas chequeos de consistencias no
tienen la valoración de performance


El monto de dinero para establecer la
consistencia donde se anticipa el cambio
La inconsistencia es contradictoria

Ej:


UNPSJB - 2005
Porque generalmente es vista como algo malo
Porque siempre se puede cuestionar la
formalización
Ingeniería de Software - Clase 3
146
Conviviendo con inconsistencia

La detección es vital



Convivir con inconsistencia es
seguro si se tiene
conocimiento de su existencia

Manejo de inconsistencia



Remover / reemplazar
elementos inconsistentes, o
remover / reemplazar reglas
que fueron rotas
Ignorarla
 Si puede ser aislada y no es
importante
UNPSJB - 2005

Tomar acciones que afinen
la situación pero que no
resuelvan la inconsistencia
Resolverla:


Si se necesita información
que no está disponible por
el momento
Mejorarla
Evadirla


Demorarla:
Negociar una solución o
encontrar un compromiso
La inconsistencia indica,
normalmente, que se necesita
más información
Ingeniería de Software - Clase 3
147
Modelo de proceso de inconsistencia
Localizar
Inconsisten
cia
Detectada
Ignorar
Caracterización
de
Inconsistencia
Identificar
Clasificar
Midiendo
Inconsistencias
UNPSJB - 2005
Tolerar
Resolver
Diferir
Evadirla
mejorarla
consecuencas de
monitoreos de acciones
monitor para inconsistencia
reglas de
consistencia
Inconsistencia
Manipulada
Analizando impacto y riesgo
Ingeniería de Software - Clase 3
148
PV para chequeo de consistencia

Quién es el responsable

Los propietarios de los PV son
responsables por cambios
locales en sus PV



Pueden sugerir cambios a
otros
No pueden forzar la
sincronización de PV
Como se expresan
responsabilidades?

Las reglas de consistencia
expresan relaciones que
deberían respetarse entre PV
UNPSJB - 2005



Cuando debería chequearse las
relaciones entre PV?


Cada PV tiene su propio
conjunto de reglas
No se necesita control central
El propietario del PV chequea
las reglas cuando lo necesite
Como se chequean las
relaciones entre PV?


El sistemas administrador de
transacciones entre PV
Los dos PV testeados son
notificados de los resultados
Ingeniería de Software - Clase 3
149
PV para chequeo de consistencia

Como resolver
inconsistencias?




Las Acciones pueden no llevar
a una solución
Las acciones surgen de los
métodos de diseño y de
experiencias en su uso
Que sucede si no se resuelve
la inconsistencia?

Deben quedar documentadas

Los cambios subsecuentes
pueden afectar a esa
inconsistencia
UNPSJB - 2005
Que sucede si cambios
futuros interfieren con la
resolución?

Los chequeos exitosos no
garantizan las relaciones se
mantengan



Cada regla puede necesitar
ser aplicada un número de
veces durante el desarrollo
Los cambios que afectan
inconsistencias resueltas son
trazados
Las acciones involucradas en
la resolución son guardadas
como parte de documentos
Ingeniería de Software - Clase 3
150
Ejercicios y trabajos






UNPSJB - 2005
Investigar sobre las metodologías de análisis I* y
KAOS (presentar un informe)
Investigar sobre RTF
Presentar un documento que resuma las actividades
de las RTF describiendo cada paso involucrado
Investigar sobre el estado del arte de la prototipación.
(a partir del paper que deben leer)
Investigar sobre el estado del arte en la negociación
de conflictos
Leer los papers:
 E,F,H,I,O,P,Q,U,V,W
 Buscar el paper Metodologías de Análisis y Diseño
convencional y OO del material 2002-2003.
Ingeniería de Software - Clase 3
151