Metodologia

Metodologías de Análisis
Clase 10 – 26/9/2007
Christian Sifaqui
Tercera iteración del diagrama de
caso de uso revisado
Sistema
Fundación MSG
l ud e» Estimar ingreso
Estimar fondos «inc por inversión
disponibles
«i
semanal
nc
por semana
lu
de
«in
Estimar gastos
»
clu
operacionales semanales
de
»
Estimar pagos y
subvenciones a la semana
Miembro Actualizar
staff MSG ingreso semanal
de deudores
Administrar
Deudores
una inversión
Actualizar
gastos operacionales
anuales estimados
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
Segunda iteración del caso de uso
Sistema
Fundación MSG
Estimar ingreso
por inversión
»
semanal
de
clu
Estimar fondos
«include»
«in
Estimar gastos
disponibles
operacionales semanales
por semana «in
c
lud
Miembro Estimar pagos y
e»
staff MSG
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
Relación «include»
Uso correcto (arriba); uso incorrecto (abajo)
Sistema
Fundación MSG
Estimar fondos
«include» Estimar pagos y
disponibles
por semana
Miembro
staff MSG
Sistema
Fundación MSG
Estimar fondos
Estimar pagos y
disponibles
por semana
Miembro
staff MSG
El diagrama de abajo modela casos de uso
Estimar fondos disponibles por semana, y
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)
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
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
Sistema
Fundación MSG
Administrar
una inversión
Miembro
staff 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
Sistema
Fundación MSG
Administrar
una hipoteca
Miembro
staff 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
Sistema Estimar ingreso
Fundación c MSG
l ude» por inversión
in
« semanal
Estimar fondos
disponibles
«include»
Estimar gastos
por semana «in
clu operacionales semanales
de
»
Estimar pagos y
Actualizar
Miembro ingreso semanal
staff MSG de deudores
Administrar Deudores
Una inversión
Administrar
una hipoteca
Actualizar
anuales estimados
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
Sistema
Fundación MSG
Producir
un reporte
Miembro
staff 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
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
Fundación c MSG
in
« semanal
Estimar fondos
disponibles
«include»
Estimar gastos
por semana «in
de
»
Estimar pagos y
Actualizar subvenciones a la semana
ingreso semanal
Miembro
de deudores
staff MSG
Administrar
Una inversión
Deudores
Administrar
una hipoteca
Actualizar
anuales estimados
Producir
un reporte
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
Fundación c MSG
in
« semanal
Estimar fondos
disponibles
«include»
Estimar gastos
por semana «in
de
»
Estimar pagos y
Administrar subvenciones a la semana
Miembro Una inversión
staff MSG
Administrar
una hipoteca
Actualizar Deudores
anuales estimados
Producir
un reporte
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
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

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
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
Sistema
Fundación MSG
Prepara formulario «in
1040
clu
de
»
de » Imprimir formulario
i nclu impuestos
Preparar formulario «
e»
1040A clud
«in
Preparador Preparar formulario

impuesto 1040EZ
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
Sistema
Fundación MSG
Estimar fondos
disponibles
por semana
Administrar
Una inversión
Miembro
staff MSG Administrar
una hipoteca
Actualizar Deudores
anuales estimados
Producir
un reporte
Descripción revisada: Estimar fondos
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
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
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 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

A veces son difíciles de precisar  ¿cómo
verificarlos?
De cualitativos llevar a cuantitativos

Transacciones por segundo
Rapidez
Tiempo de respuesta usuario/evento
Tiempo de refresco pantalla
MBytes
Tamaño
Número de chips ROM
Tiempo de entrenamiento
Confiabilidad
Probabilidad de no disponibilidad
Tasa de ocurrencias de fallas
Disponibilidad
Tiempo de entrenamiento
Facilidad de uso
Número de pantallas de ayuda
Tiempo de reinicio después de fallas
Robustez
Porcentaje de eventos que causen fallas
Probabilidad de corrupción de datos
Porcentaje de sentencias dependientes
Portabilidad de la plataforma
Número de sistemas destino
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 Captura y análisis de
factibilidad requerimientos
Especificación de
requerimientos
Validación de
Informe de
requerimientos
factibilidad
Modelos del
sistema
Requerimientos
Documento de
requerimientos
El proceso de requerimientos
Especificación de
Especificación y modelamiento
requerimientos
de requerimientos
de sistema
Especificación de
requerimientos
de usuario
Especificación de
requerimientos
de negocio
Captura de Captura de Estudio de

requerimientos Requerimientos factibilidad
de sistema de usuario
Prototipado
Captura de
Revisiones Validación de
requerimientos
requerimientos
Documento de requerimientos
de sistema
La espiral de requerimientos
Clasificación y Priorización y
organización de negociación de
requerimientos requerimientos
Descubrimiento de Documentación
requerimientos 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

Metodologia

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia

Cargado por

Copyright:

Formatos disponibles

Metodologías de Análisis

Descripción paso a paso

Descripción paso a paso

Miembro Una inversión

Descripción paso a paso

Preparador Preparar formulario

Descripción paso a paso

Por ahora, todo se ve bien

Del producto Organizacionales Externos

Usabilidad Eficiencia Confiabilidad Portabilidad Interoperabilidad Éticos Legales

Entrega Implementación Estándar

Rendimiento Espacio Privacidad Seguridad

De cualitativos llevar a cuantitativos

Captura de Captura de Estudio de

Prototipo rápido de la HCI de cada producto es

También podría gustarte