Академический Документы
Профессиональный Документы
Культура Документы
2 Elementos de un Sistema
James Grier Miller en su libro Living System destaca 19 subsistemas críticos de todos
los sistemas vivientes, haciendo una analogía con los mismos se pueden categorizar de
la manera siguiente:
El motor, que mueve el sistema o a sus partes en relación con todo o parte del
medio ambiente, o bien que mueve a los componentes del ambiente.
El canal y la red, que están compuestos por una sola ruta en el espacio físico,
o bien por múltiples rutas interconectadas, mediante las cuales las señales
portadoras de información se transmiten a todas partes del sistema.
• Sistemas naturales.
• Sistemas hechos por el hombre.
En lo que respecta a los sistemas hechos por el hombre existen una gran diversidad de
sistemas construidos, organizados y mantenidos por humanos, tales como: sistemas
sociales, sistemas de transporte, sistemas de comunicación, Sistemas de manufactura,
sistemas financieros.
Los sistemas automatizados son sistemas hechos por el hombre que interactuan con o
son controlados por una o más computadoras. Aunque hay diferentes tipos de sistemas
automatizados, todos tienden a tener componentes en común:
Existen algunos principios generales que son de interés particular para quienes crean
sistemas automatizados de información, e incluyen los siguientes:
En el modelo clásico, cada proyecto atraviesa por algún tipo de análisis, diseño e
implantación, aunque no se haga exactamente como se muestra en la figura 2.1.1(a) El
ciclo de vida de proyecto utilizado, pudiera diferir del que se muestra en la figura
2.1.1(a) en una o todas de las formas siguientes:
El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida
de los proyectos clásicos. Como se podrá ver en la figura 2.1, se espera que los
programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del
subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se
conoce como el ciclo de vida de cascada. .
En general con este enfoque de desarrollo de sistemas los diseñadores tenían poco
contacto con el analista que escribía la especificación y definitivamente "no tenía
contacto con el usuario".
2.3 Modelo Estructurado.
En el modelo estructurado se examinan brevemente las nueve actividades y los tres
terminadores que lo componen, como se muestra en la figura 2.3.1. Los terminadores
son los usuarios, los administradores, y el personal de operaciones. Los cuales se tratan
de individuos o grupos que proporcionan la entrada al equipo del proyecto, y son los
beneficiados finales del sistema.
Actividad 1: La encuesta
En general, la encuesta ocupa sólo del 5 al 10 por ciento del tiempo y los recursos de
todo el proyecto, y para los proyectos pequeños y sencillos pudiera ni siquiera ser una
actividad formal. A pesar de todo lo anterior, es una actividad importante debido a que
la administración pudiera decidir cancelar el proyecto si no parece atractivo desde el
punto de vista de costo-beneficio.
Actividad 3: El diseño
Actividad 4: Implantación
Esta actividad implica la generación de una descripción formal de las partes del sistema
que se harán en forma manual, lo mismo que la descripción de como interactuarán los
usuarios con la parte automatizada del nuevo sistema. El resultado de la actividad 7 es
un manual para el usuario.
Actividad 9: Instalación
En esta actividad sus entradas son el manual del usuario producido en la actividad 7, la
base de datos convertida que se creó con la actividad 8 y el sistema aceptado producido
por la actividad 6. En algunos casos la instalación pudiera significar simplemente un
cambio de la noche a la mañana al nuevo sistema; en otros casos, la instalación pudiera
ser un proceso gradual, en el que un grupo tras otro de usuario van recibiendo manuales
y entrenamiento y comenzado a usar el nuevo sistema.
2.4 Modelo Espiral.
El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las
mejores características tanto del ciclo de vida clásico, como de la creación de
prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El
modelo representado mediante la espiral de la figura 2.4, define cuatro actividades
principales:
Dentro del enfoque de prototipos se pretende que el modelo sea operante, es decir, una
colección de programas de computadora que simulan algunas o todas las funciones que
el usuario desea. Para lograr lo anterior se utilizan las siguientes herramientas de
software:
Este modelo concluye con una fase de diseño. Con el cual se tiene la intención de que se
modelen los requerimientos del usuario.
El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para
satisfacer los requerimientos del usuario, diciendo lo mínimo posible acerca de como se
implanta.
Específicamente, esto significa que cuando el analista habla con el usuario acerca de los
requerimientos del sistema, debe evitar describir implantaciones especificas de procesos
(burbujas en un diagrama de flujo de datos) en el sistema; es decir, no debe mostrar las
funciones del sistema que están siendo realizadas por humanos o por sistemas de
computo existentes. Como lo ilustran las figuras 3.1.1(a), ésta opción arbitrarias de
cómo podría implantarse el sistema; pero esta decisión debería retrasarse hasta que haya
comenzado la actividad de diseño.
Figuras: 3.1.1(a):Modelo que muestra como hará su labor una función
La figura 3.1.1(b) muestra un modelo esencial más apropiado de lo que la función del
sistema debe realizar sin importar su implantación final.
Lo mismo se da para los flujos y almacenes de datos: el modelo esencial debe describir
el contenido de los flujos o almacenes de datos, sin describir el medio (por ejemplo,
disco o cinta) u organización física de los datos.
Así, el primer modelo importante que se debe desarrollar como analista es uno que no
haga más que definir las interfaces entre el sistema y el resto del universo, es decir, el
ambiente. Por razones obvias, este modelo se conoce como el modelo ambiental. Por lo
tanto, se necesita saber qué información entra al sistema desde el ambiente exterior, y
qué información produce como salida al ambiente externo.
Otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos
que ocurren en el ambiente al cual debe responder el sistema. No para todos los
acontecimientos; después de todo, el ambiente en su totalidad genera un número infinito
de acontecimientos. Sólo nos preocupan aquellos que (1) ocurren en el ambiente
exterior y (2) requieren una respuesta del sistema.
En un sistema grande se puede tomar en cuenta una cantidad de factores cuando se están
escogiendo las perspectivas del proyecto. Entre los más importantes están los
siguientes:
Deseo del usuario por minimizar gastos operativos de alguna área de su negocio. La
mayor parte de las organizaciones que han tenido computadoras instaladas durante 10
años o más ya aprovecharon las oportunidades obvias de reducir el personal de oficina.
Deseo del usuario para lograr alguna ventaja estratégica para la línea de productos o
áreas de negocios que opera. Un buen ejemplo de estos son las líneas aéreas donde
mejor información acerca de tendencias del mercado y preferencias de los clientes
pueden llevar a costos de pasajes e itinerarios de aerolíneas más eficientes.
Obsérvese que cada acontecimiento se etiqueta como F,T,C. Con ello se muestra si es
de tipo de flujo, temporal, o de control. El orientado a flujos es el que se asocia con un
flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento
cuando llega algún dato (o posiblemente varios). Los acontecimientos temporales
arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos de
acontecimientos temporales pudieran ser:
A las 9:00 de la mañana se requiere un reporte diario de todos los pedidos de libros.
La parte más fácil del diagrama de contexto es el proceso; como hemos visto, consiste
en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema
completo o un acrónimo convenido. En la figuras 3.2.2 se muestra un ejemplo.
<>
Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen
del sistema, además de las señales de control que recibe o genera. Los flujos de datos se
incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el
ambiente al que deba responder el sistema, o si se ocupan (como datos) para producir
una respuesta.
Mas bien, sea el flujo de datos de entrada mediante el cual el sistema se da cuenta de
que ha ocurrido el acontecimiento. Un nombre más apropiado para el acontecimiento
sería:
Puesto que los terminadores están por definición fuera de las fronteras del intento de
construcción de sistema representado por el modelo, los realizadores no pueden
modificar la tecnología de los terminadores para mejorar su confiabilidad. En lugar de
ello, deben construir respuestas para los problemas de los terminadores en el modelo
esencial del sistema. Un enfoque útil para modelar respuestas a los problemas de
terminadores es construir una lista de acontecimientos "normales" y luego preguntar,
para cada acontecimiento, "¿Necesita el sistema responder si este acontecimiento deja
de ocurrir como se espera?.
Por ejemplo, nuestra lista de acontecimiento para el Sistema de Pedido de Libros Ajax
incluía un acontecimiento llamado "el pedido de reimpresión de libro llega a la bodega".
Pero ¿Qué tal si no llega a tiempo (por ejemplo, una semana después de la fecha
prometida por el impresor)? ¿Qué debería hacer el sistema?, Por lo que se necesitaría un
acontecimiento adicional iniciado por el sistema para hacer que se comunique con el
impresor y localice el origen del retraso.
En muchos casos el acontecimiento está determinado por el flujo; esto significa que el
sistema detecta la ocurrencia de un acontecimiento por la llegada de algún dato de un
terminador externo, esto es, se pueden requerir entradas adicionales (de otros
terminadores, y de almacenes de datos) para que un proceso produzca su salida
requerida.
De manera similar, como parte de la respuesta dibuje las salidas adecuadas producidas
por el proceso. En muchos casos, esto implicar devolver salidas a los terminadores
fuera del sistema; sin embargo, puede también involucrar salidas que se envían a los
almacenes de datos, para ser usadas como entradas de otros procesos.
Existen dos casos especiales: (1) acontecimientos únicos que causan respuestas
múltiples y, (2) acontecimientos múltiples que causan la misma respuesta. En el primer
caso, un solo acontecimiento puede causar múltiples respuestas, cada una de las cuales
se modela con su propia burbuja en el DFD preliminar.Sólo es apropiado si todas las
respuestas usan el mismo flujo de datos de entrada, y sólo si todas las respuestas son
independientes entre sí.
De manera inversa, habrá situaciones ocasionales en las que un proceso se asocia con
más de un acontecimiento.Es válido y apropiado sólo si la respuesta de la burbuja es
idéntica para los diversos acontecimientos, y sólo si los datos de entrada y salida son
idénticos para las diversas respuestas a acontecimientos.
Como analista, puede no sentir interés por los detalles del diseño de sistemas o de
programas; sin embargo, la labor de analista y la del diseñador no siempre se pueden
separar debido a que, el analista debe asegurarse de entender los requerimientos del
usuario, mientras que el diseñador debe asegurar que dichos requerimientos se puedan
implantar de manera realista con la tecnología computacional actual.
Existe otra razón para tener interés en el diseño de sistemas: tal vez le toque hacerlo.
Sobre todo en los sistemas pequeños y medianos, a menudo se espera que el mismo
individuo documente los requerimientos del usuario y además desarrolle el diseño.
Así como se deben asignar procesos a los componentes apropiados de hardware, los
almacenes de datos se deben igualmente asignar. El diseñador debe de decidir si un
almacén se realizará como base de datos en el procesador 1 o el 2. Dado que la mayor
parte de los almacenes se comparten entre muchos procesos, también debe decidir si se
deben asignar copias del almacén a diferentes procesadores.
En el nivel del modelo de tarea, el diseñador debe, procesador por procesador, asignar
procesos y almacenes a las tareas individuales de cada uno.
Obsérvese que los procesos dentro de un mismo procesador pueden tener necesidad de
comunicarse mediante alguna forma de protocolo de comunicación entre tareas. El
mecanismo para hacerlo varía de un proveedor a otro, pero casi siempre se realiza
através del sistema operativo del proveedor.
3.6 Programación.
La programación comienza cuando termina la actividad de diseño. En esta fase se
involucra la escritura de instrucciones en C++, Pascal, o algún otro lenguaje de
programación para implantar lo que el analista ha especificado y el diseñador ha
organizado en módulos.
3.7 Prueba.
En muchos casos, el analista trabaja de manera cercana con el usuario para desarrollar
un conjunto eficaz y de gran alcance de casos de prueba basados en el modelo esencial y
el modelo de implantación del usuario. Este proceso puede llevarse a cabo en paralelo
con las actividades de implantación del diseño y de la programación, para que, cuando
los programadores terminen de escribir sus programas y de realizar sus propias pruebas
locales, el equipo del analista/usuario esté listo con sus propios casos de prueba.
Existen distintas estrategias de prueba, las dos más comunes se conocen como prueba
ascendente y descendente. El enfoque ascendente empieza por probar módulos
individuales separadamente (prueba de módulos). Luego, los módulos individuales se
combinan para forma unidades que se probaran en masas (pruebas de subsistemas).
Finalmente, todos los componentes del sistema se combinan para probarse (prueba del
sistema).
Para poder realizar una excelente prueba se necesita de tres cosas: un plan de prueba,
descripciones de pruebas y procedimiento de prueba. Un plan de prueba es un
documento organizado que describe las actividades de prueba. Un documento de
planeación de pruebas típico contendrá la siguiente información:
Es importante tener en mente: los DFD no sólo se pueden utilizar para modelar sistemas
de sistemas de proceso de información, sino también como manera de modelar
organizaciones enteras, es decir, como una herramienta para la planeación estratégica y
de negocios.
• Proceso.
• Flujo.
• Almacén.
• Terminador.
Proceso.
El primer componente del DFD se conoce como proceso. Los sinónimos comunes son
burbuja, función, transformación. El proceso muestra una parte del sistema que
transforma entradas en salidas. El proceso se representa gráficamente como un círculo,
como se muestra en figura 4.1.1(a). Algunos analistas prefieren usar un óvalo o un
rectángulo con esquinas redondeadas, como se muestra en la figura 4.1.1(b). Y otros
prefieren usar un rectángulo, como se muestra en la figura 4.1(c). Las diferencias entre
estas tres formas son puramente cosméticas, aunque obviamente es importante usar la
misma forma de manera consistente para representar todas las funciones de un sistema.
Nótese que el proceso se nombra o describe con una sola palabra, frase u oración
sencilla. Un buen nombre para un proceso generalmente consiste en una frase verbo-
objeto tal como validar entradas o calcular impuesto. En algunos casos, el proceso
contendrá el nombre de una persona o un grupo (por ejemplo, un departamento o una
división de una organización), o de una computadora o un aparato mecánico.
Flujo.
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un
proceso; un ejemplo se muestra en la figura 4.1.2. El flujo se usa para describir el
movimiento de bloques o paquetes de información de una parte del sistema a otra.
En la mayoría de los sistemas que modele como analista, los flujos realmente
representan datos, es decir, bits, caracteres, mensajes, números de punto flotante y los
diversos tipos de información con los que las computadoras pueden tratar.
Nótese que el flujo de la figura 4.1.2 tiene nombre. El nombre representa el significado
del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo
lleva un tipo de paquete, como lo indica su nombre.
Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o
posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia
adentro o hacia fuera de un proceso (o ambas cosas). El flujo que se muestra en la figura
4.1.4(a) por ejemplo, indica claramente que el número se está mandando hacia el
proceso denominado Validar números telefónicos. Y el flujo denominado honorarios de
entrega de choferes de la figura 4.1.4 (b) claramente indica que es una salida generada
por el proceso Generar honorarios de entrega de choferes. Los datos que se mueven a lo
largo de dicho flujo viajarán ya sea a otro proceso (como entrada) o a un almacén o a un
terminador. El flujo de dos cabezas que se muestra en la figura 4.1.4 (c) es un diálogo,
es decir, un empacado conveniente de dos paquetes de datos (una pregunta y una
respuesta) el mismo flujo. En el caso de un diálogo, los paquetes de cada extremo de la
flecha deben nombrarse, como se ilustra en la figura 4.1.4 (c).
Almacén.
Terminador.
Existen tres cosas importantes que debemos recordar acerca de los terminadores:
Además de la regla básica que existen para la elaboración de DFD tal como, los
componentes básicos de DFD son: proceso(burbuja) flujo, almacenes y terminadores.
Existen otras reglas adicionales que nos permitirán no elaborar DFD erróneos y gratos a
la vista de los usuarios.
Un proceso en un DFD puede representar una función que se está llevando a cabo, o
pudiera indicar cómo se está llevando a cabo, identificando a la persona, grupo o
mecanismo involucrado.
Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un
objeto. Es decir, escoja un verbo activo (un verbo transitivo que tenga objeto) y un
objeto apropiado para formar una frase descriptiva para el proceso. Los siguientes son
ejemplos de nombres de procesos:
Los nombres de los procesos (al igual que los nombres de flujos y de terminadores)
deben provenir de un vocabulario que tenga algún significado para el usuario.
Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas
numeran cada burbuja. No importa mucho como sea haga esto, de izquierda a derecha,
de arriba abajo o de cualquier otra manera servirá, mientras haya constancia en la forma
de aplicar los números.
La única cosa que se debe tener en mente es que el sistema de numeración implicará,
para algunos lectores casuales de su DFD, una cierta secuencia de ejecución. Esto es,
cuando se muestre el DFD a un usuario, él pudiera preguntar: ¿Acaso la burbuja número
1 sucede primero, luego la 2 y luego la 3?. Y esto no es así en absoluto. El modelo de
DFD es una red de procesos asincrónicos que se intercomunican, lo cual es, de hecho,
una representación precisa de la manera en la que en realidad muchos sistemas operan.
El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a
cabo un sistema y las interacciones entre ellas. Pero otro propósito del DFD es ser leído
y comprendido, no sólo por el analista que construyó el modelo, sino por los usuarios
que sean los expertos en la materia de aplicación.
Existe una regla principal para la elaboración de un DFD, que se debe tener en mente:
no cree un DFD con demasiados procesos, flujos, almacenes y terminadores. En la
mayoría de los casos, esto significa que no debería haber más de media docena de
procesos y almacenes, flujos y terminadores relacionados en un solo diagrama.
Existe una excepción importante a esto, un diagrama especial conocido como diagrama
de contexto, que representa el sistema entero como un solo proceso y destaca las
interfaces entre el sistema y los terminadores externos.
Para los sistemas de tiempo real necesitamos alguna manera de modelar flujos de
control (es decir señales o interrupciones). Y se requiere una manera de mostrar
procesos de control (esto es, burbujas cuya única labor es coordinar y sincronizar las
actividades de otras burbujas del DFD). Se muestran gráficamente con líneas punteadas
en el DFD.
Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones
entre almacenes de datos en el DFD que de otra forma se hubiera visto sólo en la
especificación de procesos. Por ejemplo, un DER típico se muestra en la figura 4.2.1
Cada una de las cajas rectangulares corresponden a un almacén de datos en DFD y
puede verse que hay relaciones que normalmente no se aprecian en un DFD.
1. Tipos de objetos.
2. Relaciones.
3. Indicadores asociativos de tipo de objeto.
4. Indicadores de supertipo/subtipo.
Tipos de objetos
• Cada una puede identificarse de manera única por algún medio. Por ejemplo, si
se tiene un tipo de objeto conocido como cliente, debemos ser capaces de
distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su
número de Seguro Social).
� Cada uno juega un papel necesario en el sistema que se construye. Es decir, para que
el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin
tener acceso a esos miembros.
� Cada uno puede describirse por uno o más datos. Es decir, un cliente puede
describirse por medio de datos tales como nombre, domicilio, límite de crédito y
número telefónico.
En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación
del sistema de algo material del mundo real. Esto significa que los clientes, artículos de
inventario, empleados, partes manufacturadas, etc., son objetos típicos. El objeto es algo
material del mundo real, y el tipo de objeto es su representación en el sistema. Sin
embargo, un objeto pudiera ser algo no material: por ejemplo, horarios, planes,
estándares, estratégias y mapas.
Una persona (o cualquier cosa material) pudiera ser diversos tipos de objetos distintos
en distintos modelos de datos, o incluso en un mismo modelo. Juan Pérez, por ejemplo
puede ser empleado en un modelo de datos y cliente en otro. También pudiera ser
empleado y cliente dentro del mismo modelo.
Relaciones
Cada instancia de la relación representa una asociación entre cero o más ocurrencias de
un objeto y cero o más ocurrencias del otro. Así, en la figura 4.2.3, la relación
etiquetada como compras puede contener las siguientes instancias individuales:
El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier
dirección. Y no muestran cardinalidad, es decir, no muestran el número de objetos que
participan en la relación.
Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad
como la ordinalidad.
El indicador asociativo de tipo de objeto representa algo que funciona como objeto y
como relación. Por ejemplo, un cliente que adquiere un artículo. En donde la relación de
compra no hace más que asociar un cliente con uno o más artículos. Pero suponga que
existen datos que deseamos recordar acerca de cada instancia de una compra (por
ejemplo a qué hora del día se hizo). ¿Dónde se podría almacenar dicha información?
"Hora del día" no es un atributo de cliente, ni de artículo. Más bien, se asocia "Hora del
día" con la compra misma, y esto se muestra en un diagrama como el que ilustra la
figura 4.2.5.
Nótese que compra ahora se escribe dentro de una caja rectangular conectada por medio
de líneas dirigidas, a un rombo de relación sin nombre. Esto pretende indicar que
compra funciona como:
Existe un número de situaciones en las que los refinamientos del DER llevan a la
eliminación de tipos de objetos y relaciones redundantes o erróneas. Las más comunes
son:
4. Relaciones derivadas.
4.3 Diagramas de transición de estados.
El diagrama de transición de estado (también conocido como DTE) enfatiza el
comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo
importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como
ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutación
telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando
militares.
Cambios de estado.
Lo que identifica al estado 1 de la figura 4.3.3 como inicial es la flecha "desnuda" que
no está conectada a ningún otro estado, y lo que identifica al estado 5 como final es la
ausencia de una flecha que salga de él.
El sentido común dice que un sistema sólo puede tener un estado inicial; sin embargo,
puede tener múltiples estados finales. Los estados finales son mutuamente excluyentes,
lo cual significa que sólo uno de ellos puede ocurrir durante alguna ejecución del
sistema.
Condiciones y acciones.
Para completar nuestro DTE necesitamos añadir dos cosa más: las condiciones que
causan un cambio de estado y las acciones que el sistema toma cuando cambia de
estado. Como ilustra la figura 4.3.4, las condiciones y acciones se muestran junto a la
flecha que conecta dos estados relacionados.
Así como en los DFD se utilizó la partición también es recomendable usarla en los DTE
en donde los sistemas son muy complejos.
1. Se puede comenzar por identificar todos los posibles estados del sistema y
representar cada uno como una caja separada en una hoja de papel. Luego, se pueden
explorar todas las conexiones con significado (es decir, los cambios de estado) entre las
cajas.
Cuando se termina de construir el DTE preliminar, deben seguirse las siguientes reglas
para verificar la consistencia:
El DTE representa una especificación de proceso para una burbuja de control en DFD.
Como herramienta de modelado de alto nivel, el DTE puede servir incluso como
especificación de proceso para todo el sistema. Si se representa todo el sistema como un
diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades
en el sistema.
5. Análisis de sistemas de decisiones estructurada.
Las condiciones, las alternativas de las condiciones, las acciones y reglas de acción
deben conocerse con el fin de diseñar sistemas para decisiones estructuradas. El analista
precisa primero las condiciones. Esto es, aquellos fenómenos que pueden afectar el
resultado de algo. En el siguiente paso, el analista de sistemas identifica las opciones a
las condiciones específicas por quien toma las decisiones. Estas alternativas pueden ser
tan simples como "si", "no", o pueden ser más descriptivas como "menos de $50",
"entre $50 y $100" y "mayores de $ 100".
Luego se identifican las acciones. Esto incluye cualquier instrucción que se requiera
para alcanzar el resultado de una o más de las condiciones anteriores. Todas las
instrucciones para la manipulación o el cálculo de valores, la impresión de los informes,
o aún el desglose de las transacciones en preguntas, serían acciones. Las acciones se
unen a las condiciones por medio de las reglas de acción, las cuales son los protocolos
de ejecución de las acciones requeridas.
Los seguros de los dueños de inmuebles dependen, por supuesto del tipo de política y de
la ubicación del inmueble, pero una vez que esto se determina existen otros factores que
incrementan o disminuyen la prima del seguro. Uno de los factores es la construcción.
Una casa de tabique ahorrará al dueño un 10% de la prima anual. Si se cuenta con una
alarma sonora, se reducirá un 5% de la tasa y calculada. También el asegurado puede
hacer elecciones que incrementarían la prima. Si el dueño desea pagar por reposición,
en lugar de valor depreciado, aumenta la base un 10%. El dueño puede elegir el manejo
de un deducible de $100 dólares, en lugar de un deducible de $250 dólares; esto
incrementará la prima en un 15 %.
El documento de primas se analiza para establecer las acciones y las condiciones. Una
vez hecho lo anterior, se destacan los términos cuestionables, las ambigüedades, los
calificativos poco claros, "sin embargo", "pero" y otros términos similares. Para aclarar
todo ello, debería realizarse una entrevista para organizar el proceso de la decisión.
Observe que las alternativas se encuentran más explícitas y las acciones son más
específicas, se definen la "base", se describen y se ordenan las reglas de acción.
ENDIF
ENDIF
ENDIF
TABLA DE DECISIONES
Condición 1 SSSSSSSNNNNNNNN
Condición 1 SSSSSSSSNNNNNNNN
Condición 2 SSSSNNNN
Condición 3 SSNN
Condición 4 SN
Condición 1 SSSSSSSSNNNNNNNN
Condición 2 SSSSNNNNSSSSNNNN
Condición 3 SSNNSSNNSSNNSSNN
Condición 4 SNSNSNSNSNSNSNSN
14. Concluya la tabla insertando una X donde las reglas sugieran cierta acción.
15. Combine las reglas donde se aparenta que una alternativa no implique
diferencias en la salida; por ejemplo:
16. Condición 1 S S
17. Condición 2 S N
18. ---------------------------------
Acción 1 X X
Condición 1 S
Condición 2 __
------------------------------------
Acción 1 X
12345678
El cliente ordena del catálogo de otoño SSSSNNNN
La tabla de decisiones contempla tres condiciones (C1: clientes que ordenan del
catálogo de otoño, C2: clientes que ordenan del catálogo de Navidad y C3: clientes que
ordenan del catálogo de especialidades). Cada uno de ello tiene dos opciones (S o N).
Hay tres acciones que realizar: A1:enviar el catálogo de navidad del presente año; A2:
enviar el nuevo catálogo de especialidades; A3: enviar ambos catálogos.
1. Nos indica que enviemos el catálogo de Navidad para este año (acción 1)
2. La opción para la condición 3 siempre es N.
1234
Salario > $50.00/año SSNN
Salario<$2.00/mes SNSN
Acción 1
Acción 2
Las contradicciones se presentan cuando las reglas sugieren acciones distintas, pero
satisfacen las mismas condiciones. Las contradicciones ocurren con frecuencia si los
guiones (--) se insertan de manera incorrecta en la tabla. La redundancia ocurre cuando
un conjunto idéntico de alternativas requieren exactamente de la misma acción.
Cuando se dibujan los árboles de decisiones es útil distinguir entre las condiciones y las
acciones. Para este propósito, el uso de un nodo cuadrado indica una acción y un círculo
representa una condición, tal y como se representa en la figura 5.4.1. El uso de esta
notación hace más accesible el árbol de decisiones sí uno piensa que un círculo significa
IF (SI), mientras que cuadrado significa THEN (ENTONCES).
Para alcanzar con éxito esos objetivos, se requiere experiencia, tanto en hardware como
en software (así como ingeniería humana y base de datos). Todavía surgen tres
preguntas:
¿Cuánto esfuerzo se debe emplear en el análisis y en la definición de
sistemas y de software? Es difícil establecer unas directrices definitivas para
determinar el esfuerzo de análisis. El tamaño del sistema y su complejidad, el
área de aplicación, el uso final y las obligaciones del contrato son sólo unas
pocas de las muchas variables que afectan al esfuerzo total dedicado al análisis.
¿Quién lo hace? Todas las tareas han de ser dirigidas por un analista bien
formado y con experiencia. El analista trabaja en contacto con el personal
técnico y administrativo, tanto del cliente como del que desarrolla el sistema.
Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema; la
información que se va obtener, la información que se va suministrar, las funciones y el
rendimiento requerido. El analista se asegura de distinguir entre lo que "necesita" el
cliente (elementos críticos para la realización) y lo que el cliente "quiere" (elementos
deseables pero no esenciales).
Una vez identificado todos los objetivos, el analista realiza una evaluación de la
información suplementaria: ¿Existe la tecnología necesaria para construir el sistema?,
¿Qué recursos de fabricación y de desarrollo especiales se requerirán?, ¿Qué límites se
han impuesto a los costes y a la agenda?, etc.
Todos los proyectos son realizables - con recursos ilimitados y un tiempo infinito!.
Desafortunadamente, el desarrollo de un sistema basado en computadora se caracteriza
por la escasez de recursos y la dificultad (si no imposibilidad) de cumplir los plazos de
entrega, por lo tanto, es necesario y prudente evaluar la viabilidad de un proyecto lo
antes posible.
No será necesario llevar a cabo un estudio de viabilidad para sistemas en los que la
justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas
legales y no existe una alternativa razonable. Sin embargo, cuando no se da alguna de
las anteriores condiciones, debe realizarse el estudio.
B) Entorno de implementación.
C) Restricciones.
II. Resumen y recomendaciones de gestión.
A)Hallazgos importantes.
B) Comentarios.
C)Recomendaciones.
D)Impacto.
III. Alternativas.
La revisión del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto
(para asegurar la fiabilidad de su contenido) y luego por el director administrativo (para
determinar el estado del proyecto). El estudio debe provocar una decisión de "seguir/no
seguir". Debe tenerse en cuenta que durante las etapas de planificación, especificación y
desarrollo de la ingeniería del hardware y del software, se tomarán otras decisiones del
tipo seguir/no seguir.
En la tabla 6.2 se muestra los posibles beneficios que pueden tener los sistemas de
información de gestión; como se puede notar los beneficios se centran en el acceso de
información y su impacto en el entorno del usuario. Los beneficios que se pueden
asociar a programas de análisis científicos y de ingeniería o a un producto basado en
microprocesadores pueden diferir substancialmente.
• Posibilidad de recoger y guardar "automáticamente" datos de los registros (RC, AV, RE).
• Mantenimiento de registros más completo y más sistemático (RC, AV).
• Aumento de la capacidad para el mantenimiento de registros en términos de espacio y coste (RC).
• Estandarización del mantenimiento de registro (RC, AV).
• Aumento de la cantidad de datos que se pueden guardar por registro (RC,AV).
• Mejora en la seguridad en el almacenamiento de registros (RE, RC, MG).
• Posibilidad de crear nuevos archivos, mezclando partes de otros archivos (AV, AF).
Beneficios de las contribuciones a la posibilidad de reestructuración del sistema
• Posibilidad de crear nuevos archivos, mezclando partes de otros archivos (AV, AF).
Beneficios de las contribuciones a las posibilidades de análisis y de simulación
• Posibilidad de llevar a cabo rápidamente complejos cálculos simultáneos (AV, AF, RE).
• Posibilidad de crear simulaciones de fenómenos complejos con el fin de responder a preguntas del
tipo "qué pasa si ...?"(MG, AF).
• Posibilidad de agregar cantidades de datos de distintas formas que sean útiles para la planificación
y la toma de decisiones (MG, AF).
Beneficios de las contribuciones al control de procesos y de recursos
• Mejores posibilidades de mantener una contínua monitorización de los procesos y los recursos
disponibles (MG, RE, AF).
En la tabla 6.3 se exponen los costes asociados con el desarrollo de un sistema basado
en computadora. El analista estima cada coste y luego utiliza los costes de desarrollo y
los que surjan sobre la marcha para determinar la recuperación de la inversión, el punto
de igualdad y el período de amortización.
• Coste de consultoría
• Coste de la compra o alquiler del equipo actual.
• Coste de la instalación del equipo.
• Coste del acondicionamiento del lugar destinado al equipo (aire acondicionado, seguridad, etc.).
• Coste del Capital.
El análisis técnico empieza con una definición de la viabilidad técnica del sistema
propuesto. ¿Qué tecnologías se requieren para conseguir la funcionalidad y el
rendimiento del sistema? ¿Qué nuevos materiales, métodos, algoritmos o procesos se
requieren y cuál es el riesgo de su desarrollo? ¿Cómo afectarán al coste estos elementos
de tecnología?.
Las herramientas de que se puede disponer para el análisis técnico se encuentran en las
técnicas matemáticas de modelización y optimización, en la probabilidad y la
estadística, en la teoría de control - por nombrar unas cuantas. Sin embargo, es
importante tener en cuenta que la evaluación analítica no es siempre posible. La
modelización (bien matemática o física) es un mecanismo efectivo para el análisis
técnico de sistema basados en computadora. La figura 6.5.1 ilustra el flujo global de
información del proceso de modelización. El modelo se crea a partir de la observación
del mundo real o de una aproximación basada en los objetivos del sistema. El analista
comprueba el comportamiento del modelo y lo compara con el del mundo real o con el
del sistema esperado, obteniendo información de viabilidad técnica para el sistema
propuesto.
Figura 65:Modelización.
7. Análisis definitivo.
La respuesta es organizar el DFD global en una serie de niveles de modo que cada uno
proporcione sucesivamente más detalle sobre una porción del nivel anterior. En el caso
de los DFD, la organización de los niveles se muestra conceptualmente en la 1. 7.2.
7.1.2
El DFD del primer nivel consta sólo de una burbuja, que representa el sistema
completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores
externos. Este DFD se conoce como diagrama de contexto.
El DFD que sigue del diagrama de contexto se conoce como la figura 0. Representa la
vista de más alto nivel de las principales funciones del sistema, igual que sus principales
interfaces.
Como se mencionó anteriormente, cada burbuja debiera numerarse para una referencia
conveniente y esto también nos servirá como una manera adecuada de relacionar una
burbuja con el siguiente nivel del DFD que la describe más a fondo. Por ejemplo:
Como podrá verse, ésta es una manera bastante directa de organizar un DFD
potencialmente enorme en un grupo de piezas manejables. Pero existen diversas cosas
que debemos añadir a esta descripción de niveles:
3. ¿Deben partirse todas las partes del sistema con el mismo nivel de detalle? La
respuesta es "no". Algunas partes del sistema pueden ser más complejas que otras y
pueden requerir uno o más niveles de partición.
4. ¿Cómo se muestran estos niveles al usuario? Muchos usuarios sólo querrán ver un
diagrama: un usuario ejecutivo de alto nivel pudiera querer ver tan sólo el diagrama de
contexto o tal vez la figura 0; un usuario de nivel operacional pudiera querer ver sólo la
figura que describe el área en la cual esta interesado. Pero si alguien quiere ver una
parte más extensa del sistema, o tal vez todo, entonces tiene sentido presentar los
diagramas de una manera descendente; comenzará con el diagrama de contexto y
continuar hasta niveles más bajos de detalle.
5 ¿Cómo asegurar que los niveles del DFD sean consistentes entre sí?. Para
asegurar que cada figura sea consistente con su figura de más alto nivel se sigue una
regla sencilla: los flujos de datos que salen y entran de una burbuja en un nivel dado
deben corresponder con los que entran y salen de toda la figura en el nivel inmediato
inferior que la describe.
6. ¿Cómo se muestran los almacenes en los diversos niveles?. Esta es una área donde
la redundancia se introduce deliberadamente en el modelo. La regla es la siguiente:
mostrar un almacén en el nivel más alto donde primeramente sirve de interfaz entre dos
o más burbujas; luego, mostrarlo de nuevo en CADA diagrama de nivel inferior que
describa más a fondo dichas burbujas de interfase. Así, la figura 7.1.3 muestra un
almacén compartido por dos procesos de alto nivel; A y B; el almacén se mostraría
nuevamente en las figuras del nivel inmediato inferior que describen más a fondo A y
B.
Figura 7.1.3
Hasta aquí, hemos llegado al final del modelo esencial. Si se ha seguido todos los pasos
debe tener un modelo completo, detallado, formal y riguroso de todo lo que el sistema
debe hacer para llenar los requisitos del usuario. Contendrá lo siguiente:
• Diagrama de contexto.
• Lista de acontecimiento.
• Declaración de propósitos.
• Conjunto completo de diagramas de flujo de datos por niveles.
• Diagrama de entidad-relación completo y terminado.
• Diccionario de datos completo.
8. Implantación y operación.
Una vez terminado el modelo esencial sería suficiente para que los diseñadores y
programadores empiecen su trabajo, pero, prácticamente en todos los proyectos de
desarrollo de sistemas el usuario insistirá en proporcionar alguna información adicional.
Esta información involucra cuestiones de implantación.
La cuestión ahora es: ¿Qué funciones y qué datos se manejarán manualmente, y cuales
se automatizarán?. La frontera de automatización es casi irrelevante en el modelo
esencial pues, aunque el usuario obviamente quiere que se desarrolle un sistema
automatizado, también necesita una declaración bien hecha de los requerimientos de las
funciones y datos que queden justo fuera de la frontera de automatización.
Normalmente estas opciones extremas no ocurren; debido a que se puede llegar a algún
compromiso entre el usuario, analista y el equipo de implantación. Escogiendo que
partes de las actividades del modelo esencial se automatizarán y cuales funcionarán
manualmente. Como ilustran las figuras 8.2.1, pudiera haber diversas alternativas
razonables para dibujar la frontera de automatización. Cada una tendrá diferente costo
(que el equipo de implantación debe estimar, puesto que tiene conocimiento sobre las
posibilidades de la tecnología de implantación) y diferentes ramificaciones
organizacionales en el área del usuario.
Figura 8.2.1
La elección de los dispositivos de entrada y salida puede estar determinada por los
terminadores fuera del sistema. Los dispositivos que se usan típicamente para
proporcionar entradas al sistema incluyen los siguientes:
• Tarjetas perforadas.
• Cintas magnéticas.
• Discos flexibles
• Terminales y computadoras personales.
• Lectores ópticos y lectores de código de barras.
• Teléfono.
• Voz.
Los dispositivos de salida más usados son los siguientes:
• Salidas impresas.
• Tarjetas perforadas.
• Terminal
• Salida de voz.
• Graficador.
• Cinta magnéticas o disco.
• COM (Microforma para Salidas de Computadoras).
Para elaborar los formatos los usuarios informan al analista de "la manera en la que las
cosas tienen que ser". Es así sobre todo si el nuevo sistema debe comunicarse con otros
sistemas o personas externas a la organización que construye el nuevo sistema. Por
ejemplo, las organizaciones externas o los otros sistemas de cómputo externo pueden
proporcionar datos al sistema nuevo en un formato físico prescrito que no se puede
cambiar.
Figura 8.3.1
Diseño de formas.
Las formas de especialidad son más complejas y se crean con la ayuda de un diseñador
de formas con experiencia. Los tipos de formas de especialidad son:
Como parte de especificar formatos de entrada y salida, el analista muchas veces debe
especificar códigos, es decir, abreviaciones de la información que sería difícil y tardado
describir con detalle. Ejemplos de éstos son los números del Seguro Social, códigos
postales, números de ISBN para libros publicados y números de identificación de
empleados que se asignan a las compañías en sus declaraciones de impuestos.
Algunos puntos que se deben tomar en cuenta para la codificación de los datos en un
sistema nuevo son:
• Expandible. Debe proporcionar espacio para entradas adicionales que pudieran
requerirse.
• Preciso. Debe identificar al artículo específico.
• Conciso. Debe ser breve pero describir adecuadamente al artículo.
• Conveniente. Debe ser fácil de codificar y decodificar.
• Con significado. Debe ser útil para quienes lo manejan. De ser posible debe
indicar algunas características del artículo.
• Operable. Debe ser compatible con los métodos presentes y anticipados de
proceso de datos, manual o a máquina.
Caso Práctico.
Una forma de comprender este compendio de ideas sobre el análisis de sistemas es
explicando en forma detallada un caso práctico de un sistema real.
Nuestro caso de estudio describe los requerimientos de computarización de la
actividades de proceso de información de YOURDON Press.
El Modelo Ambiental .
La declaración de propósitos.
La lista de acontecimientos.
Modelo de Comportamiento.
El modelo preliminar de comportamiento: diagramas de flujo de datos.
Cada uno de los 40 acontecimientos listados en la sección del modelo ambiental tiene
un diagrama de flujo de datos asociado.
Al dibujar los DFD preliminares se tomó nota de los errores que se encontraron y los
cambios que se tenían que hacer en otras partes del modelo; estas notas se listan debajo
de cada DFD. La razón de esto es enfatizar que en un proyecto real el analista raramente
dibuja un DFD perfecto al primer intento; despues de pensar sobre el sistema, y luego
de entrevistas de seguimiento con el usuario, es inevitable que se encuentren errores en
el DFD que se está examinando o en alguna otra parte del modelo del sistema.
Notas
1. Al dibujar la primera versión de este diagrama, se observó que los pedidos con
tarjeta de crédito normalmente requieren autorización si la cantidad sobrepasa
algún límite prefijado. YOURDON Press aceptaba pedidos pagados con
Mastercard, Visa y American Express; por ello la interfase con el terminador
etiquetado como "AGENCIAS DE CREDITO".
2. La situación del crédito hizo obvio el hecho de que la definición de cliente en el
almacén de CLIENTES tendría que incluir lílmite-crédito como campo.
También se requiere un acontecimiento para cambiar el límite de crédito del
cliente (acontecimiento 16).
3. Para en el caso de los pedidos urgentes se envían de inmediato a la bodega;y
todos los demás pedidos se almacenan en PEDIDOS.
4. También existe la necesidad de un almacén ARCHIVOS, que es una copia del
pedido por escrito original del cliente, más una copia de la factura que se generó
para el pedido.
5. Los pedidos se pueden recibir por correo, por teléfono o en persona, por lo que
no se muestra en el DFD anterior ya que todas estas son funciones de transporte.
6. El sistema no pide automáticamente libros a la imprenta. En lugar de eso,
repetidas veces se le informa a la administración que un inventario ha bajado
más allá del umbral actual.
7. Se pueden recibir pedidos de nuevos clientes. Por eso se tendrá que crear un
nuevo registro en CLIENTES con la tasa estándar de descuento, etc. Esta es la
razón de la flecha de dos cabezas entre la burbuja 1 y el almacén CLIENTES.
Notas:
1. El pago puede cubrir diversas facturas distintas, pero no siempre queda claro de
cuáles facturas se trata. A veces los clientes no identifican la factura que están
pagando; a veces identifican facturas que ya se pagaron; en ocasiones dan como
referencia números de facturas inexistentes.
2. A veces no queda claro incluso de dónde viene el pago. Esto sucede sobre todo
en el caso de cadenas de librerías.
3. No existe garantía de que el pago sea por la cantidad exacta de la factura.
Algunos clientes tratan de evitar el pago del impuesto sobre la venta y los gastos
de envío.
Acontecimiento 3: El cliente pide información sobre un libro.
Notas:
1. El cliente generalmente pregunta cosas tales como el precio del libro, o cuándo
se espera tener en existencia cierto libro, o el programa de descuento por
volúmen.
Notas:
Notas :
1. Puede haberse retrasado el envío del pedido de algún cliente debido a lista de
espera en la bodega o porque no hay libros del titulo requerido en existencia.
2. Si el cliente decide cancelar a estas alturas el pedido, se trata como un
acontecimiento aparte (acontecimiento 8).
3. Otra posibilidad es que YOURDON Press no haya recibido el pedido (porque se
perdió en departamento de correo de la oficina del cliente o de la oficina de
YOURDON).
4. YOURDON Press puede haber recibido y procesado el pedido, pero que se haya
perdido en la agencia de transporte. En este momento el cliente quiere saber si
puede cancelar el pedido,o puede pedir crédito y volver hacer el pedido.
Notas:
1. La pregunta del cliente pueden ser sobre la tasa de descuento que se cotizó en la
factura, o con los impuestos de envío, impuestos sobre la venta u otros aspectos
de la factura.
2. Si el cliente hace una pregunta más general sobre todos sus pedidos, pagos, etc.,
la parte del sistema que lo maneja es el acontecimiento 7.
3. Para este acontecimiento, se necesita un número-factura para poder recuperar
la información sobre el pedido .
Notas:
Notas:
Notas:
1. Esto está bien si el cliente tiene saldo de crédito. En la mayoría de los casos , el
cliente lo aplicará a compras futuras. Sin embargo, en ocasiones desea un
cheque, porque no planea compras futuras o por alguna otra razón.
Notas:
Notas:
Notas:
1. Esto supone que a los vendedores se les paga una comisión aún si el cliente no
ha pagado. Ignora el suceso real de revertir una comisión si el cliente jamás paga
y se tiene que invalidar la factura asociada
2. Muchas ventas no se asocian con un vendedor individual, también pueden ser
por campañas directas por correo, reseñas en periódicos y revistas
computacionales, etc.
3. Lo que también supone este modelo es que es la misma comisión para todos los
vendedores y para todos los libros.
Notas:
Notas:
Notas :
Notas :
Notas :
Notas :
1. Con este modelo se ve la necesidad de eliminar algún día libros del sistema. Esto
rara vez sucede, pero el departamento de mercadeo llega a decidir cuando
"matar" un libro declarandolo agotado (acontecimiento 36).
2. Aunque este acontecimiento realmente crea un nuevo registro del libro (el libro
no se considera real y parte del sistema a menos que los editores hayan
terminado de editarlo y estén por enviarlo a impresión), también debemos crear
un registro de autor. Esto se hace en el acontecimiento 34.
Notas :
Notas :
Notas :
Notas :
Notas :
1. Observe que la situación de no tener un libro en existencia puede ocurrir porque
no haya llegado una reimpresión previamente pedida.
2. Como resultado de la situación de no tener en existencia un libro dado, pudiera
ser que no se surtan por el momento pedidos subsecuentes que hayan sido
procesados, pero ese es problema de la bodega en cuestión.
Notas :
1. Esto muestra que el acontecimiento 13 debe leer el almacén LIBROS para ver si
existe un adelanto excedente.
2. Este acontecimiento también crea un nuevo registro de autor si se trata de un
autor nuevo.
Notas :
Notas :
Notas :
1. Este plan consiste en hacer un pedido inicial por cierto número de libros y
acuerdan aceptar un cierto número de copias de cada libro nuevo que publique
YORDON Press. Es usado casi exclusivamente por librerías.