Análisis y diseño de sistemas
En la actualidad
la mayoría de los usuarios de microcomputadoras tienen acceso a un sistema de
información o forman parte del mismo. Todas las organizaciones cuentan con un
sistema de información de algún tipo, que sus empleados deben utilizar. Cuando
en cualquier organización se desea implantar un nuevo sistema, de tal forma que
sus miembros sean más productivos, obteniendo un mayor provecho y apoyo del
mismo, se requiere realizar una serie de acciones y previsiones.
El análisis y
diseño de sistemas es un procedimiento para la resolución de problemas. Cuando
se trata del diseño de sistemas de información, busca analizar sistemáticamente
la entrada o flujo de datos, la transformación de los datos, el almacenamiento
de datos y la salida de información en el contexto de una organización
particular. También es usado para analizar, diseñar e implementar mejoras que
puedan incorporarse a la organización y puedan ser alcanzadas al usar un
sistema de información computarizado.
Este
procedimiento se lleva a cabo, en el llamado ciclo de vida de desarrollo de
sistemas, el cual consta de seis pasos que permiten el diagnóstico y
optimización de un sistema de información. Este ciclo puede repetirse
indefinidamente, porque como ya se señaló, las organizaciones siempre se ven
sometidas a cambios, y sus sistemas deben renovarse periódicamente. Los pasos
del ciclo de vida de desarrollo son los que se encuentran en la imagen. Se
suele llamar analistas de sistemas a quienes se encargan de realizar en las
empresas, el proceso de análisis y diseño de sistemas, definiendo los
lineamientos a seguir y la manera en que debe incorporarse la tecnología de la
computación para adecuar y actualizar sus sistemas de información.
Explicacion de un sistema de informacion
La carta estructurada
La carta estructurada tambien es conocida como el modelo de
producto, es una metodologiá de análisis y diseño de sistemas de análisis
estructurado, lo que muestra es un mapa de diseño de arriba hacia abajo
(top-down) de tipo jerárquico en el que se asienta cómo será programado el
proyecto, construido, integrado y probado.
Hay una herramienta CASE que se llama Visible Analyst y te permite modelar análisis estructurado y orientado a objetos.
El diseño modular te permite asentar "los módulos" en los que estará dividida tu aplicación, digamos que ordenas tus módulos de manera que puedas "dividir el trabajo". Por ejemplo, si vas a hacer un sistema administrativo para una empresa a lo mejor tienes tus módulos de nómina, personal, inventario, compras, ventas, etc por decir algo. A lo mejor tu cliente necesita urgentemente primero la nómina; entonces es necesario que hagas el diseño de los módulos de todo el sistema para que desde el principio se tome en cuenta su crecimiento, o para dividir en equipos de trabajo que desarrollen los módulos por separado y pueda existir comunicación, estén acordes los datos, entradas con salidas, etc.
Hay una herramienta CASE que se llama Visible Analyst y te permite modelar análisis estructurado y orientado a objetos.
El diseño modular te permite asentar "los módulos" en los que estará dividida tu aplicación, digamos que ordenas tus módulos de manera que puedas "dividir el trabajo". Por ejemplo, si vas a hacer un sistema administrativo para una empresa a lo mejor tienes tus módulos de nómina, personal, inventario, compras, ventas, etc por decir algo. A lo mejor tu cliente necesita urgentemente primero la nómina; entonces es necesario que hagas el diseño de los módulos de todo el sistema para que desde el principio se tome en cuenta su crecimiento, o para dividir en equipos de trabajo que desarrollen los módulos por separado y pueda existir comunicación, estén acordes los datos, entradas con salidas, etc.
Factibilidad
Se refiere a la disponibilidad de los
recursos necesarios para llevar a cabo los objetivos o metas señaladas.
Generalmente la factibilidad se determina sobre un proyecto.
(estudio de factibilidad). El estudio de
factibilidad, es una de las primeras etapas del desarrollo de un sistema
informático. El estudio incluye los objetivos, alcances y restricciones sobre
el sistema, además de un modelo lógico de alto nivel del sistema actual (si
existe). A partir de esto, se crean soluciones alternativas para el nuevo
sistema, analizando para cada una de éstas, diferentes tipos de factibilidades.
Los tipos de factibilidades básicamente
son:
- Factibilidad técnica: si existe o está al alcance la tecnología necesaria para el sistema.
- Factibilidad económica: relación beneficio costo.
- Factibilidad operacional u organizacional: si el sistema puede funcionar en la organización.
Para cada solución factible, se presenta
una planificación preliminar de su implementación.
Estos resultados se entregan a la
gerencia, quienes son los que aprueban la realización del sistema informático.
El estudio de factibilidad, es una tarea
que suele estar organizada y realizada por los analistas de sistemas. El
estudio consume aproximadamente entre un 5% y un 10% del costo estimado total
del proyecto, y el período de elaboración del mismo varía dependiendo del
tamaño y tipo de sistema a desarrollar.
Ciclo de vida
tradicional de los sistemas de software
En
ingeniería de software, la descripción tradicional del ciclo de vida del
software está basada en un modelo conocido como el modelo de cascada (waterfall
model). Inicialmente el modelo planteaba la discretización de las
actividades involucradas en el desarrollo de software y las presentaba como una
serie lineal de tareas, donde cada tarea debía ser completada antes de comenzar
la siguiente.
Ciclo de vida tradicional
Frente
al hecho de que en la realidad no es posible lograr este grado de completitud,
posteriores variaciones del modelo reconocen la necesidad de iterar a través de
las diferentas etapas
Modelo de cascada a nivel detallado
Se
comienza con la definición del problema y se identifican los requerimientos de
los usuarios actuales y futuros, usualmente por medio de preguntas, discución
con expertos en el área, etc.. Dependiendo de la importancia y volumen del
sistema esta fase puede incluir un estudio de factibilidad/viabilidad. A partir
de esto se escriben siendos
Documentos
con las especificaciones de requerimientos del usuario y con las
especificaciones de requerimientos de la aplicación. La especificación de
requerimientos del usuario se escribe en el lenguaje de los usuarios, lo que
permite establecer un acuerdo sobre esta especificación entre los usuarios del
sistema y los ingenieros del sistema. La especificación de requerimientos de la
aplicación se escribe en el lenguaje de los programadores y establece en forma
precisa los detalles del sistema. Estas actividades comprenden el análisis del
espacio del problema (qué). A medida que avanzamos en el diagrama pasamos del
análisis al diseño del sistema, esto es, del espacio del problema al espacio de
la solución.
La
etapa de diseño es la que está definida en forma más imprecisa, quizás porque
es un proceso creativo, no mecánico, donde se hace una descomposición cada más
detallada y progresiva del sistema. El diseño de sistemas es generalmente
referido como "diseño global" o "diseño lógico" y el diseño
del programa como "diseño detallado" o "diseño físico". En
el ciclo de vida tradicional estas dos actividades de diseño pueden llegar a
traslaparse y ser realizadas en forma iterativa. En el ciclo de vida orientado
por objetos la diferenciación desaparece casi totalmente.
El
ciclo de vida del software, tal como se ha descrito en los párrafos anteriores,
es frecuentemente implementado basándose en una visión del mundo interpretada
en términos de descomposición funcional,
donde la pregunta fundamental a responder mediante las etapas de análisis y
diseño es qué hace el
sistema, esto es, cuál es su función. De esta manera, el diseño funcional (y
las técnicas de descomposición funcional utilizadas para llevarlo a cabo) está
basado en una interpretación funcional del espacio del problema y su traducción
al espacio de la solución como un grupo de procedimientos interrelacionados. El
sistema final es visto entonces como un conjunto de funciones que operan sobre
los datos, aparentemente secundarios.
La
descomposición funcional es también una metodología de análisis y diseño
arriba-abajo (top-down) y es, en consecuencia, demasiado restrictiva
para dar soporte al diseño de las aplicaciones contemporáneas. Meyer [Meyer]
resume las desventajas de la metodología de diseño arriba-abajo de la siguiente
forma:
1.
La metodología arriba-abajo no tiene en cuenta el carácter evolutivo de los
sistemas (i.e. cambio en las especificaciones, extensión, ...).
2.
En la metodología arriba-abajo el sistema está caracterizado por una sola
función, un concepto cuestionable.
3.
En la metodología arriba-abajo el punto de vista es basicamente funcional y por
lo tanto las estructuras de datos que el sistema manipula son dejadas en un
plano secundario.
4.
La metodología arriba-abajo no promueve la reutilización. (!)
Hemos
hecho una revisión del enfoque tradicional del ciclo de vida del software, una
metodología basicamente funcional. Ahora haremos una breve descripción de las
tres opciones principales para el análisis y diseño de sistemas.
Descomposición Funcional
La descomposición funcional se refiere
ampliamente al proceso de resolucion de una relacion funcional en sus partes
constituyentes, de tal manera que la funcion original se puede reconstruir (es
decir, recompuestos) de las partes en funcion de la composición. En general,
este proceso de descomposición se lleva a cabo ya sea con el fin de hacerse una
idea de la identidad de los elementos constitutivos (que pueden reflejar los procesos
individuales de fisica de interes, por ejemplo), o con el fin de obtener una representación
comprimida de la funcion global, una tarea que solo es posible cuando los
procesos constituvios poseen un cierto nivel de modularidad (es decir, la
independencia o no de interaccion).
Desarrollo Estructurado de Jackson
La
Programación Estructurada de
Jackson (Jackson Structured Programming) y el Desarrollo Estructurado de
Jackson (JSD, Jackson Structured Development) [Jackson] son técnicas que
modelan el mundo real con un efoque parcialmente orientado por objetos, donde
se utilizan métodos basados en las estructuras de datos. Sin embargo, son
esencialmente metodologías de descomposición funcional [Sommerville, p.185] en
donde las estructuras de datos son utilizadas como soporte a esta
descomposición. A diferencia de la descomposición funcional en donde las
estructuras de datos están fundamentalmente determinadas por la estructura
funcional, se puede decir que JSD es una metodología parcialmente orientada por
objetos o de centro-afuera (middle-out), que hace menos énfasis en la
parte funcional y comienza el análisis del sistema como un proceso de
modelamiento.
Desarrollo Orientado por Objetos
El
paradigma Orientado por Objetos (OO) utiliza los mismos componentes de los
sistemas de software: datos y procedimientos. Sin embargo, desenfatiza los
procedimientos y hace énfasis en el encapsulamiento de datos y procedimientos
en entidades con una interfaz claramente definida. En la descomposición de
sistemas basada en un enfoque OO, el sistema es visto como una colección de
entidades (objetos) que encapsulan cierto conocimiento (datos) y cierto comportamiento
(procedimientos), y que interactúan para realizar la tarea o tareas del caso.
Las etapas de análisis y diseño se llevan a cabo con base en estos objetos y en
los servicios que éstos prestan, utilizando un modelo cliente-servidor donde
los objetos interactúan por medio de mensajes. El uso de este modelo
cliente-servidor hace que el sistema sea descrito como 'orientado a
responsabilidades' (responsibilty-driven). El diseño detallado,
incluyendo la implementación de procedimientos y definición de estructuras de
datos, se difiere hasta una etapa más avanzada del proceso de desarrollo y es
privada a cada clase de objetos, adhiriendo estrictamente al concepto de
ocultamiento de información. De esta forma los procedimientos y estructuras de
datos no quedan 'congelados' desde las primeras etapas del diseño, cuando
todavía no se tiene un conocimiento profundo del sistema. Un sistema
representado en función de objetos es por lo tanto más flexible y la vez menos
sensible a los cambios estructurales. Es importante que las estructuras de
datos no sean especificadas muy temprano en el proceso de diseño. En
consecuencia el desarrollo orientado por objetos se centra en la abstracción de
datos en vez de fijar una estructura determinada en la especificación de los
objetos que componen el sistema.
Diagrama funcional
Un diagrama funcional es una
representación gráfica o dibujo de figuras geométricas que sirve para mostrar
el funcionamiento de, ya sea, una institución, empresa, equipo, club o una
máquina o teoría científica.
el diagrama muestra el conjunto en su totalidad, sus figuras geométricas por lo general están escritas dentro con una letra, nombre o número que las identifica y distingue de las demás.las figuras van acompañadas de líneasque unen a una con otras demostrando así los pasos que envuelven el funcionamiento del objeto que representan. la mayoría de las veces va acompañado con una leyenda o explicación debajo del dibujo, otras veces las explicaciones esttán contenidas dentro de las figuras geométricas.estos diagramas funcionales son muy utilizados en centros educativos.
el diagrama muestra el conjunto en su totalidad, sus figuras geométricas por lo general están escritas dentro con una letra, nombre o número que las identifica y distingue de las demás.las figuras van acompañadas de líneasque unen a una con otras demostrando así los pasos que envuelven el funcionamiento del objeto que representan. la mayoría de las veces va acompañado con una leyenda o explicación debajo del dibujo, otras veces las explicaciones esttán contenidas dentro de las figuras geométricas.estos diagramas funcionales son muy utilizados en centros educativos.
Diagrama de árbol
El diagrama de árbol es una representación gráfica de los posibles resultados del experimento, el cual consta una serie de pasos, donde cada uno de los pasos tiene un número finito de maneras de ser llevado a cabo. Se utiliza en los problemas de conteo y probabilidad.
Para la construcción de un diagrama en árbol se partirá poniendo una rama para cada una de las posibilidades, acompañada de su probabilidad. Cada una de estas ramas se conoce como rama de primera generación.
En el final de cada rama de primera generación se constituye a su vez, un nudo del cual parten nuevas ramas conocidas como ramas de segunda generación, según las posibilidades del siguiente paso, salvo si el nudo representa un posible final del experimento (nudo final).
Hay que tener en cuenta que la construcción de un árbol no depende de tener el mismo número de ramas de segunda generación que salen de cada rama de primera generación y que la suma de probabilidades de las ramas de cada nudo ha de dar 1.
Existe un principio sencillo de los diagramas de árbol que hace que éstos sean mucho más útiles para los cálculos rápidos de probabilidad: multiplicamos las probabilidades si se trata de ramas adyacentes (contiguas), el ejemplo de alumna de la primera facultad, o bien las sumamos si se trata de ramas separadas que emergen de un mismo punto, el ejemplo de encontrar un alumno.
Explicacion del diagrama de arbol
Diccionario de datos
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
