TABLA DE CONTENIDO CAPITULO 1: INTRODUCCION

Fundamentos de sistemas de informacin

Modelos
Modelo Fsico y Conceptual Ciclo de vida del software

Otros modelos de desarrollo de software

CAPITULO 2: REQUERIMIENTOS
Tcnicas para recolectar informacin Determinacin de requerimientos bsicos

CAPITULO 3: METODOS ESTRUCTURADOS DE DESARROLLO

Mtodos estructurados
Mtodos orientados a procesos Mtodos orientados a los datos

CAPITULO 4: ANALISIS
Diagramas de Flujos de Datos

Especificacin de procesos Diccionario de datos Diagramas de transicin de estados Diagramas entidad relacin Especificacin de requisitos

CAPITULO 5: DISEO

Introduccion al diseo
Anlisis de las transacciones y transformaciones

Diseo de entradas Diseo de salidas Diseo del dilogo GUI (interfaz grfica de usuario) Diseo modular Diseo procedimental

TALLERES EVALUACIONES ANTERIORES

HERRAMIENTAS CASE UTILIZADAS EN EL CURSO BIBLIOGRAFIA

CAPITULO 1: INTRODUCCION FUNDAMENTOS DE SISTEMAS DE INFORMACION

1. SISTEMAS ORGANIZACIONALES Los sistemas organizacionales tienen como fin producir bienes, productos y/o servicios que satisfacen la demanda de un mercado. Para lograr esto, interactan con elementos del ambiente para adquirir los materiales necesarios, los obreros y el conocimiento para fabricar los bienes. 2. SISTEMAS DE INFORMACIN ORGANIZACIONALES Los sistemas de informacin estn formados por subsistemas que incluyen hardware, software, procedimientos, usuarios (clasificados en directos, indirectos, administradores y directivos) los datos y la informacin. 3. CLASIFICACIN DE SISTEMAS DE INFORMACIN Los sistemas de informacin se clasifican en: a. Sistemas de Procesamiento de Transacciones: Los que llevan a cabo las actividades cotidianas en la organizacin. Los procedimientos estndar de operacin que facilitan el manejo de las transacciones incluyen, en general, los programas de cmputo que controlan la entrada de datos, el procesamiento de los detalles y almacenamiento y presentacin tanto de datos como de informacin.

b. Sistemas de Informacin Administrativos: Orientados hacia la toma de decisiones y utilizan datos relacionados con las transacciones as como cualquier otra informacin que sea generada dentro o fuera de la compaa. c. Sistemas para el Soporte de Decisiones: Ayudan a los directivos a resolver problemas no estructurados, no recurrentes, problemas de decisin nicos, donde es importante determinar qu tipo de informacin se debe considerar.

MODELOS 1. INTRODUCCIN Los analistas y diseadores de sistemas de informacin basan sus trabajos en la generacin de modelos que permitirn la resolucin de problemas. Estos modelos se clasifican en cuatro tipos bsicos: fsicos, narrativos, grficos y matemticos. Todos ellos facilitan tanto la comprensin como la comunicacin, y el modelo matemtico tiene la caracterstica especial de predecir el futuro. Algunos modelos representan sus entidades de forma muy especfica, mientras que otros lo hacen de manera muy general. Un modelo general tiene la ventaja de aplicar a una amplia variedad de situaciones. Se presenta un modelo general de una compaa que consiste tanto en un sistema fsico como en un sistema conceptual. El sistema fsico incluye un elemento de entrada, un elemento de transformacin y un elemento de salida, adems establece una ruta para el flujo de recursos fsicos. El sistema conceptual consiste en datos e informacin que representan el sistema fsico. Las partes integrales del sistema conceptual son un ciclo de retroalimentacin, un mecanismo de control y los estndares de desempeo. El mecanismo de control en una compaa comercial est representado por la gerencia, y el ciclo de retroalimentacin est representado por el flujo de informacin. Se obtienen datos del sistema fsico y se transforman en informacin por medio de un procesador de informacin. Los gerentes comparan la informacin del procesador de informacin con los estndares que especifican niveles aceptables o intervalos de desempeo, y deciden actuar slo cuando el desempeo se sale del intervalo aceptable. El desempeo podra ser mejor o peor que el esperado. El concepto de atender slo actividades que ameritan la atencin del gerente se denomina administracin por excepcin. Un concepto similar, que se ocupa de los factores crticos para el xito, implica vigilar unas cuantas acciones selectas que contribuyen al xito de la compaa.

Una vez que la gerencia determina que deben efectuarse cambios al sistema fsico, esas decisiones se comunican a los elementos apropiados del sistema. Puesto que el modelo general de sistemas de la compaa representa todos los tipos de organizaciones y muestra cmo se usa la informacin para manejar una organizacin, resulta un modelo til tanto para los gerentes como para los especialistas en informacin. 2. MODELOS Un modelo es una abstraccin de algo; representa algn objeto o actividad, que se denomina entidad. Los gerentes usan modelos para representar los problemas que es preciso resolver. Los objetos o actividades que causan problemas son las entidades. Hay cuatro tipos bsicos de modelos:

a. Modelos fsicos b. Modelos narrativos c. Modelos grficos d. Modelos matemticos

a. Modelos Fsicos: Un modelo fsico es una representacin tridimensional de su entidad. Los modelos fsicos que se usan en el mundo de los negocios incluyen modelos a escala de centros comerciales y prototipos de automviles nuevos. El modelo fsico tiene un uso que no puede tener el objeto real. Por ejemplo, es mucho menos costoso para quienes invierten en un centro comercial o en la fabricacin de automviles hacer cambios en los diseos de sus modelos fsicos que en los productos finales mismos. De los cuatro tipos de modelos, es probable que el modelo fsico sea el que menor valor tiene para el gerente de negocios. Generalmente no es necesario que un gerente vea algo en una forma fsica para poder entenderlo o usarlo en la resolucin de problemas.

b. Modelos Narrativos: Un tipo de modelo que los gerentes usan a diario rara vez se reconoce como un modelo. Se trata del modelo narrativo, que describe su entidad con palabras verbales o escritas. El escucha o lector puede entender la entidad a partir de la narrativa. Todas las comunicaciones de negocios son modelos narrativos, lo que convierte al modelo narrativo en el tipo de modelo ms utilizado. c. Modelos Grficos: Otro tipo de modelo que se usa todo el tiempo es el modelo grfico. Un modelo grfico representa su entidad con una abstraccin de lneas, smbolos o figuras. En los negocios se usan modelos grficos para comunicar informacin. Los informes anuales de muchas corporaciones a sus accionistas contienen grficas multicolores que comunican la condicin financiera de la compaa. Tambin se usan grficas para comunicar informacin a los gerentes. El modelo grfico de la figura ilustra uno de los conceptos ms populares en los negocios: la cantidad econmica de pedido.

La cantidad econmica de pedido (EOQ, economic order quantity) es la cantidad ptima de reabastecimiento de existencias que debe ordenarse a un proveedor. La EOQ balancea los costos de adquirir las existencias y los costos de mantenerlas. La lnea que baja desde la izquierda en la figura representa el costo de compra unitario, que disminuye a medida que aumenta la cantidad ordenada. La lnea que sube de izquierda a derecha representa el incremento lineal del costo de mantenimiento a medida que aumenta la cantidad ordenada. Ambos costos se suman para dar la curva de costo total.

El punto ms bajo de la curva de costo total representa la EOQ. Tambin se usan modelos grficos en el diseo de sistemas de informacin. Muchas de las herramientas que el analista de sistemas y el programador usan son de naturaleza grfica. Los diagramas de flujo y los diagramas de flujo de datos son ejemplos, y se ilustran en la siguiente figura.

d.

Modelos Matemticos: Al modelo matemtico se debe la mayor parte del inters actual

en el modelado de negocios. Cualquier frmula o ecuacin matemtica es un modelo matemtico. Muchos de los modelos matemticos que los gerentes de negocios usan no son ms complejos que el que se emplea para calcular la EOQ:

EOQ=

_2PS_ M

Donde P es el costo de compra unitario (en dlares), S son las ventas anuales (en unidades) y M es el costo anual de mantenimiento por unidad (en dlares). El costo de mantenimiento incluye todos los costos en que se incurre al almacenar el artculo, como seguro, desperdicio y prdida por robo. El modelo de EOQ emplea una sola ecuacin. Algunos modelos matemticos usan cientos o incluso miles de ecuaciones. Por ejemplo, un modelo de planificacin financiera creado por la Sun Oil Company durante los primeros aos de su sistema de informacin gerencial usaba aproximadamente 2000 ecuaciones. Los modelos grandes de este tipo tienden a ser complejos y difciles de usar. La tendencia actual es hacia el uso de modelos ms pequeos cuyo propsito es ayudar a ciertos gerentes a resolver problemas especficos. Una gran ventaja del modelo matemtico es la precisin con que describe las relaciones entre las partes de un objeto. Las matemticas manejan relaciones que se expresan en ms de las dos dimensiones del modelo grfico o las tres dimensiones del modelo fsico.

Para el matemtico y para el gerente que reconoce la complejidad de los sistemas de negocios, la capacidad multidimensional del modelo matemtico es muy valiosa. 3. USOS DE LOS MODELOS Los cuatro tipos de modelos facilitan tanto la comprensin como la comunicacin. Los modelos matemticos tienen, adems, una capacidad de prediccin. a. Facilitar la Comprensin: Un modelo generalmente es ms sencillo que su entidad. Es ms fcil entender la entidad si sus elementos y sus interrelaciones se presentan de manera simplificada. Los cuatro tipos de modelos llegan a variar en sus detalles. Un modelo fsico puede representar slo las caractersticas de inters; una narrativa puede reducirse a un resumen; un diagrama puede mostrar slo las principales relaciones; y una ecuacin matemtica puede contener slo ingredientes primarios. En cada caso, se procura presentar el modelo en una forma simplificada. Una vez que se han entendido estos modelos sencillos, se pueden hacer ms complejos gradualmente para representar con mayor exactitud sus entidades. Sin embargo, los modelos slo representan sus entidades, nunca son idnticos a ellas. b. Facilitar la comunicacin: Una vez que la persona que va a resolver el problema entiende la entidad, es comn que necesite comunicar ese entendimiento a otros. Quiz el analista de sistemas deba comunicarse con otros miembros del equipo que van resolver el problema. Los cuatro tipos de modelos comunican informacin con rapidez y exactitud a las personas que entienden el significado de las formas, palabras, grficos y frmulas matemticas. c. Predecir el Futuro: La precisin con que el modelo matemtico puede representar su entidad le confiere una capacidad especial que no pueden ofrecer los otros tipos de modelos. El modelo matemtico puede predecir lo que puede ocurrir en el futuro, pero no es 100% exacto. Ningn modelo es tan bueno. Dado que casi siempre es necesario suponer

cosas acerca de gran parte de los datos que se alimentan del modelo, el gerente debe aplicar su juicio e intuicin para evaluar los resultados. Tomado de: "Sistemas de Informacin gerencial, McLeod."

MODELO FISICO Y CONCEPTUAL 1. EL MODELO GENERAL DE SISTEMAS El vehculo que se utiliza como fundamento principal para la descripcin de los sistemas organizacionales se denomina modelo general de sistemas de la compaa. Se trata de un diagrama grfico acompaado de una narrativa que representa a todas las organizaciones de manera general, empleando un marco de referencia de sistemas.
a. El Sistema Fsico: El sistema fsico de la compaa transforma recursos de entrada en recursos de salida. Los recursos de entrada provienen del entorno de la compaa, ocurre una transformacin y se devuelven recursos de salida al mismo entorno. Por tanto, el sistema fsico de la compaa es un sistema abierto, que interacta con su entorno por medio de flujos de recursos fsicos.

Aunque la figura representa cualquier tipo de compaa, resulta especialmente fcil percibir su correspondencia con una operacin de manufactura en la que materias primas se transforman en productos terminados. Los otros tres recursos fsicos mquinas, dinero y recursos humanos- tambin fluyen. b. Flujo de materiales: Los materiales de entrada se reciben de los proveedores de materias primas, piezas y componentes ensamblados. Estos materiales se conservan en un rea de almacenamiento hasta que se requieren para el proceso de transformacin. Luego, pasan a la actividad de manufactura. Al trmino de la transformacin, los materiales, que ahora estn en su forma acabada, se colocan en un rea de almacenamiento hasta ser entregados a los clientes. En una empresa manufacturera, son dos las reas funcionales que intervienen en este flujo de materiales. La funcin de manufactura transforma la materia prima en productos terminados y la funcin de mercadotecnia distribuye los productos finales a los clientes. Estas dos reas deben funcionar juntas para facilitar el flujo de materiales.

c. Flujo de personal: Las entradas de personal se originan en el entorno. Los prospectos de empleados llegan de la comunidad global y tal vez de los sindicatos laborales y los competidores. Este aporte de personal generalmente es procesado por la funcin de recursos humanos y luego se asigna a diferentes reas funcionales. Mientras estn en esas reas, los empleados intervienen en el proceso de transformacin, ya sea de manera directa o indirecta. Algunos de los empleados salen de la compaa poco tiempo despus de ingresar en ella. Otros se quedan hasta su retiro. La funcin de recursos humanos procesa la terminacin, y el recurso se devuelve al entorno. d. Flujo de mquinas: Las mquinas se obtienen de proveedores y por lo regular permanecen en la compaa durante largos periodos, de tres a veinte aos aproximadamente. Tarde o temprano, todas las mquinas regresan al entorno en forma de cambios por modelos nuevos o como chatarra. Mientras estn en la compaa, las mquinas casi nunca se almacenan; ms bien estn disponibles continuamente, ya sea como camiones de entrega en la divisin de mercadotecnia, calculadoras de escritorio en el departamento de contabilidad, o prensas taladradoras en la divisin de manufactura. En virtud de tener fuentes de suministro especiales, no almacenarse dentro de la compaa y tener destinos de desecho especiales, el flujo de mquinas es el ms directo de los flujos de recursos fsicos. Por otra parte, el control del flujo de mquinas est disperso entre todas las reas que usan las mquinas. e. Flujo de dinero: El dinero se obtiene primordialmente de los dueos, que proporcionan capital de inversin, y de los clientes de la compaa, que proporcionan ingresos por ventas. Otras fuentes incluyen las instituciones financieras, que otorgan prstamos y pagan intereses por inversiones, y el gobierno, que proporciona dinero en forma de prstamos y subvenciones. Aunque varias fuentes proporcionan dinero, la responsabilidad primaria de controlar el flujo de dinero recae sobre la funcin financiera.

El flujo de dinero a travs de la firma es inusitado en un sentido. Casi nunca interviene dinero fsico. Ms bien, hay un flujo de algo que representa dinero: cheques, vales de tarjeta de crdito e incluso transacciones en forma electrnica. Slo en el nivel de venta al detalle el dinero en efectivo cambia de manos, e incluso aqu est cediendo terreno a otras formas de pago. As, el flujo de dinero conecta a la compaa con sus instituciones financieras, clientes, proveedores, accionistas y empleados. En algunos casos, la compaa retiene fondos especiales durante largo tiempo. Un ejemplo es un certificado de depsito a cinco aos. En otros casos hay un recambio rpido de dinero, como cuando los ingresos por ventas se convierten rpidamente en cheques a pagar a proveedores y empleados

2. EL SISTEMA CONCEPTUAL Algunos sistemas abiertos pueden controlar sus propias operaciones; otros no. El control se logra por medio de un ciclo que se incorpora en el sistema. El ciclo, llamado ciclo de retroalimentacin, proporciona un camino para que viajen seales del sistema a un mecanismo de control, y del mecanismo de control de vuelta al sistema. El mecanismo de control es un dispositivo de algn tipo que usa las seales de retroalimentacin para evaluar el desempeo del sistema y determinar si se requieren acciones correctivas.

a. Sistemas de ciclo abierto: Ya sealamos en el captulo 1 que un sistema sin ciclo de retroalimentacin ni mecanismo de control se denomina sistema de ciclo abierto. El sistema de la figura 6.3, adems de ser un sistema abierto, es un sistema de ciclo abierto. No hay retroalimentacin del sistema para efectuar cambios necesarios en el mismo. Es probable que haya unas cuantas compaas de negocios del tipo de ciclo abierto. Son sistemas abiertos, pero los mecanismos de retroalimentacin y control no funcionan como debieran. Las compaas se embarcan en un curso determinado y nunca cambian de direccin. Si se salen de control, nada se hace para reestablecer el equilibrio, y se tiene como resultado la destruccin del sistema (quiebra).

b. Sistemas de ciclo cerrado:

En la figura se muestra un sistema de ciclo cerrado, que

cuenta con un ciclo de retroalimentacin y un mecanismo de control. Un sistema as puede controlar sus salidas haciendo ajustes a sus entradas.

En la figura se muestra una compaa de negocios como un sistema de ciclo cerrado. El ciclo de retroalimentacin consiste en informacin. El mecanismo de control es la gerencia de la compaa. La gerencia se basa en la informacin para hacer cambios en el sistema fsico. c. Control gerencial: Como se muestra en la figura 6.5, la gerencia recibe informacin que describe las salidas del sistema. Muchos informes gerenciales incluyen este tipo de informacin: volumen de produccin, costos de distribucin, anlisis de ventas, etc. Puesto que el propsito principal de la compaa es producir algn tipo de salidas, una medida de las salidas forma parte integral del control del sistema. Un ejemplo de informes de salidas de un sistema es por ejemplo, un informe de ventas de productos en rpido movimiento. El informe dirige la atencin del gerente hacia los productos que se estn vendiendo mejor. El gerente determina entonces por qu esos

productos se estn vendiendo bien y usa sus hallazgos para incrementar las ventas de otros productos. La retroalimentacin de salidas es valiosa para el gerente, pero ste debe conocer tambin la situacin de las entradas y de los procesos de transformacin. Por ejemplo, el gerente desea informacin que describa tanto qu tan bien los proveedores estn satisfaciendo las necesidades de la compaa en cuanto a materiales de entrada, como la eficiencia de produccin de la operacin de manufactura. El anlisis de proveedores es informe acerca de las entradas al sistema. Este anlisis de un proveedores compara los proveedores de un tipo especfico de materia prima en trminos de precio, entrega y calidad. Un comprador del departamento de compras podra solicitar un informe de este tipo antes de decidir quin ser el siguiente proveedor. Un informe sobre la situacin del procesamiento de transformacin puede informar a la gerencia. Un gerente de produccin desea conocer los detalles de un trabajo especfico que se est realizando. El gerente introduce el nmero de un trabajo en una terminal y la computadora exhibe la informacin. El gerente ve que el trabajo est en el paso 4, en el departamento 410, que el paso se inici el 8 de octubre a las 10:15 A.M., y que el trabajo deber completarse para el 14 de octubre a las 9:30 A.M. este ejemplo ilustra cmo el sistema conceptual puede mantener al gerente actualizado respecto a la situacin del sistema fsico.
d. El procesador de informacin:

La informacin no siempre viaja directamente del sistema fsico al

gerente. Muchos gerentes se encuentran a cierta distancia de la actividad fsica, por lo que deben obtener informacin de un sistema o procedimiento que produce la informacin a partir de datos recolectados. Llamamos al mecanismo productor de informacin procesador de informacin. La figura 6.10 incluye la adicin del procesador de informacin que, en este anlisis, suponemos que es una computadora. Sin embargo, no es necesario que sea una computadora.

e. Estndares: Para que el gerente ejerza control sobre su rea de responsabilidad, se requiere dos ingredientes. Primero, debe haber informacin que describa lo que el rea est logrando. Segundo, debe haber estndares de desempeo que reflejen lo que el rea debera lograr. Podemos definir un objetivo como la meta general que un sistema deba alcanzar. Un sistema debe tener al menos un objetivo, pero es comn que haya varios. Normalmente, los objetivos se plantean en trminos generales. Para que los gerentes puedan controlar el sistema, necesitan algo ms especfico que los objetivos, y es aqu donde entran los estndares. Un estndar es una medida del desempeo aceptable, que idealmente se plantea en trminos especficos. La tabla 6.1 ilustra la diferencia entre la naturaleza general de los objetivos y la naturaleza especfica de los estndares. El gerente usa los estndares para controlar el sistema fsico comparando el desempeo real, que se refleja en los informes del procesador de informacin, con los estndares. Los resultados de la comparacin determinan si es necesario tomar medidas. La figura 6.11 ilustra la adicin de los estndares necesarios al modelo general. As, el sistema conceptual que controla el sistema fsico consiste en tres elementos clave: gerencia, procesador de informacin y estndares

3. EL ENTORNO

La forma final del modelo general reconoce que los recursos fluyen haca la compaa desde el entorno y salen de la firma para volver al entorno. Los recursos fsicos fluyen a travs del sistema fsico en la parte inferior del modelo. Los recursos conceptuales (informacin y datos) entran en el procesador de informacin, donde se almacenan o bien se proporcionan al gerente.

Tomado de: "Sistemas de Informacin gerencial, McLeod."

CICLO DE VIDA DE UN SOFTWARE Las etapas del ciclo de vida son las siguientes: Pre anlisis (requerimientos). 1. 2. 3. 4. 5. Anlisis (especificaciones). Diseo Codificacin Implementacin Operacin y mantenimiento

1. Pre anlisis: Cobija bsicamente el estudio de la factibilidad de un proyecto, con el fin de determinar si un sistema particular ser desarrollado, respondiendo a la pregunta de que tan factible es econmica, tcnica y operativamente.

Entradas: Declaracin de las necesidades del usuario sobre el sistema de informacin especfico. Salidas: Documento con el estudio de factibilidad que contiene: Ubicacin general del sistema:

- Descripcin del rea que maneja el sistema. - Ubicacin del sistema dentro del rea. - Objetivos y alcances. - Restricciones.

Definicin del sistema:

- Medio ambiente. - Entradas y salidas. - Componentes principales y sus relaciones * Recursos con que se cuenta: - Personal - Dinero - Hardware y software

Estimativos del proyecto:

- Tamao - Tiempo de duracin - Nmero de personas para el desarrollo - Costo

Anlisis de factibilidad:

- Factibilidad econmica - Factibilidad tcnica - Factibilidad operativa

Alternativas y recomendaciones Diagrama de actividades

2. Anlisis: Es la coleccin, organizacin y evaluacin de hechos del sistema y el medio ambiente en el cual opera, con el objeto de establecer las bases de un nuevo sistema. Responde a la pregunta de qu es lo que va a hacer el sistema? Entradas: - Estudio de factibilidad. - Requerimientos ms detallados Salidas: - Modelo de funcionamiento del sistema o especificacin a travs de un documento objetivo. Qu son las especificaciones? - Representacin grfica del sistema, aplicando el enfoque de un diagrama de flujo de datos (DFD)

- Diccionario de datos (D.D), define todos los trminos utilizados en el DFD. - Diagrama de estructura de datos (DSD), representa las relaciones existentes entre los diferentes almacenamientos de informacin que ir a utilizar el sistema. - Mini especificaciones: Es la descripcin estructurada de lo que har cada proceso o subproceso del sistema.

3. Diseo: Responde a la pregunta cmo se va a hacer el sistema? Consta de tres partes: 3.1 Diseo global: Es la concepcin global y estructural del sistema, en la que se definen las interfaces y mdulos del sistema.

Entradas: Especificaciones del anlisis. Salidas: Descripcin estructural del sistema, por medio de diagramas estructurados. 3.2. Diseo detallado: Aqu cada mdulo se detalla al mximo.

Entradas: Diagramas estructurados. Salidas: Seudocdigo o algoritmo.

4. Codificacin: Programacin en un lenguaje especfico.

Entradas: Seudocdigo. Salidas: Programacin en lenguaje fuente.

5. Implementacin o prueba: Valida el sistema con datos ficticios y luego con datos reales.

Entradas: Programas. Salidas: Sistema disponible.

6. Operacin y mantenimiento. El sistema comienza a funcionar, y se le pueden hacer mejoras, corregir errores y/o generar nuevas versiones.

CAPITULO 2: REQUERIMIENTOS DETERMINACION DE REQUERIMIENTOS (pre anlisis ) 1. CONSIDERACIONES GENERALES: 1.1. Objetivos del pre anlisis:

Determinar la factibilidad econmica, tcnica y operativa, de un proyecto de software, surgido de las necesidades de informacin de un rea especfica. De acuerdo a esta factibilidad se decidir si el sistema vale la pena no desarrollar el sistema.

Lograr un conocimiento general y estructurado de los requerimientos de informacin de un sistema, como fundamento para estimar y proyectar los recursos necesarios para su desarrollo. Plantear distintas alternativas de desarrollo de un sistema, con el fin de que la alta direccin adquiera bases suficientes para decidir (de acuerdo a los objetivos administrativos), cual alternativa implementar. Realizar una planeacin general de actividades para el desarrollo efectivo del sistema. (Esto en caso que exista factibilidad).

1.2. Definicin general del pre anlisis: Etapa preliminar en el desarrollo del sistema de informacin computarizado, el cual transforma las inquietudes y requerimientos generales de informacin de un rea especfica, en un estudio de factibilidad que contiene la definicin organizada de esos requerimientos, los recursos con que se cuenta para solucionar dichas necesidades, los estimativos de desarrollo de el nuevo sistema, el anlisis de factibilidad, alternativas de desarrollo y cronograma de actividades. 1.3. Importancia del pre anlisis:

Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el trabajo por realizar en la etapa de anlisis. Evita el desarrollo de sistemas que a nivel econmico, tcnico u operativo, sera un fracaso para la empresa. Permite planear con tiempo los recursos requeridos para el desarrollo de un sistema.

Aterriza al personal administrativo, usuarios, tcnicos en sistemas y auditores, respecto a las alternativas reales del sistema.

1.4. Participacin requerida: El desarrollo del pre anlisis implica la participacin de un grupo interdisciplinario de personas de reas distintas, cada uno de los cuales tiene sus propios intereses.

LOS USUARIOS: Son los elementos ms importantes en este grupo, ya que son los que define el problema de informacin existente. Es conveniente que participe directamente el usuario responsable del rea, o sea el Directivo encargado de la Dependencia. En forma complementario, los usuarios Directos u operativos del sistema existente.

PERSONAL DE SISTEMAS: Debe participar para los aspectos de tipo general, el Director de Sistemas o jefe de Anlisis y Programacin, y para el desarrollo concreto del estudio el analista de sistemas encargado del proyecto. Este analista deber tener conocimientos administrativos del rea por sistematizar.

AUDITORIA: Se debe asignar un auditor de sistemas para el proyecto, y este debe participar desde la etapa de pre anlisis , estableciendo objetivos generales de control y requerimientos de informacin de auditoria.

2. PASOS EN EL DESARROLLO DEL PREANLISIS 2.1. Reconocimiento general del sistema: En este punto se pueden contemplar varios aspectos, que en todos los casos no son necesarios desarrollar; todo depende de las condiciones administrativas del proyecto. CONTENIDO: 2.1.1. Ubicacin general del sistema:

Su objetivo es ubicar la necesidad de informacin planteada, dentro del medio ambiente de la organizacin. Puede contener: a. Descripcin y definicin de las caractersticas generales de la empresa. (objeto social, tamao, estructura organizativa, ubicacin geogrfica, recursos con que cuenta, sector al que pertenece). Esto puede ser importante cuando el pre anlisis se realiza a travs de personal externo o va dirigido a personas externas a la compaa. b. Descripcin y definicin del rea donde se va a desenvolver el sistema. c. Ubicacin del sistema (necesidad de informacin), dentro del rea. 2.1.2. Delimitacin o alcance del sistema: Busca definir los lmites hasta donde se piensa expandir dentro del rea, la solucin a las necesidades de informacin expuestas. Normalmente esta delimitacin se refleja en el nombre que llevar el sistema. 2.1.3. Objetivos del sistema:

Estos debern ser muy claros y especficos. Deben reflejar la satisfaccin de las necesidades de informacin, beneficios organizativos y beneficios econmicos. 2.1.4. Restricciones del sistema: Estos pueden ser de dos tipos.

Externas: Aquellas generadas a partir del medio ambiente, en este caso la organizacin.

EJEMPLO: - Dificultad fsica en la obtencin oportuna de los datos de entrada. - Imposibilidad de reasignar funciones a cargos que manejaran el sistema.

Internas: Aquellas generadas al interior del sistema por desarrollar. EJEMPLO - Imposibilidad de modificar las frmulas o clculos de un proceso especfico. - Nivel mnimo de oportunidad con que se requiere la informacin. - Perodos mnimos de almacenamiento de informacin.

2.2 Definicin del sistema: Este paso del pre anlisis tiene como objetivo definir en forma coherente y estructurada las caractersticas y necesidades de informacin existente,

identificando sus componentes, las relaciones existentes entre stos, sus entradas y salidas. Esta definicin puede hacerse de dos formas diferentes. 2.2.1 Descripcin narrativa de los requerimientos y necesidades de informacin, tratando de identificar un sistema informal que sera la base fundamental del nuevo sistema de informacin. 2.2.2 Aplicacin del enfoque de sistemas. En este sentido se trata de asimilar las necesidades de informacin existentes, como un sistema que tiene un medio

ambiente, entradas, salidas, componentes y relaciones. Este sistema sera una aproximacin inicial a lo que sera el sistema de informacin por desarrollar. Desarrollo del enfoque de sistemas 2.2.2.1 Medio ambiente. Se busca definir el macrosistema bajo el cual el nuevo sistema de informacin se desenvolver; esto implica la identificacin de los sistemas fsicos o de informacin que interactuarn con el sistema en estudio. 2.2.2.2 Entradas y salidas. Se quiere establecer aquellos flujos de informacin que entran del medio ambiente, al posible sistema (entradas); como tambin los flujos de informacin que el posible sistema entrega al medio ambiente (salidas). 2.2.2.3 Componentes bsicos de los requerimientos planteados y sus relaciones. Con este punto se desea diferenciar los elementos o componentes principales de los requerimientos de informacin propuestos; para cada componente se realiza una descripcin general; adems se establece las relaciones existentes entre stos. ECNICAS PARA RECOLECTAR INFORMACIN a. Revisin de Documentos. La revisin de documentos permite a los analistas conocer dnde est la organizacin y para dnde va. Se pueden revisar documentos cualitativos y cuantitativos. Entre los documentos cualitativos se encuentran los reportes, estados financieros, registros y formularios de captura de datos. Los documentos cuantitativos pueden ser memorandos, consultas y manuales de procedimiento y polticas.

b. Entrevistas. Son dilogos de preguntas y respuestas. Las preguntas pueden ser abiertas o cerradas. Los pasos para realizar una entrevista son:

Leer previamente el material Establecer objetivos Seleccionar el entrevistado Preparar el entrevistado Decidir tipo de entrevista. Donde las estructuras pueden ser:

Pirmide. Comienza la entrevista con preguntas cerradas y termina con preguntas abiertas. Embudo. Comienza la entrevista con preguntas abiertas y termina con preguntas cerradas. Diamante. Comienza la entrevista con preguntas cerradas, luego contina con un conjunto de preguntas abiertas y luego termina con preguntas cerradas.

c. Cuestionarios. Los cuestionarios se deben realizar cuando se presenta dispersin de personal, se requieren respuestas annimas y cuando el personal a ser entrevistado es bastante numeroso. Las preguntas de un cuestionario pueden poseer diferentes escalas:

Nominal. Su objetivo es lograr una clasificacin con base en las respuestas. Ordinal. La clasificacin se logra con base en un rango.

Intervalo. Las respuestas dan un rango de intervalos pero todos tienen la misma longitud. De relacin. Es una escala de intervalo pero comienza siempre en cero.

d. Observacin. Se debe observar el comportamiento y ejecucin de los procedimientos en la organizacin, de tal manera que se cumplan los procedimientos escritos y se estudie la realizacin de los procesos.

CAPITULO 3: METODOS ESTRUCTURADOS DE DESARROLLO METODOS ESTRUCTURADOS OBJETIVOS

Registrar de forma apropiada los requisitos de informacin Proporcionar un mtodo sistemtico de desarrollo Construir un S.I. en un tiempo apropiado y a costes aceptables Construir un sistema documentado y fcil de mantener Ayudar a identificar, lo ms pronto posible, cualquier cambio que sea posible realizar dentro del proceso de desarrollo

CARACTERSTICAS

Descomposicin funcional del sistema Construccin de modelos de datos Representacin del flujo de informacin Transformacin de diagramas de flujo de datos en estructura modular de programa

Autores: De Marco, Yourdon, Stevens, Myers, Constantine, Page-Jones, Gane y Sarson PERSPECTIVA HISTRICA a. Programacin estructurada

Naci a finales de los aos sesenta Constituye el primer enfoque de desarrollo estructurado Se establecan unas normas de aplicacin a estructuras de datos y de control

b. Diseo estructurado

A mediados de los aos setenta el enfoque estructurado se extiende a la fase de diseo

Primeras publicaciones [Myers, 1975], [Yourdon y Constantine,1975], [Page-Jones, 1980]

Mdulo de programa como componente bsico de construccin Se refina el concepto de modularidad Revisin y mejora de los conceptos de diseo estructurado [Yourdon y Constantine, 1979], [Page-Jones, 1988]

c. Anlisis estructurado Trmino popularizado por Tom DeMarco [DeMarco, 1979] Primeros autores sobre anlisis estructurado: [Gane y Sarson, 1977],[Weinberg, 1978], [DeMarco, 1979] Crticas a las especificaciones narrativas: monolticas, redundantes, ambiguas e imposibles de mantener. Movimiento gradual hacia especificaciones grficas, particionadas y mnimamente redundantes: anlisis descendente o top-down. Evolucin y ampliacin de las tcnicas de anlisis estructurado [Piattini et al., 1996] Restar importancia a los modelos fsicos y lgicos actuales Diferenciar ms los modelos fsicos y modelos lgicos Modelado de sistemas de tiempo real [Ward y Mellor, 1985], [Hatley y Pirbhai, 1987] Modelado de los datos del sistema Estudio de los eventos [McMenamin y Palmer, 1984], [Ward y Mellor, 1985] Con la evolucin de las tcnicas estructuradas se va pasando de la construccin de programas de forma artesanal a una forma que sigue mtodos de ingeniera, sentando las bases para un desarrollo automatizado El enfoque estructurado permite solventar los problemas que surgen en el desarrollo convencional

Resultados finales impredecibles

No se puede conocer el estado del proyecto Los cambios organizativos afectan negativamente al proyecto

Dependiendo del enfoque de la metodologa, se puede establecer la siguiente clasificacin

Orientados a procesos Orientados a datos

Orientados a estructuras de datos jerrquicas Orientados a estructuras de datos no jerrquicas

Tomado de: "Modelado de Sistemas. Mara N. Moreno Garca y Francisco Jos Garca Pealvo".

METODOS ORIENTADOS A PROCESOS Mtodo descendente de descomposicin funcional para definir los requisitos del sistema. Usa tcnicas grficas, dando lugar al concepto de especificacin estructurada. Algunas notaciones grficas que contiene son: Diagramas de Flujo de Datos (DFD): representacin de los procesos (funciones) que debe llevar a cabo un sistema y de los datos utilizados por los procesos Diccionario de datos: conjunto de las definiciones de todos los datos que aparecen en los DFD Especificaciones de proceso: descripcin de los procesos primitivos del sistema Mtodos: DeMarco (1979), Gane y Sarson (1977), Yourdon (1989)

Tomado de: "Modelado de Sistemas. Mara N. Moreno Garca y Francisco Jos Garca Pealvo".

MTODOS ORIENTADOS A DATOS Se pueden clasificar en:

Orientados a Datos Jerrquicos

Orientados a Datos No Jerrquicos

1. Orientados a Datos Jerrquicos: La estructura de control del programa debe ser jerrquica y debe derivarse de la estructura de datos. El proceso de diseo consiste en definir primero las estructuras de entrada y salida, para posteriormente combinarlas con el fin de obtener la estructura del programa. Finalmente se ordena la lgica procedimental para que se ajuste a esta estructura. El diseo lgico debe preceder y estar separado del diseo fsico Mtodos:

JSP (Jackson Structured Programming) y JSD (Jackson Structured Design) de Jackson (1975) LCP (Logical Construction Program) de Warnier (1974) LCS (Logical Construction Systems) de Warnier y Orr (1981)

2. Orientados a Datos No Jerrquicos: Los datos son la parte esencial del sistema porque son ms estables que los procesos que actan sobre ellos. Son una representacin de un modelo de datos de la organizacin formado por un conjunto de entidades de datos bsicas y las relaciones entre ellas. Los procesos derivan de una definicin inicial de los datos.Mtodos:

Metodologa Ingeniera de la Informacin (Information Engineering - IE) de J. Martin y C. Finkelstein [Martin,1986.

Planificacin: Se construye una arquitectura de la informacin y una estrategia que soporte los objetivos de la organizacin Anlisis: Se comprenden las reas de negocio y se determinan los requisitos del sistema Diseo: Se establece el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnologa Construccin: Se construye el sistema que cumpla los tres niveles anteriores

Tomado de: "Modelado de Sistemas. Mara N. Moreno Garca y Francisco Jos Garca Pealvo".

CAPITULO 4: ANALISIS DIAGRAMAS DE FLUJOS DE DATOS DIAGRAMAS DE FLUJOS DE DATOS

Modelo lgico y grfico del sistema tambin como modelo fsico Visin general de las funciones y transformaciones de datos en una organizacin Identifica entradas, salidas, procesos y relaciones con el exterior o a nivel general o por refinamiento, a nivel detallado

Tipos de smbolos en los DFDs 1. NOTACIN DE YOURDON

Ejemplo Sistema de distribucin sin inventario Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.

Anlisis de los procesos del sistema Aplicamos la visin sistmica Diagrama de contexto

Sistema de pedidos

El DFD del ejemplo pertenece al nivel lgico o un FD puede estar contenido en una nota, una factura, una llamada telefnica, etc. o un almacn de datos puede ser una BD o un archivo en papel o no se dice qu deber ser automtico o manual. ... en el nivel lgico
o o

se evita caer en decisiones fsicas prematuras se maneja la complejidad

En un DFD 0 real, se hara una autntica divisin en subsistemas Se obvian los FD de error En el ej. no se muestran las funciones de creacin, mantenimiento y consulta de almacenes de datos.

SMBOLOS DEL DFD (NOTACIN YOURDON)

Transformaciones o procesos (funciones, clculo, seleccin)

Terminadores (Fuentes o Destinos) (personas, entidades) Flujos de informacin (inputs-outputs) Flujos de control (Ward & Mellor 85) Archivos o depsitos temporales de informacin (base de datos, armario, clasificador, etc.)

a. Procesos:

TRANSFORMACIN (clculo, operacin) FILTRO (verificacin fecha, validacin transaccin) DISTRIBUCIN (men, seleccin, transaccin)

Un consejo: Mantenerlos simples!

Nombres nicos, significativos y concisos Preferiblemente expresados en funcin de las entradas y salidas Recomendacin: verbo (no ambiguo) + objeto o Evitar verbos ambiguos (procesar, gestionar, manejar...) o objeto est definido en el DD Los procesos se descomponen en subprocesos, hasta llegar a los procesos primitivos

b. Diagrama de contexto:

Es el DFD ms general de todos Est formado por un solo macroproceso (el sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso Delimita el sistema y su entorno

c. Entidades externas: Sealan los lmites del sistema y establecen sus relaciones con el entorno Los identificadores (nombres) de las entidades externas sern nicos, significativos y concisos

Lmites del sistema a. Actividad crtica y difcil Puede haber problemas, tanto por ser demasiado ambicioso, como poco ambicioso

b. Flujos de datos

Los nombres de los FD deben ser nicos, significativos y concisos Son datos, as que nmbralos como datos. Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades Los nombres no sirven slo para identificar los datos, sino tambin la informacin que se tiene sobre ellos

P.ej. Informacin (fecha-vlida) > Informacin (fecha)

Flujos de datos interactivos ( dialog flows ) Cuando dos FD establecen un dilogo o comparten una accin de estmulorespuesta, pueden dibujarse como un nico FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan.

Las flechas dobles con sentidos opuestos que transportan los mismos datos pueden sustituirse por flechas doblemente encabezadas Pero slo si transportan los mismos datos!

Se puede representar, si se desea, el FLUJO DE MATERIAL, usando flechas de trazo grueso Se pueden considerar flechas convergentes o divergentes, con un mismo nombre

Observaciones: Slo los procesos pueden separar FD (Piattini et al. 96) No poner FD como seales de activacin (Yourdon 89)

2. Notacin System Architect. Ejemplos FD divergentes (conectores XOR y AND)

3. Notacin System Architect.

Ejemplos FD convergentes (conectores XOR y AND)

El proceso pide el FD pedido? El proceso necesita ambos FD?

No lo sabemos, no importa:

Los aspectos procedurales no se manifiestan en los DFDs Si tales aspectos son relevantes, se deben incluir en las mini especificaciones

Almacenes de datos Nombre nico, significativo y conciso Convenciones de nombres en los FD a/desde un almacn: No lleva etiqueta El FD se refiere a un paquete (instancia) completo de la informacin contenida en el almacn La etiqueta es la misma que la del almacn

El FD se refiere a uno o ms paquetes completos (instancias) de la informacin contenida en el almacn La etiqueta es distinta de la del almacn El FD se refiere a uno o ms componentes (atributos) de una o ms instancias del almacn

Consistencia DFD / E-R Para facilitar validaciones cruzadas entre DFDs y E-R (o DED)...

Correspondencia entre los almacenes de datos principales (permanentes) del DFD y las entidades del E-R Cada almacn de un DFD representa una o varias entidades del E-R Cada entidad del E-R pertenece a un nico almacn principal de un DFD

Descomposicin funcional Cada proceso se puede explotar, refinar o descomponer en un DFD ms detallado El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerrquicamente Los niveles de la jerarqua estn determinados por la descomposicin funcional de los procesos La raz de la jerarqua es el diagrama de contexto, que es el ms general de todos

Consistencia en el DFD Cada proceso en un diagrama padre es una consolidacin del DFD hijo Balanceo de DFDs

Las E/S de un proceso padre deben corresponderse con las E/S del DFD hijo que lo explica Excepciones: errores y salidas triviales

Descomposicin paralela Descomposiciones de funciones Proceso en subprocesos (DFD) Descomposicin de flujos de datos La regla de balanceo se aplica teniendo en cuenta la descomposicin paralela Ejemplo: pedido = autorizacin + cupn de pedido + pago

Jerarqua de DFDs En un DFD completo cada proceso tiene un nmero nico que lo identifica en funcin de su situacin en la jerarqua Cada DFD tiene tambin un nmero nico que coincide con el proceso que describe Las hojas o nodos terminales corresponden a procesos primitivos o indescomponibles Para cada proceso primitivo existir una miniespecificacin.

Jerarqua de DFDs DFD 0 El primer diagrama general que sigue al de contexto es el nmero 0 por convenio En el DFD 0 se hace una descomposicin en subsistemas , es decir, se indican los procesos ms importantes en el sistema Han de ser SUBSISTEMAS

Descomposicin funcional y almacenes de datos Los almacenes aparecen lo ms tarde posible En un nivel superior nicamente cuando son interfaz entre procesos Una vez que aparezca en un DFD, el almacn aparecer otra vez en cada DFD de nivel ms bajo relacionado

Tamao de la jerarqua de DFDs Cada DFD debera tener alrededor de 7 procesos o menos En general, habr varios niveles intermedios, dependiendo del tamao y complejidad del sistema que se est modelando Cuntos niveles son convenientes? Yourdon: depende del problema Diagrama de contexto / sistema Diagrama de subsistemas Mtrica Diagrama de funciones Diagrama de subfunciones Diagrama de procesos (opcional) Reglas sintcticas en DFDs El origen y/o el destino de un FD es siempre un proceso Todo almacn y todo proceso tienen uno o ms FD de Entrada y uno o ms FD de Salida EXCEPCIN: un almacn puede no tener FD de salida, por simplificacin (p.ej. BD Histrica)

Localizacin de los procesos

DFDs Conclusiones Valiosa herramienta de comunicacin Usuario, analista, diseador, programador Se puede combinar con el uso de prototipos

Fcil de entender y de aprender Facilita las relaciones con el usuario Amplia difusin

ESPECIFICACIN DE PROCESOS La especificacin de procesos describe las reglas sobre cmo realizar el proceso para transformar las entradas en salidas. Indican el proceso a realizar, la transformacin de datos, no el algoritmo (que se selecciona en la etapa de diseo).

1. Herramientas para describir la lgica de los procesos

Tablas de decisin rboles de decisin Pre y post-condiciones Lenguaje estructurado

2. Lenguaje Estructurado

Vocabulario (restringido) de una lengua (espaol, ingls, etc.) Verbos imperativos Trminos definidos en el DD Palabras reservadas para formulacin lgica (maysculas) Sintaxis de la programacin estructurada

a. Sintaxis

Sentencia declarativa simple (secuencia) Estructura de decisin Estructura de repeticin Combinaciones de las estructuras anteriores

b.1. Sentencias declarativas

Concisin Evitar verbos ambiguos (manejar, realizar, procesar, etc.)

Utilizar verbos precisos que describan acciones concretas (imprimir, enviar, acumular...) Mencionar expresamente el objeto de la sentencia, preferiblemente utilizando los trminos del DD Ejemplos: o Recoger INF-CLIENTE o Separar PETICION o Archivar PETICION en F-PETICION *fichero* o Enviar DATOS-CLIENTE a DPTO-CLIENTES

b.2. Estructura de decisin SI Condicin SINO Accin(es) Ejemplos: a) SI Valor-capital-actual es menor que 600 Asignar Cantidad-depreciada = Valor-capital-actual = 0 SINO Asignar Cantidad-depreciada = 10% de Valor-capital-actual b) Seleccionar la poltica que se aplica: Caso 1: (Costo-de-pedido > 1000) : enviar por avin Caso 2: (Costo-de-pedido entre 100 y 1000) : enviar por correo urgente Caso 3: (Costo-de-pedido < 100) : enviar por correo normal

b.3. Estructura Repetitiva REPETIR (condicin de seleccin) Accin(es) HASTA (condicin de terminacin) MIENTRAS (condicin) Accin(es)

FIN MIENTRAS Ejemplo: REPETIR para cada registro-de-pasajero en fichero-de-reservas Acumular Cantidad-debida en Total Construir registro Nuevo-dbito Escribir Nuevo-dbito en el diario HASTA final de fichero-de-reservas

3. Tablas de Decisin

4. rboles de Decisin

DICCIONARIO DE DATOS Es un conjunto de informacin (datos) sobre datos.

1. Objetivos del DD:

Glosario de trminos Establecer terminologa estndar Proporcionar referencias cruzadas Proporcionar control centralizado para cambios

2. Informacin requerida para cada elemento del DD

Nombre Tipo de elemento Breve descripcin Sinnimos

Observaciones

3. Operadores relacionales

= : es equivalente a + : y <> : o (inclusivo: al menos una de las opciones) [ ], | : o (exclusivo: slo una de las opciones) 1{ }N : iteraciones entre 1 y N veces del trmino entre llaves ( ) : opcional *...*: comentario @: identificador de campo clave en un almacn (tambin, alternativamente, se puede subrayar la clave)

4. Ejemplos: Solicitud-destino = n_ascensor + (nplanta)

pedido = cupon-correos + (pago-previo) etiqueta = 1{carcter}8 n-de-telefono = *cualquier secuencia correcta de dgitos que provoca una llamada * [extension - local | 9 + numero - exterior] extension-local = * slo dentro del edificio * primer-digito + 3{ cualquier-digito}3 primer - digito = [1|2|3|4|5|6|7] cualquier - digito = [0|1|2|3|4|5|6|7|8|9]

DIAGRAMAS DE ESTADO 1. Elementos

Entidades: Las entidades pasan por varios estados. En cada uno de ellos pueden suceder determinados eventos que provoquen efectos o acciones sobre la entidad. Eventos: Algo que sucede en el mundo real y como consecuencia se ejecuta un proceso.

Acciones: Descripcin del estado de un evento sobre una entidad

2. Definicin de DTE. Un diagrama de transicin de estados describe un conjunto de transiciones que pueden suceder sobre una entidad. El estado en que se encuentra una entidad es el resultado de todas las transiciones sucedidas durante su vida.

3. Notacin grfica

4. Ejemplo

Tomado de: " Diagramas de Transicin de Estados. Laboratorio de Comunicaciones e Ingeniera del Software".

DIAGRAMAS ENTIDAD RELACION Es una representacin de las necesidades de informacin del usuario. Es un modelo de red que describe la distribucin de los datos del sistema 1. Componentes

Entidad: Objetos sobre los que se guarda informacin Relacin: Conjunto de conexiones entre objetos Atributo: Cada una de las propiedades o caractersticas de una entidad o de una relacin

2. Tipos de relaciones

Obligatorias y opcionales Exclusivas Reflexivas Generalizacin (relacin ES-UN o ISA)

3. Grado de una relacin Es el nmero de entidades que participan en una relacin. Grado 1, 2 n. 4. Tipo de correspondencia de una relacin Nmero mximo de ocurrencias de cada entidad que puede intervenir en una ocurrencia de la relacin. Pueden ser

Uno a uno (1:1) Uno a muchos (1:N) Muchos a muchos (N:N).

5. Cardinalidad de las entidades de una relacin

Nmero mximo y mnimo de ocurrencias que pueden estar relacionadas con una ocurrencia de la otra entidad que participa en la relacin. Puede ser: (0,1), (1,1), (0,N), (1,N) 6. Ejemplo

ESPECIFICACIN DE REQUESITOS DE SOFTWARE (ERS) 1. Estructura Bsica 1. Anlisis de Requisitos del Software 1.1. Identificacin de los usuarios participantes 1.2. Planificacin y realizacin de entrevistas 1.3. Catlogo de Requisitos del Sistema 1.3.1. Objetivos y alcance del sistema 1.3.2. Definiciones, acrnimos y abreviaturas 1.3.3. Descripcin general 1.3.4. Requisitos funcionales 1.3.5. Requisitos de usuario y tecnolgicos 1.3.6. Requisitos de interfaces externas

1.3.7. Requisitos de rendimiento 1.3.8. Requisitos de desarrollo y restricciones de diseo

2. Anlisis de Requisitos del Software El anlisis de requisitos del sistema tiene como objetivo analizar y documentar las necesidades funcionales que debern ser soportadas por el sistema a desarrollar. Para ello, se identificarn los requisitos que ha de satisfacer el nuevo sistema mediante entrevistas, el estudio de los problemas de las unidades afectadas y sus necesidades actuales. Adems de identificar los requisitos se debern establecer las prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario.

2.1. Identificacin de los usuarios participantes Los objetivos de esta tarea son identificar a los responsables de cada una de las unidades implicadas y a los principales usuarios implicados. Para ello se consideran los siguientes aspectos:

Incorporacin de usuarios al equipo de proyecto. Conocimiento de los usuarios de las funciones a automatizar. Repercusin del nuevo sistema sobre las actividades actuales de los usuarios. Implicaciones legales del nuevo sistema

Es de destacar la necesidad de una participacin activa de los usuarios del futuro sistema en las actividades de desarrollo del mismo, con objeto de conseguir la mxima adecuacin del sistema a sus necesidades y facilitar el conocimiento paulatino de dicho sistema, permitiendo una rpida implantacin. 2.2. Planificacin y Realizacin de Entrevistas. Estudio de Documentacin. Esta tarea tiene como finalidad capturar los requisitos de usuarios para el desarrollo del sistema. La entrevista consiste en una interaccin sistemtica con un usuario para extraer los conocimientos de ste. Se deben realizar entrevistas de tipo abierta y estructurada. En una entrevista abierta se plantean preguntas ms o menos espontneas al usuario, mientras que en una entrevista estructurada se planifican las preguntas que se deben plantear al usuario durante la sesin. El proceso comprende:

Planificar las entrevistas a realizar: en la planificacin se incluir fecha, hora y lugar de la entrevista, duracin estimada y guin de la entrevista. Realizar las entrevistas y documentarlas debidamente.

Documentar los requisitos identificados con sus prioridades.

A partir de las entrevistas realizadas con los responsables y usuarios, se identifican los requisitos que debe cumplir el sistema y se establecer una prioridad para los mismos, de acuerdo a las necesidades expresadas por los usuarios y a los objetivos a cubrir por el nuevo sistema. El estudio de la documentacin consiste en la educcin de requisitos de los documentos e impresos que forman parte del sistema actual. 2.3. Catlogo de Requisitos del Sistema El objetivo de la especificacin es definir en forma clara, precisa, completa y verificable todas las funcionalidades y restricciones del sistema que se desea construir. Esta documentacin est sujeta a revisiones por el grupo de usuarios que se recogern por medio de sucesivas versiones del documento, hasta alcanzar su aprobacin por parte del grupo de usuarios. Una vez aprobado, servir de base al equipo de desarrollo para la construccin del nuevo sistema. 2.3.1. Objetivos y alcance del sistema En esta etapa se detallan los objetivos del sistema, describiendo brevemente QU es lo que el sistema debe hacer. En el alcance del sistema se describe en lenguaje natural el mbito del sistema, su dominio y sus lmites. 2.3.2. Definiciones, acrnimos y abreviaturas Esta etapa tiene como fin establecer el vocabulario de trminos que forman parte del sistema, de manera que TODOS los participantes "hablen el mismo idioma". 2.3.3. Descripcin general Esta seccin nos presenta una descripcin general a grandes rasgos del sistema con el fin de conocer las principales funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro factor que pueda influir en la construccin del mismo. Una buena manera de realizar la descripcin es plantearla con un enfoque descendente; es decir, a nivel subsistemas, detallando las funciones por debajo de los mismos. 2.3.4. Requisitos funcionales Descripcin en lenguaje natural de las funciones desglosadas en la etapa anterior, detallando las entradas, las salidas y la descripcin del proceso desde el punto de vista del usuario. Las descripciones de entradas y salidas deben ser en lo posible grficas, o bien los documentos que se usan corrientemente.

2.3.5. Requisitos de usuario y tecnolgicos Requisitos de usuario: debe describirse el nivel de conocimiento de cada usuario (novato, intermedio, experto) para la realizacin de interfaces, manuales de usuario, ayuda y capacitacin de los mismos. Requisitos tecnolgicos: se describen las necesidades desde el punto de vista tecnolgico, es decir equipos de clientes y servidores, velocidades de transmisin de datos, caractersticas que debe tener el sistema operativo y el sistema gestor de base de datos, y cualquier equipo que forma parte del sistema. Este documento es solamente un conjunto de criterios que me permite luego elegir el software y hardware adecuado para el sistema. 2.3.6. Requisitos de interfaces externas En esta etapa se capturan los requerimientos que describen cmo debe ser la comunicacin del sistema con el usuario y el mundo exterior. Se deben capturar las interfaces con el usuario, interfaces hardware, interfaces software e interfaces de comunicacin.

2.3.7. Requisitos de rendimiento Pretende definir una serie de parmetros MENSURABLES del sistema que imponen restricciones sobre el mismo. Generalmente estn asociados a tiempos de respuesta, tiempos de espera y duracin de tareas batch. Estos requerimientos son muy importantes ya que la no satisfaccin de los mismos implica un fracaso del sistema, por lo que deben tener una prioridad alta. 2.3.8. Requisitos de desarrollo y restricciones de diseo Requisitos de desarrollo: se definen los requerimientos planteados por el equipo de trabajo: qu metodologa se seguir, qu ciclo de vida, qu herramientas se utilizarn, etc. Restricciones de diseo: son requisitos que nos impone la naturaleza del dominio del problema. Estos son: ajuste a estndares (p.e. una determinada manera de codificar un dato), limitaciones hardware (por los equipos disponibles), seguridad (por los distintos niveles de acceso a la informacin que deben tener los usuarios), mantenimiento (se debe tener en cuenta la ampliacin del sistema), adaptacin al entorno y polticas de borrado.

Tomado de: "IEEE/ANSI 830-1993".

CAPITULO 5: DSISEO INTRODUCCIN AL DISEO Caractersticas: a. Especificacin de elementos fsicos y lgicos

Diseo lgico Diseo de salidas Diseo de entradas Diseo de Base de Datos Diseo de controles sobre entradas y salidas Diseo de redes

Diseo fsico

Diseo de mdulos a nivel de software

b. Actividades de soporte a la organizacin:

Ayuda: rapidez en las transacciones Ajuste a la forma en que la empresa realmente trabaja

c. Diseo de la interfaz:

Ergonmico WAI

d. Especificacin de requerimientos del software: Requisitos

Funcionales No funcionales

ANLISIS DE LAS TRANSACCIONES Y TRANSFORMACIONES 1. Particin Horizontal

Definir ramas separadas de la jerarqua de mdulos para cada funcin principal Utilizar los mdulos de control para coordinar la comunicacin entre las funciones

2. Particin Vertical: Factorizacin

Disear para que la toma de decisiones y trabajo est estratificado Los mdulos de toma de decisiones deben residir en la parte ms alta de la arquitectura

3. Diagramas de estructura Ofrecen una visin de arquitectura de sistemas. 3.1. Elementos de un Diagrama de Estructuras

Mdulo o Representa una rutina, subprograma o programa

o Se representa mediante un rectngulo con el nombre del mdulo Conexiones entre mdulos o Se representan mediante flechas Comunicacin entre mdulos o Los mdulos pueden comunicarse entre s por medio de estructuras de datos o de control

3.2. Comunicacin entre mdulos La comunicacin se realiza a travs de controles o flags

o o

Paso de control entre mdulos: un mdulo comunica a otro mdulo que ha terminado su proceso y traspasa al mdulo el control del sistema Comunicacin de que se ha producido un error en el proceso Comunicacin de que se puede proceder a una operacin concreta

3.3. Tipos de comunicaciones

3.4. Ejemplo

4. Estrategias de Diseo 4.1. Anlisis de transformacin La informacin entra en el sistema mediante caminos que transforman los datos externos a un formato interno y se identifica como flujo de entrada. La informacin entrante se pasa a travs de un centro de transformacin y empieza a moverse a lo largo de caminos que ahora conducen hacia el exterior del software

4.2. Anlisis de transaccin

El flujo de informacin est caracterizado a menudo por un nico elemento de datos denominado transaccin El flujo de transaccin se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la informacin del mundo exterior en una transaccin. La transaccin se evala y basndose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de accin. El centro del flujo de informacin del que parten los caminos de accin se denomina centro de la transaccin.

Tomado de: "Departamento de Informtica. Universidad de Salamanca".

DISEO DE LA ENTRADA 1. Objetivos:

Mejorar la calidad Evitar retrasos: cuellos de botella Evitar pasos adicionales: datos mnimos de entrada Pasos sencillos para la captura: opciones de ayuda

2. Datos capturados:

Informacin variable: informacin que cambia con cada transaccin Informacin de identificacin: campos claves Informacin que no se captura:

Informacin constante. Ejemplo: Fecha: Informacin recuperada Informacin calculada

05/11/02

Ejemplo: CARRITO DE COMPRAS ID LIBRO NOMBRE LIBRO 5423-2 Anlisis Estructurado Moderno 4524-3 Ingeniera de Software CANTIDAD
1

TOTAL

Recuperados

Entrada

Calculados

3. Codificacin: a. Clasificacin: 01 02 03 04 b. Por funciones: SI Agregar: A Borrar: B Cambiar: C Autos Camiones con 2 ejes Camiones con 3 ejes Motos

c. Dgitos significativos: Cdigo: 991103 99 11 03

Ao

Ingreso Carrera

Estudiante

d. Nemnicos: TV-SAM-02348 e. Dgitos en secuencia: 023 Retiro 024 Consulta

4. Tipos de entradas: a. Impresas: Formularios Zona de Zona de control encabezados Zona de identificacin cliente Zona detalles Zona Mensajes Zona totales

b. Pantalla:

5. Validacin y verificacin de transacciones: a. Verificacin de las transacciones: Control por lotes:

Tamao de cada lote: 50 Totales para cada lote: Comparacin

b. Validacin de las transacciones:

Deteccin de transacciones no vlidas Pruebas de secuencia Pruebas de completes Pruebas de excepciones y datos obligatorios Prueba de lmites Pruebas de redundancia

c. Mtodos de correccin:

Correccin automtica Errores:

Transposicin Transcripcin

Tomado de: " Anlisis y Diseo de Sistemas de Informacin. James Senn. ".

DISEO DE LA SALIDA Salida: cualquier tipo de informacin que el sistema genera y entrega al usuario (impreso, pantalla, etc) Puede ser: externo o interno.

Fases del diseo:

Identifican las salidas Define un mtodo de presentacin; los diferentes formatos pueden ser: impresora, pantallas, audio, cd-rom, salida electrnica. Disear la presentacin de la salida

Formatos de presentacin: 1. Formato impreso: a) Formato tabular: Recomendaciones:

Hay muchos datos y pocos comentarios La informacin se puede categorizar Permite el clculo de subtotales y totales

Ejemplo Formato de Reporte de Ventas EmpresaXXX Informacin constante Fecha de Elaboracin: DD/MM/AA Persona que elabor el informe: XXXX X Nombre Vendedor Pedro Prez Pedro Prez Pedro Prez Alberto Plazas X Factura 121-2 142-2 153-2 184-3 X Fecha 01/12/02 10/12/02 28/12/02 15/12/02 Pgina: P/T

X Total 1.500.000 560.000 800.000 600.000

Subtotal:

.............................................................

Algunas veces cuando hay muchas filas o columnas, hay mucha informacin y podra verse redundante; entonces, se puede pensar en borrar. En el ejemplo anterior, el nombre Pedro Prez aparece varias veces, se podra dejar una sola vez

Convenciones para los formatos: Numricas: 9 Total: Alfanumricos: X Nombre Vendedor: Alfabtica: A Signo: S Tipo X Longitud 30 Tipo 9 Longitud 9

Reemplazo de 0 por espacios : Z Reemplazo de 0 por * : *

_999 0999

Z999 *999

Ejemplo Formato de Reporte de Ventas EmpresaXXXXXXXXXXXXXXXX Fecha de Elaboracin: 99/999/99 Persona que elabor el informe: AAAAAAAAAAA Nombre Vendedor AAAAAAAAAAAAAAA Factura 999-99 Fecha 99/999/99 Pgina: 9/9

Total 999999999

Subtotal:

.............................................................

999999999

b) Formato grfico: Graficas Sectores:

Curvas:

Barras:

Columnas: Mapas:

Ventajas:

Permite detectar patrones y tendencias Identificar factores de alto desempeo y rendimiento El volumen de informacin no cambia

Desventajas:

Presentar y detectar diferencias absolutas Pocos datos

Iconos: Manejar conos predeterminados en cada una de las pginas

Color:

Dejar su diseo para etapas finales Manejar cuatro o cinco colores como mximo Tener en cuenta el significado

2. Formato en pantalla:

Condiciones:

Tamao del monitor Resolucin del monitor Mono/policromtico

Pantallas multiples : Formatos impresos:

Formato pre-impreso Copias mltiples: impresora, fotocopiadora, papel carbn Documentos regresados por los usuarios

Nombre Apellido CC. Tipo de Documento: CC. TI PA

Tomado de: " Anlisis y Diseo de Sistemas de Informacin. James Senn".

DISEO DEL DIALOGO GUI (INTERFAZ GRFICA DE USUARIO) Diseo del dilogo GUI (interfaz grfica de usuario): 1. Mens: Herramienta de seleccin de opciones en un programa. 1.1. Jerarqua de Mens:

1.2. Tipos de mens: a. mens de tipo ndice, mediante una lista de palabras o frases muy cortas que describen o indican lo que la opcin puede hacer. Se pueden utilizar tipos de letras, estilos y tamaos para hacer el men ms legible y ms estructurado. b. mens mediante pequeos iconos que describen las acciones que el programa ofrece en un momento determinado. Encontrar estos iconos no es tarea fcil en general. Los dibujos deberan indicar la accin que su seleccin desencadena. Los iconos de los mens son generalmente iconos del tipo "ndice". 1.2.1. Mens anidados: Los mens se pueden presentar como mens de mens o mens anidados. Cada opcin del men abre otro men y la seleccin final se hace en las hojas del rbol de mens. Este recorrido de un rbol de selecciones no debe ser muy profundo, mximo 3 niveles. Generalmente los submens se abren a la derecha ya hacia abajo. Cuando los mens encuentran el borde derecho e inferior de la ventana se deben abrir hacia arriba y a la izquierda.

1.2.2. Mens pull-down (emergentes): Este men se desenrolla hacia abajo al pisar la cabeza del men. pase el mouse

1.3. Reglas para el diseo de mens. No deben ser muy largos ni muy anidados

El estilo, tipo y tamao del texto debe ayudar a la presentacin del men. El men puede contener al lado de su texto la clave o tecla a pisar para una seleccin rpida desde el teclado, para usuarios expertos. El men no debe tapar los elementos presentes en la pantalla que son necesarios para tomar una decisin.

2. Formatos de pregunta/respuesta:

Si/No Libre

3. Lenguaje de comandos: Listar Empleados

Comando(Ctrl+Alt+E)

Palabras tcnicas Cdigos nemotcnicos: ADD, LST, DEL

4. Ventanas de llenado de formularios:

Registro de Publicaciones Nombre Autor:

Ttulo: Editorial:

5. Lenguaje natural: Ejemplo: listar todos los empleados que realizaron ventas el mes pasado

PRINCIPIOS DE DISEO GUI: 1. Dar el control al usuario: debe ser intuitiva

Definir los modos de interaccin: Flexibles y adecuados Dar opciones de rehacer/deshacer Dar opciones de interrumpir una accin, volver a ejecutar una accin Pasos repetidos: macros

2. Reducir la carga de memoria:

Metforas del mundo real Colocar valores por defecto

3. Mantener una interfaz consistente

Fuente, colores, distribucin de los controles: deben ser iguales Estndares:

De Jure: Constituidos por un organismo internacional. ISO 9241: Criterios ergonmicos para VDT (terminales de despliegue visual). De Facto: Corporaciones o empresas CUA: Common User Access

(IBM-86): Componentes Visuales

Pantallas Ventanas Punteros del mouse Controles

Entornos de Presentacin:

XEROX Windows MacOS Mofit CDE Web Personalizado

Acciones en la GUI: 1. Navegacin:

Men: Principal, anterior, salir Definir atajos: para expertos

2. Procesamiento de la informacin:

Agregar Eliminar Consultar Editar

3. Retroalimentacin:

Mensajes de confirmacin de acciones Mensajes de datos o produccin incorrecta Mensajes de estado

4. Sistema de ayuda:

Ayuda general F1: Carga la ayuda del sistema Ayuda segn el contexto Temas y subtemas Bsqueda

Proceso de desarrollo de la GUI: 1. Anlisis de usuarios, tareas y entorno Usuarios:

Roles Experiencia: o Novatos o Experiencia espordica o Expertos y frecuentes

Tareas:

DFD (procesos) - (Flujos de datos)

Entorno:

Ubicacin Diseo del mueble

2. Diseo de la GUI:

Papel Automtico

3. Implementacin 4. Validacin

Estndares GUI Las guas de estilo pueden ayudar a proporcionar una estructura que puede guiar a los diseadores, pueden tener una gran variedad de formas y pueden ser obtenidas en diferentes

sitios: Artculos de revistas y Manuales y guas de estilo de empresas de software. Lo importante a retener es que tienen que ser aplicadas con cuidado. 1. Principios Son objetivos generales que pueden ser tiles para organizar el diseo. Sin embargo, no se especifican mtodos para obtener esos objetivos, y est limitado al uso prctico para minimizar el trabajo del usuario. a. Principios Preece (1994) Estn basados en principios de alto nivel y de una aplicacin muy general

Estudiar la poblacin de usuarios Reducir la carga cognitiva Aplicar tcnicas de ingeniera para resolver la problemtica del error humano Mantener consistencia y claridad

b. Principios Simpson (1985)

Define los usuarios Deja el control a los usuarios Minimiza el trabajo de los usuarios Haz un programa sencillo Es preciso ser consistente Son necesarias las realimentaciones No cargues la memoria de trabajo Trata de no hacer un uso abusivo de la memoria a largo plazo

c. Principios Schneiderman (1992)

Consistencia Permite a los usuarios experimentados atajos Dar informacin de realimentacin Haz la gestin de errores sencilla Permite que se puedan deshacer acciones Reduce la carga cognitiva de la memoria a corto termino

2. Directrices

Cada principio en general es un objetivo, pero no dice como conseguirlo Las directrices son objetivos mas especficos que los especialistas en IPO concretan de los principios para usuarios, entornos y tecnologias diferentes

a. Directrices Brown

No pongas botones de cerrar en dilogos modales

Doble clic quiere decir clic + accin Pon botones de OK y CANCEL en cualquier caja de dilogo modal Utiliza verbos en la barra de ttulo en cuadros de dilogo de funciones Aprovechar la experiencia prctica Difundir e incorporar experiencia experimental aplicable Incorporar reglas de sentido comn Promover consistencia entre los diseadores responsables de partes diferentes de la interfase Las directrices a veces pueden provocar conflictos, y por tanto siempre es importante aplicar test de usabilidad para tratar de resolverlos.

3. Estndares Desarrollar estndares para la interfase es para hacer los desarrollos de software ms fciles y seguros, estableciendo unos requisitos mnimos de fabricacin, eliminando inconsistencias y variaciones innecesarias en las interfases. Tipos: Estndar de jure y Estndar de facto 3.1. Estndar de jure Los estndares de jure son generados por un comit con estatus legal y gozan del apoyo de un gobierno o una institucin para producir estndares Para hacer un estndar de iure se ha de iniciar un proceso complejo:

Documento preliminar Enmiendas Aprobacin Ejemplo: Ansi C

Tienen estatus legal para definir estndares de jure:

ISO. Asociacin internacional de estndares ANSI. Instituto Nacional Americano para estndares IEEE. Instituto de Ingenieros Elctricos y Electrnicos americano CEN. Comit Europeo para la estadanrizacin. JIS. Instituto Japons para estndares

ISO 9241 es un estndar de j ure relacionado con los requisitos ergonmicos para trabajar con terminales de presentacin visual (VDT), tanto de hardware como de software. Las tareas de la oficina, procesamiento de texto y datos esta cubiertos por la ISO 9241. Los procesos indstriales estn cubiertos por la ISO 11064.

3.2. Estndares de facto Son estndares que nacen a partir de productos de la industria que tiene un gran xito en el mercado o desarrollos hechos por grupos de investigacin en la Universidad que se divulgan rpidamente. Su definicin se encuentra en manuales, libros y artculos. Son aceptados como tales por su uso generalizado. Por ejemplo: Lenguaje C y Normas CUA Es fundamental para los desarrolladores basar sus diseos en un conjunto de principios y directrices para tener consistencia. Por este motivo es tan importante para las organizaciones que desarrollan software, disponer de una gua que puedan seguir sus desarrolladores. Estas guas se denominan guas de estilo y varan mucho en sus objetivos. Dependiendo del sistema hay guas de estilo para Macintosh, OS/2, Windows, UNIX y Java.

CUA Fueron publicadas en 1987 por IBM juntamente con Microsoft fruto de una colaboracin comn. Se adopt universalmente por la fuerza de IBM. Windows, OS/2 i Motif, son los estndares ms importantes que siguen esta norma.

Conclusiones

Es importante destacar que aunque se sigan estrictamente las normas de la gua no hay garanta de que la interfase sea usable. Es mejor seguir las guas que no, no seguirlas. Puede que podamos hacer un diseo mejor, pero seguramente los problemas que pueda plantear pueden ser superiores a los problemas que aporta.

Tomado de: "La interaccin Persona-Ordenador. Julio Asbacal y otros".

DISEO MODULAR Diseo Modular: Mdulos que representan las estructuras de Software

Grficas de presentacin:

Principios del Diseo Modular: 1. Modularidad y fragmentacin:

2. Acoplamiento: fuerza de la relacin entre mdulos. Su objetivo es el de minimizar

Los datos enviados deben ser mnimos Los datos enviados deben ser solamente los necesarios

3. Cohesin: fuerza de la relacin dentro de los mdulos. Los mdulos realizan tareas propias definidas para cada uno y se agrupan de acuerdo a algn criterio

Relacin de mdulo sin ningn criterio:

Relacin de mdulos de acuerdo a funciones operativas:

Relacin de mdulos de acuerdo a manipulacin de datos:

4. Extensin de control: el nmero de enlaces entre un mdulo superior y sus mdulos inferiores es de 5 a 7 mdulos inferiores. 5. Tamao de los mdulos: el tamao es preferiblemente pequeo. Cuando se pase a cdigo no debe sobrepasar las 200 lneas. Hay mdulos funcionales y de control:

Los superiores son de control Los ms inferiores son funcionales. Estos tienen mayor nmero de lneas, son de mayor tamao.

6. Mdulos compartidos:

Formato de reutilizacin: No todos los datos de X y de Y, se necesitan para crear el mdulo Z

Apoyo de las labores de prueba y mantenimiento

Otras notaciones: a) Comportamiento iterativo: Significa que una secuencia de mdulos se puede ejecutar muchas veces b) Comportamiento condicional: Slo se puede comunicar con un mdulo a la vez. c) Comportamiento combinado:

DISEO DE PROCEDIMIENTOS Documentacin:

Estructurados:

Diagramas HIPO: Hierachy Input Process Output Diagramas N-S: Nassi-Scherneiderman Diagramas W-O: Warnier-Orr Pseudocdigo

1. Diagramas HIPO:

TVOC (Tabla visual de contenido): Se hace de primero

Despus aparece un documento asociado, en donde cada mdulo se describe:

Tabla visual panormica: son ms detalladas que las anteriores

Tabla visual detallada: para cada mdulo se realiza un diagrama funcional

1.2 Validar transacciones

2. Diagrama de Flujo:

3. Programacin Estructurada:

Secuencia Condicin Iteracin

4. Diagramas N-S (Nassi-Scheneiderman):

Secuencia

Condicin

Iteracin

Mientras

Until

Ejemplo : actualizacin de suscripcin peridico

5. Pseudocdigo: Representacin a un lenguaje de programacin

6. Diagramas W-O (Warner-Orr): Elementos:

Conjuntos: { Subconjuntos: Cardinalidad: (1,n) Condicionalidad: (0,1)

Secuencia de acciones mutuamente excluyentes: +

Ejemplo:

7. Manuales de procedimiento: Documento: 1. introduccin 2. Uso del sistema 2.1 Entrada

2.2 Procedimiento 2.3 Salida 3. Problemas (preguntas y respuestas) 4. Manual de referencia: Parmetros:

Narrativo Formal

5. Glosario

8. Mtodo Folclore:

Dichos Mtodos personales (documentos) Cuentos Tomado de: " Anlisis y Diseo de Sistemas de Informacin. Kendall".