SlideShare une entreprise Scribd logo
1  sur  54
Télécharger pour lire hors ligne
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
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.
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
Perfil del Analista de
       Sistemas
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)
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
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)
Cualidades del Analista
• Solucionador de problemas


• Autodisciplinada y automotivada


• Buen administrador de los recursos
Ciclo de vida de un S.I
Fases del Ciclo de Vida de un S.I.
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.
Metodologías de Desarrollo
        de un S.I
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
Criterios de calidad de un
            S.I
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
Conceptos Fundamentales
       de Diseño
«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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
Conceptos del Diseño
 Jerarquía de Control
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.
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.
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.
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).
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)
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
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
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
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’’
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.
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.
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.
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
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
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
Conceptos del Diseño
      Cohesión
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.
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.
Unidad 1 clase 1 y 2

Contenu connexe

Tendances

Cena de Filósofos
Cena de FilósofosCena de Filósofos
Cena de FilósofosMiguel Cruz
 
Simulacion de sistemas discretos
Simulacion de sistemas discretosSimulacion de sistemas discretos
Simulacion de sistemas discretosMP4R
 
Numero pseudoaleatorio
Numero pseudoaleatorioNumero pseudoaleatorio
Numero pseudoaleatorioalan moreno
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidosTensor
 
Ads sistema-panaderia-ADS
Ads sistema-panaderia-ADSAds sistema-panaderia-ADS
Ads sistema-panaderia-ADSRosarioRuiz35
 
Arquitectura Cliente-Servidor y P2P
Arquitectura Cliente-Servidor y P2PArquitectura Cliente-Servidor y P2P
Arquitectura Cliente-Servidor y P2PManuel Marcano
 
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XP
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XPETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XP
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XPJglory22
 
Mecanismos de exclusion mutua y algoritmos
Mecanismos de exclusion mutua y algoritmosMecanismos de exclusion mutua y algoritmos
Mecanismos de exclusion mutua y algoritmosAbimael hernandez
 
Tipos de Modelos de Datos : Ventajas y Desventajas
Tipos de Modelos de Datos : Ventajas y DesventajasTipos de Modelos de Datos : Ventajas y Desventajas
Tipos de Modelos de Datos : Ventajas y DesventajasJuanMiguelCustodioMo
 
Presentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarePresentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarepaoaboytes
 

Tendances (20)

Cena de Filósofos
Cena de FilósofosCena de Filósofos
Cena de Filósofos
 
Controles de desarrollo de Software
Controles de desarrollo de SoftwareControles de desarrollo de Software
Controles de desarrollo de Software
 
Paralelismo a nivel de Instrucciones
Paralelismo a nivel de InstruccionesParalelismo a nivel de Instrucciones
Paralelismo a nivel de Instrucciones
 
Simulacion de sistemas discretos
Simulacion de sistemas discretosSimulacion de sistemas discretos
Simulacion de sistemas discretos
 
Relojes y terminales
Relojes y terminalesRelojes y terminales
Relojes y terminales
 
Numero pseudoaleatorio
Numero pseudoaleatorioNumero pseudoaleatorio
Numero pseudoaleatorio
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 
Sistema de Archivos Distribuidos
Sistema de Archivos DistribuidosSistema de Archivos Distribuidos
Sistema de Archivos Distribuidos
 
Ads sistema-panaderia-ADS
Ads sistema-panaderia-ADSAds sistema-panaderia-ADS
Ads sistema-panaderia-ADS
 
Procesos en windows
Procesos en windowsProcesos en windows
Procesos en windows
 
Arquitectura Cliente-Servidor y P2P
Arquitectura Cliente-Servidor y P2PArquitectura Cliente-Servidor y P2P
Arquitectura Cliente-Servidor y P2P
 
Modelos de desarrollo de software
Modelos de desarrollo de softwareModelos de desarrollo de software
Modelos de desarrollo de software
 
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XP
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XPETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XP
ETAPAS Y SUB ETAPAS DE LA METODOLOGÍA XP
 
Ejemplo de fdd
Ejemplo de fddEjemplo de fdd
Ejemplo de fdd
 
Sistema De Gestion De Notas
Sistema De Gestion De NotasSistema De Gestion De Notas
Sistema De Gestion De Notas
 
Mecanismos de exclusion mutua y algoritmos
Mecanismos de exclusion mutua y algoritmosMecanismos de exclusion mutua y algoritmos
Mecanismos de exclusion mutua y algoritmos
 
Seguridad y proteccion
Seguridad y proteccionSeguridad y proteccion
Seguridad y proteccion
 
Tipos de Modelos de Datos : Ventajas y Desventajas
Tipos de Modelos de Datos : Ventajas y DesventajasTipos de Modelos de Datos : Ventajas y Desventajas
Tipos de Modelos de Datos : Ventajas y Desventajas
 
Presentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarePresentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del software
 
Metodología Rup
Metodología RupMetodología Rup
Metodología Rup
 

Similaire à Unidad 1 clase 1 y 2

Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTEPRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTECAMILO
 
Presentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CostePresentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CosteCAMILO
 
Proyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoProyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoCAMILO
 
presentacion de software y estimacion de doste
presentacion de software y estimacion de dostepresentacion de software y estimacion de doste
presentacion de software y estimacion de dosteCAMILO
 
Proyecto de Software y Coste
Proyecto de Software y CosteProyecto de Software y Coste
Proyecto de Software y CosteCAMILO
 
PROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSPROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSCAMILO
 
Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Lucero Mtz
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareturlahackers
 
Solución de problemas y ciclo de vida del desarrollo de software
Solución de problemas y ciclo de vida del desarrollo de softwareSolución de problemas y ciclo de vida del desarrollo de software
Solución de problemas y ciclo de vida del desarrollo de softwareAlvaro Enrique Ruano
 
Importancia de los analistas en sistemas alexis díaz
Importancia de los analistas en sistemas   alexis díazImportancia de los analistas en sistemas   alexis díaz
Importancia de los analistas en sistemas alexis díazAlexis Díaz
 
Ingeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadIngeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadXKWDX
 

Similaire à Unidad 1 clase 1 y 2 (20)

Conceptos de diseño
Conceptos de diseñoConceptos de diseño
Conceptos de diseño
 
Juan velasquez
Juan velasquezJuan velasquez
Juan velasquez
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTEPRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
 
Presentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CostePresentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de Coste
 
Proyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoProyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de Costo
 
presentacion de software y estimacion de doste
presentacion de software y estimacion de dostepresentacion de software y estimacion de doste
presentacion de software y estimacion de doste
 
Proyecto de Software y Coste
Proyecto de Software y CosteProyecto de Software y Coste
Proyecto de Software y Coste
 
PROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSPROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOS
 
8.conceptos de diseño
8.conceptos de diseño8.conceptos de diseño
8.conceptos de diseño
 
Ciclo de Vida y roles
Ciclo de Vida y roles Ciclo de Vida y roles
Ciclo de Vida y roles
 
Mod 6.2 introducción al análisis
Mod 6.2 introducción al análisisMod 6.2 introducción al análisis
Mod 6.2 introducción al análisis
 
Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
 
Solución de problemas y ciclo de vida del desarrollo de software
Solución de problemas y ciclo de vida del desarrollo de softwareSolución de problemas y ciclo de vida del desarrollo de software
Solución de problemas y ciclo de vida del desarrollo de software
 
Importancia de los analistas en sistemas alexis díaz
Importancia de los analistas en sistemas   alexis díazImportancia de los analistas en sistemas   alexis díaz
Importancia de los analistas en sistemas alexis díaz
 
Softagile
SoftagileSoftagile
Softagile
 
Ingeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadIngeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidad
 
Plan
PlanPlan
Plan
 

Plus de Jacqueline Millan

Plus de Jacqueline Millan (6)

Maquiecologico
MaquiecologicoMaquiecologico
Maquiecologico
 
Las Máquinas Simples. Material de apoyo presentado en clases
Las Máquinas Simples.  Material de apoyo presentado en clasesLas Máquinas Simples.  Material de apoyo presentado en clases
Las Máquinas Simples. Material de apoyo presentado en clases
 
Tu recuerdo mamita
Tu recuerdo mamitaTu recuerdo mamita
Tu recuerdo mamita
 
Muestra pendones
Muestra pendonesMuestra pendones
Muestra pendones
 
Tarea de la semana
Tarea de la semanaTarea de la semana
Tarea de la semana
 
Nominado (1)
Nominado (1)Nominado (1)
Nominado (1)
 

Unidad 1 clase 1 y 2

  • 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
  • 4. Perfil del Analista de Sistemas
  • 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
  • 9. Ciclo de vida de un S.I
  • 10. Fases del Ciclo de Vida de un S.I.
  • 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
  • 14. Criterios de calidad de un S.I
  • 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.
  • 35. Conceptos del Diseño Jerarquía de Control
  • 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.