clase 10, 26/9/2007
Post on 04-Jul-2015
1.493 Views
Preview:
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 usoEstimar ingreso por inversión semanal
Estimar gastos operacionales semanales
Estimar pagos y subvenciones a la semana
Caso de uso: Estimar fondos disponibles por 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
Caso de uso: 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.- 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
subvenciones a la semana
Uso correcto (arriba); uso incorrecto (abajo)
Miembro
staff MSG
Sistema
Fundación MSGEstimar fondos
disponibles
por semana
Estimar pagos y
subvenciones a la semana
Relación «include»
El diagrama de abajo modela casos de usoEstimar fondos disponibles por semana, y
Estimar pagos y subvenciones a la semana
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)
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 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
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 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
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
DeudoresAdministrar
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á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
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
DeudoresAdministrar
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 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
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 menudoCada vez que se comete un error
Algunas veces se puede reparar un artefacto incorrectoMá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 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
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
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
Caso de uso: Estimar fondos disponibles por semana
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
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 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
top related