clase 10, 26/9/2007

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 usoEstimar ingreso por inversión semanal

Estimar gastos operacionales semanales

Estimar pagos y subvenciones a la semana


Miembro

staff MSG

Sistema

Fundación MSG

Estimar fondos

disponibles

por semana

Estimar ingreso

por inversión

semanal

Estimar gastos

operacionales semanales«in

clud

e»

«include» Estimar pagos y

subvenciones a la semana

«include»

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


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


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

Segunda iteración del caso de uso

Relación «include»

Miembro

staff MSG

Sistema

Fundación MSGEstimar fondos

disponibles

por semana

«include» Estimar pagos y


Uso correcto (arriba); uso incorrecto (abajo)

Miembro

staff MSG

Sistema

Fundación MSGEstimar fondos

disponibles

por semana

Estimar pagos y



El diagrama de abajo modela casos de usoEstimar fondos disponibles por semana, y


como dos casos de uso independientesSin embargo, un caso de uso modela una

interacción entre el producto en sí mismo y usuarios del producto (actores)


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 propioPor 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 incrementalDetalles que correctamente se han pospuesto a

veces de olvidan

Dos instancias de esto se describen a continuación


Detalles del caso de uso Administrar una inversión han sido pasados por alto, y

Caso de uso Administrar una hipoteca para modelarLa 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


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


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

DeudoresAdministrar

Una inversión

Estimar fondos

disponibles

por semana

Actualizar


anuales estimados

Estimar ingreso

por inversión

semanal

Estimar gastos


«include»



«include»

Actualizar

ingreso semanal

de deudores


Hay otra omisión másCaso de uso Producir un reporte para imprimir los

tres reportesReporte 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 reporteDescripció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


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

DeudoresAdministrar

Una inversión

Estimar fondos

disponibles

por semana

Actualizar


anuales estimados

Estimar ingreso

por inversión

semanal

Estimar gastos


«include»



«include»

Actualizar

ingreso semanal

de deudores

Producir

un reporte


Rechequear los requerimientos revisados descubre dos nuevos problemasUn 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 hipotecaUna acción es modificar una hipoteca

Caso de uso Actualizar ingreso semanal de deudoresLa única acción es actualizar el ingreso semanal de los

deudoresEl ingreso semanal de los deudores es un atributo

de la hipotecaCaso de uso Administrar una hipoteca ya incluye caso de

uso Actualizar ingreso semanal de los deudoresEn 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 MSGAdministrar

una hipoteca

Sistema

Fundación MSG

Deudores

Administrar

Una inversión

Estimar fondos

disponibles

por semana

Actualizar


anuales estimados

Estimar ingreso

por inversión

semanal

Estimar gastos


«include»



«include»

Producir

un reporte


Esta iteración resultó en un decremento, no en un incremento

De hecho eliminaciones ocurren a menudoCada vez que se comete un error

Algunas veces se puede reparar un artefacto incorrectoMás frecuentemente se tiene que eliminar un

artefacto


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


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



hipotecas


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


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


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

Preparador

impuesto

Sistema

Fundación MSG

Imprimir formulario

impuestos

Prepara formulario

1040

Preparar formulario

1040A

«include»

«incl

ude»

Preparar formulario

1040EZ

«include»

La razón usual para una relación «include» es donde un caso de uso es parte de dos o más casos de usoEjemplo: formularios de impuestos EE.UU, evitar triplicado


Para el caso de estudio de la Fundación MSGTodos 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 semanaEl 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


anuales estimados

Producir

un reporte

Descripción revisada: Estimar fondos disponibles por semana

Descripción



hipotecas



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



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


Ahora los requerimientos parecen estar correctosCorresponden 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 usuarioSentencias en lenguaje natural más diagramas de los

servicios que el sistema proveerá y sus restricciones operacionales. Escrito para clientes

Requerimientos de sistemaUn 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 funcionalesSentencias 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 funcionalesRestricciones de los servicios o funciones ofrecidas por el sistema

como restricciones de tiempo, restricciones en proceso de desarrollo, estándares, etc.

Requerimientos del dominioRequerimientos 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

CompletoDeben incluir descripciones de todos los servicios

requeridos

ConsistenteNo 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 productoEspecifican que el producto entregado debe comportarse

de una manera especial, por ejemplo, velocidad de ejecución, confiabilidad, etc.

Requerimientos organizacionalesSon una consecuencia de políticas y procedimientos

organizacionales, por ejemplo, estándares de procesos usados, requerimientos de implementación

Requerimientos externosQue 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 ayudaFacilidad de uso

Tiempo de entrenamiento

Probabilidad de no disponibilidad

Tasa de ocurrencias de fallas

Disponibilidad

Confiabilidad

MBytes

Número de chips ROMTamañ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

ObviedadEspecialistas 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

requerimientosInforme de

factibilidad

Modelos del

sistema

Requerimientos

Documento de

requerimientos

El proceso de requerimientos

Captura de

requerimientosValidación de

requerimientos

Especificación de

requerimientosEspecificació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 requerimientosDescubrimiento de

requerimientos

Clasificación y

organización de

requerimientos

Priorización y

negociación de

requerimientos

Actividades del proceso

Descubrimiento de requerimientosInteractuar con los involucrados para descubrir sus requerimientos.

También se descubren en esta etapa los requerimientos del dominio

Clasificación y organización de requerimientosSe agrupan los requerimientos relacionados y se organizan en

clusteres coherentes

Priorización y negociaciónSe priorizan requerimientos y resuelven conflictos de

requerimientos

Documentación de requerimientosSe 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 interactuadorPersonas u otros sistemas que interactúan

directamente con el sistema

Puntos de vista indirectaInvolucrados que no usan el sistema pero que

influencian los requerimientos

Puntos de vista del dominioCaracterí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 esOrientada al modelo, y por lo tanto

Orientada a objeto

La fase clásica de requerimientos

La aproximación clásica a los requerimientosDescubrimiento 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 cambiarLenguajes 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 consideradosEvitar 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 funcionalMuy 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 descarteImplementar 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 siHa 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 UMLPara 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 ArchitectSoftware through Pictures

Ambientes CASE orientados a objetos incluyen:IBM Rational RoseTogetherArgoUML

Otrosposeidon 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 desarrolladoresMuchos cambios pueden indicar que el proceso

estuvo defectuoso

Cambios iniciado por el clienteProblema 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 negociarLas 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

clase 10, 26/9/2007

Economy & Finance