Manual de Analisis y Diseno de Sistemas

Anlisis y Diseo de Sistemas 1
CAPITULO
CONCEPTOS DE ANLISIS DE
SISTEMAS.
1.1 ORIGENES DEL ANALISTA DE SISTEMAS
Los primeros analistas de sistemas surgieron en la revolucin industrial. No trabajaban,

en un principio, con ordenadores o sistemas basados en ordenadores. En vez de ello,
eran ingenieros industriales cuyas responsabilidades se centraban en el diseo de
sistemas de fabricacin eficaces. Los analistas de sistemas de informacin surgieron
como respuesta a la necesidad de mejorar los recursos informticos para satisfacer los
nuevos requisitos de procesos de informacin de las aplicaciones de la empresa.
A pesar de sus enormes posibilidades tecnolgicas presentes y futuras, la computadora

aun debe su poder y utilidad a las personas. Son las personas en las empresas definen
las aplicaciones y los problemas que la computadora ha de resolver.
1.2 NECESIDAD DE LOS SISTEMAS
El campo de los sistemas es parte integral del trabajo de todo ejecutivo, o sea que cada
persona que supervisa, dirige o administra las actividades de subordinados sin importar
el nmero, tiene en su trabajo una responsabilidad inherente de los sistemas,
procedimientos o mtodos que emplean l y sus subordinados.
La ubicacin de los sistemas y procedimientos de trabajo se halla en el elemento

administrativo de la planeacin, que es el momento donde se definen cmo se van a
hacer las cosas.
1.3 CONCEPTOS GENERALES DEL ANLISIS

Es un conjunto o disposicin de procedimientos o programas relacionados de manera
que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas
clasificadas y dispuestas de manera ordenada mostrando un plan lgico en la unin de
las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo.
Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefinido en

el procesamiento de la Informacin. Esto se lleva a cabo teniendo en cuenta ciertos
principios:
Debe presentarse y entenderse el dominio de la informacin de un problema.
Defina las funciones que debe realizar el Software.
Represente el comportamiento del software a consecuencias de acontecimientos

externos.
Divida en forma jerrquica los modelos que representan la informacin,

funciones y comportamiento.
El proceso debe partir desde la informacin esencial hasta el detalle de la

Implementacin.
La funcin del anlisis puede ser dar soporte a las actividades de un negocio, o
desarrollar un producto que pueda venderse para generar beneficios. Para conseguir
este objetivo, un sistema basado en computadoras hace uso de seis (6) elementos
fundamentales:
Software, que son Programas de computadora, con estructuras de datos y su

documentacin que hacen efectiva la logstica metodologa o controles de
requerimientos del Programa.
Hardware, dispositivos electrnicos y electromecnicos, que proporcionan

capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras,
Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin
externa dentro de los Sistemas.
Personal, son los operadores o usuarios directos de las herramientas del

Sistema.
Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al

Sistema a las que se accede por medio del Software.
Documentacin, Manuales, formularios, y otra informacin descriptiva que

detalla o da instrucciones sobre el empleo y operacin del Programa.
Procedimientos, o pasos que definen el uso especfico de cada uno de los

elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.
Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos:
Identifique las necesidades del Cliente.
Evale que conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un Anlisis Tcnico y econmico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros

elementos del Sistema.
Establezca las restricciones de presupuestos y planificacin temporal.
Cree una definicin del sistema que forme el fundamento de todo el trabajo de
Ingeniera.
1.4 CLASIFICACIN DE SISTEMAS
Los sistemas se clasifican en:
Sistemas naturales y sistemas creados o hechos por el hombre. Las organizaciones

pblicas y privadas constituyen sistemas creados o hechos por el hombre.
Considerando el nmero y complejidad de los elementos y sus relaciones, y la

posibilidad de predecir su comportamiento, los sistemas pueden ser simples, complejos y
muy complejos; y deterministas y probabilistas.
Otra clasificacin de los sistemas distingue a los cerrados de los abiertos. La gran
mayora de los sistemas orgnicos son abiertos, esto quiere decir que hay un
intercambio de energa con sus integrantes.
Sistemas mecnicos o no vivientes y sistemas vivientes. Fcil de comprender porque los

organismos pblicos son sistemas vivientes, puesto que el principal componente es el ser
humano como ente individual y como miembro de un grupo social.
Sistemas adaptables y no adaptables. Las organizaciones son sistemas adaptables,

puesto que reaccionan o responden a cambios del contexto, producindose una nueva
situacin del sistema frente a la reaccin o respuesta.
CAPITULO
FUNDAMENTOS DEL DESARROLLO DE

SISTEMAS.
2.1 EL ANALISTA COMO SOLUCIONADOR DE PROBLEMAS
En esencia, el analista de sistema aplica un planteamiento de resolucin de problemas
para desarrollar los sistemas.
La resolucin de problemas es el acto de estudiar el entorno de un problema con el fin

de implantar soluciones correctivas pertinentes. Problema es un trmino que incluye:
1. Situaciones, reales o anticipadas, que requieren una accin correctiva.
2. Oportunidades de mejorar una situacin a pesar de la ausencia de quejas al

respecto.
3. Instrucciones para cambiar una situacin con independencia de que se hayan

o no recibido quejas sobre la situacin actual.
2.1.1 CARACTERSTICAS
Planificacin es el estudio continuado del entorno de un problema con el fin de

identificar las posibilidades de solucin que entraa.
En trminos ideales, los proyectos que se seleccionan proporcionaran beneficios a la

empresa a largo plazo. Por tanto, la planificacin del sistema de informacin no puede
separarse de la empresa en si mismo. Con vendra notar que muchas empresa aun no
han centrado su atencin a que unidad de planificacin.
Anlisis es el estudio del entorno del problema y las subsiguiente definicin y

establecimiento de prioridades entre las necesidades planteadas con el fin de resolver el
problema.
Diseo es la evaluacin de las diferentes alternativas a si como, las especificaciones

detalladas de la solucin final.
Implantacin es la construccin o ensamblaje de la solucin al problema que culmina

en un nuevo entorno basado en dichas soluciones.
Soporte es el mantenimiento y la mejora permanentes de la solucin en el transcurso de

su vida (que puede durar semanas, meses o ao).
2.2 BLOQUES ELEMENTALES DE UN SISTEMA DE

INFORMACIN
El anlisis de sistema desarrolla el sistema de informacin para las organizaciones.

Antes de estudiar el proceso de construccin de sistema, es preciso comprender
claramente el producto que se esta intentando elaborar.
2.2.1 CONCEPTO DE INFORMACIN
Un sistema de informacin es una disposicin de componentes integrados entre si cuyo

objetivo es satisfacer las necesidades de informacin de una organizacin.
El propsito de un sistema de informacin es recoger, procesar e intercambiar

informacin entre los trabajadores de una empresa. E l sistema de informacin ha sido
diseado para apoyar todas las operaciones de los sistemas de empresa.
2.2.2 BLOQUE ELEMENTAL PERSONAS
El primer, y mas importante, bloque de los sistemas de informacin es la persona. La

filosofa predominante en el desarrollo de sistemas debera consistir en pensar
que los sistemas estn hechos para las
personas.
Propietario del sistema
Patrocinan y promueven los sistemas de informacin.

Son normalmente responsables de fijar el
presupuesto y el plazo necesario para desarrollar y
mantener el sistema de informacin, y deciden en
ltimos trminos la validez de dichos sistemas de
informacin.
Usuarios de sistemas
Son aquellas personas que utilizan el sistema de informacin (y obtienen beneficios

directos de el) de una forma regular: Captura, valida, introduce y almacenan datos de
informacin.
Los usuarios son las personas para los cuales los analistas de sistemas desarrollan los
sistemas de informacin. Los usuarios de sistemas definen:
1. Los problemas que han de resolverse.

2. Las oportunidades que han de aprovecharse.
3. Las necesidades que han de satisfacerse
4. Las restricciones de empresa que se impondrn a los sistemas de
informacin.
2.2.3 BLOQUE ELEMENTAL DE DATOS
Los datos pueden, y deberan, interpretarse como la materia prima utilizada para
producir informacin. En consecuencia, consideramos que los datos deben constituir
uno de los pilares fundamentales de un sistema de informacin.
La mayora de las personas utiliza los trminos, datos e informacin de forma indistinta.
Sin embargo, no significan en absoluto lo mismo.
Dato: es una coleccin de hechos considerados de forma

aislados. Los datos describen la organizacin. Estos
hechos aislado aportan un significados, pero en general
no son de utilidad por si solos.
Informacin: es un dato que ha ido manipulado, con la que resulta de utilidad para
alguien. En otras palabras la informacin debe tener valor, o en caso contrario seria un
dato. La informacin le dice a la gente algo que no sabia o le confirma algo que ha
escuchado.
Como ven los datos los propietarios de sistemas
En trminos, estrictos, el propietario de sistema medio no esta interesado en los datos en

bruto, sino en las cosas que dichos datos describen. Estas cosas son los recursos de
empresa.
Los recursos de empresa son:
1. Cosas esenciales para los propsitos o los objetivos del sistema.

2. Cosas que han de ser gestionadas o controlada para alcanzar las metas y los
objetivos de empresa.
Para los propietarios de sistemas, los datos son en si mismos recursos que ayudan a
gestionar mejor esos otros recursos de empresa. Cuales son los recursos de empresas
importantes para los propietarios de sistemas para un sistema de empresa o de
informacin dado, la mayora de estos recursos corresponden a alguna de las siguientes
categoras:
Cosas tangibles (por ejemplo, materiales, suministros, maquinas, vehculos y

productos).
Funciones (por ejemplo, clientes, proveedores, empleados y titulares de
cuentas).
Sucesos (por ejemplo, pedidos, solicitudes, contratos, viajes, accidentes o
ventas).
Lugares (por ejemplo, oficinas de ventas e instalaciones de almacn).
Como ven los datos los usuarios
Los usuarios de un sistema de informacin son normalmente expertos en datos. Conocen

los datos de la empresa mejor que nadie. Como trabajadores de la informacin, se
encargan de capturar, almacenar, procesar, editar y utilizar los datos de forma
cotidiana. Por desgracia, con frecuencia ven los datos solo en funcin de cmo se
aplican en la actualidad o como piensan que deberan aplicarse.
Como ven los datos los diseadores de sistemas
Los usuarios de los sistemas definen las necesidades de datos de un sistema de

informacin. Los diseadores de sistemas convierten estas necesidades en base de datos
y archivos informticos que servirn de soporte al bloque elemental actividades del
sistema de informacin. Los diseadores de sistemas ven los datos en forma de
disposiciones de registros, estructuras de datos, esquemas de bases de datos,

organizaciones de archivos, campos, ndices y otro tem tcnicos. Algunos de ellos, si se
presentan de forma adecuada, pueden ser correctamente interpretados por los usuarios
del sistema. Pero en la mayora de caso no es as.
2.2.4 BLOQUE ELEMENTAL ACTIVIDADES
Cuando los ingenieros disean un nuevo producto, dicho producto debe cumplir alguna
funcin, hacer algo til. Los eventuales clientes definen la funcin deseada y el ingeniero
crea un diseo que realice dicha funcin. Las ACTIVIDADES definen la funcin de un
sistema de informacin.
Las actividades de una empresa son procesos

cotidianos que sirven para apoyar su cometido,
metas y objetivos. La mayor parte de las
empresas se organiza en torno a actividades tales
como el marketing, las ventas, las operaciones de
almacn, las expediciones y las recepciones, la
gestin de personal, la contabilidad y la
produccin.
Las actividades de los sistemas de informacin son los procesos que apoyan las
actividades de empresa por medio de:
1. El suministro de datos y el proceso de informaciones.
2. La mejora y la simplificacin de las actividades de empresa. Algunas

actividades pueden implantarse en forma de software. Otra han de ser
realizadas por personas.
En esencia, las actividades son trabajos llevados a cabo para la empresa tanto por
personas como por maquinas. Algunas actividades son repetitivas. Otras se producen
con menor frecuencia, a veces casi nunca.
Como ven las actividades los propietarios de sistemas
Los propietarios de sistemas estn por lo general, interesados por el plano general de la
empresa, en este caso los grupos de actividades denominadas funciones.
Las funciones son actividades en curso que apoyan el funcionamiento de la empresa. En

general, incluyen actividades muy distintas que tienen algo en comn.
Entre las funciones delos sistemas de empresa se incluyen las ventas, los servicios la
fabricacin, las expediciones, las recepciones, la contabilidad, etc.
Esencialmente, los propietarios de sistemas ven sus funciones de empresa a travs de

diversos parmetros de planificacin, como son las metas y los objetivos.
Las metas son declaraciones generales de intenciones, algo que la empresa quiere
conseguir.
Los objetivos son fines ms especficos que ayudan a alcanzar las metas.
Como ven las actividades los usuarios de sistemas
Los usuarios ven las actividades en funcin de los distintos procesos de empresa.
Los procesos de empresa son actividades que tienen entradas y salidas. Estos procesos
se basan con frecuencia en mtodos especficos y procedimientos de aplicacin paso a
paso. Los procesos de empresa pueden ser puestos en marcha por personas, maquinas u
ordenadores.
Como ven las actividades los diseadores de sistemas
La visin que tienen os diseadores de sistemas de las actividades esta acondicionada

por las limitaciones de la tecnologa especifica. En ocasiones, el analista puede elegir
esta tecnologa. Pero a menudo la eleccin ya ha sido hecha, y el analista debe utilizar
la tecnologa disponible. En ambos casos, la visin de las actividades que tienen los
diseadores de sistemas es de carcter ms bien tcnico.
2.3 CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
El ciclo d vida del desarrollo de sistemas (CVDS) es el proceso por el cual los analistas
de sistemas, los ingenieros de software, los programadores y los usuarios finales
elaboran sistemas de informacin y aplicaciones informticas.
En cualquier modo, se trata de una herramienta de gestin de proyectos que planea,

ejecuta y controla los proyectos de desarrollo de sistemas.
2.3.1 PRINCIPIOS ESENCIALES PARA EL DESARROLLO DE SISTEMAS.
Implicar Al Usuario: Es frecuente or hablar a los analistas y los programadores de me

sistema. Esta actitud ha dado lugar, en cierto modo, a una postura confrontada entre
analista, programadores y usuarios. Aunque los programadores y los analistas trabajan
intensamente para poder crear soluciones magnificas desde el punto de vista
tecnolgico, dichas soluciones a menudo se vuelven contra sus inventores porque no
responden a los problemas reales de organizacin o incluso introducen nuevos
problemas tcnicos u organizativos. Por este motivo, la implicacin del usuario e el
proyecto es una necesidad absoluta para conseguir un desarrollo fructfero de los
sistemas.
Aplicar un mtodo de resolucin de problemas: El ciclo de vida del desarrollo de

sistemas es, primero y ante todo, un mtodo de resolucin de problemas para fabricar
sistemas. El termino problema se usa en este caso como algo que incluye tanto los
problemas reales como las oportunidades de mejorar y las normas impuestas por la
direccin. El mtodo clsico de resolucin de problemas es el siguiente:
1. Identificar el problema (u oportunidad o norma).

2. Comprender el contexto del problema y las causas y efectos del mismo.
3. Definir los requisitos para alcanzar una solucin adecuada.
4. Hallar soluciones alternativas.
5. Elegir la mejor solucin.
6. Disear e implantar la solucin.
7. Observar y evaluar el impacto de la soluciona. Afinar la soluciona en forma
consecuente.
Definir fases y actividades: En su mayora los CVDS constan de fases. En su forma

clsica ms simple, los CVDS constan de cuatro fases:
1. Anlisis de sistema
2. Diseo de sistema
3. Implantacin de sistema
4. La planificacin de sistemas
Establecer normas para un desarrollo y una documentacin consistentes: Para

promover una adecuada comunicacin en esta base constantemente cambiante de
usuarios y profesionales de los sistemas de informacin, deben aplicarse normas que
aseguren la consistencia del desarrollo de sistemas.
Las normas de desarrollo de sistemas describen, por lo general actividades,

responsabilidades, directrices o requisitos de documentacin y controles de calidad.
Deberan establecerse estos cuatro tipos de normas en todas las fases del ciclo de vida.
Disear sistemas que puedan crecer y cambiar: Existe un defecto vital en el que suelen
incurrir los profesionales de sistemas de informacin que necesitan desarrollar sistemas.
Junto con la siempre creciente demanda de desarrollo de sistemas, muchos analistas de
sistemas han cado en la trampa de desarrollar sistemas que satisfacen solamente las
necesidades de los usuarios para hoy. Aunque a primera vista pueda parecer necesario,
en la prctica resulta casi siempre un fracaso.
Entropa es el trmino utilizado por los especialistas en sistemas para describir el

natural e inevitable deterioro de todos los sistemas.
CAPITULO
PLANIFICACIN DEL SISTEMA

La planificacin del sistema pretende sealar y establecer las prioridades sobre aquellas
tecnologas y aplicaciones que producirn un beneficio mximo para la empresa.
Algunos de sus sinnimos son planificacin estratgica de sistemas y gestin de recursos
de informacin.
La planificacin de sistemas se consigue mediante la cooperacin de los propietarios de

los sistemas, de aqu que en el modelo en pirmide, tenga que ver con PERSONAS,
DATOS y ACTIVIDADES.
3.1 FASES DE LA PLANIFICACION

3.1.1 FASE 1: ESTUDIO DE LA PLANIFICACIN
La primera fase de estudio de la planificacin de sistemas consiste en estudiar el

cometido de la empresa. Es sorprendente que muchas empresas no hayan documentado
su cometido de manera formal, pero en cualquier caso todas ellas tienen una misin. La
correcta planificacin de los sistemas de informacin depende de la calidad de la
planificacin de la empresa. Acorde con esto, la gestin de sistemas de informacin
desempea con frecuencia un papel clave en la orientacin y la direccin de esta fase.
Bloques Elementales Para La Fase De Estudio
Los objetivos fundamentales de la fase de estudio son:
Establecer los mandatos de la planificacin estratgicas de sistemas. (Ello

puede implicar convencer a los directivos de alto rango de la empresa de la
importancia de la planificacin estratgicas de sistemas)
Cimentar una cooperacin de trabajo entre los directores de los sistemas de
informacin y los directivos de mximo nivel de la empresa.
Analizar las estrategias de la empresa que pudieran influir sobre los sistemas
de informacin.
3.1.2 FASE 2: DEFINIR UNA ARQUITECTURA DE INFORMACIN.
Una arquitectura de informacin es un plan de seleccin de la tecnologa de informacin

y el desarrollo de los sistemas de informacin necesarios para apoyar el comercio de la
empresa.
La fase de arquitectura puede requerir seis meses o ms para su terminacin.
3.1.3 FASE 3: ANLISIS DE REAS DE LA EMPRESA
El propsito del AAE es idear un plan que lleve a obtener aplicaciones de sistemas de
informacin altamente integradas para un rea de empresa. La fase de anlisis activa
proyectos con el fin de:
1. Desarrollar una base de datos nica e integrada para toda el rea de

empresa.
2. Desarrollar una infraestructura comn de redes para el rea de empresa (lo
que incluye conexiones con otras redes y el mundo exterior).
3. Desarrollar proyectos planificados de desarrollo de aplicaciones de sistemas
de informacin evolucionaran en torno a las bases de datos compartidas y las
infraestructuras de redes, a travs de las cuales conseguirn un alto grado
de integracin.
Bloques Elementales
Los objetivos fundamentales de un AAE son:
Identificar las necesidades de la empresa de una base de datos compartida

para el rea de empresa.
Identificar las necesidades en la empresa de una red compartida para el rea
de empresa.
Refinar las necesidades tcnicas para la base de datos del rea de empresa y
las redes.
Identificar necesidades de alto nivel en la empresa en cuanto a disposicin de
aplicaciones integradas en el rea de empresa.
3.2 REINGENIERA DE PROCESOS DE LA EMPRESA

Es el conjunto de actividades de estudio y rediseo de los procesos fundamentales de
empresa, independientes de las unidades organizativas o del soporte de los sistemas de
informacin, cuyo fin es determinar si los procesos bsicos de empresa pueden ser
simplificados y mejorados de forma significativa.
CAPITULO
ANLISIS DE SISTEMAS
El anlisis de sistemas es el estudio actual de empresa y de informacin, la definicin de
las necesidades y las prioridades manifestadas por los usuarios para la construccin de
un nuevo sistema de informacin.
4.1 BLOQUES Y FASES ELEMENTALES

1. Estudio de la viabilidad del proyecto (o fase de inspeccin).
2. Estudio y anlisis del sistema actual (o fase de estudio).
3. Definicin y establecimiento de prioridades entre las necesidades de usuario
(o fase de definicin).
4.2 LA MODELIZACION DE DATOS
Un modelo es una representacin de le realidad. Como una imagen vale ms que mil
palabras, los modelos son en su mayora representaciones graficas de la realidad.
Puede establecerse modelos para los sistemas existentes, con el fin de obtener un mejor
conocimiento de dichos sistemas, para los sistemas propuestos como medio para definir
las necesidades y los diseos.
Los modelos de implantacin muestran no solo lo que es o hace un sistema, sino

tambin como es su implantacin fsica. Entre sus sinnimos se incluyen modelo
tecnolgico y modelo fsico. Los modelos de implantacin son tiles para documentar los
datos de un sistema existente. Sin embargo, los analistas han aprendido que las
necesidades de datos de los sistemas propuestos deberan especificarse, en el mejor de
los casos, mediante modelos esenciales.
Los modelos esenciales son modelos independientes de la implantacin, que describen la

esencia del sistema (lo que hace o debe hacer el sistema), independientemente del modo
en que se implante fsicamente dicho sistema. Los modelos esenciales reciben a veces el
nombre de modelos lgicos o modelos conceptuales.
La modelizacion de datos es una tcnica para la organizacin y la documentacin de los

datos de un sistema. En ocasiones, la modelizacion de datos recibe el nombre de
modelizacion de base de datos, debido a que los modelos de datos normalmente se
implantan como base de datos.
4.2.1 HERRAMIENTAS DE MODELIZACION DE DATOS.
Existen numerosas herramientas para la modelizacion de datos. Tanto los analistas de

sistemas como los usuarios encontraran en su camino diferentes herramientas, a veces
incluso en una misma organizacin. Por tanto, importante que se familiaricen con otras
dos herramientas de modelizacion de datos utilizadas comnmente: los modelos de datos
Martn y de Bachman. Estas dos herramientas pretenden representar y transmitir la
misma informacin en forma de diagrama de entidad-relacin; sin embargo cada una de
ellas posee una notacin simblica diferente. Otra herramienta es CASE las cuales son
programas (software) que automatizan o apoyan una o mas fases del ciclo de vida del
desarrollo de sistemas. El propsito de esta tecnologa es acelerar el proceso de
desarrollo de sistemas y mejorar la calidad de los sistemas resultantes.
Diagramas de entidad-relacin
Un diagrama de entidad-relacin (DER) es una herramienta de modelizacion de datos

que describe las asociaciones que existen entre las diferentes categoras de datos dentro
de un sistema de empresa o de informacin (no solo dice como implantar, crear,
modificar, usar o borrar datos.
4.2.2 COMO CONSTRUIR MODELOS DE DATOS.
Existen muchas formas y mtodos para efectuar modelizaciones de datos. En esta

seccin veremos cuando hacer una modelizacion de datos durante el desarrollo de
sistemas.
Modelizacin de datos a lo largo del ciclo de vida
La modelizacin de datos puede efectuarse durante diversas fases del ciclo de vida del
desarrollo de sistemas. Los modelos de datos son progresivos, ya que en la empresa y las
aplicaciones no tienen modelos finales. En vez de ello, un modelo de datos debera
considerarse como un documento vivo que cambiara como respuesta a los cambios que
experimente la empresa. Lo mejor es almacenar los modelos de datos en un diccionario,
de manera que puedan ser recuperados, ampliados y editados con el paso del tiempo.
Modelizacin de datos durante la planificacin de sistemas
Durante la fase de definicin de la planificacin de sistemas, normalmente se construye

un modelo de datos de empresa. Este modelo refleja una visin de alto nivel sobre las
entidades crticas de informacin. El modelo de datos de empresa recibe tambin el
nombre de modelo de datos sustancial, dado que en sus entidades representan
cuestiones sustanciales de alto nivel acerca de las cuales la direccin de la empresa
requiere informacin.
4.3 MODELIZACION DE PROCESOS
La modelizacin de procesos es una tcnica para la organizacin y la documentacin de

los procesos de un sistema, sus entradas, sus salidas y sus formas de almacenamiento.
La modelizacion de procesos es una tcnica de ingeniera de software, por tanto, es
posible que el lector encuentre modelos similares en los cursos sobre ingeniera de
software. Por otra parte, la utilidad de los modelos de procesos va mucho ms all de la
mera descripcin de los procesos de software.
La modelizacin esencial de procesos trata los procesos de empresa desde los puntos de
vista de los propietarios y los usuarios de los sistemas. Conforme a ello, estos modelos
no contienen detalles tecnolgicos o de implantacin.
4.3.1 DIAGRAMA DE FLUJO DE DATOS
Un diagrama de flujo de datos (DFD) es una herramienta de modelizacion de procesos

que representa el flujo de datos a travs de un sistema y los trabajos o procesos llevados
a cabo por dicho sistema.
Convenciones y directrices de los diagramas de flujo de datos

El smbolo principal de un diagrama de flujo es el proceso.
NOMBRE REPRESENTA SIMBOLO

Flujo de datos Los datos en
movimiento del sistema
Proceso Transformaciones de
los datos del sistema.
Almacn de datos Datos en reposo del

sistema
Agente externo o Origen y destino de los

interno flujos de datos que
entran y salen del
sistema
Un proceso es un conjunto de tareas o acciones realizadas a partir de un flujo de datos

de entrada para producir un flujo de datos de salida. Aunque los procesos pueden ser
satisfechos por personas, departamentos, robots, maquinas u ordenadores, por el
momento solo centraremos en la tarea o la accin efectuadas, y no en quien se encarga
de dicha tarea o actividad.
El flujo de datos representa la introduccin de datos en un proceso o la obtencin de

datos de un proceso.
Los agentes internos y externos definen los lmites de un sistema. Suministran entradas
o salidas netas de un sistema. Uno de sus sinnimos ms habituales es entidad interna y
externa (no confundir con entidad de datos). Los agentes reciben tambin en ocasiones
el nombre de fuentes (de entradas netas al sistema) o destinos (de salidas netas de un
sistema).
Un almacn de datos es un inventario de datos. Entre sus sinnimos se incluyen archivo

y base de datos (aunque estos dos trminos poseen un matiz ms bien relacionado con la
implantacin de modelos de procesos esenciales).
En el mejor de los casos, los almacenes de datos esenciales deberan describir cosas
sobre las cuales la empresa desea almacenar datos.
En ello se incluye:
Participantes (por
ejemplo, clientes,
proveedores,
empleados,
estudiantes,
instructores, etc.)
Objetos (como
productos, piezas,
libros de texto,
equipos, etc.)
Lugares (por
ejemplo, almacenes,
regiones de ventas,
edificios, salas, etc.)
Sucesos (como
pedidos, tarjetas de
control de tiempos,
solicitudes, cursos,
inscripciones, etc.)
4.3.2 CUANDO CONSTRUIR MODELOS DE PROCESOS
La modelizacion de procesos puede efectuarse diversas fases del ciclo de vida del
desarrollo de sistemas. Los modelos de procesos son graduales, es decir en las empresas
y las aplicaciones no tienen modelos finales. En vez de ello, un modelo ha de
considerarse como un documento vivo que evolucionara como respuesta a los cambios
experimentados por la empresa. Lo mejor es almacenar los modelos de procesos en un
diccionario, de manera que puedan ser recuperados, ampliados y editados con el paso
del tiempo.
Modelizacin de procesos durante la planificacin de sistemas
Durante las fases de estudio de la planificacin de sistemas, por lo general no se hace

ninguna modelizacion de procesos, el enteres de esta etapa se centra completamente en
el estudio de la empresa y en la misin que ha de cumplir dicha empresa.
Durante la fase de definicin de la planificacin de sistemas, normalmente se construye

un modelo de procesos de empresa. En este modelo contiene una visin general de las
funciones de empresa.
Diagrama de datos o modelo de procesos del rea de empresa.
El grado de detalle de dicho modelo varia segn las metodologas concretas utilizadas,
sin embargo, estos DFD no tienen, por lo general, el nivel de detalle suficiente como
para dar paso al diseo de aplicaciones informticas especificas. Ms bien se utilizan
para identificar aplicaciones informticas especficas y fijar prioridades entre ellas, con
vistas a las fases posteriores de anlisis y diseo.
Modelizacion de procesos durante el anlisis de sistema
La modelizacin de procesos suele construir una parte importante de muchas tcnicas y

metodologas de la fase de estudio. As los analistas realizaran diagramas de flujos de
datos de implantacin de los sistemas actuales para aumentar su conocimiento sobre los
sistemas y los problemas que se les asocian. Algunos analistas podran convertir estos
DFD de implantacin en DFD esenciales para eliminar el sesgo inevitable que se
produce cuando se parte de modelos de implantacin existentes para plantearse las
soluciones alternativas.
El paso hacia el diseo de sistema
El modelo de procesos esencial obtenido en el anlisis de sistemas describe necesidades

de procesos de la empresa, no soluciones tcnicas. Cuando se pase al diseo de
sistemas, el modelo de procesos se har ms tcnico. Deber convertirse en un modelo
de implantacin de aplicaciones que dirigir la implantacin tcnica de programas. As
los DFD pueden utilizarse tambin en las fases de diseo de implantacin.
4.3.3 MTODO DE MODELIZACION DE PROCESO PAS A PASO
Emplearemos un mtodo por etapas para suministrar un conjunto completo de los DFD
que pueden utilizarse en el futuro.
Paso 1: Elaborar un diagrama de flujo de datos de contexto
Un diagrama de flujo de datos de contexto define el campo de accin y los limites del
sistema y el proyecto. El mbito de todo proyecto esta sujeto siempre a a cambios, por
tanto, tambin lo deber estar el diagrama de flujo de datos de contexto. Entre sus
sinnimos se incluyen diagramas de contexto, modelo de contexto y modelo ambiental.
Los diagramas de contexto son difciles de elaborar, ya que han de definir el mbito de
accin del proyecto o el sistema. Para determinarlos, proponemos la siguiente
estrategia:
1. Piense en el sistema como si fuera un recipiente, para diferenciar su interior

del exterior.
2. Ignore las tareas puramente internas del recipiente. Aplicara as el clsico

concepto de caja negra de la teora de sistemas.
3. Pregunte a sus usuarios finales cuales son los sucesos o transacciones a los
cuales debe responder el sistema. Los sucesos de empresa simplemente
ocurren, y aportan nuevos datos al sistema.
4. Para cada suceso, pregunte a sus usuarios finales cuales son las respuestas
que debera producir el sistema.
5. Pregunte a sus usuarios finales cuales son los informes de formato fijo que ha
de producir el sistema.
6. Identifique las fuentes netas de datos para cada suceso. Estas fuentes se
convertirn en agentes internos o externos en los DFD.
7. Identifique los recipientes netos de cada respuesta o salida que debera

generar el sistema. Estos destinos sern tambin agentes internos y externos.
8. Identificar todos los posibles almacenes de datos externos. Muchos sistemas

requieren acceder a archivos o bases de datos de otros sistemas. Tal vez
lleguen a usar los datos de dichos archivos o bases de datos.
9. Dibuje un diagrama de contexto para todas las informaciones anteriores.
Paso 2: Elaborar un diagrama de descomposicin que esquematice los

diagramas de flujo de datos.
Existen dos formas bsicas de elaborar diagramas de flujos de datos de un sistema o una
aplicacin completos:
Trazar dos diagramas de flujo de datos, cada uno de ellos en una hoja de
papel independiente. El primer diagrama, denominado DFD general o de
nivel cero, sirve como diagrama de nivel general, consiste comnmente DFD
de sistema o de nivel uno, es una ampliacin del primer diagrama que
suministra una visin mas detallada del sistema. Puede contener de diez a
treinta procesos.
Elaborar un conjunto de diagramas de flujo de datos por niveles. Este mtodo

aplica una tcnica de explosin, en vez del anterior mtodo de expansin. El
proceso del diagrama de flujo de datos de contexto se divide en su propio
diagrama de flujo de datos que ilustra los subsistemas bsicos mostrados
como subprocesos. Cada uno de estos subprocesos puede a su vez,
desglosarse en un diagrama de flujo de datos que muestre procesos mas
detallados.
Un diagrama de descomposicin, tambin denominado grafico de jerarquas, muestra la

estructura, o descomposicin funcional en sentido descendente, de un sistema. Tambin
nos proporciona un esquema para elaborar nuestros DFD.
Paso 3: Identificar almacenes de datos
Antes de pasar a dibujar nuestros diagramas de flujo de datos, puede ser de utilidad
identificar los posibles almacenes de datos que se utilizaran en dichos diagramas. En mi
primer lugar, creamos un almacn de datos compuesto que represente a todos los datos
del sistema. Este almacn de datos se desglosa en nuestro modelo de datos. A
continuacin, identificaremos los almacenes de datos primigenios, uno para cada
entidad o entidad asociativa del modelo de datos.
Paso 4: Elaborar un diagrama general de flujo de datos
Mediante el empleo como esquema de nuestro diagrama de descomposicin, podemos

ahora proceder a desglosar los procesos del diagrama de contexto en una imagen mas
detalla del sistema. Este segundo DFD recibe normalmente el nombre de diagrama
general de flujo de datos. En el se muestran sus principales subsistemas y funciones, as
como el modo en que interaccionan entre si. Es una forma til de comunicar el
significado y la actuacin del sistema a grandes rasgos.
Diagrama general de flujo de datos

Un diagrama general de flujo de datos muestra la interaccin existente entre los
subsistemas y/o las funciones clave.
Paso 5: Elaborar diagramas de flujo de datos de nivel medio
Despus de haber elaborado el diagrama de sistemas, podemos dividir cada uno de los
procesos de dicho DFD para poner de relieve un mayor nivel de detalle sobre los
subsistemas. Cualquier proceso de un DFD es susceptible de desglose para desvelar
diagrama de flujo de datos mas detallados de dicho proceso. Se contina con el desglose
hasta que se haya obtenido un nivel de detalle suficiente. Todos los DFD, salvo los ms
detallados, reciben con frecuencia el nombre de DFD de nivel medio.
Paso 6: Elaborar los diagramas de flujo de datos de nivel primigenio
Completemos seguidamente el conjunto de DFD por niveles mediante la elaboracin de

diagramas que muestren las necesidades detalladas de proceso dentro del sistema. Estos
diagramas reciben el nombre de diagramas de flujo de datos primigenios o de bajo nivel.
Peridicamente, deberan revisarse los diagramas de descomposicin para garantizar
que se siga correctamente el esquema original. Este diagrama contiene un ejemplo de
cada uno de los tipos existentes de procesos primigenios:
Un proceso sencillo de transacciones de entrada.

Un proceso de transacciones de salida

Un proceso de produccin de informes.
Un proceso de mantenimiento de datos.
Advirtase que los DFD primigenios deben mostrar todos los almacenes de datos y los
flujos de datos primigenios apropiados.
4.4 MODELIZACION DE REDES.

La modelizacion de redes es una tcnica basada en diagramas que se emplea para
describir la forma de un sistema de empresa o de informacin en funcin de la ubicacin
de sus usuarios, sus datos y sus procesos.
4.4.1 CLCULO CENTRALIZADO Y TIEMPO COMPARTIDO
Gran parte de la base existente actualmente en las aplicaciones y los sistemas de

informacin aplica, con razonable xito pero un coste cada vez mayor, una tecnologa
anticuada: el clculo centralizado y el tiempo compartido.
El clculo centralizado es un tipo de arquitectura de aplicaciones que utiliza un nico

procesador, normalmente ubicado en un centro de proceso de datos centralizado o en un
departamento. El ordenador es normalmente un gran sistema o un mini ordenador que
permite el acceso simultaneo a muchos usuarios. Tambin recibe el nombre de proceso
centralizado.
El tiempo compartido es u mtodo por el cual los usuarios comparten un ordenador

central. En un sistema de tiempo compartido, los procesos de interfaz de usuario
(pantallas), entradas y salidas, procesos de almacenamiento y recuperacin de datos, y
tratamiento de los sistemas lgicos de empresa son realizados por un nico procesador
central.
4.4.2 SISTEMAS CLIENTE/SERVIDOR
El clculo con sistemas cliente/servidor es una extensin del proceso cooperativo cuya
realizacin ha sido posible gracias a la evolucin de los PC, las redes LAN y WAN, la
conectividad de los host, las interfaces graficas de usuario y los sistemas de gestin de
bases de datos distribuidores.
En los Sistemas cliente/servidor, se distribuye el proceso de una aplicacin entre

mltiples ordenadores en una red LAN o WAN. Los ordenadores servidores suministran
los datos comunes o impartidos a dicha aplicacin o sistema.
Existen varia razones que justifican el actual enteres en el proceso con clientes /
servidores:
Los ordenadores clientes son cada vez ms potentes y ms baratos que los
grandes ordenadores y los mini ordenadores.
Los ordenadores servidores se estn incrementando su potencia en un grado

suficiente como para controlar la carga de trabajo de muchos ordenadores
clientes, una vez mas a menor coste que los grandes ordenadores y os mini
ordenadores
El almacenamiento de datos puede llevarse ms cerca que nunca del usuario

final, donde estos recursos tienen ms valor para la empresa.
Segn los expertos, gracias a la interfaces graficas de usuario, las

aplicaciones se hacen ms fciles de aprender y de utilizar.
Segn dice, las aplicaciones en clientes/ servidores son mas fciles y menos
costosas de construir y mantener.
4.4.3 IMPLICACIONES PARA EL ANLISIS DE SISTEMA
Las opciones a las que se enfrentan los analistas de sistemas de hoy en da son confusas.
En la actualidad, dichos analistas deben saber dar respuestas a nuevas preguntas:
En que puestos puede ponerse en marcha una aplicacin o un sistema de

informacin dado?
Cuantos usuarios hay en cada puesto?
Como podran distribuirse los datos y los procesos en los distintos puestos?
Como podran distribuirse los datos y los procesos en un puesto
determinado?
Estas y otras preguntas obligan al analista a comprender perfectamente la distribucin

geogrfica asociada a cada sistema.
4.4.4 DIAGRAMAS DE CONEXIN DE PUESTOS
Un diagrama de conexin de puestos (DPC) es una herramienta de modelizacion de

redes que se describe la forma de un sistema en funcin de la ubicacin de sus usuarios,
procesos y datos, as como las interconexiones necesaria entre dicha ubicaciones.
Convenciones y directrices de los diagrama de conexin de puestos
Muestra el conjunto de smbolos empleado para la documentacin de la redes de

empresas (esquema geogrfico de un unci sistema de informacin o una aplicacin).
Un puesto es cualquier lugar en el cual existe un usuario que emplea o interacciona con
el sistema de informacin o la aplicacin.
Algunos ejemplos de ellos podran ser:
Esenciales
Ciudad
Campos Universitario Puesto de Implantacin
Edificio Lugar del Ordenador o el
Despacho Servidor
Grupos de Despacho Lugar del Terminar
Sucursal Lugar de Racismo de
Cliente Terminales
Proveedor Racismo de Red de rea
Colaborador Local
Conexin de Red de rea
Extendida
Lugar de un Perifrico
Lugar de un Perifrico de
comunicacin.
Puesto esenciales
Los Puestos Esenciales son lugares en los que pueden distribuirse, eventualmente, los
datos y los procesos. En un principio, podramos no estar seguros de las decisiones que
habran de tomarse acerca de la distribucin de los datos y los procesos en un DCP.
Conexiones esenciales
Las Conexiones Esenciales no tienen nombre en DCP. Sin embargo, si fuera de utilidad,
puede ponerse un nombre a las conexiones que indique la distancia entre los puestos que
conectan. En los casos de puestos mviles, podran indicarse unos intervalos de

distancia, lo que tambin sera apropiado en el caso de puestos geogrficamente
disperso (por ejemplo los clientes).
CAPITULO
DISEO DE SISTEMA
5.1 CONCEPTO DE DISEO DE SISTEMA
El diseo de Sistema es la evaluacin de las distintas soluciones alternativa y la
especificacin de una solucin detallada de tipo informatico. Tambin se conoce por
diseo fsico.
5.1.1 FASES DE SELECCIN DEL DISEO DE SISTEMA
Durante la fase de seleccin es interactivo identificar y analizar las diversas opciones

posibles, y solo entonces proponer las soluciones ms viables sobre la base del anlisis
realizado.
BLOQUES ELEMENTALES EN LAS FASES DE SELECCIN
En las Fases de Seleccin, existen dos objetivos fundamentales:
1. Identificar e Investigar sobre soluciones alternativa tanto manuales como de tipo

informatico que puedan servir de apoyo a la obtencin del sistema de Informacin
Objeto.
2. Evaluar la viabilidad de la soluciones alternativa y recomendar la mejor de esta
soluciones de un punto de vista global.
5.1.2 DISEO DE INTEGRACIN DE SISTEMA
Dada la necesidades de diseo y la necesidades de integracin del sistema objeto, esta

fases implica el desarrollo de la especificaciones tcnica de diseo.
Bloques elementales para la realizacin de la fase de diseo e integracin
La fase de diseo e integracin tiene un doble objetivo. En primer lugar, y como mxima
prioridad, el analista busca disear un sistema que satisfaga las necesidades y resulte
atractivo para los usuarios finales. La ergonoma desempeara un papel central durante
el diseo. En segundo lugar, tambin es muy importante, el analista pretende presentar
expesificacione claras y completas a los programadores y tcnicos informativos.

Nuestros bloques elementales de los sistemas de informacin sirven como marco de
trabajo para llevar a cabo la fase de diseo:
Redes: durante la fase de anlisis de sistemas, establecimos los requisitos de redes

del sistema del sistema objeto.
Datos: durante la fase de definicin, especificamos el contenido de cada uno de los

flujos de informacin y de datos.
Actividades: durante el diseo debe especificarse la secuencia de pasos y el flujo de

control a travs del nuevo sistema.
Personas: deben especificarse los papeles que desempean las personas

participantes en el nuevo sistema.
Tecnologa: aunque no se seleccione o disee un hardware durante la fase de diseo

fsico, el hardware impone limitaciones al sistema.
5.2 ANLISIS DE DATOS
5.2.1 ANLISIS DE DATOS PARA LAS DECISIONES DE DISEO
Anlisis de datos: es un procedimiento que prepara un modelo de datos para su

implantacin en forma de base de datos no redundante, flexible y adaptable.
Normalizacin: es un mtodo de anlisis de datos que organiza los atributos de

datos de manera que se agrupen entre si para formar entidades estables, flexibles
y adaptable.
La normalizacin: es un procedimiento con tres etapas que pone el modelo de

datos en:
Primera Forma Normal

Segunda Forma Normal
Tercera Forma Normal
5.2.2 COMO Y CUANDO REALIZAR EL ANLISIS DE DATOS
En la mayora de las organizaciones el anlisis de datos es llevado a cabo por el

analista de sistema y/o el administrador de bases de datos. Tambin participa en el
usuario final, pero principalmente como revisor del modelo de datos final.
5.2.3 MTODOS PARA EL ANLISIS DE DATOS
Existen numerosos enfoques posibles para llevar a cabo el anlisis de datos. En los
cuales son:
Paso 1: Verificar o aadir claves a las entidades
El anlisis de datos es llevado a cabo por los analistas de sistemas o administradores de

bases de datos que usan frecuentemente el trmino clave en vez de identificador cuando
se comunican con sus colegas de sistemas de informacin.
Los analistas de sistemas y los administradores de bases de datos emplean algunos

trminos especiales para diferenciar los distintos tipos especficos de claves existentes.
Clave Primaria: designa al atributo o atributos que identifican unvocamente a una y

solo una presencia de cada entidad.
Clave Candidata: es una clave primaria alternativa utilizada para identificar

unvocamente a una y solo una presencia de una entidad.
Clave Concatenada: es una clave primaria compuesta por ms de un atributo de datos.

Uno de sus sinnimos ms comunes es claves de combinacin.
Paso 2: Poner las entidades en 1FN.

Paso 3: poner las entidades en 2FN.
Paso 4: Poner las entidades en 3FN.
Paso 5: Ms simplificacin mediante inspeccin.
Paso 6: Volver a dibujar el DER refinado.
Paso 7: Revisar y afinar el modelo de datos.
5.3 ANLISIS Y DISEO DE PROCESO
5.3.1 PROCESOS CENTRALIZADOS, DISTRIBUIDOS Y COOPERATIVOS
En las aplicaciones con proceso centralizado, un ordenador principal (normalmente, un

gran sistema) administra todas las actividades, incluidas las entradas, las salidas, el
almacenamiento y recuperacin de datos y los principios lgicos.
En las aplicaciones con procesos distribuidos, son varios los ordenadores (grandes
sistemas, miniordenadores y, a veces, ordenadores personales) los que realizan todas las
actividades. Cada ordenador de la red maneja sus propias entradas, salidas, formas de
almacenamiento y recuperacin de datos y principios lgicos.
En las aplicaciones con proceso cooperativo, mltiples ordenadores comparten sus

actividades. Estos ordenadores cooperan entre si en un modo transparente para los
usuarios; cada usuario tiene la impresin de que todo el trabajo se realiza en un solo
ordenador (posiblemente, su propio PC).
5.3.2 ALMACENAMIENTO DE DATOS CENTRALIZADOS Y DISTRIBUIDOS
La distribucin de procesos no es nico problema del diseo. Tambin lo es la ubicacin

de los almacenes de datos. En su momento, se considero esencial poder controlar los
datos en un solo centro de procesos. Hasta muy recientemente, el nico modo practico
conocido para conseguir esta meta consista en almacenar todos los datos en uno o
varios ordenadores centrales con un control absoluto por parte del grupo de
administracin de datos. Solo algunos datos locales podan distribuirse en ordenadores
de gama media, mientras que los restantes permanecan bajo el control de un grupo de
administracin de datos.
5.3.3 ENTRADAS Y SALIDAS
Con respeto a las entradas y salidas deben adoptarse tambin decisiones de diseo
fundamentales. Las decisiones aplicadas suelen ser sencillas (por ejemplo, como
trabajar en modo Batch o en modo On-line). En la actualidad, debemos considerar
tambin alternativas mas modernas, como el Batch remoto, en la entrada de datos sin
teclado, la introduccin de datos mediante lpices, las interfaces graficas de usuarios, el
intercambio electrnico de datos, el intercambio de imgenes y documentos, etc.
5.4 ANLISIS Y DISEO GENERAL PARA PROCESOS
5.4.1 DIAGRAMA DE FLUJO DE DATOS DE IMPLANTACIN
Un flujo de datos de implantacin representa la implantacin de una entrada o una

salida en un proceso de implantacin. Tambin indica el acceso o la actualizacin de un
archivo o bases de datos. Puede representar igualmente la importancia de datos o la
exportacin de datos entre sistemas a travs de un rea. Finalmente, puede representar
la transferencia interna de datos entre dos procesos implantados en el mismo programa.
5.4.2 ORGANIGRAMAS DE SISTEMAS
Los organigramas de sistemas son diagramas que muestran el flujo de control a travs
de un sistema mediante la especificacin de todos los programas, entradas, salidas y
acceso y recuperaciones de datos en archivos / bases de datos.
5.5 DISEO DE ARCHIVOS Y BASES DE DATOS
5.5.1 CONCEPTOS DE DISEO DE ARCHIVOS Y BASES DE DATOS
Los archivos convencionales y las modernas bases de datos son el corazn de muchos
sistemas de informacin. El diseo de archivos y bases de datos informticos pueden ser
mas difcil debido a que el almacenamiento y la organizacin de los datos en los
soportes informaticos requiere que el analista tenga en cuenta cuestiones complejas y, a
veces, contradictorias como son, por ejemplo, la capacidad de almacenamiento y
rendimiento.
5.5.2 DISEAR Y DOCUMENTAR ARCHIVOS Y BASES DE DATOS
En esta seccin, veremos como disear y documentar los archivos. Recuerde que
algunas decisiones del diseo fsico haban sido ya guardadas en el diccionario de
proyectos. Procederemos, pues, a disear un archivo para ilustrar esta importante tarea
de diseo de sistema.
5.5.3 TCNICAS DE DISEO DE ARCHIVOS
Existen dos cuestiones importantes y relacionadas entre si de notable influencia en el

diseo de archivos:
Reducir al mnimo las redundancias en los archivos
Controles internos
5.5.4 DISEO DE ARCHIVOS
1. Este archivo debe implantarse como un registro VSAM de longitud variable.

2. El tamao del registro se especifica como un numero mnimo y mximo de bytes.
3. Normalmente existe un lmite para el tamao de un bloque (por ejemplo, la mitad de
la pista del disco).
4. Calcular el tamao del archivo es muy importante, ya que no es posible almacenar
datos para los que no se tiene sitio.
5. Resulta tambin de utilidad expresar el tamao del archivo en forma de pistas y
cilindros, debido a que dichas pistas y cilindros pueden tener que reservarse para el
archivo.
6. Para determinar el nmero de cilindros requeridos para almacenar el archivo, ha de
conocerse otras caractersticas de los paquetes de discos usados por SoundStage
Entertainment.
5.5.5 DISEAR Y DOCUMENTAR LAS BASES DE DATOS

El diseo de una base de datos cualquiera involucra por lo general al administrador de

bases de datos y a los especialitas en bases de datos. Estos gestionaran los detalles
tcnicos y las cuestiones referidas a otras aplicaciones. Sin embargo, ser de utilidad
para el analista de sistemas comprender los fundamentos de los principios de diseo
para las bases de datos relacinales.
Paso 1: Revisar requisitos de bases de datos

Paso 2: Disear el esquema lgico de las bases de datos
Paso 3: Hacer un prototipo de las bases de datos
Un esquema es el modelo estructural de una base de datos. Cualquier SGBD dado

soporta dos esquemas, un esquema lgico y un esquema fsico.
Estos dos esquemas especifican las estructuras fsica y la lgica de los registros en una
base de datos.
El esquema fsico define estructuras de datos, mtodos de acceso, organizaciones de

archivo, ndices, bloqueo, punteros y otros atributos fsicos.
El esquema lgico define la base de datos en trminos ms sencillos desde el punto de

vista de los usuarios finales y los programadores.
5.6 DISEO DE LAS ENTRADAS Y SALIDAS
5.6.1 DIRECTRICES DEL DISEO DE ENTRADAS Y SALIDAS
Las salidas presentan informaciones a los usuarios. Las salidas, el componente ms

visible de un sistema de informacin de trabajo, son la justificacin del sistema.
Durante el anlisis de sistemas, se definieron las necesidades y los requisitos de salidas,

pero no se disearon dichas salidas. Existen dos tipos bsicos de salidas informticas. El
primer tipo es el de las salidas externas.
Las salidas externas emergen del sistema para desencadenar o solicitar la confirmacin
de acciones en el exterior.
Las salidas de uso cclico son aquellas que se implantan tpicamente como formularios
que, finalmente, vuelven al sistema como entradas.
Las salidas internas permanecen dentro del sistema para apoyar el trabajo de los
usuarios y administradores del mismo.
5.6.2 CAPTURA DE ENTRADAS DE DATOS
La captura de datos es la identificacin de los nuevos datos que han de introducirse.

Un documento fuente es un formulario utilizado para registrar los datos que, en ultima
instancia, se introducirn en un ordenador. Los documentos fuente deberan ser faciales
de rellenar por los usuarios del sistema y facilitar la entrada rpida de datos en un
formato comprensible por la maquina.
La entrada de datos es el proceso de traduccin de documento fuente a un formato
comprensible por la maquina. Este formato puede ser una tarjeta perforada, una hoja
con marcas pticas, una cinta magntica o un disquete flexible, por citar solo algunos
casos.
La introduccin de datos es la entrada real de los datos en el ordenador en un formato

comprensible por la maquina.
5.6.3 FORMATO DE LAS ENTRADAS Y SALIDAS
El analista es normalmente el encargado de recomendar el mtodo, el soporte y el

formato de todas las entradas y salidas.
Mtodos y soportes de entradas por lotes
Un mtodo posible de proceso de las entradas es el conocido como entradas por lotes.
La entrada por lotes es el mtodo de entrada ms antiguo y tradicional. En el, se

recogen los documentos originales y se entregan peridicamente a los operadores de
introduccin de datos, quienes teclean dichos datos por medio de un dispositivo de
introduccin de datos que traduce a un formato comprensible por la maquina.
Mtodos y soportes de entradas en lnea
Un mtodo alternativo cada vez ms popular en el proceso de las entradas importantes

es el conocido como entradas en lnea.
La entrada en lnea es la captura de los datos en el lugar de la empresa donde se

originan y su introduccin directa en el ordenador, preferiblemente tan pronto como sea
posible. En la actualidad, la mayora de los sistemas, si no todos, utilizan o estn
empezando a utilizar mtodos de entrada de datos en lnea.
Soportes y formatos de salida
Un buen analista de sistemas considerara todas las opciones posibles para la

implantacin de una salida, en especial el soporte de la salida y el formato dela misma.
Un soporte es donde se graba la informacin de salida, como por ejemplo papel o un

dispositivo de visualizacin de imagen.
El formato es el modo en que se presenta la informacin en un soporte, por ejemplo en

columnas de nmeros.
5.6.4 CONTROLES INTERNOS DE LAS ENTRADAS Y LAS SALIDAS
Los controles de entrada aseguran que la introduccin de datos en el ordenador sea

precisa y que el sistema este protegido ante errores y abusos accidentales e intencionales
incluidos fraude.
Los controles de salida aseguran la fiabilidad y la distribucin de las salidas generadas

por el ordenador. Para las entradas, se ofrecen las siguientes directrices de control
interno:
1. Debera hacerse un seguimiento del nmero de entradas.
2. Debe ponerse especial atencin en garantizar que los datos son validos.
5.7 DISEO INTERFASE DE USUARIO
5.7.1 ESTRATEGIAS DE LAS INTERFACES DE USUARIO
Puede emplearse alguna estrategia especfica para disear una mejor interfaz de
usuario? Efectivamente, existen varias estrategias de este tipo y la eleccin de la mejor
de ellas depende de las funciones que se vayan a realizar y de las caractersticas del
usuario del sistema. Examinemos brevemente estas estrategias:
Seleccin en mens
Conjunto de instrucciones
Dilogos de preguntas-respuestas
Grficos
5.8 DISEO DE PROGRAMAS
5.8.1 DISEO MODULAR DE PROGRAMAS
Vamos a centrar nuestra atencin en el modo en que han de presentarse las

especificaciones de programacin a los programadores informticos para su
implantacin. Con este fin, veremos el diseo de programas como la combinacin de dos
componentes:
Diseo modular, o descomposicin de un programa en fragmentos

manejables.
Paquete, o conjunto de entradas, salidas, archivos, interfaz de usuario y
especificaciones de proceso de cada modulo.
5.8.2 COMO HACER EL DISEO MODULAR DE PROGRAMAS
Los programas han sido identificados a partir de las unidades de diseo. Dado estos
programas, queremos fragmentarlos en modelos manejables en torno a los cuales
podamos escribir las especificaciones del programa. Los programas podrn Ali
constituir y probar cada modulo de forma diferente. Despus, los mdulos podrn
integrarse conforme al grafico de estructuras y probarse como programas completos.
Paso 1: Definir la estructura de alto nivel

Paso 2: Identificar centros de transaccin
5.8.3 DESCOMPOSICIN MODULAR DE PROGRAMAS
Un modulo es un grupo de instrucciones ejecutables con un nico punto de entrada y un

nico punto de salida.
Existen algunos mdulos que realizan funciones nicas. Algunas de ellas serian:
Leer un registro
Editar un registro
Calcular un pago
Aadir un registro a un archivo
5.8.4 ESPECIFICACIONES DE PROGRAMAS POR PAQUETES
El paquete de especificaciones de programas es una coleccin de documentacin de

diseo que comunica con claridad los requisitos de cada programa informatico en el
sistema. Todos los programas realizan tres tipos de tareas: la introduccin o lectura de
datos, la manipulacin de los datos de entrada y la salida de datos o informacin. En
otras palabras, todas las tareas de los programas pueden clasificarse conforme a los
requisitos de entradas, procesos i salidas (EPS). En este modelo nos ayudara a obtener
los requisitos para implantar un programa informatico.
CAPITULO
IMPLEMENTACION DE SISTEMAS
6.1 CONCEPTO
Es la construccin del nuevo sistema y la entrega de dicho sistema a produccin
(explotacin diaria). Por desgracia, uno de sus sinnimos comunes es desarrollo de
sistemas.
6.2 FASE DE CONSTRUCCIN PRUEBA DE REDES Y BASES DE

DATOS EN LA IMPLEMENTACIN
En muchos casos, se construyen aplicaciones nuevas o mejoradas en torno a redes y
bases de datos ya existentes. Si as fuera esta fase se omitira. Sin embargo, si la nueva
aplicacin requiere redes y bases de datos nuevas o modificadas, deberan implantarse
normalmente antes de escribir o instalar los programas informticos, dado que los
programas de aplicacin harn uso de dichas redes y bases de datos. As, la primera
fase de algunas implantaciones ser la construccin y la pruebas de redes y bases de
datos.
Bloques elementales para construir y probar redes y bases de datos
Los objetivos fundamentales de la fase de construccin y pruebas de redes y bases de

datos son los siguientes:
Construir (o modificar) y probar las redes.

Construir (o modificar) y probar las bases de datos vacas.
Actividades, participantes y tcnicas de la construccin y pruebas de

redes y bases de datos
Actividad 1: Construir y probar redes (si es necesario)

Actividad 2: Construir y probar bases de datos (si es necesario)
6.3 FASE DE INSTALACIN Y PRUEBAS EN LA IMPLANTACIN

DE SISTEMAS
Es durante esta fase cuando se instalan y se prueban los paquetes de software. Para
garantizar que se satisfacen los requisitos de integracin del nuevo sistema, se lleva otra
vez a cabo una prueba completa del sistema. Finalmente, durante esta fase se desarrolla
un plan de conversin para orientar con xito la entrega del nuevo sistema a
produccin.
Bloques elementales para las fases de instalacin y pruebas del nuevo

sistema
Los objetivos fundamentales de esta fase son:
Instalar y probar los nuevos paquetes de software adquiridos de los

vendedores.
Realizar una prueba completa del sistema para garantizar que los paquetes
de software adaptado a las necesidades y del software adquirido funcionan
juntos de una forma apropiada.
Desarrollar un plan detallado para convertir el sistema antiguo en el nuevo
sistema.
Actividades, participantes y tcnicas de la instalacin y las pruebas del

nuevo sistema
Actividad 1: Instalar nuevo paquete de software (si es necesario).

Actividad 2: Probar el paquete (si es necesario).
Actividad 3: Realizar una prueba del sistema (si es necesario).
Actividad 4: Preparar un plan de conversin.
6.4 FASE DE ENTREGA DEL NUEVO SISTEMA PARA

EXPLOTACIN DE LA IMPLANTACIN.
Ahora, pasemos a la ltima fase de implantacin de nuestro ciclo de vida: la entrega del
nuevo sistema para su puesta en produccin. El analista es la figura principal en esta
fase de entrega, con independencia de cual haya sido su participacin en la construccin
del sistema.
Bloques elementales en la fase de entrega del nuevo sistema para su paso

a explotacin
El propsito de la fase de entrega del nuevo sistema para su paso a explotacin es

convertir suavemente el sistema antiguo en nuevo sistema. Para lograr este propsito de
esta fase, debemos alcanzar los siguientes objetivos:
Instalar los archivos o bases de datos que utilizara el nuevo sistema.

Ofrecer formacin y documentacin a las personas que utilizaran el nuevo
sistema.
Convertir el sistema antiguo en el nuevo sistema.
Evaluar el proyecto y el sistema final.
Actividades, participantes y tcnicas de la fase de entrega del nuevo

sistema para su paso a explotacin
Actividad 1: Instalar los archivos o bases de datos.

Actividad 2: Impartir formacin a los usuarios del sistema.
Actividad 3: Pasar al nuevo sistema.
CAPITULO
SOPORTE DEL SISTEMA

7.1 MANTENIMIENTO DE SISTEMAS
Con independencia de cmo esta diseado, construido y probado un sistema o

aplicacin, inevitablemente aparecern errores. Algunos de estos errores tendrn su
origen en fallos en la comunicacin de las necesidades. Otros estarn provocados por
defectos de diseo. Los habr tambin originados por situaciones no previstas y, por
tanto, no probadas. Y, por ultimo, los errores pueden ser causados tambin por un mal
uso no previsto de los programas. En todas estas situaciones, deben emprenderse
acciones de correccin.
A estas acciones las llamamos mantenimiento de sistemas o mantenimiento de

programas.
Objetivos y bloques elementales del mantenimiento de sistemas
Los objetivos fundamentales del mantenimiento de sistemas son:

Hacer cambios predecibles en los programas existentes para corregir errores
que se cometieron durante el diseo y la implantacin de sistemas. En
consecuencia, excluimos de esta actividad las mejoras y las nuevas
necesidades.
Preservar aquellos aspectos de los programas que fueron ya corregidos. Al
contrario, intentaremos evitar la posibilidad de que los arreglos en dichos
programas originen que otros aspectos de los mismos y las nuevas
necesidades.
Tareas, participantes del mantenimiento de sistemas
Pasemos ahora a revisar las directrices generales para la lectura de dichos diagramas:
Las siluetas representan personas o departamentos que inician tareas.

Los rectngulos redondeados representan tareas. Cada tarea esta enumerada
de forma nica por cuestiones de identificacin. El nombre de la tarea se
imprime en la mitad superior del smbolo. Los participantes en dicha tarea se
imprimen en la mitad inferior del smbolo. El participante es siempre la

persona que dirige la tarea.
Las fechas reflejan las entradas y las salidas de una tarea. Todas ellas tienen
un nombre. Cuando se hace referencia a una de estas entradas o salidas en el
texto, aparece subraya.
7.2 RECUPERACIN DEL SISTEMA: SUPERAR LOS FALLOS

GENERALES.
De cuando en cuando, es inevitable que un sistema falle. Este fallo se traduce

generalmente en lo que se llama un programa abortado (tambin llamado ABEND o
crash) y en posible perdido de datos. Entonces, es a menudo el analista de sistemas el
encargado de arreglar el sistema o de actuar como intermediario entre los usuarios y
quienes deben recuperar el sistema. El propsito de esta secciona es resumir brevemente
el papel del analista en la recuperacin de los sistemas.
En esta actividad no requiere un diagrama de flujo multitarea para detallar sus pasos, y
puede resumirse del modo siguiente:
En muchos casos, el analista puede sentarse ante el terminal de usuario y recuperar el

sistema. A veces, puede ser tan sencillo como pulsar una tecla especifica o volver a
arrancar el ordenador principal.
7.3 ASISTENCIA AL USUARIO FINAL
Otra actividad permanente y relativamente rutinaria en el soporte de sistemas es la

asistencia rutinaria al usuario final. Independientemente de cmo haya sido la
formacin de usuarios o de la calidad de la documentacin, los usuarios requerirn
asistencia adicional. El analista de sistemas esta, por lo general, a disposicin de los
usuarios para ofrecerles ayuda en el uso diario de aplicaciones especificas. En
aplicaciones de mxima importancia, el analista debe estar disponible da y noche.
Una vez mas, es necesario ofrecer un diagramas de flujo detallado para esta actividad.
Las tareas ms caractersticas comprenden:
Observacin rutinaria del uso del sistema.

Realizacin de estudios y reuniones para conocer el grado de satisfaccin del
usuario.
Cambiar los procedimientos de empresa para que sean mas claros (se
escribirn y se grabaran en el diccionario).
Ofrecer formacin adicional.
Anotar en el diccionario las ideas y las solicitudes sobre posibles mejoras.
7.4 MEJORAS Y REINGENIERA DE SISTEMAS
La adaptacin de un sistema existente a las nuevas necesidades es una posibilidad

siempre abierta en todo los sistemas de nueva implantacin. El mantenimiento ligado a
estas adaptaciones obliga al analista a analizar las nuevas necesidades y volver a las
fases adecuadas del anlisis, del diseo y la implantacin de sistemas. En esta seccin,
examinaremos dos tipos de mantenimiento de adaptaciones: las mejoras a los sistemas y
la reingeniera de sistemas.
Objetivos y bloques elementales de las mejoras y la reingeniera de

sistemas
El objetivo de las mejoras al sistema es modificar o ampliar el sistema de aplicacin

como respuesta a las constantemente cambiantes necesidades de empresa. Este objetivo
puede relacionarse con os bloques elementales de los sistemas de informacin del modo
siguiente:
Personas: En su mayora, las mejoras a los sistemas son propuestos por los
usuarios de los sistemas, si bien los analistas, diseadores y constructores de
sistemas tambin pueden detectar posibles problemas tcnicos relativos al
rendimiento, la seguridad y los controles internos.
Datos: Muchas mejoras de los sistemas son demandas de nueva informacin

que pueden derivarse de datos almacenados existentes. Algunas mejoras de
datos pueden requerir la ampliacin del almacenamiento de datos.
Procesos: En su mayora, las mejoras a los sistemas requieren la

modificacin de programas existentes o la creacin de nuevos programas
para ampliar el mbito general del sistema de aplicaciones.
Redes: En su mayora, las mejoras a los sistemas no tienen que ver con las
redes.
Tecnologa: En su mayora, las mejoras a los sistemas se basan en la

tecnologa.
CAPITULO
GESTIN DE PROYECTOS
En cualquier proyecto de desarrollo de sistemas, es necesario disponer de una gestin de
proyectos eficaz para garantizar que el proyecto cumple los objetivos y que se desarrolla
dentro de un presupuesto aceptable.
La gestin de proyectos es el proceso por el cual se planifica, dirige y controla el

desarrollo de un sistema aceptable con un coste mnimo y dentro de un periodo de
tiempo especifico.
Aunque las herramientas y tcnicas del anlisis y el diseo de sistemas desempean un

papel fundamental en obtener sistemas que funcionen, estos mtodos no son suficientes
por si mismos. Como vimos en el minicaso anterior, una mala gestin de proyectos, o
hacerlos ineficaces El minicaso que abre el modulo resalta las cuatro consecuencias ms
comunes derivadas de una deficiente gestin de proyectos:
Necesidades no satisfecha o no identificadas.

Cambio incontrolado del mbito del proyecto.
Exceso de coste.
Retrasos en la entrega.
Estos problemas no siempre son debidos a una mala gestin de proyectos, pero no cabe
duda de que esta tiene una importante responsabilidad en que aparezcan.
8.1 CAUSAS DE PROYECTOS FALLIDOS POR LA GESTIN.
Deficiente gestin de las expectativas. El problema es que, durante las primeras fases, el
mbito del proyecto rara vez es suficientemente preciso. Y en muchos proyectos, dicho
mbito nunca llega a definirse con precisin. Si el jefe del proyecto no se da cuenta de
este problema, el equipo del proyecto se vera con frecuencia obligado a aumentar el
mbito del proyecto (a veces, se llama a este problema sndrome de las necesidades que
crecen) o hacer cambios de ultima hora en las especificaciones y los programas.
Uno de los principales problemas asociados al exceso de coste es que muchas

metodologa o planes de proyecto requieren una estimacin excesivamente precisa de los
costes antes de empezar el proyecto .Esta estimaciones se hacen despus de un rpido

estudio previo o de viabilidad.
Para ser un buen director de proyectos, el analista debe poseer una buena formacin en
las funciones bsicas de direccin.
Funciones bsicas del director de proyectos
El director de proyectos no es simplemente un analista experimentado que se hace cargo

de un proyecto. Un director de proyectos debe aplicar un conjunto de tcnicas y
conocimientos diferentes de los que aplica un analista. Entre estas funciones se incluyen
la planificacin, la seleccin de personal, la organizacin, la definicin de calendarios,
la direccin y el control.
8.2 HERRAMIENTAS Y TCNICAS DE GESTIN DE PROYECTO

Existen muchas herramientas y tcnicas de gestin de proyectos, suficientes como para
llenar todo un libro En esta seccin, ofreceremos una introduccin a dos herramientas
de planificacin y control de proyectos, y a una sencilla herramienta de gestin de las
expectativas.
8.2.1 GRFICOS PERT
Pert, que significa Project o Program Evaluacin and Review Technique (tcnica de
evaluacin y revisin de proyectos o programas), fue desarrollado a finales de la becada
1950-1959 para planear y controlar los grandes proyectos de desarrollo armamentstico
del ejercito estadounidense. Fue desarrollado para evidenciar la interdependencia de las
tareas de los proyectos cuando se realizan la planificacin de los mismos. En esencia,
PERT es una tcnica de modelos grficos interrelacionados.
EL GRFICO
El grfico PERT, es la representacin grfica de las relaciones entre todos los
acontecimientos y tareas necesarias para realizar un proyecto.
Un acontecimiento (representado por un circulo) es un instante especfico del tiempo;
por consiguiente un acontecimiento no consume tiempo. Un acontecimiento puede ser el
principio o el fin de una tarea, un punto en el tiempo que puede ser reconocido e
identificado claramente.
Una actividad (representada por una fecha) es el trabajo necesario para alcanzar un
acontecimiento. Una actividad no puede empezar hasta que todas las actividades
precedentes hayan sido terminadas.
As un grfico est compuesto por un cierto nmero de acontecimientos ligados entre s
mediante actividades.
El grfico comienza con un nico acontecimiento inicial, se ramifica en varios caminos

que ligan diversos acontecimientos, y termina en un acontecimiento final que seala el
fin del proyecto.
Puesto que el PERT es una tcnica orientada hacia los acontecimientos, el inters se
centra en el inicio o trmino de los acontecimientos ms que las mismas actividades.
REGLAS BSICAS
Regla 1: Se usa una, y slo una flecha para representar una actividad a ejecutarse. La
longitud de la flecha y la direccin en que est orientada no tienen significado alguno.
Regla 2: El diagrama se construye conectando flechas que representa actividades,
considerando para cada una las tres preguntas siguientes:
a) Qu precede inmediatamente a esta actividad
b) Qu sigue inmediatamente a esta actividad
c) Qu actividades son concurrentes.
Regla 3: Iniciar el diagrama con una flecha preliminar.
Regla 4: Enumerar los acontecimientos.
Regla 5: Utilice las actividades ficticias, solo cuando precise mantener la lgica del
diagrama.
ESTIMACIONES TEMPORALES
Una vez que se ha logrado un grfico correcto, con los detalles adecuados, es necesario
establecer una estimacin de la duracin de cada una de las actividades; y aunque
podra utilizarse una nica estimacin, habitualmente se emplean tres estimaciones:
1.- Duracin Optimista (to): tiempo que se necesita para efectuar la actividad si no se
presentas dificultades o complicaciones imprevistas.
En la mayora de los casos la probabilidad de realizar la actividad en este tiempo es
pequea. Una regla prctica para este caso es que: slo existe una probabilidad de un
uno por ciento de realizar la actividad en un tiempo menos que la duracin optimista.
2.- Duracin Ms probable (tm): tiempo que es ms probable que necesite la actividad
para su realizacin. Esta estimacin debe tener en cuenta las circunstancias normales,
considerando algunos retrasos debidos a imprevistos, y debe estar basada en la mejor
informacin de que pueda disponerse.
3.- Duracin Pesimista (tp): tiempo que se necesita para efectuar la actividad si se
presentas dificultades inhabitales y complicaciones imprevistas.
COLECTA DE LAS ESTIMACIONES DE LAS DURACIONES

Las estimaciones de las duraciones las obtendr el analista PERT de las personas que
tienen la responsabilidad de efectuar el trabajo que representan las actividades.
Las duraciones se solicitan habitualmente en entrevistas, es decir, oralmente, con
preferencia a las comunicaciones escritas. Las estimaciones se obtendrn sin seguir el
orden secuencial que representa el grfico. Si las estimaciones se obtienen siguiendo un
camino, existe la tendencia de ir sumando mentalmente y comparando con la idea
preconcebida que se posee de la duracin del camino. Cuando esto ocurre y el tiempo
acumulado es diferente del preconcebido, el estimador consciente o inconscientemente
tiende a igualar las dos estimaciones. Evaluando las actividades sin orden se ayuda a
que cada una sea considerada independientemente de las dems.
NUMERACIN DE LOS ACONTECIMIENTOS

Los acontecimientos deben numerarse secuencial mente cuando el grfico est
terminado, esto es antes de comenzar los clculos.
Cuando la numeracin comienza en el acontecimiento inicial y prosigue secuencial
mente a travs del grfico, cada acontecimiento sucesor posee un nmero mayor que sus
predecesores.
De esta forma el circuito puede detectarse fcilmente, puesto que una actividad tendr
un nmero mayor en la cola del arco que en la cabeza.
PASOS PARA DIAGRAMAR UN PROYECTO

1.- LISTA DE ACTIVIDADES
Formular la lista de actividades a desarrollar de la siguiente manera:
A Estudio de factibilidad.
B Diseo general del sistema.
C Seleccin del personal.
D Capacitacin del personal.
E Estudio de aplicaciones.
F Estudio de financiacin.
G Estudio de equipos.
H Seleccin de equipos.
I Evaluacin final.
J Programacin.
K Envo de equipo.
L Recepcin de equipo.
M Preparacin del lugar.
N Instalacin del sistema de comunicaciones.
O Instalacin del equipo.
P Puesta a punto de programas.
Q Capacitacin de usuarios.
R Prueba del sistema.
S Puesta a punto del sistema.
T Operacin paralela.
2.- SECUENCIA LGICA DE ACTIVIDADES

Sobre la base de la lista anterior se establece la secuencia lgica de las actividades.
3.- DIBUJAR EL DIAGRAMA DE RED

Al construir el diagrama, se debe tener en cuenta para cada una de las actividades:
Qu actividad precede inmediatamente a esta actividad
Qu actividad sigue inmediatamente a esta actividad
Qu actividades son concurrentes
8.2.2 GRFICOS GANTT
El grafico de Gantt es una sencilla herramienta de grficos de tiempos que fue

desarrollada por Henry L. Gantt en 1917. Loas grficos de Gantt, que aun hoy
mantienen su popularidad, resultan bastante eficaces para la planificacin y la
evaluacin del avance de los proyecto. Al igual que los grficos de PERT, los grficos de
Gantt se basan en un enfoque grafico. La popularidad de los grficos de Gantt se deriva
de su sencillez: son fciles de aprender, leer, preparar y usar.
Un grafico de Gantt es un sencillo grafico de barras. Cada barra simboliza una tarea
del proyecto. En un grafico de Gantt, el eje horizontal representa al tiempo. Como los
grficos de Gantt se emplean para encadenar tareas entre si, el eje horizontal debera
incluir fechas. Verticalmente, y en columna izquierda, se ofrece una relaciona de las
tareas.
8.2.3 SOFTWARE DE GESTIN DE PROYECTOS
El software de gestin de proyectos se introdujo ya en el capitulo 5 como un tipo de

herramienta CASE. Ejemplos de paquetes de este tipo son Proyect, de Microsoft, y
Proyect Manager Workbench, de Applied Business Technology. Estos paquetes
simplifican enormemente la preparacin de grficos PERT y de Gantt, permitiendo la
transformacin automtica entre ambos tipos de grficos. El software permite tambin a
los directores de proyectos asignar recursos humanos y econmicos a las tareas,
informar sobre la evolucin del proyecto y hacer ensayos del tipo si-entonces cuando se
intente modificar e plan del proyecto como consecuencia de las desviaciones en el
calendario.
8.2.4 GESTIN DE RECURSOS HUMANOS
La gestin o supervisin de los miembros de un equipo de proyecto es tan importante

como la planificacin y el control del calendario, el presupuesto y las expectativas del
proyecto. Esta cuestin podra merecer un modulo completo dedicado especficamente a
ella.
8.3 TCNICAS DE INVESTIGACIN DE HECHOS
8.3.1 CONCEPTOS DE INVESTIGACIN DE HECHOS
La investigacin de hechos es un proceso formal que utiliza procedimientos de

bsqueda, entrevistas, cuestionarios, muestreo y otras tcnicas para recoger toda la
informacin disponible sobre los sistemas, sus necesidades y las preferencias mostradas.
8.3.2 HECHOS QUE DEBEN RECABAR EL ANALISTA DE SISTEMAS Y

CUANDO
La investigacin de hechos es vital importancia principalmente durante las fases de la

planificacin y el anlisis de sistemas. Es durante estas fases cuando el analista aprende
el vocabulario de la empresa y el sistema, Ali como sus problemas, oportunidades,
limitaciones, necesidades y prioridades. La investigacin de hechos se usa tambin
durante las fases de diseo y soporte, pero en menor medida.
8.3.3 MTODOS DE INVESTIGACIN DE HECHOS DISPONIBLES
Ahora que disponemos de un marco de trabajo para nuestras actividades de

investigacin de hechos, podemos introducir seis tcnicas comunes de investigacin de
hechos:
1. Muestreo de la documentacin, los formularios y los archivos existentes.

2. Investigacin y visitas a instalaciones.
3. Observacin del entorno de trabajo.
4. Cuestionarios.
5. Entrevistas.
6. Diseo de conjunto de aplicaciones (DCA).
8.3.4 MUESTREO DE LA DOCUMENTACIN, LOS FORMULARIOS Y LOS

ARCHIVOS EXISTENTES
En particular, cuando se estudia un sistema existente, puede conseguirse una buena

comprensin del mismo si se analizan la documentacin, los formularios y los archivos
existentes. Un buen analista deduce los hechos antes de la documentacin existente que
de las personas.
Tcnicas de muestreo de documentos y archivos
Como no seria nada practico estudiar todas las presencias de cada uno de los
formularios,
Los analistas suelen aplicar tcnicas de muestreo para obtener una idea general de lo
que esta sucediendo en el sistema.
El muestreo es un proceso de recogida de documentos, formularios y archivos existentes.
Como determinar el tamao de muestra
El tamao de una muestra depende de lo representativa que se quiere que sea dicha
muestra. Existen muchas cuestiones y factores de diseo, en si mismos una buena razn
para asistir a un curso introductorio sobre tcnicas estadsticas.
Seleccionar la muestra
Dos tcnicas de muestreo de uso corriente son el muestreo aleatorio y el muestreo por
estatificacin.
El muestreo aleatorio es una tcnica de muestreo caracterizada por carecer de modelo o

plan de seleccin de los datos de muestra.
La estratificacin es una tcnica de muetreo sistemtico que intenta reducir la varianza

propia de los valores por medio de la ampliacin del muestreo y la eliminacin de la
muestra de los valores excesivamente altos o excesivamente bajo.
8.3.5 INVESTIGACIN Y VISITAS A INSTALACIONES
Una segunda tcnica de investigacin de hechos es la consistente en llevar a cabo una

detenida investigacin de la aplicacin y el problema. Buenas fuentes de
informacin son las publicaciones informticas disponibles comercialmente, as
como las entrevistas que leen tpicamente los usuarios finales. De esta forma, ser
posible aprender el modo en que actuaron otros para resolver problemas
similares. Tambin puede saberse as si existen o no paquetes de software que
puedan resolver nuestro problema.
8.3.6 OBSERVACIN DEL ENTORNO DE TRABAJO
La observacin es una de las tcnicas mas eficaces para reunin de datos que nos
ayuden a conseguir comprender un sistema.
La observacin es una tcnica de investigacin de hechos durante la cual los analistas o

bien participan activamente o bien actan como espectadores de las actividades llevadas
a cabo por una persona para conocer mejor un sistema.
Esta tcnica se utiliza con frecuencia cuando no se esta seguro de la validez de los datos
recogidos por otro medio o cuando la complejidad de ciertos aspectos del sistema
impide que las explicaciones de los usuarios finales estn claras.
8.3.7 CUESTIONARIOS
Otra tcnica de investigacin de hechos es la consistente en realizar estudios mediante

cuestionarios.
Los cuestionarios son documentos especificaos que permiten al analista recoger la

informacin y las opiniones que le manifiestan las personas encuestadas.
Tipos de cuestionarios
Existen dos formatos de cuestionarios: en formato libre y en formato fijo.
Los cuestionarios con formato libre permiten al encuestado una gran libertad de
respuesta. El encuestado escribe la contestacin en un espacio en blanco reservado
inmediatamente debajo de la pregunta.
Los cuestionarios con formato fijo contienen preguntas que requieren respuestas
especficas por parte de las personas encuestadas.
Diseo de cuestionarios
Los buenos cuestionarios han de ser diseados. Si se escriben cuestionarios sin haberlos
antes diseado, las posibilidades de xito sern limitadas. El procedimiento que se
indica a continuacin ha demostrado ya su eficacia:
1. Determine que hechos y opiniones deben recabarse y de que personas. Si el numero

de personas es muy amplio, considere la posibilidad de utilizar un grupo de
encuestados menor y seleccionado aleatoriamente.
2. Sobre la base de los hechos y opiniones necesarios, determine que tipo de

cuestionario producira mejores respuestas: con formato fijo o con formato libre. A
menudo, se utiliza una combinacin de formatos que permita realizar aclaraciones
en formato libre a respuestas en formato fijo.
3. Escriba las preguntas. Examnelas bien para evitar que contengan errores de
expresin o que puedan dar lugar a interpretaciones errneas. Asegrese de que las
preguntas no dan indicios de sus opiniones personales. Edite las preguntas.
4. Pruebe las preguntas en un grupo pequeo de muestra de encuestados. Si sus

encuestados tuvieran problemas para responder a ellas o si las respuestas carecan
de utilidad, modifquela.
5. Haga copias y distribuya el cuestionario.
8.3.8 ENTREVISTAS
La entrevista personal es reconocida, por lo general, como la tcnica de investigacin de

hechos ms importante y ms frecuentemente utilizada
Las entrevistas son tcnicas de investigacin de hechos durante las cuales el analista
recoge la informacin que la suministran las personas cara a cara.
Tipo y tcnicas de entrevistas
Existen dos tipos de entrevistas, estructuradas y no estructuradas.
Las entrevistas estructuradas, el entrevistador posee un conjunto especfico de

preguntas que desea plantear al entrevistado.
Las entrevistas no estructuradas son desarrolladas solo con un objetivo o un tema

general en mente y pocas preguntas especficas, tal vez ninguna. El entrevistador cuenta,
en este caso, con el entrevistado para definir el contexto general de la entrevista y dirigir
la conversacin.
Como dirigir una entrevista
El xito de un analista de sistemas depende, al menos en parte, de su capacidad para

hacer entrevistas. Una buena entrevista supondr la seleccin de las personas adecuada
para las entrevistas, la preparacin intensiva de la entrevista, la correcta direccin de la
entrevista y el seguimiento de la entrevista.
Diseo conjunto de aplicaciones
La tcnica clsica de investigacin de hechos ha sido siempre la elaboracin de

entrevistas por separado a los usuarios finales. Sin embargo, muchos analistas han
tenido grandes problemas con las entrevistas: estas, por separado, a menudo dan como
conclusiones hechos, opiniones y prioridades en conflicto. Como resultado hay que
hacer numerosas entrevistas de seguimiento y reuniones en grupo. Por este motivo,
muchos centros de informacin esta haciendo uso de secciones de trabajo en grupo
como sustitutas de las entrevistas.
El diseo conjunto de aplicaciones (DCA) es un proceso por el cual se levan a cabo

reuniones en grupo altamente estructuradas que convocan en una misma sala a los
usuarios de sistema, los propietarios del sistema y los analistas durantes un amplio
periodo de tiempo.
CAPITULO
ANALISIS DE VARIABLES
9.1 ANLISIS DE VARIABLE
Trata sobre los elementos variables y los mtodos de clculos utilizados al por el
analista y las empresas al momento de involucrarse en el desarrollo de una aplicacin.
9.1.1 MTODO DE CONTROL PROGRESIVO
Este modulo habla sobre el anlisis de costes y beneficios y otro temas referidos a la
viabilidad que son de inters para los analistas y los usuarios de los sistemas de
informacin. Pocas cuestiones hay tan importantes como esta. El anlisis de viabilidad
no es, realidad, un anlisis de sistemas, y tampoco un diseo d sistemas Mas bien es una
actividad cruzada del ciclo de vida y debera llevarse a cabo permanentemente en el
discurrir de los proyectos de sistemas.
9.1.2 PUNTOS DE CONTROL DE VIABILIDAD EN EL CICLO DE VIDA
Empecemos por dar una definicin formal de viabilidad y anlisis de viabilidad
La viabilidad es la medida del beneficio obtenido en una organizacin gracias al

desarrollo de un sistema de informacin.
El anlisis de viabilidad es el proceso por el cual se mide la viabilidad.
Cuadro de tests de viabilidad
Hasta ahora, hemos definido viabilidad y anlisis de viabilidad, y hemos sealado los
puntos de control de la viabilidad en el ciclo de vida. En su Mayorga, los analistas
coinciden en que existen cuatro categoras de tests de viabilidad:
La viabilidad operativa es una medida del correcto funcionamiento de una posible

solucin a los problemas dentro de una organizacin Tambin es una medida de los
sentimientos que despierta un sistema o un proyecto en las personas que en el
participan.
La viabilidad tcnica es una medida del xito de la puesta en prctica de una

solucin tcnica especfica y de la disponibilidad de los recursos y los conocimientos
tcnicos necesarios.
La viabilidad de fechas es una medida que indica si un proyecto es razonable en el

cumplimiento de su calendario.
La viabilidad econmica es una medida de la eficacia de los costes asociados a un

proyecto o una soluciona. A menudo, suele recibir el nombre de anlisis de costes y
beneficios.
9.2 TCNICAS DE ANLISIS DE COSTES Y BENEFICIOS
La viabilidad econmica se ha definido como un anlisis de costes y beneficios.
9.2.1 CUANTO COSTAR EL SISTEMA?
Los costes pueden encuadrarse en dos categora. Existen costes asociados al desarrollo
del sistema y costes asociados al funcionamiento del sistema.
Los costes de desarrollo de u sistema de informacin pueden clasificarse en funciona de

la fase en que tienen lugar. En los costes del desarrollo de sistemas se incurre por lo
general solo una vez y no vuelven a producirse una vez completado el proyecto. Muchas
organizaciones tienen categoras estndar de costes que deben evaluar. En ausencia de
tales categoras, podra servirnos de ayuda la siguiente lista:
Coste de personal
Uso informatico
Formacin Costes de suministros, duplicaciones y equipos.
Coste de cualquier nuevo equipo informatico o software.
Los costes fijos se producen a intervalos regulares y en relaciones relativamente fijas.

Ejemplos de costes de operacin fijos son:
Pagos de alquiler o pagos de licencias de software.

Salarios prorrateados de los operadores de sistemas de informacin y del
personal de soporte (aunque los salarios tienden a ascender, el aumento es
gradual y no suele cambiar drsticamente de un mes a otro).
Los costes variables se producen proporcionalmente a ciertos factores de utilizacin.

Por ejemplo:
Costes del uso de ordenadores (por ejemplo, tiempo de CPU usado, tiempo de
conexin al terminar usado, almacenamientos usados).
Suministros (por ejemplo, formularios preimpresos, papel de impresora utilizado,
tarjetas perforadas, discos flexibles, cintas magnticas y otros bienes fungibles),
que barran la carga de trabajo.
9.2.2 QUE BENEFICIOS SUMINISTRARA EL SISTEMA?
Los beneficios por lo general aumentan las ganancias o reducen los costes,
caractersticas ambas muy deseables en todo nuevo sistema de informacin.
En la mayor medida posible, los beneficios deberan cuantificarse en moneda corriente.

Los beneficios pueden clasificarse en tangibles e intangibles.
Los beneficios tangibles son aquellos que son fciles de cuantificar.
Los beneficios tangibles se suelen medir en trminos de ahorros mensuales o anuales, o

de las ganancias de la empresa.
Los beneficios intangibles son aquellos que se piensa serna difciles o imposibles de
cuantificar.
A menos que estos beneficios sean, como mnimo, identificados, podra ser totalmente
posible que muchos proyectos no fueran viables.
9.2.3 ES EFICAZ EL SISTEMA PROPUESTO EN TRMINOS DE COSTES?
Existen tres conocidas tcnicas para evaluar la viabilidad econmica, tambin

denominada eficacia de costes.
1. Anlisis de amortizacin.
2. Rentabilidad de la inversin.
3. Valor actual neto.
CAPITULO
TECNICAS INTERPERSONALES
10.1 COMUNICARSE CON LA GENTE
En los proyectos de sistema de informacin se interponen con frecuencia barreras de
comunicacin, por lo general creadas de forma intencionada o accidental por los
participantes en el proyecto. Los propietarios y los usuarios de los sistemas emplean su
propio lenguaje para describir los formularios, los mtodos, los procedimientos, etc. Los
diseadores y los constructores de sistemas tienen tan bien sus propios trminos,
acronitos y clichs para describir las mismas cosas. Como consecuencia, se ha abierto
un hueco en la comunicacin entre estos dos grupos.
10.1.1 CUATROS GRUPOS PARA LA COMUNICACIN INTERPERSONAL

DURANTE LOS PROYECTOS DE SISTEMAS
Durante aos, los expertos en las lenguas y comunicaciones nos han dicho que el secreto
para mantener buenas y eficaces dotes de comunicacin oral y escrita consiste en
conocer a quien nos dirigimos. Pueden identificarse, al menos, cuatros grupos distintos:
1. Diseadores de sistemas, entre los que se incluyen nuestros colegas (otros analistas
y especialistas en sistemas de informacin).
2. Constructores de sistemas, los programadores y especialista tcnicos que elaboraran

el sistema en prctica.
3. Usuarios de los sistemas, aquellas personas cuyo trabajo cotidiano se vera afectado
directa o indirectamente por el nuevo sistema.
4. Propietarios de los sistemas, quienes, adems de poder ser usuarios de los sistemas,
patrocinan el proyecto y aprueban los gastos de los sistemas.
10.1.2 USO DE LAS PALABRAS: EXPRESIONES POSITIVAS Y NEGATIVAS
Las expresiones positivas son palabras o frases que provocan en los oyentes respuestas
positivas. Estos trminos pueden utilizarse con gran eficacia para convencer a quienes
nos escuchan de las ventajas de los cambios que se proponen. Los directivos aceptaran
con mayor facilidad aquellas ideas que promuevan los actos reflejados por expresiones
positivas.
Las expresiones negativas son palabras o frases que provocan en los oyentes respuestas
negativas. Estos terminaos pueden tambin utilizarse de manera eficaz para convencer a
dichos oyentes de las ventajas de los cambios propuestos. Los directivos aceptaran con
mayor facilidad aquellas ideas que eliminen los hechos reflejados por las expresiones
negativas.
10.2 CORREO ELECTRNICO

Al parecer, se han encontrado continuamente medios nuevos y ms eficaces para la
comunicacin entre las personas. Una de las formas mas recientes de comunicacin
interpersonal, de particular importancia para el analista de sistemas, es el correo
electrnico.
El correo electrnico nos da la oportunidad de crear, editar, enviar y recibir

informacin electrnicamente, por lo general mediante el empleo de algn tipo de red
informtica. Lo nico que se necesita es un ordenador y algn tipo de software de
correo. Las ventajas de esta forma de comunicacin son evidentes. Una persona puede
enviar y recibir mensajes casi de forma instantnea prcticamente en contacto con
cualquier lugar del mundo (siempre y cuando el emisor y el receptor estn conectados a
alguna clase de red informtica). Estos mensajes pueden leerse, almacenarse,
imprimirse, editarse o borrarse. Adems, una vez que el software del sistema de correo y
la red informtica han sido instalados, el coste real del envo mensaje es muy pequeo.
10.3 LENGUAJE CORPORAL Y PROXMICA

El lenguaje corporal es toda aquella informacin que comunica una persona a otra sin
utilizar palabras. El lenguaje corporal es una forma de comunicacin no verbal que
todos los usamos, muchas veces sin darnos cuenta.
La proxmica es la relacin que se establece entre las personas y el espacio que las
rodea. La proxmica es un factor importante de la comunicacin que puede ser
controlado por los analistas que lo conozcan y dominen.
10.4 REUNIONES
Durante el transcurso de un proyecto de desarrollo de sistemas, normalmente se
mantienen muchas reuniones.
Una reunin es un intento de alcanzar un objetivo como resultado de su discusin por

varias personas.
10.4.1 PREPARAR UNA REUNIN
Muchas personas tienen una imagen negativa de las reuniones porque muchas reuniones
a las que han asistido estaban mal organizadas y deficientemente dirigidas. Las
reuniones tambin son muy caras, porque requieren que varias personas dediquen un
tiempo que podran haber invertido mejor en un trabajo ms productivo. Mientras mas
personas participen en una reunin, mas cara cera esta.
10.4.2 DIRIGIR UNA REUNIN
Intente llegar a tiempo, pero no empiece la reunin hasta que todo el mundo este
presente. Si algn participante importante llega con ms de quince minutos de retraso,
considere la posibilidad de cancelar la reunin. Una vez iniciada esta, intente evitar las
interrupciones o los retrasos motivados, por ejemplo, por llamadas telefnicas. Tenga
impresos suficientes para todos los participantes. Tenga un buen comienzo haciendo una
revisin de la agenda, de modo que los puntos de discusin se conviertan en propiedad
de todo el grupo. Despus aborde cada punto de la agenda conforme al tiempo que se le
asigno cuando se programo la reunin. El lder del grupo ha de procurar que ninguna
persona o ningn subgrupo se erijan en dominadores de la reunin o queden
marginados. Las decisiones deberan tomarse por consenso o por el voto de la mayora.
Una regla bsica es mantenerse siempre dentro del programa: tenerse a la agenda y
concluir a tiempo. Si no se terminan de discutir todos los puntos de la agenda, se
programara otra reunin.
10.4.3 SEGUIR UNA REUNIN
Tan pronto como sea posible despus de haber terminado la reunin, debera enviarse el
acta de la misma. Esta acta debe expresarse en un resumen escrito de breve extensin
sobre lo que ocurri durante la reunin: puntos tratados, decisiones tomadas y puntos
para consideraciones futuras. El acta es preparada normalmente por el secretario, un
miembro del equipo designado por el jefe de grupo.
10.4.4 REUNIONES DE PROYECTO
Una clase especial de reunin llevada a cabo por el analista es denominada reunin de
proyecto.
La reunin de proyectos es un tipo especial de reunin convocada para realizar

revisiones en grupo de la documentacin del desarrollo de sistemas. Estas reuniones
pueden utilizarse para revisar casi cualquier tipo de documentacin detallada.
10.4.5 QUIENES DEBERAN PARTICIPAR EN LA REUNIN DE

PROYECTO?
Un grupo de una reunin de proyectos debera constar de siete participantes como

mucho. Todos los miembros de la reunin deberan ser tratados como iguales. El
analista encargado de preparar la documentacin que ha de revisarse debera presentar
dicha documentacin al grupo durante la reunin. Otro analista o usuario clave del
sistema debera ser nombrado coordinador de la reunin. El coordinador se encarga de
programar la reunin y de asegurar que todos los participantes obtengan la
documentacin con suficiente antelacin con respecto a la fecha de reunin. Entre los
restantes participantes se incluyen usuarios del sistema, analistas o especialistas que
involucraran la documentacin. Estos revisores pueden asumir tambin papeles
especiales. Por ejemplo, algunos de ellos pueden evaluar la exactitud de la
documentacin, y otros encargarse de hacer comentarios sobre la calidad, las normas y
las cuestiones tcnicas.
10.4.5 DIRIGIR UNA REUNIN DE PROYECTO
Todos los participantes deben estar de acuerdo en seguir el mismo conjunto de reglas y
procedimientos. Adems, los participantes deben coincidir en revisar la documentacin;
Esta tarea no deberla ser realizada por la persona que preparo la documentacin. El
propsito bsico de la reunin es la detencin de errores, no la correccin de errores.
Los analistas nunca deberan rebatir los comentarios de los revisores. Una actitud
defensiva cohbe la crtica constructiva. El coordinador es responsable de conseguir que
estas reglas sean explicadas, comprendidas y obedecidas del modo conveniente. Los
revisores deberan ser instalados a ofrecer al menos un comentario positivo y uno
negativo con el fin de garantizar que la reunin no sea superficial.
10.5 INFORMES ESCRITOS
El informe de empresa y tcnico es el mtodo principal usado por los analistas para
comunicar la informacin sobre un proyecto de desarrollo de sistemas. El propsito del
informe es informar o convencer, o tal vez ambas cosas.
10.5.1 LONGITUD DE UN INFORME ESCRITO
El informe escrito es un mtodo del que con mucha frecuencia abusan los analista para
comunicarse con los usuarios del sistema. Tenemos una tendencia de generar informes
extensos y voluminosos con un aspecto impresionante. A veces, tales informes son
necesarios, pero otras muchas veces no lo son. Si se pone un informe tcnico de 300
paginas sobre la mesa de un directivo, puede esperarse que dicho directivo lo hojee,
pero no que lo lea, y mucho menos que lo estudie con detenimiento.
El tamao del informe es una cuestin interesante. Despus de muchas experiencias

fracasadas, hemos aprendido a aplicar las siguientes directrices generales para limitar
el tamao de los informes:
Para directivos de alto rango: una o dos paginas.

Para directivos de nivel medio: de tres a cinco pginas.
Para directivos supervisores: menos de diez paginas.
Para personal administrativo: menos de cincuenta paginas.
10.5.2 REDACCIN DEL INFORME DE EMPRESA O TCNICO
La forma de escribir puede tener una gran influencia en la carrera profesional de

cualquier ocupacin. A continuacin, ofrecemos algunas directrices al respecto:
Los prrafos deben transmitir una sola idea Deberan influir con facilidad de uno
a otro. Una mala escritura de los prrafos da lugar casi siempre a deficiencias
en la exposicin.
Las frases no deberan ser demasiado complejas. La longitud media de una frase
no debera superar las veinte palabras. Los estudios sugieren que sentencias mas
largas de veinte palabras son difcil de leer y entender.
Se escribir en voz activa. La voz pasiva se hace pesada y aburrida cuando se

usa de forma sistemtica.
10.5.3 ORGANIZACIN DEL INFORME ESCRITO
Existe un patrn general para organizar cualquier informe. Todos los informes constan
de elementos primarios y secundarios.
Los elementos primarios muestran informacin real que intenta transmitir un informe
Ejemplos de estos elementos son la introduccin y la conclusin.
Mientras que los elementos primarios presentan la informacin real, todos los informes
contienen tambin elementos secundarios.
Los elementos secundarios resumen el informe de forma que el lector pueda identificar
fcilmente tanto el informe como sus elementos primarios. Los elementos secundarios
aaden adems un acabado profesional a los informes.

Manual de Analisis y Diseno de Sistemas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Analisis y Diseno de Sistemas

Uploaded by

Copyright:

Available Formats

Anlisis y Diseo de Sistemas 1

Los primeros analistas de sistemas surgieron en la revolucin industrial. No trabajaban,

A pesar de sus enormes posibilidades tecnolgicas presentes y futuras, la computadora

1.2 NECESIDAD DE LOS SISTEMAS

La ubicacin de los sistemas y procedimientos de trabajo se halla en el elemento

1.3 CONCEPTOS GENERALES DEL ANLISIS

Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefinido en

Debe presentarse y entenderse el dominio de la informacin de un problema.

Defina las funciones que debe realizar el Software.

Represente el comportamiento del software a consecuencias de acontecimientos

Divida en forma jerrquica los modelos que representan la informacin,

El proceso debe partir desde la informacin esencial hasta el detalle de la

Software, que son Programas de computadora, con estructuras de datos y su

Hardware, dispositivos electrnicos y electromecnicos, que proporcionan

Personal, son los operadores o usuarios directos de las herramientas del

Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al

Documentacin, Manuales, formularios, y otra informacin descriptiva que

Procedimientos, o pasos que definen el uso especfico de cada uno de los

Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos:

Identifique las necesidades del Cliente.

Realice un Anlisis Tcnico y econmico.

Asigne funciones al Hardware, Software, personal, base de datos, y otros

Establezca las restricciones de presupuestos y planificacin temporal.

1.4 CLASIFICACIN DE SISTEMAS

Los sistemas se clasifican en:

Sistemas naturales y sistemas creados o hechos por el hombre. Las organizaciones

Considerando el nmero y complejidad de los elementos y sus relaciones, y la

Sistemas mecnicos o no vivientes y sistemas vivientes. Fcil de comprender porque los

Sistemas adaptables y no adaptables. Las organizaciones son sistemas adaptables,

FUNDAMENTOS DEL DESARROLLO DE

La resolucin de problemas es el acto de estudiar el entorno de un problema con el fin

1. Situaciones, reales o anticipadas, que requieren una accin correctiva.

2. Oportunidades de mejorar una situacin a pesar de la ausencia de quejas al

3. Instrucciones para cambiar una situacin con independencia de que se hayan

Planificacin es el estudio continuado del entorno de un problema con el fin de

En trminos ideales, los proyectos que se seleccionan proporcionaran beneficios a la

Anlisis es el estudio del entorno del problema y las subsiguiente definicin y

Diseo es la evaluacin de las diferentes alternativas a si como, las especificaciones

Implantacin es la construccin o ensamblaje de la solucin al problema que culmina

Soporte es el mantenimiento y la mejora permanentes de la solucin en el transcurso de

2.2 BLOQUES ELEMENTALES DE UN SISTEMA DE

El anlisis de sistema desarrolla el sistema de informacin para las organizaciones.

2.2.1 CONCEPTO DE INFORMACIN

Un sistema de informacin es una disposicin de componentes integrados entre si cuyo

El propsito de un sistema de informacin es recoger, procesar e intercambiar

2.2.2 BLOQUE ELEMENTAL PERSONAS

El primer, y mas importante, bloque de los sistemas de informacin es la persona. La

Propietario del sistema

Patrocinan y promueven los sistemas de informacin.

Son aquellas personas que utilizan el sistema de informacin (y obtienen beneficios

1. Los problemas que han de resolverse.

2.2.3 BLOQUE ELEMENTAL DE DATOS

Dato: es una coleccin de hechos considerados de forma

Como ven los datos los propietarios de sistemas

En trminos, estrictos, el propietario de sistema medio no esta interesado en los datos en

Los recursos de empresa son:

1. Cosas esenciales para los propsitos o los objetivos del sistema.

Cosas tangibles (por ejemplo, materiales, suministros, maquinas, vehculos y

Como ven los datos los usuarios

Los usuarios de un sistema de informacin son normalmente expertos en datos. Conocen

Como ven los datos los diseadores de sistemas

Los usuarios de los sistemas definen las necesidades de datos de un sistema de

disposiciones de registros, estructuras de datos, esquemas de bases de datos,

2.2.4 BLOQUE ELEMENTAL ACTIVIDADES