1. INTRODUCCIÓN 6 1.1 SISTEMA. 7 … · introducción. 1 tabla de contenido 1. introducciÓn 6 1.1...

Introducción. 1

TABLA DE CONTENIDO

1. INTRODUCCIÓN 6

1.1 SISTEMA. 7 1.2 LA ORGANIZACIÓN. 7 1.3 ENFOQUE DE SISTEMAS. 8 1.4 SISTEMAS DE INFORMACION. 9 1.4.1 DEFINICIONES. 9 1.4.2 ELEMENTOS. 10 1.4.3 PAPEL DE LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES. 12 1.4.4 ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN. 14 1.5 CONSIDERACIONES DE SOFTWARE. 15 1.5.1 DEFINICION. 15 1.5.2 EVOLUCION. 15 1.5.3 CRISIS DEL SOFTWARE. 16 1.5.4 FACTORES CRITICOS DE ÉXITO EN EL DESARROLLO DE SISTEMAS DE INFORMACION. 16 1.6 CICLO DE VIDA DE UN SISTEMA DE INFORMACION (S.I.B.T.I.C). 17 1.6.1 PREANÁLISIS O ANTEPROYECTO. 18 1.6.2 ANÁLISIS. 18 1.6.3 DISEÑO. 18 1.6.4 CONSTRUCCION. 18 1.6.5 PRUEBAS. 18 1.6.6 IMPLEMENTACION. (PUESTA EN MARCHA DEL SISTEMA). 18

2. EL PROCESO DE DESARROLLO DEL SOFTWARE 19

2.1 LA INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA 20 2.2 EL PROCESO DEL SOFTWARE 22 2.2.1 MODELOS DE DESARROLLO DEL SOFTWARE 22 2.2.1.1 MODELO LINEAL SECUENCIAL 24 2.2.1.2 MODELO EN CASCADA. 26 2.2.2 METODOLOGIA POR FASES. 27 2.2.3 MODELO DE CONSTRUCCION DE PROTOTIPOS 28 2.2.4 MODELO DESARROLLO RÁPIDO DE APLICACIONES. 28 2.2.5 MODELOS EVOLUTIVOS EN PROCESO DEL SOFTWARE 30 2.2.5.1 MODELO EN ESPIRAL 30 2.2.5.2 MODELO EN ESPIRAL WIN WIN 31 2.2.5.3 MODELO INCREMENTAL 31 2.2.5.4 MODELO DE DESARROLLO CONCURRENTE 32 2.2.6 DESARROLLO BASADO EN COMPONENTES 32 2.2.7 MODELO DE MÉTODOS FORMALES 32 2.2.8 TÉCNICAS DE CUARTA GENERACIÓN 32

Introducción. 2

3. ANTEPROYECTO O PREANÁLISIS. 37

3.1 CONSIDERACIONES GENERALES. 37 3.1.1 OBJETIVOS. 37 3.1.2 DEFINICION. 37 3.2 IMPORTANCIA DEL ESTUDIO DE FACTIBILIDAD. 38 3.3 CARACTERISTICAS DEL ESTUDIO DE FACTIBILIDAD. 38 3.4 TALENTO HUMANO NECESARIOS. 39 3.5 PASOS EN EL DESARROLLO DEL ESTUDIO DE FACTIBILIDAD. 39 3.5.1 RECONOCIMIENTO GENERAL DEL SISTEMA. 40 3.5.1.1 Ubicación General. 40 3.5.1.2 Delimitación o Alcance del Sistema. 41 3.5.2 OBJETIVOS DEL SISTEMA. 41 3.5.3 DEFINICION DEL SISTEMA. 43 3.5.4 RECURSOS PARA EL DESARROLLO DEL NUEVO SISTEMA. 44 3.5.4.1 Recursos Económicos. 44 3.5.4.2 Recursos de Personal. 44 3.5.4.3 Recursos Técnicos. 44 3.5.5 ESTIMATIVOS DE DESARROLLO DEL SISTEMA. 45 3.5.6 ANALISIS DE FACTIBILIDAD DEL SISTEMA. 45 3.5.6.1 Factibilidad Financiera. 45 3.5.6.2 Factibilidad Técnica. 50 3.5.6.3 Factibilidad Operativa. 50 3.5.7 ALTERNATIVAS Y RECOMENDACIONES. 51 3.5.8 CRONOGRAMA DE ACTIVIDADES. 51 3.5.9 DECISION FINAL. 54 3.6 RESUMEN. 55

4. ANALISIS. 56

4.1 CONSIDERACIONES GENERALES. 56 4.1.1 OBJETIVOS. 57 4.1.2 DEFINICION. 60 4.2 IMPORTANCIA DEL ANALISIS. 62 4.3 CARACTERISTICAS DEL ANALISIS. 62 4.4 PARTICIPACION REQUERIDA. 62 4.5 PASOS EN EL DESARROLLO DEL ANALISIS. 63 4.5.1 ANALISIS DEL SISTEMA ACTUAL. 64 4.5.2 ANALISIS REQUERIMIENTOS DEL NUEVO SISTEMA. 64 4.5.3 REVALUACION DEL PREANALISIS. 65 4.5.4 DESARROLLO DE LAS ESPECIFICACIONES DEL SISTEMA PROPUESTO. 65 4.5.5 REVISION DEL ANALISIS. 66 4.5.6 ENTREGA A LA ETAPA DE DISEÑO. 67 4.6 METODOLOGIAS DE ANALISIS. 67 4.6.1 METODOLOGIAS TRADICIONALES. 67 4.6.2 METODOLOGIAS ESTRUCTURADAS. 67 4.7 ANALISIS ESTRUCTURADO. 68 4.7.1 CONCEPTOS GENERALES. 76 4.7.1.1 DEFINICION. 76

Introducción. 3

4.7.1.2 CARACTERISTICAS. 77 4.7.2 COMPONENTES. 77 4.8 MODELO DE PROCESOS. 78 4.8.1 PROPOSITO. 79 4.8.2 DIAGRAMAS DE FLUJOS DE DATOS. (DFD). 79 4.8.2.1 FLUJOS DE DATOS. 79 4.8.2.2 PROCESOS O TRANSFORMACIONES. 79 4.8.2.3 ALMACENAMIENTOS. 80 4.8.2.4 TERMINALES, ENTIDADES O AGENTES EXTERNOS. 80 4.8.2.5 COMO CONSTRUIR UN DIAGRAMA DE FLUJO DE DATOS. 81 4.8.2.6 NIVELACION. 82 4.8.2.7 BALANCEO. 83 4.8.2.8 CONVENCIONES NUMERICAS. 84 4.8.2.9 OTROS ASPECTOS. 84 4.8.3 DICCIONARIO DE DATOS (DD). 85 4.8.3.1 FUENTES Y SUMIDEROS. 85 4.8.3.2 PROCESOS. 86 4.8.3.3 ALMACENAMIENTOS. 86 4.8.3.4 FLUJO DE DATOS. 87 4.8.3.5 COMPONENTE DE DATOS. 87 4.8.3.6 ELEMENTO DE DATOS. 88 4.8.3.7 CONVENCIONES PARA EL DICCIONARIO. 88 4.8.4 EVENTOS. 88 4.8.4.1 PROPOSITO. 88 4.8.4.2 DEFINICION. 89 4.8.4.3 LISTADO DE EVENTOS. 90 4.8.4.4 DICCIONARIO DE EVENTOS. 90 4.8.4.5 MATRICES DE EVENTOS. 93 4.8.4.6 DESCUBRIMIENTO DE EVENTOS. 94 4.8.4.7 TIPOS DE EVENTOS. 94 4.8.4.8 ORGANIZACIÓN DE LA LISTA DE EVENTOS. 96 4.8.4.9 NIVELACION DE EVENTOS. 97 4.9 MODELO DE INFORMACION. 99 4.9.1 PROPOSITO. 99 4.9.2 ENTIDADES. 100 4.9.3 RELACIONES. 101 4.9.4 CARDINALIDAD. 101 4.9.5 ATRIBUTOS. 102 4.9.6 TIPOS DE ENTIDADES. 106 4.9.6.1 ENTIDAD ATRIBUTIVA. 106 4.9.6.2 ENTIDAD ASOCIATIVA. 107 4.9.7 DEFINICION DE ATRIBUTOS. 108 4.9.8 MATRICES DE ENTIDAD. 109 4.9.8.1 CRUD EVENTO/ENTIDAD. 109 4.9.8.2 MATRIZ EVENTO/UBICACIÓN DEL NEGOCIO. 109 4.9.8.3 CRUD UBICACIÓN/ENTIDAD. 110 4.9.8.4 MATRIZ AUTORIZACION USUARIO/ENTIDAD. 110 4.9.9 ALGUNOS EJEMPLOS DE MODELOS DE INFORMACION : 111 4.10 ESPECIFICACIONES DE PROCESO (MINIESPECIFICACIONES). 112 4.10.1 ASPECTOS A TENER EN CUENTA. 112

Introducción. 4

4.10.2 FORMAS DE DESCRIBIR MINIESPECIFICACIONES. 112 4.10.2.1 ESPAÑOL ESTRUCTURADO. 112 4.10.2.2 CONVENCIONES. 113 4.11 RESUMEN. 115

5. DISEÑO. 116

5.1 CONSIDERACIONES GENERALES. 116 5.1.1 OBJETIVOS. 116 5.1.2 DEFINICION. 116 5.2 IMPORTANCIA DEL DISEÑO. 117 5.3 CARACTERISTICAS DEL DISEÑO. 117 5.4 PARTICIPACION REQUERIDA. 118 5.5 PASOS EN EL DESARROLLO DEL DISEÑO. 118 5.5.1 DEFINIR LA ESTRUCTURA DEL SISTEMA (DISEÑO GLOGAL). 119 5.5.1.1 PASOS PARA EL DESARROLLO DE LA ESTRUCTURA. 119 5.5.1.2 DESCOMPOSICION FUNCIONAL DE MODULOS. 120 5.5.2 DISEÑO DE MODULOS. (DISEÑO DETALLADO). 121 5.5.2.1 REQUERIMIENTOS PARA EL DISEÑO DE MODULOS. 122 5.5.2.2 ATRIBUTOS DE UN MODULO. 122 5.5.3 DISEÑO DE BASES DE DATOS. 123 5.5.4 DISEÑO DE ENTRADAS Y SALIDAS. 124 5.5.4.1 DISEÑO DE DOCUMENTOS FUENTES. 124 5.5.4.2 DISEÑO DE VENTANAS. 125 5.5.4.3 DISEÑO DE REPORTES. 132 5.5.5 DISEÑO DE OPERACION DEL SISTEMA (PROTOTIPOS). 132 5.5.6 DOCUMENTACION Y REVISION. 134 5.6 DISEÑO ESTRUCTURADO. 134 5.6.1 CARACTERISTICAS. 134 5.6.2 COMPONENTES. 134 5.6.2.1 IDENTIFICACION DE MODULOS. 134 5.6.2.2 DIAGRAMA DE ESTRUCTURA. 136 5.6.3 CARACTERISTICAS A EVALUAR EN EL DISEÑO. 137 5.6.3.1 ACOPLAMIENTO. 137 5.6.3.2 COHESION. 139 5.6.3.3 FACTORIZACION. 143 5.6.3.4 FAN IN. 144 5.6.3.5 FAN OUT. 144 5.6.4 PROCEDIMIENTO PARA CONSTRUIR LA ESTRUCTURA DEL SISTEMA A TRAVES DEL DISEÑO ESTRUCTURADO. 145 5.7 RESUMEN : 146

6. CASO DE ESTUDIO. 147

7. BIBLIOGRAFÍA. 200

Introducción. 5

PREFACIO

Este documento se desarrolló con un solamente académico, partiendo de la necesidad de los estudiantes de ingeniería del software de tener una guía práctica que les ayude a comprender el desarrollo de un sistema de información basado en tecnologías de información computarizadas (S.I.B.T.I.C). Este libro es la primera edición, y se basó en experiencias propias del autor en desarrollo de S.I.B.T.I.C, al igual que experiencias en la asesoría de proyectos de grado de carreras informáticas en diferentes instituciones de educación superior. Para su referente temático se basó en libros tales como: “Notas de Ingeniería” de Carlos Builes, “Ingeniería del software, Un enfoque práctico” edición 5 de Roger Pressman, “UML y patrones “ de Larman entre sus principales fuentes de información.

Introducción. 6

1. INTRODUCCIÓN

El presente trabajo pretende recopilar algunas de las teorías y técnicas para el desarrollo de sistemas de información basados en tecnologías de información computarizadas( S.I.B.T.I.C), dando un referente a aquellos autores que lo han venido trabajando durante los últimos 20 años. Este documento permite al estudiante tener una guía práctica para la elaboración de sistemas de información ( S.I.B.T.I.C), además de tener una referencia bibliográfica de consulta en todo momento. Se encuentra organizado de acuerdo con el ciclo de vida que se sigue en el desarrollo de un sistema de información, presentando en cada etapa de éste, sus características, objetivos y herramientas disponibles para su elaboración y verificación. Concluye con varios ejemplos prácticos, de proyectos desarrollados por docentes y estudiantes.

Introducción. 7

1.1 SISTEMA. Es un conjunto de elementos que se INTERRELACIONAN para lograr un objetivo común. Ejemplos: La Organización (EMPRESA), El Sistema Circulatorio, La Universidad, etc. Un sistema posee características, tales como: Límites, Objetivos, Medio Ambiente, Entradas (del medio al sistema), Salidas (del sistema al medio), Elementos, Relaciones (interrelación entre elementos), funciones (Transformación de entradas en salidas), RETROALIMENTACION.

1.2 LA ORGANIZACIÓN. Por definición, la organización es un sistema conformado por elementos tales como: La Gerencia, Relaciones Industriales, Finanzas, Producción (Servicios), Mercadeo y Ventas; que se unen (se relacionan), para alcanzar los objetivos de la organización. Gráficamente:

La Organización

De esta manera, podemos decir que la organización esta influenciada por el medio ambiente y a su vez ésta misma lo modifica.

Introducción. 8

El medio ambiente en donde se desenvuelve la organización, está conformado básicamente por: Sistema Político, Sistema Económico, Sistema Cultural, La Competencia, Los Accionistas, Los Sindicatos, Los Proveedores, Los Clientes y Los Acreedores.

1.3 ENFOQUE DE SISTEMAS. Paréntesis conceptual Antes se presentarán algunos referentes conceptuales para mayor comprensión del enfoque de sistemas.

• Sistematización: Acción y efecto de estructurar, organizar algo con un conjunto ordenado de normas y procedimientos acerca de una determinada materia

• Automatización: Supresión total o parcial de la intervención humana en la ejecución de diversas tareas (Sin.: Automación)

• Computarización: Someter datos al tratamiento de un computador. • Informatización: Acción y efecto de

• Dotar un servicio, organismo, etc., de medios informáticos, asegurar su gestión mediante medios informáticos

• Utilizar la informática para tratar con ayuda del computador las necesidades de un sector profesional, para solucionar un problema (CAPITULO 18 Sistemas de información gerencial-Kenneth Laudon y Jane Laudon 6º Edición)

• Informacionalización: representa la importancia creciente de la información, y su explotación, como recurso económico

• Cultura de la Información: Una sociedad constituida por ciudadanos y organizaciones informacionalmente cultas (orden espontáneo).

• Economía de la Información : Economía en la que se ha desarrollado un sector Información que contribuya de forma relevante a su crecimiento (planificable)

• Infraestructura: Abarca la Economía de la Información, es decir, una industria potente en el sector de la información (contenidos, distribución, proceso de información)

Como vemos, en la organización existe un elemento importante que relaciona o vincula a los demás componentes y les proporciona la materia prima para lograr la consecución de sus objetivos particulares, disminuyendo la incertidumbre. Dicho elemento es la INFORMACION.

Como elemento importante, surge entonces una nueva manera de mirar la organización, mediante una serie de herramientas que le proporcionan a ésta, una

Introducción. 9

METODOLOGIA de trabajo para resolver problemas, utilizando el concepto de Sistema. Una definición de problema podría ser: “Un problema existe si hay una diferencia entre lo que está sucediendo actualmente y lo que se desea que suceda. Si no puede decir lo que le gustaría que estuviera sucediendo, todavía no tiene un problema. Simplemente se está quejando.” Kenneth Blanchard y Spencer Johnson. CARACTERISTICAS DEL ENFOQUE: • Es una manera más de mirar los fenómenos del mundo exterior. • Proporciona una visión integral de la realidad (Plano macro y micro). • Hace énfasis en las relaciones entre elementos y de éstos con el medio

ambiente. • Cada elemento no importa por SI MISMO, sino por el papel que desempeña en

el sistema. • La función del sistema NO es igual a la suma de las funciones individuales de

los elementos (Sinergia).

1.4 SISTEMAS DE INFORMACION.

1.4.1 DEFINICIONES. Algunas definiciones de INFORMACIÓN, podrían ser:

• La información es la respuesta a una pregunta previamente planteada, la cual disminuye la incertidumbre y proporciona elementos para la toma de decisiones.

• La información debe ser vista como un recurso no como un producto del procesamiento de datos

• La información se ve como un recurso de toda la organización, no sólo del departamento o proyecto que la genera o recibe

• La información proviene de varias fuentes, no sólo de las actividades tradicionales del procesamiento de datos.

Algunas definiciones de Sistemas de información:

Introducción. 10

• Un Sistema de Información es un sistema integrado usuario-máquina/usuario-usuario, que provee información que es de apoyo a las operaciones, la administración y las funciones de toma de decisiones y de control, en una empresa o proyecto determinado de acuerdo con su planteamiento o estrategia del negocio

• Es un sistema, cuya función consiste en manejar y administrar el recurso de la información, con el fin de integrar cada uno de los elementos constitutivos de una organización.

Algunos elementos de la organización son: • DINERO (FINANZAS).

• MATERIALES (PRODUCCION).

• INSTALACIONES (SERVICIOS GENERALES).

• PERSONAL (RELACIONES INDUSTRIALES).

• INFORMACION (SISTEMAS).

• GERENCIA (TOMA DE DECISIONES).

Los sistemas de información, son básicos en cualquier actividad que implique la TOMA DE DECISIONES. Permiten disminuir la incertidumbre, controlando las variables que influyen en el proceso de toma de decisiones.

1.4.2 ELEMENTOS. • Métodos y Procedimientos: Define las instrucciones detalladas para delinear las

obligaciones, responsabilidades y operación del sistema. Se parte de la Organización para la cual se va a desarrollar el S.I.B.T.I.C.

• Equipo (hardware): Equipos de Cómputo. • Personal: De sistemas, Usuarios, Auditoría y Métodos y Procedimientos. • Aplicativo (Software): Se compone de los diferentes programas de computador

que permiten la elaboración de datos e información, de forma más rápida utilizando el computador.

• Bases de datos : Son los almacenamientos de datos de forma estructurada y

organizada. • Metodología y Documentación: Son las formas estandarizadas para el

desarrollo del sistema de información, estas se componen de herramientas y

Introducción. 11

técnicas. La documentación debe estar relacionada con cada uno de los componentes del sistema de información.

Grado de Participación de la Personas en el Desarrollo de un Proyecto. Ejemplo: Sistema de Información de Nómina.

Introducción. 12

De la gráfica podemos apreciar que el sistema de información de nómina consta de los siguientes elementos: Pagos y novedades, manejo de los datos del empleado, manejo de deducciones, generación de estadísticas e impresión de cheques. Todos ellos interactuando (a través de datos e información), para lograr el objetivo básico de generar la nómina para el personal de una organización específica.

1.4.3 PAPEL DE LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES. LEY DE LA ESPECIALIZACIÓN: “Entre más adaptado se encuentre un organismo a un ambiente específico, más difícil le será adaptarse a un ambiente diferente.” La organización conforma un gran sistema en el cual sobresalen dos cualidades: • Tiene un mecanismo de evaluación o autocontrol (Retroalimentación). • Es ABIERTO; Recibe gran influencia del medio ambiente. El papel de los sistemas de información es soportar un manejo más ágil y eficaz de las variables externas e internas de la organización, para asistir en la toma de decisiones y retroalimentar información para el control de ella misma.

Introducción. 13

Los sistemas de información deben suministrar datos e información suficiente para cada nivel dentro de la organización:

Niveles en la Organización.

Sistemas Transaccionales: Se utilizan para automatizar los procesos operativos. Son sistemas intensivos en entrada de datos y salida de información, ya que a través de ellos se cargan las bases de datos de la organización. Los cálculos y fórmulas que contienen son, en la mayoría de los casos, simples de entender. Ejemplo : Facturación, Nómina, Cartera, Ventas, etc. Sistemas Tácticos : Son sistemas de apoyo a las decisiones. La información que generan le sirve a los mandos medios y a la alta gerencia. Suelen ser intensivos en cálculos y escasos en entradas de datos. Son dirigidos a un usuario final. Ejemplo: Simulaciones, Proyecciones Financieras, etc. Sistemas Gerenciales (Estratégicos): Suelen ser “In House” (hechos en casa). Su función es lograr ventajas que los competidores no posean, tales como ventajas en costos o en servicios. Apoyan el proceso de innovación de productos y procesos dentro de la empresa. Ejemplo: MRP (Manufacturing Resource Planning). A nivel estratégico, los sistemas de información deben apoyar la toma de decisiones a través de la información consolidada y resumida de los sistemas transaccionales, que se encuentran en el nivel operativo. Para el nivel administrativo, lo sistemas deben ser una herramienta para ejecutar las decisiones tomadas por el nivel estratégico (Sistemas Tácticos).

Introducción. 14

1.4.4 ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN. Administrar los sistemas de información, como un recurso más de la organización, Implica PLANEACION, ORGANIZACION Y CONTROL. Dichos elementos administrativos, los proporciona la aplicación de la INGENIERIA DE SOFTWARE, un conjunto de herramientas y tareas que tienen como objetivo la planeación, ejecución, control y puesta en marcha de sistemas de información. A este punto, surgen preguntas importantes acerca de la computarización y uso de los diferentes sistemas de información en una organización: ¿Por qué no debieran computarizarse algunos sistemas de procesamiento de datos? Por algunas variables como: • Costo. • Conveniencia. • Seguridad. • Políticas. • Facilidad de mantenimiento. • Naturaleza de los procesos. ¿Por qué se han presentado malos resultados aplicando la tecnología informática en las organizaciones? • El factor humano (humanware) ha sido descuidado, comparándolo con el

hardware y el software. No hay formación. • Los sistemas no son integrados. Son islas de computarización. • Se produce demasiados datos en las organizaciones, lo cual genera

embotellamientos y carga. • Se computarizan sistemas ineficientes, mejorando lo que no debería hacerse. • Los usuarios no participan en el diseño de los sistemas que van a utilizar. ¿Por qué la tecnología informática no ha mejorado las medidas de éxito en las organizaciones? • Los beneficios de las tecnologías informáticas no son inmediatamente visibles. • La inversión en tecnología informática no se retorna en forma financiera, sino

en forma intangible, en muchos casos. • El impacto de la tecnología informática es muy poco, sino se hace con cambios

en la organización. • El uso de herramientas de desarrollo de software es limitado en las

organizaciones.

Introducción. 15

• Los sistemas de información son depurados en producción. • Se entregan sistemas con defectos obvios. • Los sistemas son entregados tarde e incompletos, con desfases de más del

200%. • Más del 84% de los sistemas entregados, no logran las expectativas originales.

1.5 CONSIDERACIONES DE SOFTWARE.

1.5.1 DEFINICION. Es la especificación, diseño, programación, prueba, implementación y operación de S.I.B.T.I.C. (Sistemas De Información Basados en Tecnologías de Información Computarizadas). Es el hábil y disciplinado uso de herramientas de desarrollo de software, con el fin de producir S.I.B.T.I.C: Principales características: Funcionales, económicos, flexibles, confiables, eficientes, fáciles de entender y de modificar, extensibles, seguros, de respuesta rápida, abiertos para comunicarse con otros sistemas. Se debe usar entonces esta tecnología de software, para aumentar la efectividad (hacer las cosas correctas) más que para aplicar la eficiencia (hacer las cosas correctamente). Dado que computarizar tareas innecesarias aminora la productividad de la organización.

1.5.2 EVOLUCION. La evolución del software se ha motivado por el avance y desarrollo en el hardware. El desarrollo del software se puede agrupar en cinco generaciones: Primera Generación : Sistemas Batch, no portables, monoprogramación. Años: 50's - 60's. Segunda Generación: Multiprogramación, sistemas en línea, más portables, bases de datos. Años: 60's - mediados 70’s. Tercera Generación: Sistemas distribuidos, comunicación entre computadores, mayor complejidad de bases de datos. Años: mediados 70's - principios 80's. Cuarta Generación: Micros con mucha velocidad de proceso, gran capacidad de almacenamiento, facilidad de desarrollo. Años : principios 80's - fines 80's.

Introducción. 16

Quinta Generación: Inteligencia artificial, objetos, programación parametrizada, Cliente/Servidor, Internet, Intranet. Años : fines 80's - hoy. Una división en categorías más útil de los sistemas automatizados es la siguiente: • En línea. • En tiempo real. • Batch. • De apoyo a decisiones. • Basados en el conocimiento.

1.5.3 CRISIS DEL SOFTWARE. Se origina aproximadamente entre 1965 - 1967 con la aparición de los equipos IBM 370. Debido al desarrollo acelerado del hardware, que permitió realizar múltiples sistemas en un momento donde no había personal capacitado para hacerlo. Existían herramientas de hardware potentes para la época, pero el desarrollo de sistemas computarizados era artesanal, ocasionando capacidad ociosa del hardware instalado en las organizaciones. Algunas causas de esta crisis fueron: • Costos : alto costo de desarrollo, comparado con el costo del hardware. • Escasez del recurso humano capacitado. • Insatisfacción del usuario. • Resultados diferentes a los deseados. • Técnicas de desarrollo muy variadas. • Documentación tediosa. • Mantenimiento de sistemas que consumía mucho tiempo. • Retrasos en los desarrollos. Esta crisis se trata de solucionar mediante el uso de herramientas que ayuden al desarrollo del software. Surge aquí, la INGENIERIA DE SOFTWARE, como una metodología de trabajo clara para desarrollar S.I.B.T.I.C.(Sistemas de Información Basados en Tecnologías de Información Computarizadas) con una base técnica apropiada.

1.5.4 FACTORES CRITICOS DE ÉXITO EN EL DESARROLLO DE SISTEMAS DE INFORMACION. • Identificar el verdadero problema.

Introducción. 17

• Definir claramente los objetivos del proyecto. • Determinar el alcance del proyecto. • Elegir el equipo de trabajo, involucrando tanto a los gerentes como a los

usuarios. • Obtener el apoyo de la alta dirección. • Planear las actividades del proyecto. • Obtener los recursos suficientes. • Mantener una cartera balanceada de proyectos de sistemas. • Establecer un sistema de administración de proyectos. • Usar los mecanismos apropiados para ejercer un adecuado control del

proyecto. • Tomar en cuenta la evolución de los sistemas. • Garantizar adecuados canales de comunicación. • Asegurar la conformidad con los estándares.

1.6 CICLO DE VIDA DE UN SISTEMA DE INFORMACION (S.I.B.T.I.C). “EL MANUAL DEL CICLO DE VIDA DEL PROYECTO SUELE SER UN LIBRO TAN VOLUMINOSO COMO EL COMPENDIO DE NORMAS, QUE YACE (USUALMENTE SIN SER LEÍDO) SOBRE EL ESCRITORIO DE TODO ANALISTA Y PROGRAMADOR”. Edward Yourdon. Dada la veracidad de la afirmación anterior, ¿De qué sirve entonces tener un ciclo de vida de un proyecto? Existen tres objetivos principales: 1. Definir las actividades a llevarse a cabo en un proyecto de desarrollo de

sistemas. 2. Lograr congruencia entre la multitud de proyectos de desarrollo de sistemas en

una misma organización. 3. Proporcionar puntos de control y revisión administrativos de las decisiones

sobre continuar o no con un proyecto. Las fases o etapas del ciclo de vida de desarrollo de un S.I.B.T.I.C son: PREANÁLISIS (ANTEPROYECTO) ANÁLISIS. DISEÑO. CONSTRUCCIÓN. PRUEBAS IMPLEMENTACIÓN (ENTREGA AL USUARIO).

Introducción. 18

1.6.1 PREANÁLISIS O ANTEPROYECTO. Cobija las actividades necesarias para determinar si un sistema particular será desarrollado.

1.6.2 ANÁLISIS. Es la colección, organización y evaluación de HECHOS de un sistema y del medio ambiente en el cual opera, con el objetivo de establecer las BASES de un nuevo sistema S.I.B.T.I.C. Responde a las preguntas: ¿Qué es lo que hace el sistema (S.I.B.T.I.C)? ¿Que es lo que va a hacer el nuevo S.I.B.T.I.C?

1.6.3 DISEÑO. Es la especificación de la concepción y estructura del nuevo sistema, donde se definen sus módulos, a nivel general y detallado. Responde a la pregunta: ¿Como se va a hacer el nuevo sistema?

1.6.4 CONSTRUCCION. Es la programación en un lenguaje específico de sistemas, del diseño antes realizado. Traduce el diseño a herramientas de sistemas.

1.6.5 PRUEBAS. Son las pruebas Funcionales y Operacionales que se deben realizar al S.I.B.T.I.C para verificar la calidad del sistema. Las Pruebas Funcionales son las que debe realizar el usuario para verificar que se cumplen los objetivos y los requerimientos planteados al inicio del proyecto y reafirmados en la etapa del análisis. Las Pruebas Operacionales son las que deben realizar en el área de sistemas para verificar la calidad del diseño de las bases de datos y la calidad de los programas desarrollados. Estas verifican la calidad de las técnicas y métodos aplicados.

1.6.6 IMPLEMENTACION. (PUESTA EN MARCHA DEL SISTEMA).

Introducción. 19

Es la validación del nuevo sistema con datos ficticios, para luego colocarlo a funcionar realmente, con datos verídicos. Se deben hacer capacitación e inducción a los usuarios del sistema.

2. EL PROCESO DE DESARROLLO DEL SOFTWARE “Con el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es un proceso social de aprendizaje. El proceso es un dialogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una interacción entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo (La tecnología). ES un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas involucradas.” Howard Batjer,Jr. El proceso es un conjunto de tareas que se deben llevar a cabo de una forma metódica para desarrollar software de calidad. Un proceso de software define el enfoque que se toma cuando el software es tratado por la ingeniería. Pero la ingeniería del software también comprende las tecnologías que tiene el proceso –Métodos técnicos y herramientas automatizadas--. ¿Quién lo hace? Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades y lo siguen. Las personas que han solicitado el software tienen un papel importante en el proceso del mismo. ¿Por qué es importante? Proporciona estabilidad, control y organización a una actividad que si no se controla desde su comienzo tiende a volverse caótica. ¿Cómo estar seguro de que lo he hecho correctamente? La calidad, oportunidad y viabilidad a largo plazo del producto que se esta construyendo son los mejores indicadores de la eficiencia del proceso que estamos utilizando. Se define un proceso de software como un marco de trabajo de las tareas que se requieren para construir software de alta calidad.

Introducción. 20

2.1 LA INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA “La ingeniería del software es la aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software.” IEEE. LA ingeniería del software es una tecnología multicapas, donde el fundamento es la capa de PROCESO. El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs).

El trabajo que se asocia a la ingeniería del software se puede dividir en tres (3) fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto. Fase de Definición: Intentar identificar que información ha de ser procesada, que función y rendimiento se espera, que compartimiento del sistema, interfaces , restricciones de diseño y que criterios de validación se necesitan para definir un sistema correcto. Fase de Desarrollo: Se define como han de diseñarse las estructuras de datos y como se traduce este diseño en un lenguaje de programación, se define también como hacer pruebas al software. Fase de Mantenimiento:

HERRAMIENTAS METODOS

PROCESO

UN ENFOQUE DE CALIDAD

Introducción. 21

Cambio que va asociado al a corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios • Mantenimiento Correctivo Aunque el software se haya desarrollado bien, el cliente puede descubrir algunos defectos. Este cambia los el software para corregir los defectos • Mantenimiento de Adaptación Con el paso del tiempo, es probable que cambie el entorno original del software o las reglas de la empresa, es decir puede cambiar la plataforma tecnológica o políticas de realización de cálculos. Este mantenimiento produce modificación en el software para acomodarlo a los cambios de su entorno externo • Mantenimiento de Mejora Conforme se utilice el software, el cliente /usuario puede descubrir funciones adicionales que van a producir beneficios. El Mantenimiento de Mejora o perfectivo, lleva al software más allá de sus requisitos funcionales. • Mantenimiento Preventivo El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente. Además de estas actividades de mantenimiento, los usuarios del software desarrollado requieren un mantenimiento continuo. Los asientes técnicos a distancia, teléfonos de ayuda y sitios Web de aplicaciones específicas se actualizan frecuentemente como parte de la fase de mantenimiento. El mantenimiento es mucho más que una simple corrección de errores. Dentro de las actividades se encuentra:

• Seguimiento y control del proyecto de software. • Revisiones Técnicas Formales. • Garantía de Calidad del Software. • Gestión de Configuración del software. • Preparación y Producción de Documentos. • Gestión de Reutilización. • Gestión de Riesgos.

Introducción. 22

2.2 EL PROCESO DEL SOFTWARE Se establece un marco común del proceso definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos del software, un número de tareas. En los últimos años se ha hecho mucho énfasis en la “Madurez del Proceso”. El Software Engineering Institute (SEI) ha desarrollado un modelo completo que se basa en el conjunto de funciones de ingeniería del software que debería estar presente y alcanzar diferentes niveles de madurez del proceso. El SEI utiliza un cuestionario de evaluación y un esquema de 5 grados: NIVEL 1 INICIAL Se caracteriza según el caso, se definen pocos procesos y el éxito depende del esfuerzo individual. NIVEL 2 REPETIBLE Se establecen los procesos de gestión del proyecto para hacer seguimiento del costo. NIVEL 3 DEFINIDO Se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización para el desarrollo y mantenimiento del software. En este nivel se incluyen todas las características del nivel 2. NIVEL 4 GESTIONADO Se recopilan medidas detalladas del proceso del software y de la calidad del producto. Se incluyen todas las características del nivel 3. NIVEL 5 OPTIMIZACION Se posibilita una mejora del proceso. Se incluyen todas las características definidas para el nivel 4.

2.2.1 MODELOS DE DESARROLLO DEL SOFTWARE Estrategia para resolver problemas reales de una industria, que debe Incorporar los procesos, métodos y capas de herramientas.

Introducción. 23

Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas:

Definición Del Problema Identifica el problema específico a resolverse. Desarrollo Técnico Resuelve el problema específico a través de la aplicación de alguna tecnología, como pueden ser documentos, programas, datos etc. Integración de Soluciones Estas dos etapas se dividen las fases y los pasos genéricos de ingeniería de software. Integración de Soluciones y Estado Actual Estas dos etapas se dividen las fases y los pasos genéricos de ingeniería de software.

��

��

��

��

��

��

��

��

��

��

Introducción. 24

Antes de comenzar a hablar de las diferentes clases de modelos de procesos del software, es conveniente aclarar algunas definiciones que tienden a confundirse, cuando hablamos de éste tema. Son ellas las definiciones de técnica, método y metodología. Método: Forma estandarizada de realizar una tarea. Técnica: Método estructurado y repetible para lograr una tarea específica. Ejemplo: Diagramas de Flujo de Datos, Diagrama de Estructura de Datos. Metodología: Es el acomodo ordenado de las técnicas en un enfoque sistemático para la construcción o adquisición de sistemas de información (en el caso de interés). Modelo: Forma o manera de realizar una actividad o un proceso, de forma sistematizada y sistémica. Existen diferentes tipos de modelos de desarrollo de sistemas de información:

2.2.1.1 MODELO LINEAL SECUENCIAL

Ingeniería y modelado de Sistemas/Información

Ingeniería de sistemas/información

Análisis Diseño Código Prueba

Introducción. 25

El trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esta visión del sistema es esencial cuando el software se debe interconectar con otros elementos. La ingeniería y el análisis del sistema comprende los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis y de diseño. ANÁLISIS DE LOS REQUISITOS DEL SOFTWARE El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del programa a construirse, el ingeniero o analista del software debe comprender el domino de información del software así como la función requerida, comportamiento, rendimiento e interconexión. DISEÑO El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: Estructura de Datos, Arquitectura de Software, Representación de la Interfaz y Detalle Procedimental (Algoritmo) GENERACIÓN DE CÓDIGO El diseño se debe traducir en forma legible por la maquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cavo el diseño de una forma detallada, la generación de código se realiza mecánicamente. PRUEBAS El proceso de pruebas se centra en los procesos lógicos internos del software, y el los procesos externos funcionales: realizar las pruebas para la detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. MANTENIMIENTO El software indudablemente sufrirá cambios después de ser entregado al cliente, porque debe adaptarse a los cambios de su entorno externo.

Introducción. 26

El soporte y mantenimiento del software vuelve a aplicar cada una de las fases procedentes a un programa ya existente y no a uno nuevo ¿POR QUE FALLA ALGUNAS VECES EL MODELO LINEAL SECUENCIAL? 1. Los proyectos reales raras veces siguen el modelo secuencial que propone el

modelo. Aunque el modelo lineal puede acoplar interacciones lo hace indirectamente. Como resultado, los cambios pueden causar confusión cuando el equipo del proyecto comienza.

2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos.

El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar incertidumbre natural al comienzo de muchos proyectos.

3. El cliente debe tener paciencia. Una versión de trabajo del programa no está

disponible hasta que el proyecto esta muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

2.2.1.2 MODELO EN CASCADA. Es una variación del anterior, aunque básicamente son el mismo. Se basa en un plan para el proyecto y luego se realiza el análisis del dominio del problema. Terminado el análisis, se comienza el diseño. Terminado el diseño, se sigue con la construcción. Las salidas de una etapa son las entradas para la siguiente; A esto se debe su nombre.

Modelo en Cascada.

Introducción. 27

Su enfoque es conveniente para la enseñanza de las técnicas de Ingeniería de Software. Los proyectos reales se ejecutan en fases y no en ese estricto orden de actividades. No se puede pretender terminar TODO el análisis de un proyecto, por ejemplo, sin empezar nada de diseño. En los proyectos reales se suceden muchas tareas en forma concurrente, se van ajustando otras y se van aprendiendo cosas nuevas sobre la marcha, que causan revisión, en muchos casos, de tareas ya culminadas. El desarrollo así visto, en fases y con cierto grado de iteración de ajuste, es una práctica exitosa en los métodos de cascada.

Cascada con Iteración de Ajustes Integradas.

CONSIDERACIONES: La implantación ascendente es buena para el montaje de automóviles en línea, pero sólo después de que el prototipo este completamente libre de fallas. (Ciclo de vida en cascada). El agua, siendo víctima de la gravedad, no tiende a regresar hacia arriba de la colina. De manera similar, la gente tiende a tratar los regresos hacia el análisis o el diseño como una falla, en lugar de ser un paso hacia adelante.

2.2.2 METODOLOGIA POR FASES. Enfoque que sirve para acometer proyectos grandes. Tiene una ventaja y es que el aprendizaje que se logra cuando se resuelve una parte del proyecto a través del ciclo de vida completo, sirve como experiencia para el resto del proyecto. Otro beneficio es la entrega temprana de partes del proyecto, que pueden comenzar a funcionar para la organización.

Introducción. 28

Cascada en Fases.

2.2.3 MODELO DE CONSTRUCCION DE PROTOTIPOS

La construcción de un prototipo es una manera útil de extraer los requerimientos del cliente e identificar y eliminar las partes riesgosas de un proyecto. Ojo ver las diapositivas de las exposiciones

Importante ver las paginas WEB y las diapositivas de Cesar de EAFIT

FALTA modelo de construcción de prototipos

2.2.4 MODELO DESARROLLO RÁPIDO DE APLICACIONES. FALTA modelo de DRA completarlo

Introducción. 29

Desarrollado en el Pentágono, como un método para controlar los costos de proyectos de defensa. La idea es dividir el proyecto en fases más cortas de análisis, diseño, construcción y evaluación. Después de cada fase se evalúa la viabilidad del trabajo terminado, con una estimación de lo que falta. Este modelo se conoce con el nombre de DRA (Desarrollo Rápido de Aplicaciones) y resuelve el problema de la entrega rápida de código. El DRA divide el proyecto en CUADROS DE TIEMPO, que son un conjunto de características definido que se promete entregar a los usuarios dentro de un marco de tiempo fijo, digamos 90 días. Se realiza algo de análisis, un diseño breve y luego, usando herramientas de desarrollo de alto poder, se construye un prototipo funcional. El prototipo es revisado por los usuarios y se solicitan modificaciones. El ciclo de codificación y refinación del prototipo de realiza tres veces, yendo en espiral, volviendo a analizar, diseñar y evaluar. Al final del cuadro de tiempo, se instala la aplicación resultante. La ventaja del DRA es la producción de código muy temprano, que a su vez se convierte en desventaja, dado que se tiende a abandonar todas las actividades de análisis y diseño previas. Otro aspecto de fortaleza, es el hecho de involucrar al usuario en la creación de prototipos. Los cuadros de tiempo hacen, por otra parte, difícil el enfoque de realizar componentes de código reutilizables.

Introducción. 30

Tres Iteraciones Espirales en Cuadros de Tiempo.

Tanto el enfoque de cascada como el DRA, tienen sus puntos fuertes y débiles. Lo importante es saberlos aplicar a las diversas situaciones del mundo real. En general, un buen modelo ya sea de análisis o diseño, debe cumplir con cinco características principales: 1. Motivar la actividad pretendida. 2. Ser completa. 3. Ser modificable en su corrección. 4. Producir elementos contra los que se pueda medir el avance. 5. Ser fácilmente aprovechable en la fase subsecuente.

2.2.5 MODELOS EVOLUTIVOS EN PROCESO DEL SOFTWARE FALTA MODELOS EVOLUTIVOS

2.2.5.1 MODELO EN ESPIRAL FALTA MODELOS EN ESPIRAL

Introducción. 31

2.2.5.2 MODELO EN ESPIRAL WIN WIN FALTA MODELOS EN ESPIRAL WIN WIN

2.2.5.3 MODELO INCREMENTAL FALTA MODELO INCREMENTAL

• El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas <<Incrementos>>. En general, cada incremento se constituye sobre aquel que ya ha sido entregado.

• Cuando se utiliza un modelo incremental, el primer incremento en muchos casos es fundamental. Es decir se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin extraer.

Análisis Diseño

Ingeniería de

Sistemas/información

Código PruebaEntrega del

1°. incremento

Incremento 2Entrega del

2°. incremento

Entrega del

3°. incremento

Entrega del

4°. incremento

Incremento 3

Incremento 4




Introducción. 32

2.2.5.4 MODELO DE DESARROLLO CONCURRENTE FALTA CONCURRENTE

2.2.6 DESARROLLO BASADO EN COMPONENTES FALTA MODELOS COMPONENTES

2.2.7 MODELO DE MÉTODOS FORMALES FALTA MODELOS METODOS FORMALES

2.2.8 TÉCNICAS DE CUARTA GENERACIÓN FALTA TECNICAS DE 4 GENERACION

2.3 FASES O ETAPAS DE UN PROYECTO INFORMÁTICO Un proyecto de desarrollo de sistemas de información basado en tecnologías de información computarizadas, requiere, de forma general tres fases, que son:

• Planeación (preanálisis o anteproyecto) • Ciclo de Vida de Desarrollo (Ejecución real) • Ciclo de Vida de Operación (entrega y ejecución por parte de los usuarios)

Introducción. 33

ESQUEMA DEL PROYECTO

A A’ B D E

ZT+1

A � B Duración del desarrollo del proyecto A’ � B Ejecución real del proyecto (Ciclo de vida del desarrollo)A � A’ PlaneaciónB � D Ciclo de vida Útil (proyecto en operación por parte del usuario) En B muere el desarrollo del proyecto.

PlaneaciónEjecución

Real

PLANEACIONESTUDIO DE FACTIBILIDAD

A A’

SECTORY ENTORNO

MERCADO TÉCNICO

FINANCIERO

ECONOMICA

SOCIAL

D

FACTIBILIDAD

SECTORY ENTORNO

MERCADO TÉCNICO

FINANCIERO

ECONOMICA

SOCIAL

D

PREFACTIBILIDAD

SECTORY ENTORNO

MERCADO TÉCNICO

FINANCIERO

ECONOMICA

SOCIAL

D

OPORTUNIDAD

PRIMA FTE PRIMARIAPRIMA

FTE SECUNDARIAPRIMA

SUPUESTOS

Ver libro : “Ingeniería del software: Un enfoque práctico” Roger Presuman, 5 edición, Parte Segunda: Gestión de proyectos de software.

Introducción. 34

PLANEACIÓN (PREANALISIS O ANTEPROYECTO) Esta fase determina si el proyecto se va a llevar a cabo o si no se comienza con el proyecto. Ver FASE PREANALISIS. A nivel de proyectos generales (Casi siempre de infraestructura) se tienen contemplados tres estudios:

• Estudio del Sector y del Entorno • Estudio de Mercados • Estudio Técnico

(Nota: El alcance de este libro no es profundizar en estos temas, sino solamente dar un referente temático) El Estudio del Sector y del Entorno, consiste básicamente en Ubicar en que sector de la economía se encuentra la empresa donde se va ha desarrollar el proyecto, tipo de servicios o productos que maneja, Ubicación con la Competencia, Sucursales etc. Como interés de este libro solo se definirán los elementos del entorno básicos. El Estudio de Mercados, consiste en analizar Líneas de distribución, los productos de la empresa versus los mercados potenciales; Realizar un análisis de las cuatro Ps (Precio, Producto, Producción, Plaza), realizar un análisis de Oferta-Demanda-Precio. Se realiza unos Estimativos para el Desarrollo, tendiendo en cuenta un análisis de los Proveedores de tecnología, y si el Software desarrollado es un Producto para comercializar, se analizan los Clientes potenciales, la Competencia y sus precios etc. Como interés de este libro es solo realizar un análisis Costo / Beneficio El Estudio Técnico consiste en el análisis de la plataforma tecnológica de la empresa(actual), Análisis de la plataforma tecnológica requerida, conocimientos de los Analistas y desarrolladores, de los usuarios etc.

2.3.1 CICLO DE VIDA DE DESARROLLO (EJECUCIÓN REAL) Esta fase depende del Modelo de Desarrollo seleccionado. Básicamente se enfoca en las siguientes etapas: Análisis, Diseño, Construcción (codificación), Pruebas, Implementación (entrega al usuario). Ver: Proceso del software

2.3.2 CICLO DE VIDA DE OPERACIÓN (ENTREGA Y EJECUCIÓN POR PARTE DE LOS USUARIOS) Esta fase consiste en definir el tiempo que el proyecto una vez sea entregado, va a ser operado por los usuarios, es decir, es el tiempo en que los usuarios se van a beneficiar del sistema de

Introducción. 35

información desarrollado, una vez este tiempo transcurra, el sistema de información debe ser cambiado o debe ser realizado un proceso de Reingeniería, para seguir operándolo

Introducción. 36

Anteproyecto 37

3. ANTEPROYECTO O PREANÁLISIS.

3.1 CONSIDERACIONES GENERALES.

3.1.1 OBJETIVOS. • Definir todos los elementos que se requieren para desarrollar el proyecto. • Desarrollar el ESTUDIO DE FACTIBILIDAD (Determinar la factibilidad

financiera, técnica y operativa de un proyecto de software, surgido de la necesidad de un área específica).

De acuerdo a esto, se decidirá si el sistema vale la pena o no desarrollarlo. • Lograr un conocimiento GENERAL y ESTRUCTURADO de los

REQUERIMIENTOS de información de un sistema, como base 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 dirección adquiera bases suficientes para decidir cuál es la alternativa a implementar.

• Realizar una planeación general de actividades para el desarrollo efectivo del

sistema. (En caso de ser factible el sistema).

3.1.2 DEFINICION. La actividad de Preanálsis o Anteproyecto, permite realizar un análisis de los requerimientos generales y definir si es posible o no realizar el proyecto de desarrollo del sistema de información planteado. En esta actividad se lleva a cabo un Estudio de Factibilidad el cual contiene la definición organizada de esos requerimientos, los recursos con que se cuenta para solucionar dichas necesidades, los estimativos de desarrollo del nuevo sistema, el análisis de factibilidad, alternativas de desarrollo y cronograma de actividades futuras. Gráficamente:

Anteproyecto 38

Aplicando el enfoque de sistemas, tenemos: 1. Reconocer el problema (objetivo). 2. Definir el sistema (límites). 3. Determinar recursos disponibles (Equipos, personas, dinero). 4. Estimar elementos de desarrollo. 5. Análisis de factibilidad. 6. Determinar alternativas. 7. Planear actividades futuras.

3.2 IMPORTANCIA DEL ESTUDIO DE FACTIBILIDAD. • Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el

trabajo por realizar en la etapa de análisis. • Evita el desarrollo de sistemas que a nivel financiero, técnico u operativo,

serían un fracaso para la empresa. • Permite planear con tiempo los recursos requeridos para el desarrollo de un

sistema. • Establece las bases para efectuar una verdadera evaluación y control del

desarrollo de un sistema. • "Aterriza" al personal administrativo, usuarios, técnicos en sistemas y auditores,

respecto a las expectativas reales del sistema. • Evita que se “caiga” el proyecto y ayuda a encontrar la solución a las

necesidades del negocio, con base en una comprensión de ellas mismas, ajustándose dicha solución a los recursos destinados para el proyecto.

3.3 CARACTERISTICAS DEL ESTUDIO DE FACTIBILIDAD. • Es una etapa preliminar, lo cual dificulta el entendimiento inicial del grupo de

trabajo. • Se dificulta definir en forma clara el alcance del sistema a desarrollar, dado que

lo que se busca es un conocimiento general del área. • Se debe conocer la factibilidad total del sistema. • Es típico la dificultad en evaluar aspectos financieros a este nivel de

conocimiento del sistema.

Anteproyecto 39

• Es la base para la planeación futura del sistema a desarrollar.

3.4 TALENTO HUMANO NECESARIOS. El desarrollo del estudio de factibilidad implica la participación de un grupo interdisciplinario de personas de áreas distintas, cada uno con sus propios intereses: GESTORES SUPERIORES (Usuarios líderes): Son quienes definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto GESTORES TÉCNICOS (Comité técnico): Son quienes deben planificar, motivar organizar y controlar a los profesionales que realizan el trabajo del software PROFESIONALES (Analistas y Desarrolladores): Son quienes proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación. CLIENTES (Usuarios técnicos): Son quienes especifican los requerimientos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado. USUARIOS FINALES: Son quienes interactúan con el software unea vez que se ha entregado para producción Es conveniente que participe directamente el usuario responsable del área, o sea, el directivo encargado de la dependencia. AUDITORES: Son quienes controlan la buena ejecución del proyecto.

3.5 PASOS EN EL DESARROLLO DEL ESTUDIO DE FACTIBILIDAD. Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en el estudio de factibilidad de un sistema de información. Cada una de estas tareas debe estar claramente documentada, en el manual de factibilidad del sistema.

Anteproyecto 40

3.5.1 RECONOCIMIENTO GENERAL DEL SISTEMA. Con esta actividad se pretende lograr una ubicación a nivel general, por parte del grupo desarrollador, acerca de la organización, el área en estudio y el sistema mismo. Proporciona una primera visión de lo que será el alcance del nuevo sistema. Dicha tarea debe contemplar:

3.5.1.1 Ubicación General. Pretende generar una ubicación a nivel general del sistema, dentro del medio ambiente de la organización. Debe contener: • Descripción y definición de las características generales de la empresa (objeto

social, estructura organizacional, ubicación geográfica, recursos informáticos, sector al que pertenece).

• Descripción y definición del área donde se va a desenvolver el sistema. • Ubicación del sistema dentro del área.

Anteproyecto 41

3.5.1.2 Delimitación o Alcance del Sistema. Busca definir los límites hasta donde se piensa, el nuevo sistema resolverá las necesidades de información dentro del área. Es el “contrato” o compromiso que se hace entre los usuarios y el personal de sistemas. Se trata de reflejar en el nombre que llevará el sistema. El alcance se vuelve a revisar en la etapa de análisis, donde se conoce más a fondo las necesidades existentes y el funcionamiento del sistema. En el alcance se debe especificar que informes, reportes, consultas etc. se comprometen los desarrolladores entregadaza a los distintos clientes y usuarios finales. Se recomienda que estos informes, a desarrollar, se coloquen como anexos, del manual técnico. Un alcance típico sería: “El propósito del sistema de procesamiento de libros XXX es manejar todos los detalles de los pedidos de libros de los clientes, además del envío, facturación y cobro retroactivo a clientes con facturas vencidas. La información acerca de los pedidos de libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y contabilidad.”

3.5.2 Objetivos del Sistema. Deben ser claros, específicos y cuantificables (que se puedan medir). Deben reflejar la satisfacción de las necesidades de información, beneficios organizativos y beneficios económicos. Se dividen en generales y específicos.

Anteproyecto 42

Muchos Objetivos soportan la meta.

Un objetivo es una frase que cuando se lleva a cabo elimina un problema o aprovecha una oportunidad. Cada objetivo soporta una parte de la meta. Si se alcanzan todos los objetivos, se habrá alcanzado la meta. Para enunciar un objetivo se debe aplicar el concepto llamado IR AC IS (Increase Revenue, Avoid Cost, Improve Service) (Incrementar Utilidades, Rebajar Costos, Mejorar Servicio). Veamos un ejemplo de cómo formular un objetivo: Ante el problema hipotético: “El personal de ventas proporciona información incompleta al grupo de desarrollo de productos acerca de los nuevos clientes y los requerimientos de productos nuevos.” Se debe convertir primero el problema negativo a una oración positiva: “El personal de ventas necesita proporcionar información completa al grupo de desarrollo de productos acerca de los nuevos clientes y de los requerimientos de productos nuevos.” Luego nos debemos preguntar: Resolviendo este problema, ¿es probable que incrementemos ganancias, evitemos costos o mejoremos el servicio al cliente? No hay relación entre la obtención de información de clientes y productos y el incremento de ventas.

Anteproyecto 43

Lo que se ve es que la información obtenida de los clientes, bajará los costos para los nuevos productos, debido a que no se tendrá que llamar muchas veces a los clientes para solicitar aclaraciones. También mejorará el servicio al cliente, dado que se les molestará menos, para pedirles información. Usando entonces los términos IR AC IS, nuestro objetivo se plantearía así : “Evitar el costo de llamar a los clientes para aclaraciones (por x$) haciendo que el personal de ventas proporcione información completa sobre nuevos productos. Esto también mejorará el servicio al cliente reduciendo la cantidad de veces que se hace contacto con él (número de llamadas)”.

3.5.3 DEFINICIÓN DEL SISTEMA. Tiene como objetivo definir en forma COHERENTE y ESTRUCTURADA, las características y necesidades de información existente, identificando sus componentes, las relaciones existentes entre ellos, sus entradas y sus salidas. Se puede hacer de dos formas diferentes: • Descripción Narrativa. • Aplicación del Enfoque de Sistemas: Se trata de asimilar las necesidades de

información, como un sistema que tiene un medio ambiente, entradas, salidas, componentes y relaciones. Este sistema así definido, sería una APROXIMACION inicial a lo que puede ser el sistema de información por desarrollar.

Medio Ambiente: Se busca definir el marco bajo el cual el nuevo sistema se desenvolverá. Implica la identificación de los sistemas físicos o de información que INTERACTUAN con el sistema en estudio. Entradas y Salidas: Establecer aquellos flujos de información que entran del medio ambiente, al sistema (Entradas). Como también los flujos de información que el sistema entrega al medio ambiente (Salidas). Componentes: Se busca identificar los diferentes grupos de funciones o elementos generales que conforman el desempeño global del sistema. Para cada componente se realiza una descripción general. Relaciones: Es la información que un componente entrega a otro, con el fin de que entre ellos exista asociaciones o interrelaciones. Son de control total del sistema.

Anteproyecto 44

3.5.4 RECURSOS PARA EL DESARROLLO DEL NUEVO SISTEMA. Busca establecer, en forma global, con qué elementos cuenta la administración para poder solucionar las necesidades de información expuestas por el usuario y poder definir la factibilidad técnica, financiera y operativa. Estos elementos son:

3.5.4.1 Recursos Económicos. Es el presupuesto existente para el proyecto.

3.5.4.2 Recursos de Personal. Son las personas de Sistemas, usuarios, clientes y gestores disponibles para el proyecto.

3.5.4.3 Recursos Técnicos. Plataforma tecnológica: Recursos de hardware y de software disponibles en la organización. Métodos y Procedimientos del área de informática y sistemas. Procedimientos y funciones del área o áreas donde se va a desarrollar el sistema, y Auditoría.

3.5.4.3.1 Hardware o Equipo Disponible. Establecer características y capacidades del equipo o equipos que se tienen: Memoria principal, almacenamiento, velocidad de procesador, Dispositivos periféricos (Terminales, impresoras, lectoras, etc.), unidades de E/S, comunicaciones, etc.

3.5.4.3.2 Software. Se puede mirar bajo los siguientes aspectos:

3.5.4.3.2.1 De Soporte. Software ejecutable por máquina, sistemas operacionales, lenguajes de programación, manejadores de bases de datos, rutinas de acceso, herramientas de consulta, etc.

3.5.4.3.2.2 De Utilidad.

Anteproyecto 45

Software de aplicación, software existente en el mercado, desarrollo interno, desarrollo mixto.

3.5.5 ESTIMATIVOS DE DESARROLLO DEL SISTEMA. Se busca proyectar, de acuerdo a la definición y características del sistema propuesto y recursos disponibles para el mismo, el tamaño, tiempo de duración, número de personas, esfuerzo y costos de desarrollo que tendría la duración del proyecto de desarrollo (ciclo de vida de desarrollo). Un ejemplo de estimativos, es el hecho de proyectar, para una aplicación con GUI (Interfases Gráficas), el costo de la misma. Dichas aplicaciones se concentran altamente en la creación de la interfaz y en la base de datos. Se debe entonces estimar el costo con base en la cantidad de ventanas, debido a que allí es donde se gasta el mayor esfuerzo de desarrollo. Son la base para determinar la factibilidad del sistema.

3.5.6 ANÁLISIS DE FACTIBILIDAD DEL SISTEMA. Su objetivo es concluir, con base en los recursos disponibles y los estimativos de desarrollo realizados, cual es la posibilidad de desarrollo del sistema propuesto. El alcance de este libro es definir la factibilidad del sistema bajo tres ítems: Financiera, Técnica, Operativa.

3.5.6.1 Factibilidad Financiera. Es necesario conocer e identificar todos los beneficios y costos inherentes al sistema.

3.5.6.1.1 Beneficios.

3.5.6.1.1.1 Económicos. Estos se determinan a partir de los objetivos cuantificables. Expresados en períodos de tiempo (por ejemplo: Reducción del costo de papelería en $100.000 mensuales) y definidos según la duración del ciclo de operación o ejecución. Si el ciclo de vida de operación del proyecto, en el ejemplo es de 36 meses(3 años), entonces el beneficio económico sería ITEM REDUCCIÓN MENSUAL TIEMPO DE CICLO REDUCCIÓN DE OPERACIÓN TOTAL

Anteproyecto 46

Papelería $ 100.000 36(3 Años) $3’600.000 Se deben mirar aspectos como: Reducción de personal, mayores ventas, mayor rentabilidad financiera, disminución de costos, etc. Se deben tener en cuenta los objetivos cuantitativos antes planteados, para poder organizar mejor la parte financiera, ya que ellos están definidos en términos de incrementos de utilidades y rebajas de costos, aspectos que son tangibles financieramente hablando.

3.5.6.1.1.2 No Económicos. Se involucran los siguientes aspectos: Organización y control, Información más completa y segura, oportunidad en la información, mejor ambiente operativo, mayor good will, etc. Aquí también es importante contemplar aquellos objetivos que tienen que ver con el mejor servicio al cliente.

3.5.6.1.2 Costos.

3.5.6.1.2.1 De Desarrollo. Son los costos estimados que incluyen: Salarios del personal de desarrollo, usuarios, conversión y preparación de archivos y documentos, pruebas del sistema, capacitación, costos de arranque, computadores, etc.

3.5.6.1.2.2 De Equipo de Procesamiento. Se debe estimar si se requieren equipos especiales, tales como lectores de códigos de barras, impresoras de fines específicos, plotters, etc. Estos costos se adicionarán al sistema.

3.5.6.1.2.3 De Operación.

Anteproyecto 47

Se debe tratar de llegar a evaluar costos para factores como: Resistencia al cambio, mayor carga de trabajo, indisposición administrativa y operativa. En general los costos se determinan tomando en cuenta el tiempo del Ciclo de vida de Desarrollo, es decir, los valores desembolsados solo en el tiempo de duración real del proyecto, sin tener en cuenta el los egresos durante el tiempo de operación del proyecto . Ejemplo: A continuación se toma el ejemplo del proyecto SIARI (Ver anexo 2): RECURSOS PARA EL DESARROLLO ��

Totales Recursos Administrativos Recurso Concepto Sub Total

Diana Patricia Zuluaga Diego Paniagua Zapata Danny Hersain Gomez

Recurso Humano 6.300,000

PHP 4+ Lenguaje de programación 0,000 MySQL Gestor de Base de Datos 0,000

Papelería Material y suministros 116,004 Internet Material y suministros 90,006

Computador Alquiler de equipos 195,000 Transporte Transporte 2.520,000

Asesor Asesor de Proyectos 840,000 Total 10.061,010

PERSONAL: �� !�"��#��

Anteproyecto 48

$��!��%��&��'�� #�(��"��'��'�)�#�%��*��!��#��"��)�� "�� +��,+��-��%��

• �� ...�/�011' ��234�'��*�'�� 31"5�'��'�� &"��6��783�9� ��$��%�*:'��

��,+��-��• �;��<=�• '��>��

�

�� ;��)��?�� !��-�� <�� -�� @��6�� A��!�� ,� � ��B�� CDE711�122�� 6��

�� ,� �-��#�� 6��-��,�� A � ��6��

Anteproyecto 49

�

�

�� !��

��

��

�� "#$%&$'$($$

��!� ��

�� "'$&$%'&$'$

BENEFICIOS Personal Salario / Mes Reducción Valor Vida Útil /

Sistema Total

Jefe de Departamento

$ 1.000.000 90% $ 450.000 36 $ 16.200.000

Secretaria $ 360.000 50% $ 180.000 36 $ 6.480.000 Transporte Mensajero

$ 200.000 50% $ 100.000 36 $ 3.600.000

COSTOS )��*�� !��+�� ,��-��.� !�� !��,�� !��

��

�� "'/0&$$$

��

��*�� !��+�� ,��-��.� !�� !��,�� !��

�� !��

�"!#$� �� !��

�� "$

��

1��2�� )��

��)��2�� !�� !��

%��

&��

�� "3&'4$&$$$

�� 2�� 5�� 2�� !��

�� !��

'�� (��

�� "#&0#$&$$$

Anteproyecto 50

Finalización del ejemplo (SIARI Factibilidad Financiera). Para que el sistema sea factible financieramente, se requiere:

• Que la empresa cuente con el dinero suficiente para cubrir los costos de: Desarrollo, equipo y operación.

• Que los beneficios sean mayores a los costos. • Si los beneficios no se pueden expresar en términos económicos, los no

económicos deben tener el suficiente peso administrativo, como para incurrir en los costos económicos.

• Que los costos intangibles no sean lo suficientemente altos como para anular los beneficios económicos.

Si todo esto se cumple, el proyecto es factible financieramente.

3.5.6.2 Factibilidad Técnica. Se determina evaluando el software y hardware de soporte necesarios para el sistema, teniendo en cuenta los recursos que consumiría su desarrollo y operación posterior. En caso de no existir algunos de estos recursos en la empresa, el sistema seguirá siendo factible técnicamente siempre y cuando hubiese en el mercado modo de conseguirlos en el tiempo requerido.

3.5.6.3 Factibilidad Operativa. Para que el sistema sea factible operativamente, se deben cumplir los siguientes requisitos: a) Disponibilidad y disposición del personal de desarrollo y usuarios para llevar

adelante el proyecto. b) Capacidad del personal de sistemas para el desarrollo del nuevo sistema y de

los usuarios para operarlo adecuadamente. c) Viabilidad en la adecuación y cambio de normas administrativas y operativas

necesarias para que el sistema funcione. d) Viabilidad en la adecuación física requerida para que opere el sistema. e) En general, poder solucionar cualquier otro aspecto que dificulte la marcha

operativa del proyecto. La tarea de medir la factibilidad financiera, técnica y operativa, es la actividad más importante dentro del estudio de factibilidad. Por lo tanto se debe llevar a cabo con la seriedad y el compromiso de todos los integrantes del equipo de desarrollo, para evitar realizar sistemas que en la realidad no se puedan operar por falta de usuarios idóneos (factibilidad operativa), no se puedan implementar por falta de

Anteproyecto 51

presupuesto (factibilidad financiera) o no se puedan realizar dado que la tecnología de la organización no es adecuada (factibilidad técnica). Lo anterior, para concluir que el sistema debe cumplir los tres aspectos de factibilidad para que sea viable su realización. En caso de que alguna se cumpliera y fuera de vital importancia se puede tomar también la decisión de llevar a cabo el proyecto

3.5.7 ALTERNATIVAS Y RECOMENDACIONES. El desarrollo de un sistema ofrece múltiples alternativas, resultantes de su alcance, nivel de detalle, recursos requeridos y modo de procesamiento. Cuando estas alternativas son factibles de implementar, deben ser presentadas como parte del estudio de factibilidad, buscando con ello dar mayores elementos y cursos de acción a la administración para que tome la decisión más acertada. Para cada alternativa deben existir ventajas y desventajas que se deben bosquejar por parte del grupo. Las alternativas pueden ser muy variadas y dependerán de las circunstancias de cada proyecto y del entorno tecnológico. Las alternativas variarán de acuerdo con: Alcance del sistema, modo de procesamiento, nivel de detalle del desarrollo, recursos requeridos, situación financiera, situación técnica, etc. El grupo, por último, deberá recomendar la alternativa más adecuada, de acuerdo con su juicio, para que los directivos (usuarios dueños), tomen la decisión más adecuada posible. Se deben plantear como mínimo tres alternativas de solución diferentes, para el nuevo sistema, con sus respectivas ventajas y desventajas.

3.5.8 CRONOGRAMA DE ACTIVIDADES. Se proyecta el tiempo de las actividades generadas en la ejecución del sistema. Da la base para la evaluación y control del avance del proyecto. Se utiliza normalmente el diagrama de Gantt. Al final de la encuesta o estudio de factibilidad: Una estimación puede variar en más o menos un 50 por ciento. Se puede decir entonces, que el sistema tardará un año y costará $2’000.000, más o menos un

Anteproyecto 52

50 %. En realidad puede demorarse 18 meses y costar $3’000.000. Al final de análisis, la estimación puede variar en más o menos un 25% Al final del diseño, puede variar en más o menos un 10%. En la fase de programación, cuando faltan las pruebas, se desfasará en más o menos 5%. Vemos entonces, que no se puede mejorar lo que no se mide. Ejemplo de cronograma:

Anteproyecto 53

CRONOGRAMA DE ACTIVIDADESACTIVIDADES TIEMPO

SEMANAS 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

ANÁLISIS 7 SEMANAS

Sistema actualRequerimientosSistema propuestoRevisiónDISEÑO 9 SEMANAS

Diseño GlobalDiseño DetalladoBase de DatosPrototipoRevisiónCONSTRUCCION 15SEMANAS

PRUEBAS 2

PUESTA EN MARCHA

3 SEMANAS

DICIEMBRE ENERO FEBRERO MARZO

NOMENCLATURA

AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE

PUNTOS DE CONTROL

ACTIVIDAD RESUMEN

ACTIVIDAD REAL

Análisis 54

3.5.9 DECISIÓN FINAL. Tan pronto se desarrollen todos los puntos anteriores, se efectuarán los siguientes pasos: • Revisión final del documento generado en el Anteproyecto, por parte del grupo. • Entrega del documento al comité de sistemas (Si existe el comité). • Análisis del documento por parte del comité y decisión final sobre la alternativa

de desarrollo más apropiada. • En otro caso, la no realización del proyecto.

Análisis 55

3.6 RESUMEN. ENTRADAS PROCESO PARTICIPACION SALIDAS Requerimientos de Información de usuarios.

1. Reconocimiento General del sistema.

1.1 Ubicación general

Usuario Líder. Analistas.

Anteproyecto.

Recursos de Sistemas.

del sistema. 1.2 Alcance.

Documentación.

Normas, Políticas. 1.3 Objetivos. 2. Definición del

Usuarios (Todos).

Cronograma.

Sistema. 2.1 Medio Ambiente.

Analistas.

2.2 Entradas y salidas.

2.3 Relaciones. 3. Recursos para el

desarrollo. Usuario Líder. Analistas.

3.1 Económicos. 3.2 Personal.

3.3 Hardware.

3.4 Software. 4. Estimativos de Analistas. desarrollo. 5. Análisis de Usuario. Factibilidad.

5.1 Financiera. Analistas.

5.2 Técnica. 5.3 Operativa. 6 Alternativas y

Recomendaciones. Analistas.

7. Decisión Final. Usuario Líder. 8. Cronograma. Analistas.

Análisis 56

4. ANÁLISIS.


CONCEPTOS Y PRINCIPIOS DEL ANÁLISIS LIBRO PRESSMAN PAG 181 A LA 189, 196, 199 a la 216 El análisis de requisitos del sistema constituye el primer intento de comprender cuál va a ser la función y ámbito de información de un nuevo proyecto. El objetivo es conseguir representar un sistema en su totalidad, incluyendo hardware, software y personas, mostrando la relación entre los diversos componentes y sin entrar en la estructura interna de los mismos. En algunos casos se nos plantearán diferentes posibilidades y tendremos que realizar un estudio de cada una de ellas. Indudablemente, los esfuerzos realizados en esta fase producen beneficios en las fases posteriores. Sin embargo se nos pueden plantear las siguientes dudas:

? ¿Cuánto tiempo debe dedicarse al análisis del sistema? Dependerá de la naturaleza, el tamaño y la complejidad de la aplicación. Una directriz que se podría aplicar es dedicar entre un 10% y un 20% del esfuerzo total estimado al análisis del sistema y otro 10% o 20% al análisis de requisitos del software. El esfuerzo que se le dedica normalmente es mucho menor:. En la mayoría de los proyectos la mayor parte del esfuerzo se va en la codificación, precisamente por la dificultad de realizar la codificación cuando no se ha hecho un buen análisis previo.

? ¿Quién debe hacerlo? La respuesta es fácil: el analista de sistemas. Este debe ser una persona con buena formación técnica y con experiencia. No obstante, el analista no trabaja de forma aislada sino en estrecho contacto con el personal de dirección, técnico y administrativo tanto del cliente como del que desarrolla el software.

? ¿Por qué es una tarea tan difícil? Básicamente porque consiste en la traducción de unas ideas vagas de necesidades de software en un conjunto concreto de funciones y restricciones. Además el analista debe extraer información dialogando con muchas personas y cada una de ellas se expresará de una forma distinta, tendrá conocimientos informáticos y técnicos distintos, y tendrá unas necesidades y una idea del proyecto muy particulares.

Análisis 57

4.1.1 OBJETIVOS. El papel del analista de sistemas es el de definir los elementos de un sistema informático dentro del contexto del sistema en que va a ser usado. Hay que identificar las funciones del sistema y asignarlas a alguno de sus componentes. Para ello, el analista de sistemas parte de los objetivos y restricciones definidos por el usuario y realiza una representación de la función del sistema, de la información que maneja, de sus interfaces y del rendimiento y las restricciones del mismo. En la mayoría de los casos, el proyecto empieza con un concepto más bien vago y ambiguo de cuál es la función deseada. Entonces el analista debe delimitar el sistema, indicando el ámbito de funcionamiento y el rendimiento deseados. Por ejemplo, en el caso de un sistema de control, no basta con decir algo así como ‘el sistema debe reaccionar rápidamente en caso de que la señal de entrada supere los límites de seguridad’ sino que hay que definir cuáles son los límites de seguridad de la señal de entrada, en cuánto tiempo debe producirse la reacción y cómo ha de ser esta reacción. Una vez que se ha logrado delimitar la función, el ámbito de información, las restricciones, el rendimiento y las interfaces del sistema, el analista debe proceder a la asignación de funciones. Las funciones del sistema deben de ser asignadas a alguno de sus componentes (ya sean éstos software, hardware o personas). El analista debe estudiar varias opciones de asignación (considerando, por ejemplo, la posibilidad de automatizar o no alguna de estas funciones), teniendo en cuenta las ventajas e inconvenientes de cada una de ellas (en cuanto a viabilidad, costes de desarrollo y funcionamiento y fiabilidad) y decidirse por una de ellas, o bien presentar un estudio razonado de las opciones a quienes tengan que tomar la decisión. Para explicar todo lo anterior podemos poner el siguiente ejemplo:

Especificación informal del sistema de clasificación de paquetes.

El sistema de clasificación de paquetes debe realizarse de forma que los paquetes que se mueven a lo largo de una cinta transportadora sean identificados (para lo cual van provistos de un código numérico) y clasificados en alguno de los seis contenedores situados al final de la cinta. Los paquetes de cada tipo aparecen en la cinta siguiendo una distribución aleatoria y están espaciados de manera uniforme. La velocidad de la cinta debe ser tan alta como sea posible; como mínimo el sistema debe ser capaz de clasificar 10 paquetes por minuto. La carga de paquetes al principio de la cinta puede realizarse a una velocidad máxima de 20 paquetes por minuto. El sistema debe funcionar las 24 horas del día, siete días a la semana.

Análisis 58

Función del sistema.

Realizar la clasificación de paquetes que llegan por una cinta transportadora en seis compartimentos distintos, dependiendo del tipo de cada paquete.

Información que se maneja.

Los paquetes disponen de un código numérico de identificación. Debe existir una tabla o algoritmo que asigne a cada número de paquete el

contenedor donde debe ser clasificado.

Interfaces del sistema.

El sistema de clasificación se relaciona con otros dos sistemas. Por un lado tenemos la cinta transportadora. Parece conveniente que el sistema de clasificación pueda parar el funcionamiento de la cinta o del sistema de carga de paquetes en la cinta, en caso de que no pueda realizar la clasificación (por ejemplo si se produce una avería). Por otro lado, el sistema deposita paquetes en los contenedores, pero no se establece ningún mecanismo de vaciado o sustitución de los contenedores si se llenan. El sistema debería ordenar la sustitución o vaciado del contenedor o esperar mientras un contenedor esté lleno.

Como la descripción realizada por el cliente no establece los mecanismos para solventar estas dos situaciones estos detalles deben ser discutidos con el cliente.

Rendimiento.

El sistema debe ser capaz de clasificar al menos 10 paquetes por minuto. No es necesario que el sistema sea capaz de clasificar más de 20 paquetes por minuto.

Restricciones.

El sistema debe tener un funcionamiento continuo. Por tanto, debemos evitar la parada del sistema incluso en el caso de que para alguno de los componentes del mismo se averíen.

El documento no indica restricciones sobre la eficacia del sistema, es decir, sobre cuál es el porcentaje máximo que se puede tolerar de paquetes que pueden ser clasificados de forma errónea. Estos detalles también deben ser aclarados con el cliente.

Análisis 59

Asignación de funciones.

Podemos considerar tres asignaciones posibles: Asignación 1. Esta asignación propone una solución manual para implementar el sistema. Los

recursos que utiliza son básicamente personas, y se requiere además algo de documentación, definiendo las características del puesto de trabajo y del sistema de turnos y una tabla que sirva al operador para relacionar los códigos de identificación de los paquetes con el contenedor donde deben ser depositados.

La inversión necesaria para poner en marcha este sistema es mínima, pero requiere una gran cantidad de mano de obra (varios turnos de trabajo y operadores de guardia) con lo que los costes de funcionamiento serán elevados. Además hay que tener en cuenta que lo rutinario del trabajo provocará una falta de motivación en los operarios, lo que a la larga se acabará traduciendo en un mayor absentismo laboral. Todos estos factores deben de tenerse en cuenta a la hora de elegir esta u otra opción.

Asignación 2. En este caso, la solución es automatizada. Los recursos que se utilizan son:

hardware (el lector de códigos de barras, el controlador, el mecanismo de distribución), software (para el lector de códigos de barras y el controlador, y una base de datos que permita asignar a cada código su contenedor) y personas (si en caso de avería la distribución se va a hacer manualmente). Cualquiera de los elementos hardware y software tendrán la correspondiente documentación sobre cómo han sido construidos y un manual de usuario.

Aquí si hay que realizar una cierta inversión, para comprar o desarrollar los componentes del sistema, pero los costes de funcionamiento serán sin duda menores (sólo el consumo de energía eléctrica). Hay que tener en cuenta que el uso de dispositivos mecánicos (el mecanismo de distribución) va a introducir unos costes de mantenimiento y paradas por avería o mantenimiento con una cierta frecuencia.

Asignación 3. Los recursos que utilizamos aquí son: hardware (el lector, el brazo robot), software

(el del lector, el del robot, incluyendo la tabla o algoritmo de clasificación) y la documentación y manuales correspondientes a estos elementos.

En este caso la inversión inicial es, sin duda, la más elevada. Los costes de funcionamiento son bajos pero hay que considerar también el coste de mantenimiento del robot, que posiblemente tenga que ser realizado por personal especializado. Los únicos motivos que nos harían decidir por esta opción en vez de la anterior vendrían dados por una mayor velocidad, un menor número de errores o unas menores necesidades de mantenimiento o frecuencia de averías.

Por otra parte esta solución puede tener problemas de viabilidad (si no encontramos un brazo robot que sea capaz de atrapar los paquetes según pasan por la cinta).

Análisis 60

Además de las tres opciones propuestas, el ingeniero de sistemas debe considerar también la adopción de soluciones estándar al problema. Hay que estudiar si existe ya un producto comercial que realice la función requerida para el sistema o si alguna de las partes del mismo pueden ser adquiridas a un tercero. Aparte de considerar el precio de estos productos habrá que tener también en cuenta los costes del mantenimiento y el riesgo que se asocia al depender de una tecnología que no es propia (¿es la empresa proveedora estable?, ¿cuál es la calidad de sus productos?) valorando todo esto frente a los riesgos asociados a realizar el desarrollo nosotros mismos. La labor del ingeniero o analista de sistemas consiste, en definitiva, en asignar a cada elemento del sistema un ámbito de funcionamiento y de rendimiento. Después, el ingeniero del software se encargará de refinar este ámbito para el componente software del sistema y de producir un elemento funcional, que sea capaz de ser integrado con el resto de los elementos del sistema. Los objetivos principales son: • Obtener el conocimiento DETALLADO del sistema de información actual y de

TODOS los requerimientos y necesidades de información adicionales. • Realizar una reevaluación del preanálisis, con base en un conocimiento más

detallado del sistema, que permita hacer estimativos más reales, llegando a determinar factibilidades, alternativas y cronogramas más precisos, además de confirmar o aclarar completamente el alcance planteado anteriormente.

• Servir de puente de comunicación entre la parte administrativa y la parte

técnica. Se traduce el lenguaje del usuario a un lenguaje de sistemas, que permita su desarrollo posterior.

• Emitir una formulación específica de los modelos lógicos, que representen lo

que va a ser el nuevo sistema, con base en los requerimientos planteados por el usuario.

• Plantear consideraciones para el desarrollo del resto de etapas, especialmente

para el diseño. • Encontrar lo que la organización requiere que se haga antes de comenzar a

imaginarse cómo hacerlo.

4.1.2 DEFINICION.

Análisis 61

Es la transformación disciplinada de los requerimientos de información de un sistema o área, en una ESPECIFICACION FUNCIONAL, expresada en términos lógicos y usando metodologías estándares. Es el proceso de determinar QUE se necesita hacer, antes de decidir COMO debe hacerse. Es el acto del descubrimiento. Responde a las preguntas: QUE ES LO QUE HACE EL SISTEMA? QUE HARA EL NUEVO SISTEMA? Gráficamente:

De la definición anterior, es conveniente aclarar los siguientes términos: REQUERIMIENTO: Es una necesidad de información que debe satisfacer un sistema. Sólo representa lo que el usuario piensa, debe contemplar el sistema. No es necesariamente lo que en realidad necesita o es conveniente. ESPECIFICACIÓN FUNCIONAL: Es el documento donde se consigna en forma lógica y ordenada lo que el sistema debe hacer, a través de la descomposición del mismo en subsistemas. Para ello, se ESPECIFICAN a través de diferentes herramientas técnicas, los procesos, datos y operaciones que se van a manejar allí. Aplicando el enfoque de sistemas, tenemos: 1. Conocer el sistema actual. 2. Analizar los nuevos requerimientos de información.

Análisis 62

3. Revisar el preanálisis. 4. Proponer el nuevo sistema. 5. Planear actividades futuras.

4.2 IMPORTANCIA DEL ANÁLISIS. Logra integrar las necesidades y requerimientos de información de un área, en un modelo ordenado, entendible por directivos y usuarios, permitiendo la maduración y perfeccionamiento del nuevo sistema de información, llegando a los más mínimos niveles de detalle.

4.3 CARACTERÍSTICAS DEL ANÁLISIS. • Existe dificultad de comunicación entre analistas y usuarios. No hay un

lenguaje común entre usuarios y analistas. • Se crean relaciones interpersonales, que en ocasiones desvían al grupo de los

objetivos del proyecto. • El desarrollo del análisis se efectúa basado en el continuo diálogo e

intercambio de ideas y conocimientos entre el grupo de desarrollo. Pueden surgir diferencias que atrasen la marcha normal de la etapa.

• Las necesidades de información de un área no son estáticas; cambian permanentemente y en tal sentido al definir el sistema es necesario proyectar cambios futuros, si estos son predecibles y controlables por el sistema mismo.

• Cambios en el manejo y estructura administrativa y operativa del área. • Plantear un nuevo sistema, supone cambios a nivel administrativo y

adaptaciones del área. Se revisan funciones, estructura, procedimientos, etc.

4.4 PARTICIPACIÓN REQUERIDA. La elaboración de ésta etapa, supone un grupo de trabajo conformado por usuarios, analistas y auditores. USUARIOS: Personas de la administración que de una u otra forma se beneficiarán de la información suministrada por el sistema. Se clasifican en : USUARIO DUEÑO: Corresponde al dueño de la empresa o al alto directivo que tiene como responsabilidad velar por los objetivos generales de la organización. Decide si el sistema se desarrolla o no, con base en el estudio de factibilidad. USUARIO RESPONSABLE:

Análisis 63

Define el nuevo sistema, de acuerdo a los requerimientos de información existentes. Es una persona de mandos medios. USUARIO FINAL: Es quien utiliza directamente el sistema. La participación del usuario es importante porque : • Asegura que el sistema sea aceptado. • Reduce la oposición al cambio. • Ayuda a detectar conflictos organizacionales. ANALISTAS: Funcionarios encargados de definir en detalle, qué es y qué será el sistema. Es el enlace entre el usuario y el grupo de implementación (en ocasiones, el grupo de implementación, son los mismos analistas). Debe tener conocimientos administrativos, de las áreas de la empresa, de relaciones humanas, de sistemas. Debe ser un guía, un orientador para canalizar inquietudes del usuario respecto a las posibilidades técnicas. Debe ser líder, con capacidad de influir sobre el grupo. Debe demostrar seguridad y confianza y ser un gran comunicador. Debe ser un investigador, ya que el análisis es un proceso de descubrimiento. Se puede dar el lujo de suponer una tecnología perfecta, ya que su trabajo va más enfocado a descubrir procesos y requerimientos. AUDITORES DE SISTEMAS: Tienen como finalidad velar por la inclusión de los controles internos en el sistema y de los requerimientos propios de la auditoria.

4.5 PASOS EN EL DESARROLLO DEL ANALISIS. Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en el análisis de un sistema de información. Cada una de estas tareas debe estar claramente documentada, en el manual de factibilidad del sistema.

Análisis 64

4.5.1 ANALISIS DEL SISTEMA ACTUAL. Se busca conocer con todo el detalle, cuál es el funcionamiento actual del área y en especial, cuál es el MANEJO Y FLUJO DE LA INFORMACIÓN PRODUCIDA Y QUE LLEGA AL ÁREA. Es una labor totalmente descriptiva y de conocimiento por parte del grupo. Incluye: • Definición de objetivos y funcionamiento del área. • Información que alimenta al sistema. • Definición de los procesos de información existentes, qué hacen, cómo lo

hacen, con qué información lo hacen y qué resultados arrojan. Esto se logra a través de diferentes medios: • Manuales de normas administrativas y operativas. • Manuales de procedimientos administrativos y operativos. • Diagramas de flujo de documentos. • Entrevistas con usuarios. • Observación directa de los procesos y manejo de la información.

4.5.2 ANÁLISIS REQUERIMIENTOS DEL NUEVO SISTEMA. Se pretende conocer con todo el detalle, cuáles son los requerimientos de información del usuario. El usuario presenta inquietudes que él mismo NO sabe si pueden ser resueltas y omite otras que considera secundarias. Comprende:

Análisis 65

• Conocimiento de la lista de necesidades y nuevos requerimientos de

información del usuario (al detalle). • Exploración de otros posibles requerimientos del sistema, teniendo en cuenta

las posibilidades técnicas de cómputo y las necesidades futuras del área. • Clasificación y agrupación de los requerimientos. Normalmente esta información se obtiene a través de entrevistas con el usuario y de observación directa de los procesos.

4.5.3 REVALUACIÓN DEL PREANÁLISIS. Luego de conocer en detalle el funcionamiento del sistema actual y la definición concreta de los requerimientos del nuevo sistema, se debe hacer una reevaluación de los puntos tratados en el estudio de factibilidad, debido a que en la primera etapa no se conocía en forma detallada el sistema. Puede incluir: • Modificación de la definición del sistema. • Modificación de los recursos asignados. • Modificación de los estimativos. • Inclusión de nuevas alternativas de desarrollo. • Cambios en la factibilidad del sistema. • Modificación al cronograma. Sólo se revalúa si se encuentran variaciones importantes que cambien el rumbo inicial del proyecto.

4.5.4 DESARROLLO DE LAS ESPECIFICACIONES DEL SISTEMA PROPUESTO. Es el trabajo central del análisis, donde se representan los requerimientos del sistema (nuevos y actuales), en un MODELO LOGICO y ESTRUCTURADO que de respuesta a las verdaderas necesidades de información del área. Se requiere tener claramente definido el sistema actual, los nuevos requerimientos y el estudio de factibilidad revaluado. El resultado final, son las especificaciones funcionales, cuya herramienta para elaborarlas se denomina ANÁLISIS ESTRUCTURADO. Las especificaciones deben contener: • Definición del flujo o recorrido de información en el sistema, partiendo de donde

se origina hasta llegar a su destino final. Puede ser en forma narrativa o a través de gráficas.

Análisis 66

• Definición de las estructuras de información requeridas en el sistema. • Descripción de cada uno de los procesos o funciones que realiza el sistema. • Definición de las interfases o relaciones existentes entre los procesos del

sistema. • Definición de relaciones entre los almacenamientos de información requeridos

por el sistema. Una herramienta para la elaboración de especificaciones funcionales es el Análisis Estructurado, que se verá en detalle más tarde.

4.5.5 REVISIÓN DEL ANÁLISIS. Busca obtener aprobación de lo realizado en el análisis. Participantes: Usuario dueño, usuarios responsables, analistas, auditor, director de sistemas. Se debe revisar: • Que estén completos todos los requerimientos formulados por el usuario. • Que sea factible la adecuación de normas y procedimientos para la

implantación del sistema. • Que las especificaciones estén bien definidas técnicamente: procesos,

almacenamientos, relaciones. • Que estén considerados los requerimientos de auditoría. • Que las especificaciones contemplen todos los aspectos necesarios para el

diseño. • Que exista documentación. • Que haya acuerdo entre las partes. TÉCNICAS DE REVISIÓN. Existen múltiples técnicas que ayudan al grupo en la tarea de revisión de las especificaciones resultantes en la etapa del análisis. Puede decirse que cada sistema define su propia técnica de revisión. Sin embargo, formalmente, estas técnicas se pueden clasificar así: INFORMALES FORMALES DETALLADA Muy Productiva Optimas para el control SUPERFICIAL No recomendadas No recomendadas La elección del grado de detalle y formalidad, depende de la importancia del sistema, estilo administrativo de la empresa y de la auditoría. La revisión obliga a reforzar la calidad del análisis y resuelve dudas entre los interesados.

Análisis 67

4.5.6 ENTREGA A LA ETAPA DE DISEÑO. Después de efectuar la revisión de las especificaciones y realizar los ajustes del caso, se hace entrega de las especificaciones al diseñador.

4.6 METODOLOGÍAS DE ANÁLISIS. Existen diferentes enfoques metodológicos para acometer esta fase del desarrollo de sistemas de información. Algunos son:

4.6.1 METODOLOGIAS TRADICIONALES. Se originaron a partir de los años 50, con el uso del computador, como herramienta para procesar datos. Sus características son: • Son totalmente narrativas. • No hay una definición clara de las diferentes actividades que encierra el

análisis. • No existen ayudas gráficas. Con éstas metodologías, se presentan algunos inconvenientes como : • No se puede obtener una visión global e integrada del sistema. • No hay documentación completa, se dificulta la revisión y administración del

sistema. • Se generan mayores costos, pues hay mayor mantenimiento. • No se puede realizar diseño estructurado. • Existe poca estandarización de tareas y actividades.

4.6.2 METODOLOGIAS ESTRUCTURADAS. Se originan a partir de los años 70. Se fundamentan en una visión global del sistema que luego se detalla para cada una de las funciones, logrando un mejor entendimiento y organización de cada una de ellas. Su clasificación se miró anteriormente en el capítulo de Introducción. Características: • Enfatiza en el método TOP DOWN (visión que va de lo general a lo específico). • Se tiene una visión integral del sistema a estudiar. • Es totalmente gráfica. • Posee un alto grado de estandarización en sus tareas. • Se presta para posibles inclusiones de modificaciones futuras. • La parte textual es complementaria de la gráfica, a nivel de apoyo y aclaración. • Permite ver el sistema por segmentos, en forma descendente.

Análisis 68

• Se trata de manejar redundancia mínima en cuanto a las tareas a ejecutar. • Es transparente para el lector, otorgando un entendimiento rápido y global del

sistema. • Ayuda a predecir el comportamiento del sistema en el futuro. Algunos inconvenientes que se presentan en estas metodologías, son: • Se debe preparar una documentación muy extensa, para las diferentes tareas

que se deben realizar. • Se emplea mayor tiempo para su desarrollo, ya que exige mayor planeación y

conocimiento del sistema. • Se debe contar con personal capacitado en la metodología.

4.7 ANÁLISIS DE REQUISISTOS. La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software —inicialmente asignado por el ingeniero del sistema—. Se crean modelos de los requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan soluciones alternativas y el modelo completo del análisis es creado. Donald Reifer describe el proceso de ingeniería de requisitos del software en el siguiente párrafo: La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos del software —un conjunto de actividades que son denominadas análisis—. El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como un interrogador, como consultor, como persona que resuelve problemas y como negociador.

4.7.1 VISTAZO RÁPIDO

¿Qué es? El papel global del software en un gran sistema es identificado durante la

ingeniería del sistema (Libro: “Ingeniería del software” 5ª edición Roger Pressman Capítulo 10). De cualquier manera, es necesario considerar una visión lo más profunda posible del papel del software —para comprender los requisitos

Análisis 69

específicos que deben ser considerados en la construcción de un software de alta calidad—. Este es el trabajo del análisis de requisitos del software. Para realizar el trabajo adecuadamente, se deben seguir un conjunto de conceptos y principios fundamentales.

¿Quién lo hace? Generalmente, el ingeniero del software es quién realiza el análisis de requisitos. En cualquier caso, para aplicaciones de negocio complejas, un «analista de sistemas» —formado en los aspectos del negocio del dominio de la aplicación— puede realizar esta tarea.

¿Por qué es importante? Si no analizas, es muy probable que construyas una solución software muy elegante que resuelva incorrectamente el problema. El resultado es tiempo y dinero perdido, frustración personal y clientes descontentos.

¿Cuáles son los pasos? Los requisitos de datos, funciones y comportamiento son identificados por la obtención de información facilitada por el cliente. Los requisitos son refinados y analizados para verificar su claridad, completitud y consistencia. La especificación se incorpora al modelo del software y es validada tanto por el ingeniero del software como por los clientes/usuarios.

¿Cuál es el producto obtenido? Una representación efectiva del software debe ser producida como una consecuencia del análisis de requisitos. Tanto los requisitos del sistema como los requisitos del software pueden ser representados utilizando un prototipo, una especificación o un modelo simbólico.

¿Cómo puedo estar seguro de que lo he hecho correctamente? El resultado obtenido del análisis de requisitos del software debe ser revisado para conseguir: claridad, completitud y consistencia. El análisis y la especificación de los requisitos puede parecer una tarea

relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: «Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir.» El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software (Figura a continuación) El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y esta-blece las restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado. (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante enten-der el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un

Análisis 70

correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.

La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global. Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente: (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.

Figura. 4.7.1 Análisis como puente entre la ingeniería y el diseño de software. Una vez evaluados los problemas actuales y la información deseada (entrada y salida), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento

Análisis 71

del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software'? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables? Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.

4.7.2 IDENTIFICACIÓN DE REQUISITOS PARA EL SOFTWARE

Antes que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a través de un proceso de obtención. Un cliente tiene un problema que pretende sea resuelto con una solución basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. La comunicación ha empezado. Pero como ya hemos señalado, el camino de la comunicación al entendimiento está a menudo lleno de baches.

4.7.2.1 Inicio del proceso La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) y el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes); los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito. Sin embargo, hay que empezar la comunicación. Gause y Weinberg [GAU89] sugieren que el analista empiece preguntando cuestiones de contexto libre. Es decir,

Análisis 72

un conjunto de preguntas que llevarán a un entendimiento básico del problema, qué solución busca, la naturaleza de la solución que se desea y la efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría preguntar: ¿Quién está detrás de la solicitud de este trabajo? ¿Quién utilizará la solución? ¿Cuál será el beneficio económico del éxito de una solución? ¿Hay alguna otra alternativa para la solución que necesita? Estas preguntas ayudan a identificar todos los participantes que tienen un interés en el software a construir. Además, las preguntas identifican los beneficios medibles en una implementación correcta de posibles alternativas para un desarrollo normal del software. El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución: ¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena solución? ¿A qué tipo de problema(s) va dirigida esta solución? ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución? El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg las denominan «meta-preguntas» y proponen la siguiente lista (abreviada): ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son «oficiales»? ¿Estoy preguntando demasiado? ¿Hay alguien más que pueda proporcionar información adicional? ¿Hay algo más que debería preguntarle? Estas preguntas (y otras) ayudarán a «romper el hielo» e iniciar la comunicación tan esencial para el éxito del análisis. Pero el formato de reunión tipo «pregunta y respuesta» no es un enfoque que haya tenido mucho éxito. De hecho, esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituirse después por una modalidad que combine elementos de resolución del problema, negociación y especificación. En la siguiente sección se presenta un enfoque a reuniones de este tipo.

4.7.2.2 Técnicas para facilitar las especificaciones de una aplicación Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no

Análisis 73

funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo. Con estos problemas en mente es por lo que algunos investigadores independientes han desarrollado un enfoque orientado al equipo para la reunión de requisitos que se aplica durante las primeras fases del análisis y especificación. Denominadas Técnicas para facilitar las especificaciones de la aplicación (TFEA), este enfoque es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución. Hoy en día, las TFEA son empleadas de forma general por los sistemas de información, pero la técnica ofrece un potencial de mejora en aplicaciones de todo tipo. Se han propuesto muchos enfoques diferentes de TFEA2. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variación en las siguientes directrices básicas: • La reunión se celebra en un lugar neutral y acuden

tanto los clientes como los desarrolladores. • se establecen normas de preparación y de participación. • se sugiere una agenda lo suficientemente formal como para cubrir todos los

puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas.

• Un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la reunión.

• Se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o pizarras).

• El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar el objetivo.

• Para comprender mejor el flujo de acontecimientos tal y como ocurren en una reunión TFEA, presentamos un pequeño escenario que esboza la secuencia de acontecimientos que llevan a la reunión, los que ocurren en la reunión y los que la siguen.

En las reuniones iniciales entre el desarrollador y el cliente, se dan preguntas y respuestas básicas que ayudan a establecer el ámbito del problema y la percepción global de una solución. Fuera de estas reuniones iniciales, el cliente y el desarrollador escriben una «solicitud de producto» de una o dos páginas. Se selecciona lugar, fecha y hora de reunión TFEA 1 y se elige un coordinador. Se invita a participar a representantes de ambas organizaciones; la del cliente y la de desarrollo. Se distribuye la solicitud de producto a los asistentes antes de la fecha de reunión.

1 Dos de los enfoques más populares de TFEA son Desarrollo Conjunto de Aplicaciones/UAD), desarrollado por IBM, y The METHOD, desarrollado por Performance Resources, Irte, Falls Church, VA.

Análisis 74

Mientras se revisa la solicitud días antes de la reunión, se pide a todos los asistentes que hagan una lista de objetos que formen parte del entorno del sistema, otros objetos que debe producir el sistema y objetos que usa el sistema para desarrollar sus funciones. Además, se pide a todos los asistentes que hagan otra lista de ser-vicios (procesos o funciones) que manipulan o interactúan con los objetos. Finalmente, se desarrollan también listas de restricciones (por ejemplo, costes, tamaño, peso) y criterios de rendimiento (por ejemplo, velocidad, precisión). Se informa a los asistentes que no se espera que las listas sean exhaustivas, pero que sí que reflejen su punto de vista del sistema. Por ejemplo2, imagínese que a un equipo de trabajo TFEA de una compañía de productos para el consumidor se le ha dado la siguiente descripción del producto:

Nuestras investigaciones indican que el mercado de sistemas de seguridad para el hogar está creciendo a un ritmo del 40 por 100 anual. Nos gustaría entrar en este mercado construyendo un sistema de seguridad para el hogar basado en un microprocesador que proteja y/o reconozca varias situaciones indeseables tales como irrupciones ilegales, fuego, inundaciones y otras. El producto, provisionalmente llamado Hogar Seguro, utilizará los sensores adecuados para detectar cada situación, puede programarse por el propietario del hogar y llamará automáticamente a una agencia de vigilancia cuando se detecte alguna de estas situaciones.

En realidad, se proporcionaría considerablemente más información en esta fase. Pero incluso con información adicional, habría ambigüedades presentes, existirán omisiones probablemente y podrían ocurrir errores. Por ahora, la «descripción de producto» anterior bastará. El equipo TFEA está compuesto por representantes de marketing, ingeniería del software y del hardware, y de la fabricación también participará un coordinador externo. Todos los componentes del equipo TFEA desarrollan las listas descritas anteriormente. Los objetos descritos para HogarSeguro podrían incluir detectores de humo, sensores de ventanas y puertas, detectores de movimientos, una alarma, un acontecimiento (se ha activado un sensor), un panel de control, una pantalla, números de teléfono, una llamada de teléfono, etc. La lista de servicios podría incluir la instalación de la alarma, vigilancia de los sensores, marcado de teléfono, programación del panel de control y lectura de la pantalla (fíjese que los servicios actúan sobre los objetos). De igual manera, todos los asistentes TFEA desarrollarán una lista de restricciones (por ejemplo, el sistema debe tener un coste de fabricación de menos de £80, debe tener una «interfaz amigable» con el usuario y debe conectar directamente con una línea telefónica estándar) y de criterios de rendimiento (por ejemplo, un acontecimiento detectado por un sensor debe reconocerse en un segundo; se debería implementar un esquema de prioridad de acontecimientos). Cuando empieza la reunión TFEA, el primer tema de estudio es la necesidad y justificación del nuevo producto, pues todo el mundo debería estar de acuerdo en que el desarrollo (o adquisición) del producto está justificada. Una vez que se ha 2 Ejemplo tomado del libro de “Ingeniería del software: Un enfoque práctico” De Roger Presuman, 5ª Edición

Análisis 75

conseguido el acuerdo, cada participante presenta sus listas para su estudio. Las listas pueden exponerse en las paredes de la habitación usando largas hojas de papel, pinchadas o pegadas, o escritas en una pizarra. Idealmente debería poderse manejar separadamente cada entrada de las listas para poder combinarlas, borrarlas o añadir otras. En esta fase, está estrictamente prohibido, el debate o las críticas. Una vez que se han presentado las listas individuales sobre un tema, el grupo crea una lista combinada. La lista combinada elimina las entradas redundantes y añade las ideas nuevas que se les ocurran durante la presentación, pero no se elimina nada más. Cuando se han creado las listas combinadas de todos los temas, sigue el estudio —moderado por el coordinador—. La lista combinada es ordenada, ampliada o redactada de nuevo para reflejar apropiadamente el producto o sistema que se va a desarrollar. El objetivo es desarrollar una lista de consenso por cada tema (objetos, servicios, restricciones y rendimiento). Después estas listas se ponen aparte para utilizarlas posteriormente. Una vez que se han completado las listas de consenso, el equipo se divide en subequipos; cada uno trabaja para desarrollar una mini-especificación de una o más entradas de cada lista4. La mini-especificación es una elaboración de la palabra o frase contenida en una lista. Por ejemplo, la mini-especificación del objeto panel de control de HogarSeguro podría ser: montado en la pared; tamaño aproximado 23 * 13 centímetros; contiene el teclado estándar de 12 teclas y teclas especiales; contiene una pantalla LCD de la forma mostrada en el bosquejo (no presentado aquí); toda la interacción del cliente se hace a través de las teclas usadas para activar o desactivar el sistema; software para proporcionar una directriz de empleo, recordatorios, etc., conectado a todos los sensores. Cada subequipo presenta entonces sus mini-especificaciones a todos los asistentes TFEA para estudiarlas. Se realizan nuevos añadidos, eliminaciones y se sigue elaborando. En algunos casos, el desarrollo de algunas mini-especificaciones descubrirá nuevos objetos, servicios, restricciones o requisitos de rendimiento que se añadirán a las listas originales. Durante todos los estudios, el equipo sacará a relucir aspectos que no podrán resolverse durante la reunión. Se hará una lista de estas ideas para tratarlas más adelante. Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una lista de criterios de validación del producto/sistema y presenta su lista al equipo. Se crea así una lista de consenso de criterios de validación. Finalmente, uno o más participantes (o algún tercero) es asignado para escribir el borrador entero de especificación con todo lo expuesto en la reunión TFEA. TFEA no es la panacea para los problemas que se encuentran en las primeras reuniones de requisitos, pero el enfoque de equipo proporciona las ventajas de muchos puntos de vista, estudio y refinamiento instantáneo y un paso adelante hacia el desarrollo de una especificación.

Análisis 76

Lecturas importantes: Capitulo 11 del Libro: “Ingeniería del software” de Roger Pressman, 5º edición.

Aquí voy MIRAR ESTE DOCUMENTO(ISE3.DOC) Ya se paso la parte de presuman hasta la pagina 186 Despliegue de la funcion de calñidad

5. ANÁLISIS ESTRUCTURADO

5.1.1 CONCEPTOS GENERALES.

5.1.1.1 DEFINICIÓN. Es una metodología para desarrollar especificaciones funcionales, usando el enfoque Top Down. Para generar especificaciones estructuradas de un sistema de información, usa como técnicas:

• Los diagramas de flujo de datos • Los diagramas de estructura de datos • Las miniespecificaciones • Diccionarios de datos.

Análisis 77

5.1.1.2 CARACTERÍSTICAS. • Utilización de gráficas para representar el sistema, evitando al máximo,

descripciones narrativas. • Enfatiza en el flujo de información y no en los flujos de control de un sistema. • Presenta una documentación extensa de cada tarea a realizar.

5.1.2 COMPONENTES.

Descri

pción

de ob

jetos

de da

tosEspecificación de proceso (EP)

Especificación de control (EC)

DiagramaEntidad-Relación (DER)

Diagrama de Flujo de datos

Diagrama de Transición de datos

Diccionario de Datos (DD)

Figura 5.1 La Estructura del modelo de análisis Se fundamenta en los siguientes componentes: • Descripción de objetos de datos • Especificaciones de Proceso (EP) o Miniespecificaciones. • Especificación de control (EC) • Diagramas de Flujo de Datos. • Diccionario de datos. • Diagrama de Transición de Datos • Diagrama Entidad-Realción

Análisis 78

Aquí voy MIRAR ESTE DOCUMENTO(ISE3.DOC) Ya se paso la parte de presuman hasta la pagina 186 Despliegue de la funcion de calñidad pagina 200 de pressman Como se expresó anteriormente, el análisis estructurado es una herramienta para resolver el problema que plantea la fase de análisis de un proyecto, el cual es la construcción de las especificaciones funcionales, en cuanto a procesos realizados y datos que soportan dichos procesos. Para ello, se deben crear aquí, dos modelos que traten al detalle tanto los procesos como los datos. Dichos modelos deben presentar primero una situación actual del área a sistematizar, para luego generar la estructura, a través de estos modelos, de lo que será el nuevo sistema de información. Dicho de otro modo, se deben generar dos modelos (de procesos y datos), para mirar las especificaciones funcionales del sistema actual. Una vez terminada esta tarea, se generan otros dos modelos para determinar el sistema propuesto. Veamos a continuación, los modelos en detalle.

5.2 MODELO DE PROCESOS. Busca definir, a través de las técnicas anteriores, todos los procesos existentes en el sistema en estudio, sus funciones, datos de entrada, información de salida, relaciones entre procesos y cálculos realizados, con el fin de tener una base apropiada para diseñar la estructura futura del sistema.

Análisis 79

5.2.1 PROPÓSITO. • Los procesos son parte importante de cualquier sistema de información.

Comprenden la serie de transformaciones y cálculos que sufre la información a través del mismo.

• Un modelo de procesos completo debe ser lo suficientemente detallado para que sea útil en el diseño y debe incluir : • Diagrama de Flujo de Datos. • Diccionario de Datos de los diagramas anteriores. • Especificaciones de cada proceso narrado en los diferentes diagramas. • Lista de eventos a los que el sistema debe responder. • Definición clara de entradas, salidas, relaciones y procesos.

Una de las técnicas usadas para determinar un buen modelo de información es el análisis estructurado, con sus componentes de diagramas de flujo de datos, diccionario de datos y especificaciones de proceso, que se detallarán a continuación.

5.2.2 DIAGRAMAS DE FLUJOS DE DATOS. (DFD). Es la representación de un sistema de información en forma de red. Permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por “conductos” y “tanques de almacenamiento” de datos. Elementos :

5.2.2.1 FLUJOS DE DATOS. Son unos conductos a través de los cuales fluyen paquetes de información de composición conocida. Representación :

Ejemplos : Asientos Contables, Recibo de Caja, Liquidación de Matricula.

5.2.2.2 PROCESOS O TRANSFORMACIONES.

Análisis 80

Son los lugares lógicos donde la información sufre cambios o transformaciones, como consecuencia de cálculos u operaciones matemáticas y/o lógicas. Representación :

Existen algunas reglas con relación a los procesos : Ley de Transformación : Un proceso debe modificar los datos de alguna forma (la salida debe ser diferente a la entrada). Ley de Conservación : La salida de un proceso, debe ser derivable de su entrada. Sólo se le debe dar la información suficiente al proceso, para que haga su trabajo. Ejemplos : Validar Datos Cliente, Generar Reportes de Ventas, Calcular Devengados,

5.2.2.3 ALMACENAMIENTOS. Son los lugares donde se acumula la información dentro del sistema, con el fín de ser utilizada por procesos posteriores. Representación :

Ejemplos : Clientes, Cuentas, Estudiantes. Los almacenamiento son pasivos y los datos no viajarán a lo largo del flujo, a menos que el proceso los solicite explícitamente.

5.2.2.4 TERMINALES, ENTIDADES O AGENTES EXTERNOS. Son las personas (cargo), organizaciones, áreas, otros sistemas que residen FUERA del contexto del sistema en estudio y que originan o reciben la información del sistema. Se distinguen dos tipos :

Análisis 81

FUENTE : Persona (cargo), organización, área o sistema de donde se origina la información de entrada. SUMIDERO O DESTINO : Persona (cargo), organización, área o sistema hacia donde va dirigida la información generada por el sistema. Representación :

Ejemplos : Contabilidad, Nómina, Gerencia.

5.2.2.5 COMO CONSTRUIR UN DIAGRAMA DE FLUJO DE DATOS. 1. Definir flujos de entrada y salida del sistema, además de fuentes y sumideros,

de donde y hacia donde se dirige la información 2. Identificar los procesos. 3. Identificar los almacenamientos necesarios. 4. Identificar los flujos de información internos (relaciones entre procesos). 5. Definir el nombre de flujos, procesos y almacenamientos. 6. Numerar los procesos. 7. Revisar el diagrama resultante. Que sea claro, completo, consistente. Se revisa

hasta obtener una version muy perfeccionada de la realidad. 8. Expandir en otros diagramas, los procesos que requieran mayor detalle en su

definicion. El modelado de un diagrama de flujo de datos se puede describir de una variedad de maneras : • Qué funciones debe desempeñar el sistema ? • Cuáles son las interacciones entre dichas funciones ? • Qué transformaciones debe llevar a cabo el sistema ? • Qué entradas se transforman en qué salidas ? • Qué tipo de labor debe realizar el sistema ? • De dónde obtiene la información para llevar a cabo dicha labor ? • Dónde entrega los resultados de su labor ?

Análisis 82

5.2.2.6 NIVELACION. Es la división de un sistema en subsistemas y de éstos en otros, para lograr una mayor claridad en los procesos, almacenamientos y flujos de información Es el proceso de expandir el Diagrama de flujo de datos general (Nivel 1), en otros Diagramas que detallan cada vez más las funciones que se realizan en cada uno de los procesos.

Nivelación de un Diagrama de Flujo de Datos.

De la gráfica podemos apreciar que el proceso B, se dividió en las funciones B1, B2 y B3, lo cual trata de dar mayor claridad en el sistema. Desde otro punto de vista : B = B1 + B2 + B3.

Los niveles de un Diagrama de flujo de datos en un sistema, son :

5.2.2.6.1 Diagrama de Contexto (Nivel 0). Representa las entradas y salidas del sistema. Otorga una vision global del medio ambiente. Está conformado por un solo proceso. Muestra la forma en que interactúa el sistema con el medio ambiente, a través de los diferentes agentes externos (entidades) que allí se describen.

5.2.2.6.2 Diagrama de Flujo de Datos General (Nivel 1). Es la expansion del único proceso del diagrama de contexto. Contiene los procesos o funciones que a nivel general se realizan dentro del sistema. Desde otro punto de vista, son los elementos que componen el sistema en estudio. Se considera, que no deben ser más de nueve elementos generales.

Análisis 83

5.2.2.6.3 Diagrama de Flujo de Datos de Nivel 2. Son los diagramas resultantes de detallar o expandir los procesos del diagrama de flujo de datos general, en otros diagramas, con el fin de otorgar mayor claridad a cada elemento o función principal del sistema. Se detallan las tareas que componen la función básica descrita en el nivel 1.

5.2.2.6.4 Diagrama de Flujo de Datos de Nivel 3 al Nivel N. Es la expansión sucesiva de procesos del nivel 2 al nivel N-1. La expansión se realiza hasta que el sistema quede lo suficientemente claro. Es decir, hasta encontrar la función primitiva o atómica, función que tiene como característica que no se puede dividir en otras. No necesariamente todos los procesos se expanden al mismo nivel.

5.2.2.7 BALANCEO. Asi como la nivelación trata con los procesos, existe también otra técnica que se interesa en los flujos de datos que aparecen en los diferentes diagramas. Dicha técnia es el balanceo, y dice lo siguiente : Los flujos de entrada y salida en un diagrama de un proceso de nivel N, deben ser equivalentes a los flujos de entrada y salida del proceso de nivel superior (N+1), a partir del cual se hizo la expansión. Se puede realizar una descomposición más explícita de las entradas y salidas, en el diagrama hijo, respetando la equivalencia. Ejemplo :

Análisis 84

De la gráfica podemos ver por ejemplo, que el flujo de datos F1 se ha descompuesto en los componentes F11, F12 y F13, para detallar más el nivel siguiente del diagrama de flujo de datos. Un caso real en un sistema de nómina, sería el hecho de trabajar con un flujo de datos denominado “Datos personales” en el diagrama de nivel 1. Para efectos de mayor claridad, podemos descomponer dicho flujo en subflujos como : Cédula, Número de hijos y Dirección, cada uno de los anteriores, afectando la función específica de nivel más bajo en el diagrama derivado del nivel 1.

5.2.2.8 CONVENCIONES NUMERICAS. Cada proceso recibe el número del proceso padre, un punto (.) y otro número único. El proceso del diagrama de contexto, se numera con cero.

5.2.2.9 OTROS ASPECTOS. • Un diagrama de flujo de datos se expande hasta que el nivel describa

completamente las funciones que se realizan en un proceso dado. • Los procesos que no tienen más expansión se conocen como Procesos o

Funciones Primitivas. • Es importante tener en cuenta el balanceo en los diagramas, dado que son

base para la definición posterior del modelo de información del sistema. • Cada nivel no debe contener más de nueve procesos. • Llamar cada proceso con un verbo que indique la accion que se realiza. • Numerar los procesos en el orden lógico de operación del sistema. • Los procesos deben tener información que entra (flujos de entrada) e

información que sale (flujos de salida). • Si no podemos escribir una especificación de proceso razonable para una

burbuja en una página, es probable que sea demasiado compleja y debiera partirse en diagramas de menor nivel antes de tratar de escribir la especificación.

• No se debe hacer en un diagrama :

Análisis 85

5.2.3 DICCIONARIO DE DATOS (DD). Es el conjunto organizado de los términos usados en los diagramas de flujo de datos. Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, almacenamientos y cálculos intermedios. Sirve de instrumento para buscar definiciones de términos que no se comprenden en los diagramas de flujo de datos. Se aplica para los siguientes elementos :

5.2.3.1 FUENTES Y SUMIDEROS. Los agentes externos, se definen en caso de que su nombre no sea claro. Ejemplo : Inspeccion : Lugar donde se realiza una revisión detallada de los documentos de un contrato. Se debe notar que el nombre del agente externo se presta para confusiones, lo cual se debe evitar definiendo en forma precisa el objetivo del agente externo, con respecto al sistema. En general, es conveniente describir todos los agentes externos, en el diccionario de datos. Formato :

Análisis 86

NOMBRE AGENTE : TIPO AGENTE : SIGNIFICADO : OBSERVACIONES :

5.2.3.2 PROCESOS. Son descritos a través de otra especificación funcional llamada Especificaciones de Proceso ó Miniespecificaciones. Formato : NOMBRE PROCESO : SIGNIFICADO : ESPECIFICACION : OBSERVACIONES :

5.2.3.3 ALMACENAMIENTOS. Se define la estructura de los atributos que va a contener el almacenamiento dado. Ejemplo : Empleados={Cod Empl + nombre + datos personales + cargo + depend + fec ingr }. Es conveniente anotar aquí una descripción del almacenamiento, a nivel de definición del mismo. Formato :

Análisis 87

NOMBRE ALMACENAMIENTO : SINONIMOS : COMPOSICION : OBSERVACIONES :

5.2.3.4 FLUJO DE DATOS. Se debe definir la composición de la información que fluye por un canal determinado. Ejemplo : Asientos Contables : fecha + nro doc + cta + nit + ident (deb/cred) + valor + descrip. También se debe dar una explicación de cada flujo de datos. Formato : NOMBRE FLUJO : SINONIMOS : COMPOSICION : OBSERVACIONES : Este formato sirve para la definición de componentes y elementos de datos también.

5.2.3.5 COMPONENTE DE DATOS. Se debe definir la descomposición de un flujo de datos, en los diferentes subflujos que lo conforman, cuando se debe dar mayor claridad a determinados procesos. Ejemplo : Información empleados = código + nombre + datos personales. A su vez, datos personales esta conformado así :

Análisis 88

Datos Personales = direccion + tel + estado civil + profesion + nro hijos.

5.2.3.6 ELEMENTO DE DATOS. Se define aquí, la composición de los flujos, a nivel da cada atributo componente, si así lo amerita el mismo. Si se tiene claridad en la definición del flujo, esto no se hace aquí. Es conveniente definirlos más tarde, en el diseño de la base de datos. Ejemplo : edad : Edada de la persona. Cédula : Número de la cédula de ciudadanía.

5.2.3.7 CONVENCIONES PARA EL DICCIONARIO. = Equivalente a. ___ Clave de almacenamiento. + Adición de elementos (AND). [ ] Ocurrencia de una sola opcion dentro del corchete. / Separa opciones dentro del corchete. { } Repetición. ( ) Opcional. ** Comentarios. SINONIMOS : Ocurren cuando dos flujos o dos almacenamientos reciben nombres diferentes, pero su estructura o composicion es la misma. Se deben evitar al máximo, pues originan problemas de integidad, redundancia e interpretación.

5.2.4 EVENTOS.

5.2.4.1 PROPOSITO. La técnica de eventos tiene como propósito describir cual es el comportamiento adecuado de un sistema, listando todos los eventos del área de estudio, ante los cuales está planeado que el sistema debe responder. Los eventos establecen la actividad del usuario, en relación con el negocio, en términos que ellos pueden comprender fácilmente. Describen el sistema desde la perspectiva del usuario. Los teclazos y clics de ratón que son codificados son, a fin de cuentas, una implementación directa de los eventos del negocio. Es decir, los programas responden directamente a los clics y al teclado, tan pronto como estos suceden.

Análisis 89

A diferencia de la interfase texto, donde había limitado número de eventos, esta herramienta es útil para las interfases gráficas, dado que ellas manejan ilimitado número de eventos. Esta técnica puede en un momento dado, reemplazar o aclarar la nivelación en los diagramas de flujo de datos.

5.2.4.2 DEFINICION. Se entiende por evento, a alguien [Sujeto] que hace algo [Verbo] a una cosa [Objeto]. Luego la sintaxis para establecer un evento es : SUJETO-VERBO-OBJETO. En una organización los eventos suceden por todos lados : Los clientes solicitan productos, los vendedores entregan mercancías, etc. Y cada vez que pasan cosas de éste tipo, se espera que la organización responda de alguna forma. Podríamos decir entonces, que un evento es algo que sucede a algún elemento de la organización y que además se espera que esta responda de una forma adecuada a dicho estímulo. Algunas reglas para reconocer eventos son : 1. Todo evento sucede en un momento específico. 2. Sucede en el ambiente y no dentro del sistema. 3. La ocurrencia del evento está bajo el control del ambiente y no del sistema. 4. El sistema debe ser capaz de detectar que el evento sucedió. 5. Se supone que el sistema hará algo con respecto a él. Los eventos deben cumplir con todas las cinco reglas anteriores, para ser catalogados como verdaderos eventos. Obviamente la lista apropiada de eventos, dependerá de la claridad que se tenga del alcance del sistema y de sus fronteras. Una modificación a éstos, hará variar notablemente la lista citada. Ejemplos : Supongamos el sistema de un contestador automático de teléfonos. Algunos candidatos a eventos para éste sistema podrían ser : 1. Quien llama hace una llamada al propietario. 2. La máquina reproduce saludos previamente grabados. 3. Quien llama se equivoca.

Análisis 90

4. Quen llama cuelga. 5. El propietario oye un mensaje. 6. El propietario solicita mensajes. 7. El propietario no está en casa. Aplicando las cinco reglas vistas, tenemos : El enunciado (1) es un evento, dado que cumple con las cinco reglas. El enunciado (2) no es evento, ya que la reproducción del saludo es generada por el sistema, luego no cumple con las reglas 2. y 3. Es una respuesta del sistema. La oración (3) no es un evento, pues no cumple con las reglas 4. y 5. La sentencia (4) es un evento. El enunciad (5) no es un evento, pues falla la regla 4. El enunciado (6) es un evento. La sentencia (7) no es un evento, ya que el sistema no puede detectar ese hecho, lo cual hace que no cumpla con la regla 1. Las tres actividades que se deben realizar para tener un modelo de eventos adecuado son : La lista de eventos, el diccionario de eventos y las matrices de eventos. Veamos :

5.2.4.3 LISTADO DE EVENTOS. Es una lista de los eventos ante los cuales está planeado que el sistema debe responder. Se relaciona un evento por cada línea, en la lista. Ejemplo : El cliente hace un pedido. El cliente cancela un pedido. El almacén envía el pedido del cliente. ...

5.2.4.4 DICCIONARIO DE EVENTOS. Se define una entrada al diccionario, por cada evento identificado. Se trata de definir en el diccionario, el hilo de un evento o transacción.

Análisis 91

Un hilo de evento

De la gráfica : Estímulo : Es el flujo de datos de entrada que activa el evento. Actividad : Es el procesamiento realizado por el sistema para producir la Respuesta adecuada, que obviamente debe generar un Efecto en el medio ambiente. El diccionario de eventos puede reemplazar el detalle de los niveles de diagramas de flujo de datos. Ejemplo : Una entrada típica de un evento al diccionario, sería :

Análisis 92

IDENTIFICACION 150 NOMBRE El almacén envía el pedido del cliente. DESCRIPCION Cuando el almacén envía los productos al cliente, se

identifica la compañía transportadora y se actualiza la cantidad enviada de cada concepto en el pedido del cliente. Si la cantidad enviada es igual a la cantidad solicitada, se cierra el pedido. Los pedidos no son facturados sino hasta que se cierran completamente.

ESTIMULO Identificación del pedido del cliente. Identificación de la compañía transportadora. Número de vehículo. Fecha de envío. Conceptos del pedido. Cantidad enviada.

ACTIVIDAD VALIDAR DATOS PEDIDO CREAR PEDIDO LEER CONCEPTOS PEDIDO MIENTRAS CONCEPTOS DE PEDIDO VALIDAR DATOS CONCEPTO CREAR CONCEPTO PEDIDO ACTUALIZAR ESTADO PEDIDO LEER CONCEPTOS PEDIDO FIN SI ESTADO PEDIDO ES CERRADO IMPRIMIR GUIA TRANSPORTADORA FIN

RESPUESTA Guía transportadora EFECTO El transportador debe salir del lugar con la guía. Si el pedido

esta cerrado, entonces se facturará al cliente. Los componentes del diccionario son : Identificador : Es un número, no significativo. Nombre : Es una oración clara que identifica el evento, bajo la sintaxis sujeto-verbo-objeto. Descripción : Se define cuáles son las políticas de la organización, para el evento. Estímulos : Se identifican los datos que se requieren para activar el evento. Son los flujos de datos de entrada de los diagramas de flujo de datos. Actividad : Sucede dentro del sistema. Es todo el procesamiento que el sistema debe hacer para convertir la entrada del estímulo en una respuesta adecuada para el evento. Es una miniespecificación de proceso.

Análisis 93

Se puede apreciar que la técnica de eventos cubre adecuadamente las actividades del modelo de procesos, al nivel de identificar requerimientos de información y componentes de proceso. Aunque el papel de los diagramas de flujo de datos ha disminuido, esta técnica sigue siendo útil para desarrollar sistemas grandes. El diagrama de flujo de datos no hace suposiciones acerca de cuál programa alojará cualquier política de la organización y por esa única razón es una técnica valiosa para capturar los requerimientos antes de diseñar una estrategia de implementación. La actividad es neutral en relación con el lenguaje de programación utilizado para el proyecto. Es un lugar efectivo para documentar las reglas del negocio. Respuesta : Identifica los datos requeridos por el usuario para lograr el efecto deseado en el ambiente de la organización. Efecto : Es la poscondición deseada del ambiente, después de que ha recibido la respuesta. Sucede en el ambiente.

5.2.4.5 MATRICES DE EVENTOS. Sirven para relacionar los eventos con otras partes del modelo de procesos. Algunas son :

5.2.4.5.1 MATRIZ EVENTO/UBICACIÓN DEL NEGOCIO. Sirve para determinar que eventos ocurren en qué ubicaciones o sucursales de la organización. Muestra que eventos deben ser reconocidos en cada ubicación. EVENTO/UBICACIÓN MEDELLIN CALI RIONEGRO ... El cliente hace pedido X X X

El departamento de crédito aprueba pedido X ... Por ejemplo, en la sede de Medellín, es posible que sucedan los eventos de colocar pedidos por parte de los clientes y además éstos se pueden aprobar allí.

5.2.4.5.2 CRUD EVENTO/ENTIDAD. Muestra cuales eventos crean (C), leen (R), actualizan (U) o borran (D) instancias de las entidades en el modelo de información.

Análisis 94

EVENTO/ENTIDAD CLIENTE PEDIDO CPTO PEDI ... El cliente hace pedido CRU CR CR

El departamento de crédito aprueba pedido U ... Podemos ver que el evento : El cliente pace pedido, modifica en general, las tablas Cliente, Pedido y Concepto de Pedido, creando ocurrencias y actualizándolas.

5.2.4.5.3 CRUD UBICACIÓN/ENTIDAD. Muestra los requerimientos de distribución de datos de la organización y dice como debe ser el acceso a los datos (local, remoto o una combinación de ambas). UBICACIÓN/ENTIDAD CLIENTE PEDIDO CPTO PEDI ... Medellín CRU CRU CR

Cali CRU CR CR

Rionegro CRU CR CR ... Necesitaríamos, por ejemplo, ubicar las tablas de Cliente, Pedido y Concepto de Pedido en Medellín, Cali y Rionegro.

5.2.4.6 DESCUBRIMIENTO DE EVENTOS. Es fácil descubrir eventos, si tenemos la panorámica de nuestro sistema, como una acción estímulo/respuesta y no como un problema de procesamiento interno. Algunas técnicas usadas para descubrir eventos, son : • Entrevistas con usuarios. • Documentación existente del área. • El diagrama de contexto. • El modelo de información.

5.2.4.7 TIPOS DE EVENTOS. Los eventos se pueden clasificar en inesperados y esperados.

5.2.4.7.1 EVENTOS INESPERADOS. El sistema nunca sabrá cuando sucederá el evento. Ni siquiera se sabe si sucederá o no. Ejemplo : El cliente coloca pedido. La gerencia solicita un reporte de ventas. Ventas anuncia incremento de precios.

Análisis 95

Si nunca suceden, el sistema simplemente no hará nada. Cuando suceden, el sistema debe responder de alguna forma.

5.2.4.7.2 EVENTOS ESPERADOS. Son eventos que el sistema espera que sucedan en un lapso dado. La diferencia con los inesperados, es que el sistema los puede identificar. Son :

5.2.4.7.2.1 TEMPORALES. Son eventos activados por el paso del tiempo. Su sintaxis apropiada es : “Tiempo para [hacer algo]” no la normal, sujeto-verbo-objeto. Ejemplos : Tiempo para crear estados de cuenta mensuales. Tiempo para notificar salida de vehículos de la bodega. Tiempo para enviar aviso de cambio de aceite a los clientes. El sistema debe hacer algo previo para determinar si el evento ha sucedido. Regularmente, se debe confrontar contra relojes o calendarios y luego, manejar el evento.

5.2.4.7.2.2 SEUDOEVENTOS. Suceden cuando falla la ocurrencia de un evento esperado. Es la no ocurrencia de un evento esperado. El sistema no puede crear eventos. Un evento como : “El departamento de facturación envía factura al cliente”, sirve para deducir el siguiente evento esperado de la cadena : “El cliente paga el pedido”. El sistema espera un tiempo a que suceda este evento, pero no puede garantizar que el cliente pague la factura. Este tipo de hechos son los que producen los seudoeventos. Un seudoevento siempre debe tener un evento esperado asociado.

5.2.4.7.3 REVISION DE TIPOS DE EVENTOS. La mayoría de los eventos son inesperados. La clasificación vista anteriormente puede conducir a una serie de preguntas como : El evento es inesperado o esperado ? Si es esperado, Es un evento temporal esperado relativo a otro evento o a un tiempo

absoluto ? Le preocupa al sistema si no sucede (seudoevento) ? Cuál es el evento predecesor que establece la expectativa ?

Para los eventos inesperados o esperados,

Análisis 96

El ambiente es (reconocimiento directo) o el sistema (reconocimiento indirecto) el responsable del reconocimiento del evento ? Cuáles son eventos predecesores en la cadena ? Cuáles son eventos sucesores en la cadena ? Estas preguntas ayudarán a crear un modelo más completo del comportamiento deseado del sistema.

5.2.4.8 ORGANIZACIÓN DE LA LISTA DE EVENTOS. Existen varias formas de ordenar eventos :

5.2.4.8.1 EN EL TIEMPO. Los eventos se ordenan en forma cronológica, en la forma en que generalmente suceden. Esta organización hace fácil la validación de ellos por parte del usuario. Se puede identificar fácilmente los eventos predecesores y sucesores, inesperados y esperados y buscar seudoeventos que puedan faltar en la lista. Ejemplo : El cliente coloca pedido. El departamento de crédito confirma el límite de crédito del cliente. El cliente paga el anticipo sobre el pedido. El gerente de ventas aprueba el pedido. El departamento de producción programa el pedido. La planta produce el pedido. La planta envía el pedido. Es tiempo de enviar estados de cuenta mensuales. El cliente paga el saldo.

5.2.4.8.2 POR SUJETO. Se agrupan los eventos, por el sujeto que inicia el evento. Ejemplo : Eventos del Cliente : El cliente coloca pedido. El cliente paga anticipo sobre el pedido. El cliente cancela el pedido. El cliente recoge un pedido. El cliente falla en recoger un pedido ... Eventos de la Planta : La planta calendariza el pedido.

Análisis 97

La planta produce el pedido. La planta envía el pedido. ... Este ordenamiento muestra el papel completo representado por el sujeto (agente externo) en el contexto del sistema. Puede ser útil para descubrir elementos de datos acerca del sujeto.

5.2.4.8.3 POR OBJETO. El objeto del evento representa una entidad del mundo real, tal como pedido, factura, producto, etc. Con éste ordenamiento se pretende identificar todos los eventos de los objetos principales del sistema. Es conveniente tener algo del modelo de información para poder referirse más claramente a los diferentes objetos que componen el sistema.

5.2.4.9 NIVELACION DE EVENTOS. Al igual que los diagramas de flujo de datos, es conveniente entrar a nivelar también los diferentes eventos hallados en el estudio del sistema para tener un mayor grado de detalle de cada uno de ellos. Los niveles identificados son :

5.2.4.9.1 NIVEL CONCEPTUAL. Es adecuado para la fase de planeación del proyecto. Se pretende que los eventos a este nivel definan las áreas funcionales del sistema. Ejemplo : El cliente coloca pedido. Area : Captura de Pedidos.

5.2.4.9.2 NIVEL DE NEGOCIOS. Es el nivel adecuado para la fase de análisis del sistema, ya que corresponde a las diferentes tareas que los usuarios hacen para atender un pedido colocado por el cliente, por ejemplo. Todas estas tareas toman la forma de cadenas de eventos. Ejemplo : El cliente coloca pedido, se puede dividir en : Cliente coloca pedido preliminar. Gerente de ventas confirma pedido.

Análisis 98

Despachos programa el envío. Esta lista pone en evidencia los subtipos de eventos que el sistema deberá reconocer, y ayuda a descubrir los datos requeridos, además de las políticas asociadas a cada evento. Qué tanto se deberán aplicar niveles al modelo de eventos, puede ser tema de discusión. Sin embargo, la experiencia guía al analista hacia una solución práctica. Cuando la sección de actividad del diccionario de eventos comienza a exceder de una a tres páginas de especificaciones, o cuando existen numerosas estructuras CASE, probablemente se necesita descomponer más el evento, ya sea mediante subtipos o buscando una división lógica en la cadena.

5.2.4.9.3 NIVEL DE DIALOGO. Toma cada evento y lo divide en un diálogo entre el sistema y el usuario. Es útil para la realización de prototipos del sistema, además de ser un buen inicio para la fase de diseño de la interfase hombre-máquina.

5.2.4.9.4 NIVEL DE DISEÑO. El evento es descompuesto todavía más hacia la acción específica que debe realizar el usuario para informar completamente al sistema que el evento ha ocurrido. Incorpora la navegación por el sistema, botones y menúes de las ventanas. En resumen, el modelo de eventos es el pegamento que mantiene juntas las piezas del análisis, diseño, construcción y prueba. Es la razón por la cual se contrata la elaboración de determinado sistema. La clave de un buen diseño gráfico, es la comprensión de la manera en que el sistema debe comportarse cuando responde a los eventos del negocio, e incorporarle la suficiente flexibilidad para manejar varios eventos y secuencias no tradicionales. Esto no quiere decir que se permita que cualquier cosa ocurra. Se debe diseñar y decidir lo que el usuario no pueda hacer en un momento dado. Un modelo de eventos sólido, también ayuda a organizar esta tarea.

Análisis 99

Niveles de Eventos.

5.3 MODELO DE INFORMACION. Es la representación de las relaciones existentes entre los almacenamientos. Tiene como propósito establecer los caminos de acceso que permitan integrar toda la información almacenada de un sistema. Es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema y sus relaciones.

5.3.1 PROPOSITO. • Los datos son la parte medular de cualquier sistema de información.

Comprenden el mapa de la memoria empresarial de cualquier organización. • Un modelo de información completo que sea lo suficientemente detallado para

que sea útil en el diseño, debe incluir : Diagrama de Estructura de Datos (Entidad Relación). Estimaciones de volumen y retención por entidad. Atributos por entidad. Definición clara de cada entidad, relación y atributo.

Análisis 100

Propiedades de los atributos (opcionalidad, tipo de dato, rango, unidad de medida, precisión y valores restringidos).

Diagrama de Estado-Transición. Matrices de Entidad.

5.3.2 ENTIDADES. Es una cosa que tiene una existencia individual definida en la realidad o en la mente. En términos de ingeniería de software : Es un sustantivo. Además puede representar una idea del mundo real como Cliente, Pedido, etc. o puede representar una abstracción tal como : Concepto de Pedido, Acuerdo de Descuento, etc. Cada instancia individual de cada entidad es única. Sin embargo, todas tienen características y comportamientos similares que hacen que frecuentemente sea ventajoso agruparlas. En general : “Es una persona, lugar, cosa o idea abstracta sobre la que el sistema necesita recordar algo. Las instancias de cada entidad tienen características similares y se comportan de forma parecida”. Representación :

Ejemplo :

Análisis 101

5.3.3 RELACIONES. Las instancias de las entidades se asocian constantemente con instancias de otras entidades. Los clientes colocan pedidos, los pedidos pueden tener varios conceptos de pedido, cada uno asociado con un producto, el cual puede estar asociado con un saldo de inventario y así sucesivamente. A estas asociaciones se les llama Relaciones. Ejemplo :

Los nombres de las relaciones son extremadamente importantes, debido a que son capaces de expresar mucho de las políticas y el significado del negocio cuando son nombradas adecuadamente. Se deben evitar nombres de relaciones como : Puede tener, Esta relacionado a, Esta asociado con, Tiene, Es de.

5.3.4 CARDINALIDAD. Representa QUE TANTOS DE UNA COSA SE RELACIONAN CON QUE TANTOS DE OTRA. Se expresa con un valor para un mínimo y un máximo. El mínimo describe si la relación es opcional o requerida. El máximo describe si la relación es singular o plural. Del ejemplo anterior, Persona-Perro, se puede preguntar : 1. Debe una persona poseer un perro ? 2. Se puede poseer más de un perro ? 3. Debe un perro ser siempre propiedad de una persona ? 4. Puede un perro ser propiedad de más de una persona a la vez ? La pregunta 1 está diseñada para obtener la cardinalidad mínima, cuando se lee de izquierda a derecha la relación (persona-perro).

Análisis 102

Está una persona forzada a ser propietaria de un perro ?. De ser así, qué pasa si el perro se muere o se escapa ?. Debemos acosar al dueño hasta que obtenga un nuevo perro ?. Debemos darle un reemplazo ?. La pregunta 2 está diseñada para determinar si la misma instancia de la entidad A (persona), puede participar en relaciones con varias instancias de la entidad B (perro), al mismo tiempo. Las preguntas 3 y 4 miden la cardinalidad en dirección opuesta (perro-persona). La pregunta 3 comienza con la entidad perro y se lee hacia atrás, hacia persona, preguntando si la relación entre un perro y su dueño es opcional o requerida. La pregunta 4 se refiere a si permitimos una custodia múltiple de perros o si el propietario sólo puede ser una persona. La relación quedaría :

En resumen, la cardinalidad de una relación, está expresada por la cantidad de ocurrencias mínima y máxima permitida entre una instancia de la entidad A y las instancias de la entidad B y viceversa. Cardinalidades :

5.3.5 ATRIBUTOS. El tercer componente principal del modelo son los atributos, que representan a todos los elementos de datos del sistema. Cada hecho acerca de una entidad, constituye un atributo separado.

Análisis 103

Ejemplo : Dado el evento “EL CLIENTE DEJA PRENDAS EN LA LAVANDERIA”, los elementos de datos identificados allí, pueden ser : Nombre del cliente Apellido Número telefónico Fecha de recepción Número de recibo Fecha de entrega Hora de entrega Mas un grupo repetido de : Tipo de prenda Cantidad de prendas Servicio requerido Precio del servicio Instrucciones especiales Mediante la NORMALIZACION se puede atribuir a las entidades los elementos de datos identificados. La normalización consta de tres reglas denominadas formas normales. Aplicando éstas al ejemplo, tenemos : PRIMERA FORMA NORMAL (1FN). “NO HAY GRUPOS DE ATRIBUTOS REPETIDOS”. Se mueven atributos repetidos a un grupo aparte, HEREDANDO la clave de la entidad de origen de los grupos repetidos. La 1FN resuelve el antigüo problema de los grupos repetidos en conjuntos de datos. Nuestro ejemplo en 1FN sería : PEDIDO CONCEPTO PEDIDO Número Recibo Número Recibo Nombre Tipo prenda Apellido Tipo servicio Número telefónico Cantidad Fecha de recepción Precio unitario Fecha de entrega Instrucciones especiales Hora de entrega

Análisis 104

Primera Forma Normal.

SEGUNDA FORMA NORMAL (2FN). “TODOS LOS ATRIBUTOS QUE NO SON CLAVE, SON DEPENDIENTES COMPLETAMENTE EN FORMA FUNCIONAL, DE LA TOTALIDAD DE LA CLAVE PRIMARIA”. La 2FN trata el problema de los registros que tienen claves primarias compuestas por varios elementos de datos. Cada atributo debe ser funcionalmente DEPENDIENTE DE LA CLAVE COMPLETA Y NO SOLO DE PARTE DE ELLA. Por ejemplo, el Precio unitario no depende totalmente de la clave completa. Se puede determinar usando el tipo de prenda y el tipo de servicio. La 2FN elimina elementos de datos que no son completamente dependientes de una clave concatenada y los coloca en su propia tabla, con su clave única. Nuestro ejemplo en segunda forma normal, sería : PEDIDO CONCEPTO PEDIDO TIPO SERVICIO Recibo Recibo Tipo servicio Nombre Tipo prenda Tipo prenda Número telefónico Tipo servicio Precio unitario Fecha de recepción Cantidad (El precio actual) Fecha de entrega Instrucciones especiales Hora de entrega (Precio unitario) De la 2FN de nuestro ejemplo, podemos observar que existen dos atributos Precio unitario. Lo anterior para significar solamente que si fuera necesario conservar el precio unitario del negocio, hay que guardarlo en la entidad Concepto Pedido, ya que es ésta la que contiene el detalle de cada negociación realizada. La entidad Tipo Servicio, tendría siempre el Precio unitario actual, es decir, el valor que se cobra por cada servicio de una prenda dada. Si sólo interesa el precio actual, se tendría dicho atributo en la entidad Tipo Servicio únicamente, con la observación de que cuando exista un cambio en el precio, todos los negocios se liquidarían al nuevo precio.

Análisis 105

Quien aclara la situación anterior, es sólo el usuario, a la luz de las reglas y políticas establecidas en la organización. No se debe suponer nada.

Segunda Forma Normal.

TERCERA FORMA NORMAL (3FN). “CADA ATRIBUTO ES FUNDAMENTALMENTE DEPENDIENTE DE LA CLAVE, LA CLAVE COMPLETA Y DE NADA más QUE LA CLAVE”. (Se eliminan dependencias transitivas). De nuestro ejemplo, el nombre, apellido y número telefónico del cliente, no son atributos de Pedido, ya que no dependen de la clave (recibo). Son más bien atributos de la entidad Clientes. Técnicamente se desperdicia espacio cuando esta información se repite por cada pedido colocado. La 3FN se puede conseguir rápidamente si simplemente se usa una fuerte dosis de sentido común y se pregunta, por ejemplo : Es nombre de cliente un atributo de pedido ?. No. Es un atributo de cliente. Y así para cada atributo, lo que se trata es de hallar quién lo describe completa y funcionalmente. En otras palabras, que atributo o conjunto de atributos es su verdadera “MADRE”. Nuestro ejemplo en 3FN sería : CLIENTE PEDIDO CONCEPTO PEDIDO Codigo cliente Recibo Recibo Nombre Codigo cliente Tipo prenda Apellido Fecha recepción Tipo servicio Número telefónico Fecha entrega Cantidad Hora prometida Instrucciones (Precio unitario)

Análisis 106

TIPO SERVICIO

Tipo servicio Tipo prenda Precio unitario

Tercera Forma Normal.

En general, la normalización es un técnica de corrección de errores para los modelos de información y no una técnica de construcción.

5.3.6 TIPOS DE ENTIDADES.

5.3.6.1 ENTIDAD ATRIBUTIVA. Es una entidad que cobra vida como un atributo o conjunto de atributos de otra entidad. No puede existir por sí sola. Su clave será una concatenación de la clave de la entidad madre y al menos otro atributo de la entidad. Notación :

Ejemplo :

Análisis 107

Si quisiéramos guardar la información referente a los diferentes precios que ha tenido un producto en específico, deberíamos contemplar la posibilidad de manejarlos a través de una entidad de tipo atributivo, ya que se está haciendo más claridad acerca de la entidad producto. Además, debido a aspectos de normalización, es conveniente manejar dichos precios, como entidad aparte, dado que éstos, son atributos repetidos y no se estaría cumpliendo con la 1FN.

5.3.6.2 ENTIDAD ASOCIATIVA. Es una entidad que surge de una asociación o relación entre dos o más entidades. Sirve para resolver el problema de las relaciones muchos a muchos (redundancia de datos), creando una nueva entidad para la relación. Notación :

Ejemplo : Dada la siguiente relación :

La entidad asociativa resultante se puede utilizar para : • Resolver la relación muchos a muchos. • Guardar atributos adicionales que son característicos de la relación y no de las

entidades participantes. • Para permitir que una relación, al convertirse en entidad, participe en otras

relaciones. La solución a nuestro ejemplo, sería :

Existe un patrón importante :

Análisis 108

A nivel de atributos : VEHICULO CRUCE VIAS Placa Placa Código Vía Modelo Código Vía Orientación Propietario Fecha y Hora Cruce Número Carriles Veloc. Promedio Motivo Cruce Tipo Superficie Cilindraje Dirección Cruce Fecha Compra Tráfico Si deseáramos ampliar Motivo de Cruce a entidad, tendríamos :

5.3.7 DEFINICION DE ATRIBUTOS. Cada atributo requiere para su definición los siguientes ítems : Nombre : Debe ser conciso y comprensible. Definición : Es el significado y propósito del atributo. Se debe verificar por los usuarios. Sirve para implementar la ayuda en línea.

Análisis 109

Opcionalidad o no : Se debe indicar si el atributo es requerido u opcional. Tipo de Dato : Longitud y valores válidos. Debe ser consistente a lo largo del modelo y lo más apropiado posible a la realidad del atributo. Rango : Si el atributo es numérico, se debe especificar los límites inferior y superior válidos. Unidad de Medida : Se debe especificar la unidad de medida de los atributos que la contengan. Valores Restringidos : Son los valores que no debe contener el atributo.

5.3.8 MATRICES DE ENTIDAD. Buscan “relacionar” las entidades con otros objetos del sistema, para determinar el grado de consistencia o cohesión del mismo. Algunas son :

5.3.8.1 CRUD EVENTO/ENTIDAD. Busca identificar que eventos modifican las entidades en cuanto a Creación (C), Lectura (R), Modificación (U) y Borrado (D) de filas o registros. Ejemplo : EVENTO/ENTIDAD CLIENTE PEDIDO CPTO PEDIDO .... Cliente hace pedido CRU CR CR Dpto crédito aprueba pedido U RU R ... De la matriz anterior, se puede ver que dado el evento “Cliente hace un pedido”, se puede crear (C) y leer (R) una fila (registro) en la entidad Cliente, se puede crear y leer una fila en la entidad Pedido y otra como mínimo, en la entidad Concepto de Pedido.

5.3.8.2 MATRIZ EVENTO/UBICACIÓN DEL NEGOCIO. Muestra de la totalidad de eventos identificados, cuáles pueden ocurrir en las diferentes sedes de la organización, si esta posee varias sucursales. Ejemplo :

Análisis 110

EVENTO/UBICACIÓN MEDELLIN RIONEGRO CALI .... Cliente hace pedido X X X Dpto crédito aprueba pedido X ... Podemos observar que sólo es viable que ocurra el evento “El departamento de crédito aprueba pedidos”, en la oficina de Medellín. En las demás sucursales, no es viable que ocurra dicho evento. Esta matriz sirve para confirmar, a nivel de ocurrencias de eventos, cuáles pueden darse en ubicaciones diferentes a las oficinas centrales y cuáles sólo son de manejo exclusivo de las mismas.

5.3.8.3 CRUD UBICACIÓN/ENTIDAD. Es una combinación de las dos anteriores. Dice a nivel de ubicaciones, a que entidades se les puede crear, modificar o retirar filas. Ejemplo : UBICACIÓN/ENTIDAD CLIENTE PEDIDO CPTO PEDIDO .... Medellín CRU CR CR Rionegro CRU U U Cali CRU CR CR .... La oficina de Rionegro, por ejemplo, sólo puede actualizar las entidades Pedido y Concepto de Pedido.

5.3.8.4 MATRIZ AUTORIZACION USUARIO/ENTIDAD. Sirve para controlar los diferentes niveles de acceso o permisos que se le puede otorgar a los usuarios con respecto a las diferentes entidades del modelo. Ejemplo : AUTORIZ. USUARIO/ENTIDAD CLIENTE PEDIDO CPTO PEDIDO .... Representante de Ventas CRU CR CR Gerente de Crédito CRU U U Jefe de Bodega U ... El Gerente de Crédito, sólo tiene permiso para crear, leer y actualizar la entidad de Clientes. Solo puede actualizar el encabezado de Pedidos.

Análisis 111

5.3.9 ALGUNOS EJEMPLOS DE MODELOS DE INFORMACION : Sistema Hospitalario :

Sistema de Inventarios :

Análisis 112

5.4 ESPECIFICACIONES DE PROCESO (MINIESPECIFICACIONES). Es la descripción detallada y ordenada de los procesos o transformaciones, definidos en un sistema de información. Su propósito es bastante claro : • Define lo que debe hacerse para transformar las entradas en salidas.

5.4.1 ASPECTOS A TENER EN CUENTA. • Se deben definir miniespecificaciones para cada proceso y función primitiva,

descritas en los diagramas de flujo de datos. • Se describe el cálculo y la transformación que se hace sobre la información • No se debe describir : La estructura o composición de los datos (Se hace en el Diccionario de Datos). El recorrido que sigue la información en el sistema (se refleja en los diagramas de

flujo de datos). Relaciones entre estructuras de datos (se describen en el modelo de información).

5.4.2 FORMAS DE DESCRIBIR MINIESPECIFICACIONES. Existen diferentes herramientas para construir una especificación. Aunque todas son válidas, unas son más convenientes que otras, dependiendo del medio en el cual se usen. Por ejemplo, los arboles de decisión son apropiados cuando se trata de resolver especificaciones que involucren decisiones en forma binaria. En general, se usará la técnica de español estructurado que por ser genérica, es la que más se acomoda al trabajo de definición de procesos desde el punto de vista algorítmico. Algunas técnicas son : • Español Estructurado. • Tablas de Decisión. • Arboles de Decisión.

5.4.2.1 ESPAÑOL ESTRUCTURADO. Consiste en definir un proceso en forma ordenada, describiendo los diferentes cálculos y comparaciones que se realizan allí y que transforman los datos de entrada al proceso, en información de salida útil para procesos siguientes o toma de decisiones.

Análisis 113

Se realiza a través de la utilización estructurada del lenguaje.

5.4.2.2 CONVENCIONES. • Se debe limitar el vocabulario a palabras o definiciones del diccionario de

datos, verbos en infinitivo (Terminados en AR,ER,IR), cualificadores numéricos (>,<,=,<=,>=,etc.) y palabras estructuradas (Mientras, Hasta, Si, Entonces, Sino, Caso).

• Evitar la puntución y oraciones compuestas que contengan explicaciones, aclaraciones, repeticiones, etc.

• Utilizar marginación para resaltar la jerarquía interna de la miniespecificación. • Los verbos deben escogerse de entre un pequeño grupo y deben ser

orientados a la acción. Una lista aproximada sería :

LEER IMPRIMIR ESCRIBIR ORDENAR BUSCAR REEMPLAZAR SUMAR LLAMAR RESTAR MOVER MULTIPLICAR VALIDAR DIVIDIR ENCONTRAR CALCULAR BORRAR

Ejemplo : MANEJAR NEGOCIOS LEER NOVEDAD NEGOCIO MIENTRAS EXISTA NOVEDAD NEGOCIO

CASO TIPO ES INGRESO LLAMAR INGRESO NEGOCIOS CASO TIPO ES CAMBIO LLAMAR CAMBIO NEGOCIOS CASO TIPO ES RETIRO LLAMAR RETIRO NEGOCIOS OTRO CASO ENVIAR “ERROR TIPO DE NOVEDAD NO VALIDO” FINCASOS LEER NOVEDAD NEGOCIO FIN MIENTRAS FIN MANEJAR NEGOCIOS

Análisis 114

INGRESAR NEGOCIOS VALIDAR DATOS NEGOCIO SI NO EXISTEN ERRORES ENTONCES

LEER NEGOCIO SI NEGOCIO NO EXISTE ENTONCES GRABAR NEGOCIO SINO ENVIAR “NEGOCIO EXISTE. VERIFIQUE.” FIN SINO ENVIAR “EXISTEN DATOS ERRONEOS.” FIN FIN INGRESO NEGOCIOS CAMBIAR NEGOCIOS VALIDAR DATOS NEGOCIO SI NO EXISTEN ERRORES ENTONCES

LEER NEGOCIO SI NEGOCIO EXISTE ENTONCES MODIFICAR NEGOCIO SINO ENVIAR “NEGOCIO NO EXISTE. VERIFIQUE.” FIN SINO ENVIAR “EXISTEN DATOS ERRONEOS.” FIN FIN CAMBIO NEGOCIOS RETIRAR NEGOCIOS VALIDAR DATOS NEGOCIO SI NO EXISTEN ERRORES ENTONCES

LEER NEGOCIO SI NEGOCIO NO EXISTE ENTONCES RETIRAR NEGOCIO SINO ENVIAR “NEGOCIO NO EXISTE. VERIFIQUE.” FIN SINO ENVIAR “EXISTEN DATOS ERRONEOS.” FIN FIN RETIRO NEGOCIOS

Análisis 115

Como se puede apreciar, el ejemplo anterior describe las diferentes especificaciones involucradas en la descripción de un proceso denominado MANEJAR NEGOCIO, cuyo objetivo es mantener en todo momento actualizadas las diferentes transacciones que se originan allí, por concepto de negocios nuevos (Ingresar Negocios), Modificaciones a negocios existentes ( Cambiar Negocios) y retiro de negocios ya vencidos (Retirar Negocios). Es conveniente anotar que se esta describiendo en forma general lo que sucede en el proceso. El detalle se realizará en la etapa de diseño del sistema. Se puede deducir también, que mínimo existen dos niveles de diagramas de flujo de datos para las especificaciones anteriores. Un nivel general, dónde se narran las tres funciones básicas del proceso Manejar Negocios y un nivel de segundo grado, donde se describen las funciones de ingreso, modificación y retiro de negocios.

5.5 RESUMEN. ENTRADAS PROCESO PARTICIPACION SALIDAS Estudio de Factibilidad.

1. Analisis Sistema Actual.

1.1 DFD Sistema Actual.

Usuarios. Analistas.

Especificaciones Funcionales.

Sistema Actual. 1.2 DD Sistema Actual. 1.3 DSD si existe.

Cronograma Diseño.

Requerimientos detallados.

1.4 Objetivos del área. 2. Requerimientos del nuevo sistema.

Usuarios. Analistas.

3. Especificaciones del nuevo sistema.

Analistas.

3.1 Modelo de Procesos. 3.2 Modelo de

Información. 4. Revisión del Análisis.

Analistas. Usuarios.

5. Cronograma Diseño. Usuarios. Analistas.

Diseño.

116

6. DISEÑO.


6.1.1 OBJETIVOS. • Descubrir y construir una estructura lógica que de solución al sistema planteado

en el análisis. • Servir de enlace y comunicación entre las especificaciones detalladas del

sistema y el ambiente y posibilidades especificas de programación e implementación.

• Garantizar la adecuada calidad del sistema, a través del cumplimiento y optimización de sus características más importantes.

• Desarrollar la forma como los módulos o ventanas de la estructura del sistema realizarán su trabajo, con miras a facilitar la fase de construcción del sistema.

• Definir con todo el detalle, el diseño de la base de datos generada en el modelo de información.

• Definir concretamente el diseño de entradas y salidas del sistema (documentos, pantallas (ventanas), reportes, interfases).

• Definir cómo será la interacción usuario-sistema. • Garantizar que todos los requerimientos plasmados en el análisis, sean

considerados e incluidos en la estructura generada.

6.1.2 DEFINICION. Es la transformación de las especificaciones funcionales de un sistema, en un modelo que defina "COMO" se va a lograr su implementacion física. Gráficamente :

Aplicando el enfoque de sistemas, tenemos :

Diseño.

117

1. Definir la estructura inicial. 2. Diseñar los módulos y/o ventanas. 3. Terminar la base de datos. 4. Diseñar entradas y salidas. 5. Generar el prototipo. 6. Revisar el diseño.

6.2 IMPORTANCIA DEL DISEÑO. • Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el

trabajo por realizar en la etapa de construcción. • Define claramente los componentes que tendrá el nuevo sistema, a nivel de

bases de datos, procesos e interfases. • “Descubre” la estructura física que tendrá el nuevo sistema. • Toma en cuenta el diseño de formatos tanto de entrada de datos, como de

salidas del propio sistema. • Proporciona una visión inicial para los usuarios, de cómo será su interacción

con el sistema, a través de los prototipos. • Da claridad para definir la arquitectura necesaria que soportará al nuevo

sistema.

6.3 CARACTERISTICAS DEL DISEÑO. • Es una representación abstracta del sistema, que plantea una solución que

será implementada luego. • Se preocupa de la "forma" del sistema en todos sus aspectos, definiendo con

todo el detalle como se iría a obtener esa forma planteada. Para esto es necesario desarrollar ciertas actividades como :

ABSTRACCION : Generalizar un problema con el fín de asignar prioridades a su

solución y establecer una jerarquía. OPERACIONALIDAD : Convertir la estructura generada en algo realizable y

funcional. VERIFICACION : Comprobar que se cumple con lo especificado en el análisis. • Es una etapa limitada por el ambiente tecnológico de hardware y software

existente en la organización. • Busca que la construcción del sistema se vuelva más rutinaria y elemental. • La estructura a diseñar debe ser modular, donde cada módulo exhiba

características funcionales independientes. • Un buen diseño debe ser : COMPLETO : Debe abarcar todos los requerimientos planteados anteriormente. CONSISTENTE : Se deben definir bien las interfases con otros sistemas. CLARO : Que sea fácil de traducir a un lenguaje de programación.

Diseño.

118

MANTENIBLE : Que evalúe la posibilidad de modificaciones futuras. PRACTICO : Que pueda ser realizable fácilmente, con las herramientas

tecnológicas existentes en la organización. EVALUABLE : Que permita revisarse y mejorarse.

6.4 PARTICIPACION REQUERIDA. Es una etapa muy técnica que requiere gran participación del personal de sistemas y del usuario, en lo que respecta a evaluaciones de prototipos y de diseño de pantallas (ventanas) del nuevo sistema. ANALISTAS : Elaboran las especificaciones del diseño, con base en el análisis elaborado anteriormente. El papel que desempeña en ésta etapa el analista de sistemas, es el de diseñador. La habilidades de un buen diseñador difieren algo de las del analista. Veamos : Se debe enfocar a la tecnología, sin olvidar los procesos definidos en el análisis, mientras el analista hace lo contrario. Se enfrenta con la tarea de traducir los requerimientos del negocio a la tecnología disponible en la organización. Un buen diseñador es creativo, lleno de recursos e inteligente para evaluar opciones entre soluciones que no son perfectas. Las habilidades de un diseñador estan más cercanas a las de un programador, ya que se debe tener claro el ambiente tecnológico, para poder sacar el mayor provecho de él. USUARIOS : Aprueban aspectos como operación del sistema, diseño de entradas y salidas, diseño de archivos y funcionalidad del sistema (Interfase de usuario).

6.5 PASOS EN EL DESARROLLO DEL DISEÑO. Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en el diseño de un sistema de información. Cada una de éstas tareas debe estar claramente documentada, en el manual de desarrollo del sistema.

Diseño.

119

6.5.1 DEFINIR LA ESTRUCTURA DEL SISTEMA (Diseño Glogal). Su objetivo es presentar el sistema bajo una estructura funcional que coordine y oriente la ejecución de todos los módulos que lo componen. Se construye a partir del diagrama de flujo de datos y el Diccionario de datos. Se visiona la composición del sistema desde el punto de vista de componentes de desarrollo para la etapa de construcción. Esta estructura se evalúa con base en técnicas de diseño estructurado como cohesión y acople, que se describirán más adelante. La tarea es recursiva. Es decir, se va modificando y decantando la estructura, en la medida que se vaya evaluando con el usuario.

6.5.1.1 PASOS PARA EL DESARROLLO DE LA ESTRUCTURA. 1. Derivación de la estructura inicial del sistema, a partir del diagrama de flujo de

datos y el diccionario de datos. (Sugerencia : La primera estructura se puede generar como una relación de uno a uno entre procesos del diagrama de flujo de datos y módulos de la estructura).

2. Identificación de los módulos que comprenderán el sistema y representación gráfica de la relación existente entre ellos.

3. Definición de las relaciones e interfases existentes entre los módulos.

Diseño.

120

4. Evaluación y depuración de la estructura, con base en consideraciones de diseño estructurado como acople, cohesión, factorización.

5. Retomar de nuevo desde el paso 2, hasta encontrar una estructura acorde a lo planteado en el análisis y a la tecnología disponible para la realización del sistema.

6.5.1.2 DESCOMPOSICION FUNCIONAL DE MODULOS. Esta técnica es la empleada para elaborar la estructura del sistema. Consiste en descomponer en forma sucesiva un módulo en otros módulos de más baja jerarquía, hasta lograr el detalle suficiente en la asignación de funciones a estos. Reglas para la descomplosición : • Cualquier estructura tendrá un módulo general o coordinador. • Cada módulo, si lo requiere, se subdividirá en otros. • Cada módulo subordinado, será coordinado por sus padres (un módulo puede

tener varios padres). • Deben existir por lo menos dos módulos al mismo nivel de descomposición. Ejemplo :

Sistema de Información de Nómina.

Diseño.

121

La descomposición del módulo de devengados es igual a la anterior.

De la anterior estructura podemos observar : • Siempre existe un módulo coordinador. En éste caso es el módulo llamado S.I.

NOMINA. • No todos los módulos se descomponen al mismo nivel, como es el caso de

PRODUCIR CHEQES, que sólo tiene un nivel de descomposición. Un módulo se debe descomponer, hasta obtener una medida alta de cohesión en la función que realiza.

• En primera instancia se está tratando de utilizar los mismos módulos tanto para el cálculo de devengados, como para el de deducciones, con el objetivo de ahorrar más tarde, tiempo de construcción. Obviamente, se debe mirar si esto es posible, a la luz del concepto de acople, que veremos más tarde.

• Existe un módulo, cuya descomposición está mal enfocada, dado que sólo se subdivide en otro módulo, lo que atenta contra las reglas antes mencionadas. Tal módulo es el denominado ESTRACTAR BASICO.

6.5.2 DISEÑO DE MODULOS. (Diseño Detallado). Es la descripción y representación detallada de cómo cada módulo de la estructura definida, ejecutará su trabajo con el fín de facilitar el proceso de construcción. Es básico en este punto, retomar las especificaciones de proceso o miniespecificaciones desarrolladas en el análisis, ya que el diseño de módulos, no

Diseño.

122

es más que un refinamiento de la especificación de proceso elaborada anteriormente.

6.5.2.1 REQUERIMIENTOS PARA EL DISEÑO DE MODULOS. • Tener plenamente definida la estructura del sistema y las relaciones entre los

módulos, ya que de éstas dependen el diseño de las entradas y salidas. • Conocer las herramientas tecnológicas y en específico el lenguaje de

programación que se utilizará. • Considerar las miniespecificaciones desarrolladas en el análisis.

6.5.2.2 ATRIBUTOS DE UN MODULO. Un módulo consta de los siguientes atributos, que se deben tener en cuenta para su adecuada definición : Entradas : Son datos o parámetros de control que recibe el módulo de quien lo llama. Salidas : Son datos que entrega el módulo a quien lo llamó, una vez finalice su operación o mecánica. Función : Es la transformación que realiza el módulo de los datos de entrada en datos de salida. Mecánica : Es la lógica con que cada módulo ejecuta su función. Tiene cuatro elementos básicos : Condición, secuencia, repetición y rutina. Datos Internos : Es el conjunto de datos que utiliza internamente el módulo para realizar su mecánica. El módulo se describe a través de la herramienta anteriormente vista en el análisis : Español estructurado. Es conveniente anotar que bajo las actuales herramientas de desarrollo, que enfocan a tener interfases gráficas, la unidad de programación no es el módolo entero, como se desarrolla bajo las técnicas estructuradas, sino más bien es cada ventana o pantalla que se presenta al usuario. En consecuencia, se puede decir que se generan especificaciones por ventana y no por módulos completos. Dicho de otra forma, es tomar el módulo completo y “dispararlo” contra la ventana, quedeando éste fragmentado en los diferentes eventos que puede manejar la ventana, con su correspondiente especificación.

Diseño.

123

Con las nuevas tendencias entonces, se tiende a fragmentar la especificación de cada módulo, en las “porciones de código”, que cada componente de la ventana controla. Se observa entonces un principio básico de construcción con herramientas gráficas : Cada pantalla o ventana mostrada por el sistema, es controlada por el usuario y no por el sistema mismo, lo que nos lleva entonces a variar la descripción de las especificaciones de los módulos, a tener especificaciones por eventos en cada pantalla o ventana. La especificación así realizada, puede dar una buena medida de cuánto tiempo tradará la construcción del nuevo sistema, dado que podemos determinar el grado de dificultad de cada ventana, a través de dichas especificaciones. Ejemplo : Módulo : Generar Comisiones de Ventas. ABRIR ARCHIVO VENTAS SECUENCIA INICIALIZAR VRCOMISION LEER REGISTRO VENTAS MIENTRAS NO FIN ARCHIVO VENTAS REPETICION SI VRVENTA > 1’000.000 CONDICION SI VENTA DE CONTADO COMISION = 10% SINO COMISION = 8% FIN SINO SI VENTA DE CONTADO COMISION = 7% SINO COMISION = 6% FIN FIN

CALCULAR VALOR COMISION RUTINA ** (VRCOMISION = COMISION * VRVENTA)

LEER REGISTRO VENTAS FIN

6.5.3 DISEÑO DE BASES DE DATOS. Se debe establecer en detalle como será la estructura física, tablas, atributos, relaciones y formas de acceso de la información que almacenará el sistema.

Diseño.

124

Es la última oportunidad que se tiene de refinar, corregir y definir la base de datos generada en el modelo de información, pues de esta actividad se desprende la construcción física de la base de datos. Una labor bien realizada aquí, garantiza con un alto grado de confiabilidad, que el sistema responderá al alcance planteado inicialmente, en forma precisa. Una mala definición de esta tarea, traerá como consecuencia el fracaso en la construcción del sistema, y el consecuente fracaso de la culminación del mismo. Requisitos : • Tener un conocimiento detallado del diagrama de estructura de datos generado

en el modelo de información. • Conocer en detalle los recursos tecnológicos de hardware y software

existentes, respecto al manejo de bases de datos. • Conocer el modelo de procesos, para vislumbrar tipos de accesos,

clasificaciones y operaciones que se hacen sobre los archivos. Esta tarea, al igual que la definición detallada de módulos, no es más que la confirmación de lo definido en el análisis o en caso contrario, la realización y corrección del nuevo modelo de información, basados en la estructura funcional del sistema, definida anteriomente.

6.5.4 DISEÑO DE ENTRADAS Y SALIDAS. Se define aquí, con todo el grado de detalle, cómo serán los documentos de entrada requeridos por el sistema, las diferentes pantallas de diálogo, las salidas generadas, todas las consultas y reportes emitidos, los formatos de salida y las diferentes interfases con otros sistemas. Es una tarea que se ocupa mucho de la forma, dado el carácter gráfico de la tecnología usada. Se deben tener estándares claros de diseño, para evitar que cada analista realice a su amaño estas definiciones. Sino se tiene estándares, es conevniente hacer un alto en este punto y definirlos claramente, para evitar ambigüedades en la presentación y diseño del sistema. Es conveniente seguir los lineamientos que ofrece la tecnología Windows, ya que éstos son estándares a nivel mundial.

6.5.4.1 DISEÑO DE DOCUMENTOS FUENTES. Se hacen basados en el contenido de los flujos de datos de entrada del sistema, descritos en el diccionario de datos. Se debe tener en cuenta : • En el encabezado del documento :

Diseño.

125

♦ Logotipo de la Organización. ♦ Nombre de la Organización. ♦ Nombre del departamento, sección o división. ♦ Código del documento. ♦ Número del documento.

• En el cuerpo del documento :

♦ Presentar un orden lógico de campos, de acuerdo con el orden de los datos que muestran las pantallas.

♦ Mostrar una descripción clara de cada campo a diligenciar. ♦ Permitir suficiente espacio para diligenciar cada campo. ♦ Manejar una presentación agradable y armónica.

• Permitir un espacio para posibles observaciones.

6.5.4.2 DISEÑO DE VENTANAS. Las ventanas son la forma básica de comunicación con el usuario y la unidad de programación a tener en cuenta en la construcción. Se deben diseñar, teniendo en cuenta los estándares antes mencionados y el tipo de ventana (entrada de datos, consultas, de menú, etc.). Se debe tener en cuenta : • Mostrar información que indique dónde se encuentra el usuario. Debe incluir :

♦ Nombre del sistema. ♦ Nombre de la ventana. ♦ Posibilidad de maximizar, minimizar o redimesionar la ventana. ♦ Posibilidad de personalizarla.

• Permitir líneas de mensajes de ayuda y de error.

♦ Mostrar los mensajes resaltados y en cajas de diálogo. ♦ Otorgar un primer nivel de ayuda en la línea de ayudas para cada

opción.

• El orden de datos en la pantalla debe ser claro y asemejarse al orden de los datos en los documentos fuentes.

La tecnología actual direcciona el diseño de las ventanas, hacia la utilización de herramientas gráficas, por sus ventajas comparativas con otras tecnologías. Dicha técnica se conoce en el mercado con el nombre de GUI (Graphical User Interface) o Interfase Gráfica de Usuario. Miremos algunos de sus aspectos más importantes :

Diseño.

126

Las primeras GUI fueron producidas en 1980 por Xerox. Comercialmente fue Apple quien la adoptó para sus computadores, en 1984, con el éxito comercial de la Macintosh de Apple. Luego aparece, en 1985, el primer sistema operativo GUI por parte de Microsoft, llamado Windows. El debate sobre si conviene usar o no la GUI carece de sentido hoy. más bien el reto consiste en elaborar interfases que estén bien diseñadas, satisfagan las necesidades del negocio y satisfagan las expectativas cada vez mayores de los usuarios. Algunos criterios a tener en cuenta en el diseño de GUI, son : Control del Usuario : Un buen diseño debe estar direccionado a soportar el hecho de que el usuario es quien tiene el control en la GUI. El usuario tiene la libertad para moverse de ventana a ventana y hacer cualquier cosa que desee. La tarea del diseñador es restringir a lugares donde no puede ir el usuario, más que a los lugares donde puede acceder. Una buena aplicación GUI debe tener facilidad para el uso del mouse o para el teclado, indistintamente. Por ello se deben incluir aspectos como el orden de tabulación y teclas aceleradoras (hot key) para que cualquier acción que se realce con el mouse, se pueda realizar también con el teclado. Sensibilidad : El sistema debe proporcionar retroalimentación tangible e inmediata para cada acción. Puede ser tan simple como cambiar un apuntador por el reloj de arena. Se deben usar cuadros de diálogo para indicar errores de usuario, a través de mensajes claros y entendibles. Nunca mensajes generados por el sistema operativo, por ejemplo. Personalización : Se debe permitir personalizar las diferentes ventanas del sistema, a los diversos tipos de usuarios que las acceden, teniendo cuidado de modificar algunos aspectos como colores, ocultamiento de columnas, etc. Dirección : Se debe tener presente que la memorización de comandos no aplica bajo GUI. Especialmente el hecho de ubicar un objeto en el sistema, debe ser tan intuitivo como señalarlo con el mouse y realizar la operación deseada con el objeto. Algo así como “apunte y dispare”. Se pueden usar para tal propósito iconos y barras de herramientas que aclaren la ubicación de los diferentes objetos existentes. Consistencia : El sistema deberá ser consistente con el mundo en que los usuarios viven y trabajan diariamente. Para ello se debe usar el vocabulario que manejan los usuarios y tratar de estandarizarlo a lo largo de todo el sistema, para que la GUI sea entendible por ellos.

Diseño.

127

Una clave aquí de estándares, es tratar de mantener los definidos en aplicaciones de uso general como Word y Excel, que siempre tratan de mostrar la misma interfase para el usuario. Claridad : La información presentada en la interfase debe ser inmediatamente comprensible y el uso de la aplicación debe ser visualmente evidente. Se deben usar tablas de control a través de listas desplegables para dar mayor información a los usuarios, cuandos se necesitan digitar datos como por ejemplo, sexo, estado civil, departamento, etc. Estética : La composición y disposición de una ventana debe ser visualmente agradable. Deberá atraer la vista hacia la información que es más importante.El ojo humano ve primero la parte izquierda superior del centro de la pantalla y hace un barrido en el sentido de las agujas del reloj. Se debe tener especial cuidado con los colores a usar, el tipo de letra, el tamaño de la misma. No se deben presentar ventanas muy atiborradas de objetos ; es mejor dividirlas en otras ventanas, para evitar confusiones. Indulgencia : Un buen diseño de interfase debe motivar la exploración. El usuario debe sentirse libre para husmear por la aplicación y dar vistazos rápidos en las diversas ventanas y características. Se debe otorgar un nivel de acceso al usuario, de acuerdo con sus funciones en el sistema y no “castigarlo” si no presenta el perfil adecuado a sus labores. Se debe dar también una forma de salida agradable cuando se decide abandonar ya sea una transacción o la aplicación misma. En general, una de las consideraciones más importantes a recordar es que las computadoras están diseñadas para ser usadas por gente real, y siendo personas todos tenemos limitaciones. El reconocer es más fácil que recordar. Por ésta razón, la línea de comandos es cosa del pasado. Tipos de Ventanas : Ventana Principal o de Aplicación. • Es la ventana más común. • Es independiente de cualquier otra ventana. • Puede traslapar y ser traslapada por otras ventanas. • Es movible, redinmensionable, puede ser minimizada. • Generalmente tienen un menú.

Diseño.

128

Ventana Principal.

Ventana Desplegable. • Conocida con el nombre de Pop Up. • Aparece por encima de la ventana que la llama. • Se abre desde una ventana existente, llamada Ventana Madre. • No puede ser traslapada por su madre. • Puede existir después de que se cierra la ventana madre.

Diseño.

129

Ventana Pop Up.

Ventana Hija. • Es muy similar a una ventana desplegable, pero más restrictiva. • Se abre a partir de una ventana madre. • No puede ser traslapada por la ventana madre. • No puede ser arrastrada fuera del marco de la ventana madre. • No puede existir después de cerrar la ventana madre.

Diseño.

130

Ventana Hija.

Ventana de Respuesta. • Es la más restrictiva de todas las ventanas. • No se libera sino hasta que se cierra. • No es minimizable ni redimensionable. • Se usa para forzar al usuario a través de una ruta particular.

Ventana de Respuesta.

Diseño.

131

Ventana MDI. • Traduce : Marco de Interfase para Documentos Múltiples. • Es un espacio de trabajo redimensionable y autocontenido que opera como una

ventana principal. • Viene con un menú. • Las ventanas que se abren dentro del marco son llamadas Hojas MDI. • Las hojas MDI se comportan como ventanas hijas. • Se pueden acomodar en mosaico, cascada y capas. • Se pueden abrir varias instancias de la misma hoja. • Son útiles para dividir sistemas grandes en aplicaciones separadas. Carpeta con Fichas o Pestañas. • Conocida como Tab Folder. • Su apariencia es como el de un archivador manual. • Utiles para desplegar varios elementos de datos por temas. • Se accede a cada ficha, con un clic en cada pestaña.

Carpeta con Fichas o Pestañas.

Diseño.

132

6.5.4.3 DISEÑO DE REPORTES. Se diferencian de los informes, por ser impresos y tener un límite de columnas para su presentación. Se deben diseñar teniendo en cuenta el contenido de los flujos de datos de salida definidos en el diccionario de datos. Se debe tener en cuenta : • En el encabezado de los reportes :

♦ Presentar el nombre de la empresa. ♦ Mostrar el nombre del sistema de Información. ♦ Mostrar el Título del reporte. ♦ La fecha de elaboración del reporte. ♦ Paginar el reporte.

• Presentar los nombres completos de los campos a listar. • Para reportes con totales, mostrar totales generales al finalizar el reporte. • Distribuir la información en una forma clara, ordenada y armónica.

6.5.5 DISEÑO DE OPERACION DEL SISTEMA (PROTOTIPOS). Es la tarea clave en lo que respecta a la definición de la forma como van a interactuar el usuario y el sistema, ya que se define, por parte de los analistas la navegación y comunicación entre las dos partes. No debemos perder el objetivo de ésta tarea, tratando de mostrar el sistema funcionando en éste punto. En algunos establecimientos, la creación de prototipos es una “disculpa” para codificar algo rápidamente y ver si los usuarios lo aceptan. Solo se busca que los usuarios tengan una idea de cómo será el diálogo y la navegación a través del sistema y en consecuencia se le debe aclarar al mismo el objetivo anteriormente expuesto. Se debe construir un modelo sencillo que muestre cómo será la operación del sistema, con el fín de probar con el usuario la dinámica, funcionalidad y características de implementación. Está aceptado generalmente que un prototipo es un modelo a escala de lo real, pero no tan funcional para que equivalga al producto final. Es la simulación de cómo quedará funcionando el sistema, para garantizar que se ajustará a las necesidades del usuario. Es un proceso de refinamiento en el cual participa activamente el usuario. Involucra directamente al usuario en el proyecto. Por primera vez el sistema tiene

Diseño.

133

una “cara”. Inevitablemente, despúes de ver el prototipo, alguien encontrará un evento que hasta el momento no se habia detectado, añadirá elementos a las ventanas y eliminará otros innecesarios. Por ello, el prototipo enriquecerá aún más el modelo de información y de procesos definidos anteriormente. Una buena idea para construir prototipos es la elaboración de los mismos en papel, para dar una mayor agilidad a la tarea, dado que ella es recursiva, pues se pretende mostrar y corregir, hasta obtener un producto totalmente aceptado por los usuarios. Se debe tener en cuenta : • Las herramientas de hardware y software disponibles para la construcción. • La estructura general del sistema. • Los modelos definidos en el análisis (procesos e información). El modelo de información es una guía crítica para la disposición de ventanas. El

marco organizacional de los datos está dictado por la cardinalidad de la relación en el diagrama entidad-relación. Si un pedido tiene varios conceptos de pedido, se podría esperar una relación encabezado-detalle en la ventana de mantenimiento de pedidos :

• Los diferentes módulos del sistema. • Algunas características propias del usuario :

Usuarios dedicados (Exigen poca documentación y capacitación). Usuarios casual (Desean un sistema amistoso y detallado). Grado de escolaridad. Funciones que desarrolla en la organización. Nivel de jerarquía.

• No mostrar características que no se puedan luego implementar. • No se debe comenzar a construir el sistema, con la creación temprana de

prototipos.

Diseño.

134

• Corregir los modelos de procesos e información, si surgen comentarios con la exposición del prototipo.

6.5.6 DOCUMENTACION Y REVISION. Luego de realizada cada una de las tareas anteriores, es conveniente revisar la documentación generada, con el fín de verificar que el diseño sea consistente con lo propuesto y no se halla quedado ningún requerimiento por fuera de este. Los participantes en la revisión deberán conocer de antemano, al igual que en el análisis, la documentación generada en esta etapa, para que la revisión sea fructífera y no se convierta en una reunión explicativa del documento del diseño. Las tareas anteriores se pueden realizar con varias técnicas informáticas. Dentro de éstas, se encuentra el diseño estructurado, que a diferencia del análisis estructurado, tiene una alta dosis de dependencia de la experiencia que puedan presentar los analistas para su desarrollo. Miremos entonces, en detalle, el diseño estructurado.

6.6 DISEÑO ESTRUCTURADO. Es una metodología de diseño orientada a procesos, basada en el método de solución de problemas TOP DOWN y que al igual que el análisis estructurado, es gráfica.

6.6.1 CARACTERISTICAS. • Ataca la complejidad de sistemas grandes, usando la partición y la jerarquía de

los mismos en partes funcionales más pequeñas. • Usa símbolos gráficos. • Transforma el diagrama de flujo de datos a la estructura funcional del sistema. • No es la solución total. La experiencia, la creatividad e intuición combinados

con éstas herramientas, serán la clave de un buen diseño.

6.6.2 COMPONENTES. Los componentes más importantes del diseño estructurado son :

6.6.2.1 IDENTIFICACION DE MODULOS. El Diseño estructurado se fundamenta en la partición sucesiva de un módulo en otros módulos, cada uno con una función específica a desarrollar o cumplir. Por módulo se entiende : Una porción de lógica que tiene un nombre y un conjunto de atributos (Entradas, salidas, funciones, mecánica y datos internos).

Diseño.

135

Representacion :

6.6.2.1.1 TIPOS DE MODULOS. Módulo Aferente : Es un módulo cuya característica importante es la de permitir tomar información del medio externo y llevarla al medio interno. Un ejemplo típico de éstos módulos, son los encargados del manejo de entrada de datos (data entry). Módulo Eferente : Son módulos que tienen como característica importante tomar la información del medio interno y llevarla al medio ambiente. Son clásicos en ésta categoría, los módulos generadores de reportes. Módulo Coordinador : Su función básica es orientar y coordinar la labor de otros módulos. Es un módulo definitivo en los niveles altos de la estructura. Un ejemplo serían los módulos encargados de ejecutar los menú de opciones de un sistema dado. Módulo Transformador : Son módulos que realizan una labor o función específica. Por ejemplo, un módulo que siempres calcula una raíz cuadrada, con base en un número que le es enviado como parámetro.

6.6.2.1.2 INTERFASES ENTRE MODULOS. Son las diferentes relaciones o llamadas que existen entre los módulos de un sistema. Pueden ser : LLamado Sencillo :

El módulo A llama al módulo B. LLamado a sí mismo :

Diseño.

136

El módulo A se llama a sí mismo (Recursividad). LLamado Múltiple :

A Llama a B,C o D (No importa el orden ni las condiciones). LLamado Excluyente :

A Llama a B, C o D, en forma excluyente. LLamado Repetitivo :

A Llama repetidamente a B. Se puede tener que un módulo pueda ser llamado por otros módulos (A es llamado por 2 ó más módulos). Lo anterior sirve para establecer las relaciones de qué módulos llaman a otros módulos.

6.6.2.2 DIAGRAMA DE ESTRUCTURA.

Diseño.

137

Como se mencionó al inicio del diseño, el diagrama de estructura sirve para mostrar la organización relacional y en muchos casos jerárquica, de los diferentes módulos que componen el sistema de información, además de las relaciones existentes entre ellos. No expresan la lógica del procedimiento, tarea que se deja a las especificaciones de proceso, ni las diferentes interfases físicas que puedan existir. Los componetes principales de un diagrama de estructura son :

El diagrama anterior se debe leer así : • El módulo A es el módulo de nivel superior, que consulta el módulo B. (Ningún

otro módulo llama a A). • El módulo B se llama subordinado de A. • El módulo A es quién pasa los parámetros al módulo B, como parte de la

llamada y el módulo B puede o no regresar parámetros de salida, cuando regresa al módulo A. Los parámetros de entrada y salida deben estar definidos en el diccionario de datos.

6.6.3 CARACTERISTICAS A EVALUAR EN EL DISEÑO.

6.6.3.1 ACOPLAMIENTO. Es el grado de interdependencia entre módulos. Es la medida de interacción de los módulos. Mide el grado de relaciones que existen entre los diferentes módulos de la estructura. Los buenos diseñadores buscan desarrollar la estructura de un sistema, de tal forma que un módulo tenga poca dependencia de cualquier otro módulo.

Diseño.

138

Se dice que un buen diseño debe contemplar un acople mínimo, controlando variables como : Número de parámetros que se transfieren entre módulos. Transferencia de datos innecesaria a los módulos que se llaman. Transferencias de datos, no información de control. Se puede tener un espectro de acople, asi :

Espectro de Acople.

Se busca minimizar el acople para : • Controlar la propagación de errores de módulo a módulo. • Que los cambios planteados a un módulo, no afecten otros módulos. • Que al trabajar en los detalles de un módulo, no se tenga que agrupar o pensar

en muchos módulos. La conectividad sencilla da como resultado un software fácil de mantener y menos propenso al “efecto onda” producido cuando los errores aparecen en una posición y se propagan a lo largo del sistema. Los niveles altos de acople, se producen cuando los módulos están ligados a un entorno externo. Por ejemplo, entradas de dispositivos, protocolos de comunicación, etc. Aunque esto es esencial, debe limitarse a un pequeño número de módulos dentro de la estructura. Existen diferentes tipos de acople, que se pueden dar durante el diseño de un sistema. A continuación se presentan en forma ordenada, es decir, del acople “menos malo” al acople no deseable : Acople de Datos : Sucede cuando la comunicación entre módulos se hace a través de los datos estrictamente necesarios para que opere el módulo subordinado (Parámetros). Es el mejor acoplamiento. Acople de Estampa : Se da a través del envío de parámetros que no son los estrictamente necesarios para el desempeño del módulo subordinado.

Diseño.

139

Acople de Control : Sucede cuando la comunicación de módulo a módulo, se da a través de parámetros de control. Antes de ejecutar un módulo, se realiza una acción de control. Por ejemplo, verificar si existe un código de cliente antes de crearlo. Acople de Ambiente Común : Se presenta cuando la comunicación entre módulos se da a través de otro módulo de datos (módulo intermedio). Acople de Contenido : Ocurre cuando entre módulos fluyen parámetros que afectan la lógica del otro módulo. Es el acople menos deseable. Por ejemplo, el módulo A envia al módulo B el valor de N, para que éste realice un ciclo.

6.6.3.2 COHESION. Es la medida con que cada módulo ejecuta su trabajo. Evalúa al interior del módulo. El acoplamiento evalua interfases entre módulos. Se dice que a mayor cohesión, mejor es el diseño y se tiende a disminuir la comunicación o acople entre módulos. Es un principio básico en la construcción de código reutilizable. Un módulo con buena cohesión es más barato de mantener en el largo plazo. Un módulo cohesivo, ejecuta una tarea sencilla de un procedimiento de software y requiere poca interacción con procedimientos que ejecutan otra parte de un programa. Podemos manejar un espectro de cohesión, así :

Espectro de Cohesión.

Una técnica para determinar si un módulo es altamente cohesivo es escribir una frase que describa la función del módulo y luego examinar dicha frase. Puede hacerse la siguiente prueba : Si la frase es una sentencia compuesta, contiene una coma o más de un verbo, probablemente el módulo realiza más de una función. Puede tener vinculación secuencial o de comunicación.

Diseño.

140

Si la frase contiene palabras relativas al tiempo, tales como primero, a continuación, entonces, después, cuándo, al comienzo, etc., entonces probablemente el módulo es secuencial o temporal. Si el predicado de la frase no contiene un objeto específico sencillo a continuación del verbo, el módulo puede presentar cohesión lógica. Palabras como : inicializar, limpiar, etc., implican cohesión temporal. Los módulos con cohesión funcional siempre se pueden describir en función de sus elementos usando una sentencia compuesta. Pero si no se puede evitar el lenguaje anterior, siendo aún una descripción completa de la función del módulo, entonces el módulo no presenta cohesíón funcional. A nivel de ventanas, la cohesión puede ser evaluada por la cantidad y tipo de eventos de negocios que son reconocidos y manejados dentro de una ventana o juego de ventanas en una aplicación. Los diferentes tipos de cohesión, de nuevo ordenados de mejor a peor, son : Cohesión Funcional : Se presenta cuando un módulo ejecuta una sola labor. Por ejemplo un módulo que calcula devengados. Una ventana funcionalmente cohesiva, maneja un evento a nivel de negocio. Por ejemplo, se debería tener una ventana para manejar datos de un cliente, dado el evento “el empleado de ventas registra/actualiza el nombre y la dirección del cliente. Otra ventana para capturar un pedido de un cliente, etc. Se presenta una ventaja con éstas ventanas y es que son más sencillas de controlar y más especializadas y eficientes en reconocer el evento dado, lo cual hace posible también la reutilización de ellas por varios sistemas. La desventaja es que se generan muchas ventanas para el sistema. Cohesión Secuencial : Ocurre cuando un módulo ejecuta una labor de tal modo que la salida de una actividad, se convierta en la entrada para la siguiente actividad. Por ejemplo : Dada la función : X = A * (B2 * C) Gráficamente, la cohesión secuencial sucede así :

Diseño.

141

Los datos de entrada al módulo X son A, B y C, como se observa en el gráfico. Al ejecutarse la actividad D ( B*B), su resultado es la entrada para la siguiente actividad del módulo, la actividad E (D * C). Para finalizar la tarea del módulo, la actividad F retoma el resultado de la actividad E y realiza su cálculo (E * A). Las ventanas que presentan ésta cohesión tienen los eventos agrupados, debido a que éstos suceden en secuencia. Por ejemplo, se puede diseñar una ventana que pida datos de un cliente, genere un pedido y permita el pago del mismo. La ventaja de ésta cohesión es que se aproxima mucho a cómo es el flujo del trabajo normal del usuario en la organización. Es adecuada cuando se manejan tareas repetitivas. La desventaja es que existe una mezcla compleja de código no relacionado, es más compleja de diseñar, usar y de mantener. Siempre supone que los eventos suceden en forma ordenada. Es poco probable que se reuse en otros sistemas. Cohesión de Comunicación : Ocurre cuando los componentes de un módulo toman la misma entrada y producen diferentes salidas. El orden de las componentes del módulo no es importante.

X2 Log x Sen x El parámetro de entrada al módulo es el dato X. Con éste, se realizan tres funciones individuales A (X2), B (Log X) y C (Sen X), con resultados distintos. Se debe hacer notar que las diferentes funciones no se encuentran relacionadas, lo cula implica que no importa el orden de ejecución de ellas dentro del módulo.

Diseño.

142

Una ventana con este tipo de cohesión, es aquella en la que los eventos han sido agregados por que afectan al mismo objeto y se comparten los mismos datos para los eventos agrupados. Se tiene la ventaja de que los eventos comparten el mismo código de acceso de datos y las mismas reglas del negocio. Su problema es que regularmete las ventanas son utilizadas por más de un usuario, que tienen diferentes funciones a realizar sobre el mismo objeto y son obligados a usar toda la ventana. Se disipa el control sobre el objeto en muchos usuarios. Ninguno tiene el control total. Son difíciles de codificar. Cohesión Procedimental : Sucede cuando fluye control en el módulo. La secuencia de ejecución de las funciones es importante.

La gráfica anterior trata de explicar la política de algún departamento de ventas, con respecto a aprobar o no créditos a sus clientes. Se puede ver que existen varios controles para lograr la aprobación final, como son : Averiguar por el límite de crédito del cliente y controlar las fechas de vencimiento de las facturas. Dependiendo de estos dos controles, se aprueba o no el crédito correspondiente. Es conveniente, bajo éste esquema, particionar aún más el módulo para evitar “repetir código”, como se ve el la gráfica cuando ocurre la aprobación del crédito por diferentes “ramificaciones” de los controles mencionados antes (se repite APROBAR tres veces en el módulo). Una ventana con cohesión procedimental organiza las tareas de acuerdo a la descripción de trabajo de un usuario particular. Los eventos son agregados para dar al usuario todo lo que necesita en una ventana.

Diseño.

143

Esto da como resultado ventanas que son complejas, atiborradas, lentas en responder y extremadamente sensibles a los cambios organizacionales dentro del negocio. Cualquier aplicación tendrá una mezcla de cohesión entre sus ventanas. La mayoría de las ventanas bien diseñadas, caerán en los primeros tres niveles descritos. La cohesión funcional produce las mejores ventanas reutilizables, comprensibles y mantenibles, pero se tendrían muchas ventanas en el sistema. La cohesión secuencial es un método bueno para diseñar tareas que se ejecutan regularmente. La cohesión de comunicación mantiene el acceso a los datos y las reglas del negocio en un solo lugar, pero incrementa la complejidad de manejo de la interfase. Las ventanas con cohesión procedimental engendran el riesgo adicional de ser inflexibles ante los cambios de la descripción del puesto del usuario.

6.6.3.3 FACTORIZACION. Es el proceso de particionar el trabajo o función de un módulo, a través de las especificaciones de otros módulos subalternos. La factorización da como resultado una estructura de programa en la que los módulos de nivel superior toman las decisiones de ejecución y los de nivel inferior ejecutan la mayoría del trabajo de entrada, computacional y de salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo. Se busca factorizar para : • Disminuir el tamaño de módulos grandes. • Dar más independencia entre módulos, para facilitar el cambio de los

requerimientos (mejorar acoplamiento). • Mejorar cohesión, dado que se realizan funciones más particulares dentro de

cada módulo. El particionamiento no debe exceder más de nueve módulos. Se busca tener un particionamiento entre siete y nueve módulos, por nivel. Ejemplo : El módulo INGRESAR FACTURA, se puede factorizar de la siguiente forma : LEER FACTURA VALIDAR FACTURA REPORTAR FACTURA.

Diseño.

144

Se suspende la factorización cuando se llegue a una función bien definida.

6.6.3.4 FAN IN. Se define como el número de módulos que llaman a otro módulo. Un buen FAN IN implica optimización en construcción, dado que se hace uso del mismo módulo, desde diferentes funciones que lo requieren y no se repite la construcción de la función en cada módulo. Es el caso típico de la función Imprimir bajo windows, que sólo se invoca desde donde se necesite, por ejemplo desde un documento en Word o desde una hoja electrónica en Excel. Dicha función esta escrita una sola vez como módulo. Es usada por quén la necesite. Un buen número de FAN IN por módulo, puede ser tres. Quiere decir lo anterior, que un módulo puede ser usado por máximo otros tres módulos diferentes.

Podemos apreciar en la gráfica, que los módulos A, B y C, llaman al módulo D, cuyo Fan In es tres en éste caso.

6.6.3.5 FAN OUT. Se define como el número de módulos que son llamados por otro módulo. Debe ser mayor de uno y menor o igual a nueve. Un buen FAN OUT implica un adecuado particionamiento de módulos a nivel de funciones específicas, lo cual mejora la cohesión en los módulos. Es una medida que refuerza el hecho de evitar cohesiones como la procedimental y la de comunicación. Se dice que un buen Fan Out es de nueve por módulo. Quiere decir, que un módulo puede llamar a otros nueve como buena medida de Fan Out.

Diseño.

145

De la gráfica podemos ver que el Fan Out de A es tres. El módulo A llama a los módulos B, C y D.

6.6.4 PROCEDIMIENTO PARA CONSTRUIR LA ESTRUCTURA DEL SISTEMA A TRAVES DEL DISEÑO ESTRUCTURADO. El procedimiento descrito a continuación, tiene como objetivo, convertir los diagramas de flujo de datos en una estructura inicial que se vaya mejorando y puliendo a través de la evaluación sucesiva de la misma. Pasos : 1. Revisar y si es posible perfeccionar los diagramas de flujo de datos. 2. Identificar tipos de flujos de información en los diagramas de flujo de datos.

Existen diferentes tipos como :

Flujos de Transformación : La información que entra al sistema va sufriendo una serie de cambios al pasar por los procesos, hasta transformarse en flujos de salida, dando la respuesta deseada.

Flujos Aferentes : Son flujos que llevan información del medio externo a los procesos (Información de entrada). Flujos Eferentes : Son flujos que llevan información del medio interno al

exterior (Información de salida). Flujos Centrales : LLevan información dentro del medio interno, para realizar cálculos y operaciones en el sistema. Flujos de Transacción : Son flujos que sirve para enrutar a diferentes

procesos, dentro de un diagrama de flujo de datos.

3. Identificar la(s) transformacion central, o sea los procesos escenciales del sistema. (procesos a donde llegan muchos flujos aferentes y salen muchos eferentes).

4. Definir la estructura inicial del sistema. 5. Perfeccionar el cuadro resultante a través de los conceptos de : Acoplamiento, cohesión, factorización, fan in y fan out. 6. Repetir los dos pasos anteriores hasta obtener una estructura aducuada para el

diseño detallado.

Diseño.

146

6.7 RESUMEN : ENTRADAS PROCESO PARTICIPACION SALIDAS Modelo de Procesos.

1. Diseño Global. Estructura del sistema


Estructura del sistema.

Modelo de Información.

2. Diseño detallado. Diseño de módulos.

Analistas. Diseño de ventanas, reportes,

Hardware y Software existente.

3. Diseño de bases de datos.

4. Diseño de entradas/salidas.

Analistas. Analistas. Usuarios.

Informes, formatos, interfases.

4.1 Ventanas. 4.2 Formatos.

Seudocódigo. Base de datos.

4.3 Reportes. 4.4 Informes.

4.5 Interfases. 5. Diseño de operación

del sistema. Analistas. Usuarios.

Prototipos. 6. Revisión del diseño.


Caso de Estudio.

147

7. CASO DE ESTUDIO. Con la presentación del siguiente caso, se pretende aplicar todos los conceptos antes expuestos, para que se pueda tener un caso práctico que sirva de guía en algunas ocasiones, cuando especialmente, se tengan que enfrentar nuevos desarrollos en los diferentes proyectos de estudio. El caso es sobre el funcionamiento de una Tesorería hipotética, de alguna organización. Para lograr aplicar los conceptos metodológicos, se suponen algunas entrevistas con los diferentes empleados del departamento, además de la observación directa del funcionamiento del área. Cabe aclarar que dicho caso sólo persigue fines netamente académicos. No pretende ser aplicado comercialmente a ninguna organización. Veamos a continuación el desarrollo del caso. ENTREVITAS. ENTREVISTA CON EL JEFE DE TESORERIA. El objetivo de mi área es mantener un buen estado de flujo de fondos, para poder lograr el pago oportuno de las diferentes obligaciones adquiridas por la empresa, así como también poder obtener ingresos que por diferentes motivos, llegan a la Tesorería. Para ello, trato de organizar las labores del área así : Existe un área que se encarga de llevar el manejo de caja y bancos, en lo que tiene que ver con el cuadre de la caja, tramitar ingresos y emitir pagos. El funcionario de esta área tramita los ingresos efectuados por los clientes (los recibe), entregándoles un recibo de caja asociado al pago. Además paga a los proveedores las diferentes facturas que llegan al área de caja. También recibe información de consignaciones que envían los bancos por concepto de pago en otras plazas. Nuestro funcionario además elabora las consignaciones locales y las envía a los bancos respectivos. Finalmente, con la información de pagos e ingresos, cuadra la caja. Al final del día, me envía el informe de cuadre de caja y el informe de ingresos y egresos. Los ingresos recibidos también los envía a su compañero del área de proyecciones, que tiene como función básica proyectar los pagos en el tiempo, con base en las políticas de financiamiento que yo le mando a él, semanalmente.

Caso de Estudio.

148

Esta área me entrega un informe de proyecciones de ingresos y egresos y además envía a mi área de prestamos bancarios, las obligaciones que se deben tramitar con los bancos. El área de prestamos a su vez, tramita y maneja dichas obligaciones. Entrega a los bancos las solicitudes de préstamos por adquirir; si el banco acepta la solicitud, envía allí el informe de las obligaciones aceptadas. Con dicha información, el área de prestamos envía el valor de las obligaciones adquiridas al funcionario que maneja caja y bancos, para actualizar las cuentas bancarias. También genera para el departamento de contabilidad un informe de obligaciones adquiridas, para que se asienten en la contabilidad. A mi, me envía un informe de las obligaciones adquiridas por fecha de vencimiento. Se me olvidaba decirles que el funcionario de caja y bancos también genera para la contabilidad, toda la información de ingresos y egresos, para que se realicen los diferentes asientos contables. Todas las notas que llegan de los bancos por concepto de cobros de obligaciones o préstamos, son manejadas por el encargado de préstamos, quien las verifica y las aplica a los respectivos préstamos que se van pagando. Luego las remite a la caja, para que se actualicen los saldos de los bancos. Semanalmente, el departamento de cuentas por pagar entrega la programación de pagos, para que en mi área se realice el pago respectivo a los diferentes proveedores consignados en la programación, a través de la caja. Para ello, se ordena la programación, se verifican los valores a pagar y se generan los cheques. Finalmente, después del pago, se genera un informe de los cheques entregados con su respectiva orden de pago, para Cuentas por pagar. Esto es, a nivel general lo que hacemos aquí. Muchas gracias por la ayuda que me puedan prestar. ENTREVISTA CON EL ENCARGADO DE LA CAJA. Mi función básica, es mantener actualizados los diferentes saldos de las cuentas de los bancos con los cuales tenemos negocios, además de manejar también las cuentas de las diferentes cajas de la empresa. Dispongo de un archivo donde se consignan los diferentes movimientos de entradas y salidas de cada banco y cada caja. Aplico los ingresos de los clientes y de las consignaciones que envían los bancos por concepto de pagos de clientes en otras ciudades. También debo aplicar los egresos por conceptos de notas y cheques pagados. Sumarizo los ingresos y egresos del día y genero informes de ingresos y egresos para Contabilidad, la

Caso de Estudio.

149

Gerencia y el área de proyecciones. Con la información sumarizada, cuadro la caja al final del día y remito dicho cuadre a la Gerencia. A cada cliente que paga, le entrego su correspondiente recibo de caja. Dos veces al día, realizo consignaciones del dinero recibido, al banco que se tiene programado para ello. Estas consignaciones, afectan los saldos en el archivo de cuentas bancarias, como un ingreso para el banco destino y un egreso para las cajas de donde se extrae el efectivo y los cheques a consignar. Semanalmente recibo del departamento de Cuentas por pagar, la programación semanal de pagos, que contiene la información de los cheques a pagar a los diferentes proveedores, quienes tramitan las facturas y me las remiten para así poder realizar el pago. Ordeno la programación con base en las facturas y las archivo en el folder de pagos ordenada por proveedor, para poder verificar los valores totales a pagar. Si esos valores son correctos, se generan los cheques y las ordenes de pago. Al final se envía dicha información al departamento de Cuentas por pagar. ENTREVISTA CON EL ENCARGADO DE PROYECCIONES. Mi tarea consiste en realizar las proyecciones de ingresos semanales, con base en el informe de ingresos que genera el área de caja y las diferentes políticas de financiamiento que semanalmente me envía el Gerente. Realizo las proyecciones en Excel y envío el resultado al Gerente y a mi compañero del área de Préstamos. Eso es todo lo que hago a nivel de proyecciones. Mi trabajo es totalmente manual. ENTREVISTA CON EL ENCARGADO DE PRESTAMOS. Mi trabajo consiste en manejar todo lo relacionado con el trámite y manejo de los diferentes préstamos u obligaciones bancarias adquiridas por la compañía. Me envían del área de proyecciones un informe con las diferentes obligaciones a adquirir, con su valor. Yo tramito una solicitud a determinado banco y la envío. Todas las solicitudes son almacenadas en un archivador, hasta que éstas son respondidas por el banco. Una vez el banco envía la respuesta, las solicitudes aceptadas se convierten en obligaciones y se genera otro archivo con dicha información. Es mi obligación elaborar un informe para la Gerencia que contiene las diferentes obligaciones adquiridas ordenadas por fecha de vencimiento, así como también entregar un listado de las nuevas obligaciones para Contabilidad.

Caso de Estudio.

150

El valor de cada obligación también es enviado al áreas de Caja, para que allí se actualicen las cuentas bancarias. ENTREVISTA CON EL ENCARGADO DE NOTAS BANCARIAS. A mi oficina llegan todas las notas que mandan los bancos por conceptos de cobro de intereses y capital, sobre los prestamos adquiridos. Mi labor consiste en verificar si esas notas verdaderamente corresponden a obligaciones adquiridas por la empresa, con base en los archivos de préstamos y de notas que se manejan aquí. Si son notas válidas, debo aplicarlas a cada préstamo, consignando en el archivo los respectivos valores cobrados por los bancos. Genero también un informe de notas para la caja para que sean aplicadas a cada cuenta bancaria.

Caso de Estudio.

151

ESTUDIO DE FACTIBILIDAD. RECONOCIMIENTO GENERAL DEL SISTEMA. UBICACIÓN GENERAL. La empresa Alfa S.A. esta dedicada a la producción de alimentos para animales, siendo una de las más reconocidas en el medio. Comenzó labores hace diez años y su objetivo es producir el mejor suplemento alimenticio para animales, al mejor precio del mercado. Sus oficinas están ubicadas en Pereira, en las afueras de la ciudad. La compañía pertenece al sector secundario de la economía, pues está dedicada al ramo de la producción. Presenta la siguiente estructura organizacional :

Compañ í a Alfa S.A.

PLANTA ALMACEN

PRODUCCION

VENDEDORES

LINEA LIVIANA

VENDEDORES

LINEA CAMPO

VENTAS

COORDINADORES

RECURSO HUMANO

CAJA Y BANCOS

PRESTAMOS

TESORERIA CUENTAS POR PAGAR

FINANZAS

GERENCIA

Caso de Estudio.

152

El sistema a desarrollar se ubica en la dirección financiera, más específicamente en la gerencia de Tesorería, que maneja lo relacionado con los ingresos y egresos de la compañía y el manejo de todo lo relacionado con las obligaciones adquiridas con los bancos. Se pretende construir un sistema de información que maneje aspectos del área de caja y bancos y del área de prestamos bancarios. ALCANCE DEL SISTEMA. El fin del sistema de caja y obligaciones financieras es poder manejar en forma automatizada todas las tareas que tienen que ver con el manejo de las cajas y las cuentas bancarias de la compañía, tales como : ingresos, egresos, cuadre de caja, y generación de informes de gestión de las tareas anteriores para la Gerencia y otras áreas de la compañía como Contabilidad y Cuentas por pagar. Se dará información a terceros que están relacionados con el sistema, como : Clientes directos, Proveedores y Bancos. También se pretende cubrir el total manejo de las operaciones relacionadas con el área de Préstamos bancarios, como : Solicitud de préstamos, generación y manejo de las obligaciones de la compañía y administración de las notas enviadas por los bancos. Se tendrá opción de manejar proyecciones de ingresos, para la Gerencia y el departamento de Préstamos. OBJETIVOS DEL SISTEMA. Disponer de una herramienta automatizada que mejore en alto grado el desempeño del personal involucrado en el manejo de las áreas de Caja y bancos y de Préstamos, permitiendo incrementar la disponibilidad de ésta información tanto para los usuarios internos de la compañía, así como para los externos. Específicamente : • Evitar el costo de $350.000 mensuales por llamar a cada banco para solicitar el

saldo de cada cuenta bancaria en promedio, el cajero destina tres horas para lograr dicha información.

• Mejorar la atención a los clientes de la compañía, mediante la elaboración

automatizada de los diferentes recibos de caja, que se elaboran cuando éstos realizan pagos en la Caja.

• Evitar el costo de papelería de $890,000 mensuales, ocasionada por la compra

de recibos de caja, imprimiendo en formas continuas dichos recibos.

Caso de Estudio.

153

• Mejorar la atención a los proveedores, agilizando la entrega de pagos en dos días, mediante una adecuada organización e impresión de cheques.

• Evitar el costo de chequeras por valor de $1’340.000 mensuales, imprimiendo

en formas continuas los cheques para pago a proveedores. • Reducir el tiempo de elaboración y entrega de solicitudes de préstamo a los

diferentes bancos en dos días, al disponer semanalmente, al principio de la semana, de las proyecciones de obligaciones a adquirir.

• Evitar el costo de aproximadamente $3’260.000 en promedio mensual, de

multas ocasionadas por la mala aplicación de las notas bancarias a los préstamos adquiridos, haciéndolo en forma automatizada y sin errores.

• Reducir el tiempo de disponibilidad de reportes de caja, ingresos y egresos a un

día, para la Gerencia, Contabilidad, Proyecciones y Cuentas por pagar. DEFINICION DEL SISTEMA. Dentro de la empresa, el sistema interactuará con áreas como : Contabilidad, Cuentas por Pagar y la Gerencia de Tesorería. A nivel externo, con los Proveedores, quienes son los que surten a Producción de materia prima. Su relación es a través de los pagos de materia prima que se generan en la Caja. Los clientes locales y remotos, a través de los pagos directos y por medio de consignaciones que se hacen en la Caja. Los diferentes Bancos, quienes manejan las cuentas de la compañía, otorgan préstamos y envían notas de cobro. A nivel de información que genera el medio ambiente para que el sistema cumpla con sus objetivos, tenemos : Consignaciones de otras plazas, que envían los bancos de los clientes remotos. Formato de los créditos aprobados, enviados por los Bancos. Notas bancarias, para cobrar interese y capital de las obligaciones. Pagos directos realizados por los clientes. Las diferentes políticas de financiamiento que la Gerencia emite. La programación de pagos que genera el departamento de Cuentas por Pagar. Las facturas que envían los Proveedores. Con respecto a la información generada por el sistema, podemos distinguir : El pago de las facturas a los proveedores (cheque y orden de pago).

Caso de Estudio.

154

Las diferentes consignaciones generadas para los Bancos, por el cajero. Recibos de caja para los clientes que hacen pagos directos en la Caja. Información de obligaciones, ingresos y egresos, para Contabilidad. Información de caja, ingresos, egresos, obligaciones y proyecciones para la Gerencia de Tesorería. Informe de ordenes de pago y cheques pagados, para el departamento de Cuentas por Pagar. Solicitudes de crédito elaboradas por el área de préstamos, para los Bancos. Ordenes de pago y cheques para los Proveedores. Los elementos funcionales que componen el sistema son : Caja y Bancos, que maneja todo lo relacionado con cuentas en bancos y las cajas de la compañía. Proyecciones, que calcula las diferentes proyecciones de ingresos y egresos. Prestamos, que se encarga de todo lo relacionado con el manejo de créditos otorgados por los bancos. Pagos, que realiza la función propia del pago a proveedores. Notas bancarias, cuyo objetivo es mantener el funcionamiento de las operaciones que se derivan de aplicar las diferentes notas que remiten los bancos, para el pago de obligaciones. Existen también algunas relaciones entre los elementos anteriores. Dichas relaciones son : El informe de ingresos recibidos que envía la Caja a Proyecciones. Los cheques pagados que son importantes para realizar la función de la Caja y son generados por los Pagos realizados. El informe de obligaciones adquiridas, que remite el área de Prestamos al área de Caja. El informe de Notas recibidas, que diligencia Notas para la Caja. Gráficamente, podríamos decir que nuestro sistema de Caja y Obligaciones Financieras es el siguiente, en forma global :

Caso de Estudio.

155

BANCOSConsignac. otras plazas

Notas bancarias

Créditos aprobados

CLIENTES Pagos realizados

GERENCIA Políticas definanciamiento

Programación de pagos

Facturas

SISTEMA DE INFORMACION

CAJA Y BANCOS

Y

GERENCIA

BANCOS

CLIENTES

CONTABILIDAD

PROVEEDORES

CUENTAS PORPAGAR

Ingresos y pagos

Obligaciones por vencimiento

Cuadre de caja

Proyección ingresos y egresos

Consignaciones locales

Solicitud de crédito

Recibo de caja

Obligaciones adquiridasIngresos y pagosCheque y orden de pagoPagos realizados

PROVEEDORES

OBLIGACIONES

FINANCIERAS

CUENTAS PORPAGAR

DIAGRAMA DE CONTEXTO DEL SISTEMA.

RECURSOS PARA EL DESARROLLO. La siguiente es la relación de los recursos de que se dispone para el desarrollo del sistema. Económicos. Se cuenta con un presupuesto destinado para el proyecto, así : Compra de Equipo $2’000.000 Material de Oficina $ 85.000 Papel Diskettes Cinta Impresora Software de Desarrollo $1’000.000 Salarios Analistas $2’500.000 Salarios Usuarios $3’600.000 TOTAL $9’185.000 Personal. Se cuenta con un grupo de personas que ejecutarán el proyecto, entre analistas y usuarios. Ellos son :

Caso de Estudio.

156

Analistas : Juan Pérez Mónica Ramirez Pedro Juan Gómez Usuarios : Julian Medina (Usuario Dueño del sistema). Susana Pérez (Usuario Responsable y operativo). Técnicos. Los recursos de hardware y software disponibles son : Equipo de cómputo : • Microcomputador Pentium 32 Megas de memoria. 40 Mhz. Disco duro 200 Megas. Mouse Pantalla a color SVGA. Drive 31/2. • Impresora Canon Bubble Jet BJ200. Software disponible : • Visual Basic 5.0 • Windows 95 • Officce ESTIMATIVOS DE DESARROLLO. De acuerdo con lo estipulado hasta el momento, el tamaño del sistema, las personas participantes y la tecnología disponible, se estima que el proyecto puede presentar una duración de 10 meses, con dedicación de medio tiempo, por parte tanto de los analistas como de los usuarios. Se proyecta un costo de desarrollo con base en el número de ventanas a construir, siendo esta la unidad de mínima de codificación para el sistema. Aproximadamente, el costo total, sería de $2’500.000, sin incluir el salario de los usuarios involucrados.

Caso de Estudio.

157

Con los salarios de las personas mencionadas anteriormente, el costo total del proyecto sería de $6’100.000, por concepto de mano de obra. ANALISIS DE FACTIBILIDAD. Se pretende mostrar en detalle el análisis de factibilidad realizado al sistema, para determinar su viabilidad financiera, técnica y operativa. FACTIBILIDAD ECONOMICA. De acuerdo con los beneficios que otorgará el sistema al área de Tesorería y los costos en los que se debe incurrir para el desarrollo del mismo, se concluye que el sistema es factible financieramente, como se detalla a continuación : Beneficios Económicos. Para las cifras mostradas, se aplica una base mensual. Costos de chequeras $1’340.000 Multas bancarias $3’260.000 Reducción de gastos telefónicos por concepto de llamadas a los bancos $350.000 Papelería de recibos de caja $890.000 TOTAL $5’840.000 Beneficios No Económicos. Mejoras en la atención a los clientes de la compañía, al realizar los pagos en forma automatizada. Evidente mejora en los pagos a los proveedores. Reducción del tiempo de elaboración y entrega de solicitudes de préstamo a los diferentes bancos. Mayor disponibilidad de reportes de caja, ingresos y egresos para la Gerencia, Contabilidad, Proyecciones y Cuentas por pagar.

Caso de Estudio.

158

Costos. Los costos en los cuales se incurrirá en la elaboración del sistema son básicamente de desarrollo y de equipo de procesamientos. A continuación se detallan. De Desarrollo. Salarios Analistas $2’500.000 Salario Usuarios $3’600.000 Material de Oficina $85.000 TOTAL $6’185.000 Los equipos necesarios y el software de desarrollo, se encuentra disponible en la empresa, lo cual no ocasiona costos de adquisición de los mismos. Cabe aclarar que aunque los costos son mayores que los beneficios económicos, el sistema es factible, dado que los beneficios no económicos planteados anteriormente, tienen el suficiente peso, para cubrir la inversión en el sistema. FACTIBILIDAD TECNICA. Con base en la plataforma tecnológica de hardware y software disponible en la empresa, se puede concluir que el desarrollo del nuevo sistema se puede llevar a cabo, dado que dicha tecnología se ajusta completamente para la elaboración del sistema planteado. FACTIBILIDAD OPERATIVA. Los usuarios Julian Medina y Susana Pérez, cuentan con la capacitación necesaria para administrar el futuro sistema y no presentan oposición aparente a los cambios funcionales a que obliga la puesta en marcha del nuevo sistema, ya que ellos mismos son sus directos beneficiados. Los analistas Juan Pérez, Mónica Ramirez y Pedro Juan Gómez, poseen los conocimientos técnicos adecuados para la elaboración del sistema. Lo anterior lleva a concluir que el sistema, a nivel operativo también es factible.

Caso de Estudio.

159

ALTERNATIVAS Y RECOMENDACIONES. De acuerdo con el estudio realizado, se puede tener en cuenta las siguientes alternativas de solución para el desarrollo y puesta en marcha del sistema. Desarrollar el sistema por personal interno. Es una alternativa que involucra menos costo, el personal es conocedor a fondo de los problemas del área y se tendría un sistema hecho “a la medida” para la compañía. De otro lado, es más demorado su desarrollo, dado que el personal de Informática, no cuenta con todo el tiempo para desarrollar el proyecto. Es posible que se presenten, durante el desarrollo del sistema, problemas de índole interpersonal, dado que tanto los analistas como los usuarios, laboran en la misma empresa. Desarrollar el sistema con personal interno y externo (Desarrollo Mixto). Es una alternativa más costosa, pero a su vez es más rápida, dado que el personal externo es experto en el lenguaje de desarrollo a utilizar. Existe una desventaja con ésta alternativa, dado que para eventuales cambios y mejoras, se dependería completamente de los desarrolladores externos. Se debe tener capacitado personal de Sistemas de la compañía, para que éste asuma el mantenimiento del sistema, cuando los desarrolladores no puedan atenderlo directamente. Comprar el Sistema de Información. Aunque es la solución más rápida, la mayoría de los paquetes se deben adecuar a las necesidades del área, lo cual dificulta su adquisición y funcionamiento posterior. Es la alternativa más costosa. Lo anterior hace concluir que la mejor alternativa de solución, dada sus ventajas comparativas, es la que trata de desarrollar el sistema por personal interno y es la que se sugiere, para la ejecución del sistema.

Caso de Estudio.

160

CRONOGRAMA DE ACTIVIDADES. Se presenta a consideración el cronograma de las actividades restantes para culminar el proyecto. ACTIVIDAD TIEMPO M1 M2 M3 M4 M5 M6 M7 M8 M9 M0 ANALISIS 2 MESES Sistema actual Requerimientos Sistema propuesto Revisión DISEÑO 3 MESES Diseño Global Diseño Detallado Base de Datos Prototipo Revisión CONSTRUCCION 4 MESES PUESTA EN MARCHA

1 MES

Convenciones : Mn : Número del mes de trabajo. La fecha de comienzo de actividades está planteada para el mes de marzo de 1999. La duración estimada total es de diez meses.

Caso de Estudio.

161

ANALISIS. ANALISIS DEL SISTEMA ACTUAL. OBJETIVOS DEL AREA. Mantener actualizados los saldos de las cuentas bancarias que son propiedad de la empresa. Administrar el manejo de las cajas menores de la compañía. Manejar adecuadamente las diferentes obligaciones financieras que la empresa adquiere con los bancos. Elaborar proyecciones de ingresos y egresos para la Gerencia, con el fin de evaluar el flujo de caja a mediano plazo. Realizar los pagos a los diferentes proveedores de la empresa, generando los cheques de acuerdo con la programación de pagos que envía Cuentas por Pagar. DIAGRAMAS DE FLUJO DE DATOS. DIAGRAMA DE CONTEXTO.


Notas bancarias

Créditos aprobados




Facturas


CAJA Y BANCOS

Y

GERENCIA

BANCOS

CLIENTES

CONTABILIDAD

PROVEEDORES

CUENTAS PORPAGAR

Ingresos y pagos


Cuadre de caja




Recibo de caja

Obligaciones adquiridasIngresos y pagosCheque y orden de pagoPagos realizados

PROVEEDORES

OBLIGACIONES

FINANCIERAS

CUENTAS PORPAGAR

Caso de Estudio.

162

DIAGRAMA GENERAL O DE NIVEL UNO.

BANCOS

CONTABILIDAD

CLIENTES

GERENCIA

MANEJAR CAJA Y BANCOS

1

Consignac. otras plazasConsignaciones locales

Ingresos y pagosPagos realizados

Recibo de caja

Ingresos y pagosCuadre de caja

REALIZAR PROYECCIONES

2

GERENCIA

Polític

as de

finan

ciamien

to

Proye

cción

ingr

esos

y

egre

sos

Ingresos recibidos

Obligaciones a tram

itar

MANEJAR PRESTAMOS

3

BANCOS

GERENCIA

CONTABILIDAD

Créditos aprobados


Obligaciones por

vencimiento

Obligacionesadquiridas

Valor de obligaciones

REALIZAR PAGOS

4

CUENTAS PORPAGAR

PROVEEDOR

Programación pagos

Pagos realiza

dos

Facturas

Cheque y orden de pago

Che

ques

pag

ados

MANEJARNOTAS

BANCARIAS

5

BANCOS

Nota

s ba

ncar

ias

Info

rmac

ión

nota

s

BANCOS

PRESTAMOS

SOLICITUDES

PAGOS

NOTAS

Caso de Estudio.

163

NIVEL 2 : MANEJAR CAJA Y BANCOS.

BANCOS

CONTABILIDADCLIENTES

GERENCIABANCOS

RECIBIR

INGRESOS

APLICAR

EGRESOS

SUMAR

SUMAR

INGRESOS

EGRESOS

CUADRARCAJA

1.1

1.2

1.3

1.4

1.5

Pagos realizados

ELABORAR

CONSIGNACION

1.6

Recibo de caja

Ingresos recibidos

MANEJAR

PRESTAMOS

3

Valor de obligacionesValor egresos

Total ingresos

Totla egre

sos

MANEJARNOTAS

5

BANCARIAS

Notas por ingresos

Notas por egresos

BANCOSConsignaciones

otras plazas

Consignaciones

locales

GERENCIA

GERENCIA

BANCOS

Cuadre de caja

Ingresos

Pagos

CONTABILIDAD

Ingresos

Pagos

REALIZAR

PAGOS

4

Cheques pagados

NIVEL 2 : MANEJAR PRESTAMOS.

Caso de Estudio.

164

BANCOS

CONTABILIDAD

GERENCIA

PRESTAMOSSOLICITUDES

3.2

DILIGENCIARSOLICITUD

3.1

CREAR

OBLIGACION

Crédito aprobadoSolicitud de créditoObligaciones por

vencimiento

Obligacionesadquiridas2

Obligaciones a tramitar

2

REALIZARPROYECCIONES

MANEJAR

CAJA Y BANCOS

1

Valor de obligaciones

NIVEL 2 : REALIZAR PAGOS.

CUENTAS

PAGOS

ORDENARPROGRAMACION

4.1

22


VERIFICAR

VALOR

4.2

GENERARCHEQUES

4.3

POR PAGAR

Programación pagos

Cheques pagados

CUENTASPOR PAGAR

Pagos realizados

PROVEEDORESFacturas

PROVEEDORES


NIVEL 2 : MANEJAR NOTAS BANCARIAS.

Caso de Estudio.

165

NOTAS

22


VERIFICARNOTAS

5.1

BANCOS

APLICAR

NOTAS

5.2

PRESTAMOS

Notas bancarias

Información notas

DICCIONARIO DE DATOS. Se definen a continuación, las diferentes entidades o agentes externos, los almacenamientos de información, procesos y flujos de entrada y salida que conforman el sistema actual. ENTIDADES. NOMBRE : BANCOS. TIPO : FUENTE. SIGNIFICADO : Son las diferentes entidades bancarias con las cuales la empresa tiene negocios, a través de cuentas corrientes y/o préstamos. OBSERVACIONES : NOMBRE : CLIENTES. TIPO : FUENTE. SIGNIFICADO : Son todas las personas y otras empresas, que compran los diferentes productos de la empresa y originan ingresos por compras. OBSERVACIONES : NOMBRE : GERENCIA. TIPO : FUENTE, SUMIDERO. SIGNIFICADO : Es el ente que regula el área de Tesorería. OBSERVACIONES : NOMBRE : CUENTAS POR PAGAR. TIPO : FUENTE, SUMIDERO.

Caso de Estudio.

166

SIGNIFICADO : Es el área encargada de enviar la programación de pagos a la Tesorería. OBSERVACIONES : NOMBRE : PROVEEDORES. TIPO : FUENTE, SUMIDERO. SIGNIFICADO : Empresas que suministran la materia prima para la elaboración de los diferentes productos que la compañía vende. OBSERVACIONES : NOMBRE : CONTABILIDAD. TIPO : SUMIDERO. SIGNIFICADO : Es el área encargada de registrar contablemente las transacciones ocurridas por conceptos de ingresos y egresos. OBSERVACIONES : ALMACENAMIENTOS. NOMBRE : BANCOS. SINONIMO : COMPOSICION : {nombre banco+dirección+{número cuenta+saldo}} OBSERVACIONES : Se almacena la información de cada banco con sus respectivas cuentas. Se tiene carpeta por banco. NOMBRE : NOTAS. SINONIMO : COMPOSICION : {nombre banco+número nota+fecha nota+fecha aplicación+tipo nota+valor nota} OBSERVACIONES : Se lleva información archivada de las notas que envían los bancos, por diferentes conceptos (tipo nota). NOMBRE : PRESTAMOS. SINONIMO : COMPOSICION : {nombre banco+número de préstamo+fecha inicial+fecha final+valor+tasa interés} OBSERVACIONES : Carpetas que contienen los diferentes préstamos que adquiere la empresa. Se lleva carpeta por banco. NOMBRE : SOLICITUDES. SINONIMO : COMPOSICION : {Número solicitud+nombre banco+fecha envío+valor solicitado+estado solicitud} OBSERVACIONES : Se guardan todas las solicitudes enviadas a los bancos, por

Caso de Estudio.

167

conceptos de prestamos. Una vez se conceda éste, se convierte en un préstamo. NOMBRE : PAGOS. SINONIMO : MOVIMIENTOS. COMPOSICION : {[Nombre banco/Nombre proveedor]+Número de cheque+Número de orden de pago+valor} OBSERVACIONES : Es una carpeta donde se archivan los diferentes pagos realizados por la Caja. FLUJOS DE ENTRADA. NOMBRE : Consignaciones otras plazas. SINONIMO : COMPOSICION : Nombre banco+ Fecha+ Número cuenta+ Detalle cheques+Valor efectivo+Nombre cliente+Total consignación OBSERVACIONES : Son las consignaciones que los clientes de otras plazas realizan en los bancos. NOMBRE : Notas Bancarias. SINONIMO : COMPOSICION : Nombre banco+Fecha nota+Tipo nota+Fecha aplicación+Valor OBSERVACIONES : Son las notas de cobro y débito que envían los bancos a la Caja, para actualizar los saldos de las cuentas. NOMBRE : Créditos Aprobados. SINONIMO : COMPOSICION : Nombre banco+Fecha aprobación+Fecha pago+Tasa interés+Períodos de pago+Valor crédito. OBSERVACIONES : Es la información que el banco envía, al aprobar un crédito para la empresa. NOMBRE : Pagos realizados. SINONIMO : COMPOSICION : [Nombre banco/Nombre proveedor]+Concepto pago+Fecha pago+Número cheque+Valor pagado. OBSERVACIONES : Pagos efectuados a los bancos y a los proveedores, por

Caso de Estudio.

168

materia prima y cuotas de préstamos. NOMBRE : Políticas de Financiamiento. SINONIMO : COMPOSICION : Tipo de financiamiento+Valor OBSERVACIONES : Son las diferentes opciones de financiamiento que expide la Gerencia, para que la compañía disponga de fondos. NOMBRE : Programación de Pagos. SINONIMO : COMPOSICION : Fecha de pago+Beneficiario+Valor. OBSERVACIONES : Es la lista de pagos que envía el área de Cuentas por pagar a la Caja, para que se elaboren los cheques y las ordenes de pago. NOMBRE : Facturas. SINONIMO : COMPOSICION : Número factura+Fecha+Beneficiario+Detalle factura+Valor total. OBSERVACIONES : Facturas entregadas por los Proveedores a la Caja, para su posterior pago. FLUJOS DE SALIDA. NOMBRE : Ingresos y Pagos. SINONIMO : COMPOSICION : Fecha ingreso+Valor ingreso+Fecha egreso+Valor egreso+Total ingresos+Total egresos. OBSERVACIONES : Informe diario de ingresos y egresos para la Gerencia. NOMBRE : Obligaciones por vencimiento. SINONIMO : COMPOSICION : Nombre banco+Número obligación+Valor a pagar+Fecha vencimiento. OBSERVACIONES : Listado de obligaciones por fecha de vencimiento para la Gerencia. NOMBRE : Cuadre de Caja. SINONIMO : COMPOSICION : Nombre banco+Número de cuenta+Total entradas+Total salidas+Saldo. OBSERVACIONES : Informe diario del estado de las cuentas.

Caso de Estudio.

169

NOMBRE : Proyección ingresos y egresos. SINONIMO : COMPOSICION : Fecha Proyección+Ingresos proyectados+Egresos proyectados. OBSERVACIONES : Informe de proyecciones de ingresos y egresos, por fecha. NOMBRE : Consignaciones locales. SINONIMO : COMPOSICION : Nombre banco+ Fecha+ Número cuenta+ Detalle cheques+Valor efectivo+Total consignación COMPOSICION : OBSERVACIONES : Consignaciones realizadas por la empresa, en los diferentes bancos. NOMBRE : Solicitud de crédito. SINONIMO : COMPOSICION : Número solicitud+Nombre banco+valor solicitado. OBSERVACIONES : Solicitudes enviadas la los bancos, para obtener los préstamos para la empresa. NOMBRE : Recibo de Caja. SINONIMO : COMPOSICION : Número recibo+Fecha+Nombre cliente+Valor. OBSERVACIONES : Recibo generado por la Caja, al efectuar pagos los clientes de la empresa. NOMBRE : Obligaciones Adquiridas. SINONIMO : COMPOSICION : Nombre banco+Número obligación+Valor obligación. OBSERVACIONES : Informe entregado a Contabilidad, para realizar los asientos contables. NOMBRE : Cheques SINONIMO : COMPOSICION : Nombre banco+Número cheque+Fecha+Beneficiario+Valor. OBSERVACIONES : NOMBRE : Orden de Pago. SINONIMO : COMPOSICION : Número orden de pago+Número cheque+Beneficiario+Número factura a pagar+Valor.

Caso de Estudio.

170

OBSERVACIONES : Documento que se entrega a los Proveedores, al realizar el pago. NOMBRE : Pagos Realizados. SINONIMO : COMPOSICION : Fecha pago+Beneficiario+Valor. OBSERVACIONES : Informe entregado a Cuentas por Pagar, luego de efectuar los pagos correspondientes a la programación. PROCESOS. NOMBRE PROCESO : MANEJAR CAJA Y BANCOS. SIGNIFICADO : Es el área encargada de manejar las transacciones que afectan las cuentas corrientes y las caja de la empresa. ESPECIFICACION : Proceso conformado por : Recibir Ingresos. Aplicar Egresos a las Cuentas. Sumar Ingresos y Egresos. Elaborar Consignaciones. Cuadrar Caja. OBSERVACIONES : NOMBRE PROCESO : REALIZAR PROYECCIONES. SIGNIFICADO : Se realiza allí todo lo que tiene que ver con proyectar en el tiempo los diferentes ingresos y egresos de la empresa. ESPECIFICACION : Proyectar Ingresos. Proyectar Egresos. OBSERVACIONES : NOMBRE PROCESO : MANEJAR PRESTAMOS. SIGNIFICADO : Es el área encargada de administrar todo lo que tiene que ver con las obligaciones financiera de la empresa. ESPECIFICACION : Se compone de : Diligenciar Solicitud de Préstamo.

Caso de Estudio.

171

Crear Obligaciónes Adquiridas. OBSERVACIONES : NOMBRE PROCESO : REALIZAR PAGOS. SIGNIFICADO : Tramita todo lo relacionado con pagos de las obligaciones que se tienen con los bancos y con los proveedores. ESPECIFICACION : Compuesto por : Ordenar Programación de Pagos. Verificar Valores. Generar Cheques. OBSERVACIONES : NOMBRE PROCESO : MANEJAR NOTAS BANCARIAS. SIGNIFICADO : Se encarga de administrar las diferentes notas bancarias que envían las entidades financieras, para el pago de las obligaciones adquiridas. ESPECIFICACION : Conformado por : Verificar Notas. Aplicar Notas. OBSERVACIONES : REQUERIMIENTOS DEL NUEVO SISTEMA. Las necesidades de información planteadas por el área, que debe resolver el nuevo sistema, son : • Disponer de un mecanismo ágil para cuadrar la caja automáticamente. • Poder manejar los ingresos de la caja. • Manejar todos los egresos por concepto de pago a proveedores y a préstamos

bancarios. • Generar automáticamente las consignaciones locales. • Diligenciar en forma automática las diferentes solicitudes de préstamos

enviadas a los bancos. • Permitir el manejo de las obligaciones financieras, en lo que respecta a

creación, modificación, retiro y consultas. • Poder generar proyecciones de ingresos y egresos para la compañía. • Manejar las diferentes notas bancarias, con respecto a creación, modificación,

retiro y consultas.

Caso de Estudio.

172

• Generar automáticamente todos los cheques que se diligencian en la caja, con su respectiva orden de pago.

• Disponer de nuevas herramientas que permitan consultar datos en forma ágil.

Caso de Estudio.

173

ANALISIS DEL SISTEMA PROPUESTO. Se mostrará a continuación las diferentes especificaciones de lo que será el sistema propuesto de caja y bancos y obligaciones financieras, a nivel de procesos y datos. Se pretende que dicho modelo satisfaga las necesidades de información planteadas, además de los objetivos expuestos inicialmente y sirva como una base sólida para la elaboración del diseño del sistema. MODELO DE PROCESOS. DIAGRAMA DE FLUJO DE DATOS SISTEMA PROPUESTO. DIAGRAMA DE CONTEXTO.


Notas bancarias

Créditos aprobados




Facturas


CAJA Y BANCOS

Y

GERENCIA

BANCOS

CLIENTES

CONTABILIDAD

PROVEEDORES

CUENTAS PORPAGAR

Ingresos y pagos


Cuadre de caja




Recibo de caja

Cheque y orden de pagoPagos realizadosPROVEEDORES

OBLIGACIONES

FINANCIERAS

CUENTAS PORPAGAR

Asientos contables

Caso de Estudio.

174

DIAGRAMA GENERAL (NIVEL 1).

BANCOS

CONTABILIDAD

CLIENTES

GERENCIA

MANEJAR CAJA Y BANCOS

1

Consignac. otras plazasConsignaciones localesAsientos contables

Pagos realizados

Recibo de caja

Ingresos y pagosCuadre de caja

REALIZAR PROYECCIONES

2

GERENCIA

Polític

as de

finan

ciamien

to

Proye

cción

ingr

esos

y

egre

sos

MANEJAR PRESTAMOS

3

BANCOS

GERENCIA

CONTABILIDAD

Créditos aprobados


Obligaciones por

vencimiento

REALIZAR PAGOS

4

CUENTAS PORPAGAR

PROVEEDOR

Programación pagos

Pagos realiza

dos

Facturas


MANEJARNOTAS

BANCARIAS

5

BANCOS

Nota

s ba

ncar

ias

BANCOS

SOLICITUDES

PAGOS

NOTAS

Asientos contables

CUENTAS

DETALL PRESTAMOS

DETALL NOTAS

PROYECCIONESPRESTAMOS

Caso de Estudio.

175

NIVEL 2 : MANEJAR CAJA Y BANCOS.

BANCOS

CONTABILIDAD

CLIENTES

GERENCIACUENTAS

RECIBIR

INGRESOS

APLICAR

EGRESOS

MANEJAR CUENTAS

CUADRARCAJA

1.1

1.3

1.2

1.4

Pagos realizados

ELABORAR

CONSIGNACION

1.5

Recibo de caja

BANCOSConsignaciones

otras plazas

Consignaciones

locales

GERENCIA

GERENCIA

BANCOS

Cuadre de caja

Pagos

IngresosAsientos contables

BANCOS

PRESTAMOS

NOTAS

PAGOS

NIVEL 2 : REALIZAR PROYECCIONES.

GERENCIA

CUENTAS

2.1 2.2

GERENCIA

PRESTAMOS

PROYECTAR

INGRESOS

PROYECTAR

EGRESOS

Políticas de finaciamiento DETALL PRESTAMOS

PROYECCIONES

Políticas de financiamiento

Proyección de egresos Proyección de ingresos

NIVEL 2 : MANEJAR PRESTAMOS.

Caso de Estudio.

176

GERENCIA

3.23.1

CONTABILIDAD

PRESTAMOSCREAR

OBLIGACIONES

DILIGENCIAR

SOLICITUDDETALL PRESTAMOS

SOLICITUDES

3.3

MODIFICAR

OBLIGACIONES

3.4

RETIRAR

OBLIGACIONES

PRESTAMOS

DETALL PRESTAMOS

PRESTAMOS

DETALL PRESTAMOS

BANCOS


Créditos aprobados

3.5

CONSULTAR

OBLIGACIONES Obligaciones por vencimiento

Asientos contables

NIVEL 2 : REALIZAR PAGOS.

Caso de Estudio.

177

4.24.1

GENERAR

ORDEN DE PAGO

ORDENAR

PROGRAMACION

PAGOS

4.3

IMPRIMIR

CHEQUES

PROVEEDORES

CUENTAS

POR PAGAR


Facturas

PROVEEDORES

CUENTAS

POR PAGAR

Pagos realizados

Cheque

Orden de pago

NIVEL 2 : MANEJAR NOTAS BANCARIAS.

5.1

NOTASCREAR

NOTAS

DETALL NOTAS

5.2

MODIFICAR

NOTAS

5.3

RETIRAR

NOTAS

BANCOS

Notas b

anca

rias PRESTAMOS

NOTAS

DETALL NOTAS

NOTAS

DETALL NOTAS

Notas bancarias

Notas bancarias

NIVEL 3 MANEJAR CUENTAS.

Caso de Estudio.

178

1.2.1

BANCOSCREAR

CUENTAS

CUENTAS

1.2.2

MODIFICAR

CUENTAS

1.2.3

RETIRAR

CUENTAS

BANCOS

CUENTAS

BANCOS

CUENTAS

Caso de Estudio.

179

LISTA DE EVENTOS. Los eventos a los cuales debe responder el sistema propuesto son los siguientes : • El cliente realiza un pago. • El banco envía las consignaciones de otras plazas. • El gerente emite nuevas políticas de financiamiento. • El banco aprueba un crédito. • Tesorería emite una solicitud de crédito. • El banco envía notas bancarias. • Se crean nuevas cuentas corrientes. • Se retiran cuentas corrientes existentes. • Tesorería genera consignaciones. • Tesorería paga proveedores.

Caso de Estudio.

180

DICCIONARIO DE DATOS SISTEMA PROPUESTO. Para la definición del diccionario del sistema propuesto, sólo se tendrán en cuenta aquellos términos nuevos a nivel de flujos de datos y almacenamientos. Se definen los diferentes procesos, a nivel de especificaciones de proceso o miniespecificaciones. Los demás ítems definidos en el diccionario de datos del sistema actual, tienen vigencia bajo el sistema propuesto. FLUJOS DE SALIDA. NOMBRE : Asientos Contables. SINONIMO : COMPOSICION : Cuentas débito+cuentas crédito+fecha+comprobante+valores. OBSERVACIONES : Son los diferentes asientos contables que se generan en forma automática, por cada transacción realizada en el sistema. ALMACENAMIENTOS. NOMBRE : CUENTAS. SINONIMO : COMPOSICION : {nombre banco+número cuenta+saldo anterior+saldo actual}. OBSERVACIONES : Son las diferentes cuentas corrientes de que dispone la empresa, en los diferentes bancos de la ciudad. NOMBRE : DETALLE PRESTAMOS. SINONIMO : COMPOSICION : {nombre banco+número prestamo+{fecha pago interés+fecha pago capital+valor}} OBSERVACIONES : Contiene la programación teórica de pago de los diferentes préstamos. NOMBRE : DETALLE NOTAS. SINONIMO : COMPOSICION : {nombre banco+número nota+fecha+{conceptos de pago+valor concepto}}. OBSERVACIONES : Es el detalle de conceptos que se cobran en las notas enviadas por los Bancos. PROCESOS.

Caso de Estudio.

181

NOMBRE PROCESO : MANEJAR CAJA Y BANCOS. SIGNIFICADO : Es el área encargada de manejar las transacciones que afectan las cuentas corrientes y las caja de la empresa. ESPECIFICACION : LEER OPCIONES CAJA Y BANCOS MIENTRAS EXISTAN OPCIONES CASO OPCION INGRESOS LLAMAR RECIBIR INGRESOS CASO OPCION CUENTAS LLAMAR MANEJAR CUENTAS CASO OPCION EGRESOS LLAMAR APLICAR EGRESOS CASO OPCION CONSIGNACIONES LLAMAR ELABORAR CONSIGNACION OTRO CASO ERROR FINCASOS LEER OPCIONES FIN MIENTRAS OBSERVACIONES : NOMBRE PROCESO : REALIZAR PROYECCIONES. SIGNIFICADO : Se realiza allí todo lo que tiene que ver con proyectar en el tiempo los diferentes ingresos y egresos de la empresa. ESPECIFICACION : LEER PRESTAMOS LEER DETALLE PRESTAMOS LEER CUENTAS PROYECTAR INGRESOS PROYECTAR EGRESOS GRABAR PROYECCIONES GENERAR INFORMES PROYECCIONES OBSERVACIONES : NOMBRE PROCESO : MANEJAR PRESTAMOS.

Caso de Estudio.

182

SIGNIFICADO : Es el área encargada de administrar todo lo que tiene que ver con las obligaciones financiera de la empresa. ESPECIFICACION : LEER OPCIONES MANEJAR PRESTAMOS MIENTRAS EXISTAN OPCIONES CASO OPCION CREAR LLAMAR CREAR OBLIGACIONES CASO OPCION MODIFICAR LLAMAR MODIFICAR OBLIGACIONES CASO OPCION RETIRAR LLAMAR RETIRAR OBLIGACIONES CASO OPCION CONSULTAR LLAMAR CONSULTAR OBLIGACIONES OTRO CASO ERROR FINCASOS LEER OPCIONES FIN MIENTRAS OBSERVACIONES : NOMBRE PROCESO : REALIZAR PAGOS. SIGNIFICADO : Tramita todo lo relacionado con pagos de las obligaciones que se tienen con los bancos y con los proveedores. ESPECIFICACION : LEER PROGRAMACION DE PAGOS LEER FACTURAS ORDENAR PROGRAMACION GENERAR ORDENES DE PAGO IMPRIMIR CHEQUES GRABAR PAGOS OBSERVACIONES : NOMBRE PROCESO : MANEJAR NOTAS BANCARIAS.

Caso de Estudio.

183

SIGNIFICADO : Se encarga de administrar las diferentes notas bancarias que envían las entidades financieras, para el pago de las obligaciones adquiridas. ESPECIFICACION : LEER OPCIONES MANEJAR NOTAS MIENTRAS EXISTAN OPCIONES CASO OPCION CREAR LLAMAR CREAR NOTAS CASO OPCION MODIFICAR LLAMAR MODIFICAR NOTAS CASO OPCION RETIRAR LLAMAR RETIRAR NOTAS OTRO CASO ERROR FINCASOS LEER OPCIONES FIN MIENTRAS OBSERVACIONES : MODELO DE DATOS.

Caso de Estudio.

184

DIAGRAMA DE ESTRUCTURA DE DATOS.

DEFINICION DE ENTIDADES.

Caso de Estudio.

185

Ver diccionario de datos, definición de almacenamientos. (tanto el diccionario del sistema actual, como el propuesto). MATRICES DE ENTIDAD. EVENTO/ENTIDAD. EVENTO/ENTIDAD BANCO CTAS MVTO NOTAS DET.

NOTAS PREST DET.

PREST SOLIC.

El cliente realiza un pago.

R CR

El banco envía consignaciones de otras plazas.

R CR

El gerente emite nuevas políticas de financiamiento

CR

El banco aprueba un crédito.

R R CR CR CR RD

Tesorería emite una solicitud de crédito.

C

El banco envía notas bancarias.

R R CR CR CR RU RU

Se crean nuevas cuentas corrientes.

R CR CR

Se retiran cuentas corrientes existentes.

R RD RD

Tesorería genera consignaciones.

R CR

Tesorería paga proveedores.

CR CR

AUTORIZACION USUARIO/ENTIDAD.

Caso de Estudio.

186

EVENTO/ENTIDAD BANCO CTAS MVTO NOTAS DET. NOTAS

PREST DET. PREST

SOLIC.

Cajero. CRUD CRUD CRUD R R R R Analista Proyección R R R R R R Auxiliar Cajero. R R CRUD R R CR Gerente. R R R R R CRUD Analista Prestamos. CRUD CRUD CRUD CRUD RUD

Caso de Estudio.

187

DISEÑO. DISEÑO GLOBAL. La estructura que se presenta a continuación pretende soportar completamente el funcionamiento del nuevo sistema, a través de los diferentes módulos identificados en ella. Se definió y se refinó a la luz de los diferentes diagramas de flujo de datos generados en el análisis del sistema propuesto y los conceptos de cohesión y acople del diseño estructurado.

Caso de Estudio.

188

DISEÑO DETALLADO.

Caso de Estudio.

189

Con base en la estructura planteada, se detallan los diferentes módulos del sistema en forma de seudocódigo, con miras a facilitar la tarea de construcción de los mismos. Dichos módulos son : CAJA Y BANCOS Y OBLIGACIONES LEER OPCION MIENTRAS OPCION SELECCIONADA CASO OPCION = CAJA Y BANCOS LLAMAR CAJA Y BANCOS CASO OPCION = PROYECCIONES LLAMAR PROYECCIONES CASO OPCION = PRESTAMOS LLAMAR PRESTAMOS CASO OPCION = NOTAS BANCARIAS LLAMAR NOTAS BANCARIAS OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS CAJA Y BANCOS LEER OPCION MIENTRAS OPCION SELECCIONADA CASO OPCION = INGRESOS LLAMAR INGRESOS CASO OPCION = EGRESOS LLAMAR EGRESOS CASO OPCION = CONSIGNACIONES LLAMAR CONSIGNACIONES CASO OPCION = CUADRAR CAJA LLAMAR CUADRAR CAJA CASO OPCION = CUENTAS CORRIENTES LLAMAR CUENTAS CORRIENTES OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS PROYECCIONES LEER OPCION

Caso de Estudio.

190

MIENTRAS OPCION SELECCIONADA CASO OPCION = PROYECTAR INGRESOS LLAMAR PROYECTAR INGRESOS CASO OPCION = PROYECTAR EGRESOS LLAMAR PROYECTAR EGRESOS OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS PRESTAMOS LEER OPCION MIENTRAS OPCION SELECCIONADA CASO OPCION = CREAR PRESTAMOS LLAMAR CREAR PRESTAMOS CASO OPCION = MODIFICAR PRESTAMOS LLAMAR MODIFICAR PRESTAMOS CASO OPCION = RETIRAR PRESTAMOS LLAMAR RETIRAR PRESTAMOS CASO OPCION = CONSULTAR PRESTAMOS LLAMAR CONSULTAR PRESTAMOS OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS NOTAS BANCARIAS LEER OPCION MIENTRAS OPCION SELECCIONADA CASO OPCION = CREAR NOTAS LLAMAR CREAR NOTAS CASO OPCION = MODIFICAR NOTAS LLAMAR MODIFICAR NOTAS CASO OPCION = RETIRAR NOTAS LLAMAR RETIRAR NOTAS OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS INGRESOS LEER INFORMACION INGRESOS

Caso de Estudio.

191

MIENTRAS EXISTA INFORMACION INGRESOS CASO ES POR PRESTAMO LEER PRESTAMOS(COD PRESTAMO) LEER CUENTAS(COD CUENTA) GRABAR VALOR PRESTAMO CASO ES POR PAGO CLIENTES LEER CUENTAS(COD CUENTA) GRABAR VALOR PAGO GENERAR RECIBO DE CAJA CASO ES POR CONSIGNACIONES LEER CUENTAS(COD CUENTA) GRABAR VALOR PAGO

OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS

LEER INFORMACION INGRESOS FIN MIENTRAS EGRESOS LEER INFORMACION EGRESOS MIENTRAS EXISTA INFORMACION EGRESOS CASO ES POR PRESTAMOS LEER CUENTAS(COD CUENTA) GRABAR VALOR PAGADO CASO ES POR CUENTAS POR PAGAR LEER PAGOS GENERAR ORDEN DE PAGO GENERAR CHEQUES LEER CUENTAS(CDOD CUENTA) GRABAR VALOR PAGADO OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER INFORMACION EGRESOS FIN MIENTRAS CONSIGNACIONES LEER CUENTAS(COD CUENTA) SUMAR EFECTIVO SUMAR CHEQUES GENERAR CONSIGNACION GRABAR CUENTAS(COD CUENTA) CUADRAR CAJA LEER CUENTAS

Caso de Estudio.

192

MIENTRAS EXISTAN CUENTAS SUMAR INGRESOS POR CUENTA SUMAR EGRESOS POR CUENTA TOTALIZAR CUENTA LEER CUENTAS FIN MIENTRAS GENERAR INFORME CUADRE DE CAJA CUENTAS CORRIENTES LEER OPCION MIENTRAS OPCION SELECCIONADA CASO OPCION = CREAR CUENTAS LLAMAR CREAR CUENTAS CASO OPCION = MODIFICAR CUENTAS LLAMAR MODIFICAR CUENTAS CASO OPCION = RETIRAR CUENTAS LLAMAR RETIRAR CUENTAS OTRO CASO ERROR ‘OPCION NO VALIDA’ FINCASOS LEER OPCION FIN MIENTRAS CREAR CUENTAS LEER INFORMACION CUENTAS MIENTRAS EXISTA INFORMACION CUENTAS LEER BANCOS(COD BANCO) SI BANCO EXISTE ENTONCES LEER CUENTAS(COD BANCO+CON CUENTA) SI CUENTAS EXISTE ENTONCES MENSAJE ‘ERROR CUENTA EXISTE’ SINO GRABAR CUENTAS(COD BANCO+COD CUENTA) FIN SINO ERROR ’BANCO NO EXISTE’ FIN LEER INFORMACION CUENTAS FIN MIENTRAS MODIFICAR CUENTAS LEER INFORMACION CUENTAS

Caso de Estudio.

193

MIENTRAS EXISTA INFORMACION CUENTAS LEER CUENTAS(COD BANCO+CON CUENTA) SI CUENTAS EXISTE ENTONCES GRABAR CUENTAS(COD BANCO+COD CUENTA) SINO

MENSAJE ‘ERROR CUENTA NO EXISTE’ FIN LEER INFORMACION CUENTAS FIN MIENTRAS RETIRAR CUENTAS LEER INFORMACION CUENTAS MIENTRAS EXISTA INFORMACION CUENTAS LEER CUENTAS(COD BANCO+CON CUENTA) SI CUENTAS EXISTE ENTONCES BORRAR CUENTAS(COD BANCO+COD CUENTA) SINO

MENSAJE ‘ERROR CUENTA NO EXISTE’ FIN LEER INFORMACION CUENTAS FIN MIENTRAS PROYECTAR INGRESOS LEER PRESTAMOS MIENTRAS EXISTA PRESTAMOS LEER DETALLE PRESTAMOS(COD PRESTAMO) SUMAR VALOR PRESTAMOS LEER PRESTAMOS INGRESOS FIN MIENTRAS LEER CUENTAS MIENTRAS EXISTA CUENTAS SUMAR VALOR INGRESOS LEER CUENTAS FIN MIENTRAS GRABAR PROYECCIONES PROYECTAR EGRESOS LEER PRESTAMOS

Caso de Estudio.

194

MIENTRAS EXISTA PRESTAMOS LEER DETALLE PRESTAMOS(COD PRESTAMO) SUMAR VALOR PRESTAMOS EGRESOS LEER PRESTAMOS FIN MIENTRAS LEER CUENTAS MIENTRAS EXISTA CUENTAS SUMAR VALOR EGRESOS LEER CUENTAS FIN MIENTRAS GRABAR PROYECCIONES CREAR PRESTAMOS LEER INFORMACION PRESTAMOS MIENTRAS EXISTA INFORMACION PRESTAMOS LEER PRESTAMOS(COD PRESTAMO) SI PRESTAMO EXISTE ENTONCES

MENSAJE ‘ERROR PRESTAMO EXISTE’ SINO

GRABAR PRESTAMOS(COD PRESTAMO) GRABAR DETALL PRESTAMOS FIN LEER INFORMACION PRESTAMOS FIN MIENTRAS MODIFICAR PRESTAMOS LEER INFORMACION PRESTAMOS MIENTRAS EXISTA INFORMACION PRESTAMOS LEER PRESTAMOS(COD PRESTAMO) SI PRESTAMO EXISTE ENTONCES GRABAR PRESTAMOS(COD PRESTAMO) GRABAR DETALL PRESTAMOS SINO

MENSAJE ‘ERROR PRESTAMO NO EXISTE’ FIN LEER INFORMACION PRESTAMOS FIN MIENTRAS RETIRAR PRESTAMOS LEER INFORMACION PRESTAMOS MIENTRAS EXISTA INFORMACION PRESTAMOS

Caso de Estudio.

195

LEER PRESTAMOS(COD PRESTAMO) SI PRESTAMO EXISTE ENTONCES BORRAR PRESTAMOS(COD PRESTAMO) BORRAR DETALL PRESTAMOS SINO

MENSAJE ‘ERROR PRESTAMO NO EXISTE’ FIN LEER INFORMACION PRESTAMOS FIN MIENTRAS CONSULTAR PRESTAMOS LEER PRESTAMOS MIENTRAS EXISTA PRESTAMOS LEER DETALL PRESTAMOS SUMAR VALORES POR PRESTAMO IMPRIMIR VALORES POR PRESTAMO LEER PRESTAMOS FIN MIENTRAS CREAR NOTAS LEER INFORMACION NOTAS MIENTRAS EXISTA INFORMACION NOTAS LEER NOTAS(COD NOTA) SI NOTAS EXISTE ENTONCES

MENSAJE ‘ERROR NOTA EXISTE’ SINO

GRABAR NOTAS(COD NOTA) GRABAR DETALL NOTAS FIN LEER INFORMACION NOTAS FIN MIENTRAS MODIFICAR NOTAS LEER INFORMACION NOTAS MIENTRAS EXISTA INFORMACION NOTAS LEER NOTAS(COD NOTA)

Caso de Estudio.

196

SI NOTAS EXISTE ENTONCES

GRABAR NOTAS(COD NOTA) GRABAR DETALL NOTAS

SINO MENSAJE ‘ERROR NOTA NO EXISTE’

FIN LEER INFORMACION NOTAS FIN MIENTRAS RETIRAR NOTAS LEER INFORMACION NOTAS MIENTRAS EXISTA INFORMACION NOTAS LEER NOTAS(COD NOTA) SI NOTAS EXISTE ENTONCES

BORRAR NOTAS(COD NOTA) BORRAR DETALL NOTAS

SINO MENSAJE ‘ERROR NOTA NO EXISTE’

FIN LEER INFORMACION NOTAS FIN MIENTRAS

Caso de Estudio.

197

DISEÑO DE BASES DE DATOS. Como se definió anteriormente en el análisis del sistema propuesto, el modelo de datos allí consignado con sus definiciones de entidades y atributos, se ajusta completamente a las necesidades planteadas en el diseño que se propone. Para más detalle, vea análisis del sistema propuesto, modelo de datos y diccionario de datos, en lo que atañe a almacenamientos. DISEÑO DE ENTRADAS Y SALIDAS. PANTALLAS. A continuación se presentan los diferentes tipos de diseño estándar de ventanas que serán usadas en la construcción posterior del sistema. Ventana Menú.

Caso de Estudio.

198

Ventana de Entrada, Modificación, Retiro, Consulta Simple de Datos.

Ventana de Entrada, Modificación, Retiro, Consulta Simple, OPCION 2.

Ventana de Respuesta.

Caso de Estudio.

199

Para proyecciones de Ingresos y Egresos, Consignaciones, Cuadre de Caja y Consultas.

Ventana de Consultas.

Bibliografía.

200

8. Bibliografía. • Pressman, Roger. Ingeniería del Software un enfoque práctico, 3 edición,

España, McGraw Hill, 1994. • Senn, James A. Análisis y diseño de sistemas de información. México, McGraw

Hill, 1987. • Ruble, David A. Análisis y diseño práctico de sistemas cliente/servidor con GUI.

México, Prentice Hall, 1998. • Price Waterhouse. Metodología de desarrollo SMM/SD, 1984. • Universidad EAFIT. Análisis y diseño de sistemas de información. 1989.

HERRAMIENT

AS

1. INTRODUCCIÓN 6 1.1 SISTEMA. 7 … · introducción. 1 tabla de contenido 1. introducciÓn 6 1.1...

Documents

Transcript of 1. INTRODUCCIÓN 6 1.1 SISTEMA. 7 … · introducción. 1 tabla de contenido 1. introducciÓn 6 1.1...