1. Diseño de Sistemas de
Información
Unidad I. Perfil del Analista de sistemas.,
Ciclo de vida de un S.I, Metodologías de
desarrollo, Criterios de calidad. Conceptos
fundamentales de diseño
Profa. Jacqueline Millán
2. Objetivos de la Unidad
• Al finalizar esta unidad, los participantes
estarán en capacidad de:
– Describir el perfil del analista de sistemas.
– Identificar las metodologías de desarrollo
de un S.I.
– Describir los criterios de uso de un S.I.
– Reconocer las fases del ciclo de vida de un
S.I.
3. Objetivos de la Unidad
• Conceptualizar los aspectos fundamentales del
Diseño de Sistemas:
– Abstracción y Refinamiento
– Modularidad y Arquitectura
– Jerarquía de Control, Estructura de datos
– Ocultamiento de Información
– Cohesión y Acoplamiento
5. Entorno del analista
• Sistemas de procesamiento de transacciones
(nómina, inventarios, facturación)
• Sistemas de automatización de oficinas
(Aplicaciones ofimáticas y bases de datos)
• Sistemas de Información Gerencial (Conocen la
globalidad de la organización, sirven de apoyo
en la toma de decisiones)
• Sistemas Expertos e Inteligencia Artificial
(Bases de conocimientos, experticia, reglas,
heurística)
6. Características del Analista
• Evaluador Sistemático (Entrada-Proceso-Salida)
• Capaz de trabajar con todo tipo de gente
• Conocimientos sobre computadoras
• De visión amplia.
• Saber escuchar
• Organizado(a)
• Abierto a los cambios
7. Roles del Analista
• Como consultor Externo (Visión sin vicios)
• Como experto en Soporte Técnico (Hardware y
Software)
• Como Agente de cambio de la organización
(Compromiso, Visión global, integrar las TIC´s
a la cultura organizacional)
8. Cualidades del Analista
• Solucionador de problemas
• Autodisciplinada y automotivada
• Buen administrador de los recursos
11. Fases del Ciclo de Vida de un S.I.
• Investigación Preliminar (Identificación de
Problemas, oportunidades y objetivos). Determinación
de requerimientos.
• Análisis del sistema. (Análisis de necesidades y
factibilidad)
• Diseño del Sistema Recomendado. Diseño Lógico y
Diseño Físico
• Desarrollo y documentación del software.
Programación y pruebas. Documentación del sistema
• Implementación. Evaluación y seguimiento
• Mantenimiento.
13. Metodologías de desarrollo
• M.E.D.S.I. Metodología Estructurada de
desarrollo de un S.I. Década de los 70`s
• Metodología Orientada a Objetos (M.O.O) Década
de los 80`s
• Proceso Unificado (UML)
• Metodologías Ágiles… Rapid prototyping,
Extreme Programming
15. Criterios de calidad de un S.I
• De Utilización: Conformidad, fiabilidad, eficacia,
integridad, facilidad de uso.
• De Transferencia: Portabilidad, compatibilidad,
portabilidad, rentabilidad.
• De mantenimiento: Mantenibilidad, testeabiidad,
flexibilidad
17. «El comienzo de la sabiduría para un
ingeniero del software es reconocer la
diferencia entre hacer que un programa
funcione y conseguir que lo haga
correctamente». [Jackson]
Los Conceptos de Diseño de Software
fundamentales proporcionan el marco de
trabajo necesario para conseguir que lo haga
correctamente.
18. Conceptos del Diseño
La Abstracción
En informática, el énfasis en el "¿qué
hace?" más que en el "¿cómo lo hace?".
• «La abstracción es una de las formas fundamentales en
que los hombres enfrentan a la complejidad»
• Cuando buscamos una solución modular a cualquier
problema, pueden existir varios niveles de abstracción.
• En el nivel más alto, la solución se expone como una
medida extensa, empleando el lenguaje del entorno del
problema.
• En niveles inferiores de abstracción, se toma una
orientación más procedimental.
19. Conceptos del Diseño
La Abstracción
• La terminología orientada a problemas va
emparejada con la terminología orientada a la
implementación en un esfuerzo por solucionar el
problema.
• En el nivel más bajo de abstracción, se establece la
solución para poder implementarse directamente.
• La noción psicológica de «abstracción» permite
concentrarse en un problema a algún nivel de
generalización sin tener en consideración los datos
irrelevantes de bajo nivel;
• La abstracción permite trabajar con conceptos y
términos familiares en el entorno del problema, sin
tener que transformarlos en una estructura no familiar.
20. Conceptos del Diseño
La Abstracción
• Cada paso del proceso del software es un
refinamiento en el nivel de abstracción para la
solución del software.
• Durante el Análisis de los requisitos del software,
la solución del software se establece en términos
«familiares del entorno del problema».
• A medida que nos adentramos en el Diseño, se
reduce el nivel de abstracción.
• Finalmente el nivel de abstracción más bajo se
alcanza cuando se genera el código fuente.
21. Conceptos del Diseño
La Abstracción Procedimental
• A medida que alcanzamos diferentes niveles de
abstracción, creamos abstracciones
procedimentales y de datos.
• Abstracción procedimental => secuencia de
instrucciones con una función específica y limitada.
• Ejemplo de abstracción procedimental => «abrir»
una puerta.
• «Abrir» implica una secuencia larga de pasos
procedimentales:
• Llegar a la puerta; alcanzar y agarrar el picaporte;
girarlo y tirar la puerta; separarse al mover la puerta,
etc.
22. Conceptos del Diseño
La Abstracción de Datos
• Abstracción de datos => colección de datos que
describe un objeto de datos.
• En el contexto de la abstracción procedimental abrir,
hay una abstracción de datos llamada puerta.
• La abstracción de datos para puerta son el conjunto de
atributos que describen esta puerta.
• Ejemplo => tipo de puerta, dirección de apertura,
mecanismo de apertura, peso, dimensiones.
• La abstracción procedimental abrir hace uso de la
información contenida en los atributos de la abstracción de
datos puerta.
23. Conceptos del Diseño
La Abstracción de Control
• La abstracción de control es la tercera forma de
abstracción que se utiliza en el diseño del software.
• Al igual que las abstracciones procedimentales y de
datos, este tipo de abstracción implica un mecanismo de
control de programa sin especificar los datos
internos.
• Un ejemplo de abstracción de control es el semáforo de
sincronización que se utiliza para coordinar las
actividades en un sistema operativo.
24. Conceptos del Diseño
Refinamiento
• El refinamiento paso a paso es una estrategia
de diseño descendente propuesta originalmente
por Wirth.
• El desarrollo de un programa se realiza refinando
sucesivamente los niveles de detalle
procedimentales.
• Una jerarquía se desarrolla descomponiendo una
sentencia macroscópica de función (una
abstracción procedimental) paso a paso hasta
alcanzar las sentencias del lenguaje de
programación.
25. Conceptos del Diseño
Refinamiento
• Wirth brinda una visión general del Refinamiento:
• En cada paso (del Refinamiento), se descomponen
una o varias instrucciones del programa en
instrucciones más detalladas.
• Esta descomposición sucesiva (refinamiento de
especificaciones) termina cuando todas las
instrucciones se expresan en función de cualquier
lenguaje de programación.
• Así como se refinan las tareas, los datos también se
tienen que refinar, descomponer o estructurar, en
paralelo con el programa.
• Todos los pasos del refinamiento implican decisiones de
diseño.
26. Conceptos del Diseño
Refinamiento
• El Proceso de Refinamiento de Programas es similar
al proceso de refinamiento y partición que se utiliza
durante el Análisis.
• La diferencia radica en el nivel de detalle de
implementación que se haya tomado en consideración,
no en el enfoque.
• Consejo => Existe la tendencia de entrar en detalle
inmediatamente, saltándose los pasos de
refinamiento.
• Ésto conduce a errores y omisiones y hace que el
diseño sea más difícil de revisar.
27. Conceptos del Diseño
Modularidad
• Esto es obvio: Se tarda más en resolver un
problema difícil.
• Esto lleva a una conclusión: «divide y vencerás»
es más fácil resolver un problema complejo
cuando se rompe en piezas manejables.
• Consejo => No modularice de más. La
simplicidad de cada módulo se eclipsará con
la complejidad de la integración.
28. Conceptos del Diseño
Modularidad
• El esfuerzo (costo) para desarrollar un
módulo individual disminuye a medida que
aumenta el número total de módulos.
• Con los mismos requisitos, tener más módulos
conduce a un tamaño menor de cada módulo.
• Sin embargo, a medida que aumenta el
número de módulos, también crece el
esfuerzo (costo) asociado con la integración
de módulos.
29. Conceptos del Diseño
Modularidad
• ¿Cómo se define un módulo con un tamaño
adecuado?
• La respuesta se encuentra en los métodos
utilizados para definir los módulos dentro de
un sistema.
• Hay 5 criterios que ayudan a definir un sistema
modular efectivo:
30. Conceptos del Diseño
Modularidad
• Un Sistema se puede diseñar modularmente,
aunque su implementación sea «monolítica».
• => El Software puede diseñarse
modularmente.
• El código se puede desarrollar «en línea».
• Aunque el código fuente del programa puede no
tener un aspecto modular a primera vista, se ha
mantenido la filosofía y el programa proporcionará
los beneficios de un sistema modular.
31. Conceptos del Diseño
Arquitectura
• Arquitectura del Software => «Estructura
Global del Software y a las formas en que esa
Estructura proporciona la integridad
conceptual de un sistema».
• Es la estructura jerárquica de los
componentes del programa (módulos), la
manera en que los componentes interactúan y la
estructura de datos que van a utilizar los
componentes.
• «Componentes» => representan los
elementos principales del sistema y sus
interacciones.
32. Conceptos del Diseño
Arquitectura
• Objetivo del Diseño del Software => derivar
una representación arquitectónica de un
sistema.
• Esta representación sirve como marco de trabajo
desde donde se llevan a cabo actividades de
diseño más detalladas.
• Un conjunto de patrones arquitectónicos
permiten que el ingeniero del software
reutilice los conceptos a nivel de diseño.
33. Conceptos del Diseño
Jerarquía de Control
• La Jerarquía de Control, llamada «estructura
de programa», representa la organización de
los componentes de programa (módulos) e
implica una jerarquía de control.
• El diagrama más común es el de forma de
árbol, que representa el control jerárquico
para las arquitecturas de llamada y de
retorno.
34. Conceptos del Diseño
Jerarquía de Control
• Según la Figura siguiente, la profundidad y el ancho
indican la cantidad de niveles de control y el ámbito
de control global, respectivamente.
• El grado de salida mide el número de módulos que
son controlados directamente por otro módulo.
• El grado de entrada indica la cantidad de módulos
que controlan directamente a un módulo dado.
• La relación de control entre los módulos se expresa así: un
módulo que controla a otro módulo es superior a éste,
e inversamente, un módulo controlado por otro es
subordinado del controlador.
36. Conceptos del Diseño
Estructura de Datos
• La Estructura de Datos es una representación de
la relación lógica entre elementos individuales de
datos.
• Como la estructura de la información afectará
invariablemente al diseño procedimental final, la
estructura de datos es tan importante como la
estructura de programa para la representación de
la arquitectura del software.
37. Conceptos del Diseño
Estructura de Datos
• Elemento escalar => Estructura de Datos más
simple.
• Representa un solo elemento de información
que puede ser tratado por un identificador =>
se puede acceder a él especificando un sola
dirección en memoria.
• El tamaño y formato de un elemento escalar
puede variar.
• Por ejemplo: una entidad lógica de un bit de
tamaño; un entero o número de coma flotante
con un tamaño de 8 a 64 bits; una cadena de
caracteres de cientos o miles de bytes.
38. Conceptos del Diseño
Ocultamiento de Información
• La «Modularidad» nos conduce a esta pregunta:
• «¿Cómo se puede descomponer un software
para obtener el mejor conjunto de módulos?»
• El principio de ocultación de información sugiere
que los módulos se caracterizan por las decisiones
de diseño que (cada uno) oculta al otro.
• => Los módulos deben diseñarse para que su
información (procedimiento y datos) interna sea
inaccesible a otros módulos que no necesiten
esa información.
39. Conceptos del Diseño
Independencia
En la mayoría de los diseños se trata de que los
componentes sean independientes unos de otros. Ya que,
un componente independiente es mucho más fácil de
modificar.
Para reconocer y medir el grado de independencia de los
componentes de un diseño se aplican dos conceptos :
acoplamiento y cohesión (Yourdon y Constantine 1978).
40. Conceptos del Diseño
Acoplamiento
Se dice que dos componentes están “altamente
acoplado” cuando existe mucha dependencia entre ellos.
Los componentes “poco acoplado” tienen algunas
dependencias, pero las interconexiones entre ellos son
débiles.
No acoplado
Débilmente Fuertemente
acoplado (pocas acoplado
dependencias) (muchas
dependencias)
41. Conceptos del Diseño
Acoplamiento
Se puede medir el acoplamiento en función de un rango de
dependencia, que va de la dependencia completa a la
completa independencia.
La meta no necesariamente es la completa independencia,
sino mantener el menor grado de acoplamiento posible.
El bajo acoplamiento contribuye a minimizar el número de
componentes que necesitan revisión.
Tipos de acoplamiento: ALTO
Acoplamiento de Contenido
Acoplamiento Común
Acoplamiento por Control DÉBIL
Acoplamiento por estampado
Acoplamiento por datos
No acoplado BAJO
42. Conceptos del Diseño
Cohesión
Un componente es cohesivo si todos sus elementos están
orientados a la realización de una única tarea y son
esenciales para llevarla a cabo.
Tipos de cohesión:
ALTA
Funcional
Secuencial
Procedimental
Comunicacional
Temporal
Lógica
Coincidental
BAJO
43. Conceptos del Diseño
Cohesión
Cohesión Coincidental
Ocurre cuando las partes de un componente no tienen
relación alguna entre si.(Cohesión baja)
Función A
Función B Función C Partes no
relacionadas.
Función D Función E
44. Conceptos del Diseño
Cohesión
Cohesión Lógica
Algunas funciones o elementos de datos relacionados
lógicamente están puestos en el mismo componente.
Ej: Componente que lee todo tipo de entradas (cinta, disco,
puertos, etc.) existe una relación lógica, pero no todas las
formas son iguales
Función A
Lógica
Función A’
Funciones
Similares
Función A’’
45. Conceptos del Diseño
Cohesión
Cohesión Temporal
A veces un componente se utiliza para inicializar un
sistema o un conjunto de variables. Este componente
realiza varias funciones en secuencia, pero las funciones
en si solo se realizan en el momento que ocurren.
Tiempo T0
Temporal
Tiempo T0 + X
Relacionadas
Tiempo T0 + 2X
por el tiempo.
46. Conceptos del Diseño
Cohesión
Cohesión Temporal
A veces un componente se utiliza para inicializar un
sistema o un conjunto de variables. Este componente
realiza varias funciones en secuencia, pero las funciones
en si solo se realizan en el momento que ocurren.
Tiempo T0
Temporal
Tiempo T0 + X
Relacionadas
Tiempo T0 + 2X
por el tiempo.
47. Conceptos del Diseño
Cohesión
Cohesión Procedimental
Es cuando las funciones se agrupan en un mismo
componente para asegurar un orden previsto.
Por Ejemplo: los datos deben ser ingresados antes de
chequearlos o de manipularlos, tres funciones en una
secuencia específica.
Función A
Procedimental
Función B
Relacionada por
el orden de las
Función C
funciones.
48. Conceptos del Diseño
Cohesión
Cohesión Comunicacional
Es cuando en un componente se asocian funciones que
acceden a un mismo conjunto de datos.
DATOS
Función A
Comunicacional
Función B
Acceso a
algunos datos
Función C
49. Conceptos del Diseño
Cohesión
Cohesión Secuencial
Se produce cuando la salida por una parte del componente
actúa como entrada para la parte que le sigue.
Función A
Secuencial
Función B La salida de una
parte es entrada
Función C para la siguiente
50. Conceptos del Diseño
Cohesión
Cohesión funcional (deseable)
Es la ideal, donde cada elemento de proceso es esencial
para la realización de una única función y todos los
elementos esenciales están contenidos en un único
componente.
Función A – parte 1
Funcional
Función B – parte 2 Secuencial con
funciones
Función C – parte 3 completamente
relacionadas
52. Fuentes consultadas
• Fabregas , LL. Planificación, análisis y diseño de
sistemas de información
• Kendall y Kendall. Análisis y Diseño de Sistemas de
Información.
• Mendoza R. Sistemas de Información II Disponible en
http://prof.usb.ve/lmendoza/Documentos/PS-6116/Teor%EDa
• Senn J. Análisis y Diseño de Sistemas de Información.
53. Fuentes consultadas
• Fabregas , LL. Planificación, análisis y diseño de
sistemas de información
• Kendall y Kendall. Análisis y Diseño de Sistemas de
Información.
• Mendoza R. Sistemas de Información II Disponible en
http://prof.usb.ve/lmendoza/Documentos/PS-6116/Teor%EDa
• Senn J. Análisis y Diseño de Sistemas de Información.