Clase 11, 2/10/2007
-
Upload
christian-sifaqui -
Category
Documents
-
view
685 -
download
0
Transcript of Clase 11, 2/10/2007
Metodologías de Análisis
Clase 11 – 2/10/2007
Christian Sifaqui
Documento de especificación
Suficientemente informal para el clienteEl cliente no es un especialista computacional
Suficientemente formal para los desarrolladoresEs la única fuente de información para iniciar el
diseño
Estos dos requerimientos con contradictorios
Documento de especificación
El documento de especificación es un contrato entre el cliente y los desarrolladores
Restricciones típicasPlazoEjecución en paraleloPortabilidadConfiabilidadTiempo de respuesta rápido
Para software en tiempo realSe deben cumplir duras restricciones de tiempo real
Documento de especificación
Criterio de aceptaciónEs vital detallar una serie de tests
Si el producto pasa los tests, se supone que ha satisfecho sus especificaciones
Algún criterio de aceptación son repeticiones de restricciones
Estrategia de solución
Una aproximación general para construir el producto
Encontrar estrategias sin preocuparse de las restriccionesEntonces modificar las estrategias a la luz de las
restricciones, si es necesarioMantener un registro escrito de todas las
estrategias descartadas y porqué se descartaronPara proteger al equipo de análisisPara prevenir desacertadas nuevas “soluciones” durante
la mantención post-entrega
Especificaciones informales
Especificaciones informales se escriben en lenguaje natural
Ejemplo:“Si las ventas del mes actual están por debajo de las ventas objetivo, entonces se imprimirá un reporte, a menos que la diferencia entre las ventas objetivo y las ventas actuales sea menor que la mitad de la diferencia entre las ventas objetivo y las ventas actuales del mes previo, o si la diferencia entre las ventas objetivo y las ventas actuales para el mes actual está bajo un 5%”
Especificaciones informales
Las ventas objetivos de enero fueron de US$100.000, pero la ventas actuales fueron sólo de US$64.000 (36% por debajo del objetivo)Imprimir el reporte
La ventas objetivo para febrero fue de US$120.000, las ventas actuales fueron sólo de US$100.000 (16,7% bajo el objetivo)
El porcentaje de diferencia para febrero (16,7%) es menor que la mitad de la diferencia del mes previo (36%), así que no se imprime el reporte
Especificaciones informales
Las ventas objetivos de marzo fue de US$100.000, las ventas actuales US$98.000 (2% bajo el objetivo)El porcentaje de diferencia está bajo el 5%, así
que no se imprime el reporte
Especificaciones informales no dicen
“diferencia entre ventas objetivo y ventas actuales”Pero en las especificaciones no se menciona el
porcentaje de diferencia
La diferencia en enero fue de US$36.000, la diferencia en febrero fue de US$20.000No menos que la mitad de 36.000, así que se imprime el
reporte
“Diferencia … 5%”Nuevamente no se menciona el porcentaje
Especificaciones informales
Ambigüedad - ¿la cláusula se debería leer? “porcentaje de diferencia … de 5%” o “diferencia de US$5.000” u ¿otra cosa totalmente distinta?
El estilo es pobreLas especificaciones deberían indicar cuándo
se imprime el reporte
… en vez de indicar cuándo no se imprime
Especificaciones informales
AfirmaciónEsto no puede aparecer en especificaciones
profesionales
RefutaciónCaso de procesamiento de texto
Caso de estudio de prueba de correctitud
Problema de procesamiento de texto NaurDado un texto compuesto por palabras
separadas por caracteres espacio o nuevalínea, convertir a una forma línea a línea acorde a las siguientes reglas:
1.- se harán retorno de carros sólo donde el texto tenga espacio o nuevalínea
2.- cada línea se llenará tanto como sea posible, mientras
3.- la línea no tiene más de maxpos caracteres
Caso de estudio de prueba de correctitud
1969: paper de Naur
Naur construyó un procedimiento (25 líneas en Algol 60) e informalmente probó su correctitud
Caso de estudio de prueba de correctitud
1970: revisor en Computing ReviewsLa primera palabra de la primera línea está
precedida por un espacio a menos que la primera palabra sea exactamente maxpos caracteres
Caso de estudio de prueba de correctitud
1971: London encontró 3 fallas másIncluyendo: el procedimiento no termina a
menos que se encuentre una palabra más larga que maxpos caracteres
Caso de estudio de prueba de correctitud
1975: Goodenough y Gerhart encontraron 3 fallas másIncluyendo: la última palabra no será emitida a
menos que esté precedida por un espacio o nuevalínea
Goodenough y Gerhart definieron un nuevo conjunto de especificaciones, casi cuatro veces más largo que las de Naur
Caso de estudio de prueba de correctitud
1985: Meyer detectó 12 fallas en las especificaciones de Goodenough y Gerhart
Caso de estudio de prueba de correctitud
Las especificaciones de Goodenough y GerhartFueron construidas con gran cuidadoSe construyeron para corregir las especificaciones de
NaurPasaron por dos versiones, revisadas cuidadosamenteFueron escritas por expertos en especificacionesCon más tiempo del necesarioPara un producto de casi 30 líneas de largo
¿Qué probabilidad existe para escribir especificaciones sin errores para un producto real?
Caso de estudio de prueba de correctitud
1989: Schach encontró una falla en las especificaciones de Meyer
El ítem 2.- de los requerimientos originales de Naur (“cada línea se llenará tanto como sea posible”) no se cumple
Especificaciones informales
ConclusiónLenguaje natural NO es una buena manera de
especificar un producto
Análisis clásico
Análisis estructurado
Tres métodos gráficos de especificación de los 70’s
DeMarco
Gane and Sarsen
Yourdon
Son equivalentes
Son igualmente buenos
Análisis estructurado
Muchas corporaciones de EE.UU. las usan para productos comerciales
El método Gane and Sarsen se enseña porque es ampliamente usado
Estudio de caso de Sally Software Shop
Sally’s Software Shop (SSS) adquiere software de diversos proveedores y los vende al público. Paquetes de software populares se mantienen en stock, pero el resto se ordena cuando se solicita. Se les entrega crédito a instituciones y corporaciones, así como a algunos del público. A SSS le está yendo bien, con una rotación de 300 paquetes mensuales a un promedio de costo de US $250 cada uno. A pesar de su éxito, a Sally se la ha recomendado computarizar. ¿Debería?
Estudio de caso de SSS
Mejor preguntar¿Qué funciones del negocio debería
computarizar?Pagos de cuentas
Recibos de cuentas
Inventario
Mejor aún¿Cómo? ¿Batch u on-line? ¿Desarrollo propio o
outsourcing?
Estudio de caso de SSS
La clave fundamental¿Cuál es el objetivo de Sally al computarizar su
negocio?
¿Porque vende software?Ella necesita un sistema propio con efectos
deslumbrantes
¿Porque usa su negocio para lavar dinero?Ella necesita un producto que mantenga 5 tipos
diferentes de libros y sin auditoría financiera
Estudio de caso de SSS
Se supone que Sally desea computarizar “para ganar más dinero”Se necesita desarrollar análisis costo-beneficio
para cada sección de su negocio
Estudio de caso de SSS
El peligro de muchas aproximaciones estándares¡Primero producir la solución y después
encontrar cuál es el problema! “compremos un PC y de ahí vemos”
Método Gane and SarsenMétodo de nueve pasos
Se usa refinamiento sucesivo en muchos pasos
Estudio de caso de SSS
El diagrama de flujo de datos (DFD) muestra el flujo lógico de datos“Lo que pasa, no cómo pasa”
Estudio de caso de SSS
Símbolos
Cuadrado
dobleFuente o destino de datos
Flujo de datos
Rectángulo
redondeadoProceso que transforma un flujo de datos
Almacenamiento de datos
flecha
Rectángulo
abierto
Paso 1: crear el DFD
Primer refinamientoNúmero infinito de posibles interpretaciones
CLIENTE procesar_órdenes
detalles_paquete
PAQUETE_DE_DATOS
estado_crédito
DATOS_CLIENTE
pedido
factura
Paso 1
Segundo refinamientoÓrdenes pendientes se revisan diariamente
CLIENTEverificar_si_orden_
válida
detalles_paquete
PAQUETE_DE_DATOS
estado_crédito
pedido
DATOS_CLIENTE
ensamblar_
órdenes
ÓRDENES_
PENDIENTES
PROVEEDOR_
DE_SOFTWARE
poner_orden_
a_proveedor_
de_software
dirección_o_número_telefónico
detalles_de_paquete_a_ordenar
detalles_paquete_disponiblefactura
grupo_de_órdenes
Paso 1
Porción del tercer refinamiento
CLIENTEverificar_si_orden_
válida
detalles_paquete
PAQUETE_DE_DATOS
estado_crédito
pedido
DATOS_CLIENTE
ensamblar_
órdenes
detalles_paquete_a_ordenar
detalles_paquete_disponible
factura crear_
factura
dirección
detalles_entrega
detalles_paquete_recibido_de_agencia_softwareguía_despacho
Paso 1
El DFD final es mucho más grandepero es entendido fácilmente por el cliente
Cuando se trabaje con DFD grandesDefinir una jerarquía de DFDs
Una caja se convierte en DFD en nivel inferior
Paso 2: decidir qué partes computarizar y cómo
Depende de cuánto está dispuesto a invertir el cliente
Grandes volúmenes, controles firmesBatch
Pequeños volúmenes, microcomputadores in-houseOn-line
Análisis costo-beneficio
Paso 3: determinar los detalles de los flujos de datos
Determinar los ítemes de datos para cada flujo de dato
Refinar sucesivamente cada flujoEjemplo:
Orden:
identificación_orden
detalles_cliente
detalles_paquete
Se necesita un diccionario de datos para productos grandes
Ejemplo de entradas de diccionario de datos
Nombre de elemento de datos
descripción Narrativa
orden Registro que comprende los campos: Identificación_orden Detalles_cliente Dirección_cliente … Detalles_paquete Nombre_paquete Precio_paquete
Los campos contienen todos los detalles de una orden
Identificación_orden Entero 12-dígitos Número único generado por el procedimiento genear_número_orden. Los primeros 10 dígitos contienen el número de orden y os últimos 2 son dígitos de chequeo
Verificar_órden_válida Procedimiento: Parámetro de entrada: órden Parámetro de salida: número_de_errores
Este procedimiento toma la orden como entrada y chequea la validez de cada campo; por cada error encontrado, se muestra un mensaje apropiado (el número total de errores encontrados se retorna en el parámetro número_de errores)
Paso 4: definir la lógica de los procesos
Se tiene el proceso entregar_descuento_educacionalSally debe explicar el descuento que ella
entrega a instituciones educacionales10% para más de 4 paquetes
15% en 5 ó mas
Paso 4: definir la lógica de los procesos
Traducir esto a un árbol de decisión
entregar_descuento_educacional
Institución
educacional
≤ 4 paquetes: 10%
Otros: 0%
> 4 paquetes: 15%
Paso 4: definir la lógica de los procesos
La ventaja de un árbol de decisiónDetectar olvidos es muy fácil
Paso 5: definir los almacenamientos de datos
Definir los contenidos exactos y su representación (formato)COBOL: especificar a nivel pic
ADA: especificar digits o delta
Paso 5: definir los almacenamientos de datos
Especificar donde se requiera acceso inmediatoDiagrama de acceso inmediato de datos (DIAD)
Acceso a Paquete de datos por nombre, por función o por máquina, pero no por precio
Paso 5: definir los almacenamientos de datos
nombre
máquinafunción PAQUETE_DE_DATOS
nombre
precio
función
máquina
Diagrama de acceso inmediato de datos (DIAD)