SISTEMA DE INFORMACION

CAPITULO VI FASE DE DISEO Y ANALISIS

1) Identificacin de problemas, oportunidades y objetivos.

En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificacin de los problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el xito del resto del proyecto, pues nadie estar dispuesto a desperdiciar su tiempo dedicndolo al problema equivocado. La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organizacin har notar los problemas. Muchas veces esto ya fue realizado previamente: y por ello. es que se llega a invitar al analista. Las oportunidades son aquellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de informacin computarizados. Al aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estndar industrial. La identificacin de objetivos tambin es un componente importante de la primera fase. En un comienzo, el analista deber descubrir lo que la empresa intenta realizar, y luego. estar en posibilidad de determinar si el uso de los sistemas de informacin apoyara a la empresa para alcanzar sus metas, el encaminarla a problemas u oportunidades especficas.

 La siguiente etapa que aborda el analista, es la determinacin de los requerimientos de informacin a partir de los usuarios particularmente involucrados. Para identificar los requerimientos de informacin dentro de la empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organizacin, la entrevista, los cuestionarios: la observacin de la conducta de quien toma las decisiones, asi como de su ambiente, respuesta a las siguientes preguntas clave: Qu es lo que hace? Cmo se hace? Con que frecuencia se presenta? Qu tan grande es el volumen de transacciones o decisiones? Cul es el grado de eficiencia con el que se efectan las tareas? Existe algn problema? Qu tan serio es? Cul es la causa que lo origina? En esta etapa el analista hace todo lo posible por identificar qu informacin requiere el usuario para desempear sus tareas. Puede ver, cmo varios de los mtodos para establecer las necesidades de informacin, lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organizacin y de sus objetivos. En ocasiones, se llegan a concluir slo las primeras dos etapas del ciclo de desarrollo de los

2) Determinacin de los requerimientos de informacin.

3) Anlisis de las necesidades del sistema.

En esta etapa se usan herramientas y tcnicas especiales que facilitan al analista la realizacin de las determinaciones requeridas. Estas incluyen el uso de los diagramas de flujo de datos (DFD) que cuentan con una tcnica estructurada para representar en forma grfica la entrada de datos de la empresa, los procesos y la salida de la informacin. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, as como sus especificaciones, si son alfanumricos, descripcin, clave primaria, entre otros. Durante esta fase. el analista de sistemas tambin analiza las decisiones estructuradas por realizar, que son decisiones donde las condiciones, condiciones alternativas, acciones y reglas de accin podrn determinarse. Existen tres mtodos para el anlisis de las decisiones estructuradas: el lenguaje estructurado (en nuestro caso el espaol), las tablas de decisin y los rboles de decisin. A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta del sistema que resume todo lo que ha encontrado, presenta un anlisis costo / beneficio de las alternativas y plantea las recomendaciones (si es que existen) de lo que deber realizarse. Si la direccin acepta alguna de las recomendaciones, el analista proceder de acuerdo con ella.

4) Diseo del sistema

El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la del desarrollo del software, a la que denominan diseo fsico. El analista disea procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. El analista tambin disea accesos efectivos al sistema de informacin, mediante el uso de las tcnicas de diseo de formularios y de pantallas. La interfaz conecta al usuario con el sistema, y evidentemente, es de suma importancia. Seran ejemplos de interfaces para el usuario: el uso del teclado para introducir preguntas o respuestas, el uso de mens en la pantalla, el uso de dispositivos como el mouse y muchos otros. La etapa del diseo tambin incluye el diseo de los archivos o la base de datos que almacenar aquellos datos requeridos por quien toma las decisiones en la organizacin. Una base de datos bien organizada es

5) Desarrollo y documentacin del software

En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las tcnicas estructuradas para el diseo y documentacin del software se tienen: el mtodo HIPO, los diagramas de flujo. los diagramas Nassi-Schneiderman, los diagramas Warnier-Orr y el pseudocdigo. Aqu es donde, el analista de sistemas transmite al programador los requerimientos de programacin. Durante esta fase, el analista tambin colabora con los usuarios para desarrollar la documentacin indispensable del software, incluyendo los manuales de procedimientos. La documentacin le dir al usuario como operar el software, y as tambin, qu hacer en caso de presentarse algn problema.

6) Pruebas v mantenimiento del sistema.

Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y despus se examinan los resultados. El sistema de informacin debe probarse antes de utilizarlo. El costo es menor si se detectan los problemas antes de la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboracin con el analista de sistemas. En un principio, se hace una serie de pruebas, con datos tipo, para identificar las posibles fallas del sistema: ms adelante, se utilizarn los datos reales. El mantenimiento del sistema y de su documentacin empiezan justamente en esta etapa: y despus, esta funcin se realizar de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina del programador, que para las empresas llegan a implicar importantes sumas de dinero. Sin embargo, el costo del mantenimiento disminuye de manera importante cuando el analista aplica procedimientos sistemticos en el desarrollo de los sistemas.

7) Implantacin v evaluacin de sistema.

En esta ltima etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de informacin. Esto incluye el adiestramiento que el usuario requerir. Si bien, parte de esta capacitacin la dan las casas comerciales, la supervisin del adiestramiento es una responsabilidad del analista de sistemas. Ms an, el analista necesita planear la suave transicin que trae consigo un cambio de sistemas. Aunque la evaluacin del sistema se plantea como parte integrante de la ltima etapa del ciclo de desarrollo de los sistemas; realmente, la evaluacin toma parte en cada una de las etapas. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado. La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos aos. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

 Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: *Evaluacin operacional: Valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin. *Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin externo e interno. *Opinin de los administradores: evaluacin de las actividades de directivos y administradores dentro de la organizacin as como de los usuarios finales. *Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el

METODOLOGIAS DE ANALISIS Y DISEO

Este mtodo es una actividad de construccin de modelos. Mediante una notacin que es nica, se crean modelos que reflejan el flujo y el contenido de la informacin (datos y control); el sistema se divide funcionalmente y, segn los distintos comportamientos, se establece la esencia de lo que se debe construir. Surge a mediados de los aos 70, y ha ido evolucionando introducindose mejoras por varios autores; en los primeros aos se centraba en las aplicaciones de sistemas de informacin, luego a mediados de los 80 se introducen mejoras que proporcionan una notacin adecuada para los aspectos de control y de comportamiento de los problemas de tiempo real

 El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o aplicacin bien sea nuevo o ya existente. Permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadora, terminales, sistemas de almacenamiento, etc.) sin omitir ningn detalle. Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado.

 El Diseo Estructurado es otro elemento del Mtodo de Desarrollo por Anlisis Estructurado que emplea la descripcin grfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseo Estructurado es programas formados por mdulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseo Estructurado es el diagrama estructurado que es de naturaleza grfica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l.

El modelado de los Datos

El modelado de datos estudia los datos independientemente del procesamiento que los transforma. El modelado de datos responde a: Cules son las entidades de datos primarios que va a procesar el sistema.? Cul es la composicin de cada entidad de datos y que atributos la describen.? Cul es la relacin entre las entidades y los procesos que las transforman.? Para resolver estas cuestiones se realiza el diagrama entidadrelacin, donde se representa la red de datos que existe en el sistema dado, indicando los datos que se introducen, se almacenan se transforman y se producen dentro de la aplicacin.

Modelado Funcional
Diagramas de flujo de datos (DFD) Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre s por los datos. Representa el flujo de la informacin y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida. Diagramas de flujo de Control (DFC) Estas ampliaciones permiten al analista reflejar el flujo de control y el procesamiento de control; muestran como fluyen los sucesos entre los distintos procesos e ilustran como los sucesos externos hacen que se activen los procesos. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Esta ampliacin se centra menos en la creacin de smbolos grficos adicionales y ms en la representacin y especificacin de los aspectos del software orientados al control.

Modelado de Comportamiento
Es uno de los principios fundamentales de todos los mtodos de anlisis de requisitos. El Diagrama de transicin de Estado representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado

Diccionario de Datos
Es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensin de las entradas, salidas, almacenes de datos y clculos intermedios. Se podra decir que el modelo de anlisis estructurado toma la siguiente forma:

 Algunas metodologas estructuradas, que se han implantado en mayor o menor grado en el mbito laboral son: Jackson Page-Jones Gane & Sarson Jourdon / De Marco Warnier Chen Merise SSADM Metrica Euromtodo

 Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos por el software. Diagrama entidad-relacin: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripcin de datos. Diagrama de flujo de datos (DFD): sirve para dos propsitos, indica como se transforman los datos a medida que se avanza en el sistema; y representa las funciones que transforman el flujo de datos. En la Especificacin de proceso se encuentra un descripcin de cada funcin representada en el DFD. Diagrama de transicin de estados (DTE): indica como se comporta el sistema como consecuencia de sucesos externos. La Especificacin de control detalla mas informacin sobre los aspectos de control del software.

Caractersticas de Mtodo Utilizado

Los productos de anlisis han de ser de mantenimiento muy sencillo. Esto concierne concretamente al documento final (Especificacin de requisitos del software). Se deben tratar los problemas de gran tamao mediante algn mtodo efectivo de particin. Siempre que sea posible, se deben utilizar grficos. Se deben diferenciar las consideraciones lgicas (esenciales) y las fsicas (de implementacin).

Desventajas del Mtodo Estructurado

Esta metodologa clsica presenta ciertos problemas, que han ido hacindose cada vez ms graves, a medida que se construan aplicaciones y sistemas informticos ms complejos, entre los que destacan los siguientes: Modelo mental anmalo. Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras la programacin clsica se basa en el comportamiento, representado usualmente por verbos. Es difcil modificar y extender los programas, pues suele haber datos compartidos por varios subprogramas, que introducen interacciones ocultas entre ellos. Es difcil mantener los programas. Casi todos los sistemas informticos grandes tienen errores ocultos, que no surgen a la luz hasta despus de muchas horas de funcionamiento. Es difcil reutilizar los programas. Es prcticamente imposible aprovechar en una aplicacin nueva las subrutinas que se disearon para otra.

Mtodo de Anlisis Orientado a Objetos

El Anlisis Orientado a Objetos (AOO) se define como "un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", los objetos son entidades tangibles que muestran un comportamiento bien definido. Todo esto quiere decir que el anlisis orientado a objetos parte de entidades tangibles halladas en el problema, tales entidades varan dependiendo de los diversos casos prcticos, pero en todos los casos son elementos reales que toman parte del problema de forma directa. El Diseo Orientado a Objetos (DOO) "es el mtodo que lleva a una descomposicin Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economa de expresin. Se logra un mayor nivel de confianza en la correccin del software a travs de la divisin inteligente de su espacio de estados. En ltima instancia, se reducen los riesgos inherentes al desarrollo de sistemas. Los modelos del diseo orientado a objetos reflejan la importancia de plasmar explcitamente las jerarquas de clases y objetos del sistema que se disea. Estos modelos cubren tambin el espectro de las decisiones de diseo relevantes que hay que considerar en el desarrollo de un sistema complejo, y as animan a construir implantaciones que posean los atributos de los sistemas complejos bien formados.

Etapas
1) Anlisis de Requerimientos (Modelo Conceptual) En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se va a presentar la solucin que se est buscando. Se examina los requisitos desde la perspectiva de los objetos y clases del dominio del problema. Actividades de esta etapa: Diagramar los casos de usos los cuales son una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema cuando el actor usa el sistema para llevar a cabo una tarea especfica.

 Detallar o describir la informacin de entrada y salida de cada caso de uso por medio de Diagramas de interaccin de detalle (de secuencia o colaboracin). Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. Un Diagrama de Colaboracin muestra una interaccin organizada basndose en los objetos que toman parte en la interaccin y los enlaces entre los mismos (en cuanto a la interaccin se refiere). Definir la interfaz inicial del sistema (si es aplicable), lo cual puede hacerse por medio de un diagrama de estados el cual muestra la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera. Tambin puede definirse una interfaz inicial por medio de una descripcin textual del funcionamiento, diagramas de interaccin o de un prototipo funcional. Desarrollar el modelo del mundo mediante un diagrama de estructura esttica de clases. Se deben identificar Clases Elementos fsicos y lgicos dentro del sistema a modelar, comenzando por la clase del objeto ms general (el mundo) Top-down, encontrando sus componentes hasta llegar a clases de tipos bsicos. Validar los modelos o restricciones descritas para las clases. Para cada clase evaluar la completitud de las restricciones, desarrollar objetos ejemplo que

 2) Diseo del sistema (Diagrama de Clases) En esta etapa se define una subdivisin en aplicaciones del sistema (si es lo suficientemente grande) y la forma de comunicacin con los sistemas ya existentes con los cuales debe interactuar. Actividades: Definir componentes del sistema, las aplicaciones y su ubicacin. Representarlos por medio de nodos, componentes y objetos activos (representando las aplicaciones) dentro de los nodos. Definir mecanismos de comunicacin. Expresarlos por medio de asociaciones de dependencia entre los nodos, componentes o aplicaciones y, si es conocido, agregar un estereotipo para definir el protocolo de comunicacin requerido. Agregar notas con restricciones, rendimiento esperado y dems detalles de las conexiones. Particularizar los casos de uso a la arquitectura planteada. Refinar los casos de uso ya existentes de la etapa anterior para adecuarse a la arquitectura planteada. Validar arquitectura. Comprobar la validez tcnica, econmica y organizacional de la propuesta.

 3) Diseo detallado En esta etapa se adapta el anlisis a las caractersticas especficas del ambiente de implementacin y se completan las distintas aplicaciones del sistema con los modelos de control, interfaz o comunicaciones, segn sea el caso
Actividades: Detalles de implementacin del modelo del mundo: Completar detalles de las clases, atributos, diseo de asociaciones, mtodos, etc Desarrollar el modelo de interfaz: Enlazar las clases de interfaz con las clases del modelo del mundo Desarrollar los modelos de control, persistencia y comunicaciones

 4) Implementacin y pruebas Se desarrolla el cdigo de una manera certificada. Actividades: Definir estndares de programacin Codificacin y pruebas unitarias: Revisiones de cdigo Pruebas de mdulos y de sistema: Se aplican algunos casos de prueba para el Procedimiento de instalacin.

Caractersticas de la Orientacin a Objetos

Abstraccin: Denotacin de caractersticas fundamentales. Ocultacin: Encapsulamiento de la implementacin. Modularidad: Fragmentacin en componentes individuales. Jerarqua: Clasificacin de las abstracciones. Tipificacin: Caracterizacin de propiedades de una serie de entidades. Concurrencia: Existencia de objetos activos. Persistencia: Trascendencia en tiempo y/o espacio

Ventajas de la Orientacin a Objetos

Las principales ventajas del mtodo orientado a objetos descansan en su posibilidad de hacer frente a dos temas esenciales: Gestin de la complejidad y Mejora de la Productividad en el proceso de desarrollo del software, los cuales son gestionadas a travs de las siguientes estrategias: Escribir cdigo reutilizable Escribir cdigo posible de mantener Depurar mdulos de cdigo existentes Compartir cdigo con otros La complejidad se reduce y la productividad se mejora cuando se pueden volver a utilizar un cdigo de alta calidad. Los mecanismos orientados a objetos en particular la herencia fomentan la reutilizacin as

Proceso Actual de Compensacin de Cheques utilizando el Mtodo Estructurado Este proceso se efecta de manera manual, contando con el apoyo de algunos sistemas para el registro de informacin y procesamiento de clculos.

Proceso Propuesto de Compensacin de Cheques utilizando el Mtodo Estructurado Se propone un proceso que cuente con una plataforma centralizada para todas las Instituciones Financieras a travs de la cual se envn los cheques al cobro y en devolucin, que efecte los clculos, proporciones los resultados en medios electrnicos y permita el monitorero en lnea del comportamiento del proceso

Proceso Actual de Compensacin de Cheques Utilizando el Mtodo Orientado a Objetos Este proceso se efecta de manera manual, contando con el apoyo de algunos sistemas para el registro de informacin y procesamiento de clculos.

Proceso Propuesto de Compensacin de Cheques utilizando el Mtodo Estructurado

Se propone un proceso que cuente con una plataforma centralizada para todas las Instituciones Financieras a travs de la cual se enven los cheques al cobro y en devolucin, que efecte los clculos, proporciones los resultados en medios electrnicos y permita el monitoreo en lnea del comportamiento del proceso

UML como metodologa de Anlisis y diseo

Lenguaje Unificado de Modelado es el lenguaje mas conocido y utilizado en la actualidad. Es un lenguaje grafico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un plano del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de base de datos y compuestos reciclados. Sirve para especificar o describir mtodos y procesos, se utilizar para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

 UML no puede comparase con la programacin estructurada, ya que no se programa solo se diagrama la realidad de una utilizacin de un requerimiento.

Los Principales beneficios de UML

Mejores Tiempos totales de desarrollo (50% o ms). Modelar sistemas (y no solo de software) utilizando conceptos orientados a objetos Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica. Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas Mejor soporte a la planeacin y al control de proyectos Alta reutilizacion y mininizacion de costos

UML esta compuesto por

Modelo

Vistas

Diagramas

Smbolos

Reglas

Diagramas
Son graficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer todas las vistas de un sistema: Diagramas de caso de uso, Diagramas de clase Diagramas de Objetos Diagramas de Estados Diagramas de secuencia, Diagramas de colaboracin Diagramas de Actividad Diagramas de componentes Diagramas de Distribucin

 Muestran los diferentes aspectos del sistema modelado. Una vista no es una grfica, pero s una abstraccin que consiste en un numero de diagramas y todos esos diagramas juntos muestran una fotografa completa del sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son: Vista de caso de uso: muestra la funcionabilidad del sistema como la perciben los actores externos Vista Lgica: Muestra como se disea la funcionalidad dentro del sistema, en terminos de la estructura esttica y la conducta dinamica del sistema. Vista de componentes: muestra la organizacin de los componentes de cdigo. Vista concurrente: muestra la concurrencia en el sistema, direccionando los problemas con la comunicacin y sincronizacin que estn presentes en un sistema.Vista de distribucin: muestra la distribucin del sistema en la arquitectura fsica con computadoras y dispositivos llamados nodos

VISTAS

Smbolos o elementos de modelo

Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes y las relaciones entre estos conceptos incluyendo la asociacin dependencia y generalizacin. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbologa.

Reglas y mecanismos generales

Proveen comentarios extras, informacin o semntica acerca del elemento de modelo; adems proveen mecanismos de extensin para adaptarse o extender UML a un mtodo o proceso especfico, organizacin o usuario.

METODO HIPO
Las siglas nos recuerdan las tres partes principales de cualquier sistema: entrada, proceso y salida. Una vez que se ha terminado la grfica de jerarqua, se trazan otros diagramas HIPO en pginas divididas verticalmente en tres secciones, con la seccin de entrada a la izquierda, la seccin de proceso en el medio y la seccin de salida a la derecha. Hay tres tipos principales de diagramas en el sistema HIPO: VTOC o tabla visual de contenido. Diagramas de panormica HIPO (entrada/proceso/salida). Diagramas detallado HIPO.

LA VTOC (Tabla de contenido visual)

La VTOC es la grfica jerrquica. Proporciona un mapa que permite al lector localizar un mdulo de programa dentro del sistema principal. Las etiquetas o nmeros indicados a los mdulos dados en la VTOC son usados en los diagramas de panormica HIPO y diagramas detallados IPO

Diagramas de panormica HIPO

permite una vista macro de la entrada, proceso y salida. Por lo tanto es til listar todas las entradas, procesos y salidas en las tres secciones del papel sin trazar los smbolos especializados. Por otro lado existen los diagramas detallados HIPO, los cuales son ms tiles, porque en estos los diagramas panormicos generales son divididos para cada uno de los mdulos que contienen.

Diagramas detallado HIPO

El flujo de datos es representado como los datos listados en las columnas Entrada y Salida. Los almacenes de datos se traducen a los smbolos de disco o cinta, y los flujos de datos impresos enviados al usuario se convierten en smbolos de reporte

Fortalezas y debilidades del HIPO

El HIPO es una tcnica altamente visual y algo estructurada para el diseo y documentacin. El HIPO para a ser una herramienta demasiado especializada. Por el desconocimiento en la organizacin de su simbologa. El HIPO se lleva una considerable cantidad de espacio en papel. As los diagramas hijo son usados mas frecuente para representar los detalles de cada mdulo en una grfica de estructura y para preparar el cdigo de programa de computadora. El HIPO es til para la documentacin de programas. Porque con ello los autores pueden fcilmente recordarse de sus trabajos, despus de un largo tiempo. Y otros programadores que comprendan los smbolos puedan entender lo realizado y ser utilizados en las plticas o conversaciones estructuradas.

Grficas Nassi-Shneiderman
Un enfoque ms estructurado pero menos visual para el diseo y la documentacin es la grfica Nassi-Shneiderman (N-S). La principal ventaja de la grfica (N-S) es que adopta la filosofa de la programacin estructurada. La figura 12 muestra los tres smbolos bsicos que se usa en las grficas N-S. En la figura 13 se muestra la grfica N-S de un sistema de actualizacin de suscripciones de peridico.