Clase 3

Ingeniera de Software Clase 3
Ingeniera de Requerimientos (Toma, modelado, comunicacin, aceptacin y mantenimiento)
Contenido Clase 3
Obtencin de requerimientos

Modelizando Empresas y metas

Tcnicas tradicionales Entrevistas y cuestionarios Escenarios y casos de uso Aproximacin cognitiva Aproximacin contextual
Modelizando el comportamiento funcional

Modelizar funcionalidad Evolucin del Anlisis

Tcnicas formales

AE AOO
Por que modelar motivos Tipos de modelo Esquema conceptual Diferentes modelos conceptuales Requerimientos no funcionales
Especificacin vs. Modelado de requerimientos Algunos ejemplos (investigacin) SCR

RML RSML
UNPSJB - 2005
Ingeniera de Software - Clase 3
Contenido Clase 3 (cont.)
Comunicando requerimientos
Validacin de requerimientos

SRS (soft requeriment Specification) Ambigedades y como evitarlas Estndares Trazabilidad de requerimientos
Usos filosficos Revisiones e inspecciones Prototipacin
Aceptando los requerimientos

Negociacin ante problemas Solucin de conflictos
UNPSJB - 2005
Contenido clase 3 (cont.)
Evolucionando requerimientos
Administracin del cambio Administracin de inconsistencia Rasgos de interaccin Familias de productos para Administracin de requerimientos
UNPSJB - 2005
Contenido Clase 3
Bibliografa utilizada
Ingeniera de Requerimientos (Locoupulous) Ingenira de Requerimientos (Davis) Ingeniera de software (Pressman, Sommerville) Papers Varios
UNPSJB - 2005
Toma de Requerimientos
Punto de comienzo
Alguna notacin que indique que hay un problema que necesita resolverse
Oportunidad de negocios Necesidad de mercado Utilizacin de recursos
El Ing. de requerimientos es una agente del cambio Identificar el problema / oportunidad

Ingeniera de Software - Clase 3 6
El Ing.Requerimientos debe
UNPSJB - 2005
Toma de Requerimientos
Cual problema necesita ser resuelto? (identificar lmites) Donde est el problema? (el contexto o el dominio del mismo) A Quienes involucra el problema? (identificar los actores) Por qu necesita resolverse? (identificar las metas de los actores) Como debera ayudar el soft? (tomar o colectar los escenarios posibles) Para cuando debe estar resuelto? (identificar limitaciones de desarrollo) Qu debemos tener en cuenta para resolverlo? (identificar riesgos). Adquirir suficiente conocimiento Convertirse en un experto del dominio del problema
La tcnica de las 6 W: What? Where? Who? Why? When? How (Which)?

UNPSJB - 2005
Los cuatro mundos

Como el sistema utiliza la informacin sobre el dominio de la aplicacin
Mundo del sujeto
Como la mquina representa inforamcin sobre el dominio de aplicacin
Mundo del uso
Interfases de usuario
Mundo del sistema
Justificar las metas de desarrollo

UNPSJB - 2005
Mundo del desarrollo

Desiciones de diseo
Dificultades para la adquisicin
Criterios para definir el dominio del conocimiento
Conocimiento tcito
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
Las personas encuentran difcil decir que necesitan o complican mucho la explicacin
UNPSJB - 2005
Dificultades para la adquisicin
Problemas en la comunicacin
La gente puede estar imposibilitada para decir lo que realmente necesita
Problemas polticos o de seguridad
La gente puede no querer decir que es lo que necesita

Si digo algo luego quedo pegado Si abro mi negocio y otro se entera pierdo
UNPSJB - 2005
10
Tcnicas para toma de requerimientos
Tcnicas tradicionales
Introspeccin
Mirar hacia dentro del problema
Grupos enfocados Brainstorming JAD/RAD
Documentos existentes Anlisis de datos Entrevistas

Prototipacin
Aproximacin basada en representacin

Agenda abierta Estructuradas
Cuestionarios Adquisicin en grupos
Basada en objetivos Basada en escenarios Basadas en casos de uso
UNPSJB - 2005
11
Tcnicas para toma de requerimientos
Aproximacin contextual (social)
Tcnicas etnogrficas Observacin de participantes Etnometodologa Anlisis de discurso Anlisis de conversacin Anlisis de presentacin Diseo participatorio
Aproximaciones cognitivas
Anlisis de tareas Anlisis de protocolos Tcnicas de adquisicin de conocimiento
Ordenamiento de tarjetas Grillas de repertorio Tcnicas de escalado de proximidad
UNPSJB - 2005
Etnografa: ciencia que tiene por estudio y descripcin de las razas o pueblos, como tambin su lengua, sus creencias, artesanas, usos, costumbres3y formas de vida Ingeniera de Software - Clase 12
Cuestionarios
Ventajas
Qu mirar?

Puede obtener informacin rpidamente de muchas personas Puede administrarse remotamente Puede obtener actitudes y caractersticas de los actores Puede obtener un contexto muy pobre del problema
Desventajas
No hay entrevistas con usuarios
Tendencias en la seleccin de ejemplos Tendencias en la seleccin de respuestas Ejemplos de tamao chico (con poca significancia estadstica) Preguntas ambiguas (muchos que no contestan la misma pregunta) El cuestionario debe ser testeado
UNPSJB - 2005
13
Entrevistas
Tipos
Estructuradas
Existe una agenda previa con temarios Agenda abierta, no hay temarios previos
Libres
Difcil la comparacin de respuestas Administrar las entrevistas no es una tarea sencilla Preguntas sin respuestas Conocimiento tcito El contexto de discusin Actitud de los entrevistados respecto de los temas abarcados
Que mirar?

Ventajas
Ricas en adquisicin de informacin
Desventajas
Muchos datos cualitativos difciles de analizar

UNPSJB - 2005
14
Tcnicas de adquisicin en grupo
Tipos

JAD o RAD Enfoque en grupo Brainstorming
Desventajas
Ventajas
Interaccin ms natural entre la gente, mayor a una entrevista formal Se puede medir la reaccin ante material de estmulo
Presentaciones, maquetas, etc.
Puede crear grupos poco naturales y hacer sentir incmodos a los participantes Peligro de llevar a una opinin de grupo que no sea real Pueden obtenerse respuestas superficiales a cuestiones tcnicas Se requiere de un facilitador muy entrenado Tendencias en los ejemplos Dominancia y submisin
15
Que mirar?

UNPSJB - 2005
Coleccin de datos complejos
Identificar los grupos de estos datos

Hechos y figuras, informacin financiera, etc. Reportes usados para toma de decisiones,... Resultados obtenidos, informacin de marketing,.. Obtener datos representativos del conjunto de la poblacin de elementos
Ejemplos

Ejemplos propuestos tomar aquellos considerados ms relevantes Ejemplos aleatorios tomar cada n casos Ej. Aleatorios por capas identificar capas del problema y tomar un caso de cada uno Ej. Aleatorios por cluster generar subconjuntos relacionados y tomar un ejemplo de l. Balancear entre costo y relevancia del ejemplo
Tamao del ejemplo
UNPSJB - 2005
16
Casos de uso
Que es un caso de uso?
Cada forma diferente en que un actor interacta con el sistema Una descripcin de una secuencia de acciones que el sistema debe llevar a cabo para obtener un resultado observable para un actor particular [Booch] Todos los casos de uso deben ser numerados Una descripcin de un conjunto posible de escenarios, con un propsito comn Se escriben, generalmente, en lenguaje natural No hay descripcin interna del sistema, solo la interaccin con el mismo
UNPSJB - 2005
Casos de uso
Ventajas y desventajas

Caracterizacin detallada de todas las posibles interacciones con el sistema Ayuda en el dibujo de los lmites del sistema, y con el alcance de los requerimientos Los casos de uso no captura en dominio del conocimiento Un caso de uso no es especificacin precisa, solo es la representacin de un problema puntual
UNPSJB - 2005
18
Usando Casos de uso
Dibujar los lmites
Identificar los actores Para cada caso de uso Escribirlo fuera de los lmites del sistema que Especificar reglas para eleccin del mismo y para interactan con l interacturar con l Para cada factor Considerar alternativas Identificar los Ver posibles superposiciones posibles casos de uso de casos de uso
Establecer escenarios concretos para ilustrar cada caso de uso Agrupar escenarios similares en casos de uso si son una variacin sobre un tema
Template de caso de uso: Nombre: Resumen: Actores: Precondiciones: Descripciones: Excepciones: Postcondiciones:
UNPSJB - 2005
19
Un ejemplo de caso de uso

Nombre: Orden de pedido Precondicin: un usuario vlido est conectado al sistema Descripcin:

Excepciones:
El caso de uso comienza con un pedido del cliente El cliente entra su nombre y direccin Si el cliente entra solo el cdigo postal, el sistema debe agregar la ciudad y la provincia. El cliente entrar todos los cdigo de los productos deseados y la cantidad solicitada El sistema indicar el nombre del producto y el precio unitario del mismo Cliente El sistema totalizar la cantidad de productos pedidos y el total de la venta El cliente indicar la forma de pago, si es tarjeta el nmero de la misma El cliente apretar la tecla enviar El sistema verificar la informacin, guardar la orden de pedido como pendiente y la forma de pago Una vez confirmado el pago, la orden se cambiar a confirmada y se le indica esto al cliente, el caso de uso finaliza En el paso 9, si hay informacin incorrecta, el sistema le preguntar al cliente que quiso poner La orden fue salvada en el sistema y fue marcada como confirmada
Orden de pedido
Tomar Estado
Enviar catlogo
Cancelar orden
Enviar producto
Delivery
Postcondiciones:
Re-Adquirir producto
Proveedor
UNPSJB - 2005
20
Escenarios
Definicin
Ventajas
Secuencia especfica de interacciones entre actores y sistemas Tienden a ser cortos Puede sen
Positivos (comportamiento requerido) Negativos (interaccin no deseada)
Muy natural: se tratan de usar de manera expontnea Los escenarios cortos son muy buenos para ilustrar interacciones especficas Falta de estructuracin: se necesitan casos de uso o modelo de tareas para proveer una visin de alto nivel.
Desventajas
Pueden estar en modo indicativo u optativo
UNPSJB - 2005
21
Modelado de tareas y Escenarios
Modelado de tareas:

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

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

operativos
UNPSJB - 2005
23
Usando aproximacin basadas en metas
Metas
Objetivos de alto nivel de un negocio u organizacin Especificacin de cmo una meta debe estar en un nuevo sistema Metas de realizacin Metas de mantenimiento Metas soft
Requerimiento
Consejos

Las limitaciones son condiciones sobre la realizacin de una meta Las metas se obtienen mejor de mltiples fuentes Asociar actores a cada meta (revela puntos de vista y conflictos) Usar escenarios para explorar como los objetivos pueden ser alcanzados Consideraciones explcitas sobre obstculos puede ayudar a construir o definir excepciones.
Tipos

Obstculos y limitaciones
Los obstculos son comportamientos que previenen la realizacin de una meta dada
UNPSJB - 2005
24
Tcnicas adquisicin de conocimiento
Base:
Problemas de modelado

La toma de conocimiento est ligada con el descubrimiento experto de conocimiento Ligado con el crecimiento de los sistemas expertos Mtodos formales
Es muy frgil, para pequeos casos de uso
Problema de representacin
Inadecuado epistemolgicamente Expresividad vs. Facilidad de adquisicin
KE es dura
Separar el dominio del conocimiento de la performance del conocimiento

UNPSJB - 2005
Por que KE es tan difcil??
Expertos no se utilizan para describir que hacen
Problemas de representacin
Hay tres pasos para modelar el aprendizaje
Los expertos no tienen un lenguaje para describir el conocimiento
Los mecanismos procedurales y declarativos son diferentes
Cognitivo (descripcin verbal de las tareas) Asociativo (reforzar las ideas con repeticiones de dichos verbales) Autnomo (compilado, no son concisos)
Ventaja
diferentes representaciones de conocimiento son buenas para cosas diferentes El conocimiento se crea, no se extrae
Los lenguajes hablados no tiene la suficiente precisin
El conocimiento declarativo se torna procedural con aplicacin repetida, los expertos no pueden hacer esto fcilmente
Son abstracciones de la realidad Se crea travs de suposiciones simples Tiende a tener menos errores o problemas
UNPSJB - 2005
26
Expresividad vs. Facilidad de adquisicin
Son objetivos opuestos
Lo ms expresivo es ms difcil de adquirir y viceversa Ej Las interfases con reglas de induccin son fciles de adquirir pero poco expresivas La lgica de un programa es muy expresiva pero difcil de adquirir La representacin ideal intenta combinar lo mejor de cada una
UNPSJB - 2005
27
El nivel del conocimiento
Ver el modelado del conocimiento como:
Comportamiento
Acta como si tuviera conocimiento sobre el ambiente que utiliza Nivel simblico: descripciones del mecanismo del comportamiento Nivel de conocimiento: descripciones del conocimiento del agente del mundo real
Ambiente
Observacin
Construir dos modelos
Observador (modelador) Agente

mecanizado
Modelo de nivel de smbolos
UNPSJB - 2005
racionalizacin
Observar el comportamiento de un agente como una caja negra
Modelo el nivel de conocimiento
28
Algunas tcnicas de toma de conocimiento
Anlisis de protocolo
Basadas en vocalizar el comportamiento Ventajas

Desventajas

Forma verbal de las actividades cognitivas Dentro del contexto No tienen dimensin social Basada en introspeccin
Desventajas

Ayuda a construir modelos mentales, Pueden adquirir conocimiento tcito Requiere una aceptacin del conjunto de objetos Difcil de lograr
Ordenamiento de tarjetas
Tcnicas de escala de proximidad
Dado un dominio, derivar un conjunto de dimensiones para clasificarlo Ventajas:
Para un conjunto de objetos de dominio escribirlos en tarjetas para ordenarlas en grupos Ventajas
Desventajas
Simple y fcil de automatizar
UNPSJB - 2005
Las entidades necesitan ser identificadas dentro de semnticas a lo largo del dominio
29
Abstraccin vs. contextualismo
Abstraccin:
Contextualismo
Ontologa: parte de la metafsica, que estudia el ser en general y sus propiedades trascendentales
Construye modelos abstrayndolos del dominio, el modelo puede contestar preguntas
Pone nfasis en los detalles e idiosincrsia del dominio
Decidir sobre la ontologa del fenmeno que se quiere describir
Se asume que el conocimiento y el entendimiento son independientes del contexto Utilizado normalmente por cientficos naturales e ingenieros
Obtener datos naturales del dominio de estudio Usar los datos para dar explicaciones
Asume que es imposible construir modelos que tengan comportamiento cuando se remueven del contexto Usado por muchos cientficos sociales
30
UNPSJB - 2005
Visin etnometodolgica
Etnologa: ciencia que estudia el origen, la distribucin y los caracteres fsicos de las razas humanas
La toma de requerimientos es una actividad social
Se necesitan tcnicas que cubran el orden del mundo social

Porque involucra comunicacin entre personas (discusiones, observacin de la realidad, etc) Porque involucra negociacin para lograr consensos Porque afecta y cambia los sistemas de actividad humana
El mundo social solo puede entenderse si uno se mete en l

Este puede no ser obvio o describible No se puede asumir con estructura previa Es construido a partir de acciones de los participantes No se puede tomar informacin de categoras preestablecidas Como los significados se desarrollan y evolucionan en el contexto Los mtodos pblicos utilizados para que el contexto tenga sentido
31
El dominio de una aplicacin es, gralmente, un mundo social
Se necesita considerar
UNPSJB - 2005
Etnometodologa
Bases:

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

Los observadores pasan un tiempo con los sujetos, tratando de convertirse en un miembro ms del grupo Contextualizacin Se revelan detalles que otros mtodos no pueden cubrir
Ventajas

Consume mucho tiempo Se tiene mucha informacin que puede resultar difcil de analizar No se puede decir mucho de cambios que se propongan
UNPSJB - 2005
33
Por que modelar?
El modelado
actividad de definicin formal de aspectos del mundo fsico y social que nos redea con el propsito de entender y comunicar Combinar problemas
De ingeniera: mtodos formales de construccin
Modelado
Actividad de modelado
se hace sobre los cuatros dominios de informacin Empresa

Empricos: especificaciones ligadas al mundo real Formales: abstraccin, estructura y representacin del conocimiento del problema
Uso Sistema Desarrollo
Especificacin conceptual
UNPSJB - 2005
Entender un dominio especfico de informacin
34
Motivacin del modelado
Suponga que se entrevistaron varios actores de un problema relacionado a una aerolnea
Agente de viajes

Jefe ejecutivo

Administrador de ventas El nmero de valijas en el avin debe corresponder al nmero de Solo se puede usar un ticket personas que abordan pago En algunos casos puede no Las listas de pasajeros son confirmarse la reserva informacin restringida Un tckets de descuento no Solo se puede hacer el check in una puede devolverse UNPSJB vez - 2005 Ingeniera de Software - Clase 3 35
problema Jefe de seguridad
Cuando el vuelo est lleno, primero se atiende a los VIP Hay tickets de descuento para polticos podremos obtener ventajas La informacin debe resultar clasificada para actores externos al
Jefe de Catering
Un agente es responsable de reservas y cancelaciones Hay diferentes tickets ofrecidos a las agencias de viaje La comida cargada est relacionada con la nmero de personas Se debe conocer el nmero aproximado de personas en el vuelo 24 hs antes. Tambin 24 hs antes se debe saber por comidas especiales
Como se obtiene de la transparencia anterior una especificacin acorde? El modelado puede guiar la toma de requerimientos
El modelado puede ser una medida del progreso
El proceso de modelado puede ayudar a imaginarnos que hacer? Puede ayudarnos a investigar sobre requerimientos ocultos? Ej: hice bien las preguntas? La completitud del modelo implica la completitud de la toma de req.?
UNPSJB - 2005
36
El modelado puede ayudar a descubrir problemas
La inconsistencia de un modelo revela algo interesante puede corresponder a requerimientos conflictivos o

La modelizacin ayudar a chequear nuestro entendimiento

inflexibles puede significar confusin sobre terminologas, 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?
UNPSJB - 2005
37
Tipos de modelo
Se puede elegir entre una variedad de esquemas conceptuales
Lenguaje natural Muy expresivo y flexible Pobre al intentar captar la semntica del modelo Mejor para la toma de requerimientos Notacin semi formal Captura estrutura y alguna semntica Puede llevar a cabo algn razonamietno, chequeo de consistencia y animacin Notacin formal Semntica muy precisa Muy complejos
UNPSJB - 2005
Requerimientos para el esquema conceptual
Independencia de implementacin
Fcil de analizar
No modelar representacin de datos, organizacin interna, etc.
Para detectar ambigedad, inconsistencia, incompletitud Habilidad para seguir los elementos del modelo Poder animar el modelo, para comparar con la realidad No redundancia de conceptos (cada cosa expresada de una forma)
39
Abstraccin
Trazabilidad
Tomar solo aspectos principales (cosas que no cambien)
Formalidad

Ejecutabilidad
Sintaxis no ambigua Rico en semntica
Constructibilidad
Minimalidad
Debe facilitar la comunicacin analista usuario
UNPSJB - 2005
Tcnicas de modelado
Modelado de informacin (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 organizacin (i*, SSM, ISAC)

Modelado de metas: (KAOS)
Anlsis estructurado (Yourdon, Martin, etc)

Anlisis OO (Coad, Boock, UML) Mtodos formales (SCR, RSML, Z) QFD, Redes de petri (performance), Modelo de tareas (disponibilidad)
40
Modelado de req. no funcionales
De productos, de procesos y externos
UNPSJB - 2005
Modelado de requerimientos de empresa
Evolucin en el tiempo
70
Resolver los sistemas de soft

80
Tcnicas: SSM, ISAC

Involucrando toda la organizacin Sensitivo al contexto social y poltico para el cambio organizacional
Basdados en conocimiento
Tcnicas: RML
Usar representacin del conocimiento para construir modelos de dominio ejecutables Capturan aspectos estticos y dinmicos del dominio
90
Teleolgicos

Teleologa: doctrina de las causas finales
Ejemplos: KAOS, I*
Los requerimientos son metas y se pueden modelizar jerarquas Se enfocan en el por qu? Ms que en el qu?
UNPSJB - 2005
41
Revisin de modelos: ER, ISAC

ER se obvia ISAC (information systems work & analysis of Change)
Proceso ISAC
Anlisis de cambio
Desarrollado en el 70 en Suecia Pondera la cooperacin entre usuarios y desarrolladores
Estudio de actividad

Que quiere la organizacin? Cuan flexible es la organizacin respecto a cambios? Que actividades deben reagruparse en sistemas de informacin? Que prioridades tienen los sistemas de informacin? Que entradas y salidas tienen cada SI? Qu son los requerimientos cuantitativos del SI? Que tecnologa se utilizar para el SI (hard, y soft)? Que actividades del SI sern automticas o manuales?
42
Bueno para SI pero no aplicable a problemas de control
Los desarrolladores son facilitadores
Anlisis de informacin

Implementacin

UNPSJB - 2005
Revisin de modelos: ISAC-Elementos
Lista de problemas
Insatisfaccin con los sistemas corrientes

Listar los problemas Remover aquellos triviales o imposibles
Anlisis de metas
Sentencias declarativas de metas
Resultado deseado, no como obtenerlo
Lista de grupos de inters
Meta final rbol de metas Las metas deben explicar por qu existe el problema
Anlisis de problemas
Dibujar una matriz de problemas para contrastarla con los propietarios de los mismos Anlisis de causa efecto
Definir necesidades de cambio
Modelo de actividad corriente
Llevados a cabo por especialistas Cuantificar el problema Esquemas A (similar a diagramas de flujo de datos)
Evitar soluciones orientadas a problemas
Generar alternativas de cambio Modelo de situaciones deseadas
Hacer paquetes de alternativas para el cambio
Evaluar alternativas Elegir una alternativa

43
UNPSJB - 2005
Revision de modelos: SSM
Soft system methodology
Desarrollado al final del 70 Los requerimientos no se toman objetivamente, orientado hacia aspectos sociales Rasgos: Situaciones no estructuradas El impacto puede ser negativo (una computadora reduce la productividad y quita trabajo) Para una buena utilizacin se necesita una restructuracin de base muy amplia Analiza la situacin del problema usando diferentes puntos de vista Obtiene algo similar a una especificacin en conjunto con
Objetivos, estructuras de tareas, planes para la organizacin, entendimiento del ambiente

UNPSJB - 2005
44
Revision de modelos: SSM
Pasos de la metodologa
1. 2.
Situacin base (problema no estructurado) Anlisis del problema
5.
Compara el modelo conceptual con el paso 2
3.
Definir aspectos relevantes del sistema y su raz Descripcin de la actividad

humana
dibujo del mismo temas que abarca el problema
4.
Construir el modelo conceptual
Actividades del sistema necesarias para llevar a cabo la transformacin Modelo orientado al proceos, con actividades y flujo de recursos
6.
Debate sobre la factibilidad del cambio

Tres tipos de cambio: estructural, procedural y de actitud
Preguntas ordenads sobre el modelo Reconstruccin de eventos para compararlas con el modelo Comparacin general para mirar rasgos del modelo diferentes de la situacin actual
7.
Implementar los cambios
UNPSJB - 2005
45
Revision de modelos: i*
Rasgos

Desarrollado en los 90 Provee una estructura para preguntar POR QU Modela el contexto de la organizacin para SI Basado en la notacin de actor Dos partes del modelo
Caractersticas
El modelo de dependencia muestra las dependencias entre actores objetivo obtener un mejor entendimiento de los por qu?
Modelo de dependencia estratgica (relaciones entre actores) Modelo estratgico racional (modela intereses e incumbencias de actores)
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)
UNPSJB - 2005
46
Atte ndsM 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)
D D
Iniciador de l e ncue ntro ExclusionDate (P)
D D
D D
Propose dDate (M )
Pre fe rre dDate (P)
participante de l e ncue ntro
D
ISA
D
Agre e me nt (M ,P)
D X D D
Atte ndsM e e ting (ip,m)
participante importante de l e ncue ntro
Assure d(A tte ndsM e e t ing (ip,m)
D D D D D D D D D
Dependencia de metas
dependencia de recueros
dependencia de tareas Dependencia de metas soft
UNPSJB - 2005
O Opend (uncommited) X Criticas
47
Modelo racional muestra interacciones entre metas dentro de cada actor
Iniciador del encuentro

Attends Meeting
Participante del encuentro ParticipateIn Meeting D Attend Meeting

Quality (proposed DAte) Convenie nt(meetin g, Date)
D Organize meeting
Muestra nivel ms 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 descomposicin 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 Ingeniera de Software - Clase 3
Meta Cecurso Meta Sof t Tarea
-+
Arrenge Meeting Low Effort
Agreable (meeting, Date) Find Agreable Date
+
D D
User Friendly Min Interrupt ion
D D
Agree To Date
Tarea - link de descomposicn Link means-end contribucin a meta sof t
48
Conclusiones sobre i*
Ganar entendimeinto en los requerimientos del sistema Mayor nmero de niveles de anlisis en trmino de Habilidad Viabilidad Credibilidad de requerimientos
Resumiendo Mejor representacin y razonamiento del conocimiento Mayor nivel de formalidad en las expresiones Se incorpora intencionalidad relaciones mltiples y distribuidas de intencionalidad
49
UNPSJB - 2005
Revision de modelos: KAOS
Rasgos
Desarrollado al principio de los 90 Primer lenguaje de modelado de requerimientos orientado al desarrollo integral de los mismos Herramientas de soporte completas Aplicado en muchos casos de uso Tambin centrado en el por qu, cmo y cuando. Dos partes Modelado informal de metas Definicin formal para cada entidad en lgica temporal
UNPSJB - 2005
Revision de modelos: KAOS
Caractersticas
El mtodo se centra en la elaboracin de metas
Define un conjunto inicial de metas y objetivos de alto nivel Define un conjunto inicial de agentes y acciones que estos agentes pueden hacer Refina las metas usando una descomposicin denominada AND OR
Luego iterativamente
Identifica obstculos a las metas y conflictos entre metas Lleva las metas a limitaciones que pueden ser luego asignadas a agentes individuales Refina y formaliza las definiciones de objetos y acciones
51
UNPSJB - 2005
Modelado y anlisis
Anlisis de sistemas varias escuelas
Anlisis orientado a datos Anlisis estructurado Anlisis OO
Modelos se utilizan para desarrollar una comprensin del sistema a realizar tres vistas:
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
UNPSJB - 2005
52
Anlisis estructurado
Definicin
Proveer un marco de trabajo para modelar de forma 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 difcil comprensin por parte de los Target principal de sistemas usuarios SI
Se deben entender los requerimientos necesarios para continuar en la evolucin del sistema
UNPSJB - 2005
53
Conceptos centrales
Entidad externa
Transformacin de datos Flujo 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 Lugar donde se deja info para su uso posterior Los almacenes de datos son pasivos, no transforman los 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 Unidad bsica de informacin
54
Almacenamiento de datos

Grupos de datos
Elemento de dato
UNPSJB - 2005
Herramientas de modelado
DFD

Diagrama de contexto Diferentes niveles de descomposicin Llegar hasta primitivas funcionaels que no pueden ser ms descompuestas Elementos

Diccionario de datos Define cada elemento de dato Usa una notacin BNF para definir la estructura de los elementos Constructores
Notacin = Significado Est compuesto de Y
Procesos Flujos Almacenes de datos Entidades externar
Construccin
Secuencia
Seleccin Repeticin
[|] { }n
() **
O bien N repeticiones de
Datos opcionales Delimita comentarios
UNPSJB - 2005
55
Especificacin de procesos
cdigo en lenguajes narrativo o en algn pseudo cdigo Define los rasgos procedurales escenciales
DFD evolucion para poder representar TR
Evoluciones
UNPSJB - 2005
56
Anlisis OO
Conceptos bsicos
Motivacin
Se modela los requerimientos en trmino de objetos y los servicios que estos proveen Representan los datos y su procesamiento Muestra de una forma clara como se clasifican las entidades del sistema y como se componen (de otras entidades) Son una forma natural de reflejar al mundo real (objetos)
AOO es ms natural
El sistema evoluciona las funciones que realiza tienden a cambiar los objetos permanecen iguales Esto no es representable con AE (debe cambiarse) El trabajo con OO es ms mantenible
Mayor nfasis en definir correctamente interfases entre objetos
Comparado con la ambigedad de los DFDs

57
UNPSJB - 2005
Anlisis OO
Primitivas de modelado
Relaciones
Objetos
Dos tipos:

Entidades con estados, atributos o servicios Forma de agrupar objetos Abstracciones jerrquicas con una relacin ES_UN
Todo parte Es un
Clases

Mtodos o servicios
Operaciones que un objeto puede llevar a cabo Forma de invocar los mtodos o servicios Secuencia de pasaje de mensajes entre objetos Representan interacciones especficas
58
Pasaje de mensajes
Atributos Representan estados del
Escenarios y casos de uso
objeto Pueden especificar: tipo, visibilidad y modificacbilidad
UNPSJB - 2005
Anlisis OO
Conceptos fudamentales
Herencia
Simple o mltiple
Ocultamiento de informacin Agregacin
Puede describir relaciones entre las partes y el todo
UNPSJB - 2005
59
Anlisis OO
Que cosas pueden ser objetos
Roles
Entidades externas
Que interactan con el sistema a modelizar (personas, dispositivos, otros sistemas) Que son parte del dominio que se modeliza (reportes, seales)
Unidades organizacionales
Llevados por personas que interactan con el sistema Relevante a la aplicacin (deptos, divisiones, equipos) Que establecen el contexto del problema Que definen una clase (sensores, computadoras)
Lugares
Cosas
Estructuras
Ocurrencias o eventos
Que pueden ocurrir en el contexto del sistema (transferencias de recursos, acciones de control)
Los procedimientos (imprimir, copiar) y los atributos no son objetos
UNPSJB - 2005
60
Anlisis OO
Caractersticas de seleccin de objetos deben
Retener informacin
atributos
Servicio necesario Operaciones identificables Atributos mltiples
No tener uno solo Aplicables a todas las ocurrencias del objeto no solo a uno
Atributos comnes
Requisitos esenciales Entidades externas que aparecen en el espacio del problema y producen o consumen informacin
Los objetos vlidos debe satisfacer todas o casi todas las propiedades anteriores.
61
UNPSJB - 2005
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
UNPSJB - 2005
62
Anlisis OO
Objeto Atributos
Paciente
Nombre Fecha de nac Altura Peso
Paciente
Servicio
Nombre Fecha de nac Altura Peso
Clasificacin Mandatario
todo parte
1,m 1,m 1,m 1 Class Attribute 1 Class Attribute
Ingreso paciente
Cama Habitacin Serv ice
Alta paciente
medico ltima v isita
1 Class Attribute
Serv ice Serv ice Serv ice Serv ice
UNPSJB - 2005
63
Anlisis OO
AOO de Shlaer y Mellor
Proceso de seis pasos
Desarrollar un modelo de informacin
Con objetos, relaciones y atributos de objetos y relaciones
Definir la dinmica del sistema
Definir el ciclo de vida para los objetos Definir la dinmica de relaciones
Producir un modelo de tiempo y control a nivel del sistema
Desarrollar modelo de procesos
Modelo de estado para relaciones entre objetos que evolucionan en el tiempo
Para cada accin un diagrama de accin y flujo de datos
Definir dominios y subsistemas
Descomponer en partes
64
UNPSJB - 2005
Anlisis OO
UML

Unified Modeling Languaje La ltima generacion de mtodos OO
Desarrollado pro Booch, Rumbaugh y Jacobson

An en desarrollo Trata de estandarizar los conceptos de modelado OO que manejan varios autores
Es una notacin aceptada como estndar
Tiene un meta modelo estandarizado, compuesto por
Diagramas de clases Diagramas de casos de uso Diagramas de caminos de mensajes Diagramas de mensajes de objeto Diagramas de estados Diagramas de mdulos Diagramas de plataformas
Lo desarrollaremos en la clase 5 ntegramente.

65
UNPSJB - 2005
Anlisis OO
Evaluacin de AOO
Ventajas de OO para IR Se acomoda bien para el diseo y la implementacin contina una forma de pensamiento y notacin No pone nfasis en la funcin como lo hace AE Evita la fragmentacin que produce el AE Desventajas Complejo para rescatar caractersticas dinmicas de los objetos No es claro que siempre se quiera modelar objetos, servicios y relaciones Tendencia a pasar rpidamente al diseo No es la bala de plata pensada por muchos
UNPSJB - 2005
Mtodos formales en IR
Qu formalizar en IR?
Modelar el conocimiento de los requerimientos (se puede razonar sobre ellos) Especificar requerimientos (se puede hacer una documentacin precisa) Por que formalizar?
Permitirnos razonar sobre los requerimientos
Chequear propiedades automticamente Testear consistencia, explorar consecuencias
Permitirnos animar y ejecutar los requerimientos
Para remover ambigedad y mejorar precisin Proveer una base para la verificacin de lo que los requerimientos deben conocer
Ayuda en la visualizacin y validacin
Se podr formalizar eventualmente cualquier cosa
IR es un puente desde el mundo informal hacia el dominio formal de mquina
UNPSJB - 2005
67
Por qu no se formaliza?
Los mtodo formales tienden a ser de un nivel ms complejo que los otros mtodos
Incluyen mucho detalle
Tratan de concentrarse en la consistencia y correctitud del modelo
Normalmente modelizamos inconsistencias, incompletitudes y cosa incorrectas
La gente no sabe que herramientas son apropiadas Especificacin de comportamiento de programa vs. Modelado de requerimiento Los mtodos formales requieren un esfuerzo mayor Y la remuneracin es la misma....
UNPSJB - 2005
68
Que son los mtodos formales?
Vista amplia Aplicacin de matemtica discreta a la IS Involucra modelado y anlisis Con notacin precisa matemtica-like Vista estrecha Uso de lenguajes formales
Un conjunto de strings sobre un alfabeto bien definido con reglas para distinguir que esos strings pertenecen al lenguaje
Razonamiento formal sobre formulismo en el lenguaje
Pruebas formales: usan axiomas y reglas de prueba para demostar que alguna frmula est en el lenguaje
UNPSJB - 2005
Anlisis formal clases
Anlisis de consistencia y chequeo de tipos Validacin Predecir comportamiento Verificar refinamiento de diseo
UNPSJB - 2005
70
Ventajas prcticas de los mtodos formales se encuentra ms errores
Generalmente encontrados en la escritura de la especificacin formal que en el proceso de anlisis formal El anlisis formal encuentra menos errores pero ms sutiles Errores tpicos encontrados Interfases incorrectas Requerimientos incorrectos (en funcin de las entradas que se disponen) Problemas de claridad y mantenibilidad
UNPSJB - 2005
71
En que difieren los mtodos formales
Ontologa
Puede ser fija o extensible Lgica (predicado de primer orden) Otra (lenguajes algebraicos o teora de conjuntos Z)
Base matemtica
Tratamiento del tiempo Modelos estado
evento Tiempo como una objeto primario
Ejemplos SCR: fijo, lgica temporal, modelo estado evento RML: fijo, lgica de predicado de primer orden, modelo estado evento discreto Telos: extensible, tiempo como un objeto primario.
UNPSJB - 2005
72
Tres tradiciones de lenguajes
Lenguajes formales de especificacin
Grueso del trabajo en verificacin de programas Chequeo de tipos, prueba de teoremas Ej: Z, VDM Formalizan modelos dinmicos de comportamiento de sistemas
Basados en sistemas reactivos (TR) Chequeo de consistencias, chequeos de modelo Ej: RSML, SCR
Capturar conocimiento del mundo real Pone nfasis en modelado de entidades del dominio, actividades, agentes y aserciones Motores de inferencia, razonamiento por defecto Ej: Telos, RML
73
Modelado formal conceptual
Modelado de sistemas reactivos

UNPSJB - 2005
Comunicando requerimientos SRS (soft req. Specification)
El problema es como SRS Propsito comunicar los Comunicar los requerimientos de requerimientos al resto de forma clara los interesados Se explica el dominio de la aplicacin

El SRS hace esto Veremos

y del sistema que se va a desarrollar Es un elemento legal Expresa un acuerdo
Contractual

como construirlo, los problema que pueden surgir, Estndares de construccin
Lnea base para la subsecuente evolucin de productos

Soporta testeo, verificacin y validacin de sistemas Puede contener informacin para verificar que se alcancen los requerimientos
74
UNPSJB - 2005
SRS (soft req. Specification)
Lnea base para el control de cambios

Desarrolladores y programadores
Cambio de requerimientos Evolucin del soft
Tienen que implementar los requerimientos
Audiencia a quien se dirige Usuario, clientes
Testers
Ms interesados en los requerimientos No interesados en req. del soft
Determinan que requerimientos han sido alcanzados
Analistas de sistemas
Administradores de proyectos
Escriben especificaciones que interactan
Miden y controlan el proceso de anlisis y desarrollo del sistema
UNPSJB - 2005
75
SRS (soft req. Specification)
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
Refleja el entendimiento del desarrollador Base del desarrollo
El desarrollador seleccionado

UNPSJB - 2005
76
Como hacer una especificacin
Considerar dos proyectos
Uno pequeo, 1 pgm, 6 meses (A)
El programador charla con el cliente y escribe hasta 5 pginas de requerimientos Equipo de analistas modelan requerimientos, SRS 500 pginas.
Proyecto (B) Construye un documento, debe contener mucho detalle para todos los pgmdor Se debe usar la espec. para estimar recursos necesarios y plan de desarrollo. 1 programadores, equipo V&V, adminis 2 clientes
77
Gran proyecto, 50 programadores, 2 aos (B)
Proyecto A Propsito de la Especificacin Vista de administracin lectores

UNPSJB - 2005
Representa el entendimiento del programador, vuelve al cliente La especificacin es irrelevante, se tiene alocados los recursos 1 autor de especificacin 2 cliente
Como hacer una especificacin
Aspectos
Necesario
Validez (correctitud)
Expresar los req. Actuales
Completitud Especificar todo lo que el

sistema necesita y debe hacer Responder a todas las entradas posibles Completitud estructural
No ambiguo
No contener cosas que no se requieren Cada sentencia se lee de una sola forma Definir trminos confusos en un glosario Test de satisfaccin por cada cliente debe existir Cada req. Es especificado con comportamiento Por especialistas no informticos Debe mantenerse actualizado
78
Verificable

Consistencia

No contradecirse Usar trminos de manera consistente
Entendible (claro)
Modificable
UNPSJB - 2005
Las especificaciones problemas
Que puede suceder

expandidas
ambiguas
condensadas
expanden
Redundantes Ambiguas No entendibles Inconsistentes incompletas
redundantes
reducen agrega explicacin
formalizan
inconsistentes
Resuelven
no entendibles
incompletas
UNPSJB - 2005
79
Errores tpicos de especificacin
Ruido
Silencio
Tener texto poco relevante como contenido Rasgo importante no cubierto en el texto Texto que describe una solucin ms que un problema
Referencia hacia delante
Pensamiento deseado
Utilizar un concepto an no definido Texto que define un rasgo que no puede ser validado Desparramar requerimientos por todos lados y luego poner referencias cruzadas No conforme a estndares
Sobre especificacin
Puzzles
Contradiccin
Ambigedad
Texto que define un rasgo de varias formas incompatibles entre ellas Texto que se interpreta de dos o ms formas diferentes
Requerimientos mal definidos
Terminologa inventada o inconsistente Escribir de manera hostil para el lector
UNPSJB - 2005
80
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
UNPSJB - 2005
Calidad de especificacin
Anlisis de texto
Se pueden hacer anlisis textuales del SRS Medir la forma de construccin Ej; NASA usa nueve indicadores

Continuidad de los requerimientos imperativos

Establecer normas para organismo Palabras dbiles Imperativo

Palabras como sigue abajo, como sigue, etc. Mide la estructura del SRS Causan incertidumbre Ej. Adecuado, aplicable Indicacin a tablas, figuras Mide calidad del documento Lneas de texto, prrafos, hojas
Opcin
Identifica palabras como debe, es requerido, etc. Se mide cuan explcito es el SCR Palabras como puede, opcional,etc. Mide las opciones que presenta SCR Nmero de estilos por palabra, nmero de palabras por sentencia, etc.
Directivas Tamao
Estructura del texto
Estadsticas de legibilidad
Especificacin de profundidad
Mide el nmero de identificadores de sentencias
Mide profundidad de subsecciones Marca la estructura del SRS
UNPSJB - 2005
82
Ej. De texto ambiguo
El sistema deber reportar al operador todas las fallas que se originen en funciones crticas o que puedan ocurrir durante la ejecucin de secuencias crticas y para las que no haya planes de recuperacin
Originan en funciones crticas Ocurren durante secuencias crticas No hay planes de recuperacin
V V V
F V V
V F V
F F V
V V F
F V F
V F F
F F F
Se avisa al operador?
UNPSJB - 2005 Ingeniera de Software - Clase 3 83
Como evitamos ambigedad?
Revisar especificaciones en lenguaje natural

Usar personal con diferentes bases de conocimiento Incluir gente de soft, gente que entienda el problema, y usuarios El revisor debe ser diferente al autor
Notacin semiformal (tablas, grficos) Lenguajes de especificacin formales Poner un requerimiento ms de una vez ayuda al lector a comprender Pero es redundancia Se debe usar una notacin ms formal y no repetir.
Explorar por redundancia
Usar lenguajes de especificacin
Conjunto restringido del idioma
UNPSJB - 2005
84
Caractersticas de un SRS
Modificabilidad

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

Notacin til
UNPSJB - 2005
85
Estndar IEEE para SRS
IEEE introduce un estndar de 5 pasos:
Partes de un SRC
Revisin
Referencias
Describe aproximaciones recomendadas para la especificacin de requerimientos. A otros modelos IEEE Conceptos bsicos para la prctica del modelo
Est compuesto de cuatro secciones cada una con subsecciones
Definiciones
Consideraciones para producir un buen SRS
Secuencia de 8 pasos para lograr ese fn
Leer cuidadosamente el paper IEEE prctica recomendada para especificacin de Req. De soft (paper Q) La especificacin del trabajo integrador deber hacerse siguiendo esta metodologa
UNPSJB - 2005
86
Trazabilidad de requerimientos
Definicin
El documento en cuestin contiene o implementa todas las estipulaciones aplicables en el documento predecesor Un trmino dado, acrnimo o abreviacin significa la misma cosa en todos los documentos Un tem o concepto se referencia por le mismo nombre o descripcin en el documento Todo el material en el documento sucesor tiene las bases del predecesor, esto es, no se agrega material que no se pueda trazar Dos documentos no se contradicen
UNPSJB - 2005
87
Resumiendo
Importancia
Es una demostracin de completitud, necesidad y consistencia Una camino claro de alocacin y seguimiento de flujo a travs del documento Una derivacin a travs de una jerarqua
Para la verificacin y validacin
Evaluar adecuadamente los test disponibles Evaluar la conformidad de requerimientos Evaluar la completitud, consistencia y anlisis de impacto Evaluar el diseo hacia atrs y hacia delante Investigar como el comportamiento de mayor nivel impacta en la espeficacin detallada. Detectar conflictos de requerimientos Chequear consistencia a travs del ciclo de vida
88
UNPSJB - 2005
Mantenimiento
Evaluar los pedido de cambio Trazar un diseo racional (lgico)
Proveer posibilidad de audicin De cambio De riesgo De control sobre el proceso de desarrollo
Administracin

Acceso a documentos Habilidad de
encontrar informacin rpidamente en grandes documentos
Dificultades
Costo
Visibilidad de proceso Habilidad para ver

como el soft se desarrolla
Muy poco soporte automatizado Completa trazabilidad es muy cara y consumista de tiempo
UNPSJB - 2005
89
Gratificacin demorada La gente que define los links de trazabilidad no son gente que se beneficie con ellos
Tamao y diversidad
Desarrollo vs V&V
Mucho del beneficio se observa tarde en el ciclo de vida
Test, integracin, mantenimiento
Gran rango de documentos distintos, herramientas, decisiones, responsabilidades No hay esquemas comunes para clasificar y catalogar requerimientos En la prctica, la trazabilidad se enfoca en lneas base de requerimientos.
UNPSJB - 2005
90
Prctica corriente de trazabilidad
Cobertura
Links desde los requerimientos hacia el diseo, codificacin y casos de test Links hacia atrs: desde test, codificacin y diseo a requerimientos Links entre requerimientos en diferentes niveles Asignar un nico ID cada sentencia o prrafo
Proceso de trazabilidad
Identificar manualmente links Usar tablas manuales para grabar links en los documentos Usar la herramienta de trazabilidad (BD) para la trazabilidad de un gran proyecto Las herramientas tienen la habilidad de

Seguir los links Encontrar links perdidos Medir la trazabilidad total
UNPSJB - 2005
91
Herramientas para trazabilidad
Cuales?
Limitaciones
Hipertexto (links) Palabras clave que
identifican conceptos asociados a ella
Identificadores nicos
Coeficientes de similaridad sintctica
Cada requerimiento tiene un Ej ID nico con una BD de Herramientas de BD (RTM, referencias cruzadas SLATE, DOORS)
Todas requieren un gran esfuerzo manual para definir los links Todas tienen informacin puramente sintctica, sin contexto semntico
Busca la ocurrencias de patrones de palabras
Herramientas de hipertexto (document director, netscape navigator) Herramientas de desarrollo general
UNPSJB - 2005
92
Herramientas para trazabilidad
Limitaciones de herramientas
Comunicacin informal
Problemas de informacin Fallan en rastrear
informacin de trazabilidad
por ej. No pueden decir quien es el responsable de determinado dato
Mala trazabilidad de prerequerimientos
Desde donde vienen los requerimientos?
Falta de convenio
Sobre la cantidad y tipo de informacin trazada
La gente le da mucha importancia la contacto entre personas con comunicacin informal Se suplementa lo que se almacena en la BD de trazabilidad El resultado es una BD de trazabilidad que solo da parte de la historia An con la herramienta no es fcil encontrar las personas que generaron el requerimiento
UNPSJB - 2005
93
Trazabildiad Cuestiones problemticas
Cuales son?
Cambio
Intervencin
Quin estuvo involucrado en la confeccin de los requerimientos?
En que punto del ciclo de vida se produce un cambio o evolucin de req? Quien necesita ser avisado por cambios en los req?
Notificacin
Responsabilidad Quien es responsable
por este req? Quin es el responsable actual? En que punto de ciclo de vida el responsable cambia?
Prdida de conocimiento
Cuales son las ramificaciones asociadas a la prdida de conocimiento?

94
UNPSJB - 2005
Validacin de requerimientos
Qu veremos
Dos problemas con la toma de req.
Negociacin sobre requerimientos
El problema de la validacin
Que es verdadero y que es conocible?
El problema de la negociacin
Como reconciliar conflictos entre metas en un contexto social complejo
Conflictos y su resolucin Tcnicas para negociar requerimientos
Validar requerimientos

Inspecciones y revisiones prototipeo
Aproximaciones para argumentar Aproximaciones basadas en conocimiento
Priorizacin de requerimientos
UNPSJB - 2005
95
El problema de validar
Aproximacin lgica positivista
Hay un objetivo en el mundo que puede ser modelado construyendo un cuerpo consistente de conocimiento basado en observacin emprica
Usar herramientas que testeen consistencia y completitud del modelo Usar revisiones, prototipos etc para demostrar que el modelo es vlido
En IR se asume que hay un problema objetivo que existe en el mundo Construir un modelo
consistente (validarlo con observaciones empricas)
Modificacin a la lgica positivista (Popper)
Las teoras puede no proveer cosas correctas, se puede refutar encontrando excepciones Las teoras son cientficas si pueden ser refutadas
UNPSJB - 2005
96
El problema de validar
En IR, disear modelos de req para ser refutables
Ver por evidencia que muestre que el modelo es errneo
Aproximacin post modernista
No hay punto de vista privilegiado, todas las valoraciones son iguales
Usar actores para que construyan sus propios modelos de requerimientos Usar tcnicas etnogrficas para entender el problema.
En IR, la validacin siempre es subjetiva y contextualizada

UNPSJB - 2005
Revisiones e inspecciones
Como tratarlos
Desde el punto de vista de la formalidad
Asistido por clientes

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

Ms efectiva que el testing La mayora de los programas corren bien la primera vez
Se encuentra entre un 60 y 80% de errores durante la inspeccin Reduccin de costo entre el 50 y 80% para V&V.
Datos desde grandes programas
Efectos sobre competencia del staff

El factor de reduccin de errores es 5. Mejora la productividad en un 15 a 25%.
Incrementa la moral Mejor estimacin y planificacin Mejor administracin de las habilidades del staff
Estos beneficios son tiles para IR!!!!

99
UNPSJB - 2005
Limitaciones de la inspeccin
Tamao
Suficiente gente de manera que todos los expertos estn disponibles Mnimo 3 mximo 7 personas Nunca ms de 2 horas (se pierde objetividad y concentracin) Todos los revisores deben de estar de acuerdo con los resultados
Todos los tem evaluados deben estar documentados
Duracin
Reporte que resuma el trabajo Lista detallada de aspectos relevantes
Alcance
Salidas
Tomar pequeas partes, nunca el todo Examinar el producto cuando el autor termina con l.
100
Timing
UNPSJB - 2005
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 Obtener datos que ayuden a no cometer el error en el futuro
Propsito
UNPSJB - 2005
101
Guas para la revisin
Guas para la inspeccin
Antes de la revisin
Planificar las revisiones formales (RTF) en el plan del proyecto Entrenar a los revisores Asegurar que todos los asistentes estn preparados
Durante la revisin Revisar el producto

no al autor
Pegarse a la agenda Limitar el debate y la refutacin Identificar problemas pero no tratar de solucionarlos Tomar notas escritas
Evitar comentarios profesionales o destructivos

Luego de la revisin Revistar el proceso de revisin

102
UNPSJB - 2005
Eleccin de los revisores
Posibilidades

A quien excluir:
Especialistas en revisin (gente de QA) Gente del mismo equipo del autor Gente invitada por ser especialistas Gente interesada en el producto final Gente que tenga algo para contribuir Gentes de otra parte de la organzacin
Cualquier responsable directo o indirecto del autor Cualquiera con problemas personales declarados contra el autor Cualquiera que no est calificado en revisin Todos los administradores Cualquiera que tenga conflicto de intereses
UNPSJB - 2005
103
Estructuracin de la inspeccin
Se puede hacer la estructura de la revisin de varias formas:
Revisiones activas (escenarios)
Ad hoc:
Confiar en el experto en revisin
Lista de chequeos
Cada revisor lee con un propsito especfico, 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 mtodos A lista se hace a No hay una diferencia medida del marcada entre los dos documento evaluado
primeros
UNPSJB - 2005
104
Prototipacin
Definicin
Un prototipo de soft es una implementacin parcial construida para permitir al cliente, usuario o desarrollador aprender ms sobre el problema o su solucin Prototipar es el proceso de construir o trabajar sobre el modelo del sistema Primera prototipo descartable Segunda prototipo evolucionable
Respecto de definicin

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

Ventajas
Descartables
Descartables Evolucionables Tercer opcin: operacionales
Propsito

Uso
Aprender ms sobre el problema o su solucin Obtener conocimiento Etapas tempranas o posteriores
Aprender el medio de trabajo para lograr una mejor adaptacin a las necesidades y solucin Entrega temprana, test temprano, menos costo Bueno an cuando falle Derrochar esfuerzo si los requerimientos cambian rpidamente Generalmente el prototipo reemplaza documentos
107
Desventajas
Aproximacin
Rpida y sucia
UNPSJB - 2005
Evolucionables
Ventajas
Propsito Aprender ms sobre el
problema o su solucin Reducir el riesgo de construir partes del sistema en forma temprana Incremental, evolucionable Vertical: necesita desarrollo riguroso e incremental
Los requerimientos no estn congelados Solo se retorna al incremento anterior si se encuentra un error Flexible ? Est en la otra punta de los mtodos estructurados No se garantizan las soluciones ms efectivas Poco control y direccin
108
Uso
Desventajas
Aproximacin

UNPSJB - 2005
Prototipos organizacionales

Ofrecen un balance entre los casos anteriores Pasos involucrados
Se crea un prototipo evolucionable, basado en una lnea base usando metodologa clsica (cascada) La lnea base se enva a varios clientes junto con prototipadores experimentados El prototipador evala al cliente con el sistema
El prototipador graba las experiencias del usuario El usuario le dice al prototipador por necesidades faltantes El prototipador hace cambios rpidos en el prototipo El usuario reutiliza el nuevo prototipo Se gira sobre el prototipo rpido adaptndolo Cada cierto tiempo el prototipo y el prototipador retornan al laboratorio para adaptar mejor el prototipo (evolucionarlo) Esto se repite indefinidamente
UNPSJB - 2005
109
Acordando requerimientos
Aspectos
Negociacin y resolucin de conflictos Entre requerimientos encontrados Priorizacin de requerimientos 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.
Definicin de conflicto
UNPSJB - 2005
Acordando requerimientos
En IR, el foco es la inconsistencia lgica El conflicto es una divergencia entre metas, hay una condicin lmite que hace al objetivo inconsistente Nota: Los conflictos pueden ocurrir entre individuos, grupos, organizaciones o roles diferentes jugados por una sola persona No todas las partes del conflicto necesitan necesariamente ser participantes en la solucin presentada
UNPSJB - 2005
111
Modelo de resolucin
Aproximacin usada para dirimir el conflicto
Los mtodos incluyen

Trs modelos de resolucin
Negociacin Competicin Arbitraje Coercin Educacin
No todos los conflictos necesitan un mtodo de resolucin, as como no todos los conflictos necesitan ser resueltos
Cooperativo involucra negociacin Competicin involucra combate, coercin y competicin Resolucin por terceras partes arbitraje y apelar a una autoridad
UNPSJB - 2005
112
Modelo de resolucin
Negociacin
Competicin
Exploracin cooperativa en el rango de posibilidades Los participantes tratan de encontrar un punto comn que satisfaga a todas la partes
Alcanzar la mxima satisfaccin para el participante No tener en cuenta el grado de satisfaccin de las otras partes No ser necesariamente hostiles
Conocido como integracin constructiva o negociacin constructiva
Caractersticas Si yo gano, alguien

tiene que perder
UNPSJB - 2005
113
Modelo de resolucin
Terceras Partes

Se busca un rbitro para que decida Tipos
Licitar y negociar
Judicial: cada parte presenta tu base de conocimiento Extra judicial: se determina una decisin por factores mas que por los casos presentados Arbitraria: tirar una moneda
Licitar Los participantes establecen sus trminos deseados Negociar Los participantes buscan por la integracin satisfactoria de sus pedidos.
UNPSJB - 2005
114
Conflictos en sicologa social
Causas de conflictos
Deutshc (1973) Control sobre los recursos Preferencias y estorbos (gustos o actividades de una parte chocan contra otra) Creencias (disputas sobre hechos, informacin, realidad) La naturaleza de relacin entre partes Robbins (1989) Comunicacional (intercambio insuficiente de informacin, ruido, percepcin selectiva) Estructural (compatibilidad de metas, claridad jurisdiccional, estilo del lder) Factores personales (sistemas de valores individuales, caractersticas de personalidad)
UNPSJB - 2005
Experiencias resultados
Algunos aspectos observados
(hacer un mea culpa respecto de la realidad de cada uno)
Los conflictos son normales en pequeos grupos que toman decisiones Ms agresin y menos cooperacin si se restringe la comunicacin
Los grupos heterogneos son ms conflictivos (an si son ms experimentados), los grupos homogneos son mejores para tomar decisiones ms riesgosas El efecto de la personalidad es eclipsado por factores de situacin o de percepcin
UNPSJB - 2005
116
Severidad sobre el conflicto

A
Nuestra satisfaccin
Nuestra satisfaccin
mutualmente exclusivos
A y B combinados
A y B combinados
interf irientes
Satisf accin de otras partes
Nuestra satisfaccin
Nuestra satisfaccin
A y B combinados
P ara dos posiciones iniciales A y B, se puede medir la severidad del conf licto examinando que sucede cuando se combinan
inclusivos
no interf irientes
B
UNPSJB - 2005
117
Clasificacin de conflictos sociales

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

URSS vs Hungria
Estado vs mafias
CEE vs Reino unido
118
Teora del juego
Teora del juego en la resolucin de conflictos
Ej: dilema del prisionero

No Confiesa No Confiesa
Prisionero B Confiesa
Dados

Dos o ms jugadores Utilidades conocidas para cada uno de los jugadores Cual estrategia resulta en el mejor resultado Como interactan las estrategias de los jugadores
un ao a cada uno tres meses para A y 10 aos para B
Prisionero A Confiesa
10 aos para A y 3 meses para B 8 aos para uno
Puede calcular
Pero

En IR, no sabemos cuales son las utilidades Se puede resolver conflictos pidiendo a los participantes que cambien sus utilidades No sabemos ni siguiera que movimientos son posibles
119
UNPSJB - 2005
Argumentacin
gIBIS

Desarrollado en 1989 Representa el proceso de argumentacin como un grafo hipertextual Proceso bsico

Uso 1
generaliza
responde a
Posicin 1
objeto de soporte preguntas
Argumento 1
Argumento 2 Argumento 3
Identificar usos Identificar posiciones que se pueden adoptar con respecto a las posiciones Linkear argumentos que soporte o refuten posiciones
Uso 2
responde a
Posicin 2
preguntas objeto de
objeto de
Argumento 4
es sugerido por
Uso 3 Argumento 5 Uso 4
UNPSJB - 2005
120
Argumentacin
Sinptico
Propuesto por Easterbrook (1991) Herramienta que soporta la negociacin colaborativa enfocada en tareas Proceso bsico (ampliar el paper) Toma cada participante para exteriorizar sus modelos conceptuales Encuentra correspondencias entre los modelos Clasifica los puntos de disidencias Genera opciones para resolver cada disidencia
UNPSJB - 2005
121
Otros casos
Usando modelos pre-existentes
OZ

WinWin

Desarrollado por Robinson (1992) Usa el modelo de dominio preexistente para comparar perspectivas de conflicto Proceso bsico

Identificar perspectivas (coleccin de creencias) Guardar perspectivas anotando el modelo de dominio de metas y objetivos El modelo de dominio linkea atributos del producto a metas Elegir combinaciones de atributos de productos para maximizar la satisfaccin de participantes
Desarrollado por Bohem (1990) Identifica condiciones de triunfo de cada participante Incorpora el conocimiento base del dominio para calidad de requerimientos y links de atributos del producto Proceso bsico

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

Administracin tradicional del cambio

Guas Administracin de configuracin
UNPSJB - 2005
123
Tipos de programas
Programas Especificables
Problemas que pueden ser establecidos formal y completamente Aceptacin: el programa est acorde con su especificacin? Este soft no evoluciona
de se ue nar p io lac con re
Sentencias formales del problema
pr con od tro uc la ci la n de
Mundo Real
pue de de se inte r rs
Programa
ov Pr ee
Un cambio en la especificacin define un problema nuevo, entonces hay un programa nuevo
Solucin
UNPSJB - 2005
124
Tipos de programas
Programas para solucin de problemas
Sentencias imprecisas del problema del mundo real Aceptacin: el programa es una solucin aceptable al problema? El soft evoluciona continuamente
Cambia
Mundo Real Vista abstracta del mundo real Compara Cambia Especificacin de requeriminetos
Porque la solucin nunca es perfecta, y puede ser mejorada Porque el mundo real cambia y entonces el problema cambia
Solucin
Programa
UNPSJB - 2005
125
Tipos de programas
Programas empotrados
Un sistema que es parte del mundo al que modeliza Aceptacin: depende enteramente de una opinin o un juez Es inherentemente evolcionario Los cambios en el soft y el el mundo real se afectan entre s
Mundo Real Cambia Programa
Especificacin de requeriminetos
Vista abstracta del mundo real
Modelo
UNPSJB - 2005
126
Leyes de la evolucin de pgms.
Continuidad del cambio
Ley fundamental
Cualquier soft que refleje una realidad externa est en cambio continuo o se torna progresivamente menos utilizado El cambio contina hasta
que se crea que es mejor tirarlo y hacerlo de nuevo
La evolucin del soft es regulada con tendencias y variantes estadsticas
Conservacin de la estabilidad Organizacional
Incremento de complejidad
Durante la vida activa del soft, el trabajo de salida de proyecto de desarrollo es constante
A medida que el soft evoluciona, la complejidad se incrementa
Conservacin de la familiaridad
Durante la vida activa de un programa el porcentaje de cambios permanece constante
UNPSJB - 2005
127
Crecimiento en requerimientos
Modelo de Davis
El usuario necesita evolucionar continuamente
El desarrollo tradicional queda detrs de las necesidades de crecimiento
El grfico presenta el crecimiento de necesidades en el tiempo Puede ser no lineal o no continuo
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
UNPSJB - 2005
128
Mantenimiento del software
Filosofa de mantenimiento
Proceso de mantenimiento de Basili
Modelo fijo rpido

Alguien ms es el responsable del mantenimiento
Se pierden Inversiones en conocimiento y experiencia El mantenimiento se convierte en un desafio de la Ing. Reversa
Modelo iterativo Cambios hechos en base al anlisis
Los cambio hechos a nivel de cdigo, tan fcil como se pueda Rpidamente degrada la estructura del soft de soft existente Trata de controlar la complejidad y mantener un buen diseo Empieza con los requerimientos de un nuevo sistema, reusando tanto como se pueda Necesita una cultura madura de reuso para tener xito
Modelo de reuso total
El equipo de desarrollo har un compromiso a largo plazo para mantener el soft
UNPSJB - 2005
129
Adm. Tradicional de mantenimiento
Los administradores necesitan responder el requerimiento de cambio
Agregar nuevos requerimientos durante el desarrollo Modificar requerimientos durante el desarrollo Porque el desarrollo es parte del proceso de aprendizaje Remover requerimientos durante el desarrollo Quiz por problemas de costos
UNPSJB - 2005
130
Adm. Tradicional de mantenimiento
Elementos de la administracin de cambio
Items de configuracin
Cada producto diferente durante el desarrollo es un tem de configuracin Control de versin para cada tem Versin estable del documento que puede ser compartida por el equipo Proceso de aprobacin formal para incorporacin de cambios
Proceso de administracin de cambio
Lneas base

Todos los cambios propuestos son enviados formalmente como pedidos El equipo de revisin toma los pedidos de cambio y decide o no su aceptacin El equipo de revisin considera la interaccin entre cambios de requerimiento
UNPSJB - 2005
131
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

Construir un modelo Hacerlo consistente y completo Validarlo
Se asume que al IR es un proceso con una salida simple La salida es una

especificacin completa, consistente y vlida
Los requerimientos son voltiles, se necesita administracin continua de cambio Las especificaciones nunca se completan Hay mltiples versiones de modelos en el tiempo Hay mltiples variantes del modelo que exploran diferentes temas
132
No hay nunca solo un modelo
UNPSJB - 2005
singularidad de productos
Hay mltiples componentes de modelos representando diferentes descomposiciones Las familias de modelos evolucionan con el tiempo (agregando, borrando, mezclando o reestructurando la familia)
La IR debe evolucionar los requerimientos
Como se administra el cambio incremental del modelo de req? Como se pueden comparar mltiples modelo? Como afectan los cambios del modelo a las propiedades establecidas para l? Como se puede capturar la racionalidad del cambio? Como tratar con las inconsistencias e incompletitudes del modelo
UNPSJB - 2005
133
Familias de Software
El reuso del soft intenta achicar costos
Desarrollo de programas (Java, C) Divide el desarrollo del soft en dos partes Anlisis del
dominio(identifica componentes reusables del dominio del problema Desarrollo de aplicacin (usa componentes de dominio para especificar aplicaciones)
El desarrollo de soft es caro, el reuso es ideal si los sistemas son similares
Ingeniera de dominio
Libreras de componentes reusables
Reusar conocimiento y experiencia ms que solo productos de soft El desarrollo de soft reusable es ms caro!!
Especficas de dominio (libreras del Math)
UNPSJB - 2005
134
Familias de Software
Familias de soft
Muchas compaas ofrecen sistemas de soft relacionados

Elegir una arquitectura estable para la familia Identificar las variaciones entre diferentes miembros de la familia
Representa una decisin estrategia de negocio sobre que soft desarrollar
UNPSJB - 2005
135
Puntos de Vista Motivacin
Mltiples perspectivas

Modelado distribuido
Muchos actores diferentes Diversas clases de conocimiento del dominio Vistas conflictivas (y negociacin) Muchos esquemas de representacin
Analistas y actores colaborando Mtodos mltiples de modelado Evolucin continua de requerimientos Links de comunicacin imperfectos
UNPSJB - 2005
136
Puntos de Vista Motivacin
Demoras en la resolucin de inconsistencias
Modelo simple con coercin de consistencia es muy restrictivo
Inconsistencias causas
Conflicto entre fuentes de conocimiento Diferentes interpretaciones Problemas de comunicacin entre desarrolladores Diferentes velocidades de desarrollo Divergencias en los mtodos previstos errores
Se transforman en cuellos de botella para el proceso de modelado distribuido La coercin previene la divergencia de ideas
Inconsistencias se dan en situaciones de incertidumbre
Resolucin prematura puede conllevar decisiones de diseo prematuras La inconsistencia implica que se necesita ms adquisicin de conocimiento Algunas inconsistencias nunca sern resueltas
137
UNPSJB - 2005
Marco de trabajo bsico
El modelo de requerimientos es una coleccin de puntos de vista
Los PV son instanciados desde templates
Para cada PV identificar

Propietario Dominio (que describe) Estilo (notacin o reglas utilizadas) Plan de trabajo (obligaciones de consistencia con otros PV) Historia de los cambios Especificacin de contenido
Tiene un estilo y un plan de trabajo El desarrollo de templates es una tarea separada Un mtodo provee un conjunto de templates designados para ser usados juntos
UNPSJB - 2005
138
Marco de trabajo bsico
Los PV contienen reglas de consistencia
Reglas de consistencia internas para chequeo de especificacin de PV Reblas Consistencia externa para chequeos entre PV Plan de trabajo provee guas para cuando aplicar cada regla de consistencia
UNPSJB - 2005
139
Ventajas de los PV
Actores y trazabilidad

Los propietarios de PV pueden ser roles, personas, equipos... Cada contribucin de un actor es modelizada en una notacin apropiada
Estructuracin del proceso de desarrollo

Los requerimientos pueden ser trazados hacia la fuente de los mismos
Cada actor puede validar e identificar su propia contribucin Se incrementa el concepto de propiedad en el proceso de requerimiento
Cada PV es una pieza independiente No hay control global, no hay esfuerzos globales para consistencia
Trabajo sincrnico o asincrnico Las reglas de chequeo de consistencia actan puntos explcitos de sincronizacin
140
UNPSJB - 2005
Ventajas de los PV
Estructuracin de descripciones
Las contribuciones de diferentes actores son modelizadas por separado Separacin de competencias Enriquece el modelo a travs del uso de mltiples estructuras de problemas Resolucin de inconsistencias puede verse demorada Soporta negociacin permitiendo comparacin detallada de PV Anima el modelado temprano y expresin de vistas diferentes
UNPSJB - 2005
141
PV hacia adonde???
Mtodo de ingeniera
Mtodo de diseo definir un conjunto de templates coherentes PV como una herramienta Meta CASE Un proceso de modelado de grano fino en cada PV
Proceso de modelado
Cuando deberan ser aplicadas
Como grafos Como predicados sobre estructuras de objetos Como expresiones de lgica de primer orden
Como pude la inconsistencia ser reparada una vez detectada? Cuales son las consecuencias de no repararlas?
Administracin de consistencia
Como presentar reglas Trazabilidad de requerimientos de consistencia inter Los PV asociados a actores PV? con sus contribuciones
UNPSJB - 2005
142
Administracin de inconsistencia
Como aparece una inconsistencia (como ya vimos)

Definicin de inconsistencia
Conflicto entre fuentes de conocimiento Interpretaciones diferentes Problemas de comunicacin entre desarrolladores Diferentes velocidades de desarrollo Divergencias entre los mtodos utilizados errores
Dos partes de las especificacin no obedecen la misma relacin que est definida para ellos Las relaciones pueden unir
Elementos sintcticos de especificacin parcial Semntica de elementos en especificaciones parciales Subprocesos del proceso de desarrollo
UNPSJB - 2005
143
Administracin de inconsistencia
Las relaciones surgen de:

Definicin de mtodos Experiencia prctica con el mtodo Contingencias locales durante el desarrollo
Las inconsistencias pueden solamente ser detectadas automticamente si las relaciones estn definidas formalmente
UNPSJB - 2005
144
Inconsistencia
La inconsistencia est en la IS
Las descripciones de IS varian mucho en formalidad y precisin Descripciones individuales pueden ser formadas mal o ser contradictorias Las descripciones continan evolucionando durante el desarrollo El chequeo de consistencia de un gran conjunto de descripciones es muy caro en trminos computacionales
Lecciones sobre inconsistencia en la prctica
Algunas inconsistencias nunca son solucionadas
Convivir con la inconsistencia es una decisin riesgosa Los factores de riesgo

cambian, el riesgo debe reevaluarse continuamente
Porque el costo de cambiar documentos sobrepasa el beneficio Porque los humanos son buenos inventando excusas
UNPSJB - 2005
145
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
UNPSJB - 2005
146
Conviviendo con inconsistencia
La deteccin es vital
Demorarla:
Convivir con inconsistencia es seguro si se tiene conocimiento de su existencia
Si se necesita informacin que no est disponible por el momento Tomar acciones que afinen la situacin pero que no resuelvan la inconsistencia Negociar una solucin o encontrar un compromiso
Manejo de inconsistencia
Mejorarla
Evadirla
Remover / reemplazar elementos inconsistentes, o remover / reemplazar reglas que fueron rotas Si puede ser aislada y no es importante
Resolverla:
Ignorarla
La inconsistencia indica, normalmente, que se necesita ms informacin
UNPSJB - 2005
147
Modelo de proceso de inconsistencia

reglas de consistencia
monitor para inconsistencia
Localizar
Inconsisten cia Detectada Caracterizacin de Inconsistencia
Ignorar
Diferir Evadirla mejorarla
Identificar
Tolerar
Inconsistencia Manipulada
Clasificar
Resolver
Midiendo Inconsistencias
UNPSJB - 2005
Analizando impacto y riesgo

consecuencas de monitoreos de acciones
PV para chequeo de consistencia
Quin es el responsable
Los propietarios de los PV son responsables por cambios locales en sus PV
Cada PV tiene su propio conjunto de reglas No se necesita control central
Pueden sugerir cambios a otros No pueden forzar la sincronizacin de PV
Cuando debera chequearse las relaciones entre PV?
El propietario del PV chequea las reglas cuando lo necesite
Como se expresan responsabilidades?
Como se chequean las relaciones entre PV?

Las reglas de consistencia expresan relaciones que deberan respetarse entre PV
El sistemas administrador de transacciones entre PV Los dos PV testeados son notificados de los resultados
UNPSJB - 2005
149
PV para chequeo de consistencia
Como resolver inconsistencias?

Las Acciones pueden no llevar a una solucin Las acciones surgen de los mtodos de diseo y de experiencias en su uso
Que sucede si cambios futuros interfieren con la resolucin?
Los chequeos exitosos no garantizan las relaciones se mantengan
Que sucede si no se resuelve la inconsistencia?
Cada regla puede necesitar ser aplicada un nmero de veces durante el desarrollo
Deben quedar documentadas Los cambios subsecuentes

pueden afectar a esa inconsistencia
Los cambios que afectan inconsistencias resueltas son trazados Las acciones involucradas en la resolucin son guardadas como parte de documentos
150
UNPSJB - 2005
Ejercicios y trabajos
Investigar sobre las metodologas de anlisis I* y KAOS (presentar un informe) Investigar sobre RTF Presentar un documento que resuma las actividades de las RTF describiendo cada paso involucrado Investigar sobre el estado del arte de la prototipacin. (a partir del paper que deben leer) Investigar sobre el estado del arte en la negociacin de conflictos Leer los papers: E,F,H,I,O,P,Q,U,V,W Buscar el paper Metodologas de Anlisis y Diseo convencional y OO del material 2002-2003.
UNPSJB - 2005
151

Clase 3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Clase 3

Încărcat de

Drepturi de autor:

Formate disponibile

Ingeniera de Software Clase 3

Ingeniera de Requerimientos (Toma, modelado, comunicacin, aceptacin y mantenimiento)

Modelizando Empresas y metas

Modelizando el comportamiento funcional

Modelizar funcionalidad Evolucin del Anlisis

Especificacin vs. Modelado de requerimientos Algunos ejemplos (investigacin) SCR

Ingeniera de Software - Clase 3

Contenido Clase 3 (cont.)

Usos filosficos Revisiones e inspecciones Prototipacin

Aceptando los requerimientos

Negociacin ante problemas Solucin de conflictos

Ingeniera de Software - Clase 3

Contenido clase 3 (cont.)

Ingeniera de Software - Clase 3

Ingeniera de Software - Clase 3

El Ing. de requerimientos es una agente del cambio Identificar el problema / oportunidad

Ingeniera de Software - Clase 3

La tcnica de las 6 W: What? Where? Who? Why? When? How (Which)?

Los cuatro mundos

Mundo del sujeto

Como la mquina representa inforamcin sobre el dominio de aplicacin

Mundo del uso

Mundo del sistema

Justificar las metas de desarrollo

Mundo del desarrollo

Dificultades para la adquisicin

Criterios para definir el dominio del conocimiento

Ingeniera de Software - Clase 3

Dificultades para la adquisicin

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

Ingeniera de Software - Clase 3

Tcnicas para toma de requerimientos

Mirar hacia dentro del problema

Grupos enfocados Brainstorming JAD/RAD

Documentos existentes Anlisis de datos Entrevistas

Aproximacin basada en representacin

Agenda abierta Estructuradas

Cuestionarios Adquisicin en grupos

Basada en objetivos Basada en escenarios Basadas en casos de uso

Ingeniera de Software - Clase 3

Tcnicas para toma de requerimientos

Aproximacin contextual (social)

Anlisis de tareas Anlisis de protocolos Tcnicas de adquisicin de conocimiento

Ordenamiento de tarjetas Grillas de repertorio Tcnicas de escalado de proximidad

No hay entrevistas con usuarios

Ingeniera de Software - Clase 3

Ricas en adquisicin de informacin

Muchos datos cualitativos difciles de analizar

Tcnicas de adquisicin en grupo

JAD o RAD Enfoque en grupo Brainstorming

Presentaciones, maquetas, etc.

Ingeniera de Software - Clase 3

Coleccin de datos complejos

Identificar los grupos de estos datos

Tamao del ejemplo

Ingeniera de Software - Clase 3

Que es un caso de uso?

Ingeniera de Software - Clase 3

Usando Casos de uso

Dibujar los lmites

Ingeniera de Software - Clase 3