Manual de Analisis y Diseno de Sistemas

Anlisis y Diseo de Sistemas

1

CAPITULOCONCEPTOS DE ANLISIS DE SISTEMAS.1.1 ORIGENES DEL ANALISTA DE SISTEMASLos 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 SISTEMASEl 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 ANLISISEs 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.


2

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.


3

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 SISTEMASLos 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.


4

CAPITULOFUNDAMENTOS DEL DESARROLLO DE SISTEMAS.2.1 EL ANALISTA COMO SOLUCIONADOR DE PROBLEMASEn 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.


5

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 INFORMACIN

DE

UN

SISTEMA

DE

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.


6

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. 2. 3. 4. Los problemas que han de resolverse. Las oportunidades que han de aprovecharse. Las necesidades que han de satisfacerse 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


7

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,


8

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.


9

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 SISTEMASEl 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


10

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. 2. 3. 4. 5. 6. 7. Identificar el problema (u oportunidad o norma). Comprender el contexto del problema y las causas y efectos del mismo. Definir los requisitos para alcanzar una solucin adecuada. Hallar soluciones alternativas. Elegir la mejor solucin. Disear e implantar la solucin. 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. 2. 3. 4. Anlisis de sistema Diseo de sistema Implantacin de sistema 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.


11

CAPITULOPLANIFICACIN DEL SISTEMALa 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

Anlisis y Diseo de Sistemas 3.1.1 FASE 1: ESTUDIO DE LA PLANIFICACIN

12

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.

Anlisis y Diseo de Sistemas Bloques Elementales Los objetivos fundamentales de un AAE son:

13

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 EMPRESAEs 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.


14

CAPITULOANLISIS DE SISTEMASEl 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 ELEMENTALES1. 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 DATOSUn 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.


15

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.

Anlisis y Diseo de Sistemas Modelizacin de datos durante la planificacin de sistemas

16

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 PROCESOSLa 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.

Anlisis y Diseo de Sistemas Convenciones y directrices de los diagramas de flujo de datos El smbolo principal de un diagrama de flujo es el proceso.

17

NOMBREFlujo de datos Proceso

REPRESENTALos datos en movimiento del sistema Transformaciones de los datos del sistema.

SIMBOLO

Almacn de datos

Datos en reposo del sistema Origen y destino de los flujos de datos que entran y salen del sistema

Agente externo o interno

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.

Anlisis y Diseo de Sistemas 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.)

18

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.


19

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.


20

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.

Anlisis y Diseo de Sistemas Paso 3: Identificar almacenes de datos

21

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.


22

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.


23

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.


24

Algunos ejemplos de ellos podran ser: Esenciales Ciudad Campos Universitario Edificio Despacho Grupos de Despacho Sucursal Cliente Proveedor Colaborador

Puesto de Implantacin Lugar del Ordenador o el Servidor Lugar del Terminar Lugar de Racismo de Terminales Racismo de Red de rea 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


25

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).


26

CAPITULODISEO DE SISTEMA5.1 CONCEPTO DE DISEO DE SISTEMAEl 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


27

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 DATOS5.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.


28

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 PROCESO5.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


29

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 PROCESOS5.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.


30

5.5 DISEO DE ARCHIVOS Y BASES DE DATOS5.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


31

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 SALIDAS5.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


32

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.

Anlisis y Diseo de Sistemas 5.6.4 CONTROLES INTERNOS DE LAS ENTRADAS Y LAS SALIDAS

33

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 USUARIO5.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 PROGRAMAS5.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.

Anlisis y Diseo de Sistemas 5.8.2 COMO HACER EL DISEO MODULAR DE PROGRAMAS

34

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.


35

CAPITULOIMPLEMENTACION DE SISTEMAS6.1 CONCEPTOEs 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 IMPLEMENTACINEn 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)


36

6.3 FASE DE INSTALACIN Y PRUEBAS EN LA IMPLANTACIN DE SISTEMASEs 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 EXPLOTACIN DE LA IMPLANTACIN.

SISTEMA

PARA

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.


37

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.


38

CAPITULOSOPORTE DEL SISTEMA7.1 MANTENIMIENTO DE SISTEMASCon 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.


39

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 FINALOtra 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


40

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


41

GESTIN DE PROYECTOSEn 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.


42

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 PROYECTOExisten 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.


43

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.


44

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 B C D E F G H I J Estudio de factibilidad. Diseo general del sistema. Seleccin del personal. Capacitacin del personal. Estudio de aplicaciones. Estudio de financiacin. Estudio de equipos. Seleccin de equipos. Evaluacin final. Programacin.

Anlisis y Diseo de Sistemas K L M N O P Q R S T Envo de equipo. Recepcin de equipo. Preparacin del lugar. Instalacin del sistema de comunicaciones. Instalacin del equipo. Puesta a punto de programas. Capacitacin de usuarios. Prueba del sistema. Puesta a punto del sistema. Operacin paralela.

45

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


46

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.


47

8.3 TCNICAS DE INVESTIGACIN DE HECHOS8.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. 2. 3. 4. 5. 6. Muestreo de la documentacin, los formularios y los archivos existentes. Investigacin y visitas a instalaciones. Observacin del entorno de trabajo. Cuestionarios. Entrevistas. 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.

Anlisis y Diseo de Sistemas Como determinar el tamao de muestra

48

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.


49

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.


50

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


51

ANALISIS DE VARIABLES9.1 ANLISIS DE VARIABLETrata 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.


52

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 BENEFICIOSLa 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

Manual de Analisis y Diseno de Sistemas

Documents

Transcript of Manual de Analisis y Diseno de Sistemas