Diseo de sistemas de informacin

El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y

principios con el propsito de definir un dispositivo, un proceso o un Sistema, con
suficientes detalles como para permitir su interpretacin y realizacin fsica
La etapa del diseo del sistema de informacin encierra cuatro etapas:
El diseo de los datos
Trasforma el modelo de dominio de la informacin, creado durante el anlisis,
en las estructuras de datos necesarios para implementar el Software.
El diseo Arquitectnico
Define la relacin entre cada uno de los elementos estructurales del programa.
El diseo de la Interfaz
Describe como se comunica el Software consigo mismo, con los sistemas que
operan junto con l y con los operadores y usuarios que lo emplean.
El diseo de procedimientos
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseo del Software se puede definir en una sola palabra Calidad,
dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la
nica manera de materializar con precisin los requerimientos del cliente.
El Diseo del Software es un proceso y un modelado a la vez. El proceso de
Diseo es un conjunto de pasos repetitivos que permiten al diseador describir
todos los aspectos del Sistema a construir. A lo largo del diseo se evala la
calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el
modelo de anlisis y debe acumular todos los requisitos implcitos que desea el
cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y
los que prueban y mantienen el Software.
El Diseo debe proporcionar una completa idea de lo que es el Software,
enfocando los dominios de datos, funcional y comportamiento desde el punto de
vista de la Implementacin.

Etapas para la elaboracin de un diseo estructurado de un sistema

El mtodo implica la aplicacin de una secuencia de tareas de anlisis,
documentacin y diseo relacionados con lo siguiente.
Etapa 0 - Estudio de viabilidad
Con el fin de determinar si es o no viable un determinado proyecto, tiene que
haber algn tipo de investigacin sobre los objetivos y las implicaciones del
proyecto. Para los proyectos de muy pequea escala esto puede no ser necesario
en absoluto ya que el alcance del proyecto es fcil de entender. En proyectos de
mayor envergadura, la viabilidad se puede hacer, pero en un sentido informal, ya
sea porque no hay tiempo para un estudio formal o porque el proyecto es un
"must-have", y tendr que ser hecho de una manera u otra. Cuando un estudio de
viabilidad se lleva a cabo, hay cuatro reas principales de consideracin:
Tcnica: es el proyecto tcnicamente posible?

Financiera: puede permitirse el negocio para llevar a cabo el proyecto?

Organizacional: ser el nuevo sistema sea compatible con las prcticas

existentes?

tico: es el impacto del nuevo sistema socialmente aceptable?

Para responder a estas preguntas, el estudio de viabilidad es efectivamente una
versin condensada de un anlisis de sistemas totalmente soplado y diseo. Los
requisitos y los usuarios se analizan en cierta medida, algunas opciones de
negocio son elaboradas e incluso algunos detalles de la ejecucin tcnica. El
producto de esta etapa es un documento formal del estudio de factibilidad.
SSADM especifica las secciones que el estudio debe contener incluyendo
cualquier modelos preliminares que se han construido y tambin los detalles de las
opciones de excluidos y los motivos de su rechazo.
Etapa 1 - Investigacin de la situacin actual
Esta es una de las etapas ms importantes de SSADM. Los desarrolladores de
SSADM entendieron que en casi todos los casos hay algn tipo de sistema de
corriente incluso si est compuesta en su totalidad de las personas y de papel. A
travs de una combinacin de entrevistar a los empleados, cuestionarios,
observaciones de circulacin y documentacin existente, el analista llega a la

comprensin completa del sistema, ya que se encuentra al principio del proyecto.

Esto sirve para muchos propsitos:

El analista aprende la terminologa de la empresa, lo que los usuarios

hacen y cmo lo hacen.

El viejo sistema proporciona los requisitos bsicos para el nuevo sistema.

Fallas, errores y reas de ineficiencia se resaltan y sus correcciones se

aaden a los requisitos.

El modelo de datos se puede construir.

Los usuarios se involucran y aprenden las tcnicas y modelos del analista.

Los lmites del sistema se pueden definir.

Para producir los modelos, el analista trabaja a travs de la construccin de los

modelos que hemos descrito. Sin embargo, el primer conjunto de diagramas de
flujo de datos son el modelo fsico actual, es decir, con todos los detalles de cmo
se implementa el sistema antiguo. La versin final es el modelo lgico actual que
es esencialmente la misma que la corriente fsica pero con toda referencia a la
aplicacin eliminada junto con las redundancias como la repeticin de la
informacin que compone los usuarios y los requisitos catlogos.
Etapa 2 - Opciones del sistema de negocios
Tras investigar el sistema actual, el analista debe decidir sobre el diseo
general del nuevo sistema. Para hacer esto, l o ella deben usar las salidas de la
etapa anterior, se desarrolla un conjunto de opciones de negocios del sistema.
Estas son diferentes formas en que el nuevo sistema podra ser producido
variando de no hacer nada para tirar el viejo sistema en su totalidad y la
construccin de uno totalmente nuevo. El analista puede realizar una sesin de
lluvia de ideas para que se generen tantas y diversas ideas como sea posible.
Las ideas se recogen entonces para formar un conjunto de dos o tres opciones
diferentes que se presentan al usuario. Las opciones en cuenta lo siguiente:

El grado de automatizacin

El lmite entre el sistema y los usuarios

La distribucin del sistema, por ejemplo, es centralizada a una oficina o

Hacia fuera a travs de varios?

Costo / beneficio

Impacto del nuevo sistema

Cuando sea necesario, la opcin ser documentada con una estructura de

datos lgica y un diagrama de flujo de datos de nivel 1.
Los usuarios y analista juntos escogen una opcin de negocio nico. Esta
puede ser una de las ya definidas o puede ser una sntesis de los diferentes
aspectos de las opciones existentes. La salida de esta etapa es la opcin
seleccionada de negocios nica, junto con todas las salidas de la etapa de
factibilidad.
Etapa 3 - Requisitos de especificacin
Esta es probablemente la etapa ms compleja en SSADM. Usando los
requisitos desarrollados en la etapa 1 y trabajando en el marco de la opcin de
negocio seleccionado, el analista debe desarrollar una especificacin lgica
completa de lo que el nuevo sistema debe hacer. La especificacin debe estar
libre de error, ambigedad e inconsistencia. Por lgica, nos referimos a que la
especificacin no dice cmo se implementar el sistema, sino que describe lo que
el sistema va a hacer.
Para producir la especificacin lgica, el analista construye los modelos lgicos
necesarios tanto para los diagramas de flujo de datos y el modelo de datos lgicos
que consiste en la estructura lgica de datos (contemplados en otros mtodos
como diagramas entidad relacin ) y una descripcin completa de los datos y sus
relaciones. Estos se utilizan para producir la definicin de funciones de todas las
funciones que los usuarios requieren del sistema, una entidad de vida-Historias
que describen todos los acontecimientos a travs de la vida de una entidad, y el
efecto de Correspondencia Diagramas que describen cmo interacta cada uno
de los eventos con todas las entidades pertinentes. Estos son continuamente
comparan con los requisitos y en caso necesario, se aaden los requisitos para y
completados. El producto de esta etapa es un documento completo con la
especificacin de requisitos que se compone de:

El catlogo de datos actualizada

El catlogo de requisitos actualizado

La especificacin de procesamiento que a su vez se compone de:

Rol de usuario matriz de funciones /

Definiciones de funciones

Modelo lgico de datos requerido

Historias de vida entidad

Diagramas efecto correspondencia

Aunque algunos de estos artculos pueden ser desconocidos para usted, est
ms all del alcance de esta unidad para entrar en ellos con gran detalle.
Etapa 4 - Opciones del sistema Tcnicas
Esta primera etapa es una implementacin fsica del nuevo sistema. Al igual
que las opciones del sistema de negocio, en esta etapa se generan un gran
nmero de opciones para la aplicacin del nuevo sistema. Esto se perfeccion
hasta dos o tres usuario para presentar desde que se elige la opcin o sintetizado
final. Sin embargo, las consideraciones son seres muy diferentes:

Las arquitecturas de hardware

El software a utilizar

El costo de la implementacin

La dotacin de personal necesaria

Las limitaciones fsicas, tales como un espacio ocupado por el sistema

La distribucin incluidas las redes que pueden requerir

El formato general de la interfaz de la computadora humana

Todos estos aspectos deben tambin ajustarse a las restricciones impuestas

por la empresa, como el dinero y la estandarizacin de hardware y software
disponibles.
La salida de esta etapa es una opcin de sistema tcnico elegido.

Etapa 5 - Diseo lgico

Aunque el nivel anterior especifica los detalles de la ejecucin, los resultados
de esta etapa son independientes de la implementacin y se concentran en los
requisitos de la interfaz de la computadora humana. El diseo lgico especifica los
principales mtodos de interaccin en trminos de estructuras de mens y
estructuras de mando.
Un rea de actividad es la definicin de los dilogos de usuario. Estas son las
principales interfaces con que los usuarios podrn interactuar en el sistema. Otras
actividades estn relacionadas con el anlisis de los efectos de actualizacin del
sistema tanto de los acontecimientos en la necesidad de hacer consultas sobre los
datos en el sistema. Ambos utilizan los eventos, descripciones de las funciones y
diagramas efecto correspondencia producidos en la etapa 3 para determinar con
precisin cmo actualizar y leer datos de una manera consistente y segura.
El producto de esta etapa es el diseo lgico que se compone de:

Catlogo de datos

Estructura de datos lgica requerida

Modelo de proceso lgico - incluye dilogos y modelo para los procesos de

actualizacin y consulta

El estrs y momentos de flexin.

Etapa 6 - Diseo fsico

Esta es la etapa final en la que todas las especificaciones lgicas del sistema
se convierten en las descripciones del sistema en trminos de hardware y software
real. Esta es una etapa muy tcnica y un simple resumen se presenta aqu.
La estructura lgica de los datos se convierte en una arquitectura fsica en
trminos de estructuras de base de datos. Se especifica la estructura exacta de
las funciones y la forma en que se implementan. La estructura de datos fsica se
optimiza cuando sea necesario para satisfacer los requisitos de tamao y
rendimiento.
El producto es un diseo fsico completo que podra decirles a los ingenieros de
software la manera de construir el sistema en detalles especficos de hardware y
software y para los estndares apropiados.
Arquitectura de diseo del software.

La arquitectura de diseo del software es un conjunto de patrones que

proporcionan un marco de referencia necesario para guiar la construccin de un
software, permitiendo a los programadores, analistas y todo el conjunto de
desarrolladores del software compartir una misma lnea de trabajo y cubrir todos
los objetivos y restricciones de la aplicacin. Es considerada el nivel ms alto en el
diseo de la arquitectura de un sistema puesto que establecen la estructura,
funcionamiento e interaccin entre las partes del software.

Componentes
La arquitectura de software se compone por:

Clientes y servidores.

Bases de datos.

Niveles en sistemas jerrquico.

Interacciones
Entre los componentes de la arquitectura de software existe un conjunto de
interacciones entre las que sobresalen:

Llamadas a procedimientos.

Comportamiento de variables.

Protocolos cliente servidor.

Transmisin asncrona de eventos.

Caractersticas
La arquitectura de software forma la columna vertebral para construir un
sistema de software, es en gran medida responsable de permitir o no ciertos
atributos de calidad del sistema entre los que se destacan la confiabilidad y el
rendimiento del software. Adems es un modelo abstracto reutilizable [1] que puede
transferirse de un sistema a otro y que representa un medio de comunicacin y
discusin entre participantes del proyecto, permitiendo as la interaccin e
intercambio entre los desarrolladores con el objetivo final de establecer el
intercambio de conocimientos y puntos de vista entre ellos.

Tipos de arquitecturas
Para utilizar la arquitectura de software se sigue un conjunto de patrones
arquitectnicos, entre los cuales podemos encontrar:

Cliente-Servidor

Blackboard.

Modelo entre capas.

Intrprete.

Orientado a servicios.

Niveles de un diseos de software

El diseo de software tiene varios niveles los cuales estn relacionados entre
s, cada nivel tiene sus propios problemas, tcnicas de anlisis y componentes los
que pueden ser simples o complejos, reglas de composicin las cuales permiten
construir componentes complejos.
Modelos de la arquitectura de software
La arquitectura de software cuenta con varios modelos, ellos son:
Modelos estructurales
Son similares a la vista estructural, pero su nfasis primario radica en la
(usualmente una sola) estructura coherente del sistema completo, en vez de
concentrarse en su composicin. Los modelos de framework a menudo se refieren
a dominios o clases de problemas especficos. El trabajo que ejemplifica esta
variante incluye arquitecturas de software especficas de dominios, como CORBA,
o modelos basados en CORBA, o repositorios de componentes especficos, como
PRISM.
Modelos dinmicos
Enfatizan la cualidad conductual de los sistemas, Dinmico puede referirse a
los cambios en la configuracin del sistema, o a la dinmica involucrada en el
progreso de la computacin, tales como valores cambiantes de datos.

Modelos de proceso
Se concentran en la construccin de la arquitectura, y en los pasos o procesos
involucrados en esa construccin. En esta perspectiva, la arquitectura es el
resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con
el actual trabajo sobre programacin de procesos para derivar arquitecturas.