Asi p1

Anlisis de Sistemas de Informacin
1. Conceptos
1.1 Introduccin a los sistemas
Debido al crecimiento de la organizacin dentro de las industrias nace la
importancia de administrar recursos principales como la materia prima y la mano
de obra. Ahora la mayora de las empresas ya se dieron cuenta que la informacin
no solo es un producto sino el factor que determina el xito o el fracaso de la
misma.
En una empresa los sistemas de informacin desempean un papel crtico. Por
ejemplo, los directores de productos, que se enfrentan a los cambios del mercado,
deben ser capaces de anticiparse y responder a estos cambios lo antes posible.
Los sistemas de informacin deben suministrar la informacin a tiempo, no slo la
informacin referente a los mercados y productos, sino tambin la que se refiere a
los recursos disponibles en la organizacin para responder a la demanda de
productos.
1.1.1 Definiciones de sistemas

Definiendo los trminos siguientes: sistema, informacin y lo que es un sistema de
informacin.
Un sistema es un conjunto de elementos organizados que interactan entre s y
con su ambiente, para lograr objetivos comunes, operando sobre informacin,
sobre energa o materia u organismos para producir como salida informacin o
energa o materia u organismos. Un sistema aislado no intercambia ni materia ni
energa con el medio ambiente. [1]
Sistema es un modelo de ordenamiento aplicable a una determinada
organizacin que opera en un entorno cambiante, esta constituido por un conjunto
de elementos interrelacionados entre s, de forma que, si se verifica un cambio en
1
Introduccin a los sistemas
uno de ellos, se produce un efecto sobre uno o varios de los dems elementos
que lo constituyen. [3]
La informacin es un dato o un conjunto de datos que, en un contexto
determinado tienen un significado para alguien, y transmiten un mensaje til en un
lugar determinado. La informacin es un recurso primordial que incluso puede
determinar el xito o el fracaso de un negocio.
En sentido general, la informacin es un conjunto organizado de datos, que
constituyen un mensaje sobre un determinado ente o fenmeno. De esta manera,
si por ejemplo organizamos datos sobre un pas (nmero de habitantes, densidad
de poblacin, nombre del presidente, etc.) y escribimos por ejemplo, el captulo de
un libro, podemos decir que ese captulo constituye informacin sobre ese pas.
Cuando tenemos que resolver un determinado problema o tenemos que tomar
una decisin, empleamos diversas fuentes de informacin, y construimos lo que
en general se denomina conocimiento o informacin organizada que permite la
resolucin de problemas o la toma de decisiones. [5]
Segn otro punto de vista, la informacin es un fenmeno que proporciona
significado o sentido a las cosas, e indica mediante cdigos y conjuntos de datos,
los modelos del pensamiento humano. La informacin por tanto, procesa y
genera el conocimiento humano. Aunque muchos seres vivos se comunican
transmitiendo informacin para su supervivencia, la superioridad de los seres
humanos radica en su capacidad de generar y perfeccionar tanto cdigos como
smbolos con significados que conformaron lenguajes comunes tiles para la
convivencia en sociedad, a partir del establecimiento de sistemas de seales y
lenguajes para la comunicacin. [5]
Los datos se perciben mediante los sentidos, estos los integran y generan la
informacin necesaria para producir el conocimiento que es el que finalmente
permite tomar decisiones para realizar las acciones cotidianas que aseguran la
2
existencia social. La sabidura consiste en juzgar correctamente cuando, cmo,

donde y con qu objetivo emplear conocimiento adquirido.
Existe una relacin indisoluble entre los datos, la informacin, el conocimiento, el
pensamiento y el lenguaje, por lo que una mejor comprensin de los conceptos
sobre informacin redundar en un aumento del conocimiento, ampliando as las
posibilidades del pensamiento humano, que tambin emplea el lenguaje -oral,
escrito, gesticular, etc.-, y un sistema de seales y smbolos interrelacionados . [4]
Ya que tenemos estas definiciones de sistemas podramos decir entonces que un
sistema de informacin:
Es un conjunto de funciones o componentes interrelacionados que forman un
todo, es decir, obtiene, procesa, almacena y distribuye informacin para apoyar la
toma de decisiones y el control en una organizacin. Igualmente apoya la
coordinacin, anlisis de problemas, visualizacin de aspectos complejos, entre
otros.
Un sistema de informacin contiene informacin de sus procesos y su entorno.
Como actividades bsicas producen la informacin que se necesita: entrada,
procesamiento y salida. La retroalimentacin consiste en entradas devueltas para
ser evaluadas y perfeccionadas.
Es un sistema que sirve para proporcionar la informacin necesaria a la
organizacin o empresa, donde y cuando se necesite.
Un sistema de informacin es el conjunto de funciones y procedimientos
encaminados a la captacin, desarrollo, recuperacin, almacenamiento, etc., de
informacin en el seno de una organizacin. [6]
3
A un sistema de informacin lo integran dos partes bsicas: el hardware y el

software. [5]
1.1.2 Tipos
Los tipos de sistemas en general se dividen en:
Sistemas fsicos y Sistemas abstractos
Sistemas determinsticos y Sistemas probabilsticos
Sistemas abiertos y Sistemas cerrados
A continuacin se describen cada uno de ellos
1.1.2.1 Sistemas fsicos y sistemas abstractos [6]

Los sistemas fsicos son los que estn compuestos por equipos, por maquinaria y
por objetos. Pueden ser descritos en trminos cuantitativos de desempeo.
Los sistemas abstractos son los que estn compuestos por conceptos, planes e
ideas. En estos, los smbolos representan atributos y objetos, que solo existen en
el pensamiento.
1.1.2.2 Sistemas determinsticos y Sistemas probabilsticos [6]

Los sistemas determinsticos son aquellos cuyo funcionamiento puede
predecirse con toda certeza, mientras que en los Sistemas probabilsticos existe
incertidumbre al respecto.
Los sistemas probabilsticos son las organizaciones que, aunque existen
vertiginosas fuerzas internas que tiendan a convertirlas en determinsticos,
igualmente se encuentran en su medio circundante probabilstico, la incertidumbre
permea todas las actividades de la organizacin.
4
1.1.2.3 Sistemas Abiertos y sistemas Cerrados [7] [8]

Sistema abierto. Se caracteriza porque su estado original se modifica
constantemente por la accin de retroalimentacin del ambiente, desde su
nacimiento hasta su extincin. Su vida til depende de su adaptabilidad a las
exigencias del ambiente (homeostasis).
Sistema cerrado. Se caracteriza porque no tiene capacidad de cambio por si
mismo para adaptarse a las demandas del ambiente. Es irreversible y su estado
presente y final esta determinado por su estado original. Son perecederos por
desgaste (entropa).
El sistema es un proceso en marcha, por este motivo se caracteriza por
determinados parmetros. Los parmetros dan caractersticas
por sus
propiedades, valor y descripcin de un sistema especfico o de un componente del

sistema.
1.1.2.4 Parmetros de los sistemas [8]

Entradas o Insumos (input): Es todo lo que ingresa al sistema para hacerlo
funcionar. Ningn sistema es autosuficiente o autnomo. El sistema necesita de
insumos, en forma de recursos, energa o informacin.
Operacin o procesamiento: Todo sistema procesa o convierte sus entradas
mediante sus subsistemas. Cada subsistema se encarga de un tipo de insumo
que le es peculiar. En el organismo humano, el aire que respiramos es procesado
por el aparato respiratorio, la comida que comemos por el aparato digestivo, las
imgenes por los sistemas visual y nervioso
5
Salidas o resultados (output): Todo sistema coloca en el medio ambiente

externo las salidas o resultados de sus operaciones. Las entradas debidamente
procesadas y convertidas en resultados se exportan de nuevo al ambiente, en
forma de productos o servicios prestados, en el caso de las empresas.
Retroaccin o retroalimentacin (feedback): es la reentrada o retorno al
sistema de sus salidas o resultados, que pasan a influir sobre su funcionamiento.
La retroaccin es generalmente una informacin o energa de retorno que vuelve
al sistema para realimentarlo o alterar su funcionamiento como consecuencia de
sus resultados o salidas.
A partir de estos parmetros, podemos evaluar el funcionamiento de un sistema.
En lenguaje sistmico, la eficiencia es el cociente de salida sobre le entrada, es,
es decir, la cantidad de salida por unidad de entrada. Si dos sistemas presentan
los mismos resultados, pero uno de ellos requiere menos recursos de entrada,
entonces ste ser ms eficiente. Dicho de otra manera, dos sistemas utilizan la
misma cantidad de insumos, pero uno de ellos produce mejor resultado, entonces
ste ser el ms eficiente. La eficacia, por otro lado, es la relacin entre la salida y
el objetivo del sistema, esto es, en cuanto ms contribuye el resultado al alcance
del objetivo, ms eficaz ser el sistema.
Figura 1.1 Parmetros de un sistema

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed.
Prentice Hall 6 edicin
6
1.1.3 Clasificacin
Los sistemas de Informacin son desarrollados con propsitos diferentes
dependiendo de las necesidades del negocio. Hay diferentes tipos de sistemas y
se describen a continuacin:
Sistemas
de
Procesamiento
de
Transacciones
(TPS,
Transaction
Processing System).
Sistemas de Automatizacin de Oficina (OAS, Office Automatition System)
Sistemas de Trabajo de Conocimiento (KWS, Knowledge Work System)
Sistemas de Apoyo a Decisiones (DSS*, Decisin Support Systems)
Sistemas
de Informacin
Gerencial (MIS*Management Information
Systems).
Sistemas de Apoyo a Ejecutivos (ESS*, Executive Support Systems) y
Sistemas de Apoyo a Decisiones de Grupo (GDSS, Group Decisin Support

Systems).
Sistemas de Trabajo Corporativo Apoyados por Computadora (CSCWS,

Computer-Supported Collaborative Work System)
Sistemas Expertos e Inteligencia Artificial
1.1.3.1
Sistemas
de
Procesamiento
de
Transacciones
(TPS,
Transaction Processing System) [1]

Los Sistemas de Procesamiento de Transacciones son sistemas de informacin
computarizados desarrollados para procesar gran cantidad de datos para
transacciones rutinarias de los negocios. Este tipo de sistemas elimina el tedio de
las transacciones operacionales necesarias y reducen el tiempo que alguna vez
se requiri para ejecutarlas manualmente, aunque la gente todava debe alimentar
datos a los sistemas computarizados.
7
1.1.3.2
Sistemas
de
Automatizacin
de
Oficina
(OAS,
Office
Automatition System y Sistemas de Trabajo de Conocimiento (KWS,

Knowledge Work System) [1]
Al nivel de conocimiento de la organizacin hay dos clases de sistemas. Los
sistemas de automatizacin de oficina que dan soporte a los trabajadores de
datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la
informacin
para analizarla y transformar datos, o para manejarla en alguna
forma y luego compartirla o diseminarla formalmente por toda la organizacin y

algunas veces mas all de ella. Los aspectos familiares de los Sistemas de
Automatizacin de Oficina incluyen procesamiento de palabras, hojas de clculo,
editor de publicaciones, calendarizacin electrnica y comunicacin mediante
correo de voz, correo electrnico y videoconferencias.
Los Sistemas de Trabajo de Conocimiento dan soporte a los trabajadores
profesionales, tales como cientficos, ingenieros y doctores, les ayudan a crear un
nuevo conocimiento que contribuya a la organizacin o a toda la sociedad.
1.1.3.3 Sistemas de Apoyo a Decisiones (DSS, Decisin Support

Systems) [1] [4]
Una clase de ms alto nivel en los sistemas de informacin computarizada son los
sistemas de apoyo a las decisiones. El Sistemas de apoyo a decisiones es similar
al sistema de informacin gerencial tradicional en que los dos dependen de una
base de datos como fuente. Un sistema de apoyo a decisiones se aparta del
sistema de informacin gerencial tradicional en que enfatiza el apoyo a la toma de
decisiones en todas sus fases, aunque la decisin actual todava es del encargado
de la toma de decisiones (persona responsable). Los sistemas de apoyo a
decisiones estn hechos a la medida de la persona o grupo que los usa, diferente
a los sistemas de informacin gerencial tradicionales.
8
1.1.3.4
Sistemas
de
Informacin
Gerencial
(MIS,
Management
Information Systems) [1]

Los
Sistemas
de
Informacin
Gerencial
son
sistemas
de
Informacin
computarizada que trabajan debido a la interaccin resuelta entre gentes y

computadoras. Requieren que las gentes, el software y el hardware trabajen como
uno solo.
Para poder ligar la informacin, los usuarios de un Sistema de Informacin
Gerencial comparten una base de datos comn que almacena modelos que
ayudan a los usuarios a interpretar y aplicar esos mismos datos. Los Sistemas de
Informacin Gerencial producen informacin que es usada en la toma de
decisiones y tambin puede llegar a unificar algunas funciones de informacin
computarizada, aunque no exista como una estructura singular en ningn lugar del
negocio, es decir, pueden contar con algn otro tipo de sistemas de informacin
con el que se labore en la organizacin.
1.1.3.5 Sistemas de Apoyo a Ejecutivos (ESS, Executive Support

Systems) [1]
Los Sistemas de Apoyo a Ejecutivos ayudan a los ejecutivos a organizar sus
actividades relacionadas con el entorno externo mediante herramientas graficas y
de comunicaciones, que por lo general se encuentran en salas de juntas o en
oficinas corporativas personales. A pesar de que los Sistemas de Apoyo a
Ejecutivos dependen de la informacin producida por los Sistemas de
Procesamiento de Transacciones y los Sistemas de Informacin Gerencial,
ayudan a resolver problemas de toma de decisiones no estructuradas, que no
tienen una aplicacin especifica, mediante la creacin de un entorno que
contribuye a pensar en problemas estratgicos de una manera bien informada.
Los Sistemas de Apoyo a Ejecutivos amplan y apoyan las capacidades de los
ejecutivos al darles la posibilidad de comprender su entorno.
9
1.1.3.6 Sistemas de Trabajo Corporativo Apoyados por Computadora

(CSCWS, Computer-Supported Collaborative Work System)
[1]
Este tipo de software esta diseado con el fin de minimizar las conductas
negativas de grupos comunes, como: la falta de participacin originada por miedo
a las represalias si se expresa un punto de vista contrario, control por parte de los
miembros y toma de decisiones conformista. Algunas veces se puede hacer
referencia a los Sistemas de Apoyo a Decisiones de Grupo con un trmino ms
general como Sistemas de Trabajo Colaborativo apoyados por Computadora que
pueden contener el respaldo de un tipo de software denominado groupware para
la colaboracin en equipo a travs de computadoras conectadas en red.
1.1.3.7 Sistemas Expertos e Inteligencia Artificial (AI, Artificial

Intelligence) [1]
La Inteligencia Artificial ha sido para desarrollar maquinas que se comporten de
forma inteligente. Dos caminos de investigacin de la Inteligencia Artificial son la
compresin del lenguaje natural y el anlisis de la habilidad para razonar un
problema y llegar a conclusiones lgicas. Los sistemas expertos usan las tcnicas
de razonamiento de la Inteligencia Artificial para resolver los problemas que
plantean los usuarios de negocios.
Un sistema experto (o sistema basado en conocimiento) captura de forma efectiva
y usa el conocimiento de un experto para resolver un problema particular
experimentado en una organizacin. A diferencia de los Sistemas de apoyo a
decisiones, que dejan la decisin al encargado de la toma de decisiones, un
sistema experto selecciona la mejor solucin a un problema o a una clase
especfica de problemas.
Componentes Bsicos:
La base del conocimiento

10
Una motor de Inferencia (Conexin de usuario-sistema)
Interfaz de usuario
1.1.3.8 Sistemas de apoyo a decisiones de grupo (GDSS, Group

Decisin Support Systems) [1] [4]
Cuando
los
grupos
necesitan
trabajar
juntos
para
tomar
decisiones
semiestructuradas o sin estructura, un sistema de apoyo a decisiones de grupo

puede plantear una solucin. Los Sistemas de Apoyo a Decisiones de Grupo son
usados en cuartos especiales, equipados en varias configuraciones diferentes,
que permiten que los miembros del grupo interacten con apoyo electrnico,
frecuentemente en forma de software especializado y con una persona que da
facilidades al grupo. El software de Sistemas de Apoyo a Decisiones de Grupo
tambin puede ser diseado para minimizar el comportamiento negativo tpico de
grupo, tal como la falta de participacin debido al miedo a represiones por
expresar un punto de vista no popular o conflictivo, dominacin por miembros del
grupo con voz dominante y la toma de decisiones de pensamientos en grupo
1.2 Ciclo de vida de un proyecto de software [1]

El ciclo de vida de un proyecto de software es un enfoque por fases del anlisis y
diseo del software, donde su funcin principal es que los sistemas se desarrollen
de mejor manera mediante el uso de un ciclo especfico de actividades tanto del
analista como del usuario, facilitando su gestin y control. De esta forma, se suele
tener cierto grado de incertidumbre debido a que se requiere la realizacin de
tareas y actividades no realizadas anteriormente.
Algunos analistas no estn de acuerdo con las fases ya que muchas veces no se
puede ser tan exacto en el desarrollo del ciclo de vida en el desarrollo de
sistemas, pero, por lo general, les gusta su enfoque organizado. Enseguida se
11
presenta el ciclo de vida llamado algunas veces ciclo de vida bsico el cual tiene
las siguientes etapas o fases:
Planificacin y gestin del proyecto.
Determinacin de requerimientos.
Anlisis y diseo.
Programacin.
Pruebas e Implementacin.
Se tomara el siguiente diagrama de referencia donde se muestran las etapas del

ciclo de vida del desarrollo de sistemas:
Figura 1.2 Ciclo de vida del desarrollo de sistemas

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 edicin
1.2.1 Planificacin y gestin del proyecto [1]
12
En esta primera fase del ciclo de vida del desarrollo de sistemas el analista tiene
que identificar los problemas, las oportunidades y los objetivos. Esta etapa es
crtica para el xito del resto del proyecto, debido a que nadie quiere desperdiciar
el tiempo subsecuente resolviendo el problema equivocado.
La primera fase requiere que el analista observe honestamente lo que esta
sucediendo en un negocio. Luego, junto con los dems miembros de la
organizacin, el analista hace resaltar los problemas. Frecuentemente estos ya
han sido vistos por los dems, y son la razn por la cual el analista fue llamado
inicialmente.
Las oportunidades son situaciones que el analista considera que pueden ser
mejoradas por medio del uso de sistemas de informacin computarizados. El
aprovechar las oportunidades puede permitir que el negocio gane un avance
competitivo o ponga un estndar de la industria.
La identificacin de objetivos es tambin un componente importante en la primera
fase. En primer lugar, el analista debe descubrir lo que est tratando de hacer el
negocio. Luego ser capaz de ver si algn aspecto de la aplicacin de sistemas
de informacin puede ayudar para que el negocio alcance sus objetivos atacando
problemas especficos u oportunidades.
Las personas involucradas en la primera fase son los usuarios, analistas y
administradores de sistemas que coordinan el proyecto. Las actividades de esta
fase consisten en entrevistas a los administradores de los usuarios, sumarizacion
del conocimiento obtenido, estimacin del alcance del proyecto y documentacin
de los resultados. La salida de esta fase es un estudio de factibilidad que contiene
una definicin del problema y la sumarizacion de los objetivos. Luego los
administradores deben tomar una decisin para ver si continan con el proyecto
propuesto. Si el grupo de usuarios no tiene los suficientes fondos en su
presupuesto y desea atacar problemas que no estn relacionados, o los
13
problemas no requieren un sistema de cmputo, puede ser recomendada una

solucin manual y el proyecto de sistemas ya no contina.
1.2.2 Determinacin de requerimientos [1]

Esta fase es donde se determinan los requerimientos de informacin de los
usuarios. Entre las herramientas que se usan para definir los requerimientos de
informacin se encuentran mtodos interactivos como:
Muestreo
Investigacin de datos impresos
Entrevistas
Cuestionarios
Otros mtodos que se usan para definir los requerimientos pero no participa el
usuario son:
Observacin del comportamiento del encargado de la toma de decisiones
Ambiente en la oficina
Elaboracin de prototipos
En esta fase es donde se toma mayor esfuerzo por comprender que informacin
necesitan los usuarios para realizar su trabajo. Se puede ver que varios de los
mtodos para determinar los requerimientos de informacin involucran la
interaccin directa con los usuarios. Esta fase sirve para confirmar la imagen o
idea que se tiene de la organizacin y sus objetivos. Algunas veces solamente se
completan las dos primeras fases del ciclo de vida del desarrollo de sistemas.
Este tipo de estudio puede tener diferentes propsitos, y es realizado tpicamente
por un especialista llamado analista de informacin.
En esta fase los involucrados son los analistas y los usuarios (administradores de
las operaciones y los trabajadores de las operaciones). El analista de sistemas
necesita saber que los detalles de las funciones actuales del sistema: el quin (la
14
gente involucrada), el qu (la actividad del negocio), el dnde (el ambiente donde
se lleva a cabo el trabajo), el cundo (en que momento) y el cmo (de que manera
se desarrollan los procedimientos actuales) del negocio en estudio.
Al trmino de esta fase, se debe conocer el funcionamiento del negocio y poseer
informacin muy completa acerca de la gente, los objetivos, los datos y los
procedimientos implicados.
1.2.3 Anlisis y diseo [1]

1.2.3.1 Anlisis
En esta fase se involucra el anlisis de las necesidades del sistema. Nuevamente,
herramientas y tcnicas especiales ayudan para que el anlisis haga las
determinaciones de los requerimientos. Una herramienta principal es el uso de
diagramas de flujo de datos para graficar la entrada, el proceso y la salida de las
funciones del negocio en forma grfica estructurada. A partir de los diagramas de
flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos
de datos usados en el sistema, as como sus especificaciones, si son
alfanumricos y que tanto espacio ocupan cuando se imprimen.
En esta fase tambin se analiza las decisiones estructuradas que se hacen. Las
decisiones estructuradas son aquellas para las que pueden ser determinadas las
condiciones como alternativas de condicin, acciones y reglas de accin. Hay tres
mtodos principales para el anlisis de decisiones estructurales:
Lenguaje estructurado
Tablas de decisin
rboles de decisin
En esta fase se prepara una propuesta de sistema que suma lo que ha sido
encontrado, proporciona anlisis de costo/beneficio de las alternativas y hace
recomendaciones sobre lo que se debe hacer. Si alguna de las recomendaciones
15
es aceptable para la administracin, se sigue en curso. Cada problema de sistema

es nico y nunca hay una sola solucin correcta. La manera en que se formula
una solucin o recomendacin depende de la capacidad y preparacin profesional
de cada analista.
1.2.3.1.1 Tablas de decisin [10] [11]

Las tablas de decisin son herramientas que se utilizan: En la etapa de anlisis de
sistemas: para efectuar una representacin grfica simplificada de los procesos
lgicos que hayan sido relevados durante la investigacin detallada, a efectos de
analizar si se adecuan o no a los requerimientos del sistema. En la etapa de
diseo de sistemas se utilizan para representar grficamente procesos lgicos
creados para satisfacer las necesidades del sistema bajo estudio. Y se utilizan
Aisladamente, es decir, en tareas que no tengan que ver con el estudio de
sistemas, para la representacin simplificada de procedimientos especficos que
sirvan de apoyo para una interpretacin correcta del mismo y su posterior
ejecucin (procedimientos legales, impositivos, laborales, previsionales, aplicacin
de normas tcnicas, etc.)
Las Tablas de Decisin estn compuestas por cuatro secciones:
Reglas de decisin
Identificacin de
condiciones
Identificacin de
acciones
Valores de condiciones
Valores de acciones
Figura 1.3 Secciones de tablas de decisin

Jos M Alessandro, Universidad Nacional de la Plata, Tablas de decisin [En lnea], Buenos Aires Argentina
[Consulta: Mayo de 2007],
<http://www.contabilidad.econo.unlp.edu.ar/637/paginas_web/06_materiales/tablasdecision.pdf>
Seccin Identificacin de condiciones: se detalla una condicin por

rengln. Se llaman condiciones a situaciones variables que pueden ocurrir
(p.ej: tipo de cliente, monto de ventas, antigedad, etc.). [10]
16
Seccin Identificacin de acciones: se describen todos los pasos que se

deben realizar. Se llaman acciones a los distintos comportamientos que se
asumirn en funcin de los valores que tomen las condiciones. Se escriben
en el orden en que deben ser ejecutadas (p.ej: calcular descuento, calcular
retencin, pedir materiales, etc.). [10]
Seccin Valores de condiciones: se indican valores de las condiciones

indicadas en la primera seccin, dependiendo del tipo de tabla de decisin
(de entrada limitada o extendida) que se construya para representar el
proceso. [10]
Seccin Valores de acciones: se indican valores de las acciones

descriptas en la segunda seccin, dependiendo del tipo de tabla de
decisin (de entrada limitada o extendida) que se confeccione. [10]
Una vez confeccionada la tabla, quedarn determinadas las reglas de decisin.

Estas son proposiciones que se leern verticalmente, partiendo desde la seccin
Valores de Condiciones y descendiendo por la seccin Valores de Acciones. Se
las enuncia as:
SI.......(condicin1, condicin2, etc.)... ENTONCES ... (accin1, accin2,etc.).....Por ejemplo:
SI... (el empleado registra presentismo perfecto durante el mes)...ENTONCES... (sumar a su
remuneracin una bonificacin del 8% sobre su sueldo bsico).
SI ... (la liquidacin de pago de honorarios arroja un importe superior a $ 1.200
y el profesional no se encuentra inscripto en el Impuesto a las Ganancias) ...
ENTONCES ... (calcular una retencin del 28% sobre la suma que supere a dicho importe).
Las tablas de decisin permiten agrupar todas las combinaciones de condiciones

y todas las posibilidades lgicas en un conjunto de fcil entendimiento y anlisis,
creando adems la posibilidad de controlar que no se haya omitido ninguna
alternativa y que se hayan cubierto todas las posibilidades.
Como construir tablas de decisin [11]
Para desarrollar tablas de decisin, se deben seguir los siguientes pasos:
17
1. Determinar los factores considerados como ms relevantes en la toma de

decisiones. Esto permite identificar las condiciones en la decisin. Cada
condicin seleccionada de detener la caracterstica de ocurrir quo no
ocurrir; en este caso no es posible la ocurrencia parcial.
2. Determinar los pasos o actividades ms factibles bajo condiciones que
cambian (no slo las condiciones actuales). Esto permite identificar las
acciones.
3. Estudiar las diferentes posibilidades de combinaciones de condiciones.
Para cualquier nmero N condiciones, existen 2n combinaciones a
considerar, por ejemplo para tres condiciones es necesario examinar ocho
posibles combinaciones 23= 8.
4. Llenar la tabla con reglas de decisiones. Existen dos formas para hacerlo:
La primera, escenario los renglones de condicin con valores s o no para
cada combinacin posible de condiciones. Esto es llenar la primera mitad
del rengln consigo y la otra mitad con no. El siguiente rengln se llena
alternando con S y N, repitindose este proceso hasta llenar la tabla.
El otro mtodo para llenar la tabla considera una condicin a la vez y, por
cada condicin adicional, la aade a la tabla pero sin considerar las
combinaciones de condiciones y acciones duplicadas:
a) Establece la primera condicin y todas las acciones permisibles.
b) Aadir la segunda condicin duplicando la primera mitad de la matriz y
llenando los diferentes valores S y N de las dos mitades de la matriz
aumentada con las nuevas condiciones.
c) Para cada condicin adicional repite el paso b.
5. Marcar las entradas correspondientes a las acciones con una X para indicar
que stas se emprenden; dejar las celdas vacas o marcadas con un guin
para sealar que en ese rengln no emprende ninguna accin.
18
6. Examinar la tabla para detectar reglas redundantes o contradicciones entre

estas.
Estos sencillos lineamientos no slo ahorran tiempo al construir una tabla de
decisiones a partir de informacin recopilada durante la investigacin sino que
tambin es de ayuda para sealar donde falta informacin, donde no importan las
condiciones en un proceso, o donde existen relaciones o resultados importantes
que otros no detectaron o consideraron. En otras palabras, el empleo de las tablas
de decisin produce un anlisis ms completo y exacto.
Verificacin de tablas de decisin [11]
Despus de construir una tabla, se verifica que sea correcta y completa con la
finalidad de asegurar que la tabla incluye todas las condiciones junto con las
reglas de decisin que las relacionan con las acciones. Asimismo, los analistas
tambin deben examinar la tabla para encontrar redundancias y contradicciones.
Eliminacin de la redundancia. Las tablas de decisin pueden volverse muy
grandes y difciles de manejar si se permite que crezcan sin ningn control.
Remover las entradas redundantes puede ser de ayuda para manejar el tamao
de la tabla. La redundancia se presenta cuando las siguientes condiciones son
verdaderas al mismo tiempo: 1) dos reglas de decisin son idnticas salvo para
una condicin del rengln y 2) las acciones para las dos reglas son idnticas.
Supresin de contradicciones. Las reglas de decisin son contradictorias entre
s cuando dos o ms reglas tienen el mismo conjunto de condiciones pero sus
acciones son diferentes.
Las contradicciones indican que la informacin que tiene el analista es incorrecta
o bien que existe un error en la construccin de la tabla. Sin embargo, muchas
veces la contradiccin es resultado de las discrepancias en la informacin que
19
recibe el analista de diferentes personas con respecto a la forma en que estas

toman decisiones. Se puede tomar una decisin especfica utilizando diferentes
reglas. Encontrar tales discrepancias puede ser de gran utilidad para el analista
que trabaja con la finalidad de mejorar una situacin de decisin.
1.2.3.1.2. Tipos de tablas de decisin [10]

Tablas de entrada limitada [10]
Sus principales caractersticas son:
Las condiciones y las acciones figuran expresadas en forma completa.
Los valores asignados a las condiciones solo pueden ser SI o NO. Por tal
motivo las condiciones se las expresa en forma de preguntas, las cuales
slo podrn ser respondidas afirmativa o negativamente.
Los valores asignados a las acciones pueden ser: X (la accin debe ser
ejecutada) o blanco (la accin no debe ser ejecutada).
La cantidad de reglas surge de calcular 2 a la n, donde n es la cantidad de

condiciones. Luego, estas reglas de decisin se depuran:
o Eliminando las reglas inconsistentes, es decir, combinaciones de
condiciones que no se pueden dar en la realidad, y
o Eliminando las reglas redundantes. Ello se logra fusionando reglas a
las cuales les corresponden las mismas acciones y los valores de las
condiciones son todos iguales, excepto uno; a la regla que queda se
le coloca una I (indiferente o indistinto) como valor de la nica
condicin en que diferan.
20
CONDICIONES
Pago contado?
Compra >$50000?
ACCIONES
Calcular descuento 5%
s/importe compra
Calcular bonificacin 7%
s/importe compra
Calcular importe neto de la
factura
1
S
S
2
S
N
X
X
3
N
S
4
N
N
X
X
Figura 1.4 Ejemplo de Tabla limitada

Jos M Alessandro, Universidad Nacional de la Plata, Tablas de
decisin [En lnea], Buenos Aires Argentina [Consulta: Mayo de 2007],
<http://www.contabilidad.econo.unlp.edu.ar/637/paginas_web/06_materia
les/tablasdecision.pdf>
Tablas de entrada extendida [10]

Sus principales caractersticas son:
Se utilizan cuando hay variables que pueden asumir ms de dos valores.

En este caso deber considerarse que cada variable se desdobla en tantas
condiciones como valores diferentes pueda asumir la misma. En
consecuencia, en lugar de indicar SI o NO, van a escribirse todos los
valores que pueda tener cada condicin. Dichos valores pueden describirse
mediante abreviaturas, debiendo indicarse al pie o a un costado de la tabla
los significados de cada una. En aquellos casos en que los valores de una
condicin fueran indiferentes para la realizacin de determinadas acciones,
es aconsejable dejar en blanco las celdas correspondientes a los valores
de esa condicin; esto reducir la cantidad de reglas de decisin de la
tabla.
En las acciones en vez de colocar una X se describen las acciones

especficas a ejecutar.
La cantidad de reglas surge de multiplicar la cantidad de valores que

pueden tener las condiciones que se detallen. Es decir, si hay tres
condiciones: una con tres valores, otra con dos valores y la restante con
tres valores, se multiplica 3 x 2 x 3 lo cual arroja un total de 18
combinaciones o reglas posibles. Luego estas reglas se depuran
eliminando las combinaciones inconsistentes y redundantes.
21
CONDICIONES
Plazo de pago (das)
ACCIONES
Aplicar descuento
Aplicar inters
1
0
2
1-30
3
31-60
4
61-90
3%
6%
5%
Figura 1.5 Ejemplo de Tabla extendida

Tablas de entrada mixta [10]

Se combinan caractersticas de las dos anteriores, considerando los valores de las
condiciones en forma de entrada extendida e identificando las acciones en forma
de entrada limitada, o viceversa. Ejemplo de tabla de entrada mixta (condiciones
en entrada extendida y acciones en entrada limitada):
CONDICIONES
Antigedad empleado
<5 aos
5 a<10
aos
10 a15
aos
>15
aos
ACCIONES
Calcular bonificacin por
antigedad
Sueldo x 1% x aos antig
Sueldo x 1,5% x aos antig
X
X
Sueldo x 2% x aos antig
Sueldo x 2,5% x aos antig
Figura 1.6 Ejemplo de Tabla mixta

Tablas de forma ELSE

Esta es una variante en las tablas de decisin esta tiene como finalidad omitir la
recepcin por medio de reglas ELSE. Para construir una tabla de decisiones en la
forma ELSE, se especifican las reglas junto con las entradas de condicin, que
cubren todo el conjunto de acciones con excepcin de una que se convierte en la
regla a seguir cuando ninguna de las dems condiciones explicitas es verdadera.
Esta regla se encuentra en la columna final en el margen derecho, que es
22
columna ELSE si ninguna de las otras condiciones es valida, se siguen las reglas
de condicin ELSE. Esta regla elimina la necesidad de repetir condiciones que
conducen a las mismas acciones.
Tablas mltiples
La forma ELSE es una alternativa para controlar el tamao de las tablas de
decisin. Otra manera de alcanzar este mismo objetivo es alcanzando varias
tablas de decisin. De acuerdo con la s acciones seleccionadas en la primera
tabla, otras se explican en otras tablas adicionales; cada tabla proporciona
mayores detalles relacionados con las acciones y emprender.
Tambin permiten al analista establecer acciones repetitivas que deben realizarse
despus de tomar las decisiones y que continan hasta que se alcanzan
determinadas condiciones.
Las tablas se alcanzan en forma jerrquica: una tabla de nivel-alto contiene las
condiciones principales que, cuando son seleccionadas, determinan las tablas y
acciones adicionales donde se encuentran otros detalles. Una declaracin de
transferencia, como GO TO o PERFORM, en la seccin e acciones de la tabla de
control (nivel superior) dirige el recorrido hacia tablas de niveles inferiores.
Existen dos tipos de transferencias:
Transferencia directa: Se emplea una sola vez; la tabla que es seleccionada de
esta manera no vuelve a referirse a la tabla original. La proposicin "GO TO"indica
cual es la siguiente tabla que se va a examinar. Cuando se termina de examinar
las condiciones decisiones y acciones especificadas en esa tabla y se selecciona
la apropiada para completar el trabajo.
23
Transferencia temporal: En contraste con la anterior se debe de enlazar por

medio de la proposicin PERFORM al final de la tabla y con la proposicin
RETURN regresa de nuevo el control a la proposicin que sigue al GO TO en la
anterior.
1.2.3.1.2 rboles de decisin [12]
Un rbol de decisin es un modelo de prediccin utilizado en el mbito de la
inteligencia artificial, dada una base de datos se construyen estos diagramas de
construcciones lgicas, muy similares a los sistemas de prediccin basados en
reglas, que sirven para representar y categorizar una serie de condiciones que
suceden de forma sucesiva, para la resolucin de un problema. [13]
El rbol de decisin es un diagrama que representan en forma secuencial
condiciones y acciones; muestra qu condiciones se consideran en primer lugar,
en segundo lugar y as sucesivamente. Este mtodo permite mostrar la relacin
que existe entre cada condicin y el grupo de acciones permisibles asociado con
ella. [12]
La raz del rbol, aparece en la parte izquierda del diagrama y est es el punto
donde comienza la secuencia de decisin. La rama a seguir depende de las
condiciones existentes y de la decisin que debe tomarse. Al avanzar de izquierda
a derecha por una rama particular, se entiende una serie de toma de decisiones.
Despus de cada punto de decisin, se encuentra el siguiente conjunto de
decisiones a considerar. De tal forma que los nodos del rbol representan
condiciones y sealan la necesidad de tomar una determinacin relacionada con
la existencia de alguna de estas, antes de seleccionar la siguiente trayectoria. La
parte que se encuentra en la parte derecha del rbol indican las acciones que
deben realizarse, las que su vez dependen de la secuencia de condiciones que
les preceden.
24
Un rbol de decisin lleva a cabo un test a medida que este se recorre hacia las
hojas para alcanzar as una decisin. El rbol de decisin suele contener nodos
internos, nodos de probabilidad, nodos hojas y arcos. Un nodo interno contiene un
test sobre algn valor de una de las propiedades. Un nodo de probabilidad indica
que debe ocurrir un evento aleatorio de acuerdo a la naturaleza del problema, este
tipo de nodos es redondo, los dems son cuadrados. Un nodo hoja representa el
valor que devolver el rbol de decisin. y finalmente la ramas brindan los
posibles caminos que se tienen de acuerdo a la decisin tomada.
El desarrollo de rboles de decisin beneficia al analista en dos formas. Primero la
necesidad de describir condiciones y acciones lleva a los analistas a identificar de
manera formal las decisiones que actualmente deben tomarse. De esta forma, es
difcil para ellos pasar por alto cualquier etapa del proceso de decisin, sin
importar que este dependa de variables cuantitativas o cualitativas. Los rboles
tambin obligan a los analistas a considerar la consecuencia de las decisiones.
Se ha demostrado que los rboles de decisin son eficaces cuando es necesario
describir problemas con ms de una dimensin o condicin. Tambin son tiles
para identificar los requerimientos de datos crticos que rodean al proceso de
decisin, es decir, los rboles indican los conjuntos de datos que la gerencia
requiere para formular decisiones o tomar acciones. El analista debe identificar y
elaborar una lista de todos los datos utilizados en el proceso de decisin, aunque
el rbol de decisin no muestra todo los datos.
Si los rboles de decisin se construyen despus de completar el anlisis de flujo
de datos, entonces es posible que los datos crticos se encuentren definidos en el
diccionario de datos (el cual describe los datos utilizados por el sistema y donde
se emplean). Si nicamente se usan rboles de decisiones, entonces el analista
debe tener la certeza de identificar con precisin cada dato necesario para tomar
la decisin.
25
Los rboles de decisin no siempre son la mejor herramienta para el anlisis de

decisiones. El rbol de decisiones de un sistema complejo con muchas
secuencias de pasos y combinaciones de condiciones puede tener un tamao
considerable. El gran nmero de ramas que pertenecen a varias trayectorias
constituye ms un problema que una ayuda para el anlisis. En estos casos los
analistas corren el riesgo de no determinar qu polticas o estrategias de la
empresa son la gua para la toma de decisiones especficas. Cuando aparecen
estos problemas, entonces es momento de considerar las tablas de decisin.
Ejemplo: Algoritmo de construccin de rbol de decisin [13]
funcion Arbol-decision (ejemplos,atributos,default)
regresa un arbol de decisin
entradas:
ejemplos: Conjunto de ejemplos
atributos: conjunto de atributos
default: valor de default para el predicado meta
if ejemplos = vacio then regresa default
else if todos los ejemplos tienen la misma clasificacion
then regresa la clasificacion
else if atributos = vacio
then regresa VALOR-MAYORITARIO (ejemplos)
else
Mejor ESCOGE ATRIBUTO(atributos, ejemplos)
Arbol nuevo arbol de decisin con Mejor como raz para cada valor v i de Mejor do
Ejemplos {ejemplos con Mejor = i}
Subrbol
RBOL
DECISIN
(ejemplos i,
atributos-mejor,
VALORMAYORITARIO(ejemplos)) aade una rama a, Arbol con etiqueta v i y su arbol Subrbol
end
return arbol
26
Ambiente
Soleado
Lluvioso
Nublado
Humedad
Alta
Normal
Viento
P
Si
No
Figura 1.7 rbol de decisin para jugar Golf

Eduardo Morales Manzanares, Induccin de rboles de decisin [En lnea], Mxico [Consulta:
Mayo de 2007], <http://ccc.inaoep.mx/~emorales/Cursos/KDD03/
node16.html>
1.2.3.2 Diseo
En esta fase del ciclo de vida, se usa la informacin recolectada anteriormente
para realizar el diseo lgico de sistemas de informacin. En esta parte se
disean procedimientos precisos para la captura de datos, a fin de que los datos
que van a entrar al sistema de informacin sean correctos. Adems se debe de
proporcionar una entrada efectiva al sistema de informacin mediante el uso de
tcnicas para el buen diseo de formularios y pantallas.
Parte del diseo lgico del sistema de informacin es disear la interfaz de
usuario. La Interfaz conecta al usuario con el sistema y es, por lo tanto,
extremadamente importante. Ejemplos de interfaz de usuario:
Teclado para introducir preguntas y respuestas
Mens en pantalla para elegir u obtener comandos del usuario
Ratn o pantalla sensible al tacto para seleccionar opciones
La fase de diseo tambin incluye el diseo de archivos o bases de datos que

guardaran la mayor parte de los datos necesarios para los encargados en la toma
de decisiones de la organizacin. Una base de datos bien organizada es la base
para todos los sistemas de informacin. En esta fase se trabaja tambin con los
27
usuarios para disear la salida (en pantalla o impresa) que satisfaga las
necesidades de informacin.
Por ultimo se deben disear procedimientos de control y respaldo para proteger al
sistema y a los datos y producir paquetes de especificaciones de programa para
los programadores. Cada paquete debe contener diseos de entrada y salida,
especificaciones de archivos y detalles de procesamiento, y tambin pueden
incluir rboles o tablas de decisin, diagramas de flujos de datos, un diagrama de
flujo del sistema y los nombres y funciones de cualesquier de las rutinas de cdigo
que hayan sido escritas.
1.2.4 Programacin [1]

En esta fase del ciclo se trabaja con los programadores para desarrollar cualquier
software original que se necesite. Algunas de las tcnicas estructuradas para el
diseo y documentacin de software incluyen diagramas estructurados, el mtodo
HIPO (son las siglas de jerarqua entrada/proceso/salida), diagramas de flujo,
diagramas Nassi-Schneiderman y Warnier-Orr y Pseudocdigo. El analista de
sistemas usa uno o ms de estos dispositivos para comunicar al programador lo
que es necesario programar.
Durante esta fase, tambin se trabaja con los usuarios para desarrollar
documentacin del software como:
Manual de Usuario
Manual de Implementacin
Manual del sistema o Archivo lame
Ayuda en lnea
Sitios de preguntas frecuentes(FAQ, Frequently Asked Questions)
Archivo lame que se incluye en el software
28
La documentacin le dice al usuario la manera de usar el software y tambin que

hacer si se presentan problemas con el software.
Los programadores tienen un papel principal en esta fase conforme disean,
codifican y eliminan errores de sintaxis de los programas de computadora. Si el
programa va a ser ejecutado en un ambiente de macro-computadora, se debe
crear el lenguaje de control de trabajos (JCL, Job Control Language). Para
asegurar la calidad, un programador puede realizar ya sea un diseo o un ensayo
del cdigo, explicando las partes complejas del programa a otro equipo de
programadores.
1.2.5 Pruebas e Implementacin [1]

Pruebas
Antes de ser usado, debe ser probado el software. Es mucho menos

costoso encontrar problemas antes de que el sistema sea entregado a los
usuarios.
Algunas
de
las
pruebas
son
realizadas
solo
por
los
programadores, y otras en colaboracin con los analistas de sistemas.

Primero se ejecutan una serie de pruebas para que destaquen los
problemas con datos de ejemplo y eventualmente con datos reales del
software actual.
Implementacin
En esta fase del desarrollo del software el analista del sistema ayuda a
implementar el sistema de informacin. Esto incluye la capacitacin de los
usuarios para que manejen el sistema. La capacitacin es por parte del proveedor
o los fabricantes, pero la supervisin es responsabilidad del analista.
Adicionalmente, el analista necesita un plan para una conversin suave del
29
sistema antiguo al nuevo. Este proceso incluye una conversin de datos, la

instalacin de equipo y la puesta del nuevo sistema en produccin.
La evaluacin se muestra como parte de esta fase final de ciclo de vida del
desarrollo del sistema, principalmente para efectos de un debate. Aunque la
evaluacin se realiza durante cada fase. Un criterio principal que debe ser
satisfecho es si los usuarios ya estn usando el sistema.
Debemos hacer notar que a veces los sistemas trabajan en forma cclica. Cuando
un analista termina una fase del desarrollo de sistema y pasa a la siguiente, el
descubrimiento de un problema puede obligar a que el analista regrese a la fase
anterior y modifique el trabajo que ya hizo.
1.3 Estndar para el desarrollo de procesos del ciclo de vida

El estndar para los procesos del ciclo de vida describe en le conjunto de
actividades y procesos obligatorios para el desarrollo y mantenimiento del
software. El objetivo principal es establecer un marco comn para el desarrollo de
modelos de ciclo de vida.
1.3.1 Procesos y actividades
[2]
Un proceso es un conjunto de actividades que se realiza para un propsito

especifico (requerimientos, administracin, entrega) en total son 17 procesos que
son agrupados en niveles de abstraccin llamados grupos de procesos, se
muestran en la Tabla 1.1
Grupos de procesos
Modelado del ciclo de vida
Procesos
Seleccin de un modelo de ciclo de vida
Administracin del proyecto
Inicio del proyecto

Supervisin y control del proyecto
Administracin de la calidad del software
Predesarrollo
Exploracin de conceptos
Asignacin del sistema
30
Desarrollo
Requerimientos
Diseo
Implementacin
Posdesarrollo
Instalacin
Operacin y soporte
Mantenimiento
Retiro
Procesos integrales
Verificacin y validacin
Administracin de la configuracin del software
Desarrollo de la documentacin
Entrenamiento
Tabla 1.1 Grupos de procesos

Bruegge Brend, Dutoit Allen H, Ingeniera de software orientada a objetos, Ed Prentice Hall
Cada uno de los procesos se compone de actividades. Una actividad es una tarea
o grupo de subactividades que se asignan a un equipo o a un participante para
lograr un propsito especifico. Las tareas consumen recursos y crea un producto
de trabajo.
1.3.2 Modelado del ciclo de vida
[2]
Durante el proyecto el jefe o encargado del proyecto personaliza las actividades

para un proyecto especfico (una instancia del modelo de ciclo de vida). Cada
proyecto es diferente por esa razn no en todos los proyectos se requieren las
mismas actividades ni la misma secuencia. Por ejemplo, los proyectos que no
manejan el almacenamiento persistente no necesitan ejecutar la actividad del
Diseo de la base de datos.
1.3.3 Administracin del proyecto [2]

Durante la administracin del proyecto, el gerente del proyecto da inicio supervisa
y controla el proyecto por todo el ciclo de vida del software. La administracin
consta de tres procesos:
1.
Proceso de inicio del proyecto. Creacin de la infraestructura para el

proyecto. Durante este proceso se define el plan de tareas, la
calendarizacin, el presupuesto, la organizacin y el ambiente del proyecto
que incluye estndares del proyecto, infraestructura de comunicacin,
procedimientos de reunin y reporte, metodologa de desarrollo y las
31
herramientas de desarrollo. Toda la informacin generada durante este

proceso queda documentada en el plan de administracin del proyecto de
software (SPMP Software Project Management Plan). Este proceso finaliza
en cuanto se establece un ambiente constante para el proyecto.
2. Proceso de supervisin y control del proyecto. Asegura que el proyecto se
ejecute de acuerdo con el plan de tareas y el presupuesto. Si el encargado
del proyecto observa que hay desviaciones con respecto al calendario
tomara decisiones correctivas (reasignacin de recursos, cambio de
procedimientos o replaneacin de la calendarizacin). El SPMP se actualiza
para reflejar cualquiera de estos cambios. El proceso de supervisin y
control del proyecto esta activo durante todo el ciclo de vida.
3. Proceso de administracin de la calidad del software. Asegura que el
sistema que se esta construyendo satisfaga los estndares de calidad
requeridos (se seleccionaron durante el inicio del proyecto). Este proceso
queda bajo la ejecucin de de un equipo de administracin de la calidad
separado para evitar conflictos de inters. Este proceso esta activo durante
la mayor parte del ciclo de vida.
Proceso
Inicio del proyecto
Clusula
3.1.3
Establecimiento
de
Actividades
la correspondencia
entre
las
actividades y el modelo de ciclo de vida del software

3.1.4
Asignacin del recurso al proyecto
3.1.5
Establecimiento del ambiente del proyecto
3.1.6
3.2.3
Planeacin de la administracin del proyecto

Analizar riesgos
3.2.4
Realizar la planeacin de contingencias
3.2.5
Administrar el proyecto
3.2.6
Conservar registros
Administracin de la calidad del
3.2.7
3.3.3
Implementar el modelo de reporte de problemas

Planear la administracin de la calidad del software
software
3.3.4
Definir medidas
3.3.5
Administrar la calidad del software
3.3.6
Identificar las necesidades de mejora de calidad
Supervisin
control
del
proyecto
Las clusulas se refieren a un nmero de clusula de IEEE 1074.
Tabla 1.2 Procesos de la administracin del proyecto

Para poder reaccionar con rapidez ante los cambios y reportar problemas sin
introducir una sobre carga razonable, todos los participantes en el proyecto
32
necesitan estar concientes del flujo de informacin por el proyecto y de los

mecanismos para la diseminacin de la informacin.
1.3.4 Predesarrollo [2]

En el predesarrollo el cliente identifica una idea o una necesidad. Esto se resuelve
con un nuevo esfuerzo de desarrollo (ingeniera greenfield), con un cambio a la
interfaz de un sistema existente (ingeniera de interfaz) o con un reemplazo de
software de un proceso de negocios existente. El proceso de asignacin del
sistema establece la arquitectura inicial del sistema a e identifica el hardware, el
software y los requerimientos funcionales. Es necesario tomar en cuenta que la
descomposicin en subsistemas es la base de la infraestructura de comunicacin
entre los miembros del proyecto.
33
Proceso
Exploracin del concepto
Asignacin del sistema
Clusula
4.1.3
Actividades
Identificar ideas o necesidades
4.1.4
Formular enfoques potenciales
4.1.5
Realizar estudios de factibilidad
4.1.6
Planear la transicin del sistema (si es aplicable)
4.1.7
4.2.3
Refinar y analizar la idea o necesidad

Analizar funciones
4.2.4
Desarrollar la arquitectura del sistema
4.2.5
Descomponer los requerimientos del sistema
Tabla 1.3 Procesos del predesarrollo

1.3.5 Desarrollo [2]

El desarrollo consiste en los procesos que se dirigen a la construccin del
sistema.
Proceso de requerimientos. Se inicia con la descripcin informal de los

requerimientos y define los requerimientos del sistema desde le punto de
vista de los requerimientos funcionales de alto nivel, produciendo una
especificacin completa del sistema y dando la prioridad a los
requerimientos.
Proceso de diseo. Toma la arquitectura que se produjo durante el proceso

de asignacin del sistema y las especificaciones de los requerimientos y,
produce una representacin del sistema coherente y bien organizado. Las
actividades: realizar el diseo arquitectnico y disear interfaces, dan como
resultado un refinamiento de la descomposicin en subsistemas. Esto
incluye la asignacin de los requerimientos a los sistemas de hardware y
software, descripcin de las condiciones de frontera, seleccin de
componentes hechos y la definicin de los objetivos de diseo. El diseo
detallado se realiza en la actividad: Realizar diseo detallado. El proceso
de diseo da como resultado la definicin de los objetos de diseo, sus
atributos y operaciones y su organizacin en paquetes. Al finalizar esta
actividad se tienen definidos todos los mtodos y sus firmas de tipo.
Proceso de implementacin. Toma el modelo de diseo y produce una

representacin ejecutable equivalente. Este proceso incluye la planeacin
34
Ciclo de vida de un proyecto de software
de la integracin y las actividades de integracin. Las pruebas que se

toman en esta parte del desarrollo son independientes a las realizadas en
la verificacin.
Proceso
Requerimientos
Diseo
Implementacin
Clusula
5.1.3
Actividades
Definir y desarrollar los requerimientos de software
5.1.4
Definir los requerimientos de la interfaz
5.1.5
Establecer la prioridad e integrar los requerimientos de
5.2.3
software
Realizar el diseo arquitectnico
5.2.4
Disear la base de datos(si es aplicable)
5.2.5
Disear interfaces
5.2.6
Seleccionar o desarrollar algoritmos (si es aplicable)
5.2.7
5.3.3
Realizar el diseo detallado

Crear datos de prueba
5.3.4
Crear cdigo fuente
5.3.5
Crear cdigo objeto
5.3.6
Crear la documentacin operativa
5.3.7
Planear la integracin
5.3.8
Realizar la integracin
Tabla 1.4 Procesos del desarrollo

1.3.6 Posdesarrollo [2]

El posdesarrollo consta de los procesos de instalacin, mantenimiento, operacin,
soporte y retiro.
Durante la instalacin se distribuye e instala el software del sistema en el sitio del
cliente. La instalacin culmina con la prueba de aceptacin del cliente de acuerdo
con los criterios definidos en el acuerdo del proyecto.
El mantenimiento se encarga de la resolucin de errores, defectos y fallas del
software despus de la entrega del sistema. Requiere la elevacin de los
procesos y actividades del ciclo de ciclo de vida del software hacia un nuevo
proyecto.
El retiro elimina un sistema existente, dando por terminado sus operaciones y
soporte. Se reemplaza con uno nuevo. Para asegurar una transicin suave entre
35
los sistemas, a menudo se ejecutan las dos partes de retiro e instalacin hasta
que el usuario se acostumbra al nuevo.
36
Proceso
Instalacin
Operacin y soporte
Mantenimiento
Retiro
Clusula
6.1.3
Planear la instalacin
Actividades
6.1.4
Distribuir el software
6.1.5
Instalar el software
6.1.7
6.2.3
Aceptar el software en el ambiente operacional

Operar el sistema
6.2.4
Proporcionar asistencia tcnica y consultora
6.2.5
6.3.3
6.4.3
Mantenerla bitcora de peticiones de soporte

Volver a practicar el ciclo de vida del software
Notificar a los usuarios
6.4.4
Realizar operaciones paralelas (si es aplicable)
6.4.5
Retirar el sistema
Tabla 1.5 Procesos del posdesarrollo

1.3.7 Procesos integrales [2]

Durante todo el proyecto se realizan varios procesos. Al conjunto de estos
procesos se les llama procesos integrales o proceso de desarrollo cruzado.
Consta de los siguientes procesos:
Validacin y verificacin. La tarea de verificar se enfoca en mostrar que los

modelos del sistema se apegan a las especificaciones; incluye revisiones,
auditorias e inspecciones. La validacin asegura que el sistema resuelva
las necesidades del cliente e incluyen la prueba del sistema, las pruebas
beta y la prueba de aceptacin del cliente. La validacin y verificacin
durante todo el desarrollo del sistema detectando anomalas
Administracin de la configuracin del software. Esta parte se enfoca en el

seguimiento y control de los cambios a los productos de trabajo. Los
elementos en la administracin de la configuracin
incluyen el cdigo
fuente del sistema, todos los modelos de desarrollo, el plan de

administracin del proyecto de software y todos los documentos visibles
para los participantes en el proyecto.
Desarrollo de la documentacin. Este proceso trata con los productos de

trabajo (excluyendo el cdigo) que documentan los resultados producidos
por los dems procesos. Las plantillas de documentos se seleccionan
durante esta actividad.
37
Entrenamiento. En este proceso se planea el programa de entrenamiento.

Desarrollar su material, validar que sea el adecuado e implementar el
programa de entrenamiento.
38
BIBLIOGRAFA
[1] Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6
edicin
[2] Bruegge Brend, Dutoit Allen H, Ingeniera de software orientada a objetos, Ed Prentice Hall
REFERENCIAS WEB
[3] Wikipedia Foundation Inc, Sistema [En lnea], St. Petersburg EUA [Consulta: Abril de 2007]
<http://es.wikipedia.org/wiki/Sistema>
[4] GIOUPM, Copyright, Sistemas de informacin [En lnea], Espaa [Consulta: Febrero de
2006]
<http://tecnologias.gio.etsit.upm.es/sistemas-informacion/clasificacion-de-los-
sistemas-de-informacion-79.asp>
[5] Wikipedia Foundation Inc, Informacin [En lnea], St. Petersburg EUA [Consulta: Febrero
de 2007] <http://es.wikipedia.org/wiki/Informacin>
[6] Wikipedia Foundation Inc, Sistema de informacin [En lnea], St. Petersburg EUA
[Consulta: Febrero de 2007], <http://es.wikipedia.org/wiki/Sistema_de_informacin>
[7] Alfredo Garca, Universidad abierta, Anlisis y desarrollo de Sistemas [En lnea], Mxico
[Consulta: Febrero de 2006], <http://www.universidadabierta.edu.mx/Biblio/G/AnYDesSisGarcia.htm>
[8] Business School Ltda, Sistema [En lnea], Bogot Colombia [Consulta: Febrero de 2006]
<http://www.businesscol.com/productos/glosarios/administrativo/glossary.php?
word=SISTEMA>
[9] Orange Copyright 2007, Administracin de Sistemas de Informacin [En lnea] , Miami, FL
EUA [Consulta: Febrero 2006] <http://html.rincondelvago.com/administracion-de-sistemasinformaticos.html>
[10]Jos M Alessandro, Universidad Nacional de la Plata, Tablas de decisin [En lnea],
Buenos Aires Argentina [Consulta: Mayo de 2007], <http://www.contabilidad.econo.
unlp.edu.ar/637/paginas_web/06_materiales/tablasdecision.pdf>
[11]Hernndez Velsquez Jess de Israel , Copyright Ilustrados, Actividades en la
planeacin de sistemas de informacin [En lnea], [Consulta: Mayo de 2007],
<http://www.ilustrados.com/publicaciones/EpZZyuFkylXVwENorb.php>
[12]Hernndez Velsquez Jess de Israel, Soto fuentes Marco Antonia , Monografas Lucas
Morea, Sinexi SA , Actividades en la planeacin de sistemas de informacin[En lnea],
[Consulta: Mayo de 2007], <http://www.monografias.com/trabajos6/sisin/sisin.shtml>
[13]Eduardo Morales Manzanares, Induccin de rboles de decisin [En lnea], Mxico
[Consulta: Mayo de 2007], http://ccc.inaoep.mx/~emorales/Cursos/KDD03/node16.html
39
3.1 El enfoque estructurado

3.1.1 Diagramas de flujos de datos [3]
El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de
especificacin sencillo de implantar, fcil comprensin y comunicacin.
El DFD fue desarrollado por De Marco en los aos 70s y fue popularizado por
Yourdan. Es un mtodo de especificacin utilizado hasta la fecha. Para empezar se
puede preguntar Que son los diagramas de flujos de Datos?
Un diagrama de flujo de datos (DFD) es una representacin grfica de los
procesos que se realizan con los datos en su organizacin, con el uso de tan solo
cuatro smbolos, se puede crear una descripcin grafica de los procesos que, con
el tiempo, contribuirn a desarrollar una slida documentacin del sistema.
En seguida mencionan las ventajas sobre las explicaciones descriptivas en relacin
con la forma en que los datos se mueven a travs del sistema:
1. Libertad para emprender la implementacin tcnica del sistema en las
primeras etapas.
2. Comprensin ms profunda de la interrelacin entre sistemas y
subsistemas.
3. Comunicacin con los usuarios sobre el conocimiento del sistema actual
mediante diagramas de flujos de datos.
4. Anlisis de un sistema propuesto para determinar si se han definido los
datos y procesos necesarios.
La ventaja ms grande es la libertad conceptual para utilizar los cuatro smbolos,
los DFDs hacen nfasis en el procesamiento o la transformacin conforme estos
pasan por una variedad de procesos. En los DFDs lgicos no hay distincin entre
procesos manuales o automatizados. Los procesos tampoco se representan
40
grficamente en orden cronolgico. En vez de ello, se agrupan solo si el anlisis

detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los
procesos automatizados tambin se pueden agrupar.
3.1.1.1 Simbologa
En los diagramas de flujos de datos se usan cuatro smbolos bsicos para graficar
el movimiento de los datos: Un cuadrado doble, una flecha, un rectngulo con
esquinas redondeadas(o una burbuja) y un rectngulo abierto (cerrado en el lado
izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a
continuacin. Con la combinacin de estos cuatro smbolos se puede describir
grficamente un sistema completo y varios subsistemas.
Entidad
Flujo de datos
Proceso
Almacn de datos
Figura 3.1 Simbologa
Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 ed
El cuadrado doble se usa para describir una entidad externa (otro departamento,
un negocio, una persona o una maquina) que puede enviar datos al sistema o
recibirlos de el. La entidad externa, o solo entidad, tambin se llama origen o
destino de datos, y se considera externa al sistema descrito. A cada entidad se le
41
asigna un nombre adecuado. Aunque interacta con el sistema, se considera fuera

de los lmites de este. La misma entidad se podra usar ms de una vez en un
diagrama de flujo de datos en particular para evitar que las lneas se crucen en el
flujo de datos.
La flecha muestra el movimiento de los datos de un punto a otro, con la punta de
la flecha sealando hacia el destino de los datos. Los flujos de datos que ocurren
simultneamente se pueden describir mediante flechas paralelas. Una flecha
tambin puede se debe describir con un nombre, debido a que representan los
datos de un apersona, lugar o cosa.
Rectngulo con esquinas redondeadas se usa para mostrar la presencia de un
proceso de transformacin. Los procesos siempre denotan un cambio en los datos
o una transformacin de estos; por lo tanto el flujo de datos que sale de un proceso
siempre se designa de forma diferente al que entra en el. Los procesos
representan trabajo que se realiza en el tema y se deben nombrar usando uno de
los formatos siguientes:
Se le debe asignar un nombre claro ya que este permite reconocer

fcilmente lo que hace un proceso.
1. A los procesos de alto nivel asigna el nombre del sistema. Por
ejemplo: SISTEMA DE CONTROL DE VENTAS.
2. Para nombrar un subsistema principal, se usa un nombre como
SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE
CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET.
3. Para los procesos detallados se usa un formato de sustantivo-verboadjetivo. El sustantivo indica cual es el resultado principal del
proceso, tal como INFORME O REGISTRO. El verbo describe el tipo
de actividad, tal como CALCULAR, VERIFICAR, PREPARAR,
IMPRIMIR O AGREGAR. El adjetivo describe el resultado especfico
que se produce tal como NUEVO PEDIDO o INVENTARIO. Ejemplos
de nombres de procesos son CALCULAR IMPUESTOS DE VENTAS,
42
VERIFICAR ESTADOS DE CUENTA DEL CLIENTE, PREPARAR

FACTURA DE ENVIO, IMPRIMIR INFORME DE NUEVOS PEDIDOS,
ENVIAR
CONFIRMACION
AL
CLIENTE
POR
CORREO
ELECTRONICO, VERIFICAR SALDO DE TARJETA DE CREDITO Y

AGREGAR REGISTRO DE INVENTARIO.
A un proceso se le debe de asignar un nmero de identificacin nico y

exclusivo, que indique su nivel en el diagrama. Podra haber varios flujos
de datos que entren y salgan de cada proceso. Los procesos con solo un
flujo de entrada y salida se deben examinar en busca de flujos de datos
perdidos.
El rectngulo abierto representa un almacn de datos. Estos smbolos se

dibujan con el espacio suficiente para que quepan las letras de identificacin como
se muestra en la figura. En los diagramas de flujo de datos lgicos no se especifica
el tipo de almacenamiento a un lugar. En este punto el smbolo del almacn de
datos simplemente muestra un lugar de depsito
para los datos que permite
examinar, agregar y recuperar datos.

El almacn de datos podra representar un almacn manual, tal como un gabinete
de archivo, un archivo o una base de datos de computadora. A los almacenes de
datos se les asigna un nombre debido a que representan a una persona, lugar o
cosa. Los almacenes de datos temporales, tales como papel borrador o un archivo
temporal de computadora, no se incluyen en el diagrama de flujo de datos. Para
identificar el nivel del almacn de datos, a cada uno asgnele un nmero de
referencia nica, tal como D1, D2, D3 etc.
3.1.1.2 Desarrollo de Diagramas de Flujos de Datos [3]
43
Los diagramas de flujos de datos se pueden y deben dibujar de manera

sistemtica. Primero se deben visualizar los flujos de datos desde una perspectiva
jerrquica de arriba a bajo. En seguida se describen los pasos a seguir.
Lista de actividades [3]
Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa(o
historia) del sistema de la organizacin en una lista con las cuatro categoras de
entidad externa, flujo de datos, procesos, y almacn de datos. Esta lista a su vez
ayudara a determinar los lmites del sistema que describir. Una vez que se haya
recopilado una lista bsica de elementos de datos se empieza a dibujar el
diagrama de contexto.
Creacin de diagrama de contexto [3]
Con un enfoque jerrquico de arriba hacia abajo para diagramar el movimiento de
los datos, los diagramas van de lo general a lo especfico. Aunque el primer
diagrama ayuda a entender el movimiento bsico de los datos, lo general de su
naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar un
panorama global que incluya las entradas bsicas, el sistema general y las salidas.
Este diagrama ser el mas general, con una visin muy superficial del movimiento
de los datos en el sistema y una visualizacin lo mas amplia posible del sistema. El
diagrama de contexto es el nivel ms alto en un diagrama de flujo de datos y
contiene un solo proceso, que representa a todo el sistema. Al proceso se le asigna
el numero cero. En este diagrama se muestran todas las entidades externas, as
como los flujos de datos principales que van desde y hacia dichas entidades. El
diagrama no contiene ningn almacn de datos. Es bastante simple la creacin ya
que se conocen las entidades externas y el flujo de datos desde y hacia ellas.
Dibujo del diagrama 0 (el siguiente nivel) [3]
44
Al ampliar los programas se puede lograr un mayor detalle que con los diagramas
de contexto. Las entradas y salidas especificadas en el primer diagrama
permanecen constantes en todos los diagramas que le siguen. Sin embargo, el
resto del diagrama original se amplia para incluir de tres a nueve procesos y
mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada
diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para
representar subprocesos, en este paso se empiezan a completar los detalles del
movimiento de los datos. El manejo de excepciones se ignora en los primero dos o
tres niveles del diagrama de flujo de datos.
Entrada A
Entidad 1
Salida C
Nombre
del
Sistema
Entrada B
Entidad 3
Entidad 2
1
Entrada A
Proceso
general
AAA
Entidad 1
Flujo de
datos B
Proceso
general
BBB
Registro A
D1
Almacn de
Almacn de
Datos 2
Registro A
3
Entrada B
Entidad 2
Proceso
general
CCC
Entidad 3
Registro E
D2
Datos 2
Salida C
Registro E
4
Flujo de
datos D
Proceso
general
DDD
Figura 3.2 Representacin del diagrama de contexto y del diagrama cero

El diagrama cero es la ampliacin del diagrama de contexto y puede incluir hasta

nueve procesos, esto se hace porque si se agregan ms procesos producir un
45
diagrama difcil de entender. Por lo general, cada proceso se numero con un

entero, empezando en la esquina superior izquierda del diagrama y terminando en
la esquina inferior derecha. En el diagrama cero se incluyen los principales
almacenes de datos del sistema (que representan a los archivos maestros) y todas
las entidades externas. La figura 3.2 representa grficamente el diagrama de
contexto y el diagrama cero.
Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal),
se puede empezar en cualquier punto del diagrama e ir hacia delante o hacia atrs.
Si no esta seguro de lo que podra incluir en cualquier punto, tome una entidad
externa, un proceso o un almacn de datos diferente y empiece a dibujar el flujo a
partir de l:
1. Empezamos con el flujo de datos de una entidad en el lado de la entrada. Se
hacen preguntas como: Qu sucede con los datos que entran en el
sistema? Se almacenan? Esta entrada es para varios procesos?
2. Trabajamos hacia atrs a partir de un flujo de datos de salida. Examinamos
los campos de salida de un documento o pantalla. (Este enfoque es ms
sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la
salida: "De dnde viene?" o "Se calcula o almacena en un archivo?" Por
ejemplo, cuando la salida es un RECIBO DE NOMINA, el NOMBRE DEL
EMPLEADO y la DIRECCION se podran localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podran encontrarse en un REGISTRO
DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendran que
calcular. Cada archivo y registro estara conectado al proceso que produce
el recibo de nmina.
3. Examinamos el flujo de datos desde o hacia un almacn de datos. Se
pregunta: "Qu procesos ponen los datos en el almacn?" o "Qu
procesos usan los datos?" Observamos que un almacn de datos utilizado
en el sistema en el que se esta trabajando podra ser producido por un
sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya
ningn flujo de datos hacia el almacn de datos.
46
4. Analizamos un proceso bien definido. Vea qu entrada de datos necesita el

proceso y qu salida produce. Se hace un vnculo la entrada y la salida con
los almacenes de datos y las entidades adecuadas.
5. Tome nota de cualquier rea confusa en donde no est seguro de lo que se
debe incluir o de la entrada o la salida que se requiera. Al conocer las reas
problemticas podr realizar una lista de preguntas para las entrevistas de
seguimiento con los usuarios clave.
Creacin de diagramas hijos (niveles mas detallados) [3]
Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un
diagrama hijo ms detallado. El proceso del Diagrama cero a partir del cual se
realiza la ampliacin se llama proceso padre, y el diagrama que se produce se
llama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibrio
vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir
entrada que el proceso padre no produzca o reciba tambin.
Todos los flujos de datos hacia dentro o hacia fuera del proceso padre se deben
mostrar fluyendo hacia dentro o hacia fuera del diagrama hijo.
Al diagrama hijo se le asigna el mismo numero que a su proceso padre en el
Diagrama cero. Los procesos del diagrama hijo se numeran usando el numero del
proceso padre, un punto decimal y un solo numero para cado proceso hijo. Con
esto se puede localizar una serie de procesos a travs de muchos niveles de
ampliacin. Si el diagrama cero presenta los procesos 1, 2 y 3 los diagramas hijos
1, 2 y 3 estarn en el mismo nivel.
Por lo regular las entidades no se muestran en los diagramas hijos debajo del
diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujo de
datos de interfaz y se representa con una flecha que parte de un rea vaca del
diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacn
de datos, tambin el diagrama hijo podra incluir el almacn de datos. Adems, este
diagrama de nivel inferior podra contener almacenes de datos que no se muestran
47
en el proceso padre. Por ejemplo se podran incluir un archivo que contenga una
tabla de informacin, como una tabla de impuestos, o un archivo que conecta dos
procesos del diagrama hijo. En un diagrama hijo se podran incluir un flujo de datos
de nivel inferior, como una lnea de error, aunque no se podra hacer lo mismo en el
proceso padre.
Los procesos se podran ampliar o no ampliar, dependiendo de su nivel de
complejidad. Cuando no se amplia un proceso, se dice que es funcionalmente
primitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detallados
de un diagrama de flujos de datos hijo. [3]
Revisin de Errores en lo diagramas [3]
Cuando se dibujan diagramas de flujos de datos se pueden cometer varios errores
comunes como los siguientes:
1. Olvidar incluir un flujo de datos o apuntar con una flecha en la direccin
incorrecta. Un ejemplo es un proceso dibujado que muestra todos sus flujos
de datos como entrada o salida. Cada proceso transforma datos y debe
recibir una entrada y producir una salida. Este tipo de error ocurre
generalmente cuando el analista olvida incluir un flujo de datos o coloca una
flecha que apunta en la direccin incorrecta.
2. Conectar directamente entre s almacenes de datos y entidades externas.
Los almacenes de datos y las entidades externas no se deben conectar
entre s; slo se deben conectar con un proceso. Un archivo no interacta
con otro archivo sin la ayuda de un programa o una persona que mueva los
datos. Las entidades externas no trabajan directamente con los archivos.
Dos entidades externas conectadas directamente indican que desean
comunicarse entre s. Esta conexin no se incluye en el diagrama de flujo
de datos a menos que el sistema facilite la comunicacin. La elaboracin de
un informe es un ejemplo de esta clase de comunicacin. Sin embargo, es
necesario interponer un proceso entre las entidades para producir el
informe.
48
Almacn de
D1
Datos 1
El flujo de datos
coincidente
Registro A
Entidad 2
Entrada B
Flujo de
datos D
Proceso
general
CCC
Proceso
general
DDD
El flujo de datos
del proceso padre
debe coincidir con
el diagrama hijo
D1
Datos 1
Registro A
Registro
de
transaccin
1
Registro
de
transaccin
3.1
Entrada B
Almacn de
Proceso
XXX
detallado
D5
Archivo de
Transaccin 1
3
Proceso
YYY
detallado
Flujo de datos
Z detallado
Error
En los diagramas
de nivel inferior se
podran agregar
archivos de
transacciones
En un diagrama
hijo detallado se
podran agregar
lneas de error
El flujo de salida
debe coincidir con
el proceso padre
3
Proceso
general
CCC
Flujo de datos D
Figura 3.3 Representacin del diagrama de contexto y del diagrama cero

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Es necesario

revisar el diagrama flujo de datos para asegurar que cada objeto o flujo de
datos tenga un nombre adecuado. Un proceso debe indicar el nombre del
sistema o usar el formato sustantivo-verbo-adjetivo. Cada flujo de datos se
debe describir con un sustantivo.
4. Incluir ms de nueve procesos en un diagrama de flujo de datos. La
inclusin de demasiados procesos origina un diagrama confuso difcil de
entender y obstaculiza la comunicacin en lugar de facilitada. Si en un
49
sistema existen ms de nueve procesos, agrupe en un subsistema algunos

de los procesos que trabajan en conjunto y pngalos en un diagrama hijo,
5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es
decir, flujo de datos en el cual cada proceso tiene slo una entrada y una
salida. El flujo de datos lineal no es muy comn, excepto en los diagramas
de flujo de datos hijos muy detallados, su presencia normalmente indica que
al diagrama le falta algn flujo de datos.
6. Crear una separacin (o ampliacin) desequilibrada en los diagramas hijos.
Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida
que el proceso padre, Una excepcin a esta regla son las salida menores,
como las lneas de error, que se incluyen solamente en el diagrama hijo.
En seguida se sintetizan los pasos para desarrollar eficazmente diagramas de flujo
de datos, usando un enfoque jerrquico de arriba a bajo:
1. Haga una lista de las actividades del negocio y sela para determinar lo
siguiente:
Entidades externas
Flujos de datos
Procesos
Almacn de datos
2. Crear un diagrama de contexto que muestre las entidades externas y los

flujos de datos desde y hacia el sistema. No muestre ejemplos ni almacenes
de datos detallados.
3. Dibujar el diagrama 0(el siguiente nivel). Muestre procesos, pero que sean
generales. En este nivel muestre almacenes de datos.
4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0
5. Revise que no haya errores y asegrese de que sean significativos los
nombres que haya asignado a cada proceso y flujo de datos.
6. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de flujo
de datos lgico. Distinga entre los procesos manuales y automatizados,
50
describa los archivos reales y los informes por nombre y agregue controles
para indicar cuando se completan los procesos o cuando ocurren errores.
7. Ahora se hace una particin el diagrama de flujo de datos fsico separando o
agrupando sus partes con el propsito de facilitar la programacin y la
implementacin.
3.1.1.3 Diagramas de flujos de datos lgicos y fsicos [3]

Los diagramas de flujo de datos se catalogan como lgicos o fsicos. Un diagrama
de flujo de datos lgico se enfoca en el negocio y en el funcionamiento de ste. No
se ocupa de manera en que se construir el sistema. Ms bien, describe los
eventos que ocurren en el negocio y los datos requeridos y producidos por cada
evento. Por el contrario, un diagrama de flujo de datos fsico muestra cmo se
implementar el sistema, incluyendo el hardware, el software, los archivos y las
personas involucradas en el sistema. En la Tabla 3.1 se muestra un cuadro que
compara las caractersticas de los modelos lgico y fsico. Observe que el modelo
lgico refleja el negocio, mientras que el modelo fsico describe el sistema.
Caractersticas del
diseo
Lgico
Fsico
Que describe el modelo
Como funciona el negocio
Como se implementar el
sistema (o como funciona el
sistema actual)
Que representan los

procesos
Las actividades del negocio
Programas, mdulos del

programa y procedimientos
manuales
Que representan los

almacenes de datos
Colecciones de datos
independientemente de
como se almacenan.
Archivos y bases de datos

fsicos, archivos manuales
Tipos de almacenes de
datos
Muestra almacenes de
datos que representan
colecciones de datos
permanentes
Archivos maestros, archivos

de transicin. Cualesquier
proceso que operen en dos
momentos diferentes deben
conectarse mediante un
almacn de datos
Que representan los

almacenes de datos
Que representan los

almacenes de datos
Muestra controles para

validar los datos de entrada,
para obtener un registro (el
estado de un registro), para
asegurar la realizacin
exitosa de un proceso y
para la seguridad del
sistema
Tabla 3.1 Caractersticas modelos lgicos y fsicos

51
Diagrama de
flujo de
datos lgico
actual
Obtenga el diagrama de flujo de datos lgico para el

sistema actual examinando el diagrama de flujo de datos
fsico y separando las actividades nicas del negocio
Nuevo
diagrama
de flujo de
datos
lgico
Cree el diagrama de flujo de datos lgico para el nuevo

sistema agregando al diagrama de flujo de datos lgico
del sistema actual las entradas, salidas y procesos
requeridos en el nuevo sistema
Nuevo
diagrama
de flujo de
datos fsico
Obtenga el diagrama de flujo de datos fsico examinando

los nuevos procesos en el nuevo diagrama lgico.
Determine en donde deben existir la interfaz de usuario,
la naturaleza de los procesos y los almacenes de datos
necesarios
Tabla 3.2 Progresin del diagrama de flujo de datos
Una ventaja de construir el diagrama de flujo de datos lgico del sistema actual es
que puede usar para crear el diagrama de flujo de datos lgico del nuevo sistema.
Los procesos innecesarios en el nuevo sistema se podran eliminar y agregar
nuevas caractersticas, actividades, salidas, entradas y datos almacenados.
Mediante este enfoque se garantiza que el nuevo sistema conservar las
caractersticas esenciales del sistema anterior. Adems, el uso del modelo lgico
del sistema actual como base para el sistema propuesto ofrece una transicin
gradual para el diseo del nuevo sistema, Una vez desarrollado el modelo lgico
para el nuevo sistema, se podra usar para crear un diagrama de flujo de datos
fsico par tal sistema.
Desarrollo de diagramas de flujo de datos lgicos [3]
Para desarrollar un diagrama de este tipo, primero se construye un diagrama de
flujo de datos para el sistema actual. Hay varias ventajas al usar un modelo lgico,
entre ellas:
1. Mejor comunicacin con los usuarios.
2. Sistemas ms estables.
52
3. Mejor entendimiento del negocio por parte de los analistas.

4. Flexibilidad y mantenimiento.
5. Eliminacin de redundancias y creacin ms sencilla del modelo fsico.
Es ms fcil usar un modelo lgico al comunicarse con los usuarios del sistema
porque se centra en las actividades del negocio. En consecuencia los usuarios
estarn familiarizados con las actividades principales y con muchos de los
requerimientos de informacin de cada actividad.
Los diagramas de flujos de datos lgicos representan caractersticas de un sistema
que deberan existir sin importar cuales sean los medios fsicos para llevarlas a
cabo.
Desarrollo de diagramas de flujos de datos fsicos [3]
Despus de desarrollar el modelo lgico del nuevo sistema, se puede usar para
crear un diagrama de flujo de datos fsico. El diagrama de flujo de datos fsico
muestra como se crear el sistema, y generalmente contiene la mayora, si no es
que todos, de los elementos siguientes:
Procesos manuales
Procesos para agregar, eliminar, cambiar y actualizar registros.
Procesos de entrada y verificacin de datos
Procesos de validacin para garantizar la precisin de la entrada de datos
Distribucin de los procesos para reorganizar el orden de los registros
Procesos para producir cada salida nica del sistema
Almacenes de datos intermedios
Nombres de archivos reales para almacenar datos
Controles para describir la terminacin de tareas o condiciones de error
Los diagramas de flujo de datos fsicos tienen las siguientes ventajas.

53
1. Aclara qu procesos son manuales y cules son automatizados.

2. Describe los procesos con mayor detalle que los DFDs lgicos.
3. Distribuye en un orden particular los procesos que se deben realizar.
4. Identifica los almacenes de datos temporales.
5. Especifica los nombres reales de archivos y documentos impresos.
6. Agrega
controles
para
asegurar
que
los
procesos
se
realicen
adecuadamente
A menudo estos diagramas son tan complejos debido a la gran cantidad de
almacenes de datos que incluye un sistema. Frecuentemente se usan la siglas
CLAE (CRUD: Create, Read, Update and Delete) para denotar las actividades
Crear, Leer, Actualizar y Eliminar, que un sistema debe ejecutar en cada archivo
maestro. Una matriz CLAE es una herramienta que sirve para representar en que
parte del sistema ocurre cada uno de estos procesos.
Los diagramas de flujo de datos fsicos tambin tienen almacenes de datos
intermedios, con frecuencia un archivo de transaccin o una tabla de base de datos
temporal. A menudo, los almacenes de datos intermedios consisten en archivos de
transaccin que se utilizan para almacenar datos entre procesos. Dado que es
poco probable que la mayora de los procesos requieren acceso a un conjunto
determinado de datos se ejecuten al mismo tiempo, los archivos de transaccin
deben guardar los datos de un proceso para luego enviarlo al siguiente.
Tambin se puede incluir informacin relacionada con el tiempo. Por ejemplo, un
DFD fsico podra indicar que un programa de edicin se debe ejecutar antes que
un programa de actualizacin. Las actualizaciones deben ejecutarse antes que la
elaboracin de un informe resumido, o un pedido debe ingresarse en un sitio Web
antes de verificar con la institucin financiera la cantidad cargada a una tarjeta de
crdito. A causa de estas consideraciones, un diagrama de flujo de datos fsico
podra tener una apariencia ms lineal que la de un modelo lgico.
54
Se debe de crear el diagrama de flujo de datos fsico para un sistema mediante el

anlisis de su entrada y su salida. Al crear un diagrama de flujo de datos fsico, el
flujo de datos de entrada proveniente de una entidad externa en ocasiones se
denomina detonador porque inicia las actividades de un proceso, y el flujo de datos
de salida de una entidad externa se denomina respuesta porque se enva como
resultado de alguna actividad. Se determina qu campo o elementos de datos es
necesario teclear. Estos campos se denominan elementos bsicos y se deben
almacenar en un archivo. Los elementos que no se teclean sino que son resultados
de un clculo o de una operacin lgica se conocen como elementos derivados.
3.1.1.4 Particionamiento de los diagramas de flujos de datos [3]

Este es un proceso de examinar un diagrama de flujo de datos y se determina
como se debe dividir en colecciones de procedimientos manuales y colecciones de
programas de cmputo. Analice cada procedo para determinar si debe ser un
proceso manual o automatizado. Agrupe los procedimientos automatizados en una
serie de programas de cmputo. Usualmente se traza una lnea punteada
alrededor de un proceso o grupo de procesos que deben colocarse en un solo
programa de cmputo.
Existen seis razones para particionar diagramas de flujos de datos:
1. Diferentes grupos de usuarios. Los procesos son realizados por varios
grupos de usuarios diferentes, con frecuencia en distintas ubicaciones
fsicas de la compaa?. Si es as, se deben particionar en diferentes
programas de cmputo.
2. Sintonizacin. En esta parte se debe examinar que los procesos se
sincronicen. Si dos procesos se realizan en diferentes momentos, no se
puede agrupar en un programa.
3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible
agruparlos en un solo programa de cmputo.
55
4. Eficiencia. En un programa se podra combinar varios procesos para realizar

un procesamiento eficiente.
5. Consistencia de los datos. Los procesos se podran combinar en un solo
programa para mantener la consistencia de los datos.
6. Seguridad. Los procesos se podran particionar en diferentes programas por
razones de seguridad.
3.1.2 Diccionarios de datos [3]

El diccionario de datos surge de la necesidad de catalogar los procesos, flujos
almacenes estructuras y elementos de datos. Los nombres que se usan son muy
importantes. Cuando se tiene la oportunidad de asignar nombre a los componentes
de los sistemas orientados a datos, es necesario trabajar en la creacin de un
nombre significativo pero diferente al de otros componentes de datos existentes.
Se ha propuesto el diccionario de datos como gramtica casi formal para describir
el contenido de los objetos definidos durante el anlisis estructurado. Esta notacin
ha sido definida de la siguiente forma por Yourdon en 1989:
El diccionario de datos es un listado organizado de todos los elementos de datos
que son pertinentes para el sistema, con definiciones precisas y rigurosas que
permiten que el usuario y el analista del sistema tenga una misma comprensin de
las entradas, salidas, de los componentes de los almacenes y tambin los clculos
intermedios. [2]
Muchos sistemas de administracin de base de datos estn equipados con un
diccionario de datos automatizado. Estos diccionarios pueden ser complejos o
sencillos,
algunos
diccionarios
de
datos
computarizados
catalogan
automticamente los elementos de datos cuando se hace la programacin; otros

simplemente proporcionan una plantilla para motivar a la persona que llene el
diccionario a que lo haga de una manera uniforme para cada entrada.
56
A pesar de la existencia de los diccionarios de datos automatizados, entender qu

datos conforman un diccionario de datos, las convenciones usadas en estos
ltimos y cmo se desarrolla un diccionario de datos, son problemas que el analista
de sistemas debe tener siempre presentes durante el esfuerzo de sistemas.
Entender el proceso de compilar un diccionario de datos puede ayudar al analista
de sistemas a visualizar el sistema y su funcionamiento.
Adems de proporcionar documentacin y eliminar la redundancia, el diccionario
datos se podra usar para:
1. Validar la integridad y exactitud del diagrama de flujo de datos.
2. Proporcionar un punto de partida para desarrollar pantallas e informes,
3. Determinar el contenido de los datos almacenados en archivos.
4. Desarrollar la lgica para los procesos del diagrama de flujo de datos,
3.1.2.1 Depsito de datos [3] [2]

Aunque el diccionario de datos contiene informacin de los datos y procedimientos,
una coleccin ms grande de informacin de proyectos se llama depsito, El
concepto depsito es uno de los muchos impactos de las herramientas CASE y
podra contener lo siguiente:
1. Informacin sobre los datos mantenidos por el sistema, incluyendo flujos de
datos, almacenes de datos, estructuras de registros y elementos.
2. Lgica de procedimientos.
3. Diseo de pantallas e informes.
4. Relaciones entre datos, por ejemplo cmo se vincula una estructura de
datos con otra.
5. Requerimientos del proyecto y productos del sistema final.
6. Informacin sobre la administracin del proyecto, tal como itinerarios de
entrega," problemas pendientes de solucin y usuarios del proyecto.
57
Por lo general, los flujos de datos son los primeros elementos que se definen. Las
entradas y salidas del sistema se determinan mediante las entrevistas y la
observacin de los usuarios, y el anlisis de documentos y de otros sistemas
existentes. La informacin capturada se puede resumir usando un formulario que
contenga la siguiente informacin:
1. ID, un numero de identificacin opcional. A veces este se codifica usando un
esquema para identificar el sistema y la aplicacin del sistema.
2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto
que debe aparecer en el diagrama y se debe referenciar en todas las
descripciones que usen el flujo de datos.
3. Un a descripcin general del flujo de datos.
4. La fuente del flujo de datos. Esta podra ser una entidad externa, un proceso
o influjo de datos proveniente de un almacn de datos.
5. El destino del flujo de datos. Esta podra ser una entidad externa, un
proceso o influjo de datos proveniente de un almacn de datos.
6. Algo que indique si el flujo de datos es un registro que esta entrando o
saliendo de un archivo o un registro que contiene un informe, formulario o
pantalla. Si el flujo de datos contiene datos que se usan entre los procesos,
se designa como interno.
7. El nombre de la estructura de datos que describe los elementos encontrados
en este flujo de datos. Para un flujo de datos simple, podran ser uno o
varios elementos.
8. el volumen por unidad de tiempo. Los datos podran ser registros por da o
cualquier otra unidad de tiempo.
9. Un rea para comentarios adicionales y anotaciones sobre el flujo de datos.
58
Descripcin de las estructuras de datos [3]

Normalmente las estructuras de datos se describen usando una notacin
algebraica. Este mtodo permite al analista producir la vista de los elementos que
constituyen la estructura de datos junto con informacin referente a dichos
elementos. La notacin algebraica usa los siguientes smbolos:
1. Un signo de igual (=) significa esta compuesto de.
2. Un signo de suma (+) significa y.
3. Las llaves { } indican elementos repetitivos, tambin llamados grupos de
repeticin o tablas. En el grupo podra haber un elemento de repeticin o
varios de ellos. El grupo de repeticin podra tener condiciones, tal como un
nmero fijo de repeticiones o limites superiores e inferiores para el nmero
de repeticiones.
4. Los corchetes [ ] representan una situacin de uno u otro. Se podra
representar un elemento u otro, pero no ambos. Los elementos listados
entre los corchetes son mutuamente excluyentes.
5. Los parntesis ( ) representan un elemento opcional. Los elementos
opcionales se podran dejar en blanco en la entrada de las pantallas y
podran contener espacios o ceros para campos numricos en las
estructuras de archivos.
Estructuras de datos Lgicas y Fsicas [3]
Cuando son definidas las estructuras de datos por primera vez, slo son incluidos
los elementos de datos que el usuario podr ver, tales como nombre, direccin y
saldo. Esta etapa es el diseo lgico, mostrando cules datos necesita el negocio
para su operacin diaria. Usando diseo lgico como base, el analista disea luego
las estructuras de datos fsicas. Estas incluyen elementos adicionales para la
implementacin del sistema. Ejemplos de elementos de diseo fsico:
1.
Campos clave usados para localizar registros en una base de datos
59
2.
Cdigos para identificar el estado de registros maestros. Estos cdigos se

pueden mantener en archivos que generen informacin de impuestos.
3.
Los cdigos de transaccin son utilizados para identificar tipos de registros

cuando un archivo contiene tipos de registros diferentes.
4.
Las entradas de grupos repetidos contienen un contador sobre qu tantos

conceptos hay en el grupo.
5.
Lmites sobre la cantidad de conceptos aceptables en un grupo repetido.
6.
Una contrasea usada por un cliente que accede a un sitio web seguro.
Elementos de datos [3]

Cada elemento de datos se debe definir una vez en el diccionario de datos y
tambin se podra introducir previamente en un formulario de descripcin del
elemento.
Caractersticas de un formulario de descripcin de elementos:
1.
ID del elemento. Esta entrada opcional permite construcciones entradas de

diccionario de datos
2.
El nombre del elemento. El nombre debe ser descriptivo, nico y basado en

el propsito al cual esta destinado el elemento en la mayora de los
programas o por el usuario principal del elemento.
3.
Alias, son sinnimos u otros nombres para el elemento.
4.
Una descripcin breve del elemento
5.
Si el elemento es base o derivado. Elemento base es el que se teclea

inicialmente en el sistema, nombre del cliente direccin o ciudad; se deben
almacenar en archivos. Los elementos derivados son creados por procesos
como resultado de clculo.
6.
La longitud del elemento. Algunos elementos tienen longitudes estndar y

otras veces pueden variar para otros elementos, aqu se debe decidir en
conjunto con el usuario la longitud final.
60
7.
El tipo de datos: numrico, fecha, alfabtico o carcter que a veces se llama

datos alfanumricos o de texto.
8.
Los formatos de entrada y salida se deben incluir, usando smbolos de

codificacin especiales para indicar como se deben presentar los datos.
9.
Los criterios de validacin para asegurar que el sistema capture los datos
correctos. Los elementos pueden ser discretos, lo cual significa que tiene
ciertos valores fijos o continuos, con un rango parejo de valores.
10.
Cualquier valor predeterminado que pudiera tener el elemento. El valor

predeterminado se despliega en las pantallas de entrada y se usa para
reducir la cantidad de datos que tuviera que teclear el operador.
11.
Un rea adicional para observaciones o comentarios.
Almacenes de datos [3]

Todos lo elementos base se deben almacenar en el sistema. Tambin los
elementos derivados se podran almacenar en el sistema, tal como, para un
empleado, el sueldo bruto acumulado a la fecha. Los almacenes de datos se crean,
cuando los elementos base de un flujo de datos se agrupan para formar un registro
estructural, se crea un almacn de datos para cada registro estructural nico.
3.1.2.2 Creacin del diccionario de datos [3]

Las entradas del diccionario de datos se podran crear despus de completar el
diagrama de flujo de datos, o se podran construir conforme se desarrolle el
diagrama de flujo de datos. El uso de notacin algebraica y registros estructurales
permite desarrollar el diccionario de datos y los diagramas de flujos de datos
mediante un enfoque jerrquico de arriba a bajo.
Despus de realizar varias entrevistas adicionales para descubrir los detalles del
sistema, se puede extender el diagrama de flujo de datos y se crearan los
diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir los
61
nuevos registros estructurales y elementos recabados en las entrevistas,

observacin y anlisis de documentos posteriores.
Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el
nivel. El diagrama 0 debe incluir nicamente formularios, pantallas informes y
registros. Conforme se creen los diagramas hijos, el flujo de datos que entre y
salga de los procesos ser cada vez
mas detallado, incluyendo los registros
estructurales y los elementos.

Anlisis de las entradas y salidas [3]
Un paso importante en la creacin del diccionario de datos es identificar y
categorizar el flujo de datos de entrada y salida del sistema. Campos comnmente
incluidos:
1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en un
diagrama lgico, el nombre debe identificar el propsito de los datos.
2. El contacto del usuario responsable para la clarificacin de detalles
adicionales, retroalimentacin del diseo y aprobacin final
3. Si los datos son de entrada o salida
4. El formato de flujo de datos. En la fase del diseo lgico, el formato podra
ser indeterminado.
5. Elementos que indican la secuencia de los datos en un informe o pantalla.
6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o
derivados y sus criterios de edicin.
Desarrollo de almacenes de datos [3]
Otra actividad es el desarrollo de los almacenes de datos. Esta informacin se
describe en estructuras de datos. Sin embargo la informacin podra estar
almacenada en diferentes lugares, y el almacn de datos podra ser diferente en
62
cada lugar. Mientras que los flujos de datos representan datos en movimiento, los
almacenes de datos representan datos en reposo.
Los almacenes de datos contienen informacin de una naturaleza permanente o
semipermanente.
Cuando los almacenes de datos se crean para un solo informe o pantalla nos
referimos a ellos como vistas del usuario, porque representan la manera en que el
usuario quiere ver la informacin.
Uso del diccionario de datos [3]
El diccionario de datos ideal es automatizado, interactivo, en lnea y evolutivo.
Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la
organizacin, se agregan elementos de datos al diccionario de datos. El diccionario
de datos no es un fin en si mismo y nunca debe serlo, siempre debe verse como
una actividad paralela al anlisis y diseo de sistemas.
El diccionario de datos debe vincular a varios programas de sistemas para que
cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo
mismo en la base de datos. El diccionario de datos se vuelve una curiosidad
histrica sino se mantiene actualizado.
63

Asi p1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Asi p1

Hochgeladen von

Copyright:

Verfügbare Formate

Anlisis de Sistemas de Informacin

1.1.1 Definiciones de sistemas

Anlisis de Sistemas de Informacin

Anlisis de Sistemas de Informacin

existencia social. La sabidura consiste en juzgar correctamente cuando, cmo,

Anlisis de Sistemas de Informacin

A un sistema de informacin lo integran dos partes bsicas: el hardware y el

Sistemas fsicos y Sistemas abstractos

Sistemas determinsticos y Sistemas probabilsticos

Sistemas abiertos y Sistemas cerrados

A continuacin se describen cada uno de ellos

1.1.2.1 Sistemas fsicos y sistemas abstractos [6]

1.1.2.2 Sistemas determinsticos y Sistemas probabilsticos [6]

Anlisis de Sistemas de Informacin

1.1.2.3 Sistemas Abiertos y sistemas Cerrados [7] [8]

propiedades, valor y descripcin de un sistema especfico o de un componente del

1.1.2.4 Parmetros de los sistemas [8]

Anlisis de Sistemas de Informacin

Salidas o resultados (output): Todo sistema coloca en el medio ambiente

Figura 1.1 Parmetros de un sistema

Anlisis de Sistemas de Informacin

Sistemas de Automatizacin de Oficina (OAS, Office Automatition System)

Sistemas de Trabajo de Conocimiento (KWS, Knowledge Work System)

Sistemas de Apoyo a Decisiones (DSS*, Decisin Support Systems)

Gerencial (MIS*Management Information

Sistemas de Apoyo a Ejecutivos (ESS*, Executive Support Systems) y

Sistemas de Apoyo a Decisiones de Grupo (GDSS, Group Decisin Support

Sistemas de Trabajo Corporativo Apoyados por Computadora (CSCWS,

Sistemas Expertos e Inteligencia Artificial

Transaction Processing System) [1]

Anlisis de Sistemas de Informacin

Automatition System y Sistemas de Trabajo de Conocimiento (KWS,

para analizarla y transformar datos, o para manejarla en alguna

forma y luego compartirla o diseminarla formalmente por toda la organizacin y

1.1.3.3 Sistemas de Apoyo a Decisiones (DSS, Decisin Support

Anlisis de Sistemas de Informacin

Information Systems) [1]

computarizada que trabajan debido a la interaccin resuelta entre gentes y

1.1.3.5 Sistemas de Apoyo a Ejecutivos (ESS, Executive Support

Anlisis de Sistemas de Informacin

1.1.3.6 Sistemas de Trabajo Corporativo Apoyados por Computadora

1.1.3.7 Sistemas Expertos e Inteligencia Artificial (AI, Artificial

La base del conocimiento

Introduccin a los sistemas

Anlisis de Sistemas de Informacin

Una motor de Inferencia (Conexin de usuario-sistema)

1.1.3.8 Sistemas de apoyo a decisiones de grupo (GDSS, Group

semiestructuradas o sin estructura, un sistema de apoyo a decisiones de grupo

1.2 Ciclo de vida de un proyecto de software [1]

Anlisis de Sistemas de Informacin

Planificacin y gestin del proyecto.

Se tomara el siguiente diagrama de referencia donde se muestran las etapas del

Figura 1.2 Ciclo de vida del desarrollo de sistemas

1.2.1 Planificacin y gestin del proyecto [1]

Anlisis de Sistemas de Informacin

Anlisis de Sistemas de Informacin

problemas no requieren un sistema de cmputo, puede ser recomendada una

1.2.2 Determinacin de requerimientos [1]

Investigacin de datos impresos

Observacin del comportamiento del encargado de la toma de decisiones

Anlisis de Sistemas de Informacin

1.2.3 Anlisis y diseo [1]

Anlisis de Sistemas de Informacin