Apuntes Ay DS

Apuntes de Anlisis y Diseo de Sistemas
Academia de Computacin -
ANLISIS Y DISEO DE SISTEMAS TEORIA GENERAL DE SISTEMAS

Un Sistema es un conjunto de elementos que interactan entre s para lograr un fin. La finalidad de un sistema es la razn de su existencia. Para alcanzar sus objetivos, los sistemas interactan con su ambiente. El ambiente de un sistema est formado por todos los objetos que se encuentran fuera de las fronteras del sistema. Los sistemas que interactan con su ambiente se denominan sistemas abiertos. Todos los sistemas actuales son abiertos. Los sistemas que no interactan con su ambiente se denominan sistemas cerrados, pero stos solo existen en teora. Existen sistemas naturales: Sistema Solar Sistema Digestivo Sistema Ecolgico
Existen sistemas creados por el hombre: Sistema Social Sistema Econmico Sistema Poltico Sistema de Informacin
La teora general de sistemas demuestra que tanto los sistemas naturales como los creados por el hombre se comportan de la misma manera y cumplen con los mismos principios, de lo contrario, no seran sistemas. Entre los Principios de la Teora General de Sistemas ms representativos tenemos: Todos los sistemas crecen Cuanto ms especializado sea un sistema, menor ser su capacidad de adaptarse a los cambios en su ambiente. Entre ms grande sea un sistema, mayor cantidad de recursos consumir. Todos los sistemas forman parte de sistemas mayores y, a su vez, son formados por sistemas o subsistemas.
Entre los Conceptos bsicos en la teora de Sistemas tenemos: Un Dato es la unidad mnima de informacin que por s solo no tiene significado. La Informacin es un conjunto de datos que al relacionarse adquieren significado. Un Sistema de Informacin es un conjunto de elementos que interactan entre s con el objetivo de apoyar las actividades de una empresa o negocio.
ANLISIS DE SISTEMAS
Las organizaciones han reconocido, desde hace mucho, la importancia de administrar recursos principales tales como la mano de obra y las materias primas. La informacin se ha colocado en un lugar adecuado como recurso
principal. Los tomadores de decisiones estn comenzando a comprender que la informacin no es solo un subproducto de la conduccin, sino que a la vez alimenta a los negocios y puede ser el factor crtico para la determinacin del xito o fracaso de estos. El Anlisis de Sistemas es el proceso por el cual se puede administrar los sistemas de informacin computarizados de una manera eficiente, encaminado al bienestar y progreso de la empresa o negocio. Tambin se puede definir como 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 tales como: Debe presentarse y entenderse el dominio de la informacin de un problema. Definir las funciones que debe realizar el Software. Representar el comportamiento del Software a consecuencias de acontecimientos externos. Dividir en forma jerrquica los modelos que representan la informacin, funciones y comportamiento.
As como teniendo en cuenta los siguientes objetivos: Identificar las necesidades del cliente. Evaluar la vialidad del sistema. Realizar un anlisis tcnico y econmico. Asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema. Establecer restricciones de coste y tiempo. Crear una definicin del sistema que sea la base para todo el trabajo posterior de ingeniera.
Este proceso debe partir desde la informacin esencial hasta el detalle de la Implementacin. La funcin del Anlisis de Sistemas 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 de Informacin 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.
Actividades de un Sistema de Informacin Un sistema de informacin realiza cuatro operaciones bsicas: Entrada de Informacin. Es el proceso mediante el cual se alimenta de los datos necesarios al sistema de informacin. Las entradas pueden ser manuales o automticas. Una entrada manual es aquella que proporciona directamente el usuario por medio del teclado o cualquier otro dispositivo de entrada. Una entrada automtica es proporcionada por otro sistema o mdulo. Almacenamiento de Informacin. Mediante esta operacin el sistema guarda la informacin generada. La informacin se guarda y clasifica en archivos. Estos archivos son almacenados en algn dispositivo de almacenamiento, por ejemplo los discos magnticos, unidades de cinta o discos compactos. Procesamiento de la Informacin. Es la capacidad del sistema para efectuar los clculos necesarios con los datos de entrada . Los clculos son efectuados con base en una secuencia de operaciones preestablecidas
(programas). El procesamiento puede llevarse a cabo con datos introducidos recientemente en el sistema o con datos que ya se encontraban almacenados en archivos. El procesamiento de los datos permite producir informacin para lograr el objetivo del sistema. Salida de la Informacin. Consiste en el envo de la informacin al exterior del sistema. Esta informacin es el resultado del procesamiento o transformacin de los datos. La salida de la informacin se realiza mediante un dispositivo de salida. La salida de informacin de un sistema puede ser la entrada de informacin a otro sistema.
Sistema
Entrada Proceso Salida
Almacenamiento
Figura 1. Actividades de un Sistema de Informacin
LA EMPRESA
Una Empresa es un organismo creado para producir bienes y/o servicios, algunas tienen como finalidad producir utilidades y dividendos para los accionistas o propietarios de la misma, otras no tienen fines lucrativos. Niveles Organizacionales La mayora de las empresas se representan con tres niveles: El Nivel Operativo est compuesto por las personas que realizan las tareas propias de la actividad de la empresa. Por ejemplo en un banco, el nivel operativo se compone por cajeros, en una escuela, por maestros y en una fbrica por obreros. A los jefes del nivel operativo se les llama supervisores o coordinadores. El Nivel Medio es el enlace entre la operacin y la alta gerencia. Los jefes son los gerentes. La Alta Gerencia controla el rumbo de la organizacin, es por eso que con frecuencia se le llama nivel estratgico. En este nivel los jefes son los Directores.
Tipos de Decisiones En las organizaciones es necesario tomar decisiones sobre varios asuntos y para esto se requiere informacin. Por ejemplo, se toman decisiones en cuanto a lo siguiente: A qu proveedor comprar la materia prima.
Apuntes de Anlisis y Diseo de Sistemas Qu cantidad de crdito se le otorgar a un cliente. Qu tipo de productos vender la compaa.
Pero estas decisiones no son iguales, unas son ms frecuentes, de menor impacto para la organizacin y tienen procedimientos bien establecidos. Por eso se clasifican de la siguiente forma: Estructurada, este tipo de decisin tiene un impacto organizacional Bajo, es muy frecuente y se sigue un procedimiento preestablecido para tomar dicha decisin. Semiestructurada, este tipo de decisin tiene un impacto organizacional Medio, son ocasionales y se sigue un proceso pero tambin se usa la experiencia y la intuicin para tomar dicha decisin. No Estructurada, este tipo de decisin tiene un impacto organizacional Alto, son muy poco frecuentes y se basa en la intuicin y la experiencia para tomar dicha decisin.
Un administrador debe seguir un procedimiento para tomar decisiones de cualquier tipo. El procedimiento consiste bsicamente en los siguientes pasos: Plantear el Problema
Definir Alternativas
Comparar Alternativas
Seleccionar la mejor Alternativa Figura 2. Procedimiento para la toma de decisiones
Hay sistemas de informacin que apoyan este proceso en sus diferentes etapas, pues no es posible tomar decisiones sin tener suficiente informacin.
CATEGORAS DE SISTEMAS DE INFORMACIN

El Anlisis de Sistemas, tal como es ejecutado por los analistas de sistemas, busca analizar sistemticamente la entrada de datos o el flujo de datos, el proceso o transformacin de los datos, el almacenamientos de datos y la salida de informacin dentro del contexto de un negocio particular. Adems el diseo y anlisis de sistemas es usado para analizar, disear e implementar mejoras en el funcionamiento de los negocios que pueden ser logradas por medio del uso de sistemas de informacin computarizados. Los sistemas de informacin son desarrollados con propsitos diferentes dependiendo de las necesidades del negocio o empresa, entre las diferentes categoras de sistemas de informacin tenemos: Sistemas de Procesamiento de Transacciones
Los sistemas de procesamiento de transacciones (TPS, Transactions Processing Systems; por sus siglas en ingles) son sistemas de informacin computarizados desarrollados para procesar gran cantidad de datos para transacciones rutinarias de los negocios, tales como nmina e inventario. Los TPS eliminan el tedio de las transacciones operacionales necesarias y reducen el tiempo que alguna vez se requiri para ejecutarlas manualmente, aunque la gente todava debe alimentar datos a los sistemas computarizados. Una transaccin es el registro de un evento que afecta a la empresa. Por ejemplo, el pedido de un cliente es una transaccin que a su vez desencadena una serie de eventos que terminan con la entrega de un producto al cliente. Las transacciones ms comunes incluyen: Facturacin. Compra de mercanca. Pago a empleados. Depsito de cheques.
Los tipos de transacciones varan de acuerdo con el giro de la organizacin. Por ejemplo: pago de cheques y recepcin de depsitos son las transacciones en un banco, las inscripciones son transacciones en una escuela, etc. El procesamiento de transacciones es un conjunto de procedimientos que incluye las actividades de: Clculo. Clasificacin. Ordenamiento. Almacenamiento y recuperacin de informacin. Los procedimientos describen qu buscar en cada transaccin, los pasos a seguir y lo que debe hacerse en caso de que se presente una excepcin. Como estos procedimientos forman parte de la operacin de cualquier empresa, los sistemas transaccionales son desarrollados para el nivel operativo de la organizacin. La finalidad de este tipo de sistemas es mejorar las actividades rutinarias de las que depende la organizacin. Las empresas con mayor xito llevan a cabo este trabajo en una forma ordenada y eficiente. Las caractersticas de los sistemas para el procesamiento de transacciones son las siguientes: Manipulan gran cantidad de datos de entrada (transacciones) y salida de informacin. Son recolectores de informacin ya que a travs de ellos se alimentan las bases de datos de la empresa. Las Transacciones son similares. Los procedimientos para el procesamiento de transacciones estn bien comprendidos y se pueden describir con detalle. Existen muy pocas excepciones a los procedimientos normales. Permiten ahorros significativos de mano de obra, debido a que se automatizan los procesos operativos de la organizacin. La justificacin de estos sistemas se puede realizar enfrentando ingresos y costos.
Muchos sistemas transaccionales se pueden encontrar como paquetes de software en el mercado. Algunos ejemplos de sistemas transaccionales son: Sistemas de nminas. Sistemas de facturacin y ventas. Cajeros automticos.
Sistemas Transaccionales
Clientes
Proveedores
Empleados
Base de Datos Figura 3. Sistema de Procesamiento de Transacciones
Sistemas de Automatizacin de Oficina y Sistemas de Manejo de Conocimiento Al nivel de conocimiento de la organizacin hay dos clases de sistemas. Los Sistemas Automatizacin de Oficina (OAS Office Automation Systems, por sus siglas en ingls) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organizacin y algunas veces ms all de ella. Los aspectos familiares de los OAS incluyen procesamiento de palabras, hojas de clculo, editor de publicaciones, calendarizacin electrnica y comunicacin mediante correo de voz, correo electrnico y videoconferencias. Los Sistemas de Manejo de Conocimiento (KWS Knowledge Works Systems, por sus siglas en ingls) dan soporte a los trabajadores profesionales, tales como cientficos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organizacin o a toda la sociedad. Sistemas de Informacin Gerencial Estos sistemas (MIS Managerial Information Systems, por sus siglas en ingls) tambin llamados Sistemas de Informacin Administrativa, no reemplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de informacin computarizada que trabajan debido a la interaccin resuelta entre personas y computadoras. Requieren que las personas, el software y el hardware trabajen al unsono. Estos sistemas de informacin dan soporte a un espectro ms amplio de tareas
organizacionales que los sistemas de procesamiento de transacciones, incluyendo el anlisis de decisiones y la toma de decisiones. Este tipo de sistemas ayuda a los administradores a tomar decisiones estructuradas y resolver problemas del nivel medio de la empresa. Los sistemas gerenciales recurren a los datos almacenados por los sistemas transaccionales como consecuencia de las transacciones cotidianas de la empresa para presentar la informacin a los administradores. Estos sistemas organizan, filtran y totalizan los datos para entregar informacin en forma peridica, generalmente en un reporte cuyo formato se encuentra ya definido para apoyar las decisiones estructuradas. Ejemplo: El gerente de ventas recibe peridicamente los siguientes reportes: Reporte de ventas por sucursal. Reporte de ventas por producto. Reporte de ventas por vendedor. Con estos reportes el gerente podr vigilar el nivel de ventas bajo diferentes parmetros: Sucursal. Producto. Vendedor.
Con la informacin obtenida podr calcular sus ciclos de venta, la productividad de sus vendedores y la efectividad de sus productos para decidir cundo ofertar un producto o motivar a sus vendedores con incentivos econmicos. Las caractersticas principales de los sistemas de informacin gerencial son las siguientes: Suelen introducirse despus de la implantacin de los sistemas transaccionales. Filtran, organizan y totalizan los datos almacenados por los sistemas transaccionales. La informacin que generan sirve de apoyo a la toma de decisiones estructuradas de los niveles intermedios de la organizacin. Ofrecen una gran variedad de reportes. Difcilmente se encuentran separados de los sistemas transaccionales. Se requiere un sistema gerencial especfico en cada rea de la organizacin (Ventas, Finanzas, Recursos Humanos, Produccin, etc.) para cubrir las necesidades especficas de informacin.
Sistema de Apoyo a Decisiones Estos sistemas (DSS, Decisions Support Systems) son una clase de alto nivel en los sistemas de informacin computarizada. El DSS es similar al sistema de informacin gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del dominio del tomador de decisiones. Los sistemas de apoyo a decisiones estn ms hechos a la medida de la persona o grupo que los usa que los sistemas de informacin gerencial tradicionales. Como los sistemas gerenciales apoyan a los administradores de nivel medio y estratgico en el proceso de toma de decisiones semiestructuradas y no estructuradas en todas sus fases. Las caractersticas principales de este tipo de sistemas son las siguientes: La informacin que generan sirve de apoyo a la toma de decisiones de los niveles intermedios y altos de la organizacin. Suelen ser intensivos en clculos y escasos entradas y salidas de informacin. Suelen ser sistemas de informacin interactivos y amigables, con altos estndares de diseo grfico y visual. Se encuentran dirigidos al usuario final. Pueden ser desarrollados directamente por el usuario.
Sistemas Expertos e Inteligencia Artificial
La inteligencia artificial (AI, Artificial Intelligence) puede ser considerada la meta de los sistemas expertos. El empuje general de la AI ha sido desarrollar mquinas que se comporten de forma inteligente. Dos caminos de la investigacin de la AI son la comprensin del lenguaje natural y el anlisis de la habilidad para razonar un problema y llegar a conclusiones lgicas. Los sistemas expertos usan los enfoques del razonamiento de la AI para resolver los problemas que les plantean los usuarios de negocios (y otros). Los componentes bsicos de un sistema experto son la base de conocimiento, una mquina de inferencia que conecta al usuario con el sistema, procesando consultas por medio de lenguajes tales como SQL (lenguaje de consultas estructurado) y la interfaz de usuario. Inteligencia Artificial. Se puede definir como la ciencia que estudia de manera sistemtica el comportamiento inteligente, con el fin de imitar o simular las habilidades humanas mediante la creacin y utilizacin de mquinas y computadoras. Estas habilidades humanas incluyen: Razonamiento. Aprendizaje. Capacidades mecnicas. Capacidades sonoras.
En trminos generales se considera que la inteligencia artificial cubre las siguientes reas: Simulacin sensorial. Robtica. Lenguajes naturales. Sistemas expertos.
Los sistemas expertos permiten cargar bases de conocimiento integradas por una serie de reglas de sentido comn. El conocimiento se basa u obtiene a travs de la experiencia de un especialista o experto. Los elementos bsicos de un sistema experto son: Una base de conocimiento. Una mquina de inferencia. Un lenguaje para inteligencia artificial. Una interfaz de usuario.
Con base en lo anterior se puede definir a un sistema experto como un sistema computacional interactivo que permite la creacin de bases de conocimiento, las cuales una vez cargadas responden a preguntas, despejan dudas y toman cursos de accin emulando/simulando el proceso de razonamiento humano. De esta definicin se desprenden las dos habilidades fundamentales que poseen los sistemas expertos: Habilidad para el aprendizaje: requiere la interaccin de un experto en alguna rama especfica del saber y un ingeniero de conocimiento, que se encarga de traducir el conocimiento del experto en reglas heursticas para formar la base del conocimiento. Habilidad para simular el proceso del razonamiento humano: esta habilidad se desprende de utilizar las reglas heursticas introducidas o creadas por el sistema experto, a travs del proceso de aprendizaje durante la carga o generacin de las bases del conocimiento.
A diferencia de los sistemas de apoyo para la toma de decisiones, que dejan al usuario la responsabilidad de tomar la decisin final, los sistemas expertos seleccionan la mejor solucin al problema o al tipo especfico de problemas planteados. Algunos beneficios obtenidos con el uso de los sistemas expertos son los siguientes: Reduccin en la dependencia de las personas que toman las decisiones. Facilita el entrenamiento de personal. Mejora en la calidad y eficiencia en el proceso de la toma de decisiones. Transferencia de la capacidad de decisiones.
Sistemas de Apoyo a Decisiones de Grupo Cuando los grupos necesitan trabajar juntos para tomar decisiones semiestructuradas o sin estructura, un sistema de apoyo a decisiones de grupo puede plantear una solucin. Los sistemas de apoyo a decisiones de grupo (GDSS, Groups Decisions Support Systems ) son usados en cuartos especiales, equipados en varias configuraciones diferentes, que permiten que los miembros del grupo interacten con apoyo electrnico, frecuentemente en forma de software especializado y con una persona que da facilidades al grupo. Los sistemas para decisiones de grupo estn orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios apoyos como votaciones, cuestionarios, aportacin de ideas y creacin de escenarios. Sistemas de Apoyo a Ejecutivos Cuando los ejecutivos se acercan a la computadora, frecuentemente estn buscando formas que les ayuden a tomar decisiones a nivel estratgico. Un sistema de apoyo a ejecutivos (ESS) ayuda a estos, para organizar sus interacciones con el ambiente externo, proporcionando a poyo de grficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas. Aunque los ESS se apoyan en la informacin generada por los TPS y los MIS, los sistemas de apoyo a ejecutivos ayudan a sus usuarios a que ataquen problemas de decisin sin estructura, que no son especficos de una aplicacin, creando un ambiente que ayude a pensar acerca de los problemas estratgicos de una manera informada.
EL PAPEL DEL ANALISTA DE SISTEMAS

La denominacin de Analista de Sistemas vara de acuerdo con: La funcin dentro del proceso de desarrollo de sistemas. El papel que desempee dentro de la organizacin.
De acuerdo con su Funcin en el proceso de desarrollo de sistemas, al analista se le puede denominar de la siguiente manera: Analista de sistemas: en este caso la nica responsabilidad del analista es conducir estudios de sistemas para detectar hechos relevantes relacionados con la actividad de la empresa. Diseador de sistemas: es cuando el analista tambin tiene la responsabilidad de disear el nuevo sistema. Programador de sistemas: se le conoce as cuando el analista mismo desarrolla el software necesario para implantar el diseo. Esta funcin depender, generalmente, del tamao de la organizacin para la cual trabaje. Si el analista trabaja en una empresa pequea casi siempre desarrollar las tres actividades, es decir, ser analista, diseador y programador del sistema. Los analistas de sistemas generalmente valoran la manera en que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de informacin con el propsito de mejorar los procesos organizacionales. La definicin de un analista de sistemas es necesariamente amplia; el analista debe ser capaz de trabajar con personas de todas las descripciones y debe tener experiencia en el trabajo con computadoras. El analista desempea muchos papeles, balanceando a veces varios al mismo tiempo. Los tres papeles principales del analista de sistemas son: Consultor, el analista de sistemas frecuentemente acta como consultor y, por lo tanto, puede ser contratado especficamente para que se encargue de los asuntos de los sistemas de informacin dentro de un negocio. Esto puede ser una ventaja, debido a que los consultores externos pueden llevar con ellos una perspectiva fresca que no poseen otros miembros de la organizacin. Pero tambin puede decirse que los analistas externos estn en desventaja, debido a que la verdadera cultura organizacional nunca puede ser conocida por un extrao.
Experto en Soporte, Otro papel que tal vez requiera desarrollar es el de experto de soporte en un negocio donde se est empleado regularmente en alguna actividad de sistemas. En este papel el analista se apoya en su experiencia profesional relacionada con el hardware y software de computadora y su uso en el negocio. Este trabajo frecuentemente no es un proyecto de sistema completo, sino solamente pequeas modificaciones o decisiones que afectan a un solo departamento. Como experto de soporte no est administrando el proyecto, sino simplemente est sirviendo como un recurso para aquellos que lo manejan. Agente de Cambio, El papel ms comprensivo y responsable que toma un analista de sistemas es el de agente de cambio, ya sea interno o externo al negocio. Como analista se es un agente de cambio cada vez que se ejecuta cualquiera de las actividades del ciclo de vida del desarrollo de sistemas y se est presente en el negocio por un periodo extendido (desde dos semanas hasta ms de un ao). Un agente de cambio puede ser definido como una persona que sirve de catalizador para el cambio, desarrolla un plan para el cambio y trabaja junto con otros para facilitar ese cambio.
Cualidades del Analista de Sistemas A partir de la descripcin de los papeles que desempea el analista de sistemas, es fcil ver que el analista de sistemas exitoso debe poseer un alto rango de cualidades. Muchos tipos de personas diferentes son analistas de sistemas, por lo que cualquier descripcin quedar corta en alguna forma. Sin embargo hay algunas cualidades que parecen mostrar la mayora de los analistas de sistemas. Antes que nada el analista es un solucionador de problemas. Es una persona que ve el anlisis de los problemas como un reto y que disfruta el encontrar soluciones funcionales. Cuando es necesario, el analista debe ser capaz de atacar sistemticamente la situacin a la mano por medio de la aplicacin hbil de herramientas, tcnicas y experiencia. El analista tambin debe ser un comunicador capaz de relacionarse en forma significativa con las dems personas a travs de periodos extensos. Los analistas de sistemas necesitan la suficiente experiencia en computacin para programar, para comprender las capacidades de las computadoras, para recoger los requerimientos de informacin de los usuarios y para comunicar lo que se necesita a los programadores. El analista de sistemas debe ser un individuo autodisciplinado y automotivado, capaz de manejar y coordinar innumerables recursos del proyecto incluyendo a otras personas. El anlisis de sistemas es una carrera que demanda mucho, pero en compensacin es siempre cambiante y retadora.
USUARIOS
En la mayora de puntos y temas mencionados anteriormente participan personas, an con toda la tecnologa, las personas son las piezas ms importantes para que una organizacin trabaje; comunicarse y tratar con las personas es uno de los aspectos ms importantes del trabajo del analista de sistemas. Por ejemplo los gerentes y los empleados tienen buenas ideas con especto a qu es lo que si funciona y qu es lo que no, qu causa problemas y qu no, donde son necesarios los cambios y donde no, y especialmente en qu partes ser aceptado y en cules no. Actualmente los usuarios participan ms en el desarrollo de sistemas por varias razones: Los usuarios han acumulado experiencia al trabajar con aplicaciones que fueron desarrolladas para ellos anteriormente. Tienen una mejor idea de lo que significa la ayuda que pueden brindarles los sistemas de informacin y la forma de cmo obtenerla. Saben cules son las fallas de los sistemas actuales y como evitarlas. Muchos de los usuarios ya han recibido capacitacin en el uso de las computadoras y algn tipo de software. Cuando el analista desarrolla aplicaciones, necesita la participacin continua de los usuarios para comprender las funciones de la empresa que se encuentran bajo estudio. En algunos casos los usuarios desarrollan sus propias aplicaciones sin la necesidad de contar con un analista de sistemas.
10
Los analistas emplean el trmino usuarios final para referirse a las personas que no son especialistas en sistemas de informacin pero utilizan las computadoras para desempaar su trabajo. El grado de participacin de los usuarios quiz cambie y esto depende del tipo de usuario y los usuarios finales pueden agruparse en cuatro categoras: Usuario Final Directo: Tambin llamado usuario primario, es el que opera el sistema, interactua con el sistema a travs del equipo de cmputo. Alimenta al sistema y reciben las salidas de informacin. Usuario Final Indirecto: Tambin llamado usuario secundario, es el que emplea los reportes y otros tipos de informacin generada por el sistema pero no opera el equipo Administradores: Supervisan la inversin en el desarrollo o uso del sistema. Tienen la responsabilidad ante la organizacin de controlar las actividades del sistema. Directivos: Incorporan los usos estratgicos y competitivos de los sistemas de informacin en los planes y estrategias de la organizacin. Evalan los riesgos - a los que se expone la organizacin - originados por fallas en los sistemas de informacin.
ESTRATEGIAS PARA EL ANLISIS Y DISEO (DESARROLLO) DE SISTEMAS

El desarrollo de sistemas es una tarea que se puede manejar como proyecto, es decir debe tener un inicio y un fin, una secuencia de pasos o etapas y debe ajustarse a un presupuesto. Cada proyecto de desarrollo de sistemas es particular, pues nunca se presentan las mismas situaciones en dos proyectos, aunque estos sean similares. Para el desarrollador de proyectos de sistemas es de vital importancia conocer las diversas metodologas que lo apoyarn a cumplir con las especificaciones del proyecto. Las metodologas para el anlisis y diseo de sistemas es: Mtodo del Anlisis Estructurado En este mtodo, el anlisis consiste en investigar la funcionalidad de un sistema. Durante este proceso se deben responder las siguientes preguntas: Qu hace el sistema? Quines realizan las actividades? Con qu departamentos o sistemas est relacionado? Quin provee los datos o informacin fuente? Quin utiliza la informacin resultante? Para qu?
Realizar esta investigacin intuitivamente podra resultar en inconsistencias, redundancias y contradicciones que entorpezcan el proceso de desarrollo. El mtodo de desarrollo de anlisis estructurado establece un orden para evitar tales inconvenientes, de este modo se podr presentar es estudio del sistema con todos sus detalles funcionales; este mtodo es especialmente til para facilitar la comprensin de sistemas grandes y complejos . Para lograrlo: Se divide al sistema en componentes. Se construye un modelo del sistema.
Este mtodo permite que los usuarios observen los elementos lgicos separados de los elementos fsicos. Los elementos lgicos se refieren a las funciones del sistema, los datos y toda la informacin y su movimiento dentro del sistema y los elementos fsicos son las computadoras, terminales, sistemas de almacenamiento, etctera. Como el anlisis estructurado es una tcnica de modelado del flujo de los datos y del contenido de la informacin na de las herramientas principales para desarrollar este mtodo es la Diagramacin de Sistemas mediante los diagramas de flujo de Datos (DFD). Como este mtodo solo enfatiza la funcionalidad del sistema, se recomienda usarse en combinacin con otras metodologas.
11
Apuntes de Anlisis y Diseo de Sistemas Mtodo del Ciclo de Vida para el Desarrollo de Sistemas
El mtodo del ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que realizan los analistas, diseadores y usuarios para desarrollar e implantar sistemas de informacin. Este mtodo concibe el desarrollo de sistemas como un ciclo especfico de actividades. Los analistas no estn de acuerdo respecto al nmero exacto de etapas que conforman este mtodo, sin embargo, reconocen la importancia de su enfoque sistmico. Aunque cada etapa se encuentra definida, nunca se lleva a cabo como un elemento independiente. Es recomendable el ciclo de vida para proyectos de gran escala cuando involucra a varios departamentos, cuando se tienen los procedimientos bien establecidos o cuando se tiene que trabajar con un equipo de personas. De manera general, se puede decir que este mtodo cuenta con las siguientes etapas: Identificacin de Problemas, Oportunidades y Objetivos, es la primera etapa del mtodo del ciclo de vida del desarrollo de sistemas y es la ms crtica para el xito del resto del proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. En esta etapa se requiere que el analista observe honestamente lo que est sucediendo en un negocio, luego, junto con los dems miembros de la organizacin, el analista hace resaltar los problemas. Las oportunidades son situaciones que el analista considera que pueden ser mejoradas por medio del uso de sistemas de informacin computarizados. El aprovechar las oportunidades puede permitir que el negocio gane un avance competitivo o ponga un estndar de la industria. La identificacin de objetivos es tambin un componente importante de la primera etapa. En primer lugar, el analista debe descubrir lo que est tratando de hacer el negocio. Luego ser capaz de ver si algn aspecto de la aplicacin de sistemas de informacin puede ayudar para que el negocio alcance sus objetivos atacando problemas especficos u oportunidades. Determinacin de los Requerimientos de Informacin, Entre las herramientas utilizadas para definir los requerimientos de informacin en el negocio se encuentran el muestreo e investigacin de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboracin de prototipos. En esta etapa el analista est esforzndose por comprender que informacin necesitan los usuarios para realizar su trabajo. Se puede ver que varios de los mtodos para determinar los requerimientos de informacin involucran la interaccin directa con los usuarios. Esta etapa sirve para formar la imagen que el analista tiene de la organizacin y de sus objetivos. Alguna veces solamente se completan las dos primeras etapas del ciclo de vida del desarrollo de sistemas. Este tipo de estudio puede tener diferentes propsitos, y es realizado tpicamente por un especialista llamado analista de informacin (AI). Anlisis de las Necesidades del Sistema, en esta etapa el analista de sistemas involucra el anlisis de las necesidades del sistema. Nuevamente, herramientas y tcnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma grfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, as como sus especificaciones, si son alfanumricos y qu tanto espacio ocupan cuando se imprimen. Durante esta etapa el analista de sistemas tambin analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condicin, acciones y reglas de accin. Hay tres mtodos principales para el anlisis de decisiones estructurales: lenguaje estructurado, tablas de decisin y rboles de decisin. Diseo del Sistema recomendado, en esta etapa del ciclo de vida del desarrollo de sistemas, el analista usa la informacin recolectada anteriormente para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos. Adems, el analista tambin proporciona entrada efectiva para el sistema de informacin mediante el uso de tcnicas para el buen diseo de formas y pantallas. Parte del diseo lgico del sistema de informacin es disear la interfaz de usuario. La interfaz conecta al usuario con el sistema y es, por lo tanto, extremadamente importante. Ejemplos de interfaces de usuario incluyen un teclado para producir preguntas y respuestas, mens en pantalla para elegir comandos del usuario y un ratn para seleccionar opciones. Las fase de diseo tambin incluye el diseo de archivos o bases de datos que
12
guardarn la mayor parte de los datos necesarios para los tomadores de decisiones de la organizacin. Una base de datos bien organizada es la base para todos los sistemas de informacin. En esta etapa, el analista tambin trabaja con los usuarios para disear la salida (ya sea en pantalla o impresora) que satisfaga sus necesidades de informacin. Desarrollo y Documentacin del Software, en esta quinta etapa el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Algunas de las tcnicas estructuradas para el diseo y documentacin de software incluyen diagramas estructurados, el mtodo HIPO, diagramas de flujo, diagramas Nassi-Schneiderman y Warnier-Orr y pseudocdigo. El analista de sistemas usa uno o ms de estos dispositivos para comunicar al programador lo que necesita ser programado. Durante esta etapa, el analista tambin trabaja con los usuarios para desarrollar documentacin efectiva para el software, incluyendo manuales de procedimiento. La documentacin le dice al usuario la manera de usar el software y tambin que hacer si suceden problemas con el software. Por lo que los programadores en esta etapa tiene un papel principal conformen disean, codifican y eliminan errores de sintaxis de los programas de computadoras. Pruebas y Mantenimiento del Sistema, Antes de que pueda se usado, el sistema de informacin debe ser probado. Es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas de la pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual. El mantenimiento del sistema y de su documentacin comienzan con esta etapa y es efectuado rutinariamente a lo largo de la vida del sistema de informacin. Mucho del trabajo rutinario del programador consiste en el mantenimiento, ya que los negocios gastan gran cantidad de dinero en dicho mantenimiento. Muchos de los procedimientos sistemticos que emplea el analista a lo largo del ciclo de vida del desarrollo de sistemas pueden ayudar a asegurar que el mantenimiento se mantenga al mnimo. Implementacin y Evaluacin del Sistema, en esta etapa del desarrollo de sistemas el analista ayuda a implementar el sistema de informacin. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algn entrenamiento es hecho por los proveedores, pero la supervisin del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversin suave del sistema antiguo al nuevo. Este proceso incluye la conversin de archivos de formatos antiguos a nuevos o la construccin de una base de datos, la instalacin de equipo y la puesta del nuevo sistema en produccin. La evaluacin se muestra como parte de esta fase final del ciclo de vida del desarrollo de sistemas, principalmente para efectos de discusin. De hecho, la evaluacin se realiza durante cada etapa. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya estn usando el sistema.
Mtodo del Prototipo de Sistemas Un prototipo es un modelo, una representacin a escala de cualquier cosa. El desarrollo por prototipos es un proceso que facilita al programador la creacin de un modelo del software a construir. El prototipo sirve como un mecanismo para identificar los requisitos del software cuando no existe otra forma posible, para su construccin pueden utilizarse fragmentos de programas existentes o herramientas que faciliten la rpida generacin de programas. Se requiere la participacin del usuario durante su construccin, pues es l quien define las caractersticas esperadas en el sistema. Los pasos a seguir para el desarrollo de prototipos se podran definir de la siguiente manera:
Definicin de requisitos
Construccin del prototipo
Evaluacin del prototipo
13
Prototipo Final
Figura 4. Mtodo del Prototipo de Sistemas
El prototipo final no es un sistema de informacin completo, es tan solo su primera versin. Como lo afirm E. Brooks: La primera versin del sistema puede ser apenas utilizable, puede ser demasiado lento, demasiado grande, difcil de usar o las tres cosas. Por lo tanto, el prototipo deber desecharse.. Desarrollar sistemas utilizando la metodologa de prototipos puede ocasionar los siguientes problemas: El cliente ve funcionando lo que parece ser una primera versin del software y desear su implantacin de inmediato. El que desarrolla puede usar tcnicas inapropiadas con el fin de terminar el prototipo y estas eventualmente pueden quedar como parte del sistema de informacin.
Es necesario definir las reglas del juego, el cliente y el tcnico deben estar de acuerdo en el prototipo y el alcance del mismo. El desarrollo de prototipos se aplica generalmente para sistemas de informacin ubicados en los niveles medio y alto de la organizacin. Se puede hacer una clasificacin de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo a las caractersticas que consideren y a su operabilidad para realizar simulaciones. Prototipos Estticos: son aquellos que no permiten la alteracin de sus componentes, pero sirven para identificar y resolver problemas de diseo. En esta categora se incluyen las presentaciones sobre reproductores, papel u otro medio de visualizacin. Prototipos Dinmicos: permiten la evaluacin de un modelo del sistema sobre una estacin de trabajo o una terminal. Estos prototipos involucran aspectos de diseo mas detallados que los prototipos estticos, incluyendo la validacin del diseo del sistema en trminos de requerimientos no funcionales, por ejemplo de desempeo. Prototipos Robustos: deben ser relativamente completos en la simulacin de las caractersticas dinmicas de la interfaz (presentacin de mensajes de error, entrada y edicin de datos, etc.). Esta categora puede ser utilizada para validar los objetivos de diseo.
El nivel de sofisticacin del prototipo debera incrementarse a lo largo del proceso de diseo de interfaces de usuario. La informacin recolectada durante las tareas de anlisis del sistema y la especificacin de los requisitos del usuario constituyen los datos clave para el proceso de prototipacin. Este ciclo casi siempre supone que el modelo ser operante, es decir, una coleccin de programas que simularn alguna o todas las funciones que el usuario desea. Pero dado que se pretende que dichos programas sean solo de modelo, tambin se supone que al concluirse el modelado, los programas se descartarn y se reemplazarn con programas reales. Normalmente se utilizan las siguientes herramientas: Un diccionario de datos integrado. Un generador de pantallas. Un generador de informes no guiado por procedimientos. Un lenguaje de programacin de cuarta generacin. Un lenguaje de consultas no guiado por procedimientos. Medios poderosos de administracin de bases de datos.
VENTAJAS:
14
1. 2. 3. 4. 5. 6. 7.
Se incrementa la productividad del equipo de desarrollo. Se incrementa la calidad del producto final, ya que el prototipo permite trabajar, ensayar,... disminuyen los costes de mantenimiento del producto final. Los tiempos de desarrollo son inferiores. El tamao del sistema es menor. La especificacin acta como interface entre cliente y equipo de desarrollo. El propio prototipo sirve de contrato con el cliente y cualquier cambio en el prototipo debe estar consolidado por ambas partes. El prototipo es un documento vivo de buen funcionamiento del producto final. Ayuda para determinar requerimientos expresados en el prototipo. Experimenta sobre los aspectos del sistema que representan mayor complejidad. Demuestran la viabilidad del sistema. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no sobre una especificacin escrita.
INCONVENIENTES: 1. 2. 3. Fuerte inversin en un producto que se desechable: Los prototipos se descartan. Tendencia a tratar de convertir el prototipo mismo en el sistema de produccin. Aumento del coste. Se arrastran decisiones del diseo de prototipos al producto final.
HERRAMIENTAS CASE
Se puede definir las herramientas como el til que se utiliza para desarrollar un anlisis, se usan para: Concentrarse en las propiedades importantes del sistema. Discutir cambios y correcciones de los requerimientos del usuario, a bajo coste y con el riesgo mnimo. Verificar que el sistema comprende correctamente el entorno del usuario. Dar soporte automtico o semiautomtico a los mtodos.
Ejemplos de herramientas de modelado de sistemas importantes son: Diagramas de Flujo de Datos (DFD), que ilustran las funciones que el sistema debe realizar. Diagrama Entidad Relacin (DER), que hacen nfasis en lasa relaciones entre los datos. Diagrama de Transicin de Estados (DTE), que se enfoca al comportamiento dependiente del tiempo del sistema.
Debido a las caractersticas especficas del ciclo del vida del desarrollo de sistemas y, sobre todo, debido a la gran cantidad de informacin que se debe generar en cada etapa, comienzan a introducirse herramientas y entornos automatizados de produccin, organizacin, edicin y gestin de dicha informacin, que facilitan, o en muchos casos posibilitan el uso de metodologas formales de forma cmoda y eficiente. Por tanto, la tecnologa CASE sustituye el papel y el lpiz por el ordenador (computadora) para hacer del desarrollo del software un proceso ms productivo. El objetivo fundamental del CASE es proporcionar un conjunto de herramientas que automaticen los trabajos de desarrollo y mantenimiento del software, de ah sus siglas que significan: Herramientas para Ingeniera de Software Asistido por Computadora (Computer Assist Software Engineering). Los analistas se apoyan en las herramientas CASE para aumentar la productividad, comunicarse ms efectivamente con los usuarios e integrar el trabajo que realizan en el sistema, desde el principio hasta el fin del ciclo de vida del desarrollo de sistemas. Algunas de las facilidades ofrecidas por este tipo de herramientas son: Soporte a la gestin para aumentar el control y la coordinacin por parte de la direccin. Diseo de diagramas estructurados y creacin de especificaciones grficas. Prototipado de las pantallas de usuario.
15
Centralizacin de la informacin del sistema en un diccionario en el que se pueden almacenar, obtener informes y consultar. Verificacin de la consistencia y la correccin de las especificaciones del sistema. Mantenimiento, re-documentacin, reestructuracin y anlisis del sistema diseado. Eliminar errores fcilmente.
Dado que la modelizacin es una actividad grfica, se pueden conseguir DFD (diagramas de flujo de datos), DER (diagramas de entidad relacin) y DTE (diagramas de transicin de estados) ms eficientemente y conseguir resultados ms estticos con herramientas CASE. Aunque la gestin del DD (diccionario de datos) est presente en todas las herramientas CASE, la mayora tambin ofrecen otra serie de utilidades como son la normalizacin de las estructuras de datos, la generacin de las bases de datos a partir de las especificaciones de diseo, la generacin de cdigo fuente a partir de las especificaciones funcionales, la elaboracin de prototipos que permitirn al usuario observar como funcionar el sistema una vez implantado, et. Segn la capacidad de la herramienta CASE, se puede hacer la siguiente clasificacin: Herramientas CASE de Nivel Superior, denominadas tambin Planificacin Asistida por Ordenador permiten que el analista cree y modifique el diseo del sistema basndose en la utilizacin de software que permita automatizar las tareas de planificacin empresarial, por ejemplo, lo que concierne a la gestin de proyectos de desarrollo de Sistemas de Informacin. Estas herramientas tambin pueden ayudar a dar soporte al modelaje de los requerimientos funcionales de una organizacin, asistir a los analistas y usuarios en el trazo de las fronteras de un proyecto dado y ayudarlos a visualizar la manera en que el proyecto engrana con otras partes de la organizacin. Adems, algunas herramientas CASE superiores pueden dar soporte a la elaboracin de prototipos de diseos de pantalla y reportes. Herramientas CASE de Nivel Medio, tambin denominadas herramientas CASE Integradas, que combinan las herramientas CASE de nivel superior con las de nivel inferior en un solo juego de herramientas y se utilizan mucho en la automatizacin del Anlisis y Diseo de Sistemas de Informacin. Herramientas CASE de Nivel Inferior, son usadas para generar cdigo fuente de computadora, eliminando la necesidad de programar el sistema. La generacin de cdigo tiene varias ventajas: 1. El sistema puede ser producido ms rpidamente que mediante la estructura de programas de computadora. 2. La cantidad de tiempo empleada en el mantenimiento disminuye con la generacin del cdigo. No hay necesidad de modificar, probar y depurar programas de computadora. En vez de ello, el diseo en CASE es modificado y el cdigo es regenerado. 3. El cdigo puede ser generado en ms de un lenguaje de computadora, por lo que es ms fcil emigrar sistemas de una plataforma a otra. 4. La generacin de cdigo proporciona una forma eficiente en costo para adecuar sistemas comprados a proveedores de terceras partes, y as satisfacer las necesidades de la organizacin. 5. El cdigo generado est libre de errores de programacin de computadora. Los nicos errores potenciales son errores de diseo, que pueden ser minimizados por la ejecucin de reportes de anlisis CASE para asegurarse que el diseo de sistemas sea completo y correcto.
En la siguiente tabla se muestra las herramientas CASE ms populares en las dcadas de los 80 y 90: Corporacin Al Lee & Associates Anderson Consulting Cadre Technologies Inc. CGI Systems Inc. Computer Systems Advisers Inc. Intersolv KnowledgeWare Inc. Nombre del Producto Magec Foundation Temwork PacBase POSE Excelator APS Aplication Development Workbench (ADW) Tipo de Herramienta CASE CASE de nivel inferior CASE de nivel medio CASE de nivel superior CASE de nivel medio CASE de nivel superior CASE de nivel superior CASE de nivel inferior CASE de nivel medio
16
Information Engineering Workbench CASE de nivel medio (IEW) Siemens AG XperCASE CASE de nivel medio Synon Inc. Synon AS/SET CASE de nivel inferior Texas Instrument Information Engineering Facility CASE de nivel medio (IEF) Visible Systems Corp. Visible Analyst CASE de nivel superior Yourdon Inc. Analyst/Designer Toolkit CASE de nivel superior Tabla 2. Herramientas CASE ms populares en las decadas de 80 y 90
EL DICCIONARIO DE DATOS
El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el analista como el usuario tengan un entendimiento comn de todas las entradas, salidas, componentes de almacenes y clculos intermedios. Sirve como descripcin lgica del sistema y documenta: todos los flujos incluidos en el DFD, todos los almacenes de datos, la actividad de los procesos, las entidades externas. El diccionario de datos define los datos haciendo: Describe un significado de los flujos y almacenes que se muestran en los DFD. Describe la composicin de agregados de paquetes de datos que se mueven a lo largo de los flujos. Describen la composicin de los paquetes de datos en los almacenes. Especifica los valores y unidades relevantes de piezas elementales de informacin en los flujos de datos y en los almacenes de datos. Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relacin.
El diccionario de datos es tambin una aplicacin especializada de los tipos de diccionarios usados como referencias en la vida diaria. Como documento, el diccionario de datos recolecta, coordina y confirma lo que significa un trmino de datos especfico para diferentes personas de la organizacin. Los diagramas de flujo de datos, son un punto de partida excelente para la recoleccin de entradas del diccionario de datos. Los analistas de sistemas deben estar concientes y catalogar diferentes trminos que se refieren al mismo concepto de datos. Esto ayuda a evitar complicacin de esfuerzos, permite una mejor comunicacin entre los departamentos organizacionales, que comparten una base de datos y hace ms directo el mantenimiento. El diccionario de datos tambin puede servir como un estndar consistente para los elementos de datos. Existen tambin diccionarios de datos automatizados (que son parte de las herramientas CASE) son valiosos por su capacidad para hacer referencias cruzadas de conceptos de datos. Adems de proporcionar documentacin y eliminar la redundancia, el diccionario de datos puede ser usado para: 1. Validar el diagrama de flujo de datos y para confirmar que est completo y preciso. 2. Proporcionar un punto inicial para el desarrollo de pantallas y reportes. 3. Determinar el contenido de datos almacenados en archivos. 4. Desarrollar la lgica para los diagramas de flujo de datos de procesos. Para comprobar que un DD (Diccionario de Datos) es correcto se deber comprobar si todos los flujos del DFD se han definido en el diccionario, si se han definido todos los componentes de los datos, si se ha definido un dato ms de una vez y, si se ha utilizado la notacin correcta. NOTACIN DEL DICCIONARIO DE DATOS SMBOLO = DESCRIPCIN est compuesto por
17
+ () {} [] ** @ |
y optativo (puede estar presente o ausente) iteracin seleccionar una de varias alternativas comentario identificador (campo clave) para un almacn separa opciones alternativas en la construccin Tabla 2. Smbolos usados en la descripcin de una Estructura de Datos
DEFINICIONES: La definicin de un dato se introduce con el smbolo "=", que se lee: "se define como", "se compone de", "significa". Para definir por completo un dato, nuestra definicin debe incluir: la composicin del dato, si se compone de partes elementales con significado; los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse ms. ELEMENTOS DE DATOS BSICOS: Las partes elementales de los datos son aquellas para las cuales ya no existe una descomposicin con significado dentro del contexto del ambiente de usuario. Cuando se han identificado todos los datos elementales, deben introducirse en el DD con una breve narrativa describiendo su significado en el contexto del usuario. DATOS OPCIONALES: Un dato opcional es que que puede estar o no presente en un dato compuesto. Van encerrados entre parntesis y deben verificarse con el usuario. ITERACIN: La notacin de iteracin se utiliza para indicar la ocurrencia repetida de un componente de un dato. Se lee como "cero o ms ocurrencias de". SELECCIN: La notacin de seleccin indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Las opciones se encierran entre corchetes y, se separan con una barra vertical. Es importante revisar las opciones de seleccin con el usuario para cubrir todas las posibilidades. ALIAS: Un alias es una alternativa de nombre para un dato. Se incluye en el DD y se relaciona con el nombre primario u oficial del dato. Por ejemplo: comprador = *alias de cliente* Comprador no muestra su composicin ya que estos detalles aparecen en el nombre primario y as se evita la redundancia en el modelo. Debe evitarse el uso de alias en la medida de lo posible. Elementos que Integran el Diccionario de Datos Flujo de Datos: El flujo de datos es por lo general, el primer elemento o componente a ser definido. Las entradas y salidas del sistema son determinadas a partir de entrevistas, observacin de usuarios y anlisis de documentos y otros sistemas existentes. La informacin capturada para cada flujo de datos debe ser definida en el diccionario de datos o debe de ser sumarizada usando una forma que contenga la siguiente informacin: 1. 2. 3. 4. ID, un nmero de identificacin opcional. A veces el ID es codificado usando un esquema para identificar el sistema y la aplicacin dentro del sistema. Un nombre descriptivo nico para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama y que puede ser referenciado en todas las descripciones que usan el flujo de datos. Una descripcin general del flujo de datos. El origen del flujo de datos. Esto puede ser una entidad externa, un proceso o un flujo de datos que vienen de un almacn de datos.
18
Apuntes de Anlisis y Diseo de Sistemas 5. 6. 7. 8. 9.
El destino del flujo de datos (los mismos conceptos mencionados para el origen). Una identificacin de si el flujo de datos es un registro que entra o sale de un archivo, o contiene un reporte, forma o pantalla. Si el flujo de datos contiene datos que son usados entre procesos, es designado como interno. El nombre de la estructura de datos describiendo los elementos que se encuentran en este flujo de datos. Para un flujo de datos simple esto podra ser uno o varios elementos. El volumen por unidad de tiempo. Esto puede ser registros por da o cualquier otra unidad de tiempo. Un rea para comentarios adicionales y observaciones acerca del flujo de datos.
A continuacin se muestra un ejemplo de una forma para describir el flujo de datos pedido del cliente:
Descripcin del Flujo de Datos
ID: Nombre: Pedido del Cliente Descripcin: Contiene informacin del pedido del cliente y es usada para actualizar los archivos maestros de clientes y de artculo para producir un registro de pedido. Origen: Tipo de Flujo de Datos: Archivo Destino:
Pantalla
Reporte
Forma
Interno
Estructura de datos viajando con el flujo Volumen/tiempo Informacin del pedido 10/da
Comentarios: la informacin de un registro de pedido para un pedido de cliente. El pedido puede ser recibido por correo, fax o por llamada telefnico directa del cliente al departamento de procesamiento de pedidos.
Figura 5. Ejemplo de una forma para la descripcin de flujo de datos para una empresa x.
Estructura de Datos: Las estructuras de datos son descritas por lo general usando notacin algebraica. Esto permite al analista producir una lista de los elementos que conforman la estructura de datos, junto con la informacin acerca de esos elementos. Por ejemplo, el analista indicar si hay muchos de los mismos elementos dentro de la estructura
19
de datos (un grupo repetido) o si dos elementos pueden existir mutuamente excluyentes. La notacin algebraica usa los smbolos mostrados en la Tabla 2 y en la Figura 6 se muestra un ejemplo de un formato. Elemento de Datos: Cada elemento de datos puede ser definido una vez en el diccionario de datos y tambin puede ser dado anteriormente en una forma de descripcin de elemento, como se muestra en la Figura 7. Las caractersticas comnmente incluidas en la forma de descripcin de elemento son: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ID de elemento. Entrada opcional que puede ser til en diccionario de datos automatizado. El nombre del elemento, que debe ser descriptivo y nico. Alias, que son sinnimos u otros nombres para el elemento. Una descripcin breve del elemento. Si el elemento es bsico o derivado. La longitud de un elemento, para almacenarlo (longitud en la estructura). El tipo de dato, numrico, fecha, alfabtico o alfanumrico. Se deben incluir los formatos de entrada y salida, usando smbolos de codificacin especiales. Criterios de validacin, para asegurar que sean capturados los datos precisos por el sistema. Cualquier valor por omisin que pueda tener el elemento. Un rea adicional para comentarios.
Pedido del cliente =
Nmero de cliente + Nombre de cliente + Direccin + Telfono + Nmero de catlogo + Fecha de pedido + (Artculos del pedido disponibles) + Total de mercancas + (Impuestos) + Manejo y envo + Total del pedido + Mtodo de pago + (tipo de tarjeta de crdito) + (Nmero de tarjeta de crdito) + (Fecha de expiracin) Nombre + Apellido paterno + Apellido materno Calle + (Departamento) + Ciudad + Estado + Cdigo postal + (Expansin de cdigo postal) + (Pas) Clave LADA + Nmero local Cantidad pedida + Nmero del artculo + Descripcin del artculo + Tamao + Color + Precio + Total de artculos Cheque | Cargo | Orden de pago]
Nombre del cliente =
Direccin =
Telfono = Artculos del pedido disponibles =
Mtodo de pago = Tipo de tarjeta de crdito =
20
[Banamex | Bancomer | American Express | Master Card | Visa]
Figura 6. Ejemplo de una estructura de datos para pedido de cliente
Forma de Descripcin de Elemento
ID: Nombre: Alias: Alias: Descripcin: Nmero de Cliente Nmero de cliente Nmero de cuenta por cobrar Identifica en forma nica a un cliente que ha hecho cualquier
transaccin de negocios en los ltimos cinco aos Caractersticas del Elemento Longitud:
6
9(6) 9(6)
Decimales
Alfabtico Alfanumrico Fecha
Formato de Entrada: Formato de Salida: Valor por Omisin:
Numrico Bsico
Continuo
Discreto Criterio de validacin
Derivado
Continuo Limite superior Limite Inferior
Discreto Valor <999999 Significado
>0 El nmero de cliente debe de pasar una prueba de dgito verificador
Comentarios: mdulo - II
21
Figura 7. Ejemplo de Forma de Descripcin de Elemento
ESTUDIO DE FACTIBILIDAD
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materializacin sin tener perdidas econmicas y frustracin profesional. La viabilidad y el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad o factibilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters: La administracin efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El administrador del proyecto debe anticiparse a los problemas que podran surgir, as como preparar soluciones tentativas a esos problemas. La planeacin es un proceso iterativo que solamente se completa cuando el proyecto mismo se termina. Conforme la informacin se hace disponible, el plan debe revisarse regularmente. Las metas globales del negocio son un factor importante que debe considerarse cuando se formula el plan del proyecto. Conforme esto cambie, los cambios en el proyecto sern necesarios. El proceso de planeacin del proyecto inicia con una valoracin de las restricciones que afectan el proyecto (fecha de entrega requerida, personal disponible, presupuesto global, etc.). sta se lleva a cabo con una estimacin de los parmetros del proyecto como su estructura, tamao y distribucin de funciones. Entonces se definen los hitos de progreso y productos a entregar. En ese momento, el proceso entra en un ciclo. Se prepara un calendario para el proyecto y las actividades definidas en el calendario inician o continan. Despus de algn tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y sealan las discrepancias. Debido a que las estimaciones iniciales de los parmetros del proyecto son tentativas, el plan siempre deber actualizarse. Las estimaciones estn asociadas con el esfuerzo y el tiempo con las actividades identificadas del proyecto. Los administradores del proyecto deben estimar las respuestas a las siguientes preguntas: 1. Cunto esfuerzo (personal necesario) se requiere para completar una actividad? 2. Cunto tiempo se necesita para completar una actividad? 3. Cul es el costo total de una actividad? La estimacin y la realizacin del cronograma del proyecto se llevan a cabo de forma conjunta. Sin embargo, en las primeras etapas del proyecto se requieren algunas estimaciones de costos, antes que se tenga el cronograma detallado. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente. Factibilidad Tcnica.
22
Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad. Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras. Entre los aspectos tcnicos que es comn que aparezcan durante la investigacin de este tipo de factibilidad, se incluyen los siguientes: 1. 2. 3. 4. 5. Existe o se puede adquirir la tecnologa necesaria para realizar lo que se pide? El equipo propuesto tiene la capacidad tcnica para soportar todos los datos requeridos para usar el nuevo sistema? El sistema propuesto ofrecer respuestas adecuadas a las peticiones sin importar el nmero y ubicacin de los usuarios? Si se desarrolla el sistema, podr crecer con facilidad? Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos?
Por ejemplo, si la propuesta incluye una impresora que imprima con una rapidez de 15,000 lneas por minuto, entonces una breve investigacin mostrar que esta especificacin es tcnicamente factible. (La decisin de incluir la impresora en la configuracin es de ndole econmica.) Por otro lado, si un usuario solicita un sistema cuya entrada sea la voz para escribir, leer y efectuar cambios en los datos ya almacenados, entonces es muy probable que la propuesta no sea tcnicamente posible. Para complementar tambin sera necesario realizarse las siguientes preguntas: puede realizarse el proyecto con el equipo actual, la tecnologa existente de software y el personal disponible? Si se necesita nueva tecnologa, cul es la posibilidad de desarrollarla? Factibilidad econmica. Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado. El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la caractersticas del Sistema. El anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. Un sistema que puede ser desarrollado desde el punto de vista tcnico y que, adems, ser utilizado si se llega a instalar, debe ser una buena inversin para la organizacin. Los beneficios financieros deben igualar o exceder a los costos. Las cuestiones econmicas y financieras formuladas por los analistas durante la investigacin preliminar, tienen el propsito de estimar lo siguiente: 1. 2. 3. 4. 5. El costo de llevar a cabo la investigacin completa de sistemas. El costo del hardware y software para la aplicacin que se est considerando. Beneficios en la forma de reduccin de costos o de menos errores costosos. El costo si nada sucede (es decir si el proyecto no se lleva a cabo). Si los beneficios que se obtengan sern suficientes para aceptar los costos.
Una vez que el proyecto se comienza a ejecutar, las estimaciones se actualizan de forma regular. Esto ayuda al proceso de planeacin y permite la utilizacin efectiva de los recursos. Si el gasto real es significativamente ms grande que las estimaciones, entonces el administrador del proyecto debe tomar algunas acciones. stas pueden ser: solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar. Existen tres parmetros involucrados en el clculo del costo total de un proyecto de desarrollo de software: los costos de hardware y software, incluyendo el mantenimiento; los costos de viajes y capacitacin; los costos de esfuerzo (los costos de pago a los ingenieros de software).
23
Para muchos proyectos, el costo dominante es el costo del esfuerzo. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos, son relativamente bajos para muchos proyectos. Adems, el uso de correo electrnico, los chat, fax y teleconferencias reduce los viajes requeridos. Los costos del esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. Las organizaciones calculan los costos de esfuerzo en funcin de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organizacin y dividen ste entre el nmero de personas productivas. Por lo tanto, los siguientes costos son parte de los costos de esfuerzo totales: 1. los costos de proveer, calentar e iluminar las oficinas; 2. los costos del personal de apoyo como los contadores, secretarias, limpiadores y tcnicos; 3. los costos de las redes y comunicaciones; 4. los costos de los recursos centralizados como las bibliotecas, los recursos recreativos, etc.; 5. los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud. Debido a las consideraciones organizacionales involucradas, asignar precio del proyecto por lo general le concierne al administrador principal de la organizacin, as como a los administradores del proyecto de software. El proceso de desarrollo de sistemas de informacin al igual que el de cualquier producto de software, requiere la aplicacin de mtricas de estimacin para garantizar resultados ms precisos en su ciclo de vida. El objetivo de este trabajo es investigar acerca de las tcnicas de estimacin que existen para los productos de sistemas de informacin, presentando mtricas para estimacin de costos dadas por varios autores de artculos, especialistas en el asunto de aplicaciones hipermedia y web. Tcnicas de estimacin: No existe una forma simple de calcular el esfuerzo requerido para desarrollar un sistema informtico. Las estimaciones iniciales se hacen bajo la base de la definicin de requisitos de usuario de alto nivel. Pero en una primera etapa del proyecto es difcil producir una estimacin precisa de los costos de desarrollo del sistema. Por ese motivo la estimacin se utiliza para definir si el presupuesto del proyecto y el producto se ajusta para que las cifras del presupuesto se cumplan. No se conocen informes de experimentos controlados sobre los costos de los proyectos donde los costos estimados no se utilicen para ajustar el experimento. Un experimento controlado no revelara la estimacin del costo al administrador del proyecto. Los costos reales tendran que compararse con los estimados del proyecto. A pesar de esto, las organizaciones necesitan calcular esfuerzos de software y estimaciones de los costos. Para hacerlo, se utilizan una o ms de las tcnicas descritas en la tabla 1 (Boehm, 1981). Estos enfoques para la estimacin del costo se pueden abordar utilizando enfoque descendente o ascendente. Un enfoque descendente inicia en el nivel de sistema. La estimacin comienza examinando la funcionalidad total del producto y cmo es que esa funcionalidad se propaga al interactuar con las subfunciones. Se toman en cuenta los costos de las actividades del nivel del sistema tales como la integracin, la administracin de la configuracin y la documentacin. El enfoque ascendente, en contraste, inicia en el nivel de componente. El sistema se divide en componentes y se calcula el esfuerzo requerido para desarrollar cada uno de stos. Estos costos se suman para dar el esfuerzo requerido del desarrollo del sistema completo. Las desventajas del enfoque descendente son las ventajas del ascendente y viceversa. La estimacin descendente subestima los costos de resolver problemas tcnicos difciles asociados con componentes especficos como las interfaces para hardware no estndar. No existe justificacin detallada de la estimacin que se produce. En contraste, la estimacin ascendente produce tal justificacin y considera cada componente. Sin embargo, este enfoque tiende a subestimar los costos de las actividades del sistema como la integracin. La estimacin ascendente tambin es ms costosa. Debe haber un diseo inicial del sistema para identificar los componentes a evaluar. Tcnica Modelado del algoritmo de Descripcin Se desarrolla un modelo utilizando informacin histrica de costos que
24
relaciona alguna mtrica de software (por lo general, su tamao) con el costo del proyecto. Se hace una estimacin de esa mtrica y el modelo predice el esfuerzo requerido. Se consultan varios expertos en las tcnicas de desarrollo de software propuestas y en el dominio de aplicacin. Cada uno de ellos estima el Opinin de expertos costo del proyecto. Estas estimaciones se comparan y discuten. El proceso de estimacin se itera hasta que se acuerda una estimacin. Esta tcnica es aplicable cuando otros proyectos en el mismo dominio de aplicacin se han completado. Se estima el costo de un nuevo proyecto Estimacin por analoga por analoga con estos proyectos completados. Myers (1989) da una descripcin muy clara de este enfoque. La Ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles ms Ley de Parkinson que por los objetivos logrados. Si el software se tiene que entregar en 12 meses y se dispone de cinco personas, el esfuerzo requerido se estima en 60 personas-mes. El costo del software se estima dependiendo de lo que el cliente est Asignar costos para ganar dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software. Tabla 3. Tcnicas de estimacin de costos costos Cada tcnica de estimacin tiene sus propias fortalezas y debilidades. Para proyectos grandes, se deben utilizar varias tcnicas de estimacin de costos y comparar sus resultados. Si stos predicen costos radicalmente diferentes, esto indica que no se tiene suficiente informacin para generar los costos. Se debe buscar ms informaciones y repetir el proceso hasta que la estimacin converja. Estas dos tcnicas de estimacin son aplicables cuando existe un documento de requisitos para el sistema. ste define a todos los usuarios y los requisitos del sistema. Por lo tanto, se puede generar una estimacin razonable de la amplitud de la funcionalidad del sistema a desarrollar. En general, los proyectos grandes de ingeniera de sistemas normalmente tendrn tal documento de requisitos. Sin embargo, en muchos casos, los costos de muchos proyectos se tienen que estimar utilizando solamente un borrador de solicitudes del usuario del sistema. El anlisis y la especificacin de requisitos son costosos y los administradores de la compaa necesitan de una estimacin inicial del costo del sistema antes de que puedan generar un presupuesto aprobado para este proceso. Bajo estas circunstancias, asignar costos para ganar es una estrategia utilizada comnmente. La nocin de asignar precios para ganar parece no ser tica y poco apropiada para los negocios. Sin embargo, tiene algunas ventajas. Un costo del proyecto se acuerda en base a un borrador de la propuesta. Entonces, las negociaciones se llevan a cabo con el cliente para determinar una especificacin detallada del proyecto. Esta especificacin se restringe por el costo acordado. El comprador y el vendedor deben acordar la funcionalidad aceptable del sistema. El factor clave en muchos proyectos no son los requisitos del proyecto, sino el costo. Los requisitos se cambian de tal forma que no se exceda el costo. Factibilidad Operacional Los proyectos propuestos nicamente tienen beneficio cuando logran ingresar al grupo de sistemas de informacin que satisfacen los requerimientos de la organizacin. En palabras sencillas, esta prueba de factibilidad formula las siguientes preguntas: trabajar el sistema cuando est terminado e instalado? Existen barreras importantes para la implantacin? A continuacin se proporcionan varias preguntas que son de gran ayuda para probar la factibilidad operacional de un proyecto: Existe apoyo suficiente para el proyecto por parte de la administracin?, y por parte de los usuarios? Si el sistema en uso es bien visto y es utilizado por muchas personas que no ven ninguna razn para efectuar
25
cambios, entonces es probable encontrar resistencia al cambio. Los mtodos que actualmente se emplean en la empresa son aceptados por los usuarios? Si no es as, entonces los usuarios darn la bienvenida a cualquier cambio que permita tener un sistema de informacin ms til y operacional. Los usuarios han participado en la planeacin y desarrollo del proyecto? La participacin temprana disminuye, en general, los riesgos de rechazo hacia el sistema y el cambio; asimismo aumenta las posibilidades de xito de los proyectos. El sistema propuesto causar perjuicios? Producir resultados pobres en algn aspecto o rea? Se perder el control en alguna rea? Se perder la facilidad de acceso a la informacin? La productividad de los empleados ser menor despus que antes de la implantacin? Los clientes se vern afectados en forma poco favorable? El sistema reducir la productividad de otras reas?
Aspectos que al inicio parecen tener poca importancia pueden convertirse en grandes problemas despus de la implantacin. Por lo tanto siempre deben considerarse de manera cuidadosa todos los aspectos operacionales. La gente se resiste a los cambios en su forma de trabajo cuando sta no presenta inconvenientes y se siente cmoda. Pero si no es as, entonces los usuarios aceptarn con gusto cualquier cambio que permita tener un sistema ms til y fcil de usar. Por otro lado, si los usuarios se involucran con el proyecto desde el principio sern parte del cambio y las posibilidades de xito, desde la perspectiva operacional, aumentan. Adems, el proyecto debe aumentar la productividad de los empleados para que sea atractivo a la empresa. Nunca un proyecto de sistemas debe obstruir o disminuir la integracin de las funciones de una empresa ni en el corto ni en largo plazo. Factibilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema. Como es el caso de realizar un sistema copiando el funcionamiento y pantallas de otro sistema ya desarrollado, esto se toma como una violacin a las leyes del derecho de autor. Tambin es importante tomar en consideracin que al realizar un sistema de informacin se deber desarrollar el cdigo del programa utilizando el software original del lenguaje de programacin seleccionado previamente; de este modo se adquiere los derechos y licencias para distribuir programas desarrollados con dicho lenguaje aunque en esto no se incluya la distribucin y/o venta de copias del lenguaje mismo. Para evitar cualquier infraccin a las leyes es menester que se informe con la empresa desarrolladora del lenguaje de programacin cuales son los alcances y limitaciones del mismo al momento de desarrollar sistemas, esto evitar buenos dolores de cabeza y malos ratos ante la justicia. Para ser considerado como factible, la propuesta debe pasar todas las pruebas. La propuesta que no pasa las pruebas de factibilidad puede desecharse o redefinirse para presentarse nuevamente en el futuro. Algunas veces la solucin a los problemas de la empresa no es precisamente el desarrollo de un nuevo sistema de informacin.
CALENDARIZACION
Planeacin y Control de Actividades El anlisis y diseo de sistemas involucra muchos tipos de actividades diferentes que juntos forman un proyecto. El analista de sistemas debe administrar el proyecto cuidadosamente para que llegue a ser un proyecto exitoso. La administracin de proyectos involucra las tareas generales de planeacin y control. La planeacin incluye todas las actividades requeridas para seleccionar un equipo para anlisis de sistemas, la asignacin de los miembros del equipo a los proyectos adecuados, la estimacin del tiempo requerido para completar cada tarea y la canlendarizacin del proyecto para que las tareas sean terminadas en forma ordenada. El control significa usar retroalimentacin para monitorear el proyecto. Esto incluye la comparacin del plan del proyecto con su evolucin actual. El control significa, adicionalmente, el tomar las acciones adecuadas para agilizar
26
o recalendarizar las actividades para que se terminen a tiempo y, as mismo, motivar a los miembros del equipo para que se termine el trabajo adecuadamente. Se debe comenzar a planear un proyecto dividindolo en tres actividades principales. Anlisis. Recoleccin de datos Anlisis del flujo de datos y decisiones Preparacin de la propuesta Diseo de la captura de datos Diseo de la entrada Diseo de la salida Organizacin de datos Implementacin Evaluacin
Diseo.
Implementacin.
Los pasos indicados anteriormente para cada actividad todava pueden por supuesto dividirse en ms pasos, la cantidad de detalle necesaria depende del proyecto, pero es necesario que en los planes aparezcan todos los pasos crticos. Grficas de Gantt A veces la parte ms difcil de la planeacin del proyecto es el paso crucial de la estimacin del tiempo que se lleva terminar cada tarea o actividad. No hay nada que sustituya a la experiencia en la estimacin de los requerimientos de tiempo. Una Grfica de Gantt es una forma fcil para calendarizar tareas. Es esencialmente una grfica en donde las barras representan cada tarea o actividad. La longitud de cada barra representa la longitud relativa en tiempo de la tarea. Esta grfica se realiza en dos dimensiones, en una grfica de dos ejes; en este caso tenemos que es tiempo contra actividades. Por ejemplo a continuacin se presenta una grfica de Gantt para 5 actividades hipotticas. La actividad A con una duracin de 4 semanas, la actividad B con 2 semanas, la actividad C con 5 semanas, la actividad D con 3 semanas y la actividad E con 6 semanas:
Actividades
A B C D E
Actividad No Iniciada Actividad Inconclusa Actividad Terminada
10
12
14
16
Semanas
Figura 8. Ejemplo de una Grfica de Gantt Para poder determinar esta grfica se recomienda como primer punto realizar una lista de las actividades en una tabla antes de dibujar la grfica, tomando la siguiente consideracin: ACTIVIDAD A NOMBRE Primera actividad REQUISITO DURACIN (unidad de tiempo) 4
27
Apuntes de Anlisis y Diseo de Sistemas B C D E Segunda actividad Tercera actividad Cuarta actividad Quinta actividad
Academia de Computacin 2 5 3 6
A B C
Tabla 4. Tabla de actividades para el ejemplo propuesto Como se aprecia la tabla se divide en cuatro columnas las cuales describen (de izquierda a derecha) la actividad denominada por una letra del alfabeto para agilizar el anlisis y calendarizacin; Nombre muestra el nombre en si de la actividad correspondiente; Requisito indica la actividad o actividades que se requiere finalizar antes de iniciar la actividad respectiva y Duracin indica cuanto durar la actividad indicada, este se podr dar en das, semanas, meses o inclusive aos (unidad de tiempo). De esta lista-tabla de actividades se puede determinar para la grfica de Gantt que las actividades A y B no tienen ninguna actividad requisito o predecesora por lo tanto son las actividades que inician el proyecto y ambas inician en paralelo, es decir a la vez, cada una con una duracin de 4 y 2 semanas respectivamente. Tenemos ahora que la actividad C para que comience tiene como requisito que haya culminado la actividad A, y esta dura 5 semanas; la actividad D tiene como requisito a la actividad B y dura 3 semanas y por ltimo la actividad E tiene como requisito a la actividad C y dura 6 semanas. Compare esta interpretacin con la grfica de Gantt mostrada anteriormente y vera que concuerda cada barra horizontal en su inicio, fin y duracin con las dems barras de la grfica. Tambin se debe destacar que en esta grfica aparece el smbolo que indica en que semana se encuentra el desarrollo del proyecto, en nuestro ejemplo se encuentra en la semana 16, esto indica que ya se termin el proyecto por lo que todas las barras estn pintadas de gris como lo indica la leyenda adjunta a la grfica. En caso de que se encuentre en una semana intermedia se deber dar a cada actividad su estado original y preciso de desarrollo, es decir si la actividad ya se complet, si esta a medio culminar o si no se ha iniciado todava con dicha actividad. Por lo tanto se deber agregar un cuadro de leyenda donde se indique el posible estado de cada actividad dentro del diagrama, basndose en el smbolo que indica en que semana se encuentra el proyecto ( ). Diagrama PERT PERT son las siglas de Evaluacin de Programas y Tcnicas de Revisin. Un programa (sinnimo de proyecto) es representado por una red de nodos y flechas, y es luego evaluado para determinar las actividades crticas, mejorar la calendarizacin, si es necesario, y revisar el avance una vez que el proyecto se realiza. Por ejemplo el diagrama PERT correspondiente a la grfica de Gantt realizada anteriormente sera:
20 A,4 10 B,2 30 D,3 C,5 40 E,6 50
Figura 9. Diagrama PERT para el ejemplo propuesto Esta comparacin de un diagrama PERT y una Grfica de Gantt, nos muestra que, las actividades expresadas como barras en la grfica de Gantt, son representadas por flechas en el diagrama PERT. La longitud de las flechas no tiene relacin directa con la duracin de las actividades. Los crculos del diagram PERT son llamados eventos o nodos, y pueden ser identificados con nmeros, letras o cualquier otra forma arbitraria de informacin. Estos nodos circulares o eventos estn presentes para (1) reconocer que una actividad est terminada o va a iniciar y (2) indicar cules actividades necesitan ser terminadas antes de que pueda comenzar una nueva actividad (precedencia). Un proyecto tiene un inicio, una parte media y un final, siendo el inicio en nuestro ejemplo el evento 10 y el final el evento 50. Para encontrar la longitud del proyecto es identificada cada ruta. En este ejemplo, la ruta 10-2040-50 tiene una longitud de 15 das y, en cambio, la ruta 10-30-40-50 tiene una longitude de 11 das. Aunque una
28
persona puede estar trabajando en la ruta 10-20-40-50 y otra en la ruta 10-30-40-50, el proyecto no es una carrera. El proyecto o programa requiere que ambos conjuntos de actividades (o rutas) se completen y, por consecuencia, el proyecto se lleva 15 das en terminar. A la ruta ms larga se le dice Ruta Crtica. Aunque la ruta crtica es determinada calculando la ruta ms larga, est definida como la ruta que causar que el proyecto completo se atrase, aunque se encuentre un retraso de un solo da en ella. Observe que si hay un retraso de un da en la ruta 10-20-40-50 el proyecto completo se llevar ms tiempo, pero si hay un retraso de un da en la ruta 10-30-40-50 al proyecto completo no le pasar nada. El tiempo perdido que se encuentra en algunas rutas no crticas es llamado tiempo de holgura, el cual se calcula tomando la ruta ms pequea y la ruta ms grande (ruta crtica) se restan ambas y el resultado sin llegar a ser la ruta crtica es el tiempo de holgura. Por ejemplo en la ruta 10-20-40-50 se tiene un tiempo de 15 (das o semanas) y en la ruta 10-20-40-50 se tiene un tiempo de 11, al restar y considerar no llegar a ser ruta crtica se tiene que el tiempo de holgura es de 3.
MUESTREO
De manera paralela a todos los mtodos de investigacin y de observacin, estn las decisiones cruciales en relacin con qu examinar y a quien preguntar u observar. El analista de sistemas puede tomar estas decisiones con base en un enfoque estructural llamado muestreo. El Muestreo es el proceso de seleccionar sistemticamente elementos representativos de una poblacin. Cuando estos elementos seleccionados son examinados de cerca, se supone que el analista revelar informacin til acerca de la poblacin como un todo. El analista de sistemas tiene que tomar una decisin sobre dos puntos importantes. Primero, hay muchos reportes, formas, documentos de salida y memorandums que han sido generados por los miembros de la organizacin. A cules de stos debe prestar atencin el analista de sistemas y cules debe ignorar?. Segundo, gran cantidad de empleados pueden ser afectados por el sistema de informacin propuesto. A qu personas debe entrevistar el analista de sistemas, buscar informacin por medio de cuestionarios y observar en el proceso de llevar a cabo sus papeles de toma de decisin?. Para disear un buen muestro, el analista de sistemas debe seguir cuatro pasos, los cuales se listan a continuacin: 1. 2. 3. 4. Determinar los datos a ser recolectados o descritos. Determinar la poblacin a ser muestreada. Seleccionar el tipo de muestra. Decidir el tamao de la muestra.
Determinacin de los datos a ser recolectados y descritos. El analista de sistemas necesita un plan realista sobre lo que har con los datos una vez que los recolecte. Si se recolectan datos irrelevantes, se desperdicia tiempo en la recoleccin, almacenamiento y anlisis de datos intiles. Las tareas y responsabilidades del analista de sistemas en este punto son identificar las variables, atributos y conceptos de datos asociados que necesitan ser recolectados en la muestra. Se deben considerar los objetivos del estudio, as como el tipo de mtodo de recoleccin de datos (investigacin, entrevistas, cuestionarios, observacin) a ser usados. Determinacin de la poblacin a ser muestreada. El analista de sistemas debe determinar cual es la poblacin. En el caso de datos relevantes, necesita decidir, por ejemplo, si son suficientes los dos ltimos meses o si se necesitan los reportes de todo el ao para ese anlisis. En forma similar, cuando se decide a quien entrevistar, el analista de sistemas tiene que determinar si la poblacin debe incluir solamente un nivel de la organizacin o todos los niveles, o tal vez ir hasta el exterior del sistema para incluir la reaccin de los clientes Seleccin del Tipo de muestra. El analista de sistemas tiene cuatro tipos principales de muestreo, los cuales se describen con detalle a continuacin:
29
Apuntes de Anlisis y Diseo de Sistemas -
Muestras de conveniencia. Las muestras de conveniencia son muestras no restringidas y no probables. Una muestra puede ser llamada de conveniencia, si, por ejemplo, el analista de sistemas pone una noticia en el boletn de la compaa pidiendo a cualquier interesado en el nuevo reporte de desempeo de ventas que asista a una reunin a la 1:00 p.m. el martes 12. Obviamente, la muestra es la ms fcil que se podra recolectar, pero, al mismo tiempo, es la menos confiable. Muestras intencionadas. Un analista de sistemas puede seleccionar a un grupo de individuos que parecen tener conocimiento e inters en el nuevo sistema de informacin. Este es un ejemplo de una muestra intencionada basada en el juicio del analista. Aqu el analista de sistemas basa la muestra sobre un criterio (conocimiento e inters en el nuevo sistema), pero todava es una muestra no probada. Por lo tanto, este muestreo intencionado es slo moderadamente confiable. Muestras Aleatorias simples. Si se escoge realizar una muestra aleatoria simple se necesita obtener una lista numerada de la poblacin para asegurarse de que cada documento o persona de la poblacin, tenga una oportunidad igual de ser seleccionado. A veces esto no es prctico, especialmente cuando el muestreo involucra documentos y reportes. Muestras Aleatorias complejas. Frecuentemente se pueden lograr los objetivos del muestreo seleccionando uno de los enfoques para el muestreo aleatorio complejo. Los enfoques ms adecuados para el analista de sistemas son: En el mtodo ms simple del muestreo probable, el muestreo sistemtico, el analista de sistemas podra, por ejemplo, a cada ensima persona de una lista de empleados de la compaa. Sin embargo este mtodo tiene ciertas desventajas, como por ejemplo, si esa lista estuviera ordenada alfabticamente o en cualquier otra forma de orden el muestreo sera impreciso debido a la ascendencia introducida. Las muestras estratificadas son, tal vez, las ms importantes para el analista de sistemas. La estratificacin es el proceso de identificacin de subpoblaciones, o estratos, y luego la seleccin de objetos o personas a muestrear dentro de estas subpoblaciones. La estratificacin es, a menudo, esencial si el analista de sistemas va a recolectar datos eficientemente. La estratificacin tambin se aplica cuando el analista de sistemas quiere usar diferentes mtodos para recolectar datos de diferentes subgrupos. Algunas veces el analista de sistemas debe seleccionar un grupo de documentos o personas a estudiar. A esto se le llama muestreo aglomerado. Suponga que una organizacin tiene 20 bodegas repartidas por todo el pas. Tal vez quiera seleccionar uno o dos de estas bodegas, bajo la hiptesis de que son tpicas de las bodegas restantes.
Decisin del Tamao de la Muestra. Obviamente, si todos en la poblacin vieran el mundo de la misma forma, o cada uno de los documentos de una poblacin contuviera exactamente la misma informacin que cualquier otro documento, sera suficiente un tamao de muestra de uno. Dado que ste no es el caso, es necesario tomar un tamao de muestra mayor a uno pero menor que el tamao de la poblacin misma. Es importante recordar que la cantidad absoluta es ms importante en el muestreo que el porcentaje de la poblacin. Se puede obtener resultados satisfactorios muestreando 20 personas en 200 o 20 personas en 2000,000. El tamao de la muestra depende frecuentemente del costo involucrado en el tiempo requerido por el analista de sistemas o hasta el tiempo disponible de las personas de la organizacin.
ENTREVISTAS
Problemas y Oportunidades de Mejora dentro de la Organizacin El revisar la salida, la observacin del comportamiento de los empleados y el escuchar la retroalimentacin, son maneras que ayudarn al analista a resaltar los problemas y oportunidades de mejora. Observe la siguiente tabla:
30
Para identificar los problemas Revise la salida contra los criterios de desempeo
Busque estos signos especficos: Demasiados errores Trabajo terminado lentamente Trabajo hecho incorrectamente Trabajo hecho en forma incompleta Trabajo que no se realiza del todo
Observe el comportamiento de los empleados
Alto ausentismo Alta insatisfaccin en el trabajo Alta rotacin de personal Quejas Sugerencias de mejoras Prdida de ventas Menores ventas
Escuche retroalimentacin externa de: Vendedores Clientes Proveedores
Tabla 5. Problemas y signos especficos dentro de una empresa Las mejoras a los sistemas pueden ser definidas como cambios que darn como resultado beneficios aumentados y que valen la pena. Existen muchas posibilidades de mejoras, incluyendo: 1. 2. 3. 4. 5. 6. 7. 8. Aceleracin de un proceso. Agilizacin de un proceso mediante la eliminacin de pasos innecesarios o duplicados. Combinacin de procesos. Reduccin de errores en la entrada por medio de cambios en formas y pantallas. Reduccin de salida redundante. Mejora en la integracin de sistemas y subsistemas. Mejora de la satisfaccin del trabajador con el sistema. Mejora de la facilidad de interaccin de los clientes, proveedores y vendedores, con el sistema.
Se encuentra dentro de las capacidades del analista de sistemas el darse cuenta de las oportunidades para mejoras. Sin embargo, las personas que estn en contacto diario con el sistema pueden ser mejores fuentes de informacin acerca de las mejoras que deben ser hechas. Si las mejoras ya ha sido sugeridas, se necesita la experiencia propia para que ayude a determinar si valen la pena y la forma en que pueden ser implementadas. Criterios para la Seleccin de proyectos de Sistemas Respaldo de la administracin Temporizacin adecuada para comprometerse con el proyecto Posibilidad del logro de mejoras de los objetivos de la organizacin Que sea prctico en trminos de recursos para los analistas de sistemas y la organizacin Que el proyecto sea valioso comparado con otras formas en que la organizacin pueda invertir los recursos
PLANEACION DE LA ENTREVISTA
31
Existen cinco pasos para la preparacin de una entrevista, estos incluyen un rango de actividades, desde la recoleccin del material bsico de fondo hasta el tomar la decisin de a quien entrevistar. Estos cinco pasos son los siguientes: Lectura de Material de Fondo.- Leer y comprender tanta informacin de fondo acerca del entrevistado y su organizacin como le sea posible. Conforme se lea el material, se debe sensibilizar particularmente con el lenguaje que usan los miembros de la organizacin. Lo que se trata de hacer es construir un vocabulario comn, que eventualmente le permitir redactar las preguntas de la entrevista en una forma que sea comprensible por el entrevistado. Otro beneficio de la investigacin sobre la organizacin es maximizar el tiempo que se gasta en la entrevista, en vez de perder tiempo preguntando asuntos generales de fondo. Establecimiento de los Objetivos de la entrevista.- Se debe usar la informacin de fondo que recopil, as como la propia experiencia, para establecer los objetivos de la entrevista. Debe haber de cuatro a seis reas principales que se relacionan con el procesamiento de informacin y con el comportamiento para la toma de decisiones acercar de la cuales querr hacer preguntas. Estas reas incluyen: fuentes de informacin, formatos de la informacin, frecuencia de la toma de decisiones, cualidades de la informacin y estilo de la toma de decisiones. Decidir a Quien Entrevistar.- Cuando se est decidiendo a quien entrevistar incluya a gentes clave de todos los niveles que sern afectadas por el sistema en alguna forma. Se debe tratar de obtener balance para que sean tratadas tantas necesidades de los usuarios como sean posibles. El contacto de la organizacin tambin tendr algunas ideas sobre quien debe ser entrevistado. Preparar al Entrevistado.- Se debe preparar a la persona a ser entrevistada, llamndole con anticipacin y permitiendo que el entrevistado tenga tiempo para pensar acerca de la entrevista. Se deber acomodar tiempo para llamadas telefnicas y reuniones. Las entrevistas deben durar de 45 minutos a una hora, a lo mucho, se deber recordar que cuando el usuario gasta el tiempo con el analista, el usuario no est haciendo su trabajo. Si las entrevistas van ms all de una hora, es probable que los entrevistados resientan la intrusin, sin importar si manifiestan o no su resentimiento. Decidir sobre Tipos de Preguntas y Estructuras.- Se deber escribir preguntas para tratar las reas principales de la toma de decisiones descubiertas cuando se averiguaron los objetivos de la entrevista. Las tcnicas adecuadas del cuestionamiento son el corazn de la entrevista. Las preguntas tienen algunas formas bsicas que es necesario saber. Los tipos bsicos de preguntas son abiertas y cerradas. Cada tipo de pregunta puede lograr algo diferente del otro, y cada una tiene sus beneficios y desventajas. Es necesario pensar acerca del efecto que tendr cada tipo de pregunta. Es posible tambin estructurar la entrevista en tres patrones diferentes: una estructura de pirmide, una estructura de embudo o una estructura de rombo, siendo cada una de ellas adecuada bajo diferentes condiciones. A continuacin se describe a detalle algunas de las decisiones importantes que debe hacer el entrevistador. Estas incluyen cuales preguntas hacer y como, si estructurar la entrevista y cmo documentarla. TIPOS DE PREGUNTAS Preguntas Abiertas.- Las preguntas abiertas incluyen aquellas tales como Qu piensa acerca de la microcomputadoras para los gerentes? y Por favor, explqueme cmo toma una decisin de calendarizacin?. Abierta describe, de hecho, las opciones del entrevistado para responder; la respuesta puede ser de dos palabras o de dos prrafos. Los beneficios de usar preguntas abiertas son numerosos e incluyen: 1. Pone confortable al entrevistado. 2. Permite que el entrevistador recoja el vocabulario del entrevistado, el cual refleja su educacin, valores, actitudes y creencias. 3. Proporciona riqueza de detalles. 4. Revela caminos para preguntas posteriores que podran haber quedado sin atacar. 5. Hace que sea ms interesante para el entrevistado. 6. Permite ms espontaneidad. 7. Hace que la construccin de frases sea ms fcil para el entrevistador. 8. Se les puede usar en un aprieto si es que el entrevistador es tomado por sorpresa.
32
Se tiene por otro lado tambin que hay muchas desventajas que incluyen: 1. 2. 3. 4. 5. El hacer preguntas que pueden dar como resultado mucho detalle relevante. La posibilidad de perder el control de la entrevista. El permitir respuestas que pueden llevarse demasiado tiempo para la cantidad de informacin til obtenida. Pueden mostrar potencialmente que el entrevistador no est preparado. Pueden dar la impresin de que el entrevistador est en una expedicin de pesca sin un objetivo real para la entrevista.
A continuacin se presenta unos ejemplos de preguntas abiertas: Cul es su opinin del sistema de computadoras actual? Cmo ve los objetivos de este departamento (o empresa)? Cmo se relaciona esta forma con el trabajo que usted hace? Cules son algunos de los problemas que experimenta para recibir la informacin a tiempo? Cules son algunos de los errores comunes que se cometen en la captura de datos en este departamento? Describa el sistema de computacin ms frecuente con el que haya trabajado. Cules son sus responsabilidades principales? Cmo ve los objetivos de su departamento? Cmo describira su proceso de toma de decisiones? Cmo se le puede dar mejor soporte a ese proceso? Qu tan frecuentemente toma esas decisiones?
Preguntas Cerradas.- La alternativa a las preguntas abiertas se encuentra en las preguntas cerradas, que tiene la forma bsica Qu tantos subordinados tiene?. Las respuestas posibles estn cerradas al entrevistado, debido a que solamente puede responder con nmero finito, tal como ninguno, uno o quince. Un tipo especial de pregunta cerrada es la pregunta bipolar. Esto limita todava ms al entrevistado, permitindole solamente una seleccin de algn extremo, tal como si o no, cierto o falso, de acuerdo o desacuerdo. Los beneficios de usar preguntas cerradas de cualquier tipo incluyen: 1. 2. 3. 4. 5. 6. Se ahorra tiempo. Se facilita la comparacin de las entrevistas. Se llega al punto. Se mantiene control sobre la entrevista. Se tratan muchos temas rpidamente. Se obtiene datos relevantes.
Sin embargo, las desventajas del uso de preguntas cerradas son sustanciales, e incluyen: 1. 2. 3. 4. Ser aburridas para el entrevistado. No llegan a obtener grandes detalles (debido a que el entrevistador proporciona el marco de referencia para el entrevistado). Se pierden ideas principales por la razn anterior. No se llega a establecer una relacin armoniosa entre el entrevistado y el entrevistador.
Algunos ejemplos de preguntas cerradas son: Qu tantos reportes genera en un mes? Desde hace cunto trabaja para esta empresa o institucin? Cul de las siguientes fuentes de informacin es ms valiosa para usted: Formas de queja de clientes archivadas Interaccin cara a cara con el cliente La devolucin de mercanca por s misma Liste sus dos prioridades mximas para el departamento en el que trabaja
33
Quin recibe las salidas? Qu tanto lleva en este puesto? Qu reportes recibe usted? A quin consulta cuando toma una decisin? Cul es la decisin nica que toma que es esencial para el funcionamiento del departamento o empresa?
Algunos ejemplos de preguntas bipolares son: Usa usted una computadora personal? Est usted de acuerdo o no en que las funciones de contestadora automtica valdran la pena? Quiere usted recibir una impresin de computadora de su estado de cuenta cada mes? Su departamento de contabilidad proporciona transferencias de fondos electrnica automtica de los cheques de nmina para los empleados por horas? Est esta forma (reporte o forma que la empresa usa en su administracin) correctamente llenada?
Averiguaciones.- Un tercer tipo de pregunta es la averiguacin. La averiguacin ms fuerte es la ms simple: la pregunta Por qu?, otras averiguaciones son Puede darme un ejemplo? y Me podra hablar ms de esto?. El objetivo de la averiguacin es ir ms all de la respuesta inicial para obtener ms significado, para aclararlo y para obtener y expandir el punto de vista del entrevistado, tambin permiten al analista de sistemas hacer preguntas adicionales para obtener respuestas ms detalladas. Algunos ejemplos de averiguaciones: Por qu? De un ejemplo de su proceso de toma de decisiones. Por favor, proporcione una ilustracin de las medidas de desempeo que mencion antes. Qu dijo hace un momento acerca de que el uso de su IBM PC parece estar en conflicto con sus anteriores opiniones de que el trabajo gerencial no puede ser automatizado? Por favor, aclare lo que quiere usted decir en cada enunciado. Qu es lo que hace que Usted se sienta de esa forma? Dgame lo que sucede paso a paso para el llenado de la forma de pacientes.
Fallas o Errores en las preguntas Redactando las preguntas de antemano ser capaz de corregir cualquier pregunta tonta que haya escrito. Se debe buscar tipos de preguntas problemticas que pueden arruinar los datos. Son llamadas preguntas conducentes y preguntas dobles. Preguntas conducentes.- Este tipo de preguntas tienden a dirigir al entrevistado hacia la respuesta que uno parece querer. La respuesta es entonces sugerida, debido a que se est poniendo un tipo de trampa. Un ejemplo es: Ha de estar de acuerdo con los dems gerentes de que el control de inventario debe estar computarizado, no es as?. Una redaccin alterna preferida podra ser, Qu piensa usted del control de inventario computarizado?. Los datos seran ms confiables y ms vlidos y, por lo tanto, ms fciles de comprender y ms tiles. Preguntas dobles.- Las preguntas dobles son aquellas en las que se usa una sola pregunta para lo que de hecho son dos preguntas separadas. Una pregunta tal como Qu decisiones toma durante un da tpico y como las toma?, este es un ejemplo de una pregunta doble. Si el entrevistado responde a este tipo de preguntas los datos pueden presentar dificultades. Una pregunta doble es una mala alternativa, debido a que el entrevistado puede responder solamente una pregunta (a propsito o no) o se puede caer en error sobre cual pregunta est respondiendo y sacar la conclusin equivocada.
ENTREVISTAS ESTRUCTURADAS
34
As como hay dos formas reconocidas generalmente para razonar, inductiva y deductiva, hay dos formas similares para organizar las entrevistas. Una tercera forma combina ambos patrones inductivo y deductivo: Estructura de Pirmide.- La organizacin inductiva de las preguntas de la entrevista puede ser visualizada como si tuviera una forma de pirmide. Mediante el uso de esta forma el entrevistador comienza con preguntas muy detalladas y frecuentemente cerradas. El entrevistador luego expande el tema permitiendo preguntas abiertas y respuestas ms generalizadas. Se debe usar una estructura de pirmide si se considera que el entrevistado necesita ambientarse en el tema. Tambin es til si el entrevistado parece ser que se resiste a entrar en el tema. Por ejemplo, si se est entrevistando a alguien que le ha dicho por telfono que no necesita hablar con usted, debido a que esa persona ya sabe lo que tiene de errneo el modelo de planeacin, probablemente se deber estructurar la entrevista en forma piramidal. Estructura de Embudo.- En el segundo tipo de estructura el entrevistador toma un enfoque deductivo, comenzando con preguntas generales y abiertas y estrechando las respuestas posibles usando preguntas cerradas. LA estructura de la entrevista puede ser vista como con forma de embudo. El uso de esta estructura proporciona una forma fcil y no intimidante para comenzar una entrevista. Tambin es til cuando el entrevistado se siente interesado acerca del tema y necesita libertad para expresar sus emociones. Estructura de Rombo.- Frecuentemente es mejor una combinacin de las dos estructuras anteriores, dando como resultado la estructura de entrevista con forma de rombo. Esto conlleva el comenzar en una forma muy especfica, luego examinar temas generales y por ltimo llegar a una conclusin muy especfica. El entrevistador comienza con preguntas cerradas fciles que proporcionan un calentamiento al proceso de la entrevista. A la mitad de la entrevista se le pide al entrevistado opiniones sobre temas amplios, que obviamente no tienen una respuesta correcta. Luego el entrevistador estrecha las preguntas nuevamente para hacer que se respondan preguntas especficas, proporcionando as un cierre para el entrevistado y el entrevistador. La estructura de rombo combina la fuerza de los dos enfoques, pero tiene la desventaja de llevarse ms tiempo. La ventaja principal del uso de una estructura de rombo es conservar el inters y la atencin del entrevistado por medio de una diversidad de preguntas.
Entrevistas Estructuradas contra No Estructuradas Muchos entrevistadores novatos creen que, debido a que las entrevistas son parecidas a las conversaciones, es mejor no estructurar la preguntas o secuencia de preguntas en una entrevista. En una entrevista completamente estructurada todo est planeado y el plan es seguido estrictamente. Las preguntas cerradas son parte medular de una entrevista completamente estructurada. En la tabla siguiente se muestra el enfoque estructurado y no estructurado en una entrevista: No Estructurada Atributos Estructurada Difcil Evaluacin Fcil Alto Cantidad de tiempo requerido Bajo Muy necesario Entrenamiento requerido Limitado Mucho Permite espontaneidad Pequeo Mucha oportunidad Proporciona perspicacia del entrevistado Muy pequeo Grande Flexibilidad Pequeo Bajo Control del entrevistador Alto Bajo Precisin Alto Bajo Confiabilidad Alto Alto Amplitud y profundidad Bajo Tabla 6. Atributos de entrevistas estructuradas y no estructuradas a considerar cuando se decide Un formato de entrevista. REGISTRO DE LA ENTREVISTA
35
Se deber Registrar los aspectos ms importantes de la entrevista. Se puede usar una grabadora de cinta o lpiz y papel para tomar notas, pero es importante hacer un registro permanente durante la entrevista. El que se tomen notas o se use una grabadora de cinta depende, en parte, de a quien se est entrevistando y de lo que se har con la informacin una vez que haya pasado la entrevista. Adicionalmente, hay ventajas y desventajas inherentes en ambos mtodos de grabacin. Uso de una Grabadora de Cinta.- Se deber considerar al entrevistado cuando decida como grabar la entrevista. Cuando se haga una cita se le deber informar al entrevistado de que se pretende usar una grabadora de cinta en la entrevista. Se deber mencionar lo que se har con la cinta: puede ser que vaya a ser escuchada por el analista y por otros miembros del equipo y luego destruirla o ser transcrita y usada como informacin para el desarrollo del sistema. Se deber ser sincero acerca de las intenciones y confirmar la confidencialidad de cualquiera de los comentarios del entrevistado. Si el entrevistado se rehsa a permitirle el uso de la grabadora, se deber aceptar esta restriccin amablemente. Ventajas del uso de grabadora de cinta 1. Proporciona un registro completamente preciso de lo que cada persona dijo. 2. Libera al entrevistador para escuchar y responder ms rpidamente. 3. Permite mejor contacto visual y, por consecuencia, mejor desarrollo de una relacin armnica entre el entrevistador y el entrevistado. 4. Permite la reproduccin de la entrevista para otros miembros del equipo. Desventajas del uso de grabadora de cinta: 1. El hacer posiblemente inquietante la entrevista y menos apta para responder libremente. 2. Posiblemente hace que el entrevistador sea menos apto para escuchar, debido a que todo est siendo grabado. 3. La dificultad de localizar pasajes importantes en una cinta larga. 4. El incremento de costo de recoleccin de datos, debido a la necesidad de transcribir las cintas. Toma de Notas.- La toma de notas puede ser la nica manera para registrar la entrevista si el entrevistado se rehsa a la peticin de la grabacin de cinta. Es importante que se registren alguna forma la entrevista conforme sucede. Las ventajas de tomar notas incluyen: 1. 2. 3. 4. 5. Mantienen alerta al entrevistador. Ayudan a recordar preguntas importantes. Ayudan a recordar las ascendencias importantes de la entrevista. Muestran el inters del entrevistador en la entrevista. Demuestran la preparacin del entrevistador.
Las desventajas de la toma de notas incluyen: 1. 2. 3. 4. La prdida de contacto visual (y, por lo tanto, de una relacin armnica) entre el entrevistador y el entrevistado. La prdida del hilo de la conversacin. Se hace que el entrevistador tema hablar cuando se estn tomando notas. Hace que se ponga excesiva atencin a los hechos y poca atencin a los sentimientos y opiniones.
Antes de la Entrevista El da anterior a la entrevista se deber contactar al entrevistado para confirmar la hora y lugar de la entrevista. Coordinar las citas con cualquier otro miembro del equipo y recopilar los materiales necesarios. Para desarrollar la entrevista se deber vestir adecuadamente. Debido a que se estar controlando la entrevista, se deber vestir de una manera propia. La falla del vestir adecuadamente puede dar como resultado una recopilacin de datos pobre ya que las respuestas del entrevistado estarn orientadas por su percepcin inicial. Se deber llegar temprano a la entrevista. Se puede usar el tiempo adicional para revisar notas o comenzar a hacer observaciones acerca de la organizacin. Confirme con el entrevistado que Usted ya est presente y listo para comenzar la entrevista.
36
CONDUCCIN DE LA ENTREVISTA Cuando llegue salude de mano y con firmeza al entrevistado. Esto se aplica tanto si es hombre como mujer. Como en cualquier otra situacin de negocios, un apretn de manos ayuda a establecer la credibilidad y confianza. Recuerde al entrevistado el nombre de usted y describa brevemente una vez ms el por qu est ah y el por qu escogi entrevistarlo. En cuanto se siente, tome inmediatamente la grabadora y/o el cuaderno de notas y revise que todo est completo y funcionando. Recuerde al entrevistado que se grabar los puntos importantes, lo que se har con los datos que se recolecte y vuelva a afirmarle la confidencialidad de la informacin que se proporcione. Dependiendo de la estructura que se va a seguir en la entrevista se puede comenzar con algunas preguntas abiertas generales y no amenazadoras. El abrir la entrevista de esta forma ayuda a relajar al entrevistador y al entrevistado. Tambin proporciona un marco de referencia que es til para conformar las preguntas posteriores. Escuchando cuidadosamente las primeras respuestas se puede atrapar el vocabulario o jerga de la organizacin (por ejemplo en lugar de departamentos tienen unidades) o tambin las metforas tales como aqu somos una familia feliz ayudarn a revelar la membresa en la subculturas organizacionales. Las primeras respuestas abiertas tambin pueden revelar actitudes, moral y creencias del entrevistado que le ayudarn a comprender la manera en que se usa la informacin . Se debe escuchar y responder adecuadamente a lo que el entrevistado est diciendo. Conforme contina con el plan de la entrevista mencione a su interlocutor el tipo de detalle que le gustara recibir en las respuestas. Por ejemplo, si siente la necesidad de profundizar en una pregunta, motive al entrevistado para que le de un ejemplo. Si se tiene solo un inters pasajero en un tema, dgale al interlocutor que un si o no es suficiente. Usted est en control del uso del tiempo en este tipo de entrevistas, y el proporcionar lineamientos para la longitud de la respuesta es til para mantener el balance de la entrevista. Todo el material de la entrevista debe ser cubierto en 45 minutos o una hora, y por el momento se est conciente de la planeacin y administracin necesarias para lograr esto. El cerrar adecuadamente la entrevista es igualmente importante que la apertura. Durante la entrevista regrese a alguna de la respuestas del entrevistado por medio del parafraseo o sumarizacin, para volver a confirmar que se comprendi lo que quera decir. Si en cualquier momento no est seguro, se deben pedir definiciones u otro tipo de aclaraciones. No haga esto al cerrar la entrevista, no es lo ms adecuado. Sin embargo, al final de la entrevista es un momento natural para preguntar una cuestin importante: Hay algo de lo que no hayamos hablado y que usted siente que es importante que yo sepa?. La mayora de las veces es considerada una pregunta de formulismo por el entrevistado y la respuesta ser: No. Sin embargo, usted est interesado en el pequeo porcentaje de veces que esta pregunta abre las compuertas proverbiales y son presentados muchos datos nuevos ( y a veces sorprendente). Conforme concluye la entrevista hay otros procedimientos a seguir. Resuma y haga saber sus impresiones generales. Infrmele al entrevistado acerca de los pasos subsecuentes a tomar y que es lo que harn a continuacin usted y otros miembros del equipo. Tal vez se quiera preguntar al entrevistado con quien hablar a continuacin. Fije citas futuras para entrevistas de seguimiento, dele las gracias al entrevistado por haberle dado su tiempo y despdase con un apretn de manos. DESARROLLO DEL REPORTE DE LA ENTREVISTA Aunque la entrevista en s est terminada, el trabajo sobre los datos de la entrevista est apenas comenzando. Se necesita capturar la esencia de la entrevista por medio de un reporte escrito. Es imperativo que se escriba el reporte de la entrevista tan pronto como sea posible, despus de esta. Esta es otra forma con la cual se asegura la calidad de los datos logrados. Entre ms espere para escribir el reporte de la entrevista ms sospechosa se convierte la calidad de los datos. Despus de este resumen inicial pase a mayor detalle, haciendo notar los puntos principales de la entrevista y las opiniones de usted. Revise el reporte de la entrevista con su interlocutor en una reunin de seguimiento. Esto ayuda aclarar el significado de lo que el entrevistado tena en mente. Este reporte tambin permite ordenar los datos relevantes y de inters para el desarrollo del sistema de informacin, as como tambin permite ver las necesidades y problemticas de la institucin bajo anlisis.
37
DIAGRAMACION DE SISTEMAS
Un Diagrama Flujo de Datos es una representacin estructurada y grfica que describe cmo circula la informacin a travs de un sistema y los diferentes procesos de transformacin a los que se ve sometida. Permite visualizar un sistema como una red de procesos funcionales, conectados entre mediante flujos de datos. Es una de las herramientas ms usadas en sistemas computacionales en los que las funciones del sistema son de gran importancia y son ms complejas que los datos que ste maneja. Es un modelo lgico (no fsico) que representa qu hace el sistema y no cmo. Es comprensible por el usuario. Muestra cualquier nivel de detalle y, el flujo de la informacin asociada. Sirve para identificar y dar nombre a las fuentes de datos, destinos de los datos, flujos de datos, almacenes de datos y, procesos. El DFD se desarrolla con un enfoque descendente y est sujeto a una notacin y a unas reglas predefinidas que buscan producir un documento conciso y autoorganizado. El DFD se compone de Entidades Externas, flujos de datos, funciones o procesos y almacenes de datos. Convenciones usadas en diagramas de flujo de datos En un DFD se utilizan smbolos grficos para representar procesos, entidades externas, flujos de datos y almacenes de datos. Veamos cada uno de estos componentes: PROCESO.- Muestra una parte del sistema que transforma entradas en salidas, es decir, muestra cmo es que una o ms entradas se transforman en salidas. Actividad definida y predecible que transforma flujos de datos con el fin de conseguir un cierto objetivo. Se representa grficamente por un crculo. El proceso se nombre o describe con una sola palabra, frase u oracin sencilla, que describir lo que hace el proceso. FLUJO.- Informacin que circula de un objeto del diagrama a otro. Puede representar un dato elemental o una estructura de datos. Se representa grficamente por una flecha que entra o sale de un proceso. Se usa para describir el movimiento de bloques de informacin de una parte a otra del sistema, por lo que representan datos en movimiento. El nombre del flujo de datos describe el tipo de informacin que se transporta. ALMACN DE DATOS.- Conjunto de datos siempre disponible donde los datos quedan retenidos. Se utiliza para modelar una coleccin de paquetes de datos en reposo. Se denota por dos lneas paralelas. El nombre que se utiliza para denotar al almacn es el plural del que se utiliza para los datos que almacena. La informacin almacenada est en reposo. Es independiente de la implementacin fsica. Los flujos que van hacia el almacn se interpretan como una escritura, una actualizacin o una eliminacin de informacin del almacn. Los flujos que salen del almacn se interpretan como una lectura o un acceso a la informacin del almacn. AGENTE EXTERNO.- Se representa grficamente por un rectngulo y representa las entidades externas con las que el sistema se comunica. Existen tres cosas importantes acerca de los agentes externos: Son externos al sistema que se est modelando; los flujos que los conectan a los distintos procesos representan la interfaz entre l y el mundo exterior. No es posible cambiar el contenido del agente externo, ya que est fuera del dominio del cambio. Las relaciones existentes entre los agentes externos, no se muestran en el DFD.
No es relevante ni como obtiene la informacin ni qu hace con ella. Se usan cuatro smbolos bsicos para diagramar el movimiento de datos en los diagramas de flujo de datos. Como se mencion lneas arriba, son un cuadro o cuadrado, una flecha, un rectngulo con esquinas redondeadas y un
38
rectngulo con extremo abierto (cerrado al lado izquierdo y abierto del derecho), como se muestra en la siguiente figura: Smbolo Significado Ejemplo
Entidad
Estudiante
Nueva informacin de estudiante
Flujo de Datos
Proceso
2.1 Crear Registro de estudiante
Almacn de Datos
D3
Maestro de estudiantes
Figura 10. Simbologa empleada en la diagramacin de sistemas Se puede representar grficamente un sistema completo y numerosos subsistemas con la combinacin de estos cuatro smbolos, los cuales estn basados en el trabajo y la notacin de C. Gane y T. Sarson. (Notacin GaneSarson). El cuadro o cuadrado es usado para representar una entidad externa (otro departamento, un negocio, una persona o una mquina) que pueden enviar datos o recibirlos del sistema. La entidad externa tambin es llamada fuente (origen) o destino de datos y es considerada externa al estudio. Cada entidad externa es etiquetada con un nombre adecuado. Aunque interacta con el sistema, sta es considerada externa a la fronteras del sistema y por lo tanto no entra en el anlisis del sistema bajo estudio. Las entidades externas deben ser nombradas. La misma entidad externa puede ser usada ms de una vez en un diagrama de flujo de datos dado para evitar el cruce de las lneas de flujo de datos. La flecha muestra el movimiento de datos de un punto a otro, sta seala hacia el destino de los datos. Los flujos de datos que suceden simultneamente pueden ser representados simplemente mediante el uso de flechas paralelas. Debido a que una flecha representa datos acerca de una persona, lugar o cosa, tambin debe ser descrita por un nombre. Un rectngulo con esquinas redondeadas es usado para mostrar la aparicin de un proceso de transformacin. Los procesos siempre denotan un cambio o transformacin de los datos y, por lo tanto, el flujo de datos que sale de un proceso siempre es etiquetado en forma diferente al que entra en l. Los procesos representan trabajo que est siendo desarrollado dentro del sistema y deben ser nombrados usando alguno de los siguientes formatos: Un nombre claro facilita la comprensin de lo que est logrando con el proceso. 1. 2. Asigne el nombre del sistema completo cuando est nombrando un proceso de alto nivel. Un ejemplo es SISTEMA DE CONTROL DE INVENTARIO. Para nombrar un subsistema principal use un nombre tal como SUBSISTEMA DE REPORTE DE INVENTARIO.
39
Apuntes de Anlisis y Diseo de Sistemas 3.
Use un formato verbo-nombre-adjetivo para un proceso detallado. El verbo describe el tipo de actividad, por ejemplo, CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR o AADIR. El nombre indica cual es la salida principal del proceso, por ejemplo, REPORTE o REGISTRO. El adjetivo ilustra cul salida especfica es producida , tal como ENTREGAS DIFERIDAS o INVENTARIO. Ejemplos de nombres de procesos completos son: CALCULAR IMPUESTOS DE VENTAS, VERIFICAR EL ESTADO DE CUENTAS DE CLIENTES, PREPARAR LAS FACTURAS DE EMBARQUE, IMPRIMIR REPORTES DE ENTREGAS DIFERIDAS y AADIR REGISTRO DE INVENTARIO.
A los procesos tambin se les debe dar un nmero de identificacin nico, indicando el nivel del diagrama. Varios flujos de datos pueden entrar y salir de cada proceso. Examine los procesos que tiene una sola entrada y una sola salida para flujos de datos que se hayan olvidado. El ltimo smbolo bsico usado en los diagramas de flujo de datos representa un almacn de datos y es un rectngulo abierto. Este es trazado con dos lneas paralelas que son cerradas por una lnea corta al lado izquierdo y se deja abierto del lado derecho. Estos smbolos son trazados solamente del ancho suficiente para permitir las letras entre las lneas paralelas. En los diagramas de flujo de datos el tipo de almacenamiento fsico (por ejemplo, cinta, disco flexible, etc.) no es especificado. En este momento el smbolo de almacenamiento de datos est simplemente mostrando un recipiente para los datos que permita adicin y recuperacin de datos. Este almacn de datos deber ser nombrado usando un nombre adecuado. Los almacenamientos de datos temporales tal como un borrador en papel o un archivo de computadora temporal, no son incluidos en el diagrama de flujo de datos. Tampoco son incluidos ninguna forma en blanco ni discos flexibles en blanco, aunque pueden ser necesarios para la actividad del negocio. Se debe dar a cada almacn de datos un nmero de referencia nico, tal como D1, D2, D3, etc., para identificar su nivel. DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS La tcnica del DFD se basa en el principio de descomposicin de la funcionalidad de un sistema en sucesivos niveles de refinamiento (enfoque top-down) cuyo objetivo es permitir una lectura de la especificacin del sistema desde lo abstracto al detalle, permitiendo ver el sistema de forma global (niveles superiores), o de forma detallada (niveles inferiores). Se organiza as el DFD global en una serie de niveles de modo que cada uno proporcione sucesivamente ms detalles sobre una porcin del nivel anterior. As se parte de un diagrama general o Diagrama de Contexto en el que se representa una sola funcin con el nombre del sistema, las entidades externas que se relacionan con el sistema y, los flujos de entrada y salida al sistema. El siguiente nivel conocido como DFD/0 representa la vista de ms alto nivel de las principales funciones del sistema, al igual que sus principales interfaces. Y as sucesivamente. La descomposicin de cada subsistema no se detiene en un nivel determinado, sino que dependen del grado de complejidad del sistema. Normalmente se suele recomendar no utilizar ms de 4 niveles y que en cada nivel no aparezcan ms de 9 funciones. Veamos algunos aspectos de cada nivel: Diagrama de Contexto (Nivel inicial). El objetivo de este diagrama es la delimitacin del dominio del sistema que se est estudiando. Formado por una nica funcin, que representa al sistema completo y, el contexto del mismo. Diagrama nivel 0 (DFD/0). En este diagrama se especifican las funciones ms importantes del sistema, cada una de las cuales ser llevada por una parte del sistema. Podemos encontrarnos dos posibilidades: que sea igual al DC o, que est formado por las funciones o reas ms importantes del sistema. Diagrama nivel 1 (DFD/1). Es un modelo de trabajo con toda la funcionalidad del sistema. No muestra errores ni excepciones. Est formado por tantos procesos como eventos o acontecimientos se hallan detectado en la lista de eventos. Diagramas de niveles intermedios. Corresponden a los DFD en los que se explotan o descomponen cada uno de los subsistemas.
40
Diagramas de ltimo nivel. Son aquellos en los que las funciones que aparecen no se van a descomponer en subfunciones. Tales funciones no se pueden descomponer en otro DFD pero si en un documento denominado "Especificacin de Funcin Elemental" en el que se describe textualmente lo que debe hacer la funcin, pero no cmo debe hacerlo (que corresponde a la fase de diseo). Debemos saber algunos cosas sobre la descomposicin en niveles: Cmo saber cuntos niveles debe haber en un DFD? Cada DFD no debera tener ms de 6 burbujas y almacenes relacionados. Si no es posible escribir una especificacin de una funcin en una pgina, entonces es probable que sea demasiado complejo y debe descomponerse en un DFD de nivel inferior. 1. 2. 3. Existen reglas acerca del nmero de niveles que debe obtenerse? No, depender de la complejidad del sistema. Deben partirse todas las partes del sistema con el mismo nivel de detalle? No, algunas partes del sistema pueden ser ms complejas que otras y pueden requerir uno o ms niveles de descomposicin. Cmo asegurar que los niveles del DFD son consistentes entre s? Para asegurarse que un DFD es consistente con su DFD de nivel superior, los flujos de datos que entran y salen de una burbuja en un nivel dado, deben corresponder con los que entran y salen del nivel inmediato inferior que lo describe.
Cmo se muestran los almacenes en los distintos niveles? Se debe mostrar un almacn en el nivel ms alto donde primeramente sirva de interfaz entre dos o ms procesos; luego, mostrarlo de nuevo en cada diagrama de nivel inferior que describa ms a fondo dichos procesos. Los diagramas de flujo de datos pueden y deben ser trazados en forma sistemtica. Primero el analista de sistemas necesita conceptualizar los flujos de datos desde una perspectiva de arriba hacia abajo. Para comenzar un diagrama de flujo de datos, resuma o determine una lista con las cuatro categoras de entidad externa, flujo de datos, proceso y almacenamiento de datos. Esta lista a su vez ayuda a determinar las fronteras del sistema que se va a describir. Una vez que se haya compilado una lista bsica de elementos de datos, comience a trazar un diagrama de contexto. A continuacin se da un resumen de los pasos involucrados en los diagramas de flujo de datos bien terminados: 1. Haga una lista de actividades del negocio y sela para determinar varios: - Entidades externas - Flujos de datos - Procesos - Almacenes de datos Cree un diagrama de contexto que muestre las entidades externas y los flujos de datos que entran y salen del sistema. No muestre ningn proceso detallado ni almacn de datos. Trace el diagrama 0 o de primer nivel, en el siguiente nivel. Muestre procesos, pero mantngalos generales. En este nivel muestre los almacenes de datos. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0. Revise buscando errores y asegrese que las etiquetas que se asignan a cada proceso y flujo de datos son significativas. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico. Distinga entre procesos manuales y automatizados, describa los archivos actuales y reportes por nombre y aada controles para indicar cuando estn terminados los procesos o suceden errores. Divida el diagrama de flujo de datos fsico, separando o agrupando partes del diagrama para facilitar la programacin e implementacin.
2. 3. 4. 5. 6.
7.
41
Creacin del Diagrama de Contexto Con un enfoque de arriba hacia abajo para diagramar el movimiento de datos, los diagramas se mueven de lo general a lo especfico. Mientras el primer diagrama ayuda al analista de sistemas a ilustrar el movimiento de datos bsico, su naturaleza general limita su utilidad. El diagrama de contexto inicial debe ser un panorama que incluya entradas bsicas, el sistema en general y las salidas. Este ser el diagrama ms genrico, realmente una vista a ojo de pjaro del movimiento de datos en el sistema y la conceptualizacin ms amplia posible del mismo. Un resumen general de todo el sistema bajo estudio. El diagrama de contexto es el nivel ms alto en un diagrama de flujo de datos, y contiene solamente un proceso que representa al sistema completo (nicamente un proceso, no ms). A este proceso le es dado el nmero cero. Todas las entidades externas son mostradas en el diagrama de contexto, as como los flujos de datos principales que entran y salen de l. El diagrama no contiene ningn almacenamiento de datos, y es bastante simple de crear una vez que las entidades externas y el flujo de datos de y hacia ellas es conocido por los analistas a partir de entrevistas con usuarios y anlisis de documentos. A continuacin se presenta algunas formas de ejemplo de hacer un diagrama de contexto: 0
Origen Flujo Datos 1
Nombre Del Sistema
Flujo Datos 2
Destino
0
Origen/ Destino Flujo Datos 1
Nombre Del Sistema
Flujo Datos 2
Origen 1 Flujo Datos 1
0 Nombre Del Sistema

Flujo Datos 3 Destino
Flujo Datos 2 Origen 2
Figura 11. Tres ejemplos de cmo dibujar un Diagrama de Contexto Estas tres maneras de dibujar un diagrama de contexto no son las nicas, obviamente se puede obtener una combinacin adecuada de varios flujos de datos, destinos y orgenes; pero siempre ser nicamente un proceso, no ms.
42
Apuntes de Anlisis y Diseo de Sistemas Como dibujar el diagrama 0 o de Primer Nivel
Un mayor detalle que el que permite el diagrama de contexto se logra explotando o fragmentando los diagramas. Las entradas y salidas especificadas en el primer diagrama permanecen constantes en todos los diagramas subsecuentes. Sin embargo, el resto del diagrama original es explotado en acercamientos que involucran de tres a nueve procesos, y muestran almacenes de datos y nuevos flujos de datos de nivel ms bajo. Es el efecto que se obtendra usando una lupa para ver el diagrama de flujo de datos original. Cada diagrama explotado debe usar solamente una hoja de papel. Mediante la explosin del diagrama de flujo de datos hacia subprocesos, el analista de sistemas comienza a llenar los detalles acerca del movimiento de datos. El diagrama 0 o de primer nivel es la explosin del diagrama de contexto y puede incluir hasta nueve procesos. El incluir ms procesos a este nivel dar como resultado un diagrama amontonado que es difcil de comprender. Cada proceso es enumerado con un entero, comenzando por lo general, en la esquina superior izquierda del diagrama y trabajando hacia la esquina inferior derecha. Los almacenes de datos principales del sistema y todas las entidades externas son incluidas en el diagrama 0. En caso de tener problemas en la creacin de este diagrama, se puede: 1. Comenzar con el flujo de datos a partir de una entidad externa del lado de la entrada. Hgase preguntas tales como: Qu pasa con los datos que entran al sistema? Son guardados? Son alimentados a varios procesos? Trabaje hacia atrs a partir de un flujo de datos de salida. Examine los campos de salida de un documento o pantalla. Para cada campo de la salida pregntese De dnde viene? Es calculado o est guardado en un archivo? Por ejemplo, cuando la salida es un CHEQUE DE PAGO, el NOMBRE DE EMPLEADO y DIRECCIN podran estar ubicados en un archivo EMPLEADOS (almacn de datos), las horas trabajadas podran estar en un REGISTRO DE TIEMPO y el PAGO BRUTO y DEDUCCIONES podran ser calculados. Cada archivo y registro (almacn de datos) podra ser conectado con un proceso que produce el cheque de pago. Examine los datos que fluyen hacia o de un almacn de datos. Pregntese: Qu procesos ponen datos en el almacn? Qu procesos usan esos datos? Observe que un almacn de datos usado en el sistema en el que se est trabajando puede ser producido por un sistema diferente. Por lo tanto, para su ventaja puede ser que no haya ningn flujo de datos hacia el almacn de datos. Analice un proceso bien definido. Observe qu datos de entrada necesita el proceso y qu salida produce. Luego conecte la entrada y la salida a los almacenes de datos adecuados y a entidades externas. Tome nota de cualquier rea incierta donde no est seguro de lo que debe ser incluido o qu entrada o salida es requerida. El tomar conciencia de reas problemticas le ayudar a formular una lista de preguntas para entrevistas de averiguacin con usuarios principales.
2.
3.
4. 5.
Una ayuda muy importante para la realizacin del diagrama 0 o de primer nivel es la creacin del diagrama Jerrquico de Procesos. Este diagrama permite mostrar nicamente los procesos que intervienen en el sistema bajo estudio, en una forma jerrquica, es decir por niveles de arriba hacia abajo. Los procesos que se especifiquen en el primer nivel de este diagrama sern los que se usarn en el diseo del diagrama 0, tanto en cantidad como en sus nombres, y los procesos de los niveles subsiguientes se usaran de la misma forma en los diagramas ms detallados de cada proceso. Por ejemplo si se realiza un diagrama jerrquico de procesos con 5 procesos, el diagrama de primer nivel correspondiente tendr 5 procesos, ni uno ms ni uno menos, y los nombres de cada proceso sern los mismos nombres puestos en los procesos del diagrama jerrquico de procesos. A continuacin se muestra un pequeo ejemplo de lo explicado.
Nombre Sistema
43
Proceso 1
Proceso 2
Proceso 3
Proceso 4
Proceso 5
Proceso 2.1
Proceso 2.2
Proceso 2.3
Proceso 4.1
Proceso 4.2
Proceso 2.3.1
Proceso 2.3.2
Proceso 4.2.1
Proceso 4.2.2
Figura 12. Ejemplo de un Diagrama Jerrquico de Procesos
Este diagrama jerrquico de procesos de ejemplo tiene 3 niveles y puede llegar hasta 7 niveles sin que se vea todo apretado y confuso. Se deber recordar que los procesos debe denotar una accin que permita manipular, transformar los datos o la informacin que circula por el sistema. El diagrama 0 o de primer nivel correspondiente a este diagrama jerrquico de procesos es el siguiente:
0
Origen Flujo Datos 1
Flujo Datos A
D1
Flujo Datos Solicitado
Almacn de Datos 1
Proceso 1 0 Proceso 2
Flujo Datos B
Flujo Datos C
0 0 Proceso 5
Flujo Datos D
Flujo Datos a guardar
Proceso 3
0
Flujo Datos Solicitado
Flujo Datos 2
Proceso 4
Destino Flujo Datos a Flujo Datos Solicitado Almacn de Datos 2
D1
Almacn de Datos 1 guardar 44
D2
Figura 13. Ejemplo de un diagrama cero o de primer nivel Se debe percatar en este caso que para los almacenes de datos se podr utilizar la ayuda de la Tabla de Especificacin de clases, donde las clases que se especifiquen se podrn usar como almacenes de datos automatizados, se podr utilizar y repetir los almacenes de datos tantas veces sea necesario para evitar que se crucen las lneas, y no es necesario que la informacin entre y salga obligatoriamente de un almacn de datos, como se muestra en el ejemplo, y adems no hay limite en el nmero de almacenes de datos a utilizar. Por ltimo tambin se debe tomar en consideracin que las entradas y salidas lo mismo que el origen y destino son los mismos, permanecen constantes a lo mostrado en el diagrama de contexto correspondiente, en este caso corresponde al primer diagrama de contexto de ejemplo mostrado lneas arriba. ERRORES EN LOS DIAGRAMAS Pueden suceder diversos errores cuando se trazan diagramas de flujo, algunos de los ms comunes se muestran a continuacin: 1. Los flujos de datos no deben dividirse en dos o ms flujos de datos diferentes:
2
ERROR
1 3
2.
Todos los flujos de datos deben iniciarse o terminar en un proceso OBLIGADAMENTE. Es decir no pueden conectarse dos entidades externas entre si, tampoco se puede conectar una entidad externa con un almacn de datos, ni mucho menos conectar dos almacenes de datos entre si: ERROR
D1
D2
3.
Los procesos necesitan tener al menos un flujo de datos de entrada y un flujo de datos de salida: ERROR
2
45
REGLAS PARA LA DIAGRAMACION DE SISTEMAS 1. 2. 3. 4. 5. 6. 7. 8. 9. Los flujos de datos no pueden dividirse en dos o ms flujos de datos diferentes Todos los flujos de datos deben iniciarse o terminar en un proceso obligadamente. Los procesos necesitan tener al menos un flujo de datos de entrada y un flujo de datos de salida. Una entidad externa (Origen y/o Destino) no deben conectarse directamente a un almacn de datos. Todo proceso sin excepcin debe tener una entrada y una salida de flujo de datos. Un almacn de datos no debe conectarse directamente a otro almacenamiento de datos, es decir que los almacenes de datos y las entidades no pueden estar conectados entre ellos. Se debe etiquetar correctamente los procesos y/o flujos de datos, un proceso debe indicar el nombre del sistema o usar un formato verbo-nombre-adjetivo y cada flujo de datos debe ser descrito con un nombre. No de debe pasar de ms de nueve procesos por diagrama de flujo de datos, ms de nueve provocar errores y confusin a la hora de analizar el diagrama. Cada diagrama de flujo de datos hijo debe tener los mismos flujos de datos de entrada y salida que el proceso padre.
10. Los procesos que se indiquen en el diagrama jerrquico de procesos en cada nivel debern ser los mismos tanto en numero como por sus nombres que los que se pongan en el diagrama 0 o de primer nivel y los diagramas hijo. 11. Los diagramas de deben hacer siempre de lo ms general a lo ms detallado, es decir que mientras se pueda agrupar en un proceso general varias operaciones del sistema ser mucho mejor y ms sencillo de realizar el diagrama, pero esta agrupacin de operaciones deber tener sentido, los procesos o acciones que se agrupen deber ser o tener algo en comn. DIAGRAMAS DE TRANSICIN DE ESTADOS El tercer tipo de herramienta de modelado que vamos a estudiar (el diagrama de transicin de estados), enfatiza el comportamiento del sistema dependiente del tiempo. Se utiliza fundamentalmente para sistemas de tiempo real, en los que se manejan fuentes externas de datos de alta velocidad y a los que se debe proporcionar alguna respuesta lo suficientemente rpida para manejar el ambiento externo. En este tipo de modelado es importante qu sucede cuando ocurre tal evento. Notacin de los diagramas de transicin de estados Los principales componentes de este tipo de diagrama son los estados y, las flechas o cambios de estado. Los estados se representan con un rectngulo al que se le ha aadido el nombre del estado que simbolizan. Se define como un conjunto de circunstancias o atributos que caracterizan a un objeto en un tiempo dado: forma de ser, condicin,... representa algn comportamiento del sistema que es observable y que perdura durante algn tiempo finito.
46
El DTE se utiliza para desarrollar un modelo de cmo se comportara el sistema si hubiera tecnologa perfecta. Un aspecto de esta tecnologa perfecta sera que el sistema trabajara de manera infinitamente rpida. As cualquier estado observable en el que el sistema se puede encontrar corresponde a periodos en los que el sistema est esperando que algo ocurra en el ambiente exterior o est esperando a que alguna actividad que se est desarrollando en ese momento en el ambiente cambie a otra. Cambios de estado Un sistema que solo existe en un estado es esttico. Pero si un sistema puede tener varios estados, cmo se cambia de un estado a otro? Si se tienen reglas ordenadas que gobiernan el comportamiento del sistema, entonces suelen existir algunos cambios de estado significativos y vlidos.
Los cambios de estado se representan conectando los estados con flechas. Cualquier estado puede tener varios estados sucesores. En este ejemplo no se dice nada acerca de cules son los estados inicial y final del sistema. Este ejemplo representa un sistema estable, que siempre ha estado activo y que siempre lo estar. La mayora de los sistemas tienen un estado inicial y final reconocible. Lo habitual es representar el estado inicial en la cima del diagrama, aunque lo que realmente identifica al estado inicial es la flecha que llega a l de ningn estado, es decir, la ausencia de predecesores. Lo habitual es representar el estado final en la base del diagrama, aunque lo que realmente identifica al estado final es la ausencia de flechas que salen de l, es decir, la ausencia de sucesores. Un sistema tiene un estado inicial y puede tener varios estado finales. Cada estado final es mutuamente excluyente: solo uno de ellos puede ocurrir durante alguna ejecucin del sistema. Se puede suponer que los cambios de estado ocurren instantneamente, o lo que es lo mismo, no se requiere tiempo observable para que el sistema cambie de un estado a otro. Condiciones y acciones Las condiciones causan un cambio de estado y las acciones que toma el sistema cuando cambia de estado deben reflejarse en el DTE, junto a las flechas que conectas los estados relacionados. Una condicin es un acontecimiento en el ambiente externo que el sistema es capaz de detectar y que hace que el sistema cambie de estado. Como consecuencia del cambio de estado, el sistema har una o ms acciones. Las acciones son respuestas devueltas al ambiente externo, o bien clculos cuyos resultados se deben recordar. Construccin del diagrama de transicin de estados Tenemos dos enfoque para realizar un DTE: Identificar todos los posibles estados del sistema y representarlos como cajas separadas. Luego explorar las conexiones con significado (los cambios de estado).
47
Empezar por el estado inicial e ir siguiendo un camino hasta el estado final.
Una vez construido el DTE se deber contestar a las preguntas: se han definido todos los estados? Se pueden alcanzar todos los estados? En cada estado, el sistema responde a todas las condiciones posibles?
48

Apuntes Ay DS

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apuntes Ay DS

Caricato da

Copyright:

Formati disponibili

Apuntes de Anlisis y Diseo de Sistemas

ANLISIS Y DISEO DE SISTEMAS TEORIA GENERAL DE SISTEMAS

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Figura 1. Actividades de un Sistema de Informacin

Seleccionar la mejor Alternativa Figura 2. Procedimiento para la toma de decisiones

CATEGORAS DE SISTEMAS DE INFORMACIN

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Base de Datos Figura 3. Sistema de Procesamiento de Transacciones

Apuntes de Anlisis y Diseo de Sistemas

Sistemas Expertos e Inteligencia Artificial

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

EL PAPEL DEL ANALISTA DE SISTEMAS

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

ESTRATEGIAS PARA EL ANLISIS Y DISEO (DESARROLLO) DE SISTEMAS

Apuntes de Anlisis y Diseo de Sistemas

Construccin del prototipo

Evaluacin del prototipo

Apuntes de Anlisis y Diseo de Sistemas

Figura 4. Mtodo del Prototipo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas 5. 6. 7. 8. 9.

Descripcin del Flujo de Datos

Apuntes de Anlisis y Diseo de Sistemas

Pedido del cliente =

Nombre del cliente =

Telfono = Artculos del pedido disponibles =

Mtodo de pago = Tipo de tarjeta de crdito =

[Banamex | Bancomer | American Express | Master Card | Visa]

Apuntes de Anlisis y Diseo de Sistemas

Figura 6. Ejemplo de una estructura de datos para pedido de cliente

Forma de Descripcin de Elemento

Alfabtico Alfanumrico Fecha

Formato de Entrada: Formato de Salida: Valor por Omisin:

Discreto Criterio de validacin

Continuo Limite superior Limite Inferior

Discreto Valor <999999 Significado

>0 El nmero de cliente debe de pasar una prueba de dgito verificador

Apuntes de Anlisis y Diseo de Sistemas

Figura 7. Ejemplo de Forma de Descripcin de Elemento

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Actividad No Iniciada Actividad Inconclusa Actividad Terminada

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas -

Apuntes de Anlisis y Diseo de Sistemas

Observe el comportamiento de los empleados

Escuche retroalimentacin externa de: Vendedores Clientes Proveedores

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas

Apuntes de Anlisis y Diseo de Sistemas