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