Ingeniería de Software Clase 3

Ingeniería de Software Clase 3
Ingeniería de Requerimientos (Toma, modelado, comunicación, aceptación y mantenimiento)

Ingeniería de Software - Clase 3
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 Ingeniería de Software - Clase 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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Los cuatro mundos UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Usando Casos de uso Para cada caso 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 uso Template de caso de uso: Nombre: Resumen: Actores: Precondiciones: Descripciones: Excepciones: Postcondiciones: UNPSJB Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Modelado de tareas y Escenarios
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 Ingeniería de Software - Clase 3

Aproximación basada en metas
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 Ingeniería de Software - Clase 3

Usando aproximación basadas en 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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 Las entidades necesitan ser identificadas dentro de semánticas a lo largo del dominio UNPSJB Ingeniería de Software - Clase 3

Abstracción vs. contextualismo
Ontología: parte de la metafísica, que estudia el ser en general y sus propiedades trascendentales 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 UNPSJB Ingeniería de Software - Clase 3

Visión etnometodológica
Etnología: ciencia que estudia el origen, la distribución y los caracteres físicos de las razas humanas Visión etnometodológica 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 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 UNPSJB Ingeniería de Software - Clase 3

Etnometodología 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. Bases: El mundo social es ordenado El orden social puede no ser obvio y no descriptible desde el sentido común El orden social no puede asumirse con estructura previa Se enfatiza la importancia de las bases naturales. UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Por que modelar? 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 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 UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Técnicas de modelado Modelado de información (DER) Modelado de organización (i*, SSM, ISAC) Modelado de metas: (KAOS) 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 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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Revision de modelos: SSM
Pasos de la metodología Situación base (problema no estructurado) Análisis del problema “dibujo” del mismo “temas” que abarca el problema Definir aspectos relevantes del sistema y su raíz Descripción de la actividad humana Construir el modelo conceptual Actividades del sistema necesarias para llevar a cabo la transformación Modelo orientado al proceos, con actividades y flujo de recursos Compara el modelo conceptual con el paso 2 Preguntas ordenads sobre el modelo Reconstrucción de eventos para compararlas con el modelo Comparación general para mirar rasgos del modelo diferentes de la situación actual Debate sobre la factibilidad del cambio Tres tipos de cambio: estructural, procedural y de actitud Implementar los cambios UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Dependencias de tareas (un actor necesita otro actor para llevar a cabo la tarea) EJ: supongamos una agenda para la concurrencia a una cita particular (ver como evoluciona en el paper correspondiente) UNPSJB Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Análisis OO UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Como hacer una especificación
Considerar dos proyectos Uno pequeño, 1 pgm, 6 meses (A) El programador charla con el cliente y escribe hasta 5 páginas de requerimientos Gran proyecto, 50 programadores, 2 años (B) Equipo de analistas modelan requerimientos, SRS 500 páginas. Proyecto A Proyecto (B) Propósito de la Especificación Representa el entendimiento del programador, vuelve al cliente Construye un documento, debe contener mucho detalle para todos los pgmdor Vista de administración La especificación es irrelevante, se tiene alocados los recursos Se debe usar la espec. para estimar recur-sos necesarios y plan de desarrollo. lectores 1 autor de especificación 2 cliente 1 programadores, equipo V&V, adminis 2  clientes UNPSJB Ingeniería de Software - Clase 3

Como hacer una especificación
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 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 UNPSJB Ingeniería de Software - Clase 3

Las especificaciones  problemas
Que puede suceder Redundantes Ambiguas No entendibles Inconsistentes incompletas UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ocurren durante secuencias críticas No hay planes de recuperación Se avisa al operador? UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Clases de prototipos Dos clases Descartables Evolucionables Tercer opción: operacionales 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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Severidad sobre el conflicto
UNPSJB Ingeniería de Software - Clase 3

Clasificación de conflictos sociales
Unidades sociales Igual vs igual Jefe vs. Subordinado Todo vs. parte Roles Rol de familia vs. Rol ocupacional Rol ocupacional vs. Rol de unidad Personalidad social vs. Rol de familia Grupos Chicos y chicas en una clase escolar Padre vs hijos Familia núcleo vs familia ampliada Sectores Fuerza aérea vs ejército Administración vs unión Departamento vs facultad Sociedades Protestantes vs católicos Hombres libres vs esclavos Estado vs mafias Relaciones supra sociedades Bloque soviético vs primer mundo URSS vs Hungria CEE vs Reino unido UNPSJB Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

Tipos de programas Programas empotrados Un sistema que es parte del mundo al que modeliza Aceptación: depende enteramente de una opinión o un juez Es inherentemente evolcionario Los cambios en el soft y el el mundo real se afectan entre sí UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Hacer el dibujo de transparencia 6 y de la 7 UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

“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 Ingeniería de Software - Clase 3

“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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

Modelo de proceso de inconsistencia
UNPSJB Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 Ingeniería de Software - Clase 3

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 UNPSJB Ingeniería de Software - Clase 3

Ingeniería de Software Clase 3

Presentaciones similares

Presentación del tema: "Ingeniería de Software Clase 3"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Software Clase 3

Presentaciones similares

Presentación del tema: "Ingeniería de Software Clase 3"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback