• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clase 10, 26/9/2007
 

Clase 10, 26/9/2007

on

  • 2,502 views

 

Statistics

Views

Total Views
2,502
Views on SlideShare
2,481
Embed Views
21

Actions

Likes
0
Downloads
84
Comments
0

2 Embeds 21

http://ici313-2-2007.blogspot.com 19
http://www.slideshare.net 2

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Clase 10, 26/9/2007 Clase 10, 26/9/2007 Presentation Transcript

    • Metodologías de Análisis Clase 10 – 26/9/2007 Christian Sifaqui
    • Tercera iteración del diagrama de caso de uso revisado Miembro staff MSG Administrar una inversión Sistema Fundación MSG Deudores Actualizar ingreso semanal de deudores Estimar fondos disponibles por semana Actualizar gastos operacionales anuales estimados Estimar ingreso por inversión semanal Estimar gastos operacionales semanales « include » « include » Estimar pagos y subvenciones a la semana « include »
    • Caso de uso: Estimar fondos disponibles por semana
      • Caso de uso Estimar fondos disponibles por semana modela el cálculo que usa los datos obtenidos de otros tres otros casos de uso
        • Estimar ingreso por inversión semanal
        • Estimar gastos operacionales semanales
        • Estimar pagos y subvenciones a la semana
    • Caso de uso: Estimar fondos disponibles por semana
      • Segunda iteración del caso de uso
      Miembro staff MSG Sistema Fundación MSG Estimar fondos disponibles por semana Estimar ingreso por inversión semanal Estimar gastos operacionales semanales « include » « include » Estimar pagos y subvenciones a la semana « include »
    • Caso de uso: Estimar fondos disponibles por semana
      • Segunda iteración del caso de uso
      Descripción Este caso de uso permite al miembro del staff de la Fundación MSG estimar cuánto dinero tiene disponible la fundación esta semana para financiar hipotecas Descripción paso a paso 1.- Determinar el ingreso estimado por inversiones para la semana usando el caso de uso Estimar ingreso por inversión semanal 2.- Determinar los gastos operativos para la semana usando el caso de uso Estimar gastos operacionales semanales 3.- Determinar los pagos totales estimados por hipotecas para la semana usando el caso de uso Estimar pagos y subvenciones a la semana 4.- Determinar el total estimado de subvenciones usando el caso de uso Estimar pagos y subvenciones a la semana 5.- Sumar los resultados de los pasos 1 a 3 y restar los resultados de los pasos 2 y 4. Ésta es la cantidad total disponible para hipotecas para la semana actual
    • Relación « include »
      • Uso correcto (arriba); uso incorrecto (abajo)
      Miembro staff MSG Sistema Fundación MSG Estimar fondos disponibles por semana « include » Estimar pagos y subvenciones a la semana Miembro staff MSG Sistema Fundación MSG Estimar fondos disponibles por semana Estimar pagos y subvenciones a la semana
    • Relación « include »
      • El diagrama de abajo modela casos de uso
        • Estimar fondos disponibles por semana , y
        • Estimar pagos y subvenciones a la semana
      • como dos casos de uso independientes
        • Sin embargo, un caso de uso modela una interacción entre el producto en sí mismo y usuarios del producto (actores)
    • Relación « include »
      • Caso de uso Estimar pagos y subvenciones a la semana no interactúa con un actor y por lo tanto no puede ser un caso de uso propio
        • Por el contrario, es una porción del caso de uso Estimar fondos disponibles por semana , como se refleja en el diagrama superior
    • El workflow de test: Caso MSG
      • Un efecto lateral común del modelo de ciclo de vida iterativo e incremental
        • Detalles que correctamente se han pospuesto a veces de olvidan
        • Dos instancias de esto se describen a continuación
    • El workflow de test: Caso MSG
      • Detalles del caso de uso Administrar una inversión han sido pasados por alto, y
      • Caso de uso Administrar una hipoteca para modelar
        • La suma de una nueva hipoteca
        • La modificación de una hipoteca existente, o
        • La eliminación de una hipoteca existente
      • han sido totalmente olvidadas
        • (en forma similar al caso de uso Administrar una inversión )
    • Caso de uso: Administrar una inversión Miembro staff MSG Administrar una inversión Sistema Fundación MSG Descripción Este caso de uso permite a un miembro del staff de la Fundación MSG agregar y eliminar inversiones y administrar el portafolio de inversión Descripción paso a paso 1.- Agregar, modificar o eliminar una inversión
    • Caso de uso: Administrar una hipoteca Miembro staff MSG Administrar una hipoteca Sistema Fundación MSG Descripción Este caso de uso permite a un miembro del staff de la Fundación MSG agregar y eliminar hipotecas y administrar el portafolio de hipotecas Descripción paso a paso 1.- Agregar, modificar o eliminar una hipoteca
    • Cuarta iteración del diagrama de caso de uso revisado Miembro staff MSG Administrar una hipoteca Sistema Fundación MSG Deudores Administrar Una inversión Estimar fondos disponibles por semana Actualizar gastos operacionales anuales estimados Estimar ingreso por inversión semanal Estimar gastos operacionales semanales « include » « include » Estimar pagos y subvenciones a la semana « include » Actualizar ingreso semanal de deudores
    • El workflow de test: Caso MSG
      • Hay otra omisión más
        • Caso de uso Producir un reporte para imprimir los tres reportes
          • Reporte de inversiones
          • Reporte de hipotecas
          • Resultados de cálculos semanales
        • ha sido totalmente olvidado
    • Caso de uso: Producir un reporte Miembro staff MSG Producir un reporte Sistema Fundación MSG
    • Caso de uso: Producir un reporte Descripción Este caso de uso permite al miembro del staff de la Fundación MSG imprimir los resultados de los cálculos semanales de fondos disponibles para nuevas hipotecas o imprimir un listado de todas las inversiones o todas las hipotecas Descripción paso a paso 1.- Se deben generar los siguientes reportes: 1.1.- Reporte de inversiones, impreso a demanda: se imprime una lista de todas las inversiones. Para cada inversión se imprimen los siguientes atributos: número de ítem, nombre de ítem, retorno estimado anual, fecha de última actualización de retorno estimado anual 1.2.- Reportes de hipotecas, impreso a demanda: se imprime un listado de todas las hipotecas. Para cada hipoteca se imprimen los siguientes atributos: número de cuenta, nombre de hipotecario, precio original de la casa, fecha de la hipoteca, pago C & I, ingreso combinado bruto actual, fecha última actualización ingreso combinado bruto actual, impuesto anual bienes raíces, fecha última actualización impuesto anual bienes raíces, prima anual de seguro propietario, fecha última actualización prima anual de seguro propietario 1.3.- Resultado de cálculo semanal, impreso cada semana: se imprime la cantidad disponible para nuevas hipotecas durante la semana actual
    • Quinta iteración del diagrama de caso de uso revisado Miembro staff MSG Administrar una hipoteca Sistema Fundación MSG Deudores Administrar Una inversión Estimar fondos disponibles por semana Actualizar gastos operacionales anuales estimados Estimar ingreso por inversión semanal Estimar gastos operacionales semanales « include » « include » Estimar pagos y subvenciones a la semana « include » Actualizar ingreso semanal de deudores Producir un reporte
    • El workflow de test: Caso MSG
      • Rechequear los requerimientos revisados descubre dos nuevos problemas
        • Un caso de uso ha sido parcialmente duplicado
        • Dos de los casos de uso necesitan ser reorganizados
    • Caso de uso parcialmente duplicado
      • Caso de uso Administrar una hipoteca
        • Una acción es modificar una hipoteca
      • Caso de uso Actualizar ingreso semanal de deudores
        • La única acción es actualizar el ingreso semanal de los deudores
      • El ingreso semanal de los deudores es un atributo de la hipoteca
        • Caso de uso Administrar una hipoteca ya incluye caso de uso Actualizar ingreso semanal de los deudores
      • En forma acorde, el caso de uso Actualizar ingreso semanal de deudores es superfluo y debe ser eliminado
    • Sexta iteración del diagrama de caso de uso revisado Miembro staff MSG Administrar una hipoteca Sistema Fundación MSG Deudores Administrar Una inversión Estimar fondos disponibles por semana Actualizar gastos operacionales anuales estimados Estimar ingreso por inversión semanal Estimar gastos operacionales semanales « include » « include » Estimar pagos y subvenciones a la semana « include » Producir un reporte
    • El workflow de test: Caso MSG
      • Esta iteración resultó en un decremento, no en un incremento
      • De hecho eliminaciones ocurren a menudo
        • Cada vez que se comete un error
      • Algunas veces se puede reparar un artefacto incorrecto
        • Más frecuentemente se tiene que eliminar un artefacto
    • El workflow de test: Caso MSG
      • Sin embargo, cuando se descubre una falla, no se inicia el proceso desde cero
      • Primero se trata de reparar la iteración actual
      • Si el error es muy serio para que esto funcione, se devuelve a la iteración anterior y se trata de encontrar una mejor manera de seguir adelante desde allí
    • Reorganizando dos casos de uso
      • Determinar los fondos disponibles para la semana actual
        • Caso de uso Estimar fondos disponibles por semana modela el realizar el cálculo
        • Paso 1.3 del caso de uso Producir un reporte modela imprimir el resultado del cálculo
      • No tiene sentido calcular los fondos disponibles a menos que los resultados se impriman
    • Reorganizando dos casos de uso
      • La descripciones de los casos de uso
        • Estimar fondos disponibles por semana y
        • Producir un reporte
      • deben ser modificados (los casos de uso no cambian)
    • Descripción modificada: Producir un reporte Descripción Este caso de uso permite al miembro del staff de la Fundación MSG imprimir un listado de todas las inversiones o todas las hipotecas Descripción paso a paso 1.- Se deben generar los siguientes reportes: 1.1.- Reporte de inversiones, impreso a demanda: se imprime una lista de todas las inversiones. Para cada inversión se imprimen los siguientes atributos: número de ítem, nombre de ítem, retorno estimado anual, fecha de última actualización de retorno estimado anual 1.2.- Reportes de hipotecas, impreso a demanda: se imprime un listado de todas las hipotecas. Para cada hipoteca se imprimen los siguientes atributos: número de cuenta, nombre de hipotecario, precio original de la casa, fecha de la hipoteca, pago C & I, ingreso combinado bruto actual, fecha última actualización ingreso combinado bruto actual, impuesto anual bienes raíces, fecha última actualización impuesto anual bienes raíces, prima anual de seguro propietario, fecha última actualización prima anual de seguro propietario
    • Descripción modificada: Estimar fondos disponibles por semana Descripción Este caso de uso permite al miembro del staff de la Fundación MSG estimar cuánto dinero tiene disponible la fundación esta semana para financiar hipotecas Descripción paso a paso 1.- Determinar el ingreso estimado por inversiones para la semana usando el caso de uso Estimar ingreso por inversión semanal 2.- Determinar los gastos operativos para la semana usando el caso de uso Estimar gastos operacionales semanales 3.- Determinar los pagos totales estimados por hipotecas para la semana usando el caso de uso Estimar pagos y subvenciones a la semana 4.- Determinar el total estimado de subvenciones usando el caso de uso Estimar pagos y subvenciones a la semana 5.- Sume los resultados de los pasos 1 a 3 y reste los resultados de los pasos 2 y 4. Ésta es la cantidad total disponible para hipotecas para la semana actual 6.- Imprimir la cantidad total disponible para nuevas hipotecas durante la semana actual
    • El workflow de test: caso MSG
      • La razón usual para una relación «include» es donde un caso de uso es parte de dos o más casos de uso
        • Ejemplo: formularios de impuestos EE.UU, evitar triplicado
      Preparador impuesto Sistema Fundación MSG Imprimir formulario impuestos Prepara formulario 1040 Preparar formulario 1040A « include » « include » Preparar formulario 1040EZ « include »
    • Caso de uso: Estimar fondos disponibles por semana
      • Para el caso de estudio de la Fundación MSG
        • Todos los casos de uso incluidos son parte de sólo un caso de uso Estimar fondos disponibles por semana
      • Incorporar estos tres casos de uso «include» en un caso de uso Estimar fondos disponibles por semana
        • El diagrama de caso de uso resultante se presenta a continuación
    • Séptima iteración del diagrama de caso de uso revisado Miembro staff MSG Administrar una hipoteca Sistema Fundación MSG Deudores Administrar Una inversión Estimar fondos disponibles por semana Actualizar gastos operacionales anuales estimados Producir un reporte
    • Descripción revisada: Estimar fondos disponibles por semana Descripción Este caso de uso permite al miembro del staff de la Fundación MSG estimar cuánto dinero tiene disponible la fundación esta semana para financiar hipotecas
    • Descripción revisada: Estimar fondos disponibles por semana
      • Descripción paso a paso
      • 1.- Para cada inversión, extraiga el retorno estimado anual de esta inversión. Sumar
      • los retornos separados y dividir el resultado por 52 entrega el ingreso estimado para
      • la semana
      • 2.- Determinar los gastos operacionales estimados para la Fundación para la semana
      • extrayendo los gastos operacionales estimados y dividiendo por 52
      • 3.- Para cada hipoteca:
        • 3.1.- La cantidad a pagar esta semana es el total del pago C & I y 1/52avo de la suma del
        • impuesto de bienes raíces anuales y las primas anuales de seguro del propietario
        • 3.2.- Calcular 28 por ciento del ingreso bruto semanal de la pareja
        • 3.3.- Si el resultado del paso 3.1 es mayor que el resultado del paso 3.2, entonces el pago
        • de la hipoteca para esta semana es la diferencia entre el resultado del paso 3.1 y el resultado
        • del paso 3.2
        • 3.4.- En caso contrario, el pago de la hipoteca para esta semana es el resultado del paso 3.1
        • y no hay subvención esta semana
    • Descripción revisada: Estimar fondos disponibles por semana Descripción paso a paso 4.- Sumar los pagos de hipotecas de los pasos 3.3 y 3.4 entrega los pagos estimados de la hipotecas para esta semana 5.- Sumar los pagos de las subvenciones de los pasos 3.3 entrega el total de pagos de subvenciones de esta semana 6.- Sume los resultados de los pasos 1 y 4 y restar los resultados de los pasos 2 y 5. Este es el total disponible para hipotecas esta semana 7.- Imprimir la cantidad disponibles para nuevas hipotecas durante la semana actual
    • El workflow de test: Caso MSG
      • Ahora los requerimientos parecen estar correctos
        • Corresponden a lo que el cliente solicitó
        • Parecen satisfacer las necesidades del cliente
        • Al parecer no hay más errores
      • Por ahora, todo se ve bien
    • Requerimiento (Davis)
      • “ If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”
    • Tipos de requerimiento
      • Requerimientos de usuario
        • Sentencias en lenguaje natural más diagramas de los servicios que el sistema proveerá y sus restricciones operacionales. Escrito para clientes
      • Requerimientos de sistema
        • Un documento estructurado indicando descripciones detalladas de las funciones, servicios del sistema y restricciones operacionales. Define lo que debe ser implementado, de tal manera que podría ser parte de un contrato entre el cliente y el proveedor
    • Tipos de requerimiento
      • Requerimientos funcionales
        • Sentencias de servicios que el sistema debe proveer, cómo el sistema debe reaccionar a entradas particulares y cómo el sistema debe comportarse en situaciones particulares
      • Requerimientos no funcionales
        • Restricciones de los servicios o funciones ofrecidas por el sistema como restricciones de tiempo, restricciones en proceso de desarrollo, estándares, etc.
      • Requerimientos del dominio
        • Requerimientos que vienen del dominio de aplicación del sistema y que refleja características de ese dominio
    • Requerimiento
      • Describe funcionalidad o servicios del sistema
      • Depende del tipo de software, usuarios esperados y el tipo de sistema donde se usará el software
      • Requerimientos funcionales de usuarios pueden ser sentencias de alto nivel de lo que el sistema debe realizar, pero requerimientos funcionales de sistema deben describir los servicios del sistema en detalle
    • Completitud y consistencia
      • Los requerimientos deben ser completos y consistentes
      • Completo
        • Deben incluir descripciones de todos los servicios requeridos
      • Consistente
        • No deberían haber conflictos o contradicciones en las descripciones de los servicios del sistema
      • En realidad, es imposible producir un documento de requerimientos completo y consistente
    • Requerimientos no funcionales
      • Definen propiedades y restricciones del sistema, por ejemplo, confiabilidad, tiempo de respuesta y requerimientos de almacenamiento. Son restricciones capacidad de dispositivos I/O, representaciones de sistema, etc.
      • Requerimientos de procesos pueden especificar el uso de un sistema particular CASE, lenguajes de programación o método de desarrollo
      • Requerimientos no funcionales pueden ser más críticos que los funcionales. Si no se logran, el sistema es inútil.
    • Requerimientos no funcionales
      • Requerimientos del producto
        • Especifican que el producto entregado debe comportarse de una manera especial, por ejemplo, velocidad de ejecución, confiabilidad, etc.
      • Requerimientos organizacionales
        • Son una consecuencia de políticas y procedimientos organizacionales, por ejemplo, estándares de procesos usados, requerimientos de implementación
      • Requerimientos externos
        • Que surgen de factores que son externos al sistema y su proceso de desarrollo, por ejemplo, requerimientos de interoperabilidad, requerimientos legales, etc.
    • Tipos de requerimientos no funcionales Requerimientos no funcionales Del producto Organizacionales Externos Usabilidad Eficiencia Confiabilidad Portabilidad Interoperabilidad Éticos Legales Entrega Implementación Estándar Rendimiento Espacio Privacidad Seguridad
    • Requerimientos funcionales
      • A veces son difíciles de precisar  ¿cómo verificarlos?
      • De cualitativos llevar a cuantitativos
    • Requerimientos funcionales Porcentaje de sentencias dependientes de la plataforma Número de sistemas destino Portabilidad Tiempo de reinicio después de fallas Porcentaje de eventos que causen fallas Probabilidad de corrupción de datos Robustez Tiempo de entrenamiento Número de pantallas de ayuda Facilidad de uso Tiempo de entrenamiento Probabilidad de no disponibilidad Tasa de ocurrencias de fallas Disponibilidad Confiabilidad MBytes Número de chips ROM Tamaño Transacciones por segundo Tiempo de respuesta usuario/evento Tiempo de refresco pantalla Rapidez
    • Requerimientos del dominio
      • Derivados del dominio de la aplicación y describen características del sistema que reflejan el dominio
      • Son nuevos requerimientos funcionales, restricciones en requerimientos existentes o define cálculos específicos
      • Si estos requerimientos no se satisfacen, el sistema puede ser inutilizable
    • Problemas de los requerimientos del dominio
      • Entendimiento:
        • requerimientos son expresados en el lenguaje del dominio de aplicación
        • A menudo no es entendido por ingenieros de software
      • Obviedad
        • Especialistas del dominio entienden el área tan bien que no hacen explícitos sus requerimientos de dominio
    • Requerimientos de usuario
      • Deben describir requerimientos funcionales y no funcionales de una manera tal que sean entendibles por los usuarios del sistema que no tengan conocimiento técnico detallado
      • Requerimientos de usuario se definen usando lenguaje natural, tablas y diagramas para que sean entendibles por todos los usuarios
    • Requerimientos de sistema
      • Especificaciones más detalladas de funciones del sistema, servicios y restricciones que los requerimientos de usuario
      • Deben ser la base para diseñar el sistema
      • Deben ser incorporados al contrato
      • Se definen o detallan usando métodos de análisis (DFD o UML o Z o etc.)
    • El proceso de requerimientos Estudio de factibilidad Captura y análisis de requerimientos Especificación de requerimientos Validación de requerimientos Informe de factibilidad Modelos del sistema Requerimientos Documento de requerimientos
    • El proceso de requerimientos Captura de requerimientos Validación de requerimientos Especificación de requerimientos Especificación y modelamiento de requerimientos de sistema Especificación de requerimientos de usuario Estudio de factibilidad Prototipado Revisiones Captura de Requerimientos de usuario Captura de requerimientos de sistema Documento de requerimientos de sistema Especificación de requerimientos de negocio
    • La espiral de requerimientos Documentación de requerimientos Descubrimiento de requerimientos Clasificación y organización de requerimientos Priorización y negociación de requerimientos
    • Actividades del proceso
      • Descubrimiento de requerimientos
        • Interactuar con los involucrados para descubrir sus requerimientos. También se descubren en esta etapa los requerimientos del dominio
      • Clasificación y organización de requerimientos
        • Se agrupan los requerimientos relacionados y se organizan en clusteres coherentes
      • Priorización y negociación
        • Se priorizan requerimientos y resuelven conflictos de requerimientos
      • Documentación de requerimientos
        • Se documentan los requerimientos y se usan de entrada a la siguiente ronda de la espiral
    • Puntos de vista
      • Es una forma de estructurar los requerimientos para representar las perspectivas de los involucrados. Los involucrados pueden ser clasificados bajo diferentes puntos de vista
      • Este análisis multi-perspectiva es importante ya que no hay una única forma correcta de analizar los requerimientos del sistema
    • Tipos de puntos de vista
      • Punto de vista del interactuador
        • Personas u otros sistemas que interactúan directamente con el sistema
      • Puntos de vista indirecta
        • Involucrados que no usan el sistema pero que influencian los requerimientos
      • Puntos de vista del dominio
        • Características del dominio y restricciones que influyen en los requerimientos
    • La fase clásica de requerimientos
      • No existe algo como “requerimientos orientados a objeto”
        • El workflow de requerimientos no tiene nada que ver con cómo será construido el producto
      • Sin embargo, la aproximación presentada en el caso MSG es
        • Orientada al modelo, y por lo tanto
        • Orientada a objeto
    • La fase clásica de requerimientos
      • La aproximación clásica a los requerimientos
        • Descubrimiento de requerimientos
        • Análisis de requerimientos
        • Construcción de un prototipo rápido
        • Cliente y usuarios futuros experimentan con el prototipo rápido
    • Prototipo rápido
      • Construido apresuradamente (“rápido”)
        • Imperfecciones pueden ser ignoradas
      • Sólo exhibe funcionalidad clave
      • Énfasis sólo en lo que el cliente ve
        • Se ignoran chequeos de error, actualización de archivos, etc.
      • Objetivo:
        • Proveer al cliente con un entendimiento del producto
    • Prototipo rápido
      • Un prototipo rápido se construye para cambiar
        • Lenguajes para prototipos rápidos incluyen 4GL y lenguajes interpretados
    • Factores humanos
      • El cliente y los usuarios deben interactuar con la interfaz de usuario
      • Human-computer interface (HCI)
        • Menú, no línea de comando
        • “ point and click”
        • Windows, icons, pull-down menus
    • Factores humanos
      • Factores humanos debe ser considerados
        • Evitar una secuencia larga de menús
        • Permitir modificar el nivel de experticia de una interfaz
        • Uniformidad de apariencia es importante
        • Sicología avanzada vs. sentido común
        • Prototipo rápido de la HCI de cada producto es obligatorio
    • Reusando el prototipo rápido
      • Reusar el prototipo rápido es esencialmente codificar-y-corregir
      • Cambios se hacen a un producto funcional
        • Muy caro
      • Mantención es difícil sin documentos de especificaciones y diseño
      • Restricciones de tiempo real son difíciles de lograr
    • Reusando el prototipo rápido
      • Una manera de asegurarse que el prototipo rápido se descarte
        • Implementar en lenguaje diferente al del producto final
      • Código generado puede ser reusado
      • Se puede retener en forma segura (parte de) un prototipo rápido si
        • Ha sido preplanificado
        • Estas partes pasaron las inspecciones del SQA
        • Sin embargo, esto no es el prototipo rápido clásico
    • Herramientas CASE para el workflow de requerimientos
      • Se necesitan herramientas gráficas para diagramas UML
        • Para facilitar el cambio de los diagramas UML
        • La documentación se almacena en la herramienta y por lo tanto está siempre disponible
      • Estas herramientas a menudo son difíciles de usar
      • Los diagramas necesitan considerable “tweaking”
      • En general, los fortalezas superan a la debilidades
    • Herramientas CASE para el workflow de requerimientos
      • Ambientes gráficos CASE extendidos para sustentar UML, por ejemplo:
        • System Architect
        • Software through Pictures
      • Ambientes CASE orientados a objetos incluyen:
        • IBM Rational Rose
        • Together
        • ArgoUML
      • Otros
        • poseidon for UML
    • Métricas para el workflow de requerimientos
      • Volatibilidad y velocidad de convergencia son medidas de cuán rápido se determinan las necesidades del cliente
    • Métricas para el workflow de requerimientos
      • El número de cambios hechos durante las fases siguientes
      • Cambios iniciados por desarrolladores
        • Muchos cambios pueden indicar que el proceso estuvo defectuoso
      • Cambios iniciado por el cliente
        • Problema del “moving target”
    • Retos de la fase de requerimientos
      • Los empleados de la organización del cliente a menudo se sienten amenazados por la computarización
      • Los miembros del equipo de requerimientos deben ser capaces de negociar
        • Las necesidades del cliente pueden haber escalado
      • Los empleados claves de la organización cliente no tienen tiempo para discusiones esenciales profundas
      • Flexibilidad y objetividad son esenciales