Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Metodologías de Análisis Clase 11 – 2/10/2007 Christian Sifaqui
Documento de especificación <ul><li>Suficientemente informal para el cliente </li></ul><ul><ul><li>El cliente no es un esp...
Documento de especificación <ul><li>El documento de especificación es un contrato entre el cliente y los desarrolladores <...
Documento de especificación <ul><li>Criterio de aceptación </li></ul><ul><ul><li>Es vital detallar una serie de tests </li...
Estrategia de solución <ul><li>Una aproximación general para construir el producto </li></ul><ul><li>Encontrar estrategias...
Especificaciones informales <ul><li>Especificaciones informales se escriben en lenguaje natural </li></ul><ul><li>Ejemplo:...
Especificaciones informales <ul><li>Las ventas objetivos de enero fueron de US$100.000, pero la ventas actuales fueron sól...
Especificaciones informales <ul><li>Las ventas objetivos de marzo fue de US$100.000, las ventas actuales US$98.000 (2% baj...
Especificaciones informales no dicen <ul><li>“ diferencia entre ventas objetivo y ventas actuales” </li></ul><ul><ul><li>P...
Especificaciones informales <ul><li>Ambigüedad - ¿la cláusula se debería leer? “porcentaje de diferencia … de 5%” o “difer...
Especificaciones informales <ul><li>Afirmación </li></ul><ul><ul><li>Esto no puede aparecer en especificaciones profesiona...
Caso de estudio de prueba de correctitud <ul><li>Problema de procesamiento de texto Naur </li></ul><ul><ul><li>Dado un tex...
Caso de estudio de prueba de correctitud <ul><li>1969: paper de Naur </li></ul><ul><li>Naur construyó un procedimiento (25...
Caso de estudio de prueba de correctitud <ul><li>1970: revisor en Computing Reviews </li></ul><ul><ul><li>La primera palab...
Caso de estudio de prueba de correctitud <ul><li>1971: London encontró 3 fallas más </li></ul><ul><ul><li>Incluyendo: el p...
Caso de estudio de prueba de correctitud <ul><li>1975: Goodenough y Gerhart encontraron  3 fallas más </li></ul><ul><ul><l...
Caso de estudio de prueba de correctitud <ul><li>1985: Meyer detectó 12 fallas en las especificaciones de Goodenough y Ger...
Caso de estudio de prueba de correctitud <ul><li>Las especificaciones de Goodenough y Gerhart </li></ul><ul><ul><li>Fueron...
Caso de estudio de prueba de correctitud <ul><li>1989: Schach encontró una falla en las especificaciones de Meyer </li></u...
Especificaciones informales <ul><li>Conclusión </li></ul><ul><ul><li>Lenguaje natural NO es una buena manera de especifica...
Análisis clásico
Análisis estructurado <ul><li>Tres métodos gráficos de especificación de los 70’s </li></ul><ul><ul><li>DeMarco </li></ul>...
Análisis estructurado <ul><li>Muchas corporaciones de EE.UU. las usan para productos comerciales </li></ul><ul><li>El méto...
Estudio de caso de Sally Software Shop <ul><li>Sally’s Software Shop (SSS) adquiere software de diversos proveedores y los...
Estudio de caso de SSS <ul><li>Mejor preguntar </li></ul><ul><ul><li>¿Qué funciones del negocio debería computarizar? </li...
Estudio de caso de SSS <ul><li>La clave fundamental </li></ul><ul><ul><li>¿Cuál es el objetivo de Sally al computarizar su...
Estudio de caso de SSS <ul><li>Se supone que Sally desea computarizar “para ganar más dinero” </li></ul><ul><ul><li>Se nec...
Estudio de caso de SSS <ul><li>El peligro de muchas aproximaciones estándares </li></ul><ul><ul><li>¡Primero producir la s...
Estudio de caso de SSS <ul><li>El diagrama de flujo de datos (DFD) muestra el flujo lógico de datos </li></ul><ul><ul><li>...
Estudio de caso de SSS <ul><li>Símbolos </li></ul>Cuadrado doble Fuente o destino de datos Flujo de datos Rectángulo redon...
Paso 1: crear el DFD <ul><li>Primer refinamiento </li></ul><ul><ul><li>Número infinito de posibles interpretaciones </li><...
Paso 1 <ul><li>Segundo refinamiento </li></ul><ul><ul><li>Órdenes pendientes se revisan diariamente </li></ul></ul>CLIENTE...
Paso 1 <ul><li>Porción del tercer refinamiento </li></ul>CLIENTE verificar_si_orden_ válida detalles_paquete PAQUETE_DE_DA...
Paso 1 <ul><li>El DFD final es mucho más grande </li></ul><ul><ul><li>pero es entendido fácilmente por el cliente </li></u...
Paso 2: decidir qué partes computarizar y cómo <ul><li>Depende de cuánto está dispuesto a invertir el cliente </li></ul><u...
Paso 3: determinar los detalles de los flujos de datos <ul><li>Determinar los ítemes de datos para cada flujo de dato </li...
Ejemplo de entradas de diccionario de datos
Paso 4: definir la lógica de los procesos <ul><li>Se tiene el proceso  entregar_descuento_educacional </li></ul><ul><ul><l...
Paso 4: definir la lógica de los procesos <ul><li>Traducir esto a un árbol de decisión </li></ul><ul><li>entregar_descuent...
Paso 4: definir la lógica de los procesos <ul><li>La ventaja de un árbol de decisión </li></ul><ul><ul><li>Detectar olvido...
Paso 5: definir los almacenamientos de datos <ul><li>Definir los contenidos exactos y su representación (formato) </li></u...
Paso 5: definir los almacenamientos de datos <ul><li>Especificar donde se requiera acceso inmediato </li></ul><ul><ul><li>...
Paso 5: definir los almacenamientos de datos <ul><li>Diagrama de acceso inmediato de datos (DIAD) </li></ul>nombre máquina...
Upcoming SlideShare
Loading in …5
×

0

Share

Download to read offline

Clase 11, 2/10/2007

Download to read offline

  • Be the first to like this

Clase 11, 2/10/2007

  1. 1. Metodologías de Análisis Clase 11 – 2/10/2007 Christian Sifaqui
  2. 2. Documento de especificación <ul><li>Suficientemente informal para el cliente </li></ul><ul><ul><li>El cliente no es un especialista computacional </li></ul></ul><ul><li>Suficientemente formal para los desarrolladores </li></ul><ul><ul><li>Es la única fuente de información para iniciar el diseño </li></ul></ul><ul><li>Estos dos requerimientos con contradictorios </li></ul>
  3. 3. Documento de especificación <ul><li>El documento de especificación es un contrato entre el cliente y los desarrolladores </li></ul><ul><li>Restricciones típicas </li></ul><ul><ul><li>Plazo </li></ul></ul><ul><ul><li>Ejecución en paralelo </li></ul></ul><ul><ul><li>Portabilidad </li></ul></ul><ul><ul><li>Confiabilidad </li></ul></ul><ul><ul><li>Tiempo de respuesta rápido </li></ul></ul><ul><li>Para software en tiempo real </li></ul><ul><ul><li>Se deben cumplir duras restricciones de tiempo real </li></ul></ul>
  4. 4. Documento de especificación <ul><li>Criterio de aceptación </li></ul><ul><ul><li>Es vital detallar una serie de tests </li></ul></ul><ul><li>Si el producto pasa los tests, se supone que ha satisfecho sus especificaciones </li></ul><ul><li>Algún criterio de aceptación son repeticiones de restricciones </li></ul>
  5. 5. Estrategia de solución <ul><li>Una aproximación general para construir el producto </li></ul><ul><li>Encontrar estrategias sin preocuparse de las restricciones </li></ul><ul><ul><li>Entonces modificar las estrategias a la luz de las restricciones, si es necesario </li></ul></ul><ul><li>Mantener un registro escrito de todas las estrategias descartadas y porqué se descartaron </li></ul><ul><ul><li>Para proteger al equipo de análisis </li></ul></ul><ul><ul><li>Para prevenir desacertadas nuevas “soluciones” durante la mantención post-entrega </li></ul></ul>
  6. 6. Especificaciones informales <ul><li>Especificaciones informales se escriben en lenguaje natural </li></ul><ul><li>Ejemplo: </li></ul><ul><ul><li>“ 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%” </li></ul></ul>
  7. 7. Especificaciones informales <ul><li>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) </li></ul><ul><ul><li>Imprimir el reporte </li></ul></ul><ul><li>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) </li></ul><ul><ul><li>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 </li></ul></ul>
  8. 8. Especificaciones informales <ul><li>Las ventas objetivos de marzo fue de US$100.000, las ventas actuales US$98.000 (2% bajo el objetivo) </li></ul><ul><ul><li>El porcentaje de diferencia está bajo el 5%, así que no se imprime el reporte </li></ul></ul>
  9. 9. Especificaciones informales no dicen <ul><li>“ diferencia entre ventas objetivo y ventas actuales” </li></ul><ul><ul><li>Pero en las especificaciones no se menciona el porcentaje de diferencia </li></ul></ul><ul><li>La diferencia en enero fue de US$36.000, la diferencia en febrero fue de US$20.000 </li></ul><ul><ul><li>No menos que la mitad de 36.000, así que se imprime el reporte </li></ul></ul><ul><li>“ Diferencia … 5%” </li></ul><ul><ul><li>Nuevamente no se menciona el porcentaje </li></ul></ul>
  10. 10. Especificaciones informales <ul><li>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? </li></ul><ul><li>El estilo es pobre </li></ul><ul><ul><li>Las especificaciones deberían indicar cuándo se imprime el reporte </li></ul></ul><ul><ul><li>… en vez de indicar cuándo no se imprime </li></ul></ul>
  11. 11. Especificaciones informales <ul><li>Afirmación </li></ul><ul><ul><li>Esto no puede aparecer en especificaciones profesionales </li></ul></ul><ul><li>Refutación </li></ul><ul><ul><li>Caso de procesamiento de texto </li></ul></ul>
  12. 12. Caso de estudio de prueba de correctitud <ul><li>Problema de procesamiento de texto Naur </li></ul><ul><ul><li>Dado 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: </li></ul></ul><ul><ul><li>1.- se harán retorno de carros sólo donde el texto tenga espacio o nuevalínea </li></ul></ul><ul><ul><li>2.- cada línea se llenará tanto como sea posible, mientras </li></ul></ul><ul><ul><li>3.- la línea no tiene más de maxpos caracteres </li></ul></ul>
  13. 13. Caso de estudio de prueba de correctitud <ul><li>1969: paper de Naur </li></ul><ul><li>Naur construyó un procedimiento (25 líneas en Algol 60) e informalmente probó su correctitud </li></ul>
  14. 14. Caso de estudio de prueba de correctitud <ul><li>1970: revisor en Computing Reviews </li></ul><ul><ul><li>La primera palabra de la primera línea está precedida por un espacio a menos que la primera palabra sea exactamente maxpos caracteres </li></ul></ul>
  15. 15. Caso de estudio de prueba de correctitud <ul><li>1971: London encontró 3 fallas más </li></ul><ul><ul><li>Incluyendo: el procedimiento no termina a menos que se encuentre una palabra más larga que maxpos caracteres </li></ul></ul>
  16. 16. Caso de estudio de prueba de correctitud <ul><li>1975: Goodenough y Gerhart encontraron 3 fallas más </li></ul><ul><ul><li>Incluyendo: la última palabra no será emitida a menos que esté precedida por un espacio o nuevalínea </li></ul></ul><ul><li>Goodenough y Gerhart definieron un nuevo conjunto de especificaciones, casi cuatro veces más largo que las de Naur </li></ul>
  17. 17. Caso de estudio de prueba de correctitud <ul><li>1985: Meyer detectó 12 fallas en las especificaciones de Goodenough y Gerhart </li></ul>
  18. 18. Caso de estudio de prueba de correctitud <ul><li>Las especificaciones de Goodenough y Gerhart </li></ul><ul><ul><li>Fueron construidas con gran cuidado </li></ul></ul><ul><ul><li>Se construyeron para corregir las especificaciones de Naur </li></ul></ul><ul><ul><li>Pasaron por dos versiones, revisadas cuidadosamente </li></ul></ul><ul><ul><li>Fueron escritas por expertos en especificaciones </li></ul></ul><ul><ul><li>Con más tiempo del necesario </li></ul></ul><ul><ul><li>Para un producto de casi 30 líneas de largo </li></ul></ul><ul><li>¿Qué probabilidad existe para escribir especificaciones sin errores para un producto real? </li></ul>
  19. 19. Caso de estudio de prueba de correctitud <ul><li>1989: Schach encontró una falla en las especificaciones de Meyer </li></ul><ul><li>El ítem 2.- de los requerimientos originales de Naur (“cada línea se llenará tanto como sea posible”) no se cumple </li></ul>
  20. 20. Especificaciones informales <ul><li>Conclusión </li></ul><ul><ul><li>Lenguaje natural NO es una buena manera de especificar un producto </li></ul></ul>
  21. 21. Análisis clásico
  22. 22. Análisis estructurado <ul><li>Tres métodos gráficos de especificación de los 70’s </li></ul><ul><ul><li>DeMarco </li></ul></ul><ul><ul><li>Gane and Sarsen </li></ul></ul><ul><ul><li>Yourdon </li></ul></ul><ul><li>Son equivalentes </li></ul><ul><li>Son igualmente buenos </li></ul>
  23. 23. Análisis estructurado <ul><li>Muchas corporaciones de EE.UU. las usan para productos comerciales </li></ul><ul><li>El método Gane and Sarsen se enseña porque es ampliamente usado </li></ul>
  24. 24. Estudio de caso de Sally Software Shop <ul><li>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? </li></ul>
  25. 25. Estudio de caso de SSS <ul><li>Mejor preguntar </li></ul><ul><ul><li>¿Qué funciones del negocio debería computarizar? </li></ul></ul><ul><ul><ul><li>Pagos de cuentas </li></ul></ul></ul><ul><ul><ul><li>Recibos de cuentas </li></ul></ul></ul><ul><ul><ul><li>Inventario </li></ul></ul></ul><ul><li>Mejor aún </li></ul><ul><ul><li>¿Cómo? ¿Batch u on-line? ¿Desarrollo propio o outsourcing? </li></ul></ul>
  26. 26. Estudio de caso de SSS <ul><li>La clave fundamental </li></ul><ul><ul><li>¿Cuál es el objetivo de Sally al computarizar su negocio? </li></ul></ul><ul><li>¿Porque vende software? </li></ul><ul><ul><li>Ella necesita un sistema propio con efectos deslumbrantes </li></ul></ul><ul><li>¿Porque usa su negocio para lavar dinero? </li></ul><ul><ul><li>Ella necesita un producto que mantenga 5 tipos diferentes de libros y sin auditoría financiera </li></ul></ul>
  27. 27. Estudio de caso de SSS <ul><li>Se supone que Sally desea computarizar “para ganar más dinero” </li></ul><ul><ul><li>Se necesita desarrollar análisis costo-beneficio para cada sección de su negocio </li></ul></ul>
  28. 28. Estudio de caso de SSS <ul><li>El peligro de muchas aproximaciones estándares </li></ul><ul><ul><li>¡Primero producir la solución y después encontrar cuál es el problema!  “compremos un PC y de ahí vemos” </li></ul></ul><ul><li>Método Gane and Sarsen </li></ul><ul><ul><li>Método de nueve pasos </li></ul></ul><ul><ul><li>Se usa refinamiento sucesivo en muchos pasos </li></ul></ul>
  29. 29. Estudio de caso de SSS <ul><li>El diagrama de flujo de datos (DFD) muestra el flujo lógico de datos </li></ul><ul><ul><li>“ Lo que pasa, no cómo pasa” </li></ul></ul>
  30. 30. Estudio de caso de SSS <ul><li>Símbolos </li></ul>Cuadrado doble Fuente o destino de datos Flujo de datos Rectángulo redondeado Proceso que transforma un flujo de datos Almacenamiento de datos flecha Rectángulo abierto
  31. 31. Paso 1: crear el DFD <ul><li>Primer refinamiento </li></ul><ul><ul><li>Número infinito de posibles interpretaciones </li></ul></ul>CLIENTE procesar_órdenes detalles_paquete PAQUETE_DE_DATOS estado_crédito DATOS_CLIENTE pedido factura
  32. 32. Paso 1 <ul><li>Segundo refinamiento </li></ul><ul><ul><li>Órdenes pendientes se revisan diariamente </li></ul></ul>CLIENTE verificar_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_disponible factura grupo_de_órdenes
  33. 33. Paso 1 <ul><li>Porción del tercer refinamiento </li></ul>CLIENTE verificar_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_software guía_despacho
  34. 34. Paso 1 <ul><li>El DFD final es mucho más grande </li></ul><ul><ul><li>pero es entendido fácilmente por el cliente </li></ul></ul><ul><li>Cuando se trabaje con DFD grandes </li></ul><ul><ul><li>Definir una jerarquía de DFDs </li></ul></ul><ul><ul><li>Una caja se convierte en DFD en nivel inferior </li></ul></ul>
  35. 35. Paso 2: decidir qué partes computarizar y cómo <ul><li>Depende de cuánto está dispuesto a invertir el cliente </li></ul><ul><li>Grandes volúmenes, controles firmes </li></ul><ul><ul><li>Batch </li></ul></ul><ul><li>Pequeños volúmenes, microcomputadores in-house </li></ul><ul><ul><li>On-line </li></ul></ul><ul><li>Análisis costo-beneficio </li></ul>
  36. 36. Paso 3: determinar los detalles de los flujos de datos <ul><li>Determinar los ítemes de datos para cada flujo de dato </li></ul><ul><li>Refinar sucesivamente cada flujo </li></ul><ul><ul><li>Ejemplo: </li></ul></ul><ul><ul><ul><li>Orden: </li></ul></ul></ul><ul><ul><ul><li>identificación_orden </li></ul></ul></ul><ul><ul><ul><li>detalles_cliente </li></ul></ul></ul><ul><ul><ul><li>detalles_paquete </li></ul></ul></ul><ul><li>Se necesita un diccionario de datos para productos grandes </li></ul>
  37. 37. Ejemplo de entradas de diccionario de datos
  38. 38. Paso 4: definir la lógica de los procesos <ul><li>Se tiene el proceso entregar_descuento_educacional </li></ul><ul><ul><li>Sally debe explicar el descuento que ella entrega a instituciones educacionales </li></ul></ul><ul><ul><ul><li>10% para más de 4 paquetes </li></ul></ul></ul><ul><ul><ul><li>15% en 5 ó mas </li></ul></ul></ul>
  39. 39. Paso 4: definir la lógica de los procesos <ul><li>Traducir esto a un árbol de decisión </li></ul><ul><li>entregar_descuento_educacional </li></ul>Institución educacional ≤ 4 paquetes: 10% Otros: 0% > 4 paquetes: 15%
  40. 40. Paso 4: definir la lógica de los procesos <ul><li>La ventaja de un árbol de decisión </li></ul><ul><ul><li>Detectar olvidos es muy fácil </li></ul></ul>
  41. 41. Paso 5: definir los almacenamientos de datos <ul><li>Definir los contenidos exactos y su representación (formato) </li></ul><ul><ul><li>COBOL: especificar a nivel pic </li></ul></ul><ul><ul><li>ADA: especificar digits o delta </li></ul></ul>
  42. 42. Paso 5: definir los almacenamientos de datos <ul><li>Especificar donde se requiera acceso inmediato </li></ul><ul><ul><li>Diagrama de acceso inmediato de datos (DIAD) </li></ul></ul><ul><li>Acceso a Paquete de datos por nombre , por función o por máquina , pero no por precio </li></ul>
  43. 43. Paso 5: definir los almacenamientos de datos <ul><li>Diagrama de acceso inmediato de datos (DIAD) </li></ul>nombre máquina función PAQUETE_DE_DATOS nombre precio función máquina

Views

Total views

999

On Slideshare

0

From embeds

0

Number of embeds

31

Actions

Downloads

43

Shares

0

Comments

0

Likes

0

×