Download - 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
UNPSJB - 2005 Ingeniería de Software - Clase 3 3
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 4
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 5
Contenido Clase 3
Bibliografía utilizada Ingeniería de Requerimientos
(Locoupulous) Ingeniría de Requerimientos (Davis) Ingeniería de software (Pressman,
Sommerville) Papers Varios
UNPSJB - 2005 Ingeniería de Software - Clase 3 6
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 7
Toma de Requerimientos Cual problema necesita ser resuelto? (identificar límites) Donde está el problema? (el contexto o el dominio del
mismo) A Quienes involucra el problema? (identificar los
actores) Por qué necesita resolverse? (identificar las metas de
los actores) Como debería ayudar el soft? (tomar o colectar los
escenarios posibles) Para cuando debe estar resuelto? (identificar
limitaciones de desarrollo) Qué debemos tener en cuenta para resolverlo?
(identificar riesgos). Adquirir suficiente conocimiento Convertirse en un experto del dominio del problema
La técnica de las 6 W:
What?Where?Who?Why?
When?How (Which)?
UNPSJB - 2005 Ingeniería de Software - Clase 3 8
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 9
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 10
Dificultades para la adquisición
Problemas en la comunicación La gente puede estar imposibilitada para
decir lo que realmente necesita Problemas políticos o de seguridad
La gente puede no querer decir que es lo que necesita
Si digo algo luego quedo “pegado” “Si abro mi negocio y otro se entera pierdo”
UNPSJB - 2005 Ingeniería de Software - Clase 3 11
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 12
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 13
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 14
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 15
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 16
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 17
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 18
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 19
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:
UNPSJB - 2005 Ingeniería de Software - Clase 3 20
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 21
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 22
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 23
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 24
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 25
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 26
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 27
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 28
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 29
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 30
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 31
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 32
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 33
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 34
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 35
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 36
Motivación del modelado
Como se obtiene de la transparencia anterior una especificación acorde?
El modelado puede guiar la toma de requerimientos El proceso de modelado puede ayudar a imaginarnos que
hacer? Puede ayudarnos a investigar sobre requerimientos
ocultos? Ej: hice bien las preguntas?
El modelado puede ser una medida del progreso La completitud del modelo implica la completitud de la
toma de req.?
UNPSJB - 2005 Ingeniería de Software - Clase 3 37
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?
UNPSJB - 2005 Ingeniería de Software - Clase 3 38
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 39
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)
UNPSJB - 2005 Ingeniería de Software - Clase 3 40
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)
UNPSJB - 2005 Ingeniería de Software - Clase 3 41
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 42
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?
UNPSJB - 2005 Ingeniería de Software - Clase 3 43
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 44
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 45
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 46
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)
UNPSJB - 2005 Ingeniería de Software - Clase 3 47
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 48
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 49
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 50
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 51
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 52
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 53
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 54
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 55
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 56
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 57
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 58
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 59
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 60
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 61
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 62
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 63
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 64
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 65
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 66
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 67
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 68
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....
UNPSJB - 2005 Ingeniería de Software - Clase 3 69
Métodos formales en IR
Que son los métodos formales? Vista amplia
Aplicación de matemática discreta a la IS Involucra modelado y análisis Con notación precisa matemática-like
Vista estrecha Uso de lenguajes formales
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 70
Métodos formales en IR
Análisis formal clases Análisis de consistencia y chequeo de tipos Validación Predecir comportamiento Verificar refinamiento de diseño
UNPSJB - 2005 Ingeniería de Software - Clase 3 71
Métodos formales en IR
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 72
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 73
Métodos formales en IR
Tres tradiciones de lenguajes Lenguajes formales de
especificación Grueso del trabajo en
verificación de programas Chequeo de tipos, prueba de
teoremas Ej: Z, VDM
Modelado 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
UNPSJB - 2005 Ingeniería de Software - Clase 3 74
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 75
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 76
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 77
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 78
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 79
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 80
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 81
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 82
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 83
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?
UNPSJB - 2005 Ingeniería de Software - Clase 3 84
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 85
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 86
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 87
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 88
Trazabilidad de requerimientos
Resumiendo Es una demostración de
completitud, necesidad y consistencia
Una camino claro de alocación y seguimiento de flujo a través del documento
Una derivación a través de una jerarquía
Importancia Para la verificación y validación
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 89
Trazabilidad de requerimientos
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 90
Trazabilidad de requerimientos
Gratificación demorada La gente que define los
links de trazabilidad no son gente que se beneficie con ellos
Desarrollo vs V&V Mucho del beneficio se
observa tarde en el ciclo de vida
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 91
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 92
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 93
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 94
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?
UNPSJB - 2005 Ingeniería de Software - Clase 3 95
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 96
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 97
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 98
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 99
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!!!!
UNPSJB - 2005 Ingeniería de Software - Clase 3 100
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 101
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 102
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 103
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 104
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 105
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 106
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 107
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 108
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 109
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 110
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 111
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 112
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 113
Modelo de resolución
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 114
Modelo de resolución
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.
UNPSJB - 2005 Ingeniería de Software - Clase 3 115
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)
UNPSJB - 2005 Ingeniería de Software - Clase 3 116
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 117
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 118
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 119
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 120
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 121
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 122
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 123
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 124
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 125
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 126
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 127
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 128
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 129
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 130
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 Ingeniería de Software - Clase 3 131
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 132
“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
UNPSJB - 2005 Ingeniería de Software - Clase 3 133
“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
UNPSJB - 2005 Ingeniería de Software - Clase 3 134
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)
UNPSJB - 2005 Ingeniería de Software - Clase 3 135
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 136
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 137
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 138
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 139
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 140
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 141
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 142
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 143
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 144
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 145
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 146
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 147
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 148
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 149
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 150
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
UNPSJB - 2005 Ingeniería de Software - Clase 3 151
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.