CAPITULO I La Naturaleza de los Sistemas: Qu es el Anlisis: El Anlisis es el arte de determinar el porqu del problema y diagnosticar las posibles causas.

Naturaleza de los Sistemas: Existen muchos tipos diferentes de sistemas; de hecho, casi todo aquello con lo cual entramos en contacto durante nuestra vida cotidiana es un sistema o bien parte de un sistema (o ambas cosas). Significa esto que debemos estudiar todo tipo de sistemas o intentar convertirnos en expertos en sistemas sociales, bilogos y computacionales? Para nada!. Sin embargo es til organizar los diferentes tipos de sistemas en categoras. Son posibles muchas diferentes formas de categorizar. Empezaremos por dividir todos los sistemas en dos categoras: Sistemas Naturales y Sistemas Hechos por el Hombre. Sistemas Naturales: La gran mayora de los sistemas no estn hechos por el hombre: existen en la naturaleza y sirven a sus propios fines. Es conveniente dividir los sistemas naturales en dos subcategoras bsicas: Sistemas Fsicos y Sistemas Vivientes. Los sistemas fsicos incluyen ejemplos tan variados como: Sistemas Fsicos: * Sistemas estelares: galaxias, Sistemas solares, etc. * Sistemas geolgicos: Ros, cordilleras, etctera. * Sistemas moleculares: organizaciones complejas de tomos. Sistemas Vivientes * Comprenden toda la gama de animales y plantas que nos rodean, al igual que a la raza humana. Sistemas hechos por el Hombre: * Un buen nmero de sistemas son construidos, organizados y mantenidos por humanos, e incluyen: * Sistemas sociales: organizaciones de leyes, doctrinas, costumbres.
1

* Una coleccin organizada y disciplinada de ideas: El sistema de reduccin de los cuida-Kilos, etc. * Sistemas de Transporte: Redes de carreteras, canales, aerolneas, buques cargueros, etc. * Sistemas de comunicacin: telfono, tlex, seales de humo, seales de mano utilizadas por los corredores de bolsa, etc. * Sistemas de manufactura: Fbricas, lneas de ensamblado, etc. * Sistemas financieros: Contabilidad, Inventarios, Bolsa de valores, etc. Sistemas Automatizados: La mayor parte de esta asignatura se concentrar en los sistemas automatizados, es decir, en sistemas hechos por el hombre que interactan con o son controlados por uno o ms computadoras. Una divisin en categoras ms til de los sistemas automatizados es la siguiente: * Sistemas en Lnea * Sistemas de Tiempo Real * Sistemas de Apoyo a decisiones * Sistemas basados en el conocimiento Sistemas en Lnea: Un sistema en Lnea es aquel que acepta material de entrada directamente del rea donde se cre. Tambin es el sistema en el que el material de salida, o el resultado de la computacin, se devuelven directamente a donde es requerido. Una caracterstica comn de los sistemas en lnea es que entran datos a la computadora o se les recibe de ella en forma remota. Otra caracterstica de un sistema en lnea es que los datos almacenados, es decir, sus archivos o su base de datos, usualmente se organizan de tal manera que los componentes puedan ser modificados o recuperados, rpidamente y sin tener que efectuar accesos a otros componentes de informacin del sistema. Dado que un sistema en lnea interacta directamente con personas , es importante que el analista de sistemas planee cuidadosamente la interfaz humanocomputadora.

Sistemas en Tiempo Real: Un sistema computacional de tiempo real puede definirse como aquel que controla una ambiente recibiendo datos, procesndolos y devolvindolos con la suficiente rapidez como para influir en dicho ambiente en ese momento. Principios de sistemas Generales Existen algunos principios generales que son de inters particular para quienes crean sistemas automatizados de informacin, e incluyen los siguientes: * Entre ms especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes. Esto a menudo se utiliza para describir los sistemas biolgicos. Entre ms general sea un sistema, menos ptimo ser para una situacin determinada; pero entre ms ptimo sea, para tal situacin menos adaptable ser a nuevas circunstancias. * Cuanto mayor sea el sistema mayor es el nmero de sus recursos que deben dedicarse a su mantenimiento diario. Los dinosaurios pasaban la mayor parte del su tiempo llenndose de alimento para poder mantener sus enormes cuerpos. Esto tambin se aplica a ejrcitos, compaas, etc. * Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en sistemas menores: Lo ms importante es el hecho de que sugiere que la definicin del sistema que estamos tratando de desarrollar es arbitraria; Pudimos haber escogido un sistema ligeramente menor o mayor. Los sistemas crecen: Un sistema de informacin tpico, por ejemplo, crecer hasta el punto de incluir ms software, ms datos, ms funciones y ms usuarios que los que inicialmente se haba planeado. ACTIVIDADES 1) Qu es un anlisis? 2) Que es un Sistema. A continuacin hable sobre los diferentes sistemas 3) Sistemas naturales 4) Sistemas hechos por el hombre 5) Sistemas automatizados 6) Sistema en lnea 7) Sistema en tiempo real 8) Definicin de anlisis de sistemas informticos
3

CAPITULO II QUE ES EL ANLISIS DE DISEO DE SISTEMAS El Propsito del Anlisis y Diseo El Anlisis es el proceso de determinar qu se necesita hacer, antes de decidir cmo debe hacerse. El diseo es el proceso de determinar cul de muchas posibles soluciones es la mejor para lograr lo que se necesita hacer, respetando las restricciones tecnolgicas y de presupuesto del proyecto. El diseo escoge un cmo especfico para aplicarlo al qu. El Anlisis es el acto de Descubrimiento. El diseo es el arte de compromiso. Papeles del Analista de sistema: Arquelogo y Escribano Innovador Mediador Jefe de Proyecto Arquelogo y Escribano: Es un arquelogo porque descubre cosas, pero al descubrirlas los saca con mucho cuidado. l debe descubrir las cosas donde aparentemente no hay. Muchas veces el usuario no quiere contarnos o no conoce. Muchas veces la poltica de la empresa, no nos permite sacar la informacin sin chocar con alguien por lo tanto se debe quitar las piezas con cuidado, tal como lo hace un arquelogo. Podemos decir que tambin es escribano porque debe documentar todo lo que recolecta, a fin de poder consultar ms adelante. Cualquier cosa que se reclame ms adelante, debe estar documentado. Esta documentacin tiene peso, tanto legal como de ayuda para otros Analistas que quieran participar del proyecto. Innovador: El analista debe ir mucho ms de una simple solucin a un problema de carga de datos, sino que debe ayudar a la empresa a hallar nuevas formas de economizar, automatizar y prestar sencillez para que las operaciones se hagan lo mas transparente y sencilla posible. El analista debe aprovechar toda la tecnologa de la informtica para automatizar e integrar los sistemas (esto hace que las cargas de datos no se dupliquen). Mediador: A veces el analista se encuentra mediando entre administradores y usuarios, propietario y operadores, etc. Esto requiere que el analista use la diplomacia y la negociacin. (mas adelante hablaremos sobre las habilidades de un analista). No debe dejarse engaar por la autoridad que le prestarn para la toma de decisiones, recuerde que debe llegar a un consenso entre las partes.
4

Jefe de Proyecto: La mayora de las veces se asigna al analista para estar en frente de un proyecto, primero por la experiencia que tiene y porque est antes de los programadores y diseadores. El estar en frente de un proyecto implica el manejo de tiempo, personales, control del producto. Etc. Habilidades del Analista: El papel del Analista es ir y encontrar qu problemas existen en el negocio y determinar lo que desean que sucedan quienes estn a cargo del Sistema. Esto se logra haciendo las entrevistas, documentaciones e investigaciones de la empresa. Una de las formas de lograr esto es escribiendo los problemas y convirtindolo en objetivos. (Estudiaremos las tcnicas en otro capitulo). Necesita estar conciente en lo que es posible, factible y prctico en lo que se refiera a la computacin en los negocios. Necesita saber como el negocio hace dinero. En trminos generales el analista es un Investigador, ya que el anlisis es un proceso de descubrimiento. Debe estar desenterrando gemas de datos desconocidos de entre el naufragio de los archivos planos de un sistema heredado, o descifrando jeroglficos de un antiguo algoritmo de algn programador que ya ha muerto. Puede que tambin tenga que conocer frmulas nuevas e inventar nuevas para solucionar problemas. Muchas veces el analista es socilogo que tiene que convivir con cierta especie de gente para entender su dialecto y comprender ms sobre el ambiente. Esto se hace realidad cuando debe comprender y estar de lado del usuario y sufrir lo que ellos sufren para entender sus necesidades. Tambin son mucha importancia las buenas habilidades de comunicaciones. Es importante hacer llegar al usuario final la importancia del nuevo sistema (ya que el usuario generalmente teme al cambio). Tambin puede ser llamado a hacer diplomacia entre dos fracciones del negocio en conflicto y resolver problemas de procedimientos. (esto ltimo puede acontecer porque no son claros las responsabilidades de cada uno Ej. Quien recibe los pedidos de productos a reponer?). Papeles de Un Analista El papel del analista es ir y encontrar qu problemas existen en el negocio y determinar lo que desean que suceda quienes estn a cargo del mismo. Como analista necesita estar consciente en forma muy precisa de la manera en que un negocio hace dinero. Necesita estar profundamente consciente de lo que es posible, factible y prctico en lo que se refiere a la computacin en los negocios. Tambin son de gran importancia las buenas habilidades para la comunicacin. En la fase de anlisis de un proyecto se pasar gran parte del tiempo sacando informacin de los posibles usuarios del sistema, reorganizando lo que aprende y volvindolo a presentar para su validacin.
5

Tal vez sea llamado para hacer diplomacia, resolviendo conflictos y dando soluciones entre facciones del negocio que estn en guerra, o pasar tiempo en el papel de consejero de campamento aliviando el miedo que los usuarios tienen al cambio. Diseador de Sistemas EL diseador de sistemas es quin recibe los resultados de su trabajo de Anlisis: La labor de l es transformar la peticin, libre de consideraciones de tecnologa, emanada de los requerimientos del usuario, en un diseo arquitectnico de alto nivel, que servir de base para el trabajo de los programadores. Explora las diversas soluciones, tomando decisiones bien informadas para llegar a un producto que dejar a los usuarios bien satisfechos. El Diseador es un bicho ligeramente diferente al analista, y debe estar en constante comunicacin con el analista, intercambiando ideas y negociando cambios para hacer posible, factible algunos de los anlisis previamente hechos. El analista debe pasar al diseador los detalles del anlisis para que esta sea retroalimentada. Los desarrolladores son las personas que estn ms en contacto con los programadores. Este tiene a su cargo el cmo va a quedar el sistema para ser presentado al usuario final. El diseo se refiere casi completamente a los compromisos. El diseador se enfrenta con la enorme tarea de mapear los requerimientos del negocio, con la tecnologa disponible. El analista se puede dar el lujo de suponer una tecnologa perfecta. El documenta los requerimientos del usuario como si todos los procesadores fueran infinitamente rpidos y todos los datos estuvieran disponibles instantneamente. Sin embargo, el diseador debe hacer que los deseos y fantasas de los usuarios se ejecuten en el lastimero conjunto de mquinas que pone a disposicin del departamento. Habilidades de un Diseador: Es en parte ingeniero y parte artesano: traza los planos a partir de los cuales servir de base a los programadores para realizar su construccin. (DFD y diccionario de datos). La parte de artesano es porque debe hacer que los planos sean agradables a la vista y que no sea complicado de entender. Un buen diseador es creativo: debe ofrecer creaciones que servir para solucionar problemas tcnicos y operacionales (Ej. Un sistema de caja que pueda atender todos los ingresos y egresos, para luego tirar los asientos de contabilidad). Lleno de recursos e inteligente para evaluar opciones entre soluciones que no son perfectas: debe poder optar por soluciones que ayuden al usuario y que no genere muchos costos. Ej. De que nos sirve cargar un lote de datos que solamente servirn para ser listado y luego borrado (para eso se pueden usar planillas electrnicas).

Debe tener un buen entendimiento de las capacidades del ambiente de destino, para disear sistemas que aprovechen sus fortalezas y eviten sus fallas ms notorias: Esto requiere que el analista vivencie todas las operaciones que van a ser automatizadas, absorbiendo los problemas, complejidades y polticas que rigen dichas operaciones. Qu se necesita para que un Proyecto Cliente/Servidor sea exitoso EL secreto del desarrollo exitoso en los ambientes Cliente/Servidor multiplataforma actuales en realidad no es ningn secreto. Toma a la gente adecuada, a la administracin sensata y a una buena metodologa. La gente adecuada La clave para reunir a un equipo exitoso no solamente es contratar a la cantidad necesaria de personas inteligentes y lanzarlas ante el problema. En vez de ello, lo que hay que hacer, es construir una matriz de las habilidades necesarias a lo largo de la duracin del proyecto y determinar cules se necesitan y en qu momento. La gran complejidad del ambiente Cliente/Servidor actual nos fuerza a reconocer que no podemos apoyarnos completamente en tcnicos con conocimientos generales. Necesitamos de gente que tenga grandes habilidades en reas que tienes curvas de aprendizaje amplias y con gran pendiente. Administracin Slida de Un Proyecto La labor del Gerente del proyecto es planear y asignar el trabajo, medir el avance continuamente y ajustar el plan con base en sus mediciones. Esta es una tarea imposible a menos de que se tenga algn plan contra el cual medir el avance. Mientras que los analistas, diseadores y desarrolladores individuales son responsables del dominio y la ejecucin de la ejecucin de las tcnicas, el gerente de proyecto sirve como la fuerza conductora para ordenar las tareas en una metodologa coherente a fin de satisfacer los objetivos del proyecto. Ciclos de Vida de un Proyecto Concepto Las organizaciones de procesos de datos tienden a ser relativamente informales. Los proyectos de desarrollo de sistemas nacen de conversaciones entre el usuario y el administrador del proyecto (que puede ser el analista, el programador, el operario y el conserje), y el proyecto procede desde el anlisis hasta el diseo e implementacin sin mayor alboroto. Sin embargo, en las organizaciones ms grandes, las cosas se llevan a cabo de manera mucho mas formal. Cada vez son ms las organizaciones grandes y pequeas que estn adoptando un ciclo de vida uniforme y nico para sus
7

proyectos. Esto se conoce como el plan general del proyecto, la metodologa del desarrollo del sistema o, simplemente, La forma en la que hacemos las cosas aqu. Existen tres objetivos principales: Definir las actividades a llevarse a cabo en un proyecto de desarrollo de sistemas Lograr la congruencia entre la multitud de proyectos de desarrollo de sistemas en una misma organizacin Proporcionar puntos de control y revisin administrativos de las decisiones sobre continuar o no con un proyecto Tipos de ciclos de Vida de un Proyecto Ciclo de Vida del Proyecto clsico El Ciclo de Vida semiestructurado El ciclo de vida Estructurado del proyecto El ciclo de Vida de Prototipos El Enfoque de Cascada La cascada tradicional tiene cierta lgica. Se hace un plan para un proyecto y luego se realiza el anlisis de l dominio del problema. Cuando se declara la victoria en el anlisis comienza el diseo, y una vez que est terminado el diseo comienza la constriccin. Las salidas de una etapa son las entradas para la siguiente, y a esto se debe la metfora de Cascada. La cascada tiene un atractivo ordenado que hace que sea un modelo especialmente conveniente para la enseanza de las tcnicas de Ingeniera de Software. Las metodologas de cascada sufren de mala analoga. El agua, siendo vctima de la gravedad, no tiende a tratar los regresar hacia arriba de la colina para dar otro paso por su propia cada. De manera similar, la gente tiende a tratar los regresos hacia el anlisis o el diseo como una falla en vez de ser un paso hacia delante.
Planeacin

Anlisis

Diseo

Construccin

El Enfoque Espiral El modelo espiral fue desarrollado originalmente en el Pentgono como un mtodo para controlar los costos desbocados de armas masivas y proyectos de desarrollo de sistemas de defensa. Despus de cada fase se evala la viabilidad del trabajo terminado junto con una estimacin refinada para las siguientes etapas. Qu es lo que hace que una metodologa sea buena Una buena metodologa arma a sus practicantes con un juego de herramientas de tcnicas confiables y repetibles que se adecuan particularmente bien a los problemas que estn tratando de resolver. Una metodologa balanceada incluye tcnicas que le dan a los analistas y diseadores una amplia cobertura de todos los aspectos que deban modelar, pero les permiten desviar su nfasis de modelado para adaptarse a la tendencia del problema de negocios. Caractersticas de buenas metodologas de diseo El diseo consiste en decidir en que debe construirse para satisfacer los requerimientos de los usuarios. Las buenas metodologas de diseo comparten las siguientes caractersticas: El buen diseo debe motivar la toma de decisiones ayudando a evaluar alternativas. El diseo necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse El diseo debe ser verificable antes de su construccin Una buena metodologa de diseo crea productos diferenciados que son mensurables El diseo debe ser fcilmente aprovechado en el producto final Caractersticas de buenas metodologas de Anlisis El Anlisis consiste en comprender y documentar las necesidades del usuario. Una metodologa de anlisis exitosa presentar las siguientes caractersticas: Una tcnica de anlisis debe motivar el acto del descubrimiento proporcionando un marco de trabajo en el que el analista puede escribir lo que ellos saben y evaluar lo que tienen que aprender.
9

La metodologa de anlisis debe ser completa respecto a que cubra adecuadamente cada uno de los aspectos del problema de negocios. Los resultados del anlisis necesitan se verificables La metodologa de anlisis tambin debe crear unidades medbles para el gerente del proyecto El qu tanto deba ser fcilmente convertible en un diseo y, por lo tanto, pueda tener tendencia hacia un tipo de diseo particular. ACTIVIDADES

1) 2) 3)

Habla sobre El propsito de anlisis y diseo Describa Las habilidades de un analista Describa Las habilidades de un diseador

4) Que se necesita para que un proyecto cliente/servidor sea exitoso

5)

Habla sobre la Administracin slida de un proyecto

6) Describe la Metodologa slida (cascada y espiral) 7) Que es lo que hace que una metodologa sea slida 8) Caractersticas de buenas metodologas de diseo 9) Caractersticas de buenas metodologas de anlisis

CAPITULO III LOS QUE PARTICIPAN EN EL ANLISIS DE SISTEMAS Usuarios: Es la persona ms importante en el juego de los sistemas, es alguien que el analista conoce como usuario. Es aqul para quin se construye el Sistema; Es la persona a la que tendr que entrevistar, a menudo con gran detalle, a fin de conocer las caractersticas que deber tener el nuevo sistema para poder tener xito. Debe hacerse notar que la mayora de los usuarios no se refieren a s mismos como usuarios. En algunas organizaciones se evita ese problema utilizando el trmino cliente o dueo para identificar al usuario. El usuario es el dueo en el sentido de que es l quien recibe el sistema cuando se termina de crearlo. Y el usuario es el cliente por lo menos en dos sentidos importantes: 1) como en muchas otras profesiones, el cliente siempre tiene la razn, sin importar lo exigente, desagradable o irracional que pueda parecer 2)el cliente es el que a fin de cuentas paga el sistema y usualmente tiene el derecho de rehusarse a pagar si no est conforme con el producto. En la mayora de los casos es fcil identificar a los usuarios, de manera caracterstica, es aquel que formalmente solicita un sistema. En una organizacin pequea, esto suele ser un procedimiento muy informal; pudiera consistir simplemente que el usuario llame por telfono al analista. Sin embargo, hay un gran nmero de situaciones en las que no se conoce la identidad del verdadero usuario o bien en las que hay poca oportunidad de que este interacte con el analista. An si el sistema se desarrolla por completo dentro de una sola organizacin, el verdadero usuario pudiera nombrar a un representante para trabajar con el analista, por estar demasiado ocupado personalmente con otros asuntos. Muchas veces no se identifica con certeza al verdadero usuario. En este caso hay una gran posibilidad de malos entendidos. Para poder evitar esto se deben tener en cuenta dos puntos: Siempre que sea posible, debe tratar de establecer contacto directo con el usuario, es importante tener reuniones con la persona que en ltimo trmino recibir el sistema. De hecho suele ser an mejor si el usuario forma parte activa del equipo encargado del proyecto. En muchas organizaciones, el usuario suele ser el gerente de proyectos; incluso, algunos argumentan que el usuario mismo debera llevar a cabo el proyecto. Si no es posible comunicarse con el usuario, la documentacin generada por el Analista se vuelve ms importante.

Tipos de Usuarios No todos los usuarios son responsables de los mismos eventos del negocio y, por lo tanto, no todos los usuarios necesitan los usuarios necesitan todo el software que se distribuye. Suponiendo que hay muchas aplicaciones que ejecutan sobre la misma base de datos, el diseador tiene la alternativa de distribuir una gran aplicacin a todos o muchas aplicaciones pequeas solamente a quienes las necesitan. La segunda alternativa tiene algunas ventajas. Cuando se divide una aplicacin cliente grande en varias partes, el software cliente ocupa menos espacio de disco. Cuando el usuario solicita mejoras al software se pueden aislar los cambios en un ejecutable particular. La ventaja es de se molesta a menos usuarios con una mejora de software cuando se libera la aplicacin mejorada, y no se necesitan probar las partes de la aplicacin que no son efectuadas. La desventaja es que toda esta particin para asegurarse de que la IT est muy consciente de cules partes de la aplicacin estn en cada PC de usuario. Para los negocios que tienen una mezcla de aplicaciones que comparten la misma base de datos, que puede ser construida por diferentes grupos dentro de la IT o contener algunos paquetes comprados, tal sea necesaria una solucin de servidor pesado para asegurarse de que los datos estn encapsulados adecuadamente con las reglas del negocio adecuadas. Uno de los errores ms frecuentes que cometen en el campo de las computadoras sobre todo los programadores y a veces tambin los analistas, es suponer que todos los usuarios son iguales. La palabra usuario, como sustantivo singular, da a entender que el analista slo tendr que interactuar con una persona. Aun cuando sea obvio que deber intervenir ms de un usuario, se tiene la tendencia a pensar en ellos como grupo de humanos amorfo y homogneo. Decir simplemente que un usuario difiere de otro es insuficiente: claro, tienen diferentes personalidades, diferente preparacin, diferentes intereses, etc. Pero tambin hay diferencias importantes, que usted debe tener en mente al trabajar como analista. He aqu dos maneras de clasificar a los usuarios: 1.) Por categora de trabajo o nivel de supervisin 2.) Por nivel de experiencia en el procesamiento de datos. Clasificacin de los usuarios por categora de trabajo: En un proyecto tpico de anlisis de sistemas se pasar una considerable cantidad de tiempo entrevistando a los usuarios para determinar los requerimientos del sistema. Pero Cules usuarios?. a qu nivel? Desde luego, esto depender del proyecto y de las polticas de su organizacin. Sin embargo, habitualmente tendr que interactuar con individuos de tres categoras de trabajo: Usuarios operacionales, Usuarios Supervisores, y Usuarios Ejecutivos. Usuarios Operacionales: Tienden a poseer un panorama "Local" del sistema; por lo general son conocedores del trabajo especfico que realizan. Sin embargo a
1

menudo no estn familiarizados con el panorama general; es decir, puede ser que tengan dificultad para describir cmo es que su actividad propia encaja dentro de la organizacin global o para describir el carcter global de su organizacin. Esto rara vez se de a torpeza, sino a que no tienen inters en el asunto. O tambin pudiera reflejar que el usuario supervisor no les haya dado a conocer nada de eso porque as lo prefiere. Los usuarios de este nivel se preocupan mucho por las funciones que tendr, pero es ms probable que se preocupen por los detalles de la interfaz humana. Por ejemplo Qu tipo de teclado estar usando?, es como el teclado de la mquina de escribir que he estado usando durante aos?, Cmo aparecern las cosas en la pantalla?, se podrn leer los caracteres en la pantalla?, etc. Estos son los detalles que el supervisor del usuario de nivel operacional pudiera o no tomar en cuenta, pero cmo se podr imaginar, son vitales para el xito de un sistema y se tendrn que elaborar. Los usuarios operacionales suelen pensar en los sistemas en trminos fsicos, es decir en trminos de la tecnologa de puesta en prctica que comnmente se utiliza para implantar o hacer uso de del sistema, o en trminos de la tecnologa que imaginan que pudiera utilizarse. Las discusiones abstractas acerca de funciones y tipos de datos puede resultar difciles; de aqu que el analista de sistema pudiera requerir hablar con el usuario exclusivamente en trminos familiares. Luego, con otra actividad aparte, puede traducir esta descripcin fsica a un modelo esencial, es decir, a un modelo de lo que el sistema debe hacer independientemente de la tecnologa usada para realizarlo. Usuario supervisor: usualmente administran a un grupo de usuarios operacionales y son responsables de sus logros.(obviamente se puede imaginar, ms de un nivel de usuarios supervisores en una organizacin grande.). Muchos de ellos son usuarios operacionales que han sido promocionados. Por eso, usualmente estn familiarizados con el trabajo de sus subordinados operacionales y se puede suponer que estarn de acuerdo con sus necesidades, preocupaciones y perspectivas. Sin embargo, esto no siempre es as. Dado que el mercado ha cambiado, la economa y la Tecnologa han cambiado tanto, el trabajo operacional de hoy en da puede diferir mucho de lo que era hace 20 aos. El Usuario supervisor suele actuar entre el analista y el usuario operacional, arguyendo que estos ltimos estn demasiados ocupados como para perder su tiempo hablando con el analista. El usuario supervisor a menudo piensa en los mismos trminos fsicos que el usuario operacional, y su perspectiva a menudo resulta tan local como la de este ltimo. Desde luego, uno esperar que una persona de nivel administrativo tuviera un panorama ms global; como corolario, pudiera resultar que el usuario supervisor ya no recuerde una de las detalladas polticas de negocios que los usuarios operacionales llevan a cabo. Los usuarios supervisores son los que estn ms en contacto para los requerimientos y las polticas de la empresa que su sistema deber realizar.

El Usuario Ejecutivo: Generalmente se interesan ms por el panorama global del sistema. En general no se involucran directamente con el desarrollo del sistema, a menos que el proyecto sea tan amplio y tan importante que tenga un impacto de primer orden en la empresa. En un proyecto normal, el usuario suele estar dos o tres niveles ms arriba de la accin asociada con el proyecto. Aspectos sobre el usuario ejecutivo: 1. Puede proporcionar la iniciativa para el proyecto, pero es ms probable que sirvan slo como autoridad para financiar las solicitudes que se originan en niveles ms bajos de la organizacin. 2. Por lo comn, no fueron previamente usuarios operacionales o, si lo fueron, habr sido hace tanto tiempo, que cualquier experiencia que tengan al respecto ser obsoleta. Por ello no se encuentran en posicin que le permita definir los requerimientos del sistema para aquellos que lo estarn manejando cotidianamente. 3. Se preocupan ms por los detalles estratgicas y las ganancias / prdidas a largo plazo. De aqu que, por lo regular estn menos interesados en asuntos operacionales tales como abatir los costos de transaccin o ahorrarse tres oficinistas. 4. Se interesan ms en el panorama local. En consecuencia, suelen no interesarse por los detalles. 5. En realidad no estarn interesados en los modelos fsicos del sistema y se preguntarn por qu se toman la molestia de mostrrselos. Clasificacin de los Usuarios por nivel de experiencia: Amateur Es aquel que jams ha visto una computadora y que exclama a todo pulmn y con frecuencia que l no entiende todo ese asunto de las computadoras. Este tipo de usuario suele ser un empleado o negociante de mediana edad que ha sobrevivido felizmente a lo largo de 16 aos de educacin y de otros 10 o 20 aos en el empleo antes de que se introdujeran las computadoras. Sin embargo tambin es comn encontrar usuarios jvenes, que encuentran las computadoras aburridas, intimidantes o inaplicables en sus vidas. En realidad el verdadero problema con el usuario amateur es un tanto ms sutil: puede se que se encuentre difcil de entender el lenguaje que el analista usa para describir las caractersticas, funciones y opciones que ofrece el sistema que se deber implantar, aun cuando se evite la terminologa obviamente relacionada con las computadoras. Novato presuntuoso Es una persona que ha tenido que ver con uno o dos proyectos de desarrollo de sistemas o (peor an) es un usuario que posee una computadora personal y que ha escrito uno o dos (uf!) programas en Basic. Por lo comn, alega saber exactamente lo que quiere que el sistema haga y suele sealar todos los errores que el analista cometi en el ltimo proyecto. Esto est bien, excepto por una cosa: a menudo se enzarza
1

demasiado en discusiones sobre la tecnologa especifica que se va a usar para realizar el Sistema. Esta clase de usuarios suele sugerir por adelantado que es lo que deberamos hacer, sin saber exactamente cuales son los lenguajes tcnicos adecuados. Comnmente esta clase de personas suelen confundir las palabras tcnicas y mezclarlas, produciendo una peligrosa situacin hacia el desastre. Otras veces sugieren cosas que son inalcanzables y a veces peor, no se usa ms o no es la recomendable. Usuario que realmente entiende el Anlisis de Sistemas Hay algunos usuarios que realmente entienden el Anlisis de sistemas, y tambin la tecnologa de las computadoras (adems de su propia profesin). Es un placer trabajar con tales personas; de hecho el nico problema pudiera ser que el usuario y el analista obtengan tal placer de la discusin sobre herramientas y tcnicas del anlisis de sistemas, que se olviden por completo de que su verdadero objetivo es implantar un sistema. Administracin La Informacin como recurso de las organizaciones: De tiempo atrs, las organizaciones han reconocido la importancia de una administracin adecuada de los recursos bsicos, tales como la mano de obra y las materias primas. Hasta ahora es cuando la informacin tiene connotacin de recurso primordial. Los responsables de la toma de decisiones empiezan a considerar que la informacin, ya no es un producto exclusivamente colateral de la operacin de la Empresa, sino que en s, es uno de los promotores de las misma. La informacin puede llegar a ser el elemento decisivo, que en un momento dado, determine el xito o el fracaso de un negocio. Administracin de la Informacin como recurso: Con el fin de lograr la mxima utilidad de la informacin, esta debe administrarse de manera correcta, como ocurrira con cualquier otro de los recursos de la empresa. Los directivos deben entender que existen costos que se asocian con la produccin, distribucin, seguridad, almacenamiento y recuperacin de la informacin. Administracin de la informacin generada por computadora: La disponibilidad actual de las computadoras ha generado todo incremento y una diversificacin de la informacin, tanto para la sociedad en general, como para los negocios en particular. La administracin de la informacin que se genera por computadora, difiere en diversas formas de aquella que se obtiene manualmente. A menudo, se tiene una mayor cantidad de informacin si sta se genera utilizando sistemas computacionales; los costos para crear y mantener la informacin computarizada, son aparentemente mayores; la informacin que genera la computadora puede llegar a multiplicarse a velocidades impresionantes. Con frecuencia la informacin
1

que se genera por computadora se trata con menos escepticismo que la obtenida por otros medios. El trmino Administracin es bastante amplio; de hecho, es probable que el analista de sistemas entre en contacto con diversos tipos de administradores:
1.

Administradores de Usuarios: son administradores que estn a cargo de varias personas en el rea operacional donde se va a implantar el nuevo sistema. Por lo general son administradores de nivel medio que desean sistemas que produzcan una variedad de informes internos y de anlisis a corto plazo. Los informes internos suelen ser informes financieros, de fallas y otros por el estilo. Administradores de Informtica: Son las personas encargadas del proyecto en si de sistemas, y los administradores de nivel superior encargados de la administracin global y distribucin de los recursos de todo el personal tcnico de la organizacin de creacin o desarrollo de sistemas. Administracin general: Son los administradores de nivel superior que no estn directamente involucrados con la organizacin de informtica ni son de la organizacin usuaria. Pudiera ser el presidente de la organizacin o el jefe de administracin financiera (el contador, el director de finanzas, etc.). Generalmente se interesan ms bien por los sistemas de planeacin estratgica y de apoyo a decisiones. A pesar de que la administracin superior si requiere informes financieros internos, no suele necesitar la cantidad de detalles que ocupan los administradores usuarios.

2.

3.

La principal interaccin entre el Analista y todos los Administradores tiene que ver con los recursos que se asignarn al proyecto. Es tarea del Analista identificar y documentar los requerimientos del usuario y las limitaciones dentro de las cuales se tendr que implantar el sistema. Hay varios puntos que conviene tener en mente acerca de los administradores: a) Cuanto ms alto nivel ocupen, menos probable es que sepan de la tecnologa de las computadoras. Esto no debe afectarle a usted como analista (es ms fcil la labor de los diseadores de sistemas), pero debe recordar que ha de concentrarse en tratar de las caractersticas esenciales del sistema cuando est hablando con ellos. Estas caractersticas esenciales se refieren a cmo el sistema le ayudar a administrar su negocio y el ahorro de dinero. b) Las metas y prioridades de la administracin pudieran entrar en conflicto con las del usuario, sobre todo los usuarios operacionales y los usuarios supervisores. La administracin pudiera incluso querer imponerles un sistema y obligarlos a usarlo. Esta clase de conflictos puede ser detectado ya en las entrevistas, cosa que el analista pueda intervenir y llegar a un equilibrio adecuado.

c) Una variante de lo anterior es la siguiente: pudiera se que la administracin no est dando los recursos, los fondos o el tiempo que los usuarios crean necesarios para implantar un sistema efectivo. Es cmodo para el analista y el usuario, en este caso, responder a esto que la Administracin no entiende, pero a menudo se trata de una decisin consciente y calculada. En estos casos se deben dialogar y resolver el problema negociando, ya sea el tiempo, el costo y lograr as un objetivo en comn. (no siempre lo ptimo es posible, y lo posible no siempre es lo ptimo).
d)

El trmino administracin da a entender un grupo homogneo de personas que piensan de la misma manera; desde luego, la realidad suele ser diferente. Los administradores tienen diferentes puntos de vistas y opiniones, y a menudo tienen diferentes metas y objetivos. Discuten y compiten unos con otros. Por esto, pudiera suceder que algunos miembros de la administracin estn a favor y otros en contra. Despus de esto es posible que el proyecto de su sistema muera. Los administradores son muy necesarios para guiarnos en la complejidad de los procedimientos administrativos, pero es difcil en el momento de aplicar las normas de operacin e implementacin del nuevo sistema

e) Tambin es cmodo suponer que una vez que la administracin toma una decisin colectiva acerca de un determinado proyecto se atiene a dicha decisin. Sin embargo, no necesariamente sucede as: pudiera que fuerzas externas obliguen a la administracin a acelerar determinado proyecto, a quitarle recursos o, de plano, abandonarlo. Esto suele causar una depresin emocional enorme a los que intervienen en el proyecto, incluyndolo a usted como analista. La relacin entre su proyecto de desarrollo de sistemas y la administracin pudiera depender en gran medida de la estructura administrativa global de su organizacin, sobre todo de la relacin de las actividades del desarrollo de sistemas con el resto de la organizacin. De todo esto podemos deducir que la administracin forma una parte decisiva en el anlisis que va a realizar, desde luego, no siempre nuestro sistema ser algo comercial, pero en la gran mayora de las empresas existen y no podemos desaprovecharlos. A medida que entienda el mecanismo administrativo, tambin entender de donde vendr la informacin y hacia quin ir dirigido el resultado de esa informacin procesada o almacenada. Es fundamental que se entienda bien cual es el mecanismo y tambin como la empresa hace dinero para que el sistema tenga el mayor beneficio posible. Para que empiece a entender la empresa, puede usted pedir un organigrama de la empresa. Auditores profesionales de control de calidad Segn sea el tamao de su proyecto y la naturaleza de la organizacin para la que trabaja, Pudiera haber Auditores (Personal de Control de Calidad o miembros del departamento de Normas o Estndares) , participando en su proyecto.
1

El objetivo general de este equipo, es asegurar que su sistema se desarrolle de acuerdo con diversos estndares o normas externos (es decir, externos a su proyecto). Estos estndares debe estar sujeto a las normas de la empresa, cumpliendo con el objetivo principal. Esto si su proyecto fuera a nivel local, de lo contrario debe aplicarse en forma ms global. Por ejemplo: podemos citar el Libro de IVA Compras y El Libro de IVA Ventas, Contabilidad Gral. Etc. Hay problemas que debe prever, cuando est trabajando con auditores, personal de control de calidad o miembros del departamento de normas o estndares: 1. A menudo no se involucran sino hasta el final del proyecto. Despus de que se ha terminado con el trabajo del anlisis de sistema, el diseo y la programacin, cuando se ha comenzado con la prueba formal. A estas alturas, es muy difcil hacer cambios importantes en el sistema. 2. A menudo estn familiarizados con alguna notacin o formato antiguos para la documentacin de requerimientos de sistemas (diagramas de flujo). Para eso, es importante asegurarse de que los modelos Tomemos las experiencias de nuestro mercado; la mayora de las empresas se encuentran auditando los sistemas porque no saben en que situacin se encuentran sus sistema, tanto si el sistema est terminado o en desarrollo. En el primer caso se debe entender que se est usando a la auditoria para detectar qu est funcionando mal, porque el sistema est completo pero no arroja los resultados esperados. Para el segundo caso, son los Analistas o los desarrolladores, que, no comunicando el avance de los sistemas, los directivos sospechan de que su sistema no se est desarrollando, como fue hablado o planificado. Todo esto hace que el auditor tome especial importancia, para mediar entre las partes y hacer un estudio del proyecto actual e informar de la situacin real. Esta informacin puede llevar al auditor a recomendar la suspensin del proyecto, o recomendar medidas correctivas del caso. Adems de las auditorias de control de proyecto, tambin podemos hablar sobre los controles que debe realizar el sistema en cuestin de control de fraudes, accesos, control de carga, integridad de los datos, consistencia, operaciones no permitidas a ciertos usuarios y seguridad de los Archivos (Respaldos y recuperacin) y tambin la seguridad fsica de toda la informacin.

El Analista de Sistemas Este es Ud. El analista de sistemas es el personaje clave en cualquier proyecto de desarrollo de sistema. Los Programadores El programador es quin recibe del Diseador los requerimientos de hardware y Software que se usar para poner en prctica el sistema. Pero, quienes son estos personajes que se escuchan tan a menudo y con algunos mitos sobre ellos: Son los responsables de construir el sistema que el diseador y el analista, han soado, son los constructores de sus casas, el que sabe como y donde poner los comandos, en las computadoras. En el mejor de los casos, los programadores, no tienen mucho contacto con los Analistas. Digamos que los diseadores, son los que actan de intermediario entre ellos. Es probable que el analista de sistemas, est asignado ya a otro proyecto, cuando el programador, empiece a trabajar. Esto quiere decir que el analista de sistemas, es el primero en hacer el trabajo y luego el programador. No se puede decir que el analista y el programador, nunca se encuentren, pero las posibilidades, son casi nulas. En nuestro mbito de la informtica, cada uno decide, que es los que ms le gusta, y es as que los programadores (por ms que se hayan recibido de analistas), deciden quedarse en el mundo de la programacin, y por que no, es un mundo fascinante, lleno de descubrimientos, nuevos y con constantes actualizaciones, nuevos lenguajes que nacen, se actualizan, y a medida que uno va tratando con ellos se pueden encontrar soluciones para cada exigencia de las empresas. Logros que son recompensados con el entusiasmo de quienes lo manejan. Casos en los cuales es posible que exista algn contacto entre Analista y Programador: a) En proyectos pequeos: en donde los papeles del analista, diseador y programador se combinan, de tal manera que el analista hace el mismo trabajo de analista y diseador. b) El analista hace de administrador del proyecto, por lo tanto, tiene contacto con el programador para guiar y disipar las dudas de la construccin del sistema. c) A menudo el programador descubre algunas ambigedades, o requerimientos que no estaban al descubierto. d) Cuando el programador debe dar informacin del sistema anterior, que ser reemplazado, por ser obsoleto Personal de Operaciones El personal de operaciones es el responsable del centro de computo: La red de telecomunicaciones, la seguridad del Hardware y del software, adems de la ejecucin de los programas, el montaje de los discos y el manejo de la salida de las impresoras.
1

Sin embargo hay ms de lo que parece a simple vista: El Analista debe entender las restricciones impuestas al nuevo sistema por el personal de operaciones, pues esto influye en la especificacin detallada que produzca. Es importante entender el ambiente en el que se desenvuelve el operador para poder agilizar su trabajo (porque de eso se trata). Por ejemplo: supongamos que una persona es el encargado de recibir los productos y cargar las facturas, para su posterior pago. Deberamos pedir a esta persona que cargue tambin los nuevos productos que estn entrando por primera vez?. NO, por lo tanto, se tiene que buscar soluciones para que esto sea factible, en modo operativo y administrativo. Recuerde, usted debe agilizar la informacin, no complicarla. Si ponemos a un personal que tenga que hacer ms de una actividad, probablemente exista sobrecarga de informacin, y eso puede causar errores de carga. Como as tambin debemos cuidar que no exista la carga en dos partes a la vez. Cuando un personal de operaciones tiene algn problema, este, no atiende por los problemas de organizacin, y generalmente, el culpable, son los informticos, por eso es importante la colaboracin de estas personas, para que puedan, sugerir, probar y aprobar la funciones del nuevo programa, esto debe hacerse con retroalimentacin. Existen en otras compaas muchas ms grandes, donde el personal de operaciones existe para las pruebas del nuevo sistema, estos personales de pruebas son llamados, Personales de Produccin. Para otros casos son contratados, esta personas para intermediar, entre el usuario final y el programador para capturar todas las deficiencias y sugerencias al programa que se est implementando. ACTIVIDADES
1) Que son los Usuarios 2) Menciona la Clasificacin de los usuarios 3) Habla sobre los usuarios por categora de trabajo o nivel de supervisin 4) Habla sobre los usuarios por nivel de experiencia en el procesamiento de datos 5) Menciona los aspectos fundamentales sobre el usuario ejecutivo 6) Habla sobre Administracin 7) Explica los diferentes tipos de administradores 8) Cual es l objetivo principal de los Auditores profesionales de control de calidad 9) Menciona los problemas que se pueden tener cuando se esta trabajando con auditores 10) Quien es el Analista de Sistemas 11) Que funcin desempea los Programadores 12) Mencione los casos en los cuales es posible que exista algn contacto entre Analista y Programador

13) Cite las responsabilidades del Personal de Operaciones.

CAPITULO IV DIAGRAMA DE FLUJOS DE DATOS Introduccin Esta es una Herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre si por conductos y tanques de almacenamiento de datos. Empezaremos nuestro estudio de los DFD examinando los componentes de un diagrama tpico de flujo de dato: el Proceso, el flujo, el Almacn y el terminador. Tenga en mente que el DFD es tan slo una de las herramientas de modelado disponibles y que nicamente proporciona un punto de vista de un sistema, el orientado a funciones. Los Componentes de un DFD El Proceso: El Primer componente del DFD se conoce como Proceso. Los sinnimos comunes son burbuja, funcin o transformacin. El proceso muestra una parte del sistema que transforma entradas en salidas; es decir, muestra como es que una o ms entradas se transforman en salidas. El proceso se representa grficamente como un crculo. Algunos Analistas prefieren usar valo o rectngulo con esquinas redondeadas, y otros prefieren usar un rectngulo. La diferencia entre estos es puramente cosmticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funciones de un sistema. El nombre para una burbuja debe ser una frase verbo-objeto tal como validar entrada o Calcular Impuesto.

Harina Hornear Pastel Azucar Pastel

El flujo: Un Flujo se representa grficamente por medio de una flecha que entra o sale de un proceso; el flujo se usa para describir el movimiento de bloques o paquetes de informacin de una parte del sistema otra. Para ello, los flujos representan datos en movimiento.
Informacin

En la mayora de los sistemas que modele como analista , los flujos realmente representan datos, es decir, bits, caracteres, mensajes, nmeros de punto flotante y los diversos otros tipos de informacin con los que la computadora puede tratar. Tambin puede escogerse para modelar una lnea de ensamblado y que no haya componentes computarizados. En tales casos, los paquetes o fragmentos mostrados por los flujos sern tpicamente materiales fsicos. Ntese tambin que los flujos muestran la direccin; una cabeza de flecha en cualquier extremo, indica si el dato se est moviendo hacia adentro o hacia fuera. Cuando el Flujo viaja desde un proceso a un almacn se dice que la informacin se est almacenando, cuando sale de un almacn, hacia un proceso se dice que est leyendo. Y cuando tiene ambos se dice que es una actualizacin. Los flujos de datos puede Divergir o converger en un DFD, conceptualmente, esto es algo as como un Ro principal que se divide en varios ms pequeos, o varios pequeos que se unen. El Almacn: El Almacn se utiliza para modelar una coleccin de paquetes de datos en reposo. Se denota por dos lneas paralelas. De modo caracterstico el nombre que se utiliza para identificar el almacn es el plural del que se utiliza para los paquetes que entran y salen del almacn por medio de los flujos.

PEDIDOS

Para un analista con conocimientos de proceso de datos es tentador referirse a los almacenes como archivos o bases de datos. Pero un almacn tambin pudiera consistir en datos almacenados en conjuntos de fichas, cajas de cartn, nombres y domicilio, directorio, o diversos archivos de un archivero. Aparte de la forma fsica que toma el Almacn , tambin existe la cuestin de su propsito. existe el sistema por causa de un requerimiento fundamental del usuario o por algn aspecto conveniente de la realizacin del sistema?. En el primer caso, la base de datos existe como un rea de almacenamiento diferida en el tiempo, necesaria entre los procesos que ocurren en momentos diferentes. El Almacn representa datos en reposo y si existe un almacn entre dos procesos es porque existe un tiempo para el segundo. O sea que el segundo no depende del primero, solamente depende de la informacin almacenada. El terminador: El siguiente componente del DFD es un Terminador; grficamente se representa como un rectngulo. Los terminadores representan entidades externas con las cuales el sistema se comunica. Comnmente un terminador es una persona o un grupo, por ejemplo, una organizacin externa o una agencia
2

gubernamental, o un grupo o departamento que est dentro de la misma compaa u organizacin, pero fuera del control del sistema que est modelando. Existen tres cosas que debemos recordar acerca de los terminadores: Son Externos al sistema que se est modelando; los flujos que conectan los terminadores a diversos procesos (o almacenes) en el sistema representan la interfaz entre l y el mundo externo. 2. Como consecuencia, es evidente que ni el analista ni el diseador del sistema estn en posibilidades de cambiar los contenidos de un terminador o la manera en que trabaja. En el lenguaje usado por diversos libros de texto clsico sobre anlisis estructurado, el terminador est fuera del dominio del cambio. 3. Las relaciones que existan entre los terminadores no se muestran en le modelo de DFD. Pudieran existir de hecho diversas relaciones, pero por definicin, no son parte del sistema que se est estudiando.
1.

GUIA para la Construccin de un DFD Existen un nmero de reglas adicionales que se requieren para poder utilizar un DFD con xito. Algunas de estas reglas Ayudarn para no elaborar DFD errneos (por ejemplo, incompletos o lgicamente inconsistentes). Algunas de las reglas tienen la finalidad de ayudarle para que dibuje un DFD grato a la vista, y que, por tanto, tenga ms probabilidades de que lo lea con cuidado el usuario: Escoger nombres con significado para los procesos, flujos, almacenes y terminadores. Si podemos evitar nombres de personas (o de grupos) y papeles polticos, entonces podemos etiquetar los procesos de tal manera que se puedan identificar las funciones que el sistema est llevando a cabo. Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo-objeto. Es decir, escoja un verbo activo (un verbo transitivo, uno que tenga objeto) y un objeto apropiado para formar una frase descriptiva para el proceso. Nombres adecuados para procesos: 1. 2. 3. 4. Calcular trayectoria del proyectil Producir informe de Inventario Validar Nmero telefnico Asignar estudiantes a la clase

Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de un vocabulario que tenga algn significado para el usuario. Esto suceder de manera muy natural si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algn entendimiento mnimo de la materia de aplicacin subyacente.

Numerar los procesos. Como una manera conveniente de referirse a los procesos en un DFD, muchos analistas numeran casa burbuja. No importa mucho cmo se haga esto, mientras haya constancia en la manera de aplicar los nmeros. La numeracin no implica que se tiene una secuencia de ejecucin, como muchos de los usuarios interpretarn, Esto no es as en lo absoluto. El modelo del DFD es una red de procesos asincrnicos que se intercomunican, lo cal es, de hecho, una representacin precisa de la manera en la que en realidad muchos sistemas operan. Para qu numerar las burbujas entonces?. En parte, como se indic anteriormente, es una manera muy conveniente de referirse a los procesos. Pero de mayor importancia an es el hecho de que los nmeros se convierten en base para la numeracin jerrquica cuando se introduzcan los diagramas de flujo por niveles. Redibujar el DFD tantas veces como sea necesario estticamente. En proyecto real de anlisis de sistemas, el DFD que se analiza, deber dibujarse y volverse a dibujar, a menudo hasta 10 veces o ms, antes de ser a) tcnicamente correcto b) ser aceptable para el usuario y c) estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a la direccin de la organizacin. Evitar los DFD demasiados complejos El propsito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema y las interacciones entre ellas. Pero otro propsito de DFD es ser ledo y comprendido, no slo por el analista que construy el modelo, sino por los usuarios que sean los expertos en la materia de aplicacin. Esto significa que el diagrama debe ser fcilmente entendido, fcilmente asimilado y placentero a la vista. Asegurarse de que el DFD sea internamente consistente y que tambin lo sea con cualquiera DFD relacionados con l. Existen algunas reglas respecto a cmo asegurar que el DFD mismo sea consistente: Evite Sumideros Infinitos: burbujas que tienen entradas pero no salidas, Tambin son conocidos por los analistas como Agujeros negros. 1. Evite las burbujas de generacin espontnea: que tienen salidas sin tener entradas, porque son sumamente sospechosas y generalmente incorrectas.

2.

Tenga cuidado con los flujos y procesos no etiquetados: Esto suele ser indicio de falta de esmero, pero puede esconder un error an ms grave: a veces el analista no etiqueta un flujo o un proceso porque simplemente no se le ocurre algn nombre razonable. Tenga cuidado con los almacenes de slo lectura o slo escritura: Esta regla es anloga a la de los procesos de nicamente entradas o nicamente salidas. La nica excepcin a esta regla es el almacn externo.

3.

DFD por Niveles: Organizar el DFD global en una serie de niveles de modo que cada uno proporcione sucesivamente ms detalles sobre una porcin del nivel anterior. Esto es anlogo al la organizacin de mapas en un atlas. El DFD del primer nivel consta slo de una burbuja, que representa el sistema completo: los flujos de datos muestran las interfaces entre el sistema y los terminadores externos Como podr verse, sta es una manera bastante directa de organizar un DFD potencialmente enorme en un grupo de piezas manejables. Pero existen diversas cosas que debemos aadir a esta descripcin de niveles: Cmo saber cuntos niveles debe haber en un DFD? La respuesta es que cada DFD debe tener no ms de media docena de burbujas y almacenes relacionados. As, se ha partido un sistema grande en tres niveles, pero sus DFD de nivel ms bajo an contienen 50 burbujas cada uno, entonces falta por lo menos un nivel ms. 2. Existen reglas acerca del nmero de niveles que debieran esperarse en un sistema tpico? En un sistema simple, probablemente se encontrarn dos o tres niveles; uno mediano tendr generalmente de tres a seis niveles; uno grande tendr de cinco a ocho niveles. Debe ser bastante precavido con la gente que le diga que todos los sistemas pueden modelarse en exactamente tres niveles.
1. 3.

Deben partirse todas las partes del sistema con el mismo nivel de detalle? Por ejemplo, si la burbuja 2 de la figura 0 requiere tres niveles ms de detalle es necesario que tambin la burbuja 3 tenga tres niveles ms de detalle?. Las respuesta es NO. Algunas partes de sistema pueden requerir uno o ms niveles de particin. Por otro lado si la burbuja 2, que existe en la figura 0, resulta primitiva, mientras que la burbuja 3 requiere de siete niveles ms de particin, entonces el modelo global del sistema est ladeado y probablemente est mal organizado. Cmo se muestran estos niveles al usuario? Muchos usuarios slo querrn ver un diagrama: un usuario ejecutivo de alto nivel pudiera querer ver slo el diagrama de contexto o tal vez la Figura 0; un usuario de nivel operacional pudiera querer ver slo la figura que describe el rea en la cul est interesado. Pero si alguien quiere ver una parte ms extensa del sistema, o tal vez todo, entonces tiene sentido presentar los diagramas de una manera
2

4.

descendente; comenzar con el diagrama de contexto y continuar hasta niveles ms bajos de detalle.
5.

Cmo asegurar que los niveles del DFD sean consistentes entre si? El asunto de la consistencia resulta ser de importancia crtica, pues los diversos niveles del DFD los desarrollan en general distintas personas en un proyecto real. Para asegurar que cada figura sea consistente con sus figuras de ms alto nivel se sigue una regla muy sencilla: Los flujos de datos que salen y entran de una burbuja de un nivel dado deben corresponder con los que entran y salen de toda la figura en el nivel inmediato inferior que la describe. Cmo se muestran los almacenes en los diversos niveles? Esta es un rea donde la redundancia se introduce deliberadamente en el modelo. La regla es la siguiente: mostrar un almacn en el nivel ms alto donde primeramente sirve de interfaz entre dos o ms burbujas, luego mostrarlo de nuevo en cada diagrama de nivel inferior que describa ms a fondo dichas burbujas de interfase. El corolario de esto es que los almacenes locales, que utilizan slo las burbujas en una figura de menor nivel, no se mostrarn en niveles superiores, dado que se incluyen de manera implcita en un proceso del nivel inmediato superior.

6.

PPS Primitive Processing Specification La especificacin de proceso es la descripcin de qu es lo que sucede en cada burbuja primitiva de nivel ms bajo en un DFD. Define lo que debe hacerse para transformar entradas en salidas. Debe reunir los siguientes requerimientos: 1. La especificacin del proceso debe expresarse de una manera que puedan verificar tanto el usuario como analista. 2. El proceso debe especificarse en una forma que pueda se comunicada efectivamente al pblico amplio que est involcrudado. Diagrama de Entidad-Relacin Es un modelo de red que describe con alto nivel de abstraccin la distribucin de datos almacenados en un sistema. Es muy diferente del DFD, que modela las funciones que lleva a cabo un sistema; y es diferente del diagrama de transicin de estados. Enfatiza las relaciones entre almacenes de datos. Diccionario de Datos: Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas para que tanto el usuario como el analista tengan un entendimiento comn de todas las entradas, salidas, componentes de almacenes y clculos intermedios.

ACTIVIDADES
1.

Habla sobre El proceso

2. Que es un flujo 3. Defina almacn

4. 5. 6. 7. 8. 9.

Que es un terminador Explica la Construccin del DFD Describe El DFD por niveles Que es un PPS Primitive Procesing Specification Que es un Diagrama Entidad Relacin Habla sobre El diccionario de datos

CAPITULO V

Cmo naci UML

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el anlisis y diseo de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento. Booch haba escrito "Object-Oriented Analysis and Design with Applications " un libro de referencia en el anlisis y diseo orientado a objetos desarrollando su propia notacin. Por su parte James Rumbaugh haba desarrollado su propia notacin de diseo orientado a objetos llamada OMT (Object Modeling Technique) en su libro "ObjectOriented Modeling and Design ". Por otro lado Jacobson se haba revelado como un visionario del anlisis (padre de los casos de uso) y sobre todo del diseo orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven Approach ". A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos. En 1994 Rational contrat a Rumbaugh en donde ya trabajaba Booch, un ao despus Jacobson se una a ellos en Rational. En 1997 sali a la luz la versin 1.0 de UML.

Qu es UML Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, disear, configurar, mantener y controlar la informacin sobre los sistemas a construir. UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. Un sistema se modela como una coleccin de objetos discretos que interactan para realizar un trabajo que finalmente beneficia a un usuario externo. El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas actuales en un acercamiento estndar. UML no es un lenguaje de programacin. Las herramientas pueden ofrecer generadores de cdigo de UML para una gran variedad de lenguaje de programacin, as como construir modelos por ingeniera inversa a partir de programas existentes. Es un lenguaje de propsito general para el modelado orientado a objetos. UML es tambin un lenguaje de modelamiento visual que permite una abstraccin del sistema y sus componentes. Existan diversos mtodos y tcnicas Orientadas a Objetos, con muchos aspectos en
2

comn pero utilizando distintas notaciones, se presentaban inconvenientes para el aprendizaje, aplicacin, construccin y uso de herramientas, etc., adems de pugnas entre enfoques, lo que genero la creacin del UML como estndar para el modelamiento de sistemas de software principalmente, pero con posibilidades de ser aplicado a todo tipo de proyectos. Objetivos del UML UML es un lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. UML no pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver requisitos dirigidos por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribucin, as como tambin los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito general. Imponer un estndar mundial.

Orientacin a objetos Permite al programador que organice su programa de acuerdo con abstracciones de ms alto nivel, siendo estas ms cercanas a la manera de pensar de la gente. Ejemplo: Cuentas de bancos, reservaciones de vuelos. Etc. Los datos globales desaparecen por lo tanto cualquier cambio en la estructura de algunos de los datos slo debiera afectar las funciones definidas en ese mismo objeto y no en los dems, en general un programa orientado a objetos se define en trminos de objetos y relaciones los datos y funciones se guardan dentro de objetos, datos estn ubicados en el centro del objeto, lo cual hace que un cambio en su estructura solo afecte sus funciones del mismo objeto, pero no al resto de la aplicacin. Tipos de Ingenieras El modelado es importante, pero recordemos que el producto principal de un equipo de desarrollo es software y no diagramas. Po supuesto, la razn por la que se crean modelos es para entregar, en el momento oportuno, el software adecuado que satisfaga los objetivos siempre cambiantes de los usuarios y la empresa.

Para algunos usos de UML, los modelos realizados nunca se correspondern con un cdigo. Por ejemplo, si se modela un proceso de negocio con diagramas de actividades, muchas de las actividades modeladas involucrarn a personas y no a computadoras. En la mayora de los casos, sin embargo, los modelos creados se correspondern correspondencia con cdigo, al respecto ningn UML no de especfica ninguna de particular con lenguaje programacin

programacin orientado a objetos, pero se dise con estas correspondencias en mente. Vea la siguiente figura como Star UML posee correspondencias con algunos lenguajes.

Fig. 1 Observe como Star UML hace Referencia a Lenguajes como C++, C# y Java

Ingeniera Directa La ingeniera Directa es el proceso de transformar un modelo en cdigo a travs de una correspondencia con un lenguaje de implementacin. La ingeniera inversa produce una prdida de informacin, porque los modelos escritos en UML son semnticamente ms ricos que cualquier lenguaje de programacin orientado a objetos actual. De hecho, sta es una de las razones por las que se necesitan modelos adems de cdigo. Las caractersticas estructurales, como las colaboraciones, y las caractersticas de comportamiento, como las interacciones, pueden visualizarse claramente en UML, pero no tan claramente a partir de simple cdigo fuente.

Ingeniera inversa La ingeniera inversa es el proceso de transformar cdigo en un modelo a travs de una correspondencia con un lenguaje de programacin especfico. La ingeniera inversa produce un aluvin de informacin, parte de la cual est a un nivel ms bajo del que se necesita para construir modelos tiles. Al mismo tiempo es incompleta ya que hay una prdida de informacin cuando se hace ingeniera directa de modelos a cdigos, as que no se puede recrear completamente un modelo a partir de cdigo a menos que las herramientas incluyan informacin en los comentarios del cdigo fuente que vaya ms all de la semntica del lenguaje de implementacin.

Secuencia Metodolgica de construccin de diseos Una herramienta CASE (ingeniera de software asistida por computadora) ayuda a los administradores de proyectos de ingeniera de software en las actividades de gestin, anlisis, diseo y codificacin de software. Los proyectos encarados con un apoyo de CASE logran modelos del sistema que permiten entender lo que el sistema har, a la vez que pueden hacerse un
3

seguimiento de la completitud, precisin y consistencia del diseo, esto lleva a descubrir errores solo durante la fase de programacin y que slo sean errores de programacin y no un reflejo de falta de entendimiento entre usuarios y analistas. Las actividades de diseo producen un modelo que en conjunto forman un plano gua para la construccin y prueba del sistema. Cada modelo se refleja en un tipo de diagrama o un conjunto de diagramas y dependen de las diferentes fases del desarrollo, estos diagramas pueden variar dependiendo del tamao y naturaleza del sistema. Definir el repositorio del proyecto Para poder vincular cada diagrama con un documento de especificacin es importante crear una estructura de directorio repositorio donde puedan colocarse los diferentes artefactos que documentarn el sistema en si. A modo de sugerencia he creado este grupo de directorios:

Observe en la figura que el directorio Repositorio Moble posee un archivo de texto leeme.txt, es recomendable colocar un archivo de este tipo para identificar el objeto del directorio, escribiendo en el archivo la lista de directorios y artefactos que incluye dicho directorio. A su vez cada subdirectorio debera de incluir otro archivo del mismo nombre y sucesivamente en cada directorio o subdirectorio. Definir Tipo de ingeniera Para nuestro ambiente, tenemos bien definido el tipo de ingeniera que aplicamos, ya que generalmente los educandos realizan la prctica de diseo de sistemas de cero, es decir que el diseo de sistemas se realiza desde el principio sin la observacin de sistemas existentes.

Fig. 2 Vea como indicar el tipo de ingeniera Definir los modelos que se disearn Cuando se modela algo, se crea una simplificacin de la realidad para comprender mejor el sistema que se est desarrollando. Con UML, se construyen modelos a partir de bloques de construccin bsicos, tales como clases, interfaces, colaboraciones, componentes, nodos, dependencias, generalizaciones y asociaciones. Para nuestro ejemplo utilizaremos los siguientes modelos:

Modelo de Negocios Modelo de comportamiento Modelo de objetos Modelo de despliegue

Para crear los modelos con StarUML slo haga click derecho sobre el nombre del proyecto y agregue los modelos. F2 para renombrar los modelos. Vea esto en la siguiente figura.

Fig. 3 Vea como agregar modelos

El modelo del negocio En la etapa inicial de un proyecto de desarrollo de software, antes de la determinacin de requerimientos, surge la importancia de la obtencin de informacin de las caractersticas del negocio, la cual nos proporcionara un panorama detallado de la estructura y organizacin de la empresa, identificacin de usuarios participantes, el entorno tecnolgico en que se encuentra y sobre todo nos permite considerar las referencias para el sistema de informacin en estudio, desde el punto de vista de reglas, normativas, leyes o recomendaciones que se deben tener en cuenta a lo largo de todo el proceso de desarrollo. Las entrevistas a usuarios y conversaciones son el punto de partida para obtener el panorama general del negocio, cuestiones como naturaleza del negocio que pueden ser inversiones nacionales o extranjeras, seguros, importacin o exportacin, produccin de materia prima y otros; nos darn una idea de qu debemos manejar para saber como encarar el proyecto de nuestro cliente. No
3

tema en solicitar copias de organigramas o algn documento que le ayude a adentrarse en las funciones de cada rea del negocio. Moble-up, es el emprendimiento de negocio iniciado por dos personas en la dcada de los 90, dedicndose a la produccin de sillas, sillones de metal con partes de frmica y juegos de comedor del mismo material. La produccin se basa en la compra de materia prima que incluye partes como tornillos, caos de hierro, cordones de plstico, tapones de plsticos, insumos para la produccin como electrodos, pintura para metales, hojas de sierra para los cortes, lija y otros. El pago de honorarios al personal se realiza semanalmente y de acuerdo a la produccin que logra cada personal de Moble-up. Luego del cierre de los bancos, la empresa fue afectada por escasez de circulante, lo que motivo a buscar nuevas formas de ingreso. La produccin tuvo una cada; lo que creo el retiro del personal en aquel entonces, esta situacin llevo a la empresa a la venta de los muebles con pagos fraccionados. Para cumplir con este nuevo enfoque de negocio, se contrataron cobradores y se empez a adquirir modelos de muebles de otros fabricantes. El nuevo enfoque tomado por Moble-up, tuvo sus resultados en un tiempo muy reducido, teniendo que ampliar las instalaciones e incluso arrendar otras dependencias para manejar el crecimiento y mejorar la atencin al cliente. Al ao de la nueva forma de trabajo, el movimiento de compras y ventas se haba triplicado y la cantidad de clientes ha aumentado tanto que se ha vuelto una situacin difcil de controlar de forma manual. Las cuentas por cobrar de clientes se registran de forma manual en fichas que son confeccionadas para el efecto y que son entregadas al personal de cobranza para el correspondiente registro de cobros de cuotas del cliente. Con esta forma de control, en muchas oportunidades se desconoca el vencimiento de las cuentas de clientes, se desconoca la existencia real de los productos ofrecidos por Moble-up. Moble-up a menudo deba pasar la vergenza de cambios en los precios segn el vendedor, puesto que no dispona de un
3

catalogo de precios de productos. Esta situacin generaba la perdida de cierre de una venta. En la siguiente figura puede observarse un modelo del negocio de Moble-up, este modelo es inicial, puesto que a primera vista podemos rescatar como los actores del negocio se relacionan con los procesos del negocio. Este modelo de negocio fue diseado con visual paradigm 6.0 y no pretende que sea el definitivo ya que conforme se empape con los procesos del negocio ir refinando el diseo.

El modelo de requerimientos El modelo de requerimientos parte del relevamiento de requisitos, en donde se lleva acabo el proceso de descubrir, analizar, escribir y verificar los servicios y restricciones del sistema de software. Su importancia radica en que, de la definicin de los requerimientos depender la definicin de las etapas subsecuentes del desarrollo de software, es decir, que si no se descubren los requerimientos que se encuentran en el ambiente repercute de forma negativa debido a que como si son encontrados en una etapa avanzada del desarrollo, obligar a retroceder nuevamente a la etapa de requerimientos, esto provocara cambios en el sistema y consecuentemente retraso en la entrega del sistema. Un caso peor es, que no se encontraran y especificaran todos los requerimientos del sistema en un proceso de desarrollo de software, lo cual producira la entrega de un producto de software incompleto o poco funcional. Se puede considerar a esta etapa como la ms importante de todo el proyecto, por lo tanto se deber recurrir a la tcnica ms ptima para lograr obtener con claridad lo que desea el usuario que proporcione el sistema a desarrollar. Observe ahora su modelo de negocios e identifique las reas en las que debe entrevistarse (entienda que cuando hablamos de reas necesariamente debe conversar con algn personal de esa rea) y haga una lista de ellas. Veamos:

El rea de compras El rea de ventas

3

El rea de depsito El rea de cobranza.

Con la lista de reas, puede comenzar un relevamiento de requerimientos de cada usuario en su rea. Como descubrir los requerimientos para diagramar En el mbito de los negocios existen eventos que para un experto en software el es como el pan de cada da, son justamente estos eventos los que se necesitan capturar para determinar el comportamiento del sistema a desarrollar. Para capturar un evento que ocurre en el ambiente, debe considerarse la sintaxis sujeto-verbo-objeto y esto no es que sea una tarea sencilla especialmente si es que no se elabor un buen relevamiento de datos. De acuerdo al relevamiento realizado en cada rea pueden redactarse lista de eventos por cada rea que puede tomar la siguiente forma:

1.1 El personal de compras hace pedidos al proveedor. 1.2 El personal de compras recepciona factura del proveedor. 1.3 El personal de compras solicita informe de compras

Como se muestra en este ejemplo una lista de eventos no debera presentar palabras innecesarias, se escribir el evento de forma especfica en una lnea y para que sea verdaderamente til deber estar agrupada y ordenada correspondiente a cada actividad de la estructura organizativa del negocio. Queda demostrado que el primer evento El personal de compras hace pedidos al proveedor se compone de: Sujeto: El personal de compras Verbo: hace Objeto: pedidos al proveedor.

Los nombres de eventos son importantes y no deben escatimarse esfuerzo para buscar la expresin del evento. Ha llegado el momento de tomar slo aquellos a los que el sistema debe responder, esto puede conseguirse mediante la confeccin de una planilla en la que podemos comparar nombre de evento, requerimiento que se cubre, y el estimulo que activa el evento. No crea que las palabras estimulo y eventos sean de significado igualitarios. Para ordenar las ideas puede crear un esquema como sigue Evento: Personal de compra elabora orden de compra Requerimiento: elaborar orden de compra Estimulo: lista de compra Respuesta: Orden de compra El cuadro completo de los eventos de nuestro caso de estudio es como se muestra, fjese como queda la siguiente tabla donde se ordenan los eventos, el estimulo que produce y a que requerimiento atiende evento El personal de compras elabora orden de compra El personal de compras recepciona factura de proveedor El personal de compras solicita informe de compras requerimiento Elaborar orden de compra Registrar compra elaborar informe de compras estimulo lista de compras factura de compra parmetros fechas, sucursal

No se debe caer en el error de que el diagrama de requerimientos es el modelo de eventos, tal vez el analista pueda encontrar las herramientas grficas para demostrar un modelo adecuado para el modelo de eventos, pero por ahora nos bastara la utilizacin de la tabla anterior para continuar con nuestro trabajo de
4

disear el diagrama de requerimientos. Hemos demostrado como llegar a los requerimientos. La lista de eventos entonces ayuda a un diseo ms exacto y la manera en que debe reaccionar el sistema al detectar un estimulo ocasionado por un evento externo al sistema. De sta forma ser ms sencilla la tarea de descubrir eventos y respuestas para determinar el comportamiento de nuestro sistema. Una vez obtenido todos los requerimientos de forma especifica y objetiva se deber organizar el documento de tal forma que estn agrupados los requerimientos por cada rea, puede observarse como se han refinado los requerimientos como sigue:. 1 Departamento de compras 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4 Elaborar orden de compra Registrar las compras Elaborar un informe de compras Recepcionar pedido de productos del cliente Registrar las ventas y actualizar ctas. de clientes Elaborar informe de ventas Elaborar lista de ctas. a cobrar Actualizar cta. CTE. del cliente Realizar apertura/cierre de caja Elaborar resumen de movimiento de caja Transferir productos entre depsitos y sucursales Ajustar existencia de productos luego de inventario Obtener informe de existencia mnimas Preparar planilla para inventario

Departamento de ventas

Departamento de cobranzas

rea de depsito (inventario de bienes de cambio)

Esta lista de requerimientos del cliente es representado en un diagrama de requerimientos para documentar el relevamiento y realizar ya un anlisis inicial del negocio. Siguiendo con nuestro ejemplo tomaremos slo el rea de compras. El resultado se observa en el siguiente diagrama de requerimientos.

Observe que el requerimiento gestionar compras se le ha asignado un ID = 1, esto es solo a los efectos de identificarlo desde nuestra lista de requerimientos y cada objeto de requerimiento contiene datos sobre el rea donde se detecto el requerimiento, el tipo de requerimiento, el mtodo por el que se identific y su grado de prioridad entre los dems requerimientos. Como una forma de organizar el diseo, puede numerar cada extensin del requerimiento, vea que en el diseo cada requerimiento posee un ID. La siguiente figura es una vista modelo del negocio confeccionado con StarUML en la versin 5.0 y pretende mostrar cuales macroprocesos (paquetes) que son ejecutados en la empresa interactan con los actores comerciales.

Fjese como los actores comerciales proveedor y cliente no poseen las lneas de relacin con los subsistemas del sistema. Ahora que conocemos cuales subsistemas se deben encarar, podemos disear el modelo de caso de uso del negocio por cada rea, a su vez estos CUN por rea me permite generar casi automtico un Modelo de negocio global con el diagrama de CU. (Esto se muestra en seminario Taller) Para nombrar los CUN por rea refirase a las funciones de cada rea o de cada departamento. Por ejemplo, la funcin principal del departamento de ventas es administrar las ventas, la de compras es la de gestionar y realizar las compras de productos, y para cada rea su funcin principal. Cmo llegar diagramar el Modelo de Negocio Global con Caso de de uso Si la organizacin de nuestros requerimientos se ha hecho de forma estructural, el camino para la construccin del modelo de caso del negocio global ser muy sencillo. Tome a los actores del ambiente y colquelos en el diseo, luego coloque los casos de uso del negocio que corresponda a cada rea y arrstrelo en la pgina del diagrama, las relaciones entre CU y Actor se incluirn automticamente. Vea ahora como queda el modelo casos de uso del negocio.
4

Observe que los actores comerciales proveedor y cliente ya no aparecen en el diseo de modelo caso de uso del negocio El modelo de casos de usos Los casos de uso muestran la visin funcional del programa. Son como una forma de especificar el comportamiento del sistema. Representan una forma fcil de expresar cmo algo o alguien hace uso del sistema e interacta con el, esto nos permite ver los recursos que el sistema proporciona. Los casos de uso son una forma visual de describir los distintos escenarios que sirven para mostrar momentos de interaccin de los actores con el sistema. Una de las ventajas de los casos de usos es que establecen un punto de referencia comn entre el programador y el cliente o el jefe que encarga el desarrollo de y permiten documentar de manera sencilla y entendida por cualquiera ajeno a la informtica.

Para representar los diagramas del Modelo de Casos de Uso nuevamente nos referiremos a nuestro modelo de requerimientos, punto de partida para encontrar los casos de usos del negocio, as cada requerimiento se puede convertir en un caso de uso.

El caso de uso registrar compra El modelo de objetos La modelizacin orientada a objetos se centra en el desarrollo de una coleccin de objetos discretos que incorporan tanto estructura de datos como comportamiento. Los objetos ejecutan o reciben operaciones que representan las interacciones entre objetos. El centro de atencin es la construccin de definiciones de objetos que puedan organizarse en una jerarqua de clases con altos niveles de abstraccin. Los objetos pueden agruparse mediante agregaciones, y pueden tener relaciones y atributos (propiedades) de forma similar al modelo entidad relacin. De hecho, el modelo de datos (ERD) constituye la base de los conceptos orientados a objetos (entidades y atributos) Para nuestro ejemplo tomaremos slo una parte de todo nuestro proyecto, y siguiendo con nuestra lnea de ejemplo nos abocamos a disear los objetos de datos del rea de compras, como se ve en la siguiente figura:

Mencionamos en este punto que el modelado de objetos de datos, es una tarea paralela al diseo de todo el proyecto, por lo que este modelo es importante tener ya para continuar con nuestro proyecto, cuyo paso siguiente es el de construir el modelo de comportamiento utilizando un diagrama de secuencias y/o de colaboracin. El modelo de informacin El modelado de la informacin forma la base del diseo de la base de datos relacional. Para construir nuestro modelo de informacin podemos basarnos inicialmente en nuestro diagrama de objetos de datos, luego ir refinando a medida que se entra en detalles en el anlisis y diseo de sistemas En el siguiente ejemplo se presenta el DER de compra.

El modelo de secuencias Un modelo de secuencias es un tipo de modelo de interaccin junto con el diagrama de colaboracin, el modelo se secuencias se expresa por medio de un diagrama de secuencias que muestra las interacciones entre los objetos organizados en una secuencia temporal. En particular muestra los objetos participantes en la interaccin y la secuencia de mensajes intercambiados. Para disear el diagrama de secuencias necesariamente debera de tener el diagrama de objetos de datos. Arrastre el actor desde el caso de uso que
4

corresponda y luego cada uno de los objetos de datos desde el explorador de modelos.

El modelo de colaboracin El uso del diagrama de colaboracin es mostrar la implementacin de una operacin. La colaboracin muestra los parmetros y las variables locales de la operacin, as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de seales del programa. Un diagrama de secuencia muestra secuencias en el tiempo como dimensin geomtrica, pero las relaciones son implcitas. Un diagrama de colaboracin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales estn menos claras. La construccin del diagrama de colaboracin se realiza de forma automtica a partir de nuestro diagrama de secuencia. Pero la herramienta STARUML presenta un error en esta parte del programa, cuando se le da la orden de convertir un diagrama de secuencia a diagrama de colaboracin.
4

Antes de realizar esta operacin asegrese de grabar todo el trabajo. Luego realizar la conversin del diagrama de secuencia a de colaboracin. Cerrar la aplicacin StarUML luego volver a ejecutarlo. El diagrama de colaboracin se puede encontrar en el mismo nivel de jerarquas donde se encontraba el diagrama de secuencias. Se puedo luego mover al paquete de Diagramas de colaboracin creando primero un diagrama de colaboracin vaco. Cortar el anterior, posicionar sobre el nuevo diagrama de colaboracin y hacer click derecho para pegar el diagrama de colaboracin confeccionado automticamente.

Arreglar el diseo.

En ese sentido nuestro diagrama quedara como se muestra en la siguiente figura:

Escenarios y necesidades del cliente (Prototipado de ventanas) Cuando se utiliza el proceso unificado, en vez de construir un prototipo rpido se muestran al cliente los casos de uso, o con ms precisin, los diagramas de interaccin que reflejan las clases que realizan los escenarios del caso de caso de uso. El cliente puede comprender cmo se comportar el sistema de informacin. No obstante, hay un rea donde un prototipo rpido es superior a un escenario y sta es la interfase del usuario. No hay manera de que un escenario pueda describir una pantalla tan bien como lo hace un prototipo rpido. Para crear prototipazo de ventanas puede valerse de cualquier lenguaje de programacin y construir el modelo de ventana que el usuario final estara manejando. Actualmente existen muchas herramientas case que incluyen esta prestacin para la construccin de prototipos de interfase de usuario. El modelo de despliegue

Conclusin Uno de los objetivos del modelado es describir el sistema que se est desarrollando a un nivel de detalle que permita controlar partes de un modulo con otro y determinar durante este ciclo de vida de desarrollo que no se haya omitido partes que son inherentes a otras. Al respecto, controlar que los modelos sean correspondientemente satisfactorios o por lo menos en un grado aceptable permitir obtener un producto final utilizable. El especialista en diseos y modelos debe considerar que un modelo que no sigue alguna semntica estandarizada, bien podra crear modelos no vlidos que llevara a un modelo no aplicable en el desarrollo del producto que se busca o necesita. Luego de una serie de vaivn de preguntas, entrevistas y mltiples cambios en cada uno de los diagramas el analista se encuentra frente a un conjunto de diagramas que en algunos casos por si solos carecen de sentido alguno, pero que en suma hacen a todo el proyecto. Esta serie de modelos puestos sobre la mesa de trabajo comienzan a tener sentido recin cuando se comienza a desarrollar el software, aclaro que no es una regla que deba tenerse todos los diagramas para comenzar el desarrollo del producto, sino que cada diagrama adquiere importancia cuando se empieza el trabajo de la construccin del software. Los modelos en agrupacin reflejan las tres capas que luego se considera como parte de la arquitectura del software, estos modelos son tenidos en cuenta cuando se desarrolla sistemas de gestin para la toma de decisiones para empresas, y se puede generalizar como sigue: A) Una vista de datos, B) Una vista del negocio C) Una vista del comportamiento

Estas capas son totalmente interdependientes y aunque se construyan de forma separada estn altamente relacionados en lo que conocemos como las reglas del negocio.

Bibliografa
Libros BOCH Grady, RUMBAUGH James, JACOBSON Ivar. 2003. El Lenguaje Unificado de Modelado. Espaa. Addison Wesley . 2. Edicin LARMAN, Craig. 2003. Uml y Patrones. Pearson Educacin. GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, and VLISSIDES, John. 2003. Patrones de diseo. Mxico. Addison Wesley POMMIER, Jorge T. Anlisis de requerimientos orientado a los objetivos. Mxico. Prentice Hall PRESSMAN, Roger. 2002. Ingeniera del software un enfoque prctico. Mxico. Mac Graw Hill. 5 Edicin. RUBLE, David. 1998. Anlisis y diseo prctico de sistemas para sistemas cliente servidor con Gui. Mxico. Prentice Hall. SCHACH, Stephen. 2005. Anlisis y diseo orientado a objetos con UML y el proceso unificado. Mxico. Mac Graw Hill. YOURDON, Edgar. 1989. Anlisis estructurado moderno. Mxico. Prentice Hall. Revistas y manuales Ministerio de Administraciones Pblicas. Anlisis del sistema de informacin. Metodologa Mtrica Versin 3. Per. Mundo Linux Nro: 40. 2002. Revistas Profesionales S.L. Espaa. Web site http://www.umsanet.edu.bo/docentes/teran http://weblog.mendoza.edu.ar/actinform/archives/004744.html http://www.eside.deusto.es/postgrado/dissc/default.asp?lang=SP http://www.icesi.edu.co/esn/contenido_programas.jsp?id=icesi3educc22 http://directo.uniovi.es/catalogo/FichaAsignatura.ASP?asignatura=7803 http://www.ctv.es/USERS/belmont/indexoo.htm http://www.tic.udc.es/~fbellas/teaching/adoo/ http://www.esoft.cl/pages/parte2a.html http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN08.htm http://www.altana.es/master/ http://www.programacion.com/articulo/inukisoft
5

http://www.itba.edu.ar/capis/webcapis/OldWeb/ancis5.html http://www.univernet.net/aulas/informatica/poo/cap-vi.htm http://www.dei.inf.uc3m.es/docencia/p_s_ciclo/pa/web/practicas/pfeb/pa-pfeb.pdf http://www.sparxsystems.cl/uml_patterns.html http://www.sparxsystems.cl/create_uml_patterns.html http://www.sparxsystems.cl/import_uml_patterns.html http://www.sparxsystems.cl/use_uml_patterns.html http://www.programacion.com/java/articulo/joa_patrones1/ http://www.programacion.com/java/articulo/joa_patrones1/#joa_patrones1_softwa re http://www.willydev.net/descargas/WillyDEV_JoseLuis_Diagramas_REP.pdf http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art163.asp http://www.ati.es/gt/LATIGOO/OOp96/Ponen12/atio6p12.html http://www.visual-paradigm.com/product/vpuml/demos/ http://www.dsic.upv.es/~uml/curso.pdf http://www.ciao.es/Rational_Rose_Enterprise_Edition__Opinion_612900 http://arantxa.ii.uam.es/~saiz/poo-cuarto/curso-actual/transp/ingenieria-softwareoo.PPT http://www.techeras.com/pdf/Syllabus_BPM_y_UML_para_Desarrolladores_de_S oftware_con_RUP.pdf http://www.fi.uba.ar/materias/7572/PatronesAnalisis.pdf http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15 http://www.yoprogramo.com/articulo4.php http://www.creangel.com/uml/secuencia.php http://www.ingenierosoftware.com/analisisydiseno/uml.php DESARROLLO DE LOS MODELOS: PROF. ING. HILARIO MACHUCA

ANEXO EL PROTOTIPO DE INTERFAZ Introduccin Ahora entramos a lo divertido. Este capitulo presenta el concepto de creacin de prototipos. En algunos establecimientos, la creacin de prototipos es un eufemismo para codifique algo rpidamente y vea si los usuarios lo aceptan . Dentro de estas pginas no encontrar este enfoque. En vez de ello le propongo que un prototipo se puede construir bien. U prototipo exitoso comienza con un objetivo establecido de lo que se quiere aprender al hacerlo. Una vez que se comprende lo que se quiere lograr, se puede seleccionar una tcnica de creacin de prototipos. Qu es un Prototipo Est aceptado generalmente que un prototipo es un modelo a escala o facsmil de lo real, pero no tan funcional para que equivalga al producto final. Los prototipos se presentan en muchas formas y tamaos. En la industria automotriz, los prototipos de autos pueden ir en complejidad desde un modelo tallado en madera hasta un vehculo motorizado real que se puede conducir. El mismo rango de complejidad resulta cierto para los sistemas de software. El prototipo puede ser tan simple como un conjunto de disposiciones de pantallas en hojas de papel pegadas en la pared, o tan sofisticado como programas de software animados que permiten a los usuarios hacer clic en los botones e introduzcan datos. El Propsito del Prototipo La creacin de prototipos siempre debe realizarse con un objetivo de aprendizaje especfico en mente. En la fase de anlisis de un proyecto, la principal directiva del prototipo es derivar y validar los requerimientos esenciales, manteniendo abiertas, al mismo tiempo, las opciones de implementacin. Beneficios de la creacin temprana de prototipos Ms que cualquiera de los tres grandes modelos, el prototipo de interfaz realmente introduce a los usuarios en el proyecto. Por primera vez el sistema tiene una cara. Inevitablemente, despus de ver el prototipo, alguien le dir al analista acerca de un evento que hasta ese momento no se haba mencionado. Tambin aadir conceptos de datos a la ventana que no se mencionaron durante las entrevistas y posiblemente elimine algunos por irrelevantes. La creacin de prototipos tambin causar que salgan a la superficie los asuntos de los procesos del negocio.

El prototipo tambin permite que se exploren ambientes de destino posibles. Tal vez una interfaz grfica de usuario no sea lo ptimo para su aplicacin particular. Se puede explorar la manera en que se vera la interfaz con sistemas basados en pluma, dispositivos porttiles pequeos, lectores de cdigos de barras, una pgina Web o las antiguas pantallas verdes de caracteres. Qu tan detallado debe ser el prototipo? Si se enfrenta a un grupo de usuarios que estn obsesionados en la navegacin, la demostracin de varias rutas de navegacin para su navegacin para su disposicin de ventanas, frecuentemente eliminar sus preocupaciones. Tambin aclarar consideraciones de diseo importantes que pueden usarse posteriormente, y ayudar a que los usuarios regresen al tema.

Ventajas y Desventajas Existen ventajas relevantes en el uso del Prototipo:

Modificacin del Sistema en Etapas tempranas de su desarrollo: El xito del uso del prototipo depende de qu tan pronto y con que frecuencia se reciba la retroalimentacin del usuario para hacer cambios y adecuarlos a las necesidades actuales. Los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizan en etapas tardas, como el prototipo puede cambiar varias veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentacin, la cual nos permite conocer la opinin del usuario sobre cambios a la entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos y mejorar el sistema.

El desarrollo de prototipos implica una inversin en tiempo y en dinero, siempre pero siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas son ms fciles de detectar en un prototipo.

Eliminacin de sistemas indeseables: Por permitir recopilar informacin nos permite eliminar un sistema que no lleg a ser lo que esperaban de l los usuarios. La inversin de tiempo y dinero se destaca pero es menor que la del sistema completo. Se toma esta decisin cuando el sistema no es til o no satisface los objetivos que se propuso el equipo de desarrollo, es una decisin dificil pero evita seguir gastando dinero y tiempo en un proyecto inservible. Diseo de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los principales promotores del xito.

El prototipo cuenta con las siguientes desventajas:

5

Administracin dificil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era sus propsitos. Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando an es imcompleto e inadecuado.

El prototipo se inicia cuando se observa la: Importancia de Definir su Objetivo Siempre se debe establecer cual es su objetivo, ya que un prototipo puede ser til en diferentes fases del proyecto, por ello su objetivo debe ser claro. Durante la fase de anlisis se usa para obtener los requerimientos del usuario. En la fase de diseo se usa para ayudar a evaluar muchos aspectos de la implementacin seleccionada. Propsitos del Prototipo En la fase de Anlisis de un proyecto, su principal propsito es obtener y validar los requerimientos esenciales, manteniendo abiertas, las opciones de implementacin. Esto implica que se debe tomar los comentarios de los usuarios, pero debemos regresar a sus objetivos para no perder la atencin. En la fase de Diseo, su propsito, basndose en los requerimientos previamente obtenidos, es mostrar las ventanas, su navegacin, interaccin, controles y botones al usuario y obtener una retroalimentacin que nos permite mejorar el Diseo de Interfaz.

Caractersticas de los Prototipos El proceso de desarrollo y empleo de prototipos tiene las siguientes caractersticas:

El prototipo es una aplicacin que funciona Los prototipos se crean con rapidez Los prototipos evolucionan a travs de un proceso iterativo Los prototipos tienen un costo bajo de desarrollo

Informacin Obtenida con el uso del Prototipo Reacciones Iniciales del Usuario El profesional de Sistema por medio de la observacin, evaluacin y la retroalimentacin, obtendr como reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente es el acoplamiento entre las necesidades y las caractersticas modeladas en el sistema. A travs de la recopilacin de tales reacciones, el profesional, ir descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se encuentran satisfechos con l, o si habr dificultades para vender o implantar el sistema.
5

Sugerencias Las sugerencias son el fruto de la relacin de los usuarios con el prototipo, las sugerencias aportadas por el usuario indican al profesional porque caminos dirigirse para refinar el prototipo, modificarlo o depurarlo, de forma que satisfaga mejor las necesidades de los usuarios. Innovaciones Las innovaciones son aquellas caractersticas nuevas del sistema que no fueron contempladas previamente a la interaccin con el prototipo. Prioridades La informacin que se obtiene con el uso de prototipos permite al profesional establecer prioridades y reorientar sus planes de una manera menos costosas y con un mnimo de contratiempo. Una de las peores cosas que le puede pasar a un profesional es disear e implantar un sistema que el usuario no necesita, ni desean.

ACTIVIDADES

1) Que es un prototipo 2) Beneficio de la creacin temprana de prototipos 3) Que tan detallado debe ser el prototipo 4) De donde vienen las ventajas 5) Como se inicia el prototipo 6) Caractersticas de los prototipos