Clase 3

Ingeniera de Software
Clase 3
Ingeniera de Requerimientos
(Toma, modelado, comunicacin,
aceptacin y mantenimiento)
Contenido Clase 3
Obtencin de requerimientos
Tcnicas tradicionales
Entrevistas y cuestionarios
Escenarios y casos de uso
Aproximacin cognitiva
Aproximacin 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
Evolucin del Anlisis
AE
AOO
Tcnicas formales
Especificacin vs. Modelado de

requerimientos
Algunos ejemplos
(investigacin)
SCR
RML
RSML
Ingeniera de Software -
Contenido Clase 3 (cont.)
Comunicando
requerimientos
SRS (soft
requeriment
Specification)
Ambigedades y
como evitarlas
Estndares
Trazabilidad de
requerimientos
UNPSJB - 2005
Validacin de
requerimientos
Usos filosficos
Revisiones e inspecciones
Prototipacin
Aceptando los
requerimientos
Negociacin ante problemas

Solucin de conflictos
Contenido clase 3 (cont.)
Evolucionando requerimientos
Administracin
del cambio
Administracin de inconsistencia
Rasgos de interaccin
Familias de productos para Administracin
de requerimientos
UNPSJB - 2005
Contenido Clase 3
Bibliografa utilizada
Ingeniera
de Requerimientos
(Locoupulous)
Ingenira de Requerimientos (Davis)
Ingeniera de software (Pressman,
Sommerville)
Papers Varios
UNPSJB - 2005
Toma de Requerimientos
Punto de comienzo
Alguna
notacin que indique que hay un

problema que necesita resolverse
Oportunidad de negocios
Necesidad de mercado
Utilizacin de recursos
El
Ing. de requerimientos es una agente

del cambio
El Ing.Requerimientos debe
Identificar
UNPSJB - 2005
el problema / oportunidad
Toma de Requerimientos
Cual problema necesita ser resuelto? (identificar lmites)
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 debera 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
Latcnica
tcnicade
de
las
las66W:
W:
What?
What?
Where?
Where?
Who?
Who?
Why?
Why?
When?
When?
How
How(Which)?
(Which)?
UNPSJB - 2005
Los cuatro mundos

Como el
sistema utiliza la
informacin
sobre el dominio
de la aplicacin
Mundo del
sujeto
Como la mquina
representa
inforamcin sobre el
dominio de
aplicacin
Mundo del
uso
Interfases de
usuario
Mundo del
sistema
Justificar las
metas de
desarrollo
Mundo del
desarrollo
Desiciones de
diseo
UNPSJB - 2005
Dificultades para la adquisicin
Criterios para definir el dominio del

conocimiento
El conocimiento puede estar distribuido a lo largo

de muchos recursos
Generalmente no est descrito en forma explcita
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
Conocimiento tcito
Las personas encuentran difcil decir que necesitan

o complican mucho la explicacin
UNPSJB - 2005
Dificultades para la adquisicin
Problemas en la comunicacin
La
gente puede estar imposibilitada para

decir lo que realmente necesita
Problemas polticos 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
10
Tcnicas para toma de requerimientos
Tcnicas tradicionales
Mirar hacia dentro del

problema
Documentos existentes
Anlisis de datos
Entrevistas
Introspeccin
Agenda abierta
Estructuradas
Cuestionarios
Adquisicin en grupos
UNPSJB - 2005
Grupos enfocados
Brainstorming
JAD/RAD
Prototipacin
Aproximacin basada en
representacin
Basada en objetivos
Basada en escenarios
Basadas en casos de
uso
11
Tcnicas para toma de requerimientos
Aproximacin
contextual (social)
Tcnicas etnogrficas
Observacin de
participantes
Etnometodologa
Anlisis de discurso
Anlisis de
conversacin
Anlisis de
presentacin
Diseo participatorio
UNPSJB - 2005
Aproximaciones
cognitivas
Anlisis de tareas
Anlisis de protocolos
Tcnicas de adquisicin
de conocimiento
Ordenamiento de
tarjetas
Grillas de repertorio
Tcnicas de escalado
de proximidad
Etnografa:
Etnografa:ciencia
cienciaque
quetiene
tienepor
porestudio
estudioyydescripcin
descripcinde
delas
las
razas
o
pueblos,
como
tambin
su
lengua,
sus
creencias,
razas o pueblos, como tambin su lengua, sus creencias,
artesanas,
usos,
Ingeniera
decostumbres
Softwareyy-formas
12
artesanas,
usos,
costumbres
formasde
devida
vida
Cuestionarios
Ventajas
Puede obtener informacin

rpidamente de muchas
personas
Puede administrarse
remotamente
Puede obtener actitudes y
caractersticas de los actores
Desventajas
No hay entrevistas con

usuarios
UNPSJB - 2005
Puede obtener un contexto

muy pobre del problema
Qu mirar?
Tendencias en la seleccin
de ejemplos
Tendencias en la seleccin
de respuestas
Ejemplos de tamao chico
(con poca significancia
estadstica)
Preguntas ambiguas
(muchos que no contestan la
misma pregunta)
El cuestionario debe ser
testeado
13
Entrevistas
Tipos
Estructuradas
Agenda abierta, no hay

temarios previos
Ventajas
Existe una agenda

previa con temarios
Ricas en adquisicin de
informacin
Desventajas
Libres
Muchos datos cualitativos

difciles de analizar
UNPSJB - 2005
Difcil la comparacin de
respuestas
Administrar las
entrevistas no es una
tarea sencilla
Que mirar?
Preguntas sin
respuestas
Conocimiento tcito
El contexto de discusin
Actitud de los
entrevistados respecto
de los temas abarcados
14
Tcnicas de adquisicin en grupo
Tipos
JAD o RAD
Enfoque en grupo
Brainstorming
Ventajas
Interaccin ms natural
entre la gente, mayor a
una entrevista formal
Se puede medir la
reaccin ante material
de estmulo
Presentaciones,
maquetas, etc.
Desventajas
Que mirar?
UNPSJB - 2005
Puede crear grupos poco

naturales y hacer sentir
incmodos a los participantes
Peligro de llevar a una opinin de
grupo que no sea real
Pueden obtenerse respuestas
superficiales a cuestiones
tcnicas
Se requiere de un facilitador muy
entrenado
Tendencias en los ejemplos
Dominancia y submisin
15
Coleccin de datos complejos
Identificar los grupos de

estos datos
Hechos y figuras,
informacin financiera, etc.
Reportes usados para toma
de decisiones,...
Resultados obtenidos,
informacin de marketing,..
Ejemplos
Ejemplos propuestos tomar

aquellos considerados ms
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.
Obtener datos
representativos del conjunto Tamao del ejemplo
de la poblacin de
Balancear entre costo y
elementos
relevancia del ejemplo
UNPSJB - 2005
16
Casos de uso
Que es un caso de uso?
Cada forma diferente en que un actor interacta con

el sistema
Una descripcin 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 descripcin de un conjunto posible de escenarios,
con un propsito comn
Se escriben, generalmente, en lenguaje natural
No hay descripcin interna del sistema, solo la
interaccin con el mismo
UNPSJB - 2005
17
Casos de uso
Ventajas y desventajas
Caracterizacin detallada de todas las posibles

interacciones con el sistema
Ayuda en el dibujo de los lmites 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 especificacin precisa, solo
es la representacin de un problema puntual
UNPSJB - 2005
18
Usando Casos de uso
Dibujar los lmites
Identificar los actores

fuera de los lmites del
sistema que interactan
con l
Para cada factor
Identificar los posibles

casos de uso
Establecer escenarios
concretos para ilustrar
cada caso de uso
Agrupar escenarios
similares en casos de
uso si son una variacin
sobre un tema
UNPSJB - 2005
Ingeniera de
Para cada caso de uso
Escribirlo
Especificar reglas para
eleccin del mismo y para
interacturar con l
Considerar alternativas
Ver posibles superposiciones
de casos de uso
Template
Templatede
decaso
casode
deuso:
uso:
Nombre:
Nombre:
Resumen:
Resumen:
Actores:
Actores:
Precondiciones:
Precondiciones:
Descripciones:
Descripciones:
Excepciones:
Excepciones:
Postcondiciones:
Software -Postcondiciones:
19
Un ejemplo de caso de uso
Nombre: Orden de pedido

Precondicin: un usuario vlido est conectado al sistema
Descripcin:
Excepciones:
El caso de uso comienza con un pedido del cliente

El cliente entra su nombre y direccin
Si el cliente entra solo el cdigo postal, el sistema debe agregar la ciudad y la
provincia.
El cliente entrar todos los cdigo 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 nmero de la misma
El cliente apretar la tecla enviar
El sistema verificar la informacin, 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
En el paso 9, si hay informacin incorrecta, el sistema le preguntar al cliente
que quiso poner
Postcondiciones:
La orden fue salvada en el sistema y fue marcada como confirmada
UNPSJB - 2005
Orden de pedido
Tomar Estado
Enviar catlogo
Cancelar orden
Enviar producto
Re-Adquirir
producto
Delivery
Proveedor
20
Escenarios
Definicin
Secuencia especfica de
interacciones entre
actores y sistemas
Tienden a ser cortos
Puede sen
Positivos
(comportamiento
requerido)
Negativos (interaccin
no deseada)
Pueden estar en modo

indicativo u optativo
UNPSJB - 2005
Ventajas
Muy natural: se tratan

de usar de manera
expontnea
Los escenarios cortos
son muy buenos para
ilustrar interacciones
especficas
Desventajas
Falta de estructuracin:
se necesitan casos de
uso o modelo de tareas
para proveer una visin
de alto nivel.
21
Modelado de tareas y Escenarios
Modelado de tareas:
Conjunto jerrquico de
actividades estereotpicas
Los subojetivos son
tareas (o casos posibles
de uso)
Escenarios
Son caminos a travs del modelo

de tareas, tomando una secuencia
especfica 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
peridicamente o en
escenarios en si mismo, interactan
respuesta a
con mltiples escenarios
contingencias.
UNPSJB - 2005
22
Aproximacin basada en metas
Aproximacin
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
especficos
Anlisis de metas
Documentos, organizacin y
clasificacin de metas
Evolucin de metas
Refinar, elaborar y poner
operativos
UNPSJB - 2005
Ventajas
Razonablemente
intuitivo
La declaracin explcita
de metas provee una
base para la solucin de
conflictos
Desventajas
Difcil de seguir la
evolucin
23
Usando aproximacin basadas en metas
Metas
Especificacin de cmo una meta

debe estar en un nuevo sistema
Tipos
Objetivos de alto nivel de un

negocio u organizacin
Requerimiento
Metas de realizacin
Metas de mantenimiento
Metas soft
Consejos
Obstculos y limitaciones
Los obstculos son

comportamientos que
previenen la realizacin de
una meta dada
UNPSJB - 2005
Las limitaciones son condiciones

sobre la realizacin de una meta
Las metas se obtienen mejor de

mltiples fuentes
Asociar actores a cada meta
(revela puntos de vista y
conflictos)
Usar escenarios para explorar
como los objetivos pueden ser
alcanzados
Consideraciones explcitas sobre
obstculos puede ayudar a
construir o definir excepciones.
24
Tcnicas adquisicin de conocimiento
Base:
La toma de conocimiento
est ligada con el
descubrimiento experto
de conocimiento
Ligado con el crecimiento
de los sistemas expertos
Mtodos formales
KE es dura
Problemas de modelado
Problema de
representacin
Separar el dominio del

conocimiento de la
performance del
conocimiento
UNPSJB - 2005
Es muy frgil,
para pequeos casos de
uso
Inadecuado
epistemolgicamente
Expresividad vs.
Facilidad de adquisicin
25
Por que KE es tan difcil??
Expertos no se utilizan para

describir que hacen
Problemas de representacin
Hay tres pasos para modelar el

aprendizaje
Cognitivo (descripcin verbal de

las tareas)
Asociativo (reforzar las ideas con
repeticiones de dichos verbales)
Autnomo (compilado, no son
concisos)
Los mecanismos procedurales y

declarativos son diferentes
El conocimiento declarativo se
torna procedural con aplicacin
repetida, los expertos no pueden
hacer esto fcilmente
UNPSJB - 2005
Los expertos no tienen un

lenguaje para describir el
conocimiento
Los lenguajes hablados no tiene

la suficiente precisin
diferentes representaciones de
conocimiento son buenas para
cosas diferentes
Ventaja
El conocimiento se crea, no se
extrae
Son abstracciones de la realidad

Se crea travs de suposiciones
simples
Tiende a tener menos errores o
problemas
26
Expresividad vs. Facilidad de adquisicin
Son objetivos opuestos

Lo
ms expresivo es ms difcil de adquirir

y viceversa
Ej
Las interfases con reglas de induccin son
fciles de adquirir pero poco expresivas
La lgica de un programa es muy
expresiva pero difcil de adquirir
La representacin ideal intenta combinar lo
mejor de cada una
UNPSJB - 2005
27
El nivel del conocimiento

Ver el modelado del
conocimiento como:
UNPSJB - 2005
racionalizacin
Observar el comportamiento de
un agente como una caja negra
Acta como si tuviera
conocimiento sobre el
ambiente que utiliza
Construir dos modelos
Nivel simblico: descripciones
del mecanismo del
comportamiento
Nivel de conocimiento:
descripciones del conocimiento
del agente del mundo real
Ambiente
Observacin
Observador
(modelador)
Agente
mecanizado
Modelo el nivel
de conocimiento
Comportamiento
Modelo de nivel
de smbolos
28
Algunas tcnicas de toma de

conocimiento
Anlisis de protocolo
Basadas en vocalizar el
comportamiento
Ventajas
Forma verbal de las
actividades cognitivas
Dentro del contexto
Desventajas
No tienen dimensin social
Basada en introspeccin
Tcnicas de escala de
proximidad
Dado un dominio, derivar un

conjunto de dimensiones para
clasificarlo
Ventajas:
UNPSJB - 2005
Ayuda a construir modelos mentales,

Pueden adquirir conocimiento tcito
Desventajas
Requiere una aceptacin del
conjunto de objetos
Difcil de lograr
Ordenamiento de tarjetas
Para un conjunto de objetos de

dominio escribirlos en tarjetas para
ordenarlas en grupos
Ventajas
Simple y fcil de automatizar
Desventajas
Las entidades necesitan ser
identificadas dentro de semnticas a
lo largo del dominio
29
Abstraccin vs. contextualismo
Abstraccin:
Construye modelos
abstrayndolos del dominio, el
modelo puede contestar
preguntas
Decidir sobre la ontologa del
fenmeno que se quiere
describir
Se asume que el conocimiento
y el entendimiento son
independientes del contexto
Utilizado normalmente por
cientficos naturales e
ingenieros
UNPSJB - 2005
Contextualismo
Pone nfasis en los

detalles e idiosincrsia del
dominio
Ontologa:
Ontologa:parte
parte
de
delalametafsica,
metafsica,
que
estudia
que estudiaelelser
ser
en
general
y
sus
en general y sus
propiedades
propiedades
trascendentales
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
cientficos sociales
30
Visin etnometodolgica
La toma de requerimientos es
una actividad social
Porque involucra comunicacin

entre personas (discusiones,
observacin de la realidad, etc)
Porque involucra negociacin
para lograr consensos
Porque afecta y cambia los
sistemas de actividad humana
El dominio de una aplicacin es,

gralmente, un mundo social
UNPSJB - 2005
Se necesitan tcnicas que cubran el

orden del mundo social
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
Etnologa:
Etnologa:ciencia
cienciaque
que
estudia
el
origen,
la
estudia el origen, la
distribucin
distribucinyylos
los
caracteres
caracteresfsicos
fsicosde
delas
las
razas
razashumanas
humanas
Es construido a partir de acciones de

los participantes
No se puede tomar informacin de
categoras preestablecidas
Se necesita considerar
Como los significados se desarrollan

y evolucionan en el contexto
Los mtodos pblicos utilizados para
que el contexto tenga sentido
31
Etnometodologa
Bases:
El mundo social es ordenado

El orden social puede no ser
obvio y no descriptible desde
el sentido comn
El orden social no puede
asumirse con estructura
previa
Se enfatiza la importancia de
las bases naturales.
UNPSJB - 2005
Categoras:
Las tcnicas
convencionales suponen
categoras preexistentes
La Etnografa intenta
utilizar sujetos con
categoras propias
Medidas
No tienen objetividad
cientfica, por ende los
sujetos deben crear su
propia fuente de
medicin.
32
Observacin de participantes
Bases:
Los observadores
pasan un tiempo con
los sujetos, tratando
de convertirse en un
miembro ms del
grupo
Ventajas
Contextualizacin
Se revelan detalles
que otros mtodos no
pueden cubrir
UNPSJB - 2005
Desventajas
Consume mucho
tiempo
Se tiene mucha
informacin que
puede resultar difcil
de analizar
No se puede decir
mucho de cambios
que se propongan
33
Por que modelar?
El modelado
actividad de definicin formal

de aspectos del mundo fsico
y social que nos redea con el
propsito de entender y
comunicar
Modelado
Actividad de modelado
Combinar problemas
Empricos: especificaciones
ligadas al mundo real
Formales: abstraccin,
estructura y representacin
del conocimiento del
problema
UNPSJB - 2005
De ingeniera:
mtodos formales de
construccin
se hace sobre los

cuatros dominios de
informacin
Empresa
Uso
Sistema
Desarrollo
Especificacin conceptual
Entender un dominio
especfico de informacin
34
Motivacin del modelado
Suponga que se entrevistaron varios

actores de un problema relacionado a
una aerolnea
Cuando el vuelo est lleno, primero se

atiende a los VIP
Hay tickets de descuento para polticos
podremos obtener ventajas
La informacin debe resultar clasificada
para actores externos al problema
Agente de viajes
Jefe ejecutivo
Jefe de Catering
Jefe de seguridad
El nmero de valijas en el avin debe

corresponder al nmero de personas
que abordan
Las listas de pasajeros son informacin
restringida
Solo se puede hacer el check in una
vez
UNPSJB - 2005
Un agente es responsable de
reservas y cancelaciones
Hay diferentes tickets ofrecidos a
las agencias de viaje
La comida cargada est
relacionada con la nmero de
personas
Se debe conocer el nmero
aproximado de personas en el
vuelo 24 hs antes.
Tambin 24 hs antes se debe saber
por comidas especiales
Administrador de ventas
Solo se puede usar un ticket pago

En algunos casos puede no
confirmarse la reserva
Un tckets de descuento no puede
devolverse
35
Como se obtiene de la transparencia anterior una

especificacin 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
36
El modelado puede ayudar a descubrir problemas
La inconsistencia de un modelo revela algo interesante
puede corresponder a requerimientos conflictivos o

inflexibles
puede significar confusin sobre terminologas, alcances,
etc.
Puede revelar desacuerdos entre actores
La modelizacin ayudar a chequear nuestro

entendimiento
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?
UNPSJB - 2005
37
Tipos de modelo
Se puede elegir entre una variedad de

esquemas conceptuales
Lenguaje natural
Muy expresivo y flexible
Pobre al intentar captar la semntica del modelo
Mejor para la toma de requerimientos
Notacin semi formal
Captura estrutura y alguna semntica
Puede llevar a cabo algn razonamietno, chequeo
de consistencia y animacin
Notacin formal
Semntica muy precisa
Muy complejos
UNPSJB - 2005
38
Requerimientos para el esquema

conceptual
Independencia de implementacin
Tomar solo aspectos principales

(cosas que no cambien)
Sintaxis no ambigua
Rico en semntica
Debe facilitar la comunicacin
analista usuario
UNPSJB - 2005
Habilidad para seguir los

elementos del modelo
Ejecutabilidad
Para detectar ambigedad,

inconsistencia, incompletitud
Trazabilidad
Constructibilidad
Fcil de analizar
Formalidad
No modelar representacin de
datos, organizacin interna, etc.
Abstraccin
Poder animar el modelo, para

comparar con la realidad
Minimalidad
No redundancia de conceptos
(cada cosa expresada de una
forma)
39
Tcnicas de modelado
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
Modeladode
deinformacin
informacin(DER)
(DER)
Modelado
Modeladode
deorganizacin
organizacin(i*,
(i*,
SSM,
ISAC)
SSM, ISAC)
Modelado
Modeladode
demetas:
metas:(KAOS)
(KAOS)
Anlsis
Anlsisestructurado
estructurado(Yourdon,
(Yourdon,
Martin,
Martin,etc)
etc)
Anlisis
AnlisisOO
OO(Coad,
(Coad,Boock,
Boock,UML)
UML)
Mtodos
Mtodosformales
formales(SCR,
(SCR,RSML,
RSML,
Z)
Z)
Modelado de req. no funcionales
De productos, de procesos y externos
UNPSJB - 2005
QFD,
QFD,Redes
Redesde
depetri
petri
(performance),
(performance),Modelo
Modelode
de
tareas
tareas(disponibilidad)
(disponibilidad)
40
Modelado de requerimientos de empresa
Evolucin en el tiempo
70
Resolver los sistemas de soft
80
Tcnicas: SSM, ISAC
Basdados en conocimiento
90
Usar representacin del conocimiento para construir modelos de dominio ejecutables

Capturan aspectos estticos y dinmicos del dominio
Tcnicas: RML
Teleologa:
Teleologa:doctrina
doctrina
de
delas
lascausas
causasfinales
finales
Teleolgicos
Involucrando toda la organizacin

Sensitivo al contexto social y poltico para el cambio organizacional
Los requerimientos son metas y se pueden modelizar jerarquas

Se enfocan en el por qu? Ms que en el qu?
Ejemplos: KAOS, I*
UNPSJB - 2005
41
Revisin de modelos: ER, ISAC
ER se obvia
ISAC (information
systems work & analysis
of Change)
Desarrollado en el 70 en
Suecia
Pondera la cooperacin
entre usuarios y
desarrolladores
Proceso ISAC
UNPSJB - 2005
Que actividades deben reagruparse en

sistemas de informacin?
Que prioridades tienen los sistemas de
informacin?
Anlisis de informacin
Que quiere la organizacin?

Cuan flexible es la organizacin respecto a
cambios?
Estudio de actividad
Los desarrolladores son

facilitadores
Bueno para SI pero no

aplicable a problemas de
control
Anlisis de cambio
Que entradas y salidas tienen cada SI?

Qu son los requerimientos cuantitativos
del SI?
Implementacin
Que tecnologa se utilizar para el SI (hard,

y soft)?
Que actividades del SI sern automticas o
manuales?
42
Revisin de modelos: ISAC-Elementos
Lista de problemas
Insatisfaccin con los sistemas

corrientes
Listar los problemas

Remover aquellos triviales o imposibles
Dibujar una matriz de problemas para

contrastarla con los propietarios de los
mismos
Anlisis de causa efecto
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
Anlisis de problemas
Anlisis de metas
Lista de grupos de inters
Hacer paquetes de alternativas para

el cambio
Evaluar alternativas
Elegir una alternativa
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 utilizacin se necesita una restructuracin de base
muy amplia
Analiza la situacin del problema usando diferentes puntos de vista
Obtiene algo similar a una especificacin en conjunto con
Objetivos, estructuras de tareas, planes para la organizacin,

entendimiento del ambiente
UNPSJB - 2005
44
Revision de modelos: SSM
Pasos de la metodologa
1.
2.
Situacin base (problema no

estructurado)
Anlisis del problema
5.
Preguntas ordenads sobre

el modelo
Reconstruccin de eventos
para compararlas con el
modelo
Comparacin general para
mirar rasgos del modelo
diferentes de la situacin
actual
dibujo del mismo

temas que abarca el problema
3.
Definir aspectos relevantes del

sistema y su raz
Descripcin de la actividad
humana
4.
Construir el modelo conceptual
Actividades del sistema necesarias

para llevar a cabo la
transformacin
Modelo orientado al proceos, con
actividades y flujo de recursos
UNPSJB - 2005
Compara el modelo
conceptual con el paso 2
6.
Debate sobre la factibilidad

del cambio
Tres tipos de cambio:

estructural, procedural y de
actitud
7.
Implementar los cambios
45
Revision de modelos: i*
Rasgos
Caractersticas
Desarrollado en los 90
Provee una estructura para preguntar

POR QU
Modela el contexto de la organizacin
para SI
Basado en la notacin de actor
Dos partes del modelo
Modelo de dependencia estratgica

(relaciones entre actores)
Modelo estratgico 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?
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
AttendsMeeting
(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
D
ExclusionDate
(P)
Iniciador
del
encuentro
participante
del
encuentro
PreferredDate
(P)
D
D
ProposedDate
(M)
D
Agreement
(M,P)
D
X D
AttendsMeeting
(ip,m)
Assured(A
ttendsMeet
ing (ip,m)
participante
importante
del
encuentro
D
D
Dependencia de metas
dependencia de recueros
dependencia de tareas
Dependencia de metas
soft
O Opend (uncommited)
X Criticas
47
Modelo racional muestra

interacciones entre metas
dentro de cada actor
Muestra nivel ms detallado
del modelado mirando dentro Quick
de los actores para modelizar
sus relaciones internas
Muestra la descomposicin
Find
Suitable
de tareas
Slot
Muestra los links entre tareas
y metas
SR provee una forma de
modelar actores interesados,
como deben encontrarse la
forma de evaluarlos
Attends
Meeting
ParticipateIn
Meeting
D
Attend
Meeting
Organize
meeting
Quality
(proposed
DAte)
Low
Effort
MeetingBe
Schedule
Schedule
Meeting
Obtain
Agreement
Merge
AvailDate
Obtain
AvailDate
D
Meta
Exclusion
Dates
D
D
Preferred
Dates
Proposed
Date
Agreemen
t
D
D
Arrenge
Meeting
Convenie
nt(meetin
g, Date)
Low
Effort
Agreable
(meeting,
Date)
Find
Agreable
Date
User
Friendly
Min
Interrupt
ion
Agree To
Date
Cecurso
Meta Soft
Tarea
-+
UNPSJB - 2005
Participante
del
encuentro
Iniciador
del
encuentro
Tarea - link de descomposicn

Link means-end
contribucin a meta soft
48
Conclusiones sobre i*
Ganar entendimeinto en los

requerimientos del sistema
Mayor nmero de niveles de
anlisis en trmino de
Habilidad
Viabilidad
Credibilidad de
requerimientos
UNPSJB - 2005
Resumiendo
Mejor representacin y
razonamiento del
conocimiento
Mayor nivel de
formalidad en las
expresiones
Se incorpora
intencionalidad
relaciones mltiples y
distribuidas de
intencionalidad
49
Revision de modelos: KAOS
Rasgos
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
Tambin centrado en el por qu, cmo y cuando.
Dos partes
Modelado informal de metas
Definicin formal para cada entidad en lgica
temporal
UNPSJB - 2005
50
Revision de modelos: KAOS
Caractersticas
El mtodo se centra en
la elaboracin 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
Refina las metas
usando una
descomposicin
denominada AND OR
UNPSJB - 2005
Identifica
obstculos 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 anlisis
Anlisis de sistemas
varias escuelas
Anlisis orientado a
datos
Anlisis estructurado
Anlisis OO
Modelos se utilizan
para desarrollar una
comprensin del sistema
a realizar tres vistas:
UNPSJB - 2005
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
Definicin
Se deben entender los

requerimientos necesarios para
continuar en la evolucin del
sistema
Proveer un marco de trabajo

para modelar de forma detallada
el sistema como parte de la
Debilidades
obtencin y anlisis de
No provee mtodos efectivos para
requerimientos (Sommerville)
tratar con requerimientos no
Aproximacin al modelo
funcionales
conceptual orientada en los
No ayuda al usuario a decirir el
datos
mejor mtodo para cada caso
DFD es el elemento ms
Produce demasiada documentacin
representativo
Modelos muy detallados que son de
Target principal de sistemas
difcil comprensin por parte de los
usuarios
SI
UNPSJB - 2005
53
Conceptos centrales
Transformacin de datos
Actividades que transforman
los datos
Flujo de 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
UNPSJB - 2005
Entidad externa
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 bsica de
informacin
54
Herramientas de modelado
DFD
Diagrama de contexto
Diferentes niveles de
descomposicin
Llegar hasta primitivas
funcionaels que no pueden
ser ms descompuestas
Elementos
Procesos
Flujos
Almacenes de datos
Entidades externar
UNPSJB - 2005
Diccionario de datos
Define cada
elemento de dato
Usa una notacin
BNF para definir la
estructura de los
elementos
Constructores
Construccin
Notacin
Significado
Est compuesto de
Secuencia
Seleccin
[|]
O bien
Repeticin
{ }n
N repeticiones de
()
Datos opcionales
**
Delimita comentarios
55
Especificacin de procesos
cdigo
en lenguajes narrativo o en algn

pseudo cdigo
Define los rasgos procedurales escenciales
Evoluciones
DFD
UNPSJB - 2005
evolucion para poder representar TR
56
Anlisis OO
Conceptos bsicos
Se modela los requerimientos

en trmino 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
Motivacin
AOO es ms 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 ms
mantenible
Mayor nfasis en definir

correctamente interfases entre
objetos
Comparado con la ambigedad

de los DFDs
57
Anlisis OO
Primitivas de modelado
Objetos
Entidades con estados,
atributos o servicios
Clases
Forma de agrupar objetos
Abstracciones jerrquicas con
una relacin ES_UN
Atributos
Representan estados del objeto
Pueden especificar: tipo,
visibilidad y modificacbilidad
UNPSJB - 2005
Relaciones
Dos tipos:
Mtodos o servicios
Operaciones que un objeto puede

llevar a cabo
Pasaje de mensajes
Todo parte
Es un
Forma de invocar los mtodos o

servicios
Escenarios y casos de uso
Secuencia de pasaje de mensajes

entre objetos
Representan interacciones
especficas
58
Anlisis OO
Conceptos fudamentales
Herencia
Simple o mltiple
Ocultamiento
de informacin
Agregacin
UNPSJB - 2005
Puede describir relaciones entre las partes y el

todo
59
Anlisis OO
Que cosas pueden ser objetos
Entidades externas
Que interactan con el sistema
a modelizar (personas,
dispositivos, otros sistemas)
Cosas
Que son parte del dominio que
se modeliza (reportes, seales)
Ocurrencias o eventos
Que pueden ocurrir en el
contexto del sistema
(transferencias de recursos,
acciones de control)
UNPSJB - 2005
Roles
Unidades organizacionales
Que establecen el contexto del

problema
Estructuras
Relevante a la aplicacin
(deptos, divisiones, equipos)
Lugares
Llevados por personas que

interactan con el sistema
Que definen una clase

(sensores, computadoras)
Los procedimientos (imprimir,

copiar) y los atributos no son
objetos
60
Anlisis OO
Caractersticas de seleccin
de objetos deben
atributos
Operaciones identificables
Atributos mltiples
Servicio necesario
Requisitos esenciales
Retener informacin
No tener uno solo
Atributos comnes
Aplicables a todas las

ocurrencias del objeto no
solo a uno
UNPSJB - 2005
Entidades externas
que aparecen en el
espacio del problema
y producen o
consumen
informacin
Los objetos vlidos

debe satisfacer todas
o casi todas las
propiedades
anteriores.
61
Anlisis OO
Variantes para el AOO
Coad- Yourdon
Dcada del 80
Cinco pasos de modelado
UNPSJB - 2005
Identificar los objetos y clases

Identificar estructuras (todo parte, es un )
Definir sujetos
Vista ms abstracta de una coleccin de objetos
(agrupamientos por puntos en comn)
Definir los atributos
Definir los servicios y la conexin de mensajes
62
Anlisis OO
Paciente
Objeto
Nombre
Fecha de nac
Altura
Peso
Atributos
Paciente
Nombre
Fecha de nac
Altura
Peso
Servicio
Clasificacin
todo parte
1,m
Mandatario
Ingreso
paciente
Cama
Habitacin
Service
UNPSJB - 2005
Alta paciente
medico
ltima visita
Service
1,m
1,m
1
Class
1
Class
1
Class
Attribute
Attribute
Attribute
Service
Service
Service
63
Anlisis OO
AOO de Shlaer y Mellor
Proceso de seis pasos
Desarrollar un modelo de
informacin
Con objetos, relaciones y

atributos de objetos y
relaciones
Definir el ciclo de vida para

los objetos
Definir la dinmica de
relaciones
Modelo de estado para

relaciones entre objetos que
evolucionan en el tiempo
UNPSJB - 2005
Definir la dinmica del

sistema
Desarrollar modelo de
procesos
Producir un modelo de
tiempo y control a nivel
del sistema
Para cada accin un

diagrama de accin y
flujo de datos
Definir dominios y
subsistemas
Descomponer en partes
64
Anlisis OO
UML
Unified Modeling Languaje

La ltima generacion de
mtodos OO
Desarrollado pro Booch,

Rumbaugh y Jacobson
An en desarrollo
Trata de estandarizar los
conceptos de modelado OO que
manejan varios autores
Es una notacin aceptada

como estndar
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 mdulos
Diagramas de
plataformas
Lo desarrollaremos en la
clase 5 ntegramente.
65
Anlisis OO
Evaluacin de AOO
Ventajas de OO para IR
Se acomoda bien para el diseo y la implementacin

contina una forma de pensamiento y notacin
No pone nfasis en la funcin como lo hace AE
Evita la fragmentacin que produce el AE
Desventajas
Complejo para rescatar caractersticas dinmicas de los

objetos
No es claro que siempre se quiera modelar objetos,
servicios y relaciones
Tendencia a pasar rpidamente al diseo
No es la bala de plata pensada por muchos
UNPSJB - 2005
66
Mtodos formales en IR
Qu formalizar en IR?
Modelar el conocimiento de los

requerimientos (se puede
razonar sobre ellos)
Especificar requerimientos (se
puede hacer una documentacin
precisa)
Por que formalizar?
Para remover ambigedad y

mejorar precisin
Proveer una base para la
verificacin de lo que los
requerimientos deben conocer
UNPSJB - 2005
Permitirnos razonar sobre los

requerimientos
Permitirnos animar y ejecutar los

requerimientos
Chequear propiedades
automticamente
Testear consistencia, explorar
consecuencias
Ayuda en la visualizacin y validacin
Se podr formalizar eventualmente

cualquier cosa
IR es un puente desde el mundo

informal hacia el dominio formal de
mquina
67
Por qu no se formaliza?
Los mtodo formales tienden

a ser de un nivel ms
complejo que los otros
mtodos
Incluyen mucho detalle
Tratan de concentrarse en la
consistencia y correctitud del
modelo
Normalmente modelizamos
inconsistencias,
incompletitudes y cosa
incorrectas
UNPSJB - 2005
La gente no sabe que

herramientas son
apropiadas
Especificacin de
comportamiento de
programa vs.
Modelado de
requerimiento
Los mtodos formales
requieren un esfuerzo
mayor
Y la remuneracin
es la misma....
68
Que son los mtodos formales?
Vista amplia
Aplicacin de matemtica discreta a la IS

Involucra modelado y anlisis
Con notacin precisa matemtica-like
Vista estrecha
Uso de lenguajes formales
Un conjunto de strings sobre un alfabeto bien definido con

reglas para distinguir que esos strings pertenecen al
lenguaje
Razonamiento formal sobre formulismo en el lenguaje
UNPSJB - 2005
Pruebas formales: usan axiomas y reglas de prueba para

demostar que alguna frmula est en el lenguaje
69
Anlisis formal clases

Anlisis
de consistencia y chequeo de tipos

Validacin
Predecir comportamiento
Verificar refinamiento de diseo
UNPSJB - 2005
70
Ventajas prcticas de los mtodos formales

se encuentra ms errores
Generalmente encontrados en la escritura de la

especificacin formal que en el proceso de anlisis
formal
El anlisis formal encuentra menos errores pero
ms sutiles
Errores tpicos encontrados
Interfases incorrectas
Requerimientos incorrectos (en funcin de las
entradas que se disponen)
Problemas de claridad y mantenibilidad
UNPSJB - 2005
71
En que difieren los

mtodos formales
Ontologa
Base matemtica
Puede ser fija o

extensible
Lgica (predicado de
primer orden)
Otra (lenguajes
algebraicos o teora de
conjuntos Z)
Tratamiento del tiempo
Modelos estado-evento
Tiempo como una objeto
primario
UNPSJB - 2005
Ejemplos
SCR: fijo, lgica
temporal, modelo
estado evento
RML: fijo, lgica de
predicado de
primer orden,
modelo estado
evento discreto
Telos: extensible,
tiempo como un
objeto primario.
72
Tres tradiciones de lenguajes
Lenguajes formales de
especificacin
Grueso del trabajo en

verificacin de programas
Chequeo de tipos, prueba de
teoremas
Ej: Z, VDM
Modelado formal conceptual
Modelado de sistemas reactivos
Formalizan modelos dinmicos

de comportamiento de
sistemas
UNPSJB - 2005
Basados en sistemas reactivos

(TR)
Chequeo de consistencias,
chequeos de modelo
Ej: RSML, SCR
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

Propsito
comunicar los
Comunicar los requerimientos de
requerimientos al resto de
forma clara
los interesados
Se explica el dominio de la aplicacin y
El SRS hace esto

Veremos
del sistema que se va a desarrollar
como construirlo,
los problema que
pueden surgir,
Estndares de
construccin
UNPSJB - 2005
Contractual
Es un elemento legal
Expresa un acuerdo
Lnea base para la subsecuente

evolucin de productos
Soporta testeo, verificacin y validacin

de sistemas
Puede contener informacin para
verificar que se alcancen los
requerimientos
74
Lnea base para el control de

cambios
Ms interesados en los
requerimientos
No interesados en req. del soft
Analistas de sistemas
Determinan que
requerimientos han sido
alcanzados
Administradores de
proyectos
Escriben especificaciones que

interactan
UNPSJB - 2005
Tienen que implementar

los requerimientos
Testers
Usuario, clientes
Desarrolladores y
programadores
Cambio de requerimientos
Evolucin del soft
Audiencia a quien se dirige
Miden y controlan el
proceso de anlisis y
desarrollo del sistema
75
Quin lo escribe
El proveedor
El oferente
Debe ser especfico para demostrar credibilidad y

competencia tcnica
General para evitar sobre compromiso
El desarrollador seleccionado
UNPSJB - 2005
Debe ser general para tener una buena seleccin de

pedidos
Debe dejar de lado los pedidos no razonables
Refleja el entendimiento del desarrollador

Base del desarrollo
76
Como hacer una especificacin
Considerar dos proyectos
Uno pequeo, 1 pgm, 6 meses (A)
El programador charla con el cliente y escribe hasta 5

pginas de requerimientos
Gran proyecto, 50 programadores, 2 aos (B)
Equipo de analistas modelan requerimientos, SRS 500

pginas.
Proyecto A
Proyecto (B)
Propsito de la
Especificacin
Representa el entendimiento del

programador, vuelve al cliente
Construye un documento, debe contener

mucho detalle para todos los pgmdor
Vista de
administracin
La especificacin es irrelevante, se
tiene alocados los recursos
Se debe usar la espec. para estimar recursos necesarios y plan de desarrollo.
lectores
1 autor de especificacin
1 programadores, equipo V&V, adminis
2 cliente
2 clientes
UNPSJB - 2005
77
Como hacer una especificacin
Aspectos
Validez (correctitud)
Expresar los req. Actuales
Completitud
Especificar todo lo que el
sistema necesita y debe
hacer
Responder a todas las
entradas posibles
Completitud estructural
Consistencia
No contradecirse
Usar trminos de manera
consistente
UNPSJB - 2005
Necesario
No ambiguo
Test de satisfaccin por cada cliente

debe existir
Cada req. Es especificado con
comportamiento
Entendible (claro)
Cada sentencia se lee de una sola forma

Definir trminos confusos en un glosario
Verificable
No contener cosas que no se requieren
Por especialistas no informticos
Modificable
Debe mantenerse actualizado
78
Las especificaciones problemas
Que puede suceder
Redundantes
Ambiguas
No entendibles
Inconsistentes
incompletas
expandidas
ambiguas
expanden
condensadas
formalizan
redundantes
reducen
agrega
explicacin
no
entendibles
inconsistentes
Resuelven
incompletas
UNPSJB - 2005
79
Errores tpicos de especificacin
Ruido
Rasgo importante no cubierto en el

texto
Texto que define un rasgo de varias

formas incompatibles entre ellas
Texto que se interpreta de dos o ms
formas diferentes
UNPSJB - 2005
Texto que define un rasgo que no

puede ser validado
Puzzles
Desparramar requerimientos por

todos lados y luego poner
referencias cruzadas
Requerimientos mal definidos
Utilizar un concepto an no definido
Pensamiento deseado
Texto que describe una solucin ms

que un problema
Ambigedad
Contradiccin
Referencia hacia delante
Sobre especificacin
Tener texto poco relevante como

contenido
Silencio
No conforme a estndares
Terminologa inventada o
inconsistente
Escribir de manera hostil para el
lector
80
No incluir en especificacin
Planes de desarrollo del proyecto
El tiempo de vida del SRS es hasta el final de la fase

de operacin
Tiempo de vida del plan desarrollo es ms corto
Planes de aseguramiento del producto
Costo, staff, esquemas, mtodos, herramientas, etc.
Calidad, V&V, QA, test
Diseo
Requerimientos y diseos pensados para gente

diferente
Anlisis y diseo son reas diferentes
UNPSJB - 2005
81
Calidad de especificacin
Anlisis de texto
Se pueden hacer anlisis textuales

del SRS
Imperativo
Identifica palabras como debe, es

requerido, etc.
Se mide cuan explcito es el SCR
Opcin
Palabras como sigue abajo, como

sigue, etc.
Mide la estructura del SRS
Medir la forma de construccin

Establecer normas para organismo Palabras dbiles
Ej; NASA usa nueve indicadores
Continuidad de los requerimientos

imperativos
Palabras como puede,

opcional,etc.
Mide las opciones que presenta SCR
Estadsticas de legibilidad
Nmero de estilos por palabra,

nmero de palabras por sentencia,
etc.
UNPSJB - 2005
Directivas
Lneas de texto, prrafos, hojas
Estructura del texto
Indicacin a tablas, figuras

Mide calidad del documento
Tamao
Causan incertidumbre
Ej. Adecuado, aplicable
Mide el nmero de identificadores de

sentencias
Especificacin de profundidad
Mide profundidad de subsecciones

Marca la estructura del SRS
82
Ej. De texto ambiguo
El sistema deber reportar al operador todas las fallas

que se originen en funciones crticas o que puedan
ocurrir durante la ejecucin de secuencias crticas y
para las que no haya planes de recuperacin
Originan en funciones crticas
Ocurren durante secuencias crticas
No hay planes de recuperacin
Se avisa al operador?
UNPSJB - 2005
83
Como evitamos ambigedad?
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
especificacin
Notacin semiformal (tablas,

grficos)
Lenguajes de especificacin
formales
Explorar por redundancia
Conjunto restringido del

idioma
UNPSJB - 2005
Poner un requerimiento ms de
una vez ayuda al lector a
comprender
Pero es redundancia
Se debe usar una notacin ms
formal y no repetir.
84
Caractersticas 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
implementacin
Notacin til
Que lo haga fcilmente comprensible
UNPSJB - 2005
85
Estndar IEEE para SRS
IEEE introduce un estndar de

5 pasos:
Describe aproximaciones
recomendadas para la
especificacin de
requerimientos.
A otros modelos IEEE
Definiciones
Referencias
Partes de un SRC
Revisin
Conceptos bsicos para la

prctica del modelo
Consideraciones para producir

un buen SRS
Secuencia de 8 pasos para

lograr ese fn
UNPSJB - 2005
Est compuesto de
cuatro secciones cada
una con subsecciones
Leer cuidadosamente el
paper IEEE prctica
recomendada para
especificacin de Req.
De soft (paper Q)
La especificacin del
trabajo integrador
deber hacerse
siguiendo esta
metodologa
86
Trazabilidad de requerimientos
Definicin
El documento en cuestin contiene o implementa

todas las estipulaciones aplicables en el documento
predecesor
Un trmino dado, acrnimo o abreviacin significa
la misma cosa en todos los documentos
Un tem o concepto se referencia por le mismo
nombre o descripcin 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
UNPSJB - 2005
87
Resumiendo
Es una demostracin de
completitud, necesidad y
consistencia
Una camino claro de
alocacin y seguimiento
de flujo a travs del
documento
Una derivacin a travs
de una jerarqua
Importancia
Para la verificacin y validacin
UNPSJB - 2005
Evaluar adecuadamente los test

disponibles
Evaluar la conformidad de
requerimientos
Evaluar la completitud, consistencia y
anlisis de impacto
Evaluar el diseo hacia atrs y hacia
delante
Investigar como el comportamiento
de mayor nivel impacta en la
espeficacin detallada.
Detectar conflictos de requerimientos
Chequear consistencia a travs del
ciclo de vida
88
Mantenimiento
Evaluar los pedido de

cambio
Trazar un diseo
racional (lgico)
Habilidad de encontrar
informacin
rpidamente en
grandes documentos
Costo
Habilidad para ver

como el soft se
desarrolla
UNPSJB - 2005
De cambio
De riesgo
De control sobre el
proceso de desarrollo
Dificultades
Visibilidad de proceso
Proveer posibilidad de
audicin
Administracin
Acceso a documentos
Muy poco soporte

automatizado
Completa trazabilidad
es muy cara y
consumista de tiempo
89
Gratificacin demorada
La gente que define los
links de trazabilidad no
son gente que se
beneficie con ellos
Tamao y diversidad
Desarrollo vs V&V
Mucho del beneficio se

observa tarde en el ciclo
de vida
Test, integracin,
mantenimiento
UNPSJB - 2005
Gran rango de
documentos distintos,
herramientas,
decisiones,
responsabilidades
No hay esquemas
comunes para
clasificar y catalogar
requerimientos
En la prctica, la
trazabilidad se enfoca
en lneas base de
requerimientos.
90
Prctica corriente de trazabilidad
Cobertura
Links desde los

requerimientos hacia el
diseo, codificacin y casos
de test
Links hacia atrs: desde
test, codificacin y diseo a
requerimientos
Links entre requerimientos
en diferentes niveles
Proceso de trazabilidad
Asignar un nico ID cada

sentencia o prrafo
UNPSJB - 2005
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
Seguir los links

Encontrar links perdidos
Medir la trazabilidad total
91
Herramientas para trazabilidad
Cuales?
Hipertexto (links)
Limitaciones
Palabras clave que

identifican conceptos
asociados a ella
Identificadores nicos
Cada requerimiento tiene un Ej

ID nico con una BD de
Herramientas de BD (RTM,
referencias cruzadas
SLATE, DOORS)
Coeficientes de similaridad
sintctica
Todas requieren un gran

esfuerzo manual para definir
los links
Todas tienen informacin
puramente sintctica, sin
contexto semntico
Busca la ocurrencias de
patrones de palabras
UNPSJB - 2005
Herramientas de hipertexto
(document director, netscape
navigator)
Herramientas de desarrollo
general
92
Herramientas para trazabilidad
Limitaciones de herramientas
Problemas de informacin
por ej. No pueden decir

quien es el responsable de
determinado dato
Mala trazabilidad de prerequerimientos
Desde donde vienen los

requerimientos?
Falta de convenio
Comunicacin informal
Fallan en rastrear
informacin de trazabilidad
Sobre la cantidad y tipo de

informacin trazada
UNPSJB - 2005
La gente le da mucha
importancia la contacto
entre personas con
comunicacin 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
An con la herramienta no
es fcil encontrar las
personas que generaron el
requerimiento
93
Trazabildiad Cuestiones problemticas
Cuales son?
Cambio
Intervencin
Quin estuvo
involucrado en la
confeccin de los
requerimientos?
Notificacin
Responsabilidad
UNPSJB - 2005
Quien es responsable
por este req?
Quin es el
responsable actual?
En que punto de ciclo
de vida el
responsable cambia?
En que punto del ciclo

de vida se produce un
cambio o evolucin
de req?
Quien necesita ser
avisado por cambios
en los req?
Prdida de conocimiento
Cuales son las

ramificaciones
asociadas a la prdida
de conocimiento?
94
Validacin de requerimientos
Qu veremos
Dos problemas con la toma de

req.
Que es verdadero y que es

conocible?
El problema de la
negociacin
Negociacin sobre
requerimientos
El problema de la validacin
Como reconciliar conflictos

entre metas en un contexto
social complejo
Validar requerimientos
Inspecciones y revisiones
prototipeo
UNPSJB - 2005
Conflictos y su
resolucin
Tcnicas para
negociar
requerimientos
Aproximaciones para
argumentar
Aproximaciones
basadas en
conocimiento
Priorizacin de
requerimientos
95
El problema de validar
Aproximacin lgica
positivista
Hay un objetivo en el
mundo que puede ser
modelado construyendo un
cuerpo consistente de
conocimiento basado en
observacin emprica
En IR se asume que hay un

problema objetivo que existe
en el mundo
Construir un modelo
consistente (validarlo con
observaciones empricas)
UNPSJB - 2005
Usar herramientas que

testeen consistencia y
completitud del modelo
Usar revisiones, prototipos
etc para demostrar que el
modelo es vlido
Modificacin a la lgica
positivista (Popper)
Las teoras puede no

proveer cosas correctas,
se puede refutar
encontrando excepciones
Las teoras son cientficas
si pueden ser refutadas
96
El problema de validar
En IR, disear modelos

de req para ser
refutables
Ver por evidencia que
muestre que el modelo
es errneo
Aproximacin post
modernista
No hay punto de vista

privilegiado, todas las
valoraciones son
iguales
Usar actores para

que construyan sus
propios modelos de
requerimientos
Usar tcnicas
etnogrficas para
entender el
problema.
En IR, la validacin
siempre es subjetiva y
contextualizada
UNPSJB - 2005
97
Revisiones e inspecciones
Como tratarlos
Desde el punto de vista de la

formalidad
Informal: en una charla de
caf o en un reunin de
equipo
Formal:encuentros
programados, participantes
preparados, agenda
definida, formato especfico,
salida de documento
acordado
Administradores de revisin
Usados para proveer
certeza sobre el diseo
UNPSJB - 2005
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 inspeccin formal
Muy til para la etapa de

programacin
Programacin de aplicaciones
Ms efectiva que el testing

La mayora de los
programas corren bien la
primera vez
Datos desde grandes

programas
El factor de reduccin de
errores es 5.
Mejora la productividad en
un 15 a 25%.
UNPSJB - 2005
Efectos sobre competencia

del staff
Se encuentra entre un
60 y 80% de errores
durante la inspeccin
Reduccin de costo entre
el 50 y 80% para V&V.
Incrementa la moral
Mejor estimacin y
planificacin
Mejor administracin de
las habilidades del staff
Estos beneficios son tiles

para IR!!!!
99
Limitaciones de la inspeccin
Tamao
Suficiente gente de manera

que todos los expertos estn
disponibles
Mnimo 3 mximo 7 personas
Nunca ms de 2 horas (se

pierde objetividad y
concentracin)
Todos los revisores deben de

estar de acuerdo con los
resultados
UNPSJB - 2005
Reporte que resuma

el trabajo
Lista detallada de
aspectos relevantes
Alcance
Salidas
Todos los tem

evaluados deben estar
documentados
Duracin
Tomar pequeas partes,

nunca el todo
Timing
Examinar el producto
cuando el autor termina
con l.
100
Limitaciones de la inspeccin
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 sern muy
costosos de solucionar
Propsito
Obtener datos que ayuden a no cometer el error en

el futuro
UNPSJB - 2005
101
Guas para la revisin
Guas para la inspeccin
Antes de la revisin
Planificar las revisiones

formales (RTF) en el
plan del proyecto
Entrenar a los revisores
Asegurar que todos los
asistentes estn
preparados
Durante la revisin
Revisar el producto no
al autor
UNPSJB - 2005
Evitar comentarios
profesionales o
destructivos
Pegarse a la agenda
Limitar el debate y
la refutacin
Identificar
problemas pero no
tratar de
solucionarlos
Tomar notas escritas
Luego de la revisin
Revistar el proceso
de revisin
102
Eleccin de los revisores
Posibilidades
Especialistas en revisin
(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 organzacin
UNPSJB - 2005
A quien excluir:
Cualquier responsable
directo o indirecto del autor
Cualquiera con problemas
personales declarados contra
el autor
Cualquiera que no est
calificado en revisin
Todos los administradores
Cualquiera que tenga
conflicto de intereses
103
Estructuracin de la inspeccin
Se puede hacer la
estructura de la revisin
de varias formas:
Confiar en el experto
en revisin
Lista de chequeos
Revisiones activas
(escenarios)
Ad hoc:
Cada revisor lee con un

propsito especfico, usando
cuestionarios especializados
Diferentes revisores toman
diferentes perspectivas
Diferencias
Usar una lista de
preguntas o casos a
Los escenarios encuentran
revisar
mayores fallos que los otros
mtodos
A lista se hace a
No hay una diferencia
medida del
documento evaluado
marcada entre los dos
primeros
UNPSJB - 2005
104
Prototipacin
Definicin
Un prototipo de soft es una implementacin parcial

construida para permitir al cliente, usuario o
desarrollador aprender ms sobre el problema o su
solucin
Prototipar es el proceso de construir o trabajar
sobre el modelo del sistema
Respecto de definicin
Primera prototipo descartable

Segunda prototipo evolucionable
UNPSJB - 2005
105
Caractersticas de prototipos
Explicativo
Exploratorio
Determina el problema, evala necesidades, clarifica

metas, examina alternativas y evala ideas, es informal,
no es estructurado
Experimental
Explica, demuestra e informa, luego se avanza
Evala propuestas y el comportamiento del modelo
Evolucionario
Elige y refina soluciones, se usa como producto
UNPSJB - 2005
106
Clases de prototipos
Dos clases
Descartables
Evolucionables
Tercer opcin: operacionales
Descartables
Propsito
Uso
Aprender ms sobre el
problema o su solucin
Obtener conocimiento
Etapas tempranas o
posteriores
Aproximacin
Rpida y sucia
UNPSJB - 2005
Ventajas
Aprender el medio de
trabajo para lograr una
mejor adaptacin a las
necesidades y solucin
Entrega temprana, test
temprano, menos costo
Bueno an cuando falle
Desventajas
Derrochar esfuerzo si los
requerimientos cambian
rpidamente
Generalmente el
prototipo reemplaza
documentos
107
Evolucionables
Aprender ms sobre el
problema o su solucin
Reducir el riesgo de
construir partes del sistema
en forma temprana
Incremental, evolucionable
Aproximacin
Vertical: necesita desarrollo

riguroso e incremental
UNPSJB - 2005
Los requerimientos no
estn congelados
Solo se retorna al
incremento anterior si
se encuentra un error
Flexible ?
Desventajas
Uso
Ventajas
Propsito
Est en la otra punta

de los mtodos
estructurados
No se garantizan las
soluciones ms
efectivas
Poco control y direccin
108
Prototipos organizacionales
Ofrecen un balance entre los

casos anteriores
Pasos involucrados
Se crea un prototipo
evolucionable, basado en una
lnea base usando
metodologa clsica
(cascada)
La lnea base se enva a
varios clientes junto con
prototipadores
experimentados
El prototipador evala 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
rpidos en el prototipo
El usuario reutiliza el nuevo
prototipo
Se gira sobre el prototipo rpido
adaptndolo
Cada cierto tiempo el prototipo y
el prototipador retornan al
laboratorio para adaptar mejor el
prototipo (evolucionarlo)
Esto se repite indefinidamente
109
Acordando requerimientos
Aspectos
Negociacin y resolucin de conflictos

Entre requerimientos encontrados
Priorizacin de requerimientos
Definicin de conflicto
En la psicologa social, el foco es la

interdependencia y percepcin
La interaccin de gente intedependiente que
percibe en forma opuesta metas, objetivos o
valores, y como ve a la otra parte como
interfiriendo sobre sus objetivos.
UNPSJB - 2005
110
Acordando requerimientos
En IR, el foco es la inconsistencia lgica

El conflicto es una divergencia entre metas, hay
una condicin lmite 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 solucin
presentada
UNPSJB - 2005
111
Modelo de resolucin
Aproximacin usada
para dirimir el conflicto
Los mtodos incluyen
Negociacin
Competicin
Arbitraje
Coercin
Educacin
No todos los conflictos

necesitan un mtodo de
resolucin, as como no
todos los conflictos
necesitan ser resueltos
UNPSJB - 2005
Trs modelos de
resolucin
Cooperativo involucra
negociacin
Competicin
involucra combate,
coercin y competicin
Resolucin por terceras
partes arbitraje y
apelar a una autoridad
112
Modelo de resolucin
Negociacin
Competicin
Exploracin
cooperativa en el
rango de posibilidades
Los participantes
tratan de encontrar un
punto comn que
satisfaga a todas la
partes
Conocido como
integracin constructiva
o negociacin
constructiva
UNPSJB - 2005
Alcanzar la mxima
satisfaccin para el
participante
No tener en cuenta el
grado de satisfaccin
de las otras partes
No ser
necesariamente
hostiles
Caractersticas
Si yo gano, alguien
tiene que perder
113
Modelo de resolucin
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
decisin por factores
mas que por los casos
presentados
Arbitraria: tirar una
moneda
Licitar y negociar
Licitar
Los participantes
establecen sus
trminos deseados
Negociar
Los participantes
buscan por la
integracin
satisfactoria de sus
pedidos.
114
Conflictos en sicologa social
Causas de conflictos
Deutshc (1973)
Control sobre los recursos
Preferencias y estorbos (gustos o actividades de una
parte chocan contra otra)
Creencias (disputas sobre hechos, informacin, realidad)
La naturaleza de relacin entre partes
Robbins (1989)
Comunicacional (intercambio insuficiente de
informacin, ruido, percepcin selectiva)
Estructural (compatibilidad de metas, claridad
jurisdiccional, estilo del lder)
Factores personales (sistemas de valores individuales,
caractersticas de personalidad)
UNPSJB - 2005
115
Experiencias resultados
Algunos aspectos
observados
(hacer un mea culpa

respecto de la
realidad de cada uno)
Los conflictos son

normales en pequeos
grupos que toman
decisiones
Ms agresin y menos
cooperacin si se
restringe la
comunicacin
UNPSJB - 2005
Los grupos
heterogneos son ms
conflictivos (an si son
ms experimentados),
los grupos homogneos
son mejores para tomar
decisiones ms
riesgosas
El efecto de la
personalidad es
eclipsado por factores
de situacin o de
percepcin
116
mutualmente
exclusivos
Ay B
combinados
Satisfaccin de otras partes
Ay B
combinados
no
interfirientes
Para dos posiciones

iniciales A y B, se
puede medir la
severidad del
conflicto examinando
que sucede cuando
se combinan
N u e s tr a s a tis fa c c i n
Severidad sobre el conflicto
interfirientes
inclusivos
UNPSJB - 2005
Ay B
combinados
117
Clasificacin de conflictos sociales

Unidades
sociales
Igual vs igual
Jefe vs.
Subordinado
Todo vs. parte
Roles
Rol de familia
vs. Rol
ocupacional
Chicos y chicas
en una clase
escolar
Fuerza area vs
ejrcito
Rol ocupacional
vs. Rol de
unidad
Padre vs hijos
Administracin
vs unin
Personalidad
social vs. Rol de
familia
Familia ncleo
vs familia
ampliada
Departamento
vs facultad
Sociedades
Protestantes vs
catlicos
Hombres libres
vs esclavos
Estado vs
mafias
Relaciones
supra
sociedades
Bloque sovitico
vs primer
mundo
URSS vs
Hungria
CEE vs Reino
unido
Grupos
Sectores
UNPSJB - 2005
118
Teora del juego
Teora del juego en la

resolucin de conflictos
Ej: dilema del prisionero
Prisionero B
Dados
Dos o ms jugadores
Utilidades conocidas
para cada uno de los
jugadores
Puede calcular
Confiesa
un ao a cada
uno
10 aos para A
y 3 meses
para B
tres meses
para A y 10
aos para B
8 aos para
uno
Prisionero A
Confiesa
Cual estrategia
resulta en el mejor
resultado
Como interactan las
estrategias de los
jugadores
UNPSJB - 2005
No Confiesa
No Confiesa
Pero
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
119
Argumentacin
gIBIS
Desarrollado en 1989
Representa el proceso
de argumentacin como
un grafo hipertextual
Proceso bsico
Identificar usos
Identificar posiciones
que se pueden
adoptar con respecto
a las posiciones
Linkear argumentos
que soporte o refuten
posiciones
UNPSJB - 2005
Uso 1
responde a
Posicin 1
objeto de
Argumento 1
soporte
generaliza
preguntas
responde a
Uso 2
Argumento 3
Posicin 2
preguntas
Argumento 2
objeto de
objeto de
Argumento 4
es sugerido por
Uso 3
Argumento 5
Uso 4
120
Argumentacin
Sinptico
Propuesto por Easterbrook (1991)

Herramienta que soporta la negociacin
colaborativa enfocada en tareas
Proceso bsico (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
UNPSJB - 2005
121
Otros casos
Usando modelos pre-existentes
OZ
Desarrollado por Robinson

(1992)
Usa el modelo de dominio
preexistente para comparar
perspectivas de conflicto
Proceso bsico
Identificar perspectivas
(coleccin 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 satisfaccin 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 bsico
Entrar las condiciones de triunfo bsicas

de cada participante
Identificar estrategias de atributos para
condiciones de triunfo
Determinar efectos negativos para cada
estrategia sobre cada condicin de triunfo
Resolver manualmente las desaveniencias
122
Evolucin de Req. guas
El soft evoluciona
porque los
requerimientos
evolucionan
Familias de software
Guas
Administracin de
configuracin
UNPSJB - 2005
Lneas de productos
Puntos de vista
Leyes de la evolucin
del soft
Administracin
tradicional del cambio
Como marco para el

entendimiento de la
evolucin de
requerimientos
Administracin de
inconsistencia
Razonamiento sobre el
cambio
Rasgos ppales de la
interaccin
123
Tipos de programas
Programas
Especificables
Problemas que pueden

ser establecidos formal
y completamente
Aceptacin: el
programa est acorde
con su especificacin?
Este soft no evoluciona
Sentencias
formales del
problema
Mundo
Real
Un cambio en la
especificacin define
un problema nuevo,
entonces hay un
programa nuevo
UNPSJB - 2005
Programa
Solucin
124
Tipos de programas
Programas para solucin

de problemas
Sentencias imprecisas
del problema del mundo
real
Aceptacin: el programa
es una solucin
aceptable al problema?
El soft evoluciona
continuamente
Porque la solucin
nunca es perfecta, y
puede ser mejorada
Porque el mundo real
cambia y entonces el
problema cambia
UNPSJB - 2005
Mundo
Real
Cambia
Vista abstracta
del mundo real
Compara
Cambia
Especificacin
de
requeriminetos
Solucin
Programa
125
Tipos de programas
Programas
empotrados
Un sistema que es
parte del mundo al
que modeliza
Aceptacin: depende
enteramente de una
opinin 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
Especificacin
de
requeriminetos
Vista abstracta
del mundo real
Modelo
126
Leyes de la evolucin 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 contina hasta

que se crea que es mejor
tirarlo y hacerlo de nuevo
Incremento de complejidad
Conservacin de la estabilidad
Organizacional
La evolucin del soft es regulada

con tendencias y variantes
estadsticas
Durante la vida activa del soft, el

trabajo de salida de proyecto de
desarrollo es constante
Conservacin de la familiaridad
Durante la vida activa de un

programa el porcentaje de
cambios permanece constante
127
Crecimiento en requerimientos
Modelo de Davis
El usuario necesita
evolucionar
continuamente
El grfico presenta el
crecimiento de
necesidades en el
tiempo
Puede ser no lineal o
no continuo
El desarrollo tradicional
queda detrs de las
necesidades de
crecimiento
UNPSJB - 2005
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
Filosofa de mantenimiento
Alguien ms es el
responsable del
mantenimiento
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
Proceso de mantenimiento de Basili
Modelo fijo rpido
Modelo iterativo
Los cambio hechos a nivel de

cdigo, tan fcil como se pueda
Rpidamente degrada la estructura
del soft
Cambios hechos en base al anlisis
de soft existente
Trata de controlar la complejidad y
mantener un buen diseo
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
129
Adm. Tradicional de mantenimiento
Los administradores necesitan responder el

requerimiento de cambio
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
UNPSJB - 2005
130
Adm. Tradicional de mantenimiento
Elementos de la administracin
de cambio
Items de configuracin
Cada producto diferente

durante el desarrollo es un
tem de configuracin
Control de versin para cada
tem
Proceso de administracin de
cambio
Lneas base
Versin estable del documento

que puede ser compartida por
el equipo
Proceso de aprobacin formal
para incorporacin de cambios
UNPSJB - 2005
Todos los cambios

propuestos son enviados
formalmente como pedidos
El equipo de revisin toma
los pedidos de cambio y
decide o no su aceptacin
El equipo de revisin
considera la interaccin
entre cambios de
requerimiento
131
singularidad de productos
La mayora de las tcnicas de Lo anterior ignora la realidad

La IR no termina en la
IR se enfocan a modelos
especificacin
individuales
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
especificacin completa,
consistente y vlida
UNPSJB - 2005
Los requerimientos son voltiles,

se necesita administracin
continua de cambio
Las especificaciones nunca se
completan
No hay nunca solo un modelo

Hay mltiples versiones de
modelos en el tiempo
Hay mltiples variantes del
modelo que exploran diferentes
temas
132
singularidad de productos
Hay mltiples
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
UNPSJB - 2005
Como se administra el cambio

incremental del modelo de req?
Como se pueden comparar
mltiples 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
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 ms que solo
productos de soft
El desarrollo de soft reusable
es ms caro!!
Libreras de componentes
reusables
Desarrollo de programas
(Java, C)
Ingeniera de dominio
Divide el desarrollo del soft en

dos partes
Especficas de dominio (libreras

del Math)
UNPSJB - 2005
Anlisis del
dominio(identifica
componentes reusables del
dominio del problema
Desarrollo de aplicacin
(usa componentes de
dominio para especificar
aplicaciones)
134
Familias de Software
Familias de soft
Muchas
compaas ofrecen sistemas de soft

relacionados
Elegir una arquitectura estable para la familia
Identificar las variaciones entre diferentes
miembros de la familia
Representa
una decisin estrategia de

negocio sobre que soft desarrollar
UNPSJB - 2005
135
Puntos de Vista Motivacin
Mltiples
perspectivas
Muchos actores
diferentes
Diversas clases de
conocimiento del
dominio
Vistas conflictivas (y
negociacin)
Muchos esquemas de
representacin
UNPSJB - 2005
Modelado distribuido
Analistas y actores
colaborando
Mtodos mltiples de
modelado
Evolucin continua de
requerimientos
Links de
comunicacin
imperfectos
136
Puntos de Vista Motivacin
Demoras en la resolucin de
inconsistencias
Inconsistencias causas
Conflicto entre fuentes de

conocimiento
Diferentes interpretaciones
Problemas de comunicacin
entre desarrolladores
Diferentes velocidades de
desarrollo
Divergencias en los mtodos
previstos
errores
UNPSJB - 2005
Modelo simple con coercin de

consistencia es muy restrictivo
Se transforman en cuellos de botella
para el proceso de modelado distribuido
La coercin previene la divergencia de
ideas
Inconsistencias se dan en situaciones de
incertidumbre
Resolucin prematura puede conllevar
decisiones de diseo prematuras
La inconsistencia implica que se necesita
ms adquisicin de conocimiento
Algunas inconsistencias nunca sern
resueltas
137
Marco de trabajo bsico
El modelo de requerimientos
es una coleccin de puntos
de vista
Para cada PV identificar
Propietario
Dominio (que describe)
Estilo (notacin o reglas
utilizadas)
Plan de trabajo
(obligaciones de
consistencia con otros PV)
Historia de los cambios
Especificacin 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 mtodo provee un
conjunto de templates
designados para ser usados
juntos
138
Marco de trabajo bsico
Los PV contienen reglas de consistencia

Reglas
de consistencia internas para

chequeo de especificacin de PV
Reblas Consistencia externa para
chequeos entre PV
Plan de trabajo provee guas para
cuando aplicar cada regla de consistencia
UNPSJB - 2005
139
Ventajas de los PV
Actores y trazabilidad
Los propietarios de PV pueden

ser roles, personas, equipos...
Cada contribucin de un actor
es modelizada en una
notacin apropiada
Cada actor puede validar e

identificar su propia
contribucin
Se incrementa el concepto
de propiedad en el proceso
de requerimiento
Los requerimientos pueden

ser trazados hacia la fuente
de los mismos
UNPSJB - 2005
Estructuracin del
proceso de desarrollo
Cada PV es una pieza

independiente
No hay control global,
no hay esfuerzos
globales para
consistencia
Trabajo sincrnico o
asincrnico
Las reglas de chequeo
de consistencia actan
puntos explcitos de
sincronizacin
140
Ventajas de los PV
Estructuracin de descripciones
Las contribuciones de diferentes actores son

modelizadas por separado
Separacin de competencias
Enriquece el modelo a travs del uso de mltiples
estructuras de problemas
Resolucin de inconsistencias puede verse
demorada
Soporta negociacin permitiendo comparacin
detallada de PV
Anima el modelado temprano y expresin de vistas
diferentes
UNPSJB - 2005
141
PV hacia adonde???
Mtodo de ingeniera
Proceso de modelado
Mtodo de diseo
definir un conjunto de
templates coherentes
PV como una
herramienta Meta CASE
Administracin de
consistencia
Como presentar reglas

de consistencia inter PV?
UNPSJB - 2005
Cuando deberan ser aplicadas
Un proceso de modelado
de grano fino en cada PV
Como grafos
Como predicados sobre
estructuras de objetos
Como expresiones de lgica
de primer orden
Como pude la inconsistencia

ser reparada una vez
detectada?
Cuales son las consecuencias
de no repararlas?
Los PV asociados a actores con

sus contribuciones
142
Como aparece una

inconsistencia (como ya
vimos)
Conflicto entre fuentes de

conocimiento
Interpretaciones diferentes
Problemas de comunicacin
entre desarrolladores
Diferentes velocidades de
desarrollo
Divergencias entre los
mtodos utilizados
errores
UNPSJB - 2005
Definicin de inconsistencia
Dos partes de las

especificacin no obedecen la
misma relacin que est
definida para ellos
Las relaciones pueden unir
Elementos sintcticos de
especificacin parcial
Semntica de elementos en
especificaciones parciales
Subprocesos del proceso de
desarrollo
143
Las
relaciones surgen de:
Definicin de mtodos
Experiencia prctica con el mtodo
Contingencias locales durante el desarrollo
Las
inconsistencias pueden solamente ser

detectadas automticamente si las
relaciones estn definidas formalmente
UNPSJB - 2005
144
Inconsistencia
La inconsistencia est en la IS
Las descripciones de IS varian

mucho en formalidad y
precisin
Descripciones individuales
pueden ser formadas mal o
ser contradictorias
Las descripciones continan
evolucionando durante el
desarrollo
El chequeo de consistencia de
un gran conjunto de
descripciones es muy caro en
trminos computacionales
UNPSJB - 2005
Lecciones sobre inconsistencia

en la prctica
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 decisin riesgosa
Los factores de riesgo

cambian, el riesgo debe
reevaluarse continuamente
145
Inconsistencia
Algunas
chequeos de consistencias no
tienen la valoracin de performance
La
El monto de dinero para establecer la

consistencia donde se anticipa el cambio
inconsistencia es contradictoria
Ej:
Porque generalmente es vista como algo malo
Porque siempre se puede cuestionar la
formalizacin
UNPSJB - 2005
146
Conviviendo con inconsistencia
La deteccin 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

situacin pero que no
resuelvan la inconsistencia
Resolverla:
Si se necesita informacin
que no est disponible por el
momento
Mejorarla
Evadirla
Demorarla:
Negociar una solucin o

encontrar un compromiso
La inconsistencia indica,
normalmente, que se necesita
ms informacin
147
Modelo de proceso de inconsistencia
Localizar
Inconsisten
cia
Detectada
Ignorar
Caracterizacin
de
Inconsistencia
Identificar
Clasificar
Midiendo
Inconsistencias
UNPSJB - 2005
Tolerar
Resolver
Diferir
Evadirla
mejorarla
Analizando impacto y riesgo
consecuencas de
monitoreos de acciones
monitor para inconsistencia
reglas de
consistencia
Inconsistencia
Manipulada
148
PV para chequeo de consistencia
Quin 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
sincronizacin de PV
Como se expresan
responsabilidades?
Las reglas de consistencia

expresan relaciones que
deberan respetarse entre PV
UNPSJB - 2005
Cuando debera 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
149
PV para chequeo de consistencia
Como resolver
inconsistencias?
Las Acciones pueden no llevar

a una solucin
Las acciones surgen de los
mtodos de diseo y de
experiencias en su uso
Que sucede si no se resuelve

la inconsistencia?
Que sucede si cambios futuros

interfieren con la resolucin?
Deben quedar documentadas
Los cambios subsecuentes

pueden afectar a esa
inconsistencia
UNPSJB - 2005
Los chequeos exitosos no

garantizan las relaciones se
mantengan
Cada regla puede necesitar

ser aplicada un nmero de
veces durante el desarrollo
Los cambios que afectan

inconsistencias resueltas son
trazados
Las acciones involucradas en
la resolucin son guardadas
como parte de documentos
150
Ejercicios y trabajos
Investigar sobre las metodologas de anlisis 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 prototipacin.
(a partir del paper que deben leer)
Investigar sobre el estado del arte en la negociacin
de conflictos
Leer los papers:
E,F,H,I,O,P,Q,U,V,W
Buscar el paper Metodologas de Anlisis y Diseo
convencional y OO del material 2002-2003.
UNPSJB - 2005
151

Clase 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clase 3

Uploaded by

Copyright:

Available Formats

Ingeniera de Software

Por que modelar motivos

Especificacin vs. Modelado de

Contenido Clase 3 (cont.)

Negociacin ante problemas

Contenido clase 3 (cont.)

notacin que indique que hay un

Ing. de requerimientos es una agente

Los cuatro mundos

Dificultades para la adquisicin

Criterios para definir el dominio del

El conocimiento puede estar distribuido a lo largo

Las personas encuentran difcil decir que necesitan

Dificultades para la adquisicin

gente puede estar imposibilitada para

Problemas polticos o de seguridad

gente puede no querer decir que es lo

Tcnicas para toma de requerimientos

Mirar hacia dentro del

Tcnicas para toma de requerimientos

Puede obtener informacin

No hay entrevistas con

Puede obtener un contexto

Agenda abierta, no hay

Existe una agenda

Muchos datos cualitativos

Tcnicas de adquisicin en grupo

Puede crear grupos poco

Coleccin de datos complejos

Identificar los grupos de

Ejemplos propuestos tomar

Que es un caso de uso?

Cada forma diferente en que un actor interacta con

Caracterizacin detallada de todas las posibles

Usando Casos de uso

Dibujar los lmites

Identificar los actores

Identificar los posibles

Para cada caso de uso

Un ejemplo de caso de uso

Nombre: Orden de pedido

El caso de uso comienza con un pedido del cliente

La orden fue salvada en el sistema y fue marcada como confirmada

Pueden estar en modo

Muy natural: se tratan

Modelado de tareas y Escenarios

Son caminos a travs del modelo

Aproximacin basada en metas

Se enfoca en por que se

Usando aproximacin basadas en metas

Especificacin de cmo una meta

Objetivos de alto nivel de un

Los obstculos son

Las limitaciones son condiciones

Las metas se obtienen mejor de

Tcnicas adquisicin de conocimiento

Separar el dominio del

Por que KE es tan difcil??

Expertos no se utilizan para

Hay tres pasos para modelar el

Cognitivo (descripcin verbal de

Los mecanismos procedurales y

Los expertos no tienen un