54
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

Unidad 1 clase 1 y 2

Embed Size (px)

DESCRIPTION

Unidad 1 de Diseño de sistemas de Informacion IUTA

Citation preview

Page 1: Unidad 1 clase 1 y 2

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

Page 2: Unidad 1 clase 1 y 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.

Page 3: Unidad 1 clase 1 y 2

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

Page 4: Unidad 1 clase 1 y 2

Perfil del Analista de Sistemas

Page 5: Unidad 1 clase 1 y 2

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)

Page 6: Unidad 1 clase 1 y 2

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

Page 7: Unidad 1 clase 1 y 2

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)

Page 8: Unidad 1 clase 1 y 2

Cualidades del Analista

• Solucionador de problemas

• Autodisciplinada y automotivada

• Buen administrador de los recursos

Page 9: Unidad 1 clase 1 y 2

Ciclo de vida de un S.I

Page 10: Unidad 1 clase 1 y 2

Fases del Ciclo de Vida de un S.I.

Page 11: Unidad 1 clase 1 y 2

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.

Page 12: Unidad 1 clase 1 y 2

Metodologías de Desarrollo de un S.I

Page 13: Unidad 1 clase 1 y 2

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

Page 14: Unidad 1 clase 1 y 2

Criterios de calidad de un S.I

Page 15: Unidad 1 clase 1 y 2

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

Page 16: Unidad 1 clase 1 y 2

Conceptos Fundamentales de

Diseño

Page 17: Unidad 1 clase 1 y 2

«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.

Page 18: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa Abstracción

• «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.

En informática, el énfasis en el "¿qué hace?" más que en el "¿cómo lo hace?".

Page 19: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa 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.

Page 20: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa 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.

Page 21: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa 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.

Page 22: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa 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.

Page 23: Unidad 1 clase 1 y 2

Conceptos del DiseñoLa 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.

Page 24: Unidad 1 clase 1 y 2

Conceptos del DiseñoRefinamiento

• 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.

Page 25: Unidad 1 clase 1 y 2

Conceptos del DiseñoRefinamiento

• 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.

Page 26: Unidad 1 clase 1 y 2

Conceptos del DiseñoRefinamiento

• 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.

Page 27: Unidad 1 clase 1 y 2

Conceptos del DiseñoModularidad

• 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.

Page 28: Unidad 1 clase 1 y 2

Conceptos del DiseñoModularidad

• 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.

Page 29: Unidad 1 clase 1 y 2

Conceptos del DiseñoModularidad

• ¿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:

Page 30: Unidad 1 clase 1 y 2

Conceptos del DiseñoModularidad

• 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.

Page 31: Unidad 1 clase 1 y 2

Conceptos del DiseñoArquitectura

• 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.

Page 32: Unidad 1 clase 1 y 2

Conceptos del DiseñoArquitectura

• 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.

Page 33: Unidad 1 clase 1 y 2

Conceptos del DiseñoJerarquí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.

Page 34: Unidad 1 clase 1 y 2

Conceptos del DiseñoJerarquí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.

Page 35: Unidad 1 clase 1 y 2

Conceptos del DiseñoJerarquía de Control

Page 36: Unidad 1 clase 1 y 2

Conceptos del DiseñoEstructura 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.

Page 37: Unidad 1 clase 1 y 2

Conceptos del DiseñoEstructura 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.

Page 38: Unidad 1 clase 1 y 2

Conceptos del DiseñoOcultamiento 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.

Page 39: Unidad 1 clase 1 y 2

Conceptos del DiseñoIndependencia

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).

Page 40: Unidad 1 clase 1 y 2

Conceptos del DiseñoAcoplamiento

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 acopladoDébilmente

acoplado (pocas dependencias)

Fuertemente acoplado (muchas

dependencias)

Page 41: Unidad 1 clase 1 y 2

Conceptos del DiseñoAcoplamiento

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:Acoplamiento de Contenido

Acoplamiento Común

Acoplamiento por Control

Acoplamiento por estampado

Acoplamiento por datos

No acoplado

ALTO

BAJO

DÉBIL

Page 42: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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:

Funcional

Secuencial

Procedimental

Comunicacional

Temporal

Lógica

Coincidental

ALTA

BAJO

Page 43: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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

Función D Función E

Partes no relacionadas.

Page 44: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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

Lógica

Funciones Similares

Función A

Función A’

Función A’’

Page 45: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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.

Temporal

Relacionadas por el tiempo.

Tiempo T0

Tiempo T0 + X

Tiempo T0 + 2X

Page 46: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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.

Temporal

Relacionadas por el tiempo.

Tiempo T0

Tiempo T0 + X

Tiempo T0 + 2X

Page 47: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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.

Procedimental

Relacionada por el orden de las funciones.

Función A

Función B

Función C

Page 48: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesión

Cohesión Comunicacional

Es cuando en un componente se asocian funciones que acceden a un mismo conjunto de datos.

Comunicacional

Acceso a algunos datos

Función A

Función B

Función C

DATOS

Page 49: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesión

Cohesión Secuencial

Se produce cuando la salida por una parte del componente actúa como entrada para la parte que le sigue.

Secuencial

La salida de una parte es entrada para la siguiente

Función A

Función B

Función C

Page 50: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesió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.

Funcional

Secuencial con funciones completamente relacionadas

Función A – parte 1

Función B – parte 2

Función C – parte 3

Page 51: Unidad 1 clase 1 y 2

Conceptos del DiseñoCohesión

Page 52: Unidad 1 clase 1 y 2

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%20PS6116%20Dise%F1o.pdf

• Senn J. Análisis y Diseño de Sistemas de Información.

Page 53: Unidad 1 clase 1 y 2

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%20PS6116%20Dise%F1o.pdf

• Senn J. Análisis y Diseño de Sistemas de Información.

Page 54: Unidad 1 clase 1 y 2