Capitulo 5 Evaluación de Arquitecturas de Software



Descargar 40,46 Kb.
Fecha de conversión08.06.2017
Tamaño40,46 Kb.

Capitulo 5 Evaluación de Arquitecturas de Software

Contenido

  • Introducción
  • Tipos de evaluación
    • Cualitativa
    • Cuantitativa
  • Expedientes de escenarios
  • Métodos de evaluación
    • Basada en escenarios
    • Simulación
    • Modelo matemático
    • Basado en experiencia

Introducción

  • La idea principal de la metodología en estudio es que los atributos de calidad de un sistema puedan ser evaluados explícitamente durante el diseño arquitectónico.
  • Tradicionalmente se implementa el sistema y después se evalúa. El problema es que no existe un sistema implementado para ser evaluado.
  • Se propone evaluar el diseño y cuando cumpla con los requisitos establecidos implementarlo.

Introducción

  • Como puede medirse una especificación abstracta??
  • La meta de este capitulo es:
  • Evaluar el potencial de la arquitectura diseñada para alcanzar los niveles requeridos en los atributos de calidad.
  • Ejemplo
    • Rendimiento – NO usar Blackboard
    • Flexibilidad – Usar Blackboard

Introducción

  • La evaluación de una arquitectura tiene como meta:
  • La evaluación puede ser absoluta o relativa
  • Evaluación de
  • Arquitectura
  • Orientado a la
  • Arquitectura
  • Enfoque en
  • atributos de calidad
  • Clientes
  • Expertos
  • Cualitativo
  • (comparación)
  • Cuantitativo
  • (predicción)

Tipos de Evaluación

  • Evaluación cualitativa
  • Evaluación cuantitativa
  • Evaluación de valores máximos-mínimos

Evaluación Cualitativa

  • Las técnicas de evaluación cualitativas descansan sobre el conocimiento que los arquitectos han acumulado con la experiencia en la solución de ciertos tipos de problemas.
    • Evaluación por pares
    • Patrones
    • Conocimiento estadístico, etc.
  • Este conocimiento es inexplícito y generalmente no esta documentado en las organizaciones

Formas de evaluación cualitativa

  • Asignar diseñadores experimentados al proyecto.
  • Ingeniería de conocimiento.
    • Capturar en documentos el conocimiento de los ingenieros
  • Inteligencia artificial.
    • El conocimiento cualitativo se captura para construir herramientas inteligentes que asistan al personal menos experimentado

Evaluación Cualitativa

  • Ejemplo: Comparar dos arquitecturas relativamente a un atributo de calidad establecido.
  • Desventaja: La respuesta de la evaluación es boolena: A1 es mejor que A2 o viceversa.
  • La comparación podría ser relativa a mas de un atributo de calidad. Pero que pasa si las respuestas son contradictorias?

Evaluación Cuantitativa

  • Las técnicas de evaluación cuantitativa miden las propiedades de un sistema; es difícil usarlas durante el proceso de desarrollo debido a que la información del proyecto es incompleta
  • Ejemplo: Se requiere evaluar el rendimiento (transacciones/segundo) de un sistema o el tiempo promedio de respuesta (segundos/transacciones) o estimar el costo de mantenimiento por año.
    • Si podemos generar estimaciones verídicas entonces podemos tomar mejores decisiones seleccionando la mejor arquitectura.

Evaluación Cuantitativa

  • Las estimaciones mejoraran al mismo tiempo que el sistema se diseña
  • Estas mejoraran considerablemente cuando el sistema se implemente
  • NOTA IMPORTANTE: una estimación debe consistir de un valor estimado acompañado por un estimado de su beneficio

Evaluación de un valor máximo (mínimo) teórico de un atributo de calidad

  • En la fase de diseño de la arquitectura no hay forma de determinar los valores máximos (rendimiento) o mínimos (tiempo de repuesta) teóricos que el sistema podrá alcanzar.
  • Se debe monitorear el sistema en su desarrollo para modificar la arquitectura o renegociar los valores de los atributos de calidad.

Tipos de Evaluación

  • La evaluación cuantitativa es mas costosa que la cualitativa.
  • La evaluación cuantitativa no es exacta. (predice)
  • La evaluación cualitativa tiende a ser mas usada. (costo-beneficio)

Expedientes de Escenarios

  • Problema: Generalmente los requisitos de calidad se omiten o se especifican pobremente en los requerimientos de los clientes.
    • Las interfaces deben ser fáciles de usar.
    • El sistema debe ser capaz de soportar una carga alta de trabajo.
  • Para evaluar la arquitectura cuantitativamente con respecto a sus atributos de calidad, estos deben ser especificados explícitamente.

Expedientes

  • Posiblemente los usuarios/clientes no saben/pueden especificar los atributos de calidad explícitamente (e.g. Confiabilidad = 0.9999) pero usando su imaginación, describen de manera general el funcionamiento del sistema.
  • Esto nos da un conjunto de escenarios para un atributo de calidad en particular, los cuales constituyen un expediente.
  • A cada escenario de un expediente se le asigna una importancia relativa.

Tipos de Expedientes

  • Expedientes de Cambios (Mantenimiento)
  • Expedientes de Uso (Eficiencia/Rendimiento, Confiabilidad)
  • Expedientes de Peligro (Seguridad)

Expedientes

  • Este método expande la idea de desarrollar casos de uso para especificar el comportamiento esperado del sistema.
  • Los casos de uso serán usados para caracterizar el rendimiento del sistema, e.g. Cual es el tiempo de respuesta esperado para un escenario específico?

Expedientes

  • El problema es que muchos escenarios caen fuera de los casos de uso normales.
  • Ejemplo: Situaciones de peligro para especificar requerimientos de seguridad o escenarios de cambios a futuro para especificar requerimientos de mantenibilidad.

Expedientes de Escenarios

  • Expediente completo vs Selección de escenarios
  • HW
  • OS
  • GUI
  • App
  • ...
  • ...
  • HW
  • OS
  • GUI
  • App
  • ...

Expedientes Completos o Selección

  • Un expediente completo es aquel que contiene todos los escenarios concernientes a un atributo de calidad.
    • A menos que el sistema sea demasiado pequeño, el número de escenarios será demasiado grande como para ser desarrollado completamente.
    • Ejemplo: En un expediente de mantenimiento, como se podrían anticipar todos los escenarios de cambios futuros?

Expedientes Completos o Selección

  • Si se decide usar un conjunto de escenarios seleccionados, entonces habrá otros problemas:
    • Para que el conjunto sea representativo, los escenarios deben seleccionarse aleatoriamente del conjunto completo. (experimentos en investigación)
    • Debemos confiar en que el arquitecto tiene la experiencia para seleccionar los escenarios que formaran parte del expediente y que reflejen al expediente completo. (Esto puede realizarse usando algunas técnicas grupales e.g. FMEA).
  • FMEA Failure Modes and Effects Analysis

Definiendo Expedientes

Definiendo Expedientes Bottom-up

  • Entrevistar a los clientes
  • Categorizar los escenarios
  • Asignar pesos a los escenarios
  • Iterar estos pasos hasta cubrir los aspectos mas relevantes del sistema

Definiendo Expedientes Top-down

  • Definir categorías de escenarios:
    • Particionar los escenarios en un número de subgrupos basados en alguna característica del grupo.
    • Ejemplo: agrupar los casos de uso en base a los actores identificados.
    • Tratar de identificar de 4 a 8 categorías en cada expediente.

Definiendo Expedientes Top-down

  • Selección y definición de escenarios para cada categoría:
    • Una vez que se han agrupado los escenarios en subgrupos debe ser mas fácil seleccionar los escenarios mas representativos.
    • Producir hasta 10 escenarios por expediente.

Definiendo Expedientes Top-down

  • Asignar peso a cada escenario (usar datos históricos o estimados).
    • Para los casos de uso, el peso representa la frecuencia de ejecución de cada escenario.
    • Para escenarios de Mantenimiento, el peso representa la probabilidad de que ese escenario ocurra.
    • Seleccionar un esquema de asignación de pesos, 1 a 10, 1 a 100, (--,-,0,+,++), (1,3,9) como en QFD.
    • Normalizar pesos. Una vez que los pesos se han asignado, suma todos los pesos y divide cada peso individual por la suma. (los pesos deben sumar 1 y pueden ser fácilmente interpretados)
  • QFD (Quality Function Deployment)

Definiendo Expedientes

  • Formas de asignar pesos:
    • Individual (arquitecto)
    • Grupal (el equipo de diseño en sesión interactiva)
    • Grupal previa. Cada miembro prepara individualmente y en reunión grupal se define el peso de cada escenario

Expedientes de Atributo de Calidad

  • Los atributos de calidad pueden ser definidos en:
    • Rendimiento/ Eficiencia
    • Mantenimiento
    • Confiabilidad
    • Seguridad externa
    • Seguridad en los datos

Expedientes de Atributo de Calidad

  • Rendimiento/ Eficiencia.- Medir la eficiencia del sistema en ejecución:
    • rendimiento, número de escenarios por unidad de tiempo
    • tiempo de respuesta de un escenario especifico.
  • Arquitecturas pobremente diseñadas causan “cuellos de botella”.
  • Expediente: Describe el conjunto de escenarios funcionales de una instancia especifica para uno de los usuarios.

Rendimiento/ Eficiencia

  • Categorías.- Se encuentran descomponiendo los escenarios de uso en tipos de usuarios (actores) y/o interfaces del sistema.
  • Pesos.- representa la frecuencia de ejecución del escenario.
  • Información para la Descripción de la Arquitectura
    • Comportamiento del sistema para cada escenario
    • El tiempo promedio (y peor caso) de retraso en cada componente del sistema.
    • Usar datos históricos

Expedientes de Atributo de Calidad

  • Confiabilidad.- Es una función de diferentes factores (arquitectura, diseño detallado, implementación, experiencia, etc).
  • La confiabilidad de la arquitectura se basa en la interacción de los componentes durante la ejecución y los efectos de los errores en el sistema.
  • Los escenarios de uso que atraviesan varios componentes tendrán menor confiabilidad que aquellos que usan uno solo.

Expedientes de Atributo de Calidad

  • Confiabilidad
  • Expediente.- Los escenarios de uso se evalúan respecto a la confiabilidad del componente.
  • Peso.- Los pesos asociados a cada escenario y la confiabilidad de los componentes permiten calcular la confiabilidad del sistema.
  • Información de la descripción de la arquitectura
    • Se requiere información de la confiabilidad de los componentes (datos históricos o estimaciones por experiencia).

Expedientes de Atributo de Calidad

  • Seguridad Externa
  • Evalúa los efectos negativos o destructivos del sistema. No se relaciona con la funcionalidad del sistema sino con los efectos en el mundo real.
  • Efectos físicos
    • La maquina no detecta burbujas de aire en la sangre.
    • El sistema bancario realiza transacciones incorrectas.
  • Se deben detectar errores internos y errores en los datos de entrada.

Expedientes de Atributo de Calidad

  • Seguridad Externa
  • Expediente de daños / peligro.- Describen situaciones en las que NO detectar una falla puede traer consecuencias negativas o desastrosas.
  • Categorías.- Se organizan de acuerdo a documentos certificados, los puntos de interacción del sistema con el mundo real o componentes críticos los cuales al fallar, pueden provocar situaciones de peligro.
  • Información de la descripción de la arquitectura
    • Seguridad se usa en sistemas embebidos
    • Seguridad del software se deriva de la seguridad del sistema.

Expedientes de Atributo de Calidad

  • Seguridad en los datos
    • Intento de alterar partes del sistema
    • Información secreta o confidencial no disponible a usuarios no autorizados.
  • Disponibilidad.- Negar el servicio ante ataques.
  • Sistemas militares, negocios, gobierno deben mantener su información disponible solo para usuarios autorizados.

Expedientes de Atributo de Calidad

  • Seguridad en los datos
  • Expediente que contiene los aspectos que serán evaluados.
  • Ejemplo: Acceso a información secreta
  • Interno Externo (intento de acceso
  • No autorizado)
  • No intencional
  • Intencional
  • Categorías.- Usar todas las interfaces del sistema
  • Información de la descripción de la arquitectura.- Depende del aspecto a ser evaluado (Disponible/ Confidencial / Integridad)

Expedientes de Atributo de Calidad

  • Mantenimiento. La meta es absorber los requerimientos de cambios sin modificar la arquitectura.
  • Cambios con impacto en la arquitectura son prohibitivos.
  • Expediente. Dos tipos de categorías:
    • Identificar los cambios de categorías con base en interfaces e identificar pesos con base en la estabilidad de cada interfase. (hardware, SO, interfaces con otros sistemas, interfase de usuario)
    • Cambios en escenarios. Describen cambios en el funcionamiento del sistema.
  • Peso.- Indica la probabilidad de que el cambio ocurra en un periodo de tiempo.

Mantenimiento

  • Información para la Descripción de la Arquitectura.
    • Los escenarios de cambios se evalúan respecto al impacto que provocan en la arquitectura.
    • El impacto se calcula en términos de LOC que deben cambiarse.
    • Debe estimarse el número de LOC de cada componente del sistema para realizar la evaluación del atributo de mantenimiento.
  • LOC: Lines of code.

Ejemplo

  • Category
  • Market Driven
  • Hardware
  • Hardware
  • Hardware
  • Safety
  • Medical Adv.
  • Medical Adv.
  • Medical Adv.
  • Com.and I/O
  • Algorithms
  • Scenario Description (Weight)
  • Change measurement units from Celsius to Fahrenheit for temperature in a treatment. (0.043)
  • Add second concentrate pump and conductivity sensor. (0.043)
  • Replace blood pumps using revolutions per minute with pumps using actual flow rate (ml/s). (0.087)
  • Replace duty-cycle controlled heater with digitally interfaced heater using percent of full effect. (0.174)
  • Add alarm for reversed flow through membrane. (0.087)
  • Modify treatment from linear weight loss curve over time to inverse logarithmic. (0.217)
  • Change alarm from fixed flow limits to follow treatment. (0.087)
  • Add sensor and alarm for patient blood pressure (0.087)
  • Add function for uploading treatment data to patient’s digital journal. (0.043)
  • Change controlling algorithm for concentration of dialysis fluid from PI to PID. (0.132)

Ejemplo

  • Pág.. 90
  • Categorías:
    • Enfocadas al Mercado
    • Hardware
    • Regulaciones de seguridad
    • Avances médicos en la ciencia
    • Comunicación y E/S
    • Implementación de algoritmos

Resumen de Expedientes

  • Crear un expediente para cada atributo de calidad
  • Definir dos conjuntos de escenarios
    • Para diseño (completos)
    • Para evaluación (parciales)
  • Definir las categorías de los escenarios (4 a 6)
  • Definir escenarios para cada categoría ( max. 10)
  • Asignar pesos (frecuencia, probabilidad, etc.)
  • Normalizar los pesos

Cuatro Métodos de Evaluación

  • Basada en escenarios
  • Basada en simulación
  • Basada en un modelo matemático
  • Basada en la experiencia

Basada en Escenarios

  • Este método depende directamente de el expediente definido para el atributo de calidad que será evaluado.
  • La efectividad de la evaluación depende de que la selección de escenarios sea representativa. Si los escenarios no son representativos del mundo real, el método puede resultar “sospechoso”.

Basada en Escenarios

  • Expediente de
  • escenarios
  • Análisis de
  • Impacto
  • Puntos Problema
  • De la
  • Arquitectura
  • Resultados de
  • la Evaluación
  • Predicción de
  • Atributos de
  • Calidad
  • Valores de QA
  • Arquitectura de
  • Software

Basada en Escenarios

  • Análisis de Impacto:
    • Evalúa el impacto de cada escenario en la arquitectura.
      • Para escenarios de cambios:
        • Cuantos componentes requieren modificación?
        • Cuantos componentes nuevos se requieren?
        • Cuantas líneas de código (nuevas/modificadas)?
      • Para escenarios de rendimiento:
        • Ejecutando el escenario a través de los componentes: Cual es el tiempo de ejecución por componente y cual es el tiempo de sincronización entre componentes?
    • Recolecta y totaliza los resultados

Basada en Escenarios

  • Predicción de Atributos de Calidad usando los resultados del análisis de impacto.
    • Para mantenimiento:
      • Predecir el esfuerzo requerido en promedio para mantenimiento usando como medida el número de líneas de código o las horas de trabajo.
      • Calcular el costo de mantenimiento (numero de horas de trabajo para cada LOC * Total LOC)
    • Para rendimiento: predecir el tiempo de respuesta o el número de transacciones

Ejemplo. Sistema de Diálisis

  • Proceso artificial para remover agua y otros elementos de la sangre de un paciente con problemas en los riñones.
  • Definición de categorías:
    • Enfocadas al Mercado
    • Hardware
    • Regulaciones de seguridad
    • Avances médicos en la ciencia
    • Comunicación y E/S
    • Implementación de algoritmos
  • Definición (selección) de escenarios por categoría.
  • Asignación de pesos y normalización.
  • Resumen del expediente de mantenimiento (tabla)

Basada en Escenarios

  • Categoría
  • P Norm.
  • Enfocadas al Mercado
  • C1 Cambia medida de temperatura de grados Celsius a Fahrenheit en el 1 tratamiento
  • 0.043
  • Hardware
  • C2 Agregar segunda bomba y un sensor de conductividad 1
  • 0.043
  • Hardware
  • C3 reemplazar bombas de sangre usando revoluciones por minuto 2
  • con bombas usando tasa de flujo actual (ml/s)
  • 0.087
  • Hardware
  • C4 Reemplazar controlador de calor con uno de interfase digital 4
  • usando % de efecto total
  • 0.174
  • Seguridad
  • C5 Agregar alma para detectar reversión de flujo 2
  • 0.087
  • Avances médicos
  • C6 modificar tratamiento de curva de peso lineal sobre el tiempo 5
  • a logaritmo inverso
  • 0.217
  • Avances médicos
  • C7 cambia alarma de limites fijos de flujo a tratamiento 2
  • 0.087
  • Avances médicos
  • C8 Agregar sensor y alarma para pacientes con presión sanguínea 2
  • 0.087
  • Com. e I/O
  • C9 Agregar función para actualizar datos del tratamiento en el diario 1
  • digital del paciente
  • 0.043
  • Algoritmos
  • C10 cambiar algoritmo controlador para concentración de fluido de 3
  • PI a PID
  • 0.132
  • Tabla de Expediente de cambios para mantenimiento
  • Suma 23 1.0

Arquitectura del sistema

  • Interfase Hombre-Máquina
  • Hardware API
  • Sistema de Control
  • Sistema de Protección
  • IHM.- Responsable de presentar interfaces y alarmas al usuario.
  • SC.- configuración del sistema para operación y monitoreo.
  • SP.- Detecta situaciones que ponen en riesgo al paciente e inicia procesos para regresar a un estado seguro.
  • Nota: Los componentes no vienen en el libro.

Tamaño de componentes

  • Componente
  • LOC
  • HDFTreatment
  • 200
  • ConcentrationDevice
  • 100
  • ConcCtrl
  • 175
  • Acetate Pump and Conductivity Sensor
  • 100
  • HaemoDialysisMachines
  • 500
  • Fluidheater
  • 100
  • AlarmDetectorDevice
  • 100

Basada en Escenarios

  • Escenario
  • Componenetes Afectados
  • Volumen
  • C1
  • HDFTreatment (20% cambio) + nuevo componente Normaliser type
  • 0.2 * 200 + 20 = 60
  • C2
  • ConcentrationDevice (20% cambio) + ConcCtrl (50% cambio) + reuso de Acetate Pump and Conductivity Sensor con 10% modificacion c/u
  • 0.2 * 100 + 0.5 *175 + 0.1 * 100 +
  • 0.1 * 100 = 127.5
  • C3
  • HaemoDialysisMachines (10% cambio) + new AlarmHandler + new AlarmDevice
  • 0.1 * 500 + 200 + 100 = 350
  • C4
  • Fluidheater (10% cambio) remove DutyCycleControl and replace with reused SetCtrl
  • 0.1 * 100 = 10
  • C5
  • HDFTreatment (50% cambio)
  • 0.5 * 200 = 100
  • C6
  • AlarmDetectorDevice (50% cambio) HDFTreatment (20% cambio) + HaemoDialysisMachines (20% cambio)
  • 0.5 * 100 + 0.2 * 200 + 0.2 * 500 =190
  • C7
  • See C3
  • = 350
  • C8
  • New ControllingAlgorithm + new Normalizer
  • 100 + 20 = 120
  • C9
  • HDFTreatment (20% cambio) + HaemoDialysisMachines (50% cambio)
  • 0.2 * 200 + 0.5 * 500 = 290
  • C10
  • Replacement with new ControllingAlgorithm
  • = 100

Usando las tablas anteriores es posible calcular el número promedio de LOC para cada escenario.

  • 0.043*60 +
  • 0.043*127.5 +
  • 0.087*350 +
  • 0.174* 10 +
  • 0.087*100 +
  • 0.217*190 +
  • 0.087*350 +
  • 0.087*120 +
  • 0.043*290 +
  • 0.132*100
  • Cambios 145 LOC
  • en promedio
  • Peso normalizado del escenario * LOC afectadas
  • Cálculo del esfuerzo de mantenimiento
  • Asumiendo 20 requerimientos de cambio por año y 1 LOC por hora de trabajo
  • 20 (req.) * 145 (LOC por req.) / 1 (LOC por hora) =
  • 2900 horas de trabajo en un año
  • Cuantas personas se requieren para realizar el mantenimiento?
  • Requerimientos
  • LOC x Req
  • LOC x hora
  • Predicción
  • 20
  • 145
  • 1
  • 2900
  • 20
  • 145
  • 2
  • 1450
  • 20
  • 145
  • 5
  • 580
  • 20
  • 145
  • 10
  • 290
  • 20
  • 145
  • 20
  • 145
  • Que significa la predicción?

Evaluación basada en escenarios

  • Puede usarse para comparar dos o mas arquitecturas cualitativamente, en este caso no es necesario cuantificar el impacto solo estimar usando alguna escala (--,-,+,++) y totalizar.
  • Es buena para evaluar atributos de calidad de desarrollo. Para atributos operacionales otras técnicas son mejores.

Evaluación Basada en Escenarios

  • La evaluación consiste de dos pasos:
    • Análisis del impacto: toma la arquitectura y el expediente como entrada y genera datos que representan el impacto de cada escenario.
    • Predicción de atributo de calidad: Usa los datos generados en el paso anterior para hacer declaraciones a cerca del nivel del atributo de calidad.

Basada en Simulación

  • Implementación de la arquitectura en un prototipo
  • Contexto de simulación abstracto
  • Evaluación con la ejecución de escenarios
  • Ejemplo
    • rendimiento
    • confiabilidad

Basada en Simulación- Proceso

  • Define e implementa el contexto del sistema
  • Implementación abstracta de los componentes de la arquitectura
  • Implementación de los expedientes
  • Simulación del sistema con los escenarios
  • Recolecta resultados y predice atributos de calidad
  • Identifica errores de funcionalidad

Ejemplo

  • Simulación de un proceso de inspección de latas
  • La predicción del atributo de calidad depende de:
    • El expediente usado para la simulación
    • La implementación del contexto
    • La relación entre la arquitectura usada en la simulación y la arquitectura real

Basada en un Modelo Matemático

  • Modela la arquitectura usando aproximaciones
  • Análisis estático por cálculos
  • Relación con otras técnicas de evaluación
  • ejemplo
    • Modelado de rendimiento
    • Modelado de tareas en tiempo real

Modelo Matemático - Proceso

  • Selecciona el modelo matemático abstracto adecuado (sistemas en tiempo real, alto rendimiento, etc.)
  • Representa la arquitectura en términos del modelo
  • Estima los datos requeridos de entrada
  • Calcula la salida del modelo e interpreta resultados
  • Predicción de atributos de calidad, obtén una conclusión
  • Escribe lista de problemas de la arquitectura

Assessing the Friction Stir Welding Process With Mathematical Modeling Dr. Paul Colegrove, Cranfield University, United Kingdom, and COMSOL, Inc, Burlington, Massachusetts Saturday, September 01 2007

  • Figure 3: A customized user interface runs a Mathematical Model of FSW to analyze various materials and configurations.

Basado en Experiencia

  • Especialmente para ingenieros de software experimentados
  • Argumentos lógicos guían el razonamiento
  • Base para otras técnicas
  • Equipos de ingenieros para evaluación de arquitecturas

Satisfacción de Clientes

  • Reunión después del diseño arquitectónico (usuarios finales, clientes, operadores, implementadores, etc.)
  • Cada grupo define sus escenarios principales
  • Mezcla de los escenarios y creación de un subconjunto
  • Discusión de escenarios (max. 20) para solucionar conflictos
  • Si los conflictos permanecen, el diseño de la arquitectura se rechaza , sino se continua con el desarrollo

Líneas de Productos de Software

  • Meta: determinar la capacidad de la arquitectura para soportar todos los productos de una familia
  • Métodos de evaluación:
    • Evaluación por contexto
    • Evaluación por cada miembro de la familia de productos
    • Evaluación por los sistemas mas importantes
  • Evaluación para futuros miembros de la familia

Conclusión

  • Prioridad
  • Arquitectura de
  • Software
  • Especificación de
  • Requerimientos
  • Resultados de
  • Evaluación
  • Requerimientos de
  • Calidad
  • Requerimientos
  • Funcionales
  • Expediente
  • de escenarios
  • Diagrama de
  • Contexto
  • Interfase
  • Arquetipos
  • Relación
  • Componentes
  • Relación
  • Decisión de
  • Diseño
  • Estructura


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal