Clase 3

Ingeniera de Software
Clase 3
Ingeniera de Requerimientos
(Toma, modelado, comunicacin,
aceptacin y mantenimiento)
Contenido Clase 3
Obtencin de requerimientos Modelizando el comportamiento
Tcnicas tradicionales funcional
Entrevistas y cuestionarios Modelizar funcionalidad
Escenarios y casos de uso Evolucin del Anlisis
Aproximacin cognitiva AE
Aproximacin contextual AOO
Modelizando Empresas y Tcnicas formales
metas Especificacin vs. Modelado de
Por que modelar motivos requerimientos
Tipos de modelo Algunos ejemplos
(investigacin)
Esquema conceptual
SCR
Diferentes modelos RML
conceptuales
RSML
Requerimientos no
funcionales
UNPSJB - 2005 Ingeniera de Software - Clase 3 2

Contenido Clase 3 (cont.)
Comunicando Validacin de
requerimientos requerimientos
SRS (soft Usos filosficos
requeriment Revisiones e inspecciones
Specification)
Prototipacin
Ambigedades y
como evitarlas Aceptando los
Estndares requerimientos
Trazabilidad de Negociacin ante problemas
requerimientos 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

Contenido Clase 3
Bibliografa utilizada
Ingeniera de Requerimientos
(Locoupulous)
Ingenira de Requerimientos (Davis)
Ingeniera de software (Pressman,
Sommerville)
Papers Varios

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 el problema / oportunidad

Toma de Requerimientos
Cual problema necesita ser resuelto? (identificar
lmites)
Donde est el problema? (el contexto o el dominio
La tcnica de del mismo)
las 6 W:
A Quienes involucra el problema? (identificar los
What? actores)
Por qu necesita resolverse? (identificar las metas
Where?
Who? de los actores)
Why?
Como debera ayudar el soft? (tomar o colectar los
When?
How (Which)? 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
Los cuatro mundos
Como el Como la mquina
sistema utiliza la representa
Mundo del
informacin inforamcin sob re el
sob re el dominio sujeto dominio de
de la aplicacin aplicacin
Mundo del Interfases de Mundo del

uso usuario sistema
Justificar las
Mundo del Desiciones de
metas de
desarrollo diseo
desarrollo

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

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

Tcnicas para toma de requerimientos
Tcnicas tradicionales
Introspeccin Grupos enfocados
Mirar hacia dentro del Brainstorming
problema JAD/RAD
Documentos existentes Prototipacin
Anlisis de datos Aproximacin basada en
Entrevistas representacin
Agenda abierta Basada en objetivos
Estructuradas Basada en escenarios
Cuestionarios Basadas en casos de
Adquisicin en grupos uso

Tcnicas para toma de requerimientos
Aproximacin Aproximaciones
contextual (social) cognitivas
Tcnicas etnogrficas Anlisis de tareas
Observacin de
Anlisis de protocolos
participantes
Tcnicas de adquisicin
Etnometodologa
de conocimiento
Anlisis de discurso Ordenamiento de
Anlisis de tarjetas
conversacin Grillas de repertorio
Anlisis de
Tcnicas de escalado
presentacin de proximidad
Diseo participatorio
Etnografa: ciencia que tiene por estudio y descripcin de las
razas o pueblos, como tambin su lengua, sus creencias,
UNPSJB - 2005 artesanas, usos,
Ingeniera costumbres
de Software - Clase 3y formas de vida 12
Cuestionarios
Ventajas Qu mirar?
Puede obtener informacin Tendencias en la seleccin
rpidamente de muchas de ejemplos
personas Tendencias en la seleccin
Puede administrarse de respuestas
remotamente Ejemplos de tamao chico
Puede obtener actitudes y (con poca significancia
caractersticas de los actores estadstica)
Desventajas Preguntas ambiguas
Puede obtener un contexto (muchos que no contestan la
muy pobre del problema misma pregunta)
No hay entrevistas con El cuestionario debe ser
usuarios testeado

Entrevistas
Tipos Difcil la comparacin de
Estructuradas respuestas
Existe una agenda Administrar las
previa con temarios entrevistas no es una
Libres tarea sencilla
Agenda abierta, no Que mirar?
hay temarios previos Preguntas sin
Ventajas respuestas
Ricas en adquisicin de Conocimiento tcito
informacin El contexto de discusin
Desventajas Actitud de los
Muchos datos entrevistados respecto
cualitativos difciles de de los temas abarcados
analizar

Tcnicas de adquisicin en grupo
Tipos
JAD o RAD Desventajas
Enfoque en grupo Puede crear grupos poco
Brainstorming naturales y hacer sentir
incmodos a los participantes
Ventajas
Peligro de llevar a una opinin
Interaccin ms natural de grupo que no sea real
entre la gente, mayor a
una entrevista formal Pueden obtenerse respuestas
superficiales a cuestiones
Se puede medir la tcnicas
reaccin ante material
de estmulo Se requiere de un facilitador
muy entrenado
Presentaciones,
maquetas, etc. Que mirar?
Tendencias en los ejemplos
Dominancia y submisin
Coleccin de datos complejos
Identificar los grupos de Ejemplos propuestos tomar
aquellos considerados ms
estos datos relevantes
Hechos y figuras, Ejemplos aleatorios tomar
informacin financiera, etc. cada n casos
Reportes usados para toma Ej. Aleatorios por capas
de decisiones,... identificar capas del problema
Resultados obtenidos, y tomar un caso de cada uno
informacin de marketing,.. Ej. Aleatorios por cluster
Ejemplos generar subconjuntos
relacionados y tomar un
Obtener datos ejemplo de l.
representativos del
Tamao del ejemplo
conjunto de la poblacin de
elementos Balancear entre costo y
relevancia del ejemplo

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

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

Usando Casos de uso
Dibujar los lmites
Identificar los actores Para cada caso de uso
fuera de los lmites del Escribirlo
sistema que Especificar reglas para
interactan con l eleccin del mismo y para
Para cada factor interacturar con l
Considerar alternativas
Identificar los
posibles casos de uso Ver posibles superposiciones
de casos de uso
Establecer escenarios
concretos para Template de caso de uso:
ilustrar cada caso de
Nombre:
uso
Resumen:
Agrupar escenarios Actores:
similares en casos de Precondiciones:
uso si son una Descripciones:
variacin sobre un Excepciones:
tema Postcondiciones:
Un ejemplo de caso de uso
Nombre: Orden de pedido

Precondicin: un usuario vlido est conectado al sistema
Descripcin:
El caso de uso comienza con un pedido del cliente Orden de pedido
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 Tomar Estado
solicitada
El sistema indicar el nombre del producto y el precio unitario del mismo
El sistema totalizar la cantidad de productos pedidos y el total de la venta Cliente
Enviar catlogo
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 Cancelar orden
Una vez confirmado el pago, la orden se cambiar a confirmada y se le indica

esto al cliente, el caso de uso finaliza Delivery
Excepciones: Enviar producto
En el paso 9, si hay informacin incorrecta, el sistema le preguntar al cliente

que quiso poner
Postcondiciones: Re-Adquirir
La orden fue salvada en el sistema y fue marcada como confirmada producto Proveedor

Escenarios
Definicin Ventajas
Secuencia especfica de Muy natural: se tratan
interacciones entre de usar de manera
actores y sistemas expontnea
Tienden a ser cortos Los escenarios cortos
Puede sen son muy buenos para
Positivos ilustrar interacciones
(comportamiento especficas
requerido) Desventajas
Negativos (interaccin Falta de estructuracin:
no deseada) se necesitan casos de
Pueden estar en modo uso o modelo de tareas
indicativo u optativo para proveer una visin
de alto nivel.

Modelado de tareas y Escenarios
Modelado de tareas: Escenarios
Conjunto jerrquico de Son caminos a travs del modelo
actividades estereotpicas de tareas, tomando una secuencia
Los subojetivos son especfica en tiempo de pasos
tareas (o casos posibles Puede ser usado para organizar
de uso) requerimientos
Pueden ocurrir en Puede incluir paralelismo
secuencia, en paralelo o Excepciones
como alternativas
Son variantes de casos de uso
Pueden ocurrir
peridicamente o en No pueden ser modeladas como
respuesta a escenarios en si mismo,
contingencias. interactan con mltiples
escenarios

Aproximacin basada en metas
Aproximacin Ventajas
Se enfoca en por que se Razonablemente
construye el sistema
intuitivo
Se expresa el por que como
un conjunto de metas La declaracin explcita
Se usa refinamiento de metas de metas provee una
para arribar a requerimientos base para la solucin de
especficos conflictos
Anlisis de metas Desventajas
Documentos, organizacin y Difcil de seguir la
clasificacin de metas evolucin
Evolucin de metas
Refinar, elaborar y poner
operativos

Usando aproximacin basadas en metas
Metas Las limitaciones son condiciones
Objetivos de alto nivel de un sobre la realizacin de una meta
negocio u organizacin Consejos
Requerimiento Las metas se obtienen mejor de
Especificacin de cmo una meta mltiples fuentes
debe estar en un nuevo sistema
Asociar actores a cada meta
Tipos (revela puntos de vista y
Metas de realizacin conflictos)
Metas de mantenimiento

Usar escenarios para explorar
Metas soft

como los objetivos pueden ser
Obstculos y limitaciones alcanzados
Los obstculos son Consideraciones explcitas sobre
comportamientos que obstculos puede ayudar a
previenen la realizacin de
una meta dada construir o definir excepciones.

Tcnicas adquisicin de conocimiento
Base: Problemas de modelado
La toma de Es muy frgil,
conocimiento est para pequeos casos
ligada con el de uso
descubrimiento Problema de
experto de representacin
conocimiento Inadecuado
Ligado con el epistemolgicamente
crecimiento de los Expresividad vs.
sistemas expertos Facilidad de adquisicin
Mtodos formales
KE es dura
Separar el dominio del
conocimiento de la
performance del
conocimiento
Por que KE es tan difcil??
Expertos no se utilizan para Problemas de representacin
describir que hacen Los expertos no tienen un
lenguaje para describir el
Hay tres pasos para modelar el conocimiento
aprendizaje Los lenguajes hablados no
Cognitivo (descripcin verbal tiene la suficiente precisin
de las tareas) diferentes representaciones de
Asociativo (reforzar las ideas conocimiento son buenas para
con repeticiones de dichos cosas diferentes
verbales) Ventaja
Autnomo (compilado, no son El conocimiento se crea, no se
concisos) extrae
Los mecanismos procedurales y Son abstracciones de la
declarativos son diferentes realidad
El conocimiento declarativo se Se crea travs de

suposiciones simples
torna procedural con Tiende a tener menos errores
aplicacin repetida, los o problemas
expertos no pueden hacer
esto fcilmente

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

El nivel del conocimiento
Ver el modelado del
conocimiento como: Modelo el nivel
de conocimiento
Observar el comportamiento de
racionalizacin
un agente como una caja negra Ambiente
Acta como si tuviera
Comportamiento
conocimiento sobre el
ambiente que utiliza Observacin
Construir dos modelos

Nivel simblico: descripciones Observador
del mecanismo del (modelador)
comportamiento
mecanizado
Nivel de conocimiento: Agente
descripciones del
conocimiento del agente del Modelo de nivel
de smbolos
mundo real

Algunas tcnicas de toma de conocimiento
Anlisis de protocolo Ayuda a construir modelos
Basadas en vocalizar el mentales,
comportamiento Pueden adquirir conocimiento
tcito
Ventajas
Desventajas
Forma verbal de las
actividades cognitivas Requiere una aceptacin del
conjunto de objetos
Dentro del contexto
Difcil de lograr
Desventajas
No tienen dimensin social Ordenamiento de tarjetas
Basada en introspeccin Para un conjunto de objetos de
dominio escribirlos en tarjetas para
Tcnicas de escala de ordenarlas en grupos
proximidad Ventajas
Dado un dominio, derivar un Simple y fcil de automatizar
conjunto de dimensiones para
clasificarlo Desventajas
Ventajas: Las entidades necesitan ser
identificadas dentro de semnticas
a lo largo del dominio
Ontologa: parte
de la metafsica,
Abstraccin vs. contextualismo que estudia el ser

en general y sus
propiedades
trascendentales
Abstraccin: Contextualismo
Construye modelos Pone nfasis en los
abstrayndolos del dominio, detalles e idiosincrsia
el modelo puede contestar del dominio
preguntas Obtener datos
Decidir sobre la ontologa naturales del dominio
del fenmeno que se quiere de estudio
describir Usar los datos para
Se asume que el dar explicaciones
conocimiento y el Asume que es imposible
entendimiento son construir modelos que
independientes del contexto tengan comportamiento
Utilizado normalmente por cuando se remueven
cientficos naturales e del contexto
ingenieros Usado por muchos
cientficos sociales
Etnologa: ciencia que
estudia el origen, la
distribucin y los
caracteres fsicos de las
Visin etnometodolgica razas humanas
Se necesitan tcnicas que cubran el

La toma de requerimientos es orden del mundo social
una actividad social Este puede no ser obvio o
Porque involucra comunicacin describible
entre personas (discusiones, No se puede asumir con estructura
previa
observacin de la realidad, etc) El mundo social solo puede
Porque involucra negociacin entenderse si uno se mete en l
para lograr consensos Es construido a partir de acciones
de los participantes
Porque afecta y cambia los
No se puede tomar informacin de
sistemas de actividad humana categoras preestablecidas
El dominio de una aplicacin es, Se necesita considerar
gralmente, un mundo social Como los significados se
desarrollan y evolucionan en el
contexto
Los mtodos pblicos utilizados
para que el contexto tenga sentido

Etnometodologa
Categoras:
Bases: Las tcnicas
El mundo social es ordenado convencionales suponen
El orden social puede no ser categoras
obvio y no descriptible preexistentes
desde el sentido comn La Etnografa intenta
El orden social no puede utilizar sujetos con
asumirse con estructura categoras propias
previa Medidas
Se enfatiza la importancia No tienen objetividad
de las bases naturales. cientfica, por ende los
sujetos deben crear su
propia fuente de
medicin.

Observacin de participantes
Bases: Desventajas
Los observadores Consume mucho
pasan un tiempo con tiempo
los sujetos, tratando Se tiene mucha
de convertirse en un informacin que
miembro ms del puede resultar difcil
grupo de analizar
Ventajas No se puede decir
Contextualizacin mucho de cambios
Se revelan detalles que se propongan
que otros mtodos no
pueden cubrir

Por que modelar?
De ingeniera:
El modelado mtodos formales de
actividad de definicin formal construccin
de aspectos del mundo fsico Modelado
y social que nos redea con el
se hace sobre los
propsito de entender y
cuatros dominios de
comunicar
informacin
Actividad de modelado Empresa
Combinar problemas Uso
Empricos: especificaciones Sistema
ligadas al mundo real Desarrollo
Formales: abstraccin,
estructura y representacin Especificacin
del conocimiento del conceptual
problema Entender un dominio
especfico de
informacin
Motivacin del modelado
Suponga que se entrevistaron varios
actores de un problema relacionado Agente de viajes
a una aerolnea Un agente es responsable de
reservas y cancelaciones
Jefe ejecutivo Hay diferentes tickets ofrecidos
Cuando el vuelo est lleno, primero a las agencias de viaje
se atiende a los VIP Jefe de Catering
Hay tickets de descuento para La comida cargada est
polticos podremos obtener relacionada con la nmero de
ventajas personas
La informacin debe resultar Se debe conocer el nmero
clasificada para actores externos al aproximado de personas en el
vuelo 24 hs antes.
problema Tambin 24 hs antes se debe
Jefe de seguridad saber por comidas especiales
El nmero de valijas en el avin Administrador de ventas
debe corresponder al nmero de Solo se puede usar un ticket
personas que abordan pago
Las listas de pasajeros son En algunos casos puede no
informacin restringida confirmarse la reserva
Solo se puede hacer el check in una Un tckets de descuento no
puede devolverse
UNPSJB vez
- 2005 Ingeniera de Software - Clase 3 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.?

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?

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

Requerimientos para el esquema
conceptual
Independencia de implementacin Fcil de analizar

No modelar representacin de Para detectar ambigedad,
datos, organizacin interna, etc. inconsistencia, incompletitud
Abstraccin Trazabilidad
Tomar solo aspectos principales Habilidad para seguir los
(cosas que no cambien) elementos del modelo
Formalidad Ejecutabilidad
Sintaxis no ambigua Poder animar el modelo, para
Rico en semntica comparar con la realidad
Constructibilidad Minimalidad
Debe facilitar la comunicacin No redundancia de conceptos
analista usuario (cada cosa expresada de una
forma)

Tcnicas de modelado
Modelado de informacin (DER)
Modelado de empresa Modelado de organizacin (i*,
Metas y objetivos SSM, ISAC)
Estructura organizacional Modelado de metas: (KAOS)
Actividades, procesos y productos
Roles y trabajos de agentes
Anlsis estructurado (Yourdon,
Modelado de requerimientos Martin, etc)
funcionales
Anlisis OO (Coad, Boock,
Vistas estructurales (de datos) UML)
Vistas de comportamiento
Requerimientos de tiempo Mtodos formales (SCR, RSML,
Z)
Modelado de req. no funcionales
De productos, de procesos y externos QFD, Redes de petri
(performance), Modelo de
tareas (disponibilidad)

Modelado de requerimientos de empresa
Evolucin en el tiempo
70
Resolver los sistemas de soft
Involucrando toda la organizacin
Sensitivo al contexto social y poltico para el cambio organizacional
Tcnicas: SSM, ISAC
80
Basdados en conocimiento
Usar representacin del conocimiento para construir modelos de dominio
ejecutables
Capturan aspectos estticos y dinmicos del dominio
Tcnicas: RML
90 Teleologa: doctrina de
Teleolgicos las causas finales
Los requerimientos son metas y se pueden modelizar jerarquas
Se enfocan en el por qu? Ms que en el qu?
Ejemplos: KAOS, I*

Revisin de modelos: ER, ISAC
ER se obvia Proceso ISAC
ISAC (information Anlisis de cambio
systems work & analysis Que quiere la organizacin?
of Change) Cuan flexible es la organizacin
respecto a cambios?
Desarrollado en el 70 en Estudio de actividad
Suecia
Que actividades deben reagruparse
Pondera la cooperacin en sistemas de informacin?
entre usuarios y Que prioridades tienen los sistemas
desarrolladores de informacin?
Los desarrolladores son Anlisis de informacin
facilitadores Que entradas y salidas tienen cada
Bueno para SI pero no SI?
aplicable a problemas de Qu son los requerimientos
control cuantitativos del SI?
Implementacin
Que tecnologa se utilizar para el SI
(hard, y soft)?
Que actividades del SI sern
automticas o manuales?
Revisin de modelos: ISAC-Elementos
Lista de problemas Anlisis de metas
Insatisfaccin con los sistemas
corrientes Sentencias declarativas de metas
Listar los problemas Resultado deseado, no como
Remover aquellos triviales o obtenerlo
imposibles Meta final rbol de metas
Lista de grupos de inters
Dibujar una matriz de problemas para Definir necesidades de cambio
contrastarla con los propietarios de Las metas deben explicar por qu
los mismos existe el problema
Anlisis de problemas Generar alternativas de cambio
Anlisis de causa efecto
Evitar soluciones orientadas a Modelo de situaciones deseadas
problemas Hacer paquetes de alternativas para
Llevados a cabo por especialistas el cambio
Cuantificar el problema
Evaluar alternativas
Modelo de actividad corriente
Esquemas A (similar a diagramas de Elegir una alternativa
flujo de datos)
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

Revision de modelos: SSM
Pasos de la metodologa 5. Compara el modelo
1. Situacin base (problema no conceptual con el paso 2
estructurado) Preguntas ordenads sobre
2. Anlisis del problema el modelo
dibujo del mismo Reconstruccin de
temas que abarca el problema eventos para compararlas
3. Definir aspectos relevantes del con el modelo
sistema y su raz Comparacin general para
Descripcin de la actividad mirar rasgos del modelo
humana diferentes de la situacin
actual
4. Construir el modelo conceptual 6. Debate sobre la factibilidad
Actividades del sistema del cambio
necesarias para llevar a cabo la
transformacin Tres tipos de cambio:
estructural, procedural y
Modelo orientado al proceos, con de actitud
actividades y flujo de recursos
7. Implementar los cambios

Revision de modelos: i*
Rasgos Caractersticas
Desarrollado en los 90 El modelo de dependencia
Provee una estructura para muestra las dependencias entre
preguntar POR QU actores objetivo obtener un
Modela el contexto de la mejor entendimiento de los por
organizacin para SI qu?
Basado en la notacin de actor Dependencia entre metas y
submetas (un actor depende
Dos partes del modelo
de otro actor para alcanzar
Modelo de dependencia una meta)
estratgica (relaciones entre
Dependencia de recursos (un
actores)
actor necesita un recurso de
Modelo estratgico racional otro actor)
(modela intereses e incumbencias
de actores)

AttendsMeeting
(p,m)
D
D
Dependencias de D
ExclusionDate
D participante
tareas (un actor
(P)
PreferredDate D del
D (P) encuentro
necesita otro actor

Iniciador
del D
encuentro
para llevar a cabo la

ProposedDate
D (M) D
ISA
tarea)
Agreement
D (M,P)
X D
EJ: supongamos una D AttendsMeeting
(ip,m) D
participante
importante
agenda para la del

encuentro
concurrencia a una Assured(A
cita particular (ver ttendsMeet D

ing (ip,m)
como evoluciona en
D D Dependencia de metas
el paper D D dependencia de recueros
correspondiente) D D dependencia de tareas
Dependencia de metas
D D soft
O Opend (uncommited)
UNPSJB - 2005 Ingeniera de Software - Clase 3 X Criticas 47
Participante
Modelo racional muestra Iniciador

del
del
encuentro
interacciones entre metas encuentro

ParticipateIn
dentro de cada actor D
Attends
Meeting D
Meeting
Arrenge
Muestra nivel ms detallado Organize Attend
meeting Meeting Convenie
nt(m e e tin
Meeting
del modelado mirando Quick Low

Quality
+ g, Date )
Agreable
Low
dentro de los actores para

MeetingBe (propos e d Effort
Schedule Effort DAte ) (meeting,
- Date) +
modelizar sus relaciones -
Schedule
Exclusion + Find Us e r
+
internas
Meeting Frie ndly
Obtain D Dates D Agreable - M in
Date
Find AvailDate D - Inte rrupt
Muestra la descomposicin
Obtain Preferred ion
Suitable D
Agreement D Dates
Slot
de tareas Merge
Proposed
Date D
Agree To
Muestra los links entre

AvailDate D Date
D
Agreemen
tareas y metas Meta

t
SR provee una forma de

Cecurso
Meta Soft
modelar actores Tarea
interesados, como deben

Tarea - link de descomposicn
Link means-end
encontrarse la forma de
-+
contribucin a meta soft
evaluarlos
Conclusiones sobre i*
Ganar entendimeinto en los Resumiendo
requerimientos del sistema Mejor representacin y
Mayor nmero de niveles de razonamiento del

anlisis en trmino de conocimiento
Habilidad Mayor nivel de
Viabilidad
formalidad en las
expresiones
Credibilidad de
Se incorpora
requerimientos
intencionalidad
relaciones mltiples y
distribuidas de
intencionalidad

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

Revision de modelos: KAOS
Caractersticas Identifica
El mtodo se centra en obstculos a las
la elaboracin de metas metas y conflictos
Define un conjunto entre metas
inicial de metas y
objetivos de alto nivel Lleva las metas a
Define un conjunto limitaciones que
inicial de agentes y pueden ser luego
acciones que estos asignadas a
agentes pueden hacer agentes
Luego iterativamente individuales
Refina las metas
usando una Refina y formaliza
descomposicin las definiciones de
denominada AND OR objetos y acciones

Modelado y anlisis
Anlisis de sistemas Una perspectiva
varias escuelas externa que modela el
Anlisis orientado a contexto o entorno del
datos sistema
Anlisis estructurado Una perspectiva de
comportamiento del
Anlisis OO sistema
Modelos se utilizan Una perspectiva
para desarrollar una estructural que modela
comprensin del sistema la arquitectura del
a realizar tres vistas: sistema o la ED
procesados por este

Anlisis estructurado
Definicin Se deben entender los
requerimientos necesarios para
Proveer un marco de trabajo continuar en la evolucin del
para modelar de forma sistema
detallada el sistema como parte
Debilidades
de la 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
SI usuarios

Conceptos centrales Entidad externa
Transformacin de datos Actividad fuera del
Actividades que transforman alcance del sistema
los datos Fuente o destino de
Flujo de datos info en los DFD
Indica el paso de datos de la No pueden
entrada del mismo hacia la interactuar
salida directamente con los
Representa grupos de datos o almacenes de datos
elementos de datos
Grupos de datos
Almacenamiento de datos
Clustes de datos
Lugar donde se deja info para
su uso posterior representados como
un flujo de dato
Los almacenes de datos son
pasivos, no transforman los simple
datos Elemento de dato
Unidad bsica de
informacin
Herramientas de modelado Diccionario de datos
DFD Define cada
Diagrama de contexto elemento de dato
Diferentes niveles de Usa una notacin
descomposicin BNF para definir la
Llegar hasta primitivas estructura de los
funcionaels que no pueden elementos
ser ms descompuestas
Constructores
Elementos
Procesos
Flujos Construccin Notacin Significado
Almacenes de datos = Est compuesto de
Entidades externar Secuencia + Y
Seleccin [|] O bien
Repeticin { }n N repeticiones de
() Datos opcionales
** Delimita comentarios

Especificacin de procesos
cdigo en lenguajes narrativo o en algn
pseudo cdigo
Define los rasgos procedurales escenciales
Evoluciones
DFD evolucion para poder representar TR

Anlisis OO
Conceptos bsicos Motivacin
Se modela los requerimientos AOO es ms natural
en trmino de objetos y los El sistema evoluciona las
servicios que estos proveen funciones que realiza tienden
a cambiar los objetos
Representan los datos y su permanecen iguales
procesamiento Esto no es representable con
Muestra de una forma clara AE (debe cambiarse)
como se clasifican las entidades El trabajo con OO es ms
del sistema y como se mantenible
componen (de otras entidades) Mayor nfasis en definir
correctamente interfases entre
Son una forma natural de
objetos
reflejar al mundo real (objetos)
Comparado con la
ambigedad de los DFDs

Anlisis OO
Primitivas de modelado Relaciones
Objetos Dos tipos:
Todo parte
Entidades con estados, Es un
atributos o servicios Mtodos o servicios
Clases Operaciones que un objeto
Forma de agrupar objetos puede llevar a cabo
Abstracciones jerrquicas con Pasaje de mensajes
una relacin ES_UN Forma de invocar los mtodos o
Atributos servicios
Representan estados del Escenarios y casos de uso
Secuencia de pasaje de
objeto
mensajes entre objetos
Pueden especificar: tipo,
Representan interacciones
visibilidad y modificacbilidad especficas

Anlisis OO
Conceptos fudamentales
Herencia
Simple o mltiple
Ocultamiento de informacin
Agregacin
Puede describir relaciones entre las partes y el
todo

Anlisis OO
Que cosas pueden ser objetos Roles
Llevados por personas que
Entidades externas interactan con el sistema
Que interactan con el Unidades organizacionales
sistema a modelizar Relevante a la aplicacin
(personas, dispositivos, otros (deptos, divisiones, equipos)
sistemas) Lugares
Cosas Que establecen el contexto
del problema
Que son parte del dominio Estructuras
que se modeliza (reportes, Que definen una clase
seales) (sensores, computadoras)
Ocurrencias o eventos Los procedimientos (imprimir,
Que pueden ocurrir en el copiar) y los atributos no son
contexto del sistema objetos
(transferencias de recursos,
acciones de control)
Anlisis OO
Caractersticas de seleccin Requisitos esenciales
de objetos deben Entidades externas
Retener informacin que aparecen en el
atributos espacio del
Servicio necesario problema y
Operaciones identificables producen o
Atributos mltiples consumen
No tener uno solo informacin
Atributos comnes
Aplicables a todas las
Los objetos vlidos
ocurrencias del objeto no debe satisfacer
solo a uno
todas o casi todas
las propiedades
anteriores.
Anlisis OO
Variantes para el AOO
Coad- Yourdon
Dcada del 80
Cinco pasos de modelado

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

Anlisis OO
Objeto Paciente Paciente

Nombre Nombre
Atributos Fecha de nac Fecha de nac
Altura Servicio Altura
Peso Peso
Clasificacin todo parte 1,m

1,m
Mandatario 1,m
1
1
Ingreso Alta paciente 1
paciente Class Class Class
medico
Cama ltima visita Attribute Attribute Attribute
Habitacin
Service
Service Service Service Service

Anlisis OO
AOO de Shlaer y Mellor

Proceso de seis pasos
Desarrollar un modelo de Definir la dinmica del
informacin sistema
Con objetos, relaciones y
Producir un modelo de
atributos de objetos y
tiempo y control a nivel
relaciones
del sistema
Definir el ciclo de vida para
Desarrollar modelo de
los objetos
procesos
Definir la dinmica de Para cada accin un
relaciones diagrama de accin y
Modelo de estado para flujo de datos
relaciones entre objetos que
Definir dominios y
evolucionan en el tiempo
subsistemas
Descomponer en partes
Anlisis OO
UML Diagramas de clases
Unified Modeling Languaje Diagramas de casos
La ltima generacion de de uso
mtodos OO Diagramas de
Desarrollado pro Booch, caminos de mensajes
Rumbaugh y Jacobson
Diagramas de
An en desarrollo
Trata de estandarizar los
mensajes de objeto
conceptos de modelado OO que Diagramas de estados
manejan varios autores
Diagramas de
Es una notacin aceptada
mdulos
como estndar
Tiene un meta modelo Diagramas de
estandarizado, compuesto por plataformas
Lo desarrollaremos en la
clase 5 ntegramente.
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

Mtodos formales en IR
Qu formalizar en IR? Permitirnos razonar sobre los

Modelar el conocimiento de los requerimientos
requerimientos (se puede Chequear propiedades
razonar sobre ellos) automticamente
Testear consistencia, explorar
Especificar requerimientos (se
consecuencias
puede hacer una
documentacin precisa) Permitirnos animar y ejecutar los
requerimientos
Por que formalizar?
Ayuda en la visualizacin y validacin
Para remover ambigedad y
mejorar precisin Se podr formalizar eventualmente
Proveer una base para la cualquier cosa
verificacin de lo que los IR es un puente desde el mundo
requerimientos deben conocer informal hacia el dominio formal de
mquina

Por qu no se formaliza? La gente no sabe que
Los mtodo formales tienden herramientas son
a ser de un nivel ms apropiadas
complejo que los otros Especificacin de
mtodos comportamiento de
Incluyen mucho detalle programa vs.
Modelado de
Tratan de concentrarse en la
requerimiento
consistencia y correctitud del
modelo Los mtodos formales
requieren un esfuerzo
Normalmente modelizamos
inconsistencias,
mayor
incompletitudes y cosa Y la remuneracin
incorrectas es la misma....

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
Pruebas formales: usan axiomas y reglas de prueba
para demostar que alguna frmula est en el lenguaje

Anlisis formal clases

Anlisis de consistencia y chequeo de tipos
Validacin
Predecir comportamiento
Verificar refinamiento de diseo

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

En que difieren los Ejemplos
mtodos formales SCR: fijo, lgica
Ontologa temporal, modelo
Puede ser fija o estado evento
extensible
RML: fijo, lgica de
Base matemtica
Lgica (predicado de predicado de
primer orden) primer orden,
Otra (lenguajes modelo estado
algebraicos o teora evento discreto
de conjuntos Z)
Telos: extensible,
Tratamiento del tiempo
tiempo como un
Modelos estado-
evento
objeto primario.
Tiempo como una
objeto primario
Tres tradiciones de lenguajes Basados en sistemas reactivos

(TR)
Lenguajes formales de
Chequeo de consistencias,
especificacin chequeos de modelo
Grueso del trabajo en Ej: RSML, SCR
verificacin de programas Modelado formal conceptual
Chequeo de tipos, prueba de Capturar conocimiento del
teoremas mundo real
Ej: Z, VDM Pone nfasis en modelado de
Modelado de sistemas reactivos entidades del dominio,
actividades, agentes y
Formalizan modelos dinmicos aserciones
de comportamiento de Motores de inferencia,
sistemas razonamiento por defecto
Ej: Telos, RML
Comunicando requerimientos
SRS (soft req. Specification)
El problema es como SRS

comunicar los Propsito
requerimientos al resto de Comunicar los requerimientos de

forma clara
los interesados Se explica el dominio de la aplicacin
El SRS hace esto y del sistema que se va a desarrollar
Veremos Contractual
Es un elemento legal
como construirlo, Expresa un acuerdo
los problema que Lnea base para la subsecuente
pueden surgir, evolucin de productos
Estndares de Soporta testeo, verificacin y
construccin validacin de sistemas
Puede contener informacin para
verificar que se alcancen los
requerimientos

Lnea base para el control de Desarrolladores y

cambios programadores
Cambio de requerimientos Tienen que implementar
Evolucin del soft los requerimientos
Audiencia a quien se dirige Testers
Usuario, clientes
Determinan que
requerimientos han sido
Ms interesados en los
alcanzados
requerimientos
No interesados en req. del soft Administradores de
Analistas de sistemas
proyectos
Miden y controlan el
Escriben especificaciones que
interactan
proceso de anlisis y
desarrollo del sistema

Quin lo escribe
El proveedor
Debe ser general para tener una buena seleccin de
pedidos
Debe dejar de lado los pedidos no razonables
El oferente
Debe ser especfico para demostrar credibilidad y
competencia tcnica
General para evitar sobre compromiso
El desarrollador seleccionado
Refleja el entendimiento del desarrollador
Base del desarrollo

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 Representa el entendimiento del Construye un documento, debe contener

Especificacin programador, vuelve al cliente mucho detalle para todos los pgmdor
Vista de La especificacin es irrelevante, se Se debe usar la espec. para estimar recur-
administracin tiene alocados los recursos sos necesarios y plan de desarrollo.
lectores 1 autor de especificacin 1 programadores, equipo V&V, adminis
2 cliente 2 clientes
Como hacer una especificacin
Aspectos Necesario
No contener cosas que no se
Validez (correctitud) requieren
Expresar los req. Actuales No ambiguo
Completitud Cada sentencia se lee de una sola
Especificar todo lo que el
forma
sistema necesita y debe Definir trminos confusos en un
hacer glosario
Responder a todas las Verificable
entradas posibles Test de satisfaccin por cada cliente
debe existir
Completitud estructural
Cada req. Es especificado con
Consistencia comportamiento
No contradecirse Entendible (claro)
Usar trminos de manera Por especialistas no informticos
consistente Modificable
Debe mantenerse actualizado
Las especificaciones problemas
expandidas
expanden
Que puede suceder
ambiguas
condensadas
Redundantes
formalizan inconsistentes
Ambiguas redundantes
No entendibles reducen agrega no Resuelven
Inconsistentes
explicacin entendibles

incompletas
incompletas

Errores tpicos de especificacin
Ruido Referencia hacia delante
Tener texto poco relevante como Utilizar un concepto an no definido
contenido Pensamiento deseado
Silencio Texto que define un rasgo que no
Rasgo importante no cubierto en el puede ser validado
texto Puzzles
Sobre especificacin Desparramar requerimientos por
Texto que describe una solucin ms todos lados y luego poner
que un problema referencias cruzadas
Contradiccin Requerimientos mal definidos
Texto que define un rasgo de varias No conforme a estndares
formas incompatibles entre ellas Terminologa inventada o
Ambigedad inconsistente
Texto que se interpreta de dos o ms Escribir de manera hostil para el
formas diferentes lector

No incluir en especificacin
Planes de desarrollo del proyecto
Costo, staff, esquemas, mtodos, herramientas,
etc.
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
Calidad, V&V, QA, test
Diseo
Requerimientos y diseos pensados para gente
diferente
Anlisis y diseo son reas diferentes

Calidad de especificacin
Anlisis de texto Continuidad de los requerimientos
Se pueden hacer anlisis textuales imperativos
del SRS Palabras como sigue abajo, como
sigue, etc.
Medir la forma de construccin Mide la estructura del SRS
Establecer normas para organismo Palabras dbiles
Ej; NASA usa nueve indicadores Causan incertidumbre
Imperativo Ej. Adecuado, aplicable
Identifica palabras como debe, es Directivas
requerido, etc. Indicacin a tablas, figuras
Se mide cuan explcito es el SCR Mide calidad del documento
Opcin Tamao
Palabras como puede, Lneas de texto, prrafos, hojas
opcional,etc. Estructura del texto
Mide las opciones que presenta SCR
Mide el nmero de identificadores de
Estadsticas de legibilidad sentencias
Nmero de estilos por palabra, Especificacin de profundidad
nmero de palabras por sentencia,
etc. Mide profundidad de subsecciones
Marca la estructura del SRS

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 V F V F V F V F

Ocurren durante secuencias crticas V V F F V V F F
No hay planes de recuperacin V V V V F F F F
Se avisa al operador?

Como evitamos ambigedad?
Revisar especificaciones en Notacin semiformal (tablas,
lenguaje natural grficos)
Usar personal con diferentes Lenguajes de especificacin
bases de conocimiento formales
Incluir gente de soft, gente
Explorar por redundancia
que entienda el problema, y
usuarios Poner un requerimiento ms de
El revisor debe ser diferente una vez ayuda al lector a
al autor comprender
Usar lenguajes de Pero es redundancia
especificacin Se debe usar una notacin ms
Conjunto restringido del formal y no repetir.
idioma

Caractersticas de un SRS
Modificabilidad
Bien estructurado, indexado, con referencias cruzadas
Sin redundancia
No es modificable si no es trazable
Trazabilidad
Cada requerimiento se puede rastrear hasta su fuente
Cada requerimiento se puede rastrear hasta su
implementacin
Notacin til
Que lo haga fcilmente comprensible

Estndar IEEE para SRS
IEEE introduce un estndar de Partes de un SRC
5 pasos: Est compuesto de
Revisin cuatro secciones cada
una con subsecciones
Describe aproximaciones
recomendadas para la
especificacin de Leer cuidadosamente el
requerimientos. paper IEEE prctica
Referencias recomendada para
A otros modelos IEEE especificacin de Req.
Definiciones De soft (paper Q)
Conceptos bsicos para la La especificacin del
prctica del modelo trabajo integrador
Consideraciones para producir deber hacerse
un buen SRS siguiendo esta
Secuencia de 8 pasos para metodologa
lograr ese fn

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

Resumiendo Importancia
Para la verificacin y validacin
Es una demostracin de
Evaluar adecuadamente los test
completitud, necesidad y disponibles
consistencia Evaluar la conformidad de
Una camino claro de requerimientos
alocacin y seguimiento Evaluar la completitud,
consistencia y anlisis de impacto
de flujo a travs del
Evaluar el diseo hacia atrs y
documento hacia delante
Una derivacin a travs Investigar como el
de una jerarqua comportamiento de mayor nivel
impacta en la espeficacin
detallada.
Detectar conflictos de
requerimientos
Chequear consistencia a travs del
ciclo de vida
Mantenimiento Proveer posibilidad de
audicin
Evaluar los pedido de
cambio Administracin
Trazar un diseo De cambio
racional (lgico) De riesgo
De control sobre el
Acceso a documentos
proceso de desarrollo
Habilidad de
Dificultades
encontrar informacin
rpidamente en Costo
grandes documentos Muy poco soporte
automatizado
Visibilidad de proceso
Completa trazabilidad
Habilidad para ver es muy cara y
como el soft se consumista de tiempo
desarrolla

Gratificacin demorada Tamao y diversidad
Gran rango de
La gente que define los
documentos distintos,
links de trazabilidad no herramientas,
son gente que se decisiones,
beneficie con ellos responsabilidades
Desarrollo vs V&V No hay esquemas
comunes para
Mucho del beneficio se clasificar y catalogar
observa tarde en el ciclo requerimientos
de vida En la prctica, la
Test, integracin, trazabilidad se enfoca
mantenimiento en lneas base de
requerimientos.

Prctica corriente de trazabilidad
Cobertura Identificar manualmente
Links desde los links
requerimientos hacia el Usar tablas manuales para
diseo, codificacin y casos grabar links en los
de test documentos
Links hacia atrs: desde Usar la herramienta de
test, codificacin y diseo a trazabilidad (BD) para la
requerimientos trazabilidad de un gran
Links entre requerimientos proyecto
en diferentes niveles Las herramientas tienen la
Proceso de trazabilidad habilidad de
Seguir los links
Asignar un nico ID cada
sentencia o prrafo Encontrar links perdidos
Medir la trazabilidad total

Herramientas para trazabilidad
Cuales? Limitaciones
Hipertexto (links) Todas requieren un gran
esfuerzo manual para definir
Palabras clave que
los links
identifican conceptos
asociados a ella Todas tienen informacin
puramente sintctica, sin
Identificadores nicos contexto semntico
Cada requerimiento tiene un Ej
ID nico con una BD de Herramientas de BD (RTM,
referencias cruzadas SLATE, DOORS)
Coeficientes de similaridad Herramientas de hipertexto
sintctica (document director, netscape
Busca la ocurrencias de navigator)
patrones de palabras Herramientas de desarrollo
general

Herramientas para trazabilidad
Limitaciones de herramientas Comunicacin informal
Problemas de informacin La gente le da mucha
Fallan en rastrear
importancia la contacto
informacin de trazabilidad entre personas con
por ej. No pueden decir
comunicacin informal
quien es el responsable de Se suplementa lo que se
determinado dato almacena en la BD de
Mala trazabilidad de pre- trazabilidad
requerimientos El resultado es una BD de
Desde donde vienen los trazabilidad que solo da
requerimientos? parte de la historia
Falta de convenio An con la herramienta no
Sobre la cantidad y tipo de es fcil encontrar las
informacin trazada personas que generaron el
requerimiento

Trazabildiad Cuestiones problemticas
Cuales son? Cambio
Intervencin En que punto del ciclo
Quin estuvo de vida se produce un
involucrado en la cambio o evolucin
confeccin de los de req?
requerimientos? Notificacin
Responsabilidad Quien necesita ser
Quien es responsable
avisado por cambios
por este req? en los req?
Quin es el Prdida de
responsable actual? conocimiento
En que punto de ciclo Cuales son las
de vida el ramificaciones
responsable cambia? asociadas a la prdida
de conocimiento?

Validacin de requerimientos
Qu veremos
Dos problemas con la toma de Negociacin sobre
req. requerimientos
El problema de la validacin Conflictos y su
Que es verdadero y que es resolucin
conocible? Tcnicas para
El problema de la negociar
negociacin requerimientos
Como reconciliar conflictos
Aproximaciones para
entre metas en un contexto
social complejo argumentar
Aproximaciones
Validar requerimientos
basadas en
Inspecciones y revisiones conocimiento
prototipeo Priorizacin de
requerimientos

El problema de validar
Aproximacin lgica Usar herramientas que
positivista testeen consistencia y
completitud del modelo
Hay un objetivo en el
mundo que puede ser Usar revisiones, prototipos
modelado construyendo un etc para demostrar que el
cuerpo consistente de modelo es vlido
conocimiento basado en Modificacin a la lgica
observacin emprica positivista (Popper)
En IR se asume que hay un Las teoras puede no
problema objetivo que existe proveer cosas correctas,
en el mundo se puede refutar
Construir un modelo encontrando excepciones
consistente (validarlo con Las teoras son cientficas
observaciones empricas) si pueden ser refutadas

El problema de validar
En IR, disear modelos Usar actores para
de req para ser que construyan sus
refutables
propios modelos de
Ver por evidencia que
muestre que el
requerimientos
modelo es errneo Usar tcnicas
Aproximacin post etnogrficas para
modernista entender el
No hay punto de vista problema.
privilegiado, todas las
valoraciones son
iguales
En IR, la validacin
siempre es subjetiva y
contextualizada

Revisiones e inspecciones
Como tratarlos
Desde el punto de vista de Asistido por clientes
la formalidad Inspecciones
Informal: en una charla de Proceso manejado
caf o en un reunin de por herramientas
equipo (formal)
Formal:encuentros Usado para mejorar
programados, la calidad del proceso
participantes preparados, de desarrollo
agenda definida, formato Junta datos por
especfico, salida de defecto para analizar
documento acordado al calidad del proceso
Administradores de revisin Rol principal:
Usados para proveer entrenar personal
certeza sobre el diseo junior y expertos en
transferencias.

Beneficios de la inspeccin formal
Muy til para la etapa de
programacin Se encuentra entre un
60 y 80% de errores
Programacin de aplicaciones
durante la inspeccin
Ms efectiva que el testing
Reduccin de costo entre
La mayora de los el 50 y 80% para V&V.
programas corren bien la
primera vez Efectos sobre competencia
del staff
Datos desde grandes
Incrementa la moral
programas
Mejor estimacin y
El factor de reduccin de
planificacin
errores es 5.
Mejor administracin de
Mejora la productividad en
las habilidades del staff
un 15 a 25%.
Estos beneficios son tiles
para IR!!!!

Limitaciones de la inspeccin
Tamao
Todos los tem
Suficiente gente de manera
evaluados deben estar
que todos los expertos estn
documentados
disponibles
Reporte que resuma
Mnimo 3 mximo 7 personas el trabajo
Duracin Lista detallada de
Nunca ms de 2 horas (se aspectos relevantes
pierde objetividad y Alcance
concentracin)
Tomar pequeas partes,
Salidas nunca el todo
Todos los revisores deben de Timing
estar de acuerdo con los
Examinar el producto
resultados
cuando el autor termina
con l.

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

Guas para la revisin
Guas para la inspeccin Pegarse a la
Antes de la revisin agenda
Planificar las Limitar el debate y
revisiones formales
la refutacin
(RTF) en el plan del
proyecto Identificar
Entrenar a los problemas pero no
revisores tratar de
Asegurar que todos solucionarlos
los asistentes estn
preparados Tomar notas
Durante la revisin escritas
Revisar el producto Luego de la revisin
no al autor
Revistar el proceso
Evitar comentarios
profesionales o de revisin
destructivos
Eleccin de los revisores
Posibilidades A quien excluir:
Especialistas en revisin Cualquier responsable
(gente de QA) directo o indirecto del autor
Gente del mismo Cualquiera con problemas
equipo del autor personales declarados
Gente invitada por ser contra el autor
especialistas
Cualquiera que no est
Gente interesada en el
calificado en revisin
producto final
Gente que tenga algo Todos los administradores
para contribuir Cualquiera que tenga
Gentes de otra parte de conflicto de intereses
la organzacin

Estructuracin de la inspeccin
Se puede hacer la
estructura de la revisin Revisiones activas
de varias formas: (escenarios)
Cada revisor lee con un
Ad hoc: propsito especfico, usando
Confiar en el experto cuestionarios especializados
en revisin Diferentes revisores toman
Lista de chequeos diferentes perspectivas
Usar una lista de Diferencias
preguntas o casos a Los escenarios encuentran
revisar mayores fallos que los otros
A lista se hace a mtodos
medida del No hay una diferencia
documento evaluado marcada entre los dos
primeros

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

Caractersticas de prototipos
Explicativo
Explica, demuestra e informa, luego se avanza
Exploratorio
Determina el problema, evala necesidades, clarifica
metas, examina alternativas y evala ideas, es informal,
no es estructurado
Experimental
Evala propuestas y el comportamiento del modelo
Evolucionario
Elige y refina soluciones, se usa como producto

Clases de prototipos
Dos clases Ventajas
Descartables Aprender el medio de
Evolucionables trabajo para lograr una
mejor adaptacin a las
Tercer opcin: operacionales
necesidades y solucin
Descartables Entrega temprana, test
Propsito temprano, menos costo
Aprender ms sobre el Bueno an cuando falle
problema o su solucin
Obtener conocimiento Desventajas
Uso Derrochar esfuerzo si
Etapas tempranas o los requerimientos
posteriores cambian rpidamente
Aproximacin Generalmente el
Rpida y sucia prototipo reemplaza
documentos

Evolucionables Ventajas
Propsito Los requerimientos
no estn congelados
Aprender ms sobre el
problema o su solucin Solo se retorna al
incremento anterior si
Reducir el riesgo de se encuentra un error
construir partes del sistema Flexible ?
en forma temprana
Desventajas
Uso Est en la otra punta
Incremental, evolucionable de los mtodos
Aproximacin estructurados
No se garantizan las
Vertical: necesita desarrollo
soluciones ms
riguroso e incremental efectivas
Poco control y
direccin
Prototipos organizacionales El prototipador graba las
Ofrecen un balance entre los experiencias del usuario
casos anteriores El usuario le dice al prototipador
por necesidades faltantes
Pasos involucrados
El prototipador hace cambios
Se crea un prototipo rpidos en el prototipo
evolucionable, basado en
una lnea base usando El usuario reutiliza el nuevo
metodologa clsica prototipo
(cascada) Se gira sobre el prototipo rpido
La lnea base se enva a adaptndolo
varios clientes junto con Cada cierto tiempo el prototipo y
prototipadores el prototipador retornan al
experimentados laboratorio para adaptar mejor el
El prototipador evala al prototipo (evolucionarlo)
cliente con el sistema Esto se repite indefinidamente

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.

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

Modelo de resolucin
Aproximacin usada Trs modelos de
para dirimir el conflicto resolucin
Los mtodos incluyen Cooperativo involucra
Negociacin negociacin
Competicin
Competicin
Arbitraje involucra combate,
Coercin coercin y competicin
Educacin
Resolucin por terceras
No todos los conflictos partes arbitraje y
necesitan un mtodo de
resolucin, as como no apelar a una autoridad
todos los conflictos
necesitan ser resueltos

Modelo de resolucin
Negociacin Competicin
Exploracin Alcanzar la mxima
cooperativa en el satisfaccin para el
rango de participante
posibilidades No tener en cuenta el
Los participantes grado de satisfaccin
tratan de encontrar de las otras partes
un punto comn que No ser
satisfaga a todas la necesariamente
partes hostiles
Conocido como Caractersticas
integracin constructiva Si yo gano, alguien
o negociacin tiene que perder
constructiva

Modelo de resolucin
Terceras Partes Licitar y negociar
Se busca un rbitro
para que decida Licitar
Tipos Los participantes
Judicial: cada parte establecen sus

presenta tu base de trminos deseados
conocimiento
Negociar
Extra judicial: se
determina una Los participantes
decisin por factores buscan por la
mas que por los casos integracin
presentados
satisfactoria de sus
Arbitraria: tirar una
moneda
pedidos.

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)
Experiencias resultados
Algunos aspectos Los grupos
observados heterogneos son ms
(hacer un mea culpa conflictivos (an si son
respecto de la ms experimentados),
realidad de cada uno) los grupos homogneos
son mejores para tomar
Los conflictos son
decisiones ms
normales en pequeos
riesgosas
grupos que toman
decisiones El efecto de la
personalidad es
Ms agresin y menos
eclipsado por factores
cooperacin si se
de situacin o de
restringe la
percepcin
comunicacin

Severidad sobre el conflicto
A
A y B
mutualmente A combinados
Nuestra satisfaccin
exclusivos
Nuestra satisfaccin
A y B
B interfirientes B
combinados
Satisf accin de otras partes Para dos posiciones Satisf accin de otras partes
iniciales A y B, se
puede medir la
severidad del
Nuestra satisfaccin
Nuestra satisfaccin
A
conflicto examinando
A y B
A
combinados
que sucede cuando
se combinan
inclusivos
no
interfirientes
B B
Satisf accin de otras partes Satisf accin de otras partes

Clasificacin de conflictos sociales
Unidades sociales Igual vs igual Jefe vs. Todo vs. parte
Subordinado
Roles Rol de familia vs. Rol ocupacional Personalidad social
Rol ocupacional vs. Rol de unidad vs. Rol de familia
Grupos Chicos y chicas en Padre vs hijos Familia ncleo vs

una clase escolar familia ampliada
Sectores Fuerza area vs Administracin vs Departamento vs

ejrcito unin facultad
Sociedades Protestantes vs Hombres libres vs Estado vs mafias
catlicos esclavos
Relaciones supra Bloque sovitico URSS vs Hungria CEE vs Reino
sociedades vs primer mundo unido

Teora del juego
Teora del juego en la

Ej: dilema del prisionero
resolucin de conflictos Prisionero B
Dados No Confiesa Confiesa
Dos o ms jugadores No Confiesa un ao a cada

10 aos para A
y 3 meses
Utilidades conocidas uno
para B
para cada uno de los Prisionero A
tres meses
jugadores Confiesa para A y 10
8 aos para
Puede calcular Pero aos para B
uno
Cual estrategia En IR, no sabemos cuales son las

resulta en el mejor utilidades
resultado Se puede resolver conflictos
Como interactan las pidiendo a los participantes que
estrategias de los cambien sus utilidades
jugadores No sabemos ni siguiera que
movimientos son posibles

Argumentacin
gIBIS
Desarrollado en 1989
Representa el proceso Argumento 1
de argumentacin como
objeto de
Uso 1 responde a Posicin 1
un grafo hipertextual soporte

generaliza Argumento 2
Proceso bsico
preguntas

responde a
Identificar usos Uso 2 Argumento 3
Identificar posiciones
que se pueden Posicin 2
adoptar con respecto
objeto de
Argumento 4
a las posiciones preguntas
objeto de es sugerido por
Linkear argumentos Uso 3
que soporte o refuten Argumento 5 Uso 4
posiciones

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

Otros casos
Usando modelos pre-existentes WinWin
OZ Desarrollado por Bohem (1990)
Desarrollado por Robinson Identifica condiciones de triunfo de
(1992) cada participante
Usa el modelo de dominio Incorpora el conocimiento base del
preexistente para comparar
perspectivas de conflicto dominio para calidad de
Proceso bsico requerimientos y links de atributos
Identificar perspectivas
del producto
(coleccin de creencias) Proceso bsico
Guardar perspectivas anotando Entrar las condiciones de triunfo bsicas
el modelo de dominio de metas de cada participante
y objetivos
El modelo de dominio linkea Identificar estrategias de atributos para
atributos del producto a metas condiciones de triunfo
Elegir combinaciones de Determinar efectos negativos para cada
atributos de productos para estrategia sobre cada condicin de
maximizar la satisfaccin de triunfo
participantes Resolver manualmente las
desaveniencias

Evolucin de Req. guas
El soft evoluciona Familias de software
porque los Lneas de productos
requerimientos Puntos de vista
evolucionan Como marco para el
Leyes de la evolucin entendimiento de la
del soft evolucin de
requerimientos
Administracin Administracin de
tradicional del cambio inconsistencia
Guas Razonamiento sobre el
Administracin de cambio
configuracin Rasgos ppales de la
interaccin

Tipos de programas
Programas
Especificables
Problemas que pueden Sentencias
ser establecidos formal e e
formales del
y completamente u ed ars
p ion
problema pr con
od tro
c n uc la
Aceptacin: el r ela co ci la
n
programa est acorde de
con su especificacin? Mundo Programa

Este soft no evoluciona Real
Un cambio en la pue ee
de de se ov
especificacin define inte r
P r
un problema nuevo, rs Solucin

entonces hay un
programa nuevo

Tipos de programas
Programas para solucin
de problemas
Sentencias imprecisas
del problema del mundo Cambia
Mundo
real Real
Aceptacin: el
programa es una Vista abstracta
solucin aceptable al del mundo real
problema?
El soft evoluciona Compara Cambia
continuamente Especificacin
de
Porque la solucin requeriminetos
nunca es perfecta, y
puede ser mejorada
Porque el mundo real Solucin Programa
cambia y entonces el
problema cambia

Tipos de programas
Programas
empotrados
Un sistema que es
parte del mundo al
que modeliza Mundo Real
Aceptacin: depende Cambia
enteramente de una Programa
opinin o un juez
Es inherentemente Especificacin
evolcionario de
Vista abstracta
del mundo real
Los cambios en el
requeriminetos
soft y el el mundo
real se afectan
entre s Modelo

Leyes de la evolucin de pgms.
Continuidad del cambio Ley fundamental
Cualquier soft que refleje una La evolucin del soft es regulada
realidad externa est en con tendencias y variantes
cambio continuo o se torna estadsticas
progresivamente menos Conservacin de la estabilidad
utilizado Organizacional
El cambio contina hasta
que se crea que es mejor Durante la vida activa del soft, el
tirarlo y hacerlo de nuevo trabajo de salida de proyecto de
desarrollo es constante
Incremento de complejidad
Conservacin de la familiaridad
A medida que el soft
evoluciona, la complejidad se Durante la vida activa de un
incrementa programa el porcentaje de
cambios permanece constante

Crecimiento en requerimientos
Modelo de Davis Solo se hacen parte
El usuario necesita de los requerimientos
evolucionar originales
continuamente
El grfico presenta el Siempre se agrega
crecimiento de nueva funcionalidad
necesidades en el Eventualmente se
tiempo
tornan en soft muy
Puede ser no lineal o
no continuo costoso que necesita
El desarrollo tradicional planear sus cambios
queda detrs de las Los reemplazos solo
necesidades de implementan partes
crecimiento de los requerimientos

Mantenimiento del software
Filosofa de Proceso de mantenimiento de Basili
mantenimiento Modelo fijo rpido
Los cambio hechos a nivel de
Alguien ms es el cdigo, tan fcil como se pueda
responsable del Rpidamente degrada la estructura
mantenimiento del soft
Se pierden Inversiones Modelo iterativo
Cambios hechos en base al anlisis
en conocimiento y de soft existente
experiencia Trata de controlar la complejidad y
El mantenimiento se mantener un buen diseo
convierte en un desafio Modelo de reuso total
de la Ing. Reversa Empieza con los requerimientos de
un nuevo sistema, reusando tanto
El equipo de desarrollo como se pueda
har un compromiso a Necesita una cultura madura de
largo plazo para reuso para tener xito
mantener el soft

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

Adm. Tradicional de mantenimiento
Elementos de la administracin
de cambio
Items de configuracin Proceso de administracin de
Cada producto diferente cambio
durante el desarrollo es un Todos los cambios
tem de configuracin propuestos son enviados
Control de versin para cada formalmente como pedidos
tem El equipo de revisin toma
Lneas base los pedidos de cambio y
Versin estable del documento decide o no su aceptacin
que puede ser compartida por El equipo de revisin
el equipo considera la interaccin
Proceso de aprobacin formal entre cambios de
para incorporacin de cambios requerimiento

singularidad de productos
La mayora de las tcnicas de Lo anterior ignora la realidad
IR se enfocan a modelos La IR no termina en la
individuales especificacin
Pasos Los requerimientos son
Construir un modelo voltiles, se necesita
administracin continua de
Hacerlo consistente y
cambio
completo
Las especificaciones nunca se
Validarlo
completan
Se asume que al IR es un
No hay nunca solo un modelo
proceso con una salida simple
Hay mltiples versiones de
La salida es una modelos en el tiempo
especificacin completa,
consistente y vlida Hay mltiples variantes del
modelo que exploran diferentes
temas

singularidad de productos
Hay mltiples Como se administra el cambio
componentes de incremental del modelo de req?
modelos representando Como se pueden comparar
diferentes mltiples modelo?
descomposiciones Como afectan los cambios del
Las familias de modelos modelo a las propiedades
evolucionan con el establecidas para l?
tiempo (agregando, Como se puede capturar la
borrando, mezclando o racionalidad del cambio?
reestructurando la Como tratar con las
familia) inconsistencias e
La IR debe evolucionar incompletitudes del modelo
los requerimientos

Familias de Software
El reuso del soft intenta achicar Desarrollo de programas
costos (Java, C)
El desarrollo de soft es caro, el Ingeniera de dominio
reuso es ideal si los sistemas
son similares Divide el desarrollo del soft en
Reusar conocimiento y dos partes
experiencia ms que solo Anlisis del
productos de soft dominio(identifica
El desarrollo de soft reusable componentes reusables del
es ms caro!!
dominio del problema
Libreras de componentes
reusables Desarrollo de aplicacin
Especficas de dominio (libreras (usa componentes de
del Math) dominio para especificar
aplicaciones)

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

Puntos de Vista Motivacin
Mltiples Modelado distribuido
perspectivas Analistas y actores
Muchos actores colaborando
diferentes
Mtodos mltiples de
Diversas clases de modelado
conocimiento del
dominio Evolucin continua de
Vistas conflictivas (y requerimientos
negociacin) Links de
Muchos esquemas de comunicacin
representacin imperfectos

Puntos de Vista Motivacin
Demoras en la resolucin de Modelo simple con coercin de
inconsistencias consistencia es muy restrictivo
Inconsistencias causas Se transforman en cuellos de botella
para el proceso de modelado
Conflicto entre fuentes de
distribuido
conocimiento
La coercin previene la divergencia de
Diferentes interpretaciones
ideas
Problemas de comunicacin
entre desarrolladores Inconsistencias se dan en situaciones de
incertidumbre
Diferentes velocidades de
desarrollo Resolucin prematura puede conllevar
decisiones de diseo prematuras
Divergencias en los
mtodos previstos La inconsistencia implica que se
necesita ms adquisicin de
errores conocimiento
Algunas inconsistencias nunca sern
resueltas

Marco de trabajo bsico
El modelo de requerimientos Los PV son instanciados desde
es una coleccin de puntos templates
de vista Tiene un estilo y un plan de
Para cada PV identificar trabajo
Propietario
El desarrollo de templates es
Dominio (que describe)
una tarea separada
Estilo (notacin o reglas
utilizadas) Un mtodo provee un
Plan de trabajo conjunto de templates
(obligaciones de designados para ser usados
consistencia con otros PV) juntos
Historia de los cambios
Especificacin de contenido

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

Ventajas de los PV
Actores y trazabilidad Estructuracin del
Los propietarios de PV pueden proceso de desarrollo
ser roles, personas, equipos...
Cada contribucin de un actor Cada PV es una pieza
es modelizada en una independiente
notacin apropiada No hay control global,
Cada actor puede validar e no hay esfuerzos
identificar su propia globales para
contribucin consistencia
Se incrementa el concepto Trabajo sincrnico o
de propiedad en el proceso
de requerimiento asincrnico
Los requerimientos pueden Las reglas de
ser trazados hacia la fuente chequeo de
de los mismos consistencia actan
puntos explcitos de
sincronizacin

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

PV hacia adonde???
Mtodo de ingeniera
Mtodo de diseo Como grafos
definir un conjunto de Como predicados sobre
templates coherentes estructuras de objetos
Como expresiones de lgica
PV como una de primer orden
herramienta Meta CASE Cuando deberan ser
Proceso de modelado aplicadas
Un proceso de Como pude la inconsistencia
modelado de grano fino ser reparada una vez
detectada?
en cada PV
Cuales son las
Administracin de consecuencias de no
consistencia repararlas?
Como presentar reglas Trazabilidad de
de consistencia inter requerimientos
PV? Los PV asociados a actores
con sus contribuciones
Como aparece una Definicin de inconsistencia
inconsistencia (como ya Dos partes de las
vimos) especificacin no obedecen la
Conflicto entre fuentes de misma relacin que est
conocimiento definida para ellos
Interpretaciones diferentes Las relaciones pueden unir
Problemas de comunicacin Elementos sintcticos de
entre desarrolladores especificacin parcial
Diferentes velocidades de Semntica de elementos en
desarrollo especificaciones parciales
Subprocesos del proceso de
Divergencias entre los desarrollo
mtodos utilizados
errores

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

Inconsistencia
La inconsistencia est en la IS Lecciones sobre inconsistencia
Las descripciones de IS varian en la prctica
mucho en formalidad y Algunas inconsistencias nunca
precisin son solucionadas
Descripciones individuales Porque el costo de cambiar
pueden ser formadas mal o documentos sobrepasa el
ser contradictorias beneficio
Las descripciones continan Porque los humanos son
evolucionando durante el buenos inventando
desarrollo excusas
El chequeo de consistencia de Convivir con la inconsistencia
un gran conjunto de es una decisin riesgosa
descripciones es muy caro en Los factores de riesgo
trminos computacionales cambian, el riesgo debe
reevaluarse continuamente

Inconsistencia
Algunas chequeos de consistencias no
tienen la valoracin de performance
El monto de dinero para establecer la
consistencia donde se anticipa el cambio
La inconsistencia es contradictoria
Ej:
Porque generalmente es vista como algo malo
Porque siempre se puede cuestionar la
formalizacin

Conviviendo con inconsistencia
La deteccin es vital Demorarla:
Convivir con inconsistencia es Si se necesita informacin
seguro si se tiene que no est disponible por
conocimiento de su existencia el momento
Manejo de inconsistencia Mejorarla
Tomar acciones que afinen
Evadirla
la situacin pero que no
Remover / reemplazar resuelvan la inconsistencia
elementos inconsistentes, o
remover / reemplazar reglas Resolverla:
que fueron rotas Negociar una solucin o
encontrar un compromiso
Ignorarla
Si puede ser aislada y no es
La inconsistencia indica,
importante normalmente, que se necesita
ms informacin

Modelo de proceso de inconsistencia
reglas de
consistencia
monitor para inconsistencia
monitoreos de acciones
consecuencas de
Localizar Ignorar
Diferir
Inconsis-
Inconsisten tencia
Caracterizacin Manipu-
cia
Detectada
Identificar de Tolerar Evadirla lada
Inconsistencia
mejorarla
Clasificar Resolver
Midiendo
Analizando impacto y riesgo
Inconsistencias
PV para chequeo de consistencia
Quin es el responsable Cada PV tiene su propio
Los propietarios de los PV son conjunto de reglas
responsables por cambios No se necesita control central
locales en sus PV Cuando debera chequearse las
Pueden sugerir cambios a relaciones entre PV?
otros El propietario del PV chequea
No pueden forzar la las reglas cuando lo necesite
sincronizacin de PV
Como se chequean las
Como se expresan relaciones entre PV?
responsabilidades? El sistemas administrador de
Las reglas de consistencia transacciones entre PV
expresan relaciones que Los dos PV testeados son
deberan respetarse entre PV notificados de los resultados

PV para chequeo de consistencia
Como resolver Que sucede si cambios
inconsistencias? futuros interfieren con la
Las Acciones pueden no llevar resolucin?
a una solucin Los chequeos exitosos no
Las acciones surgen de los garantizan las relaciones se
mtodos de diseo y de mantengan
experiencias en su uso Cada regla puede necesitar
Que sucede si no se resuelve ser aplicada un nmero de
veces durante el desarrollo
la inconsistencia?
Los cambios que afectan
Deben quedar documentadas
inconsistencias resueltas son
Los cambios subsecuentes trazados
pueden afectar a esa
inconsistencia Las acciones involucradas en
la resolucin son guardadas
como parte de documentos

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.

Clase 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 3

Cargado por

Copyright:

Formatos disponibles

Ingeniera de Software

UNPSJB - 2005 Ingeniera de Software - Clase 3 2

UNPSJB - 2005 Ingeniera de Software - Clase 3 3

UNPSJB - 2005 Ingeniera de Software - Clase 3 4

UNPSJB - 2005 Ingeniera de Software - Clase 3 5

El Ing. de requerimientos es una agente

UNPSJB - 2005 Ingeniera de Software - Clase 3 6

Mundo del Interfases de Mundo del

UNPSJB - 2005 Ingeniera de Software - Clase 3 8

UNPSJB - 2005 Ingeniera de Software - Clase 3 9

UNPSJB - 2005 Ingeniera de Software - Clase 3 10

UNPSJB - 2005 Ingeniera de Software - Clase 3 11

UNPSJB - 2005 Ingeniera de Software - Clase 3 13

UNPSJB - 2005 Ingeniera de Software - Clase 3 14

UNPSJB - 2005 Ingeniera de Software - Clase 3 16

Una descripcin de un conjunto posible de

UNPSJB - 2005 Ingeniera de Software - Clase 3 17

UNPSJB - 2005 Ingeniera de Software - Clase 3 18

Nombre: Orden de pedido

Una vez confirmado el pago, la orden se cambiar a confirmada y se le indica

En el paso 9, si hay informacin incorrecta, el sistema le preguntar al cliente

UNPSJB - 2005 Ingeniera de Software - Clase 3 20

UNPSJB - 2005 Ingeniera de Software - Clase 3 21

UNPSJB - 2005 Ingeniera de Software - Clase 3 22

UNPSJB - 2005 Ingeniera de Software - Clase 3 23

UNPSJB - 2005 Ingeniera de Software - Clase 3 24

UNPSJB - 2005 Ingeniera de Software - Clase 3 26

Son objetivos opuestos

UNPSJB - 2005 Ingeniera de Software - Clase 3 27

Construir dos modelos

UNPSJB - 2005 Ingeniera de Software - Clase 3 28

Abstraccin vs. contextualismo que estudia el ser

Se necesitan tcnicas que cubran el

UNPSJB - 2005 Ingeniera de Software - Clase 3 31

UNPSJB - 2005 Ingeniera de Software - Clase 3 32

UNPSJB - 2005 Ingeniera de Software - Clase 3 33

Como se obtiene de la transparencia anterior una

El modelado puede ser una medida del progreso

UNPSJB - 2005 Ingeniera de Software - Clase 3 36

UNPSJB - 2005 Ingeniera de Software - Clase 3 37

UNPSJB - 2005 Ingeniera de Software - Clase 3 38

Independencia de implementacin Fcil de analizar

UNPSJB - 2005 Ingeniera de Software - Clase 3 39

UNPSJB - 2005 Ingeniera de Software - Clase 3 40

UNPSJB - 2005 Ingeniera de Software - Clase 3 41

UNPSJB - 2005 Ingeniera de Software - Clase 3 44

UNPSJB - 2005 Ingeniera de Software - Clase 3 45

UNPSJB - 2005 Ingeniera de Software - Clase 3 46

necesita otro actor

para llevar a cabo la

agenda para la del

concurrencia a una Assured(A

cita particular (ver ttendsMeet D

el paper D D dependencia de recueros

correspondiente) D D dependencia de tareas

Modelo racional muestra Iniciador

interacciones entre metas encuentro

del modelado mirando Quick Low

dentro de los actores para

Muestra los links entre

tareas y metas Meta

SR provee una forma de

modelar actores Tarea