Académique Documents
Professionnel Documents
Culture Documents
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.
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.
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
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.
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
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.
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
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.
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.
14
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.
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.
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.
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
NOMBRE
Flujo de datos Proceso
REPRESENTA
Los 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
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.
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.
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.
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
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
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.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.
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.
30
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.
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.
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
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.
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
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.
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
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.
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.
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 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.
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.
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.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.
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 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.
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.
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.
53
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.
54
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
55
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.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.
56
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.
57 REUNIN DE
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.
58
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.