ingeniería de software clase 3

Ingeniería de SoftwareClase 3

Ingeniería de Requerimientos(Toma, modelado, comunicación,

aceptación y mantenimiento)

UNPSJB - 2005 Ingeniería de Software - Clase 3 2

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

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 RML RSML


Contenido Clase 3 (cont.)

Comunicando requerimientos 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


Contenido clase 3 (cont.)

Evolucionando requerimientos Administración del cambio Administración de inconsistencia Rasgos de interacción Familias de productos para Administración

de requerimientos


Contenido Clase 3

Bibliografía utilizada Ingeniería de Requerimientos

(Locoupulous) Ingeniría de Requerimientos (Davis) Ingeniería de software (Pressman,

Sommerville) Papers Varios


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. de requerimientos es una agente del cambio

El Ing.Requerimientos debe Identificar el problema / oportunidad


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)?


Los cuatro mundos

Mundo delsujeto

Mundo deldesarrollo

Mundo deluso

Mundo delsistema

Interfases deusuario

Justificar lasmetas dedesarrollo

Como elsistema utiliza la

informaciónsobre el dominiode la aplicación

Como la máquinarepresenta

inforamción sobre eldominio deaplicación

Desiciones dediseño


Dificultades para la adquisición

Criterios para definir el dominio del conocimiento 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 Conocimiento tácito

Las personas encuentran difícil decir que necesitan o complican mucho la explicación


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”


Técnicas para toma de requerimientos

Técnicas tradicionales Introspección

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 Basada en objetivos Basada en escenarios Basadas en casos de

uso


Técnicas para toma de requerimientos Aproximación

contextual (social) 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 y formas de vida


Cuestionarios Ventajas

Puede obtener información rápidamente de muchas personas

Puede administrarse remotamente

Puede obtener actitudes y características de los actores

Desventajas Puede obtener un contexto

muy pobre del problema No hay entrevistas con

usuarios

Qué mirar? 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


Entrevistas Tipos

Estructuradas Existe una agenda

previa con temarios Libres

Agenda abierta, no hay temarios previos

Ventajas Ricas en adquisición de

información Desventajas

Muchos datos cualitativos difíciles de analizar

Difícil la comparación de respuestas

Administrar las entrevistas no es una tarea sencilla

Que mirar? Preguntas sin

respuestas Conocimiento tácito El contexto de discusión Actitud de los

entrevistados respecto de los temas abarcados


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

Que mirar? Tendencias en los ejemplos Dominancia y submisión


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

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


Casos de uso

Que es un caso de uso? 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


Casos de uso

Ventajas y desventajas 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


Usando Casos de uso

Dibujar los límites Identificar los actores

fuera de los límites del sistema que interactúan con él

Para cada factor Identificar los posibles

casos de uso Establecer escenarios

concretos para ilustrar cada caso de uso

Agrupar escenarios similares en casos de uso si son una variación sobre un tema

Para cada caso de uso Escribirlo Especificar reglas para

elección del mismo y para interacturar con él

Considerar alternativas Ver posibles superposiciones

de casos de usoTemplate de caso de uso:

Nombre:Resumen:Actores:Precondiciones:Descripciones:Excepciones:Postcondiciones:


Un ejemplo de caso de uso

Nombre: Orden de pedido Precondición: un usuario válido está conectado al sistema Descripción:

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

Excepciones: En el paso 9, si hay información incorrecta, el sistema le preguntará al cliente que quiso poner

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

Re-Adquirir producto

Tomar Estado

Enviar catálogo

Cancelar orden

Proveedor

Orden de pedido

DeliveryEnviar producto

Cliente


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

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.


Modelado de tareas y Escenarios Modelado de tareas:

Conjunto jerárquico de actividades estereotípicas

Los subojetivos son tareas (o casos posibles de uso)

Pueden ocurrir en secuencia, en paralelo o como alternativas

Pueden ocurrir periódicamente o en respuesta a contingencias.

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 Excepciones

Son variantes de casos de uso No pueden ser modeladas como

escenarios en si mismo, interactúan con múltiples escenarios


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 Evolución de metas

Refinar, elaborar y poner operativos

Ventajas Razonablemente

intuitivo La declaración explícita

de metas provee una base para la solución de conflictos

Desventajas Difícil de seguir la

evolución


Usando aproximación basadas en metas Metas

Objetivos de alto nivel de un negocio u organización

Requerimiento Especificación de cómo una meta

debe estar en un nuevo sistema Tipos

Metas de realización Metas de mantenimiento Metas soft

Obstáculos y limitaciones Los obstáculos son

comportamientos que previenen la realización de una meta dada

Las limitaciones son condiciones sobre la realización de una meta

Consejos 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.


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 KE es dura

Separar el dominio del conocimiento de la performance del conocimiento

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


Por que KE es tan difícil?? Expertos no se utilizan para

describir que hacen 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

Problemas de representación 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

Son abstracciones de la realidad Se crea través de suposiciones simples Tiende a tener menos errores o problemas


Expresividad vs. Facilidad de adquisición

Son objetivos opuestos 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


El nivel del conocimiento Ver el modelado del

conocimiento como: Observar el comportamiento de

un agente como una caja negra Actúa como si tuviera

conocimiento sobre el ambiente que utiliza

Construir dos modelos Nivel simbólico: descripciones

del mecanismo del comportamiento

Nivel de conocimiento: descripciones del conocimiento del agente del mundo real

Ambiente

mec

aniz

ado

Modelo de nivelde símbolos

Com

port

amie

nto

raci

onal

izac

ión

Modelo el nivelde conocimiento

Observación

Observador(modelador)

Agente


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 Desventajas

No tienen dimensión social Basada en introspección

Técnicas de escala de proximidad Dado un dominio, derivar un

conjunto de dimensiones para clasificarlo

Ventajas:

Ayuda a construir modelos mentales,

Pueden adquirir conocimiento tácito Desventajas

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


Abstracción vs. contextualismo

Abstracción: Construye modelos

abstrayéndolos del dominio, el modelo puede contestar preguntas

Decidir sobre la ontología del fenómeno que se quiere describir

Se asume que el conocimiento y el entendimiento son independientes del contexto

Utilizado normalmente por científicos naturales e ingenieros

Contextualismo Pone énfasis en los

detalles e idiosincrásia del dominio

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

Ontología: parte de la metafísica, que estudia el ser en general y sus propiedades trascendentales


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

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 Es construido a partir de acciones de

los participantes No se puede tomar información de

categorías preestablecidas Se necesita considerar

Como los significados se desarrollan y evolucionan en el contexto

Los métodos públicos utilizados para que el contexto tenga sentido

Etnología: ciencia que estudia el origen, la distribución y los caracteres físicos de las razas humanas


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.

Categorías: Las técnicas

convencionales suponen categorías preexistentes

La Etnografía intenta utilizar sujetos con categorías propias

Medidas No tienen objetividad

científica, por ende los sujetos deben crear su propia fuente de medición.


Observación de participantes

Bases: Los observadores

pasan un tiempo con los sujetos, tratando de convertirse en un miembro más del grupo

Ventajas Contextualización Se revelan detalles

que otros métodos no pueden cubrir

Desventajas 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


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

Actividad de modelado Combinar problemas

Empíricos: especificaciones ligadas al mundo real

Formales: abstracción, estructura y representación del conocimiento del problema

De ingeniería: métodos formales de construcción

Modelado se hace sobre los cuatros

dominios de información Empresa Uso Sistema Desarrollo

Especificación conceptual Entender un dominio

específico de información


Motivación del modelado

Suponga que se entrevistaron varios actores de un problema relacionado a una aerolínea Jefe ejecutivo

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 El número de valijas en el avión debe

corresponder al número de personas que abordan

Las listas de pasajeros son información restringida

Solo se puede hacer el check in una vez

Agente de viajes 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 Solo se puede usar un ticket pago En algunos casos puede no confirmarse la reserva Un tíckets de descuento no puede devolverse


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.?


Motivación del modelado El modelado puede ayudar a descubrir problemas

La inconsistencia de un modelo revela algo interesante puede corresponder a requerimientos conflictivos o

inflexibles puede significar confusión sobre terminologías, alcances,

etc. Puede revelar desacuerdos entre actores

La modelización ayudará a chequear nuestro entendimiento Podemos testear que el modelo tengas las propiedades

esperadas? Se puede razonar sobre el modelo entendido y sus

consecuencias? Podemos “animar” el modelo para ayudarnos a validar

requerimientos?


Tipos de modelo

Se puede elegir entre una variedad de esquemas conceptuales Lenguaje natural

Muy expresivo y flexible Pobre al intentar captar la 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


Requerimientos para el esquema conceptual

Independencia de implementación No modelar representación de

datos, organización interna, etc. Abstracción

Tomar solo aspectos principales (cosas que no cambien)

Formalidad Sintaxis no ambigua Rico en semántica

Constructibilidad Debe facilitar la comunicación

analista usuario

Fácil de analizar Para detectar ambigüedad,

inconsistencia, incompletitud Trazabilidad

Habilidad para seguir los elementos del modelo

Ejecutabilidad Poder “animar” el modelo, para

comparar con la realidad Minimalidad

No redundancia de conceptos (cada cosa expresada de una forma)


Técnicas de modelado

Modelado de empresa Metas y objetivos Estructura organizacional Actividades, procesos y productos Roles y trabajos de agentes

Modelado de requerimientos funcionales Vistas estructurales (de datos) Vistas de comportamiento Requerimientos de tiempo

Modelado de req. no funcionales De productos, de procesos y externos

Modelado de información (DER)

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)


Modelado de requerimientos de empresa Evolución en el tiempo

’70 Resolver los sistemas de soft

Involucrando toda la organización Sensitivo al contexto social y político para el cambio organizacional

Técnicas: SSM, ISAC ’80

Basdados en conocimiento Usar representación del conocimiento para construir modelos de dominio ejecutables Capturan aspectos estáticos y dinámicos del dominio

Técnicas: RML ’90

Teleológicos 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*

Teleología: doctrina de las causas finales


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

Que quiere la organización? Cuan flexible es la organización respecto a cambios?

Estudio de actividad Que actividades deben reagruparse en sistemas de información? Que prioridades tienen los sistemas de información?

Análisis de información Que entradas y salidas tienen cada SI? Qué son los requerimientos cuantitativos del SI?

Implementación Que tecnología se utilizará para el SI (hard, y soft)? Que actividades del SI serán automáticas o manuales?


Revisión de modelos: ISAC-Elementos Lista de problemas

Insatisfacción con los sistemas corrientes

Listar los problemas Remover aquellos triviales o

imposibles Lista de grupos de interés

Dibujar una matriz de problemas para contrastarla con los propietarios de los mismos

Análisis de problemas Análisis de causa efecto

Evitar soluciones orientadas a problemas

Llevados a cabo por especialistas Cuantificar el problema

Modelo de actividad corriente Esquemas A (similar a diagramas de

flujo de datos)

Análisis de metas Sentencias declarativas de metas

Resultado deseado, no como obtenerlo

Meta final árbol de metas Definir necesidades de cambio

Las metas deben explicar por qué existe el problema

Generar alternativas de cambio Modelo de situaciones deseadas

Hacer paquetes de alternativas para el cambio

Evaluar alternativas Elegir una alternativa


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

Objetivos, estructuras de tareas, planes para la organización, entendimiento del ambiente


Revision de modelos: SSM Pasos de la metodología

1. Situación base (problema no estructurado)

2. Análisis del problema“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ónModelo orientado al proceos, con actividades y flujo de recursos

5. Compara el modelo conceptual con el paso 2

Preguntas ordenads sobre el modeloReconstrucción de eventos para compararlas con el modeloComparación general para mirar rasgos del modelo diferentes de la situación actual

6. Debate sobre la factibilidad del cambio

Tres tipos de cambio: estructural, procedural y de actitud

7. Implementar los cambios


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

Modelo de dependencia estratégica (relaciones entre actores)

Modelo estratégico racional (modela intereses e incumbencias de actores)

Características El modelo de dependencia

muestra las dependencias entre actores objetivo obtener un mejor entendimiento de los por qué?

Dependencia entre metas y submetas (un actor depende de otro actor para alcanzar una meta)

Dependencia de recursos (un actor necesita un recurso de otro actor)


Revision de modelos: i*

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)

AttendsMeeting(p,m)

Iniciadordel

encuentro

participanteimportante

delencuentro

participantedel

encuentro

ExclusionDate(P)

Agreement(M,P)

ProposedDate(M)

PreferredDate(P)

AttendsMeeting(ip,m)

Assured(AttendsMeeting (ip,m)

D

D

X D

D

D

D

DD

D

D

D

D

ISA

D

D

D D Dependencia de metas

D D dependencia de recueros

D D dependencia de tareas

D D Dependencia de metassoft

O Opend (uncommited)X Criticas


Revision de modelos: i*

Modelo racional muestra interacciones entre metas dentro de cada actor

Muestra nivel más detallado del modelado mirando dentro de los actores para modelizar sus relaciones internas

Muestra la descomposición de tareas

Muestra los links entre tareas y metas

SR provee una forma de modelar actores interesados, como deben encontrarse la forma de evaluarlos

Iniciadordel

encuentro

Organizemeeting

MergeAvailDate

ObtainAgreement

ObtainAvailDate

ScheduleMeeting

Quick LowEffort

FindSuitable

Slot

- -

MeetingBeSchedule

ParticipateInMeeting

AttendMeeting

Agree ToDate

ArrengeMeeting

FindAgreable

Date

Convenient(meeting, Date) Low

EffortQuality

(proposedDAte)

UserFriendly

MinInterrupt

ion

Agreable(meeting,

Date)

Participantedel

encuentro

--

+ +

+

+

AttendsMeeting

ExclusionDates

Agreement

ProposedDate

PreferredDates

D

D D

DD

DD

D

DD

- +

Meta

contribución a meta softLink means-end

Tarea - link de descomposicón

Tarea

Meta Soft

Cecurso


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

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


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


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 Refina las metas

usando una descomposición denominada AND OR

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


Modelado y análisis

Análisis de sistemas varias escuelas 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:

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


Análisis estructurado Definición

Proveer un marco de trabajo para modelar de forma detallada el sistema como parte de la obtención y análisis de requerimientos (Sommerville)

Aproximación al modelo conceptual orientada en los datos

DFD es el elemento más representativo

Target principal de sistemas SI

Se deben entender los requerimientos necesarios para continuar en la evolución del sistema

Debilidades No provee métodos efectivos para

tratar con requerimientos no funcionales

No ayuda al usuario a decirir el mejor método para cada caso

Produce demasiada documentación Modelos muy detallados que son de

difícil comprensión por parte de los usuarios


Análisis estructurado Conceptos centrales

Transformación de datos Actividades que transforman

los datos Flujo de datos

Indica el paso de datos de la entrada del mismo hacia la salida

Representa grupos de datos o elementos de datos

Almacenamiento de datos Lugar donde se deja info para

su uso posterior Los almacenes de datos son

pasivos, no transforman los datos

Entidad externa Actividad fuera del

alcance del sistema Fuente o destino de

info en los DFD No pueden interactuar

directamente con los almacenes de datos

Grupos de datos Clustes de datos

representados como un flujo de dato simple

Elemento de dato Unidad básica de

información


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 Procesos Flujos Almacenes de datos Entidades externar

Diccionario de datos Define cada

elemento de dato Usa una notación

BNF para definir la estructura de los elementos

Constructores

Construcción Notación Significado

= Está compuesto de

Secuencia + Y Selección [ | ] O bien

Repetición { }n N repeticiones de

( ) Datos opcionales

* * Delimita comentarios


Análisis estructurado

Especificación de procesos código en lenguajes narrativo o en algún

pseudo código Define los rasgos procedurales escenciales

Evoluciones DFD evolucionó para poder representar TR


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)

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

Comparado con la ambigüedad de los DFDs


Análisis OO

Primitivas de modelado Objetos

Entidades con estados, atributos o servicios

Clases Forma de agrupar objetos Abstracciones jerárquicas con

una relación ES_UN Atributos

Representan estados del objeto Pueden especificar: tipo,

visibilidad y modificacbilidad

Relaciones 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


Análisis OO

Conceptos fudamentales Herencia

Simple o múltiple Ocultamiento de información Agregación

Puede describir relaciones entre las partes y el todo


Análisis OO

Que cosas pueden ser objetos Entidades externas

Que interactúan con el sistema a modelizar (personas, dispositivos, otros sistemas)

Cosas Que son parte del dominio que

se modeliza (reportes, señales) Ocurrencias o eventos

Que pueden ocurrir en el contexto del sistema (transferencias de recursos, acciones de control)

Roles Llevados por personas que

interactúan con el sistema Unidades organizacionales

Relevante a la aplicación (deptos, divisiones, equipos)

Lugares Que establecen el contexto

del problema Estructuras

Que definen una clase (sensores, computadoras)

Los procedimientos (imprimir, copiar) y los atributos no son objetos


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

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.


Análisis OO

Variantes para el AOO Coad- Yourdon

Década del ´80 Cinco pasos de modelado

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


Análisis OO

NombreFecha de nacAlturaPeso

Paciente

Service

Cama Habitación

Ingresopaciente

Service

medico última visita

Alta paciente

Objeto

todo parte

Mandatario

Servicio

Clasificación

AtributosNombreFecha de nacAlturaPeso

Paciente

1,m

1

Service

Attribute

Class

Service

Attribute

Class

1,m

1

Service

Attribute

Class

1,m

1


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

Producir un modelo de tiempo y control a nivel del sistema

Desarrollar modelo de procesos

Para cada acción un diagrama de acción y flujo de datos

Definir dominios y subsistemas

Descomponer en partes


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

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.


Análisis OO

Evaluación de AOO 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


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

Permitirnos razonar sobre los requerimientos

Chequear propiedades automáticamente

Testear consistencia, explorar consecuencias

Permitirnos animar y ejecutar los requerimientos

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


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

Normalmente modelizamos inconsistencias, incompletitudes y cosa incorrectas

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....



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

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 fórmula está en el lenguaje



Análisis formal clases Análisis de consistencia y chequeo de tipos Validación Predecir comportamiento Verificar refinamiento de diseño



Ventajas prácticas de los métodos formales se encuentra más errores 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


Métodos formales en IR En que difieren los

métodos formales Ontología

Puede ser fija o extensible

Base matemática Lógica (predicado de

primer orden) Otra (lenguajes

algebraicos o teoría de conjuntos Z)

Tratamiento del tiempo Modelos estado-evento Tiempo como una objeto

primario

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.



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 de sistemas reactivos Formalizan modelos dinámicos

de comportamiento de sistemas

Basados en sistemas reactivos (TR)

Chequeo de consistencias, chequeos de modelo

Ej: RSML, SCR Modelado formal conceptual

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


Comunicando requerimientos SRS (soft req. Specification)

El problema es como comunicar los requerimientos al resto de los interesados El SRS hace esto Veremos

como construirlo, los problema que

pueden surgir, Estándares de

construcción

SRS Propósito

Comunicar los requerimientos de forma clara

Se explica el dominio de la aplicación y del sistema que se va a desarrollar

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


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 Analistas de sistemas

Escriben especificaciones que interactúan

Desarrolladores y programadores

Tienen que implementar los requerimientos

Testers Determinan que

requerimientos han sido alcanzados

Administradores de proyectos

Miden y controlan el proceso de análisis y desarrollo del sistema


SRS (soft req. Specification)

Quién lo escribe El proveedor

Debe ser general para tener una buena selección de pedidos

Debe dejar de lado los pedidos no razonables El oferente

Debe ser específico para demostrar credibilidad y competencia técnica

General para evitar sobre compromiso El desarrollador seleccionado

Refleja el entendimiento del desarrollador Base del desarrollo


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 laEspecificació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 recur-sos necesarios y plan de desarrollo.

lectores 1 autor de especificación2 cliente

1 programadores, equipo V&V, adminis2 clientes


Como hacer una especificación

Aspectos Validez (correctitud)

Expresar los req. Actuales Completitud

Especificar todo lo que el sistema necesita y debe hacer

Responder a todas las entradas posibles

Completitud estructural Consistencia

No contradecirse Usar términos de manera

consistente

Necesario No contener cosas que no se requieren

No ambiguo Cada sentencia se lee de una sola forma Definir términos confusos en un glosario

Verificable Test de satisfacción por cada cliente

debe existir Cada req. Es especificado con

comportamiento Entendible (claro)

Por especialistas no informáticos Modificable

Debe mantenerse actualizado


Las especificaciones problemas

Que puede suceder Redundantes Ambiguas No entendibles Inconsistentes incompletas

ambiguas

incompletas

redundantes

noentendibles

inconsistentes

condensadas

reducen Resuelven

expanden

formalizan

agregaexplicación

expandidas


Errores típicos de especificación Ruido

Tener texto poco relevante como contenido

Silencio Rasgo importante no cubierto en el

texto Sobre especificación

Texto que describe una solución más que un problema

Contradicción Texto que define un rasgo de varias

formas incompatibles entre ellas Ambigüedad

Texto que se interpreta de dos o más formas diferentes

Referencia hacia delante Utilizar un concepto aún no definido

Pensamiento deseado Texto que define un rasgo que no

puede ser validado Puzzles

Desparramar requerimientos por todos lados y luego poner referencias cruzadas

Requerimientos mal definidos No conforme a estándares

Terminología inventada o inconsistente

Escribir de manera hostil para el lector


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

Calidad, V&V, QA, test Diseño

Requerimientos y diseños pensados para gente diferente

Análisis y diseño son áreas diferentes


Calidad de especificación Análisis de texto

Se pueden hacer análisis textuales del SRS Medir la forma de construcción Establecer normas para organismo

Ej; NASA usa nueve indicadores Imperativo

Identifica palabras como “debe”, “es requerido”, etc. Se mide cuan explícito es el SCR

Opción 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.

Continuidad de los requerimientos imperativos Palabras como “sigue abajo”, “como sigue”, etc. Mide la estructura del SRS

Palabras débiles Causan incertidumbre Ej. Adecuado, aplicable

Directivas Indicación a tablas, figuras Mide calidad del documento

Tamaño Líneas de texto, párrafos, hojas

Estructura del texto Mide el número de identificadores de sentencias

Especificación de profundidad Mide profundidad de subsecciones Marca la estructura del SRS


Ej. De texto ambiguo

El sistema deberá reportar al operador todas las fallas que se originen en funciones 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 FOcurren durante secuencias críticas V V F F V V F FNo hay planes de recuperación V V V V F F F FSe avisa al operador?


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 Conjunto restringido del

idioma

Notación semiformal (tablas, gráficos)

Lenguajes de especificación formales

Explorar por redundancia 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.


Características de un SRS

Modificabilidad Bien estructurado, indexado, con referencias cruzadas Sin redundancia No es modificable si no es trazable

Trazabilidad Cada requerimiento se puede rastrear hasta su fuente Cada requerimiento se puede rastrear hasta su

implementación Notación útil

Que lo haga fácilmente comprensible


Estándar IEEE para SRS IEEE introduce un estándar de

5 pasos: Revisión

Describe aproximaciones recomendadas para la especificación de requerimientos.

Referencias A otros modelos IEEE

Definiciones Conceptos básicos para la

práctica del modelo Consideraciones para producir

un buen SRS Secuencia de 8 pasos para

lograr ese fín

Partes de un SRC 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


Trazabilidad de requerimientos

Definición 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



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

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



Mantenimiento Evaluar los pedido de

cambio Trazar un diseño

racional (lógico) Acceso a documentos

Habilidad de encontrar información rápidamente en grandes documentos

Visibilidad de proceso Habilidad para ver

como el soft se desarrolla

Proveer posibilidad de audición

Administración De cambio De riesgo De control sobre el

proceso de desarrollo Dificultades

Costo Muy poco soporte

automatizado Completa trazabilidad

es muy cara y consumista de tiempo



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

Test, integración, mantenimiento

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.


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

Seguir los links Encontrar links perdidos Medir la trazabilidad total


Herramientas para trazabilidad Cuales?

Hipertexto (links) Palabras clave que

identifican conceptos asociados a ella

Identificadores únicos Cada requerimiento tiene un

ID único con una BD de referencias cruzadas

Coeficientes de similaridad sintáctica

Busca la ocurrencias de patrones de palabras

Limitaciones Todas requieren un gran

esfuerzo manual para definir los links

Todas tienen información puramente sintáctica, sin contexto semántico

Ej Herramientas de BD (RTM,

SLATE, DOORS) Herramientas de hipertexto

(document director, netscape navigator)

Herramientas de desarrollo general


Herramientas para trazabilidad Limitaciones de herramientas

Problemas de información Fallan en rastrear

información de trazabilidad por ej. No pueden decir quien

es el responsable de determinado dato

Mala trazabilidad de pre-requerimientos

Desde donde vienen los requerimientos?

Falta de convenio Sobre la cantidad y tipo de

información trazada

Comunicación informal 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


Trazabildiad Cuestiones problemáticas Cuales son?

Intervención Quién estuvo

involucrado en la confección de los requerimientos?

Responsabilidad Quien es responsable

por este req? Quién es el

responsable actual? En que punto de ciclo

de vida el responsable cambia?

Cambio En que punto del ciclo

de vida se produce un cambio o evolución de req?

Notificación Quien necesita ser

avisado por cambios en los req?

Pérdida de conocimiento Cuales son las

ramificaciones asociadas a la pérdida de conocimiento?


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 Como reconciliar conflictos

entre metas en un contexto social complejo

Validar requerimientos Inspecciones y revisiones prototipeo

Negociación sobre requerimientos

Conflictos y su resolución

Técnicas para negociar requerimientos

Aproximaciones para argumentar

Aproximaciones basadas en conocimiento

Priorización de requerimientos


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

Construir un modelo consistente (validarlo con observaciones empíricas)

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)

Las teorías puede no proveer cosas correctas, se puede refutar encontrando excepciones

Las teorías son científicas si pueden ser refutadas


El problema de validar En IR, diseñar modelos

de req para ser refutables

Ver por evidencia que muestre que el modelo es erróneo

Aproximación post modernista

No hay punto de vista privilegiado, todas las valoraciones son iguales

En IR, la validación siempre es subjetiva y contextualizada

Usar actores para que construyan sus propios modelos de requerimientos

Usar técnicas etnográficas para entender el problema.


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 Usados para proveer

certeza sobre el diseño

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.


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

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.

Efectos sobre competencia del staff

Incrementa la moral Mejor estimación y

planificación Mejor administración de

las habilidades del staff Estos beneficios son útiles

para IR!!!!


Limitaciones de la inspección Tamaño

Suficiente gente de manera que todos los expertos estén disponibles

Mínimo 3 máximo 7 personas Duración

Nunca más de 2 horas (se pierde objetividad y concentración)

Salidas Todos los revisores deben de

estar de acuerdo con los resultados

Todos los ítem evaluados deben estar documentados

Reporte que resuma el trabajo

Lista detallada de aspectos relevantes

Alcance Tomar pequeñas partes,

nunca el todo Timing

Examinar el producto cuando el autor termina con él.


Limitaciones de la inspección

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

Propósito Obtener datos que ayuden a no cometer el error en

el futuro


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 Evitar comentarios

profesionales o destructivos

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


Elección de los revisores

Posibilidades 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: 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


Estructuración de la inspección

Se puede hacer la estructura de la revisión de varias formas: Ad hoc:

Confiar en el experto en revisión

Lista de chequeos Usar una lista de

preguntas o casos a revisar

A lista se hace a medida del documento evaluado

Revisiones activas (escenarios)

Cada revisor lee con un propósito específico, usando cuestionarios especializados

Diferentes revisores toman diferentes perspectivas

Diferencias Los escenarios encuentran

mayores fallos que los otros métodos

No hay una diferencia marcada entre los dos primeros


Prototipación

Definición 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

Respecto de definición Primera prototipo descartable Segunda prototipo evolucionable


Características de prototipos

Explicativo Explica, demuestra e informa, luego se avanza

Exploratorio Determina el problema, evalúa necesidades, clarifica

metas, examina alternativas y evalúa ideas, es informal, no es estructurado

Experimental Evalúa propuestas y el comportamiento del modelo

Evolucionario Elige y refina soluciones, se usa como producto


Clases de prototipos

Dos clases Descartables Evolucionables Tercer opción: operacionales

Descartables Propósito

Aprender más sobre el problema o su solución

Obtener conocimiento Uso

Etapas tempranas o posteriores

Aproximación Rápida y sucia

Ventajas 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 Desventajas

Derrochar esfuerzo si los requerimientos cambian rápidamente

Generalmente el prototipo reemplaza documentos


Clases de prototipos Evolucionables

Propósito Aprender más sobre el

problema o su solución Reducir el riesgo de

construir partes del sistema en forma temprana

Uso Incremental, evolucionable

Aproximación Vertical: necesita desarrollo

riguroso e incremental

Ventajas Los requerimientos no

están congelados Solo se retorna al

incremento anterior si se encuentra un error

Flexible ? Desventajas

Está en la otra punta de los métodos estructurados

No se garantizan las soluciones más efectivas

Poco control y dirección


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

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


Acordando requerimientos

Aspectos Negociación y resolución de conflictos

Entre requerimientos encontrados Priorización de requerimientos

Definición de conflicto 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.


Acordando requerimientos

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


Modelo de resolución

Aproximación usada para dirimir el conflicto Los métodos incluyen

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 Cooperativo

involucra negociación Competición

involucra combate, coerción y competición

Resolución por terceras partes arbitraje y apelar a una autoridad



Negociació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

Competición 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



Terceras Partes Se busca un árbitro

para que decida Tipos

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 Licitar

Los participantes establecen sus términos deseados

Negociar Los participantes

buscan por la integración satisfactoria de sus pedidos.


Conflictos en sicología 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, 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)


Experiencias resultados

Algunos aspectos observados

(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

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


Severidad sobre el conflicto

Satisfacción de otras partes

Satisfacción de otras partesSatisfacción de otras partes

Satisfacción de otras partes

Nue

stra

sat

isfa

cció

n

Nue

stra

sat

isfa

cció

n

Nue

stra

sat

isfa

cció

n

Nue

stra

sat

isfa

cció

n

A

A

A

A

B

B B

B

A y Bcombinados

A y Bcombinados

A y Bcombinados

nointerfirientes

inclusivos

interfirientes

mutualmenteexclusivos

Para dos posicionesiniciales A y B, se

puede medir laseveridad del

conflicto examinandoque sucede cuando

se combinan


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

familiaGrupos 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


Teoría del juego

Teoría del juego en la resolución de conflictos Dados

Dos o más jugadores Utilidades conocidas

para cada uno de los jugadores

Puede calcular Cual estrategia

resulta en el mejor resultado

Como interactúan las estrategias de los jugadores

Ej: dilema del prisionero

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

un año a cadauno

8 años parauno

tres mesespara A y 10años para B

10 años para Ay 3 meses

para B

No Confiesa

No Confiesa

Confiesa

Confiesa

Prisionero B

Prisionero A


Argumentación

gIBIS Desarrollado en 1989 Representa el proceso

de argumentación como un grafo hipertextual

Proceso básico Identificar usos Identificar posiciones

que se pueden adoptar con respecto a las posiciones

Linkear argumentos que soporte o refuten posiciones

Uso 1

Uso 4Uso 3

Uso 2

Posición 1

Posición 2

Argumento 1

Argumento 5

Argumento 4

Argumento 3

Argumento 2

preguntases sugerido porobjeto de

objeto de

preguntas

soporte

objeto de

responde a

responde a

generaliza


Argumentación

Sinóptico 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


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

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


Evolución de Req. guías

El soft evoluciona porque los requerimientos evolucionan Leyes de la evolución

del soft Administración

tradicional del cambio Guías Administración de

configuración

Familias de software Líneas de productos

Puntos de vista 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


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 Un cambio en la

especificación define un problema nuevo, entonces hay un programa nuevo

Sentenciasformales del

problema

Programa

Solución

MundoReal


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

Porque la solución nunca es perfecta, y puede ser mejorada

Porque el mundo real cambia y entonces el problema cambia ProgramaSolución

MundoReal

Compara Cambia

Cambia

Vista abstractadel mundo real

Especificaciónde

requeriminetos


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í Modelo

Mundo Real

Cambia

Vista abstractadel mundo real

Especificaciónde

requeriminetos

Programa


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

El cambio continúa hasta que se crea que es mejor tirarlo y hacerlo de nuevo

Incremento de complejidad A medida que el soft

evoluciona, la complejidad se incrementa

Ley fundamental La evolución del soft es regulada

con tendencias y variantes estadísticas

Conservación de la estabilidad Organizacional 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


Crecimiento en requerimientos Modelo de Davis

El usuario necesita evolucionar continuamente 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

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


Mantenimiento del software Filosofía de mantenimiento

Alguien más es el responsable del mantenimiento

Se pierden Inversiones en conocimiento y experiencia

El mantenimiento se convierte en un desafio de la Ing. Reversa

El equipo de desarrollo hará un compromiso a largo plazo para mantener el soft

Proceso de mantenimiento de Basili Modelo fijo rápido

Los cambio hechos a nivel de código, tan fácil como se pueda Rápidamente degrada la estructura del soft

Modelo iterativo Cambios hechos en base al análisis 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


Adm. Tradicional de mantenimiento

Los administradores necesitan responder el requerimiento de cambio Agregar nuevos requerimientos durante el

desarrollo Modificar requerimientos durante el desarrollo

Porque el desarrollo es parte del proceso de aprendizaje

Remover requerimientos durante el desarrollo Quizá por problemas de costos


Adm. Tradicional de mantenimiento Elementos de la 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

Líneas base Versión estable del

documento que puede ser compartida por el equipo

Proceso de aprobación formal para incorporación de cambios

Proceso de administración de cambio

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


“singularidad de productos”

La mayoría de las técnicas de IR se enfocan a modelos individuales Pasos

Construir un modelo Hacerlo consistente y

completo Validarlo

Se asume que al IR es un proceso con una salida simple

La salida es una especificación completa, consistente y válida

Lo anterior ignora la realidad La IR no termina en la

especificación 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


“singularidad de productos”

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


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!!

Librerías de componentes reusables Específicas de dominio (librerías

del Math)

Desarrollo de programas (Java, C)

Ingeniería de dominio Divide el desarrollo del soft en

dos partes Análisis del

dominio(identifica componentes reusables del dominio del problema

Desarrollo de aplicación (usa componentes de dominio para especificar aplicaciones)


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 Representa una decisión estrategia de

negocio sobre que soft desarrollar


Puntos de Vista Motivación

Múltiples perspectivas Muchos actores

diferentes Diversas clases de

conocimiento del dominio

Vistas conflictivas (y negociación)

Muchos esquemas de representación

Modelado distribuido Analistas y actores

colaborando Métodos múltiples de

modelado Evolución continua de

requerimientos Links de

comunicación imperfectos


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

Se transforman en cuellos de botella para el proceso de modelado distribuido

La coerción previene la divergencia de ideas

Inconsistencias se dan en situaciones de incertidumbre

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


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

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


Marco de trabajo básico

Los PV contienen reglas de consistencia 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


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

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

Estructuración del proceso de desarrollo 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


Ventajas de los PV

Estructuración de descripciones 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


PV hacia adonde??? Método de ingeniería

Método de diseño definir un conjunto de templates coherentes

PV como una herramienta Meta CASE

Proceso de modelado Un proceso de modelado

de grano fino en cada PV Administración de

consistencia Como presentar reglas de

consistencia inter PV?

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?

Trazabilidad de requerimientos Los PV asociados a actores con

sus contribuciones


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

Definición de inconsistencia 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


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

Las inconsistencias pueden solamente ser detectadas automáticamente si las relaciones están definidas formalmente


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

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

Los factores de riesgo cambian, el riesgo debe reevaluarse continuamente


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:

Porque generalmente es vista como algo malo Porque siempre se puede cuestionar la

formalización


Conviviendo con inconsistencia La detección es vital

Convivir con inconsistencia es seguro si se tiene conocimiento de su existencia

Manejo de inconsistencia Evadirla

Remover / reemplazar elementos inconsistentes, o remover / reemplazar reglas que fueron rotas

Ignorarla Si puede ser aislada y no es

importante

Demorarla: Si se necesita información

que no está disponible por el momento

Mejorarla Tomar acciones que afinen

la situación pero que no resuelvan la inconsistencia

Resolverla: Negociar una solución o

encontrar un compromiso La inconsistencia indica,

normalmente, que se necesita más información


Modelo de proceso de inconsistencia

Localizar

mejorarla

Evadirla

Diferir

Resolver

Tolerar

Ignorar

Clasificar

IdentificarCaracterización

deInconsistencia

mon

itor p

ara

inco

nsis

tenc

ia

cons

ecue

ncas

de

mon

itore

os d

e ac

cion

es

Analizando impacto y riesgoMidiendoInconsistencias

Inconsistencia

Detectada

Inconsis-tencia

Manipu-lada

reglas deconsistencia


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

Cada PV tiene su propio conjunto de reglas

No se necesita control central Cuando debería chequearse las

relaciones entre PV? 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


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

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


Ejercicios y trabajos 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

Documents