Análisis y diseño de Sistemas

• Programa : Listo para correr por su autor, en

el sistema en que fue desarrollado
• Producto de Programación: Puede ser
ejecutado, testeado, reparado y extendido por
“cualquiera”
• Sistema de programación: Colección de
programas interactivos, interfases y recursos
necesarios definidos
Análisis y Diseño de Sistemas - JML 1
 Sistema como producto

• Diseño general
• Compuesto por productos de programación
• Definición y testeo de interfases
• Definición de recursos necesarios para su
funcionamiento
• Portabilidad

Análisis y Diseño de Sistemas - JML 2

 Qué es el Software?
• Cerebro de una computadora
• El conocimiento capturado de un área de
aplicación
• Colección de programas y datos necesarios en
una computadora ,para una aplicación
particular
• Toda la documentación producida durante el
desarrollo de un sistema
Análisis y Diseño de Sistemas - JML 3
 Software
• El Software provee la porción activa del
Sistema, lo que hace que el sistema se vea
“vivo”
• El Software puede ser distintas cosas, pero
todas son simplemente aspectos de
información

Análisis y Diseño de Sistemas - JML 4

 Representaciones de Software

• Programas
• Diseño escrito en algún lenguaje de
programación
• Diseño arquitectónico representado como
diagramas de estructura
• Especificaciones escritas en un lenguaje formal
• Requerimientos

Análisis y Diseño de Sistemas - JML 5

Conocimiento de la Ingeniería del Software

• Toda la información que describe el

desarrollo en general (el como se usa un
método de diseño)
• Información: del proyecto , la tecnología del
Software, identificación y solución a
problemas técnicos

Análisis y Diseño de Sistemas - JML 6

 Conocimiento del dominio específico

• Entender como un proceso físico es

controlado
• Procedimientos inherentes al dominio
• Saber el comportamiento ,cómo funciona “la
cosa”

Análisis y Diseño de Sistemas - JML 7

 Información

• Es la esencia del Software

• Si no se maneja correctamente perjudica al
Software

Análisis y Diseño de Sistemas - JML 8

 Ciclo de Vida

• Definición
• Desarrollo
• Operación
• Evolución

Análisis y Diseño de Sistemas - JML 9

 Definición
• Instrucciones necesarias
• Análisis de necesidades
• Instrucciones de requerimientos
• Análisis de requerimientos
• Definición de elementos de datos
• Especificaciones funcionales

Análisis y Diseño de Sistemas - JML 10

 Desarrollo - Descripción técnica del sistema
• Especificaciones Técnicas
• Diseños arquitectónicos
• Diseños detallados
• Estructura de Base de Datos
• Descripción de datos
• Programas ejecutables

Análisis y Diseño de Sistemas - JML 11

 Desarrollo - Agregaciones del sistema

• Colección de programas
• Definición de interfases
• Integración de hardware y software
• Integración hombre, hardware y software

Análisis y Diseño de Sistemas - JML 12

 Operación - Sistema instalado
• Instalación
• Control de versiones
• Producción
• Medidas de eficiencia
• Reportes de error
• Medición de la efectividad

Análisis y Diseño de Sistemas - JML 13

 El Software no es fácil de cambiar

• No debe cambiarse sólo el código

• El cambio debe hacerse desde “arriba”
• Se debe prever el impacto de los cambios
• Debe actualizarse la documentación
• Control de versiones

Análisis y Diseño de Sistemas - JML 14

 El “viejo código” nunca muere
• Uso productivo
• Los usuarios lo aceptan, sin importar si es
lento, si hay que extenderlo. Cuando el
software se vuelve parte de sus vidas
(competencia subconsciente)
• Los usuarios no quieren tomarse el trabajo de
cambiarlo, con todo lo que ello implica
• Razones económicas
Análisis y Diseño de Sistemas - JML 15
 CICLO DE VIDA

Requerimientos Planeamiento Testeo

de softtware testeo sistema sistema de
de software software

Diseño Planeamiento
testeo Testeo
preliminar integración
integración

Diseño Planeamiento Testeo

detallado testeo unitario unitario

Codificación

Análisis y Diseño de Sistemas - JML 16

Fuente: Davis
 Costos por etapa
• Tamaño del programa
• bajo desarrollo
• (en k-líneas de código)
• Etapas
• 2 8 32 120

• 1.Requerimientos 6 6 6 6

• 2.Diseño preliminar 15 15 15 15

• 3.Diseño detallado, codificación 64 61 58 56

• 4.Integración y testeo del problema 15 18 21 23

• TOTAL (%) 100 100 100 100

Análisis y Diseño de Sistemas - JML 17

Fase de requerimientos
Comienzo
•Sistema de software
- Se reconoce un problema y que requiere solución, ó
- Surge una nueva idea de software (invención)
•Sistema de hardware y software
- Sigue al diseño del sistema
- Acompaña a la fase de requerimientos de hardware
Finalización
•Se describe el comportamiento externo del problema
•Se documentan las interfases sistema-ambiente
•La SRS describe que hará el sistema sin decir cómo

Análisis y Diseño de Sistemas - JML 18

D1020
Dilema “qué vs cómo”
Todas las metodologías pretenden presentar qué hace el software sin
aludir a cómo lo hace, pero en realidad hablan de distintos
requerimientos
Necesidades del usuario
qué/cómo
Espacio de productos (los comportamientos legales)
qué/cómo
Comportamiento real del producto
qué/cómo
Arquitectura/flujo de datos
qué/cómo
Especificación de módulo
qué/cómo
Algoritmos
qué/cómo
Código Análisis y Diseño de Sistemas - JML 19
D1030
 Diferentes nomenclaturas
Actividad Freeman Ross Davis Yourdon
Análisis de Análisis Análisis de Análisis Modelo
problemas contexto de esencial
problemas
Definición del Especificac Escribir Modelo de
comportam. funcional la SRS implement
externo Especificac del usuario
Definición de funcional Diseño Diseño Diseño
las preliminar
componentes
del producto

Análisis y Diseño de Sistemas - JML 20

 Tipos de requerimientos
• Que definen funciones
• “El sistema exhibirá la ubicación actual del barco”
• Que limitan funciones
• "El sistema debe generar un tono de dial dentro de los 5
segundos”
• Limita el tiempo de la función
• Que especifican relaciones
• "El sistema permite especificar en el set-up el color de
las naves exhibidas en la consola”
• Establece una relación de control entre el set-up y la
función de selección de color
Análisis y Diseño de Sistemas - JML 21
D1180
Importancia de los requerimientos
• Axioma:
• Hacer un mejor trabajo definiendo y especificando software no
sólo vale la pena sino que también es posible y ventajoso en costo
• Soporte:
• 1. Cuanto más tarde en el ciclo de vida se detecta un error, más
cuesta repararlo
• 2. Muchos errores permanecen latentes y no son detectados hasta
bastante despues de la etapa en que se cometieron
• 3. Se están cometiendo demasiado errores
• 4. Los errores de requerimientos son típicamente: hechos,
incorrectos, omisiones, inconsistencias y ambigüedades
• 5. Los errores en los requerimientos pueden detectarse

Análisis y Diseño de Sistemas - JML 22

D1220
 Hipótesis 1
• 1. Cuanto más tarde en el ciclo de vida se detecta un
error, más cuesta repararlo
• Evidencia
• ETAPA COSTO RELATIVO DE
• REPARACION
• REQUERIMIENTOS 0.1 - 0.2
• DISEÑO 0.5
• CODIFICACION 1
• TEST DE UNIDADES 2
• TEST DE ACEPTACION 5
• MANTENIMIENTO 20

Análisis y Diseño de Sistemas - JML 23

D1230
 Hipótesis 1
Posibles explicaciones
• A) Si la mayoría de los errores se detectan a tiempo,
entonces detectar y reparar errores en la etapa N+1 es
inherentemente más costoso que en la N
• B) Puede ser que el incremento de los costos derive de la
necesidad de corregir:
• - los errores originales y
• - los que se generan en etapas posteriores

• El crecimiento de los costos de reparación es producto

de la catarata de errores que se producen
• La explicación A es antintuitiva, consideramos la B
Análisis y Diseño de Sistemas - JML 24
D1240
Catarata de errores
Modelo de Mizuno

Análisis y Diseño de Sistemas - JML 25

D1245
 PROBLEMA REAL

especificación especificación
correcta incorrecta

Especificación de requerimientos

diseño basado en
diseño diseño especificación
correcto incorrecto incorrecta

Diseño

programas basados programas basados

programas errores de en diseño especificación
correctos programación incorrecto incorrecta

Implementación

funciones errores errores no errores

correctas corregibles corregibles ocultos

Testing Análisis y Diseño de Sistemas - JML 26

 PROBLEMA REAL

especificación especificación
correcta incorrecta

Especificación de requerimientos

diseño basado en
diseño diseño especificación
correcto incorrecto incorrecta

Diseño

programas basados programas basados

programas errores de en diseño especificación
correctos programación incorrecto incorrecta

Implementación

funciones errores errores no errores

correctas corregibles corregibles ocultos

Testing Análisis y Diseño de Sistemas - JML 27

 Hipótesis 2
• 2. Muchos errores permanecen latentes y no son
detectados hasta bastante despues de la etapa en que se
cometieron

• Evidencia (TRW)
• 54% de los errores se detectan después de las fases de
• codificación y prueba de unidades (45% de la fase de
• requerimientos y 9% de codificación)

Análisis y Diseño de Sistemas - JML 28

D1250
 Hipótesis 3
• 3. Se están cometiendo demasiado errores

• Evidencia ( De Marco)
• 56% de los errores tienen su origen en la etapa de
requerimientos

Análisis y Diseño de Sistemas - JML 29

D1250
 Hipótesis 4
• 4. Los errores de requerimientos son típicamente: hechos,
incorrectos, omisiones, inconsistencias y ambigüedades

• Evidencia (Basili, A-7E)

• - Errores administrativos: 77%
• - Hechos incorrectos: 49%
• - Omisiones: 31%
• - Inconsistencias: 13%
• - Ambigüedades: 5%
• - Requerimientos mal ubicados: 2%
Análisis y Diseño de Sistemas - JML 30
D1260
 Hipótesis 5
• 5. Los errores en los requerimientos pueden detectarse

• Evidencia (Basili, A-7E)

• Errores detectados manualmente: 33%
• Inpección: 65%
• Testeo de unidades: 10%
• Integración: 5%
• Evaluación: 10%
• Otros: 10%
• Las inspecciones han resultado de muy alta efectividad

Análisis y Diseño de Sistemas - JML 31

D1260
 Conclusión
• Se cometen muchos errores de requerimientos (Hip 3 y
4)
• Muchos de esos errores se detectan tardíamente (Hip 2)

• Sin embargo muchos pueden detectarse tempranamente

(Hip 5)
• No detectar los errores contribuye al incremento de
costos en el software (Hip 1)

Análisis y Diseño de Sistemas - JML 32

D1270
Impacto de los errores en la etapa
de requerimientos
• El software resultante puede no satisfacer a los
usuarios
• Las interpretaciones múltiples de los requerimientos
pueden causar desacuerdos entre clientes y
desarrolladores
• Es imposible que a través del testeo el software
satisfaga sus requerimientos
• Puede gastarse tiempo y dinero construyendo el
sistema erróneo
Análisis y Diseño de Sistemas - JML 33
D1280