tabla de contenido

TABLA DE CONTENIDO
1.
INTRODUCCIÓN
6
1.1 SISTEMA.
1.2 LA ORGANIZACIÓN.
1.3 ENFOQUE DE SISTEMAS.
1.4 SISTEMAS DE INFORMACION.
1.4.1 DEFINICIONES.
1.4.2 ELEMENTOS.
1.4.3 PAPEL DE LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES.
1.4.4 ADMINISTRACIÓN DE SISTEMAS DE INFORMACIÓN.
1.5 CONSIDERACIONES DE SOFTWARE.
1.5.1 DEFINICION.
1.5.2 EVOLUCION.
1.5.3 CRISIS DEL SOFTWARE.
1.5.4 FACTORES CRITICOS DE ÉXITO EN EL DESARROLLO DE SISTEMAS DE
INFORMACION.
1.6 CICLO DE VIDA DE UN SISTEMA DE INFORMACION (S.I.B.T.I.C).
1.6.1 PREANÁLISIS O ANTEPROYECTO.
1.6.2 ANÁLISIS.
1.6.3 DISEÑO.
1.6.4 CONSTRUCCION.
1.6.5 PRUEBAS.
1.6.6 IMPLEMENTACION. (PUESTA EN MARCHA DEL SISTEMA).
7
7
8
9
9
10
12
14
15
15
15
16
2.
19
EL PROCESO DE DESARROLLO DEL SOFTWARE
2.1 LA INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA
2.2 EL PROCESO DEL SOFTWARE
2.2.1 MODELOS DE DESARROLLO DEL SOFTWARE
2.2.1.1 MODELO LINEAL SECUENCIAL
2.2.1.2 MODELO EN CASCADA.
2.2.2 METODOLOGIA POR FASES.
2.2.3 MODELO DE CONSTRUCCION DE PROTOTIPOS
2.2.4 MODELO DESARROLLO RÁPIDO DE APLICACIONES.
2.2.5 MODELOS EVOLUTIVOS EN PROCESO DEL SOFTWARE
2.2.5.1 MODELO EN ESPIRAL
2.2.5.2 MODELO EN ESPIRAL WIN WIN
2.2.5.3 MODELO INCREMENTAL
2.2.5.4 MODELO DE DESARROLLO CONCURRENTE
2.2.6 DESARROLLO BASADO EN COMPONENTES
2.2.7 MODELO DE MÉTODOS FORMALES
2.2.8 TÉCNICAS DE CUARTA GENERACIÓN
Introducción.
16
17
18
18
18
18
18
18
20
22
22
24
26
27
28
28
30
30
31
31
32
32
32
32
1
3.
ANTEPROYECTO O PREANÁLISIS.
37
3.1 CONSIDERACIONES GENERALES.
3.1.1 OBJETIVOS.
3.1.2 DEFINICION.
3.2 IMPORTANCIA DEL ESTUDIO DE FACTIBILIDAD.
3.3 CARACTERISTICAS DEL ESTUDIO DE FACTIBILIDAD.
3.4 TALENTO HUMANO NECESARIOS.
3.5 PASOS EN EL DESARROLLO DEL ESTUDIO DE FACTIBILIDAD.
3.5.1 RECONOCIMIENTO GENERAL DEL SISTEMA.
3.5.1.1 Ubicación General.
3.5.1.2 Delimitación o Alcance del Sistema.
3.5.2 OBJETIVOS DEL SISTEMA.
3.5.3 DEFINICION DEL SISTEMA.
3.5.4 RECURSOS PARA EL DESARROLLO DEL NUEVO SISTEMA.
3.5.4.1 Recursos Económicos.
3.5.4.2 Recursos de Personal.
3.5.4.3 Recursos Técnicos.
3.5.5 ESTIMATIVOS DE DESARROLLO DEL SISTEMA.
3.5.6 ANALISIS DE FACTIBILIDAD DEL SISTEMA.
3.5.6.1 Factibilidad Financiera.
3.5.6.2 Factibilidad Técnica.
3.5.6.3 Factibilidad Operativa.
3.5.7 ALTERNATIVAS Y RECOMENDACIONES.
3.5.8 CRONOGRAMA DE ACTIVIDADES.
3.5.9 DECISION FINAL.
3.6 RESUMEN.
37
37
37
38
38
39
39
40
40
41
41
43
44
44
44
44
45
45
45
50
50
51
51
54
55
4.
56
ANALISIS.
4.1 CONSIDERACIONES GENERALES.
4.1.1 OBJETIVOS.
4.1.2 DEFINICION.
4.2 IMPORTANCIA DEL ANALISIS.
4.3 CARACTERISTICAS DEL ANALISIS.
4.4 PARTICIPACION REQUERIDA.
4.5 PASOS EN EL DESARROLLO DEL ANALISIS.
4.5.1 ANALISIS DEL SISTEMA ACTUAL.
4.5.2 ANALISIS REQUERIMIENTOS DEL NUEVO SISTEMA.
4.5.3 REVALUACION DEL PREANALISIS.
4.5.4 DESARROLLO DE LAS ESPECIFICACIONES DEL SISTEMA PROPUESTO.
4.5.5 REVISION DEL ANALISIS.
4.5.6 ENTREGA A LA ETAPA DE DISEÑO.
4.6 METODOLOGIAS DE ANALISIS.
4.6.1 METODOLOGIAS TRADICIONALES.
4.6.2 METODOLOGIAS ESTRUCTURADAS.
4.7 ANALISIS ESTRUCTURADO.
4.7.1 CONCEPTOS GENERALES.
4.7.1.1 DEFINICION.
Introducción.
56
57
60
62
62
62
63
64
64
65
65
66
67
67
67
67
68
76
76
2
4.7.1.2 CARACTERISTICAS.
4.7.2 COMPONENTES.
4.8 MODELO DE PROCESOS.
4.8.1 PROPOSITO.
4.8.2 DIAGRAMAS DE FLUJOS DE DATOS. (DFD).
4.8.2.1 FLUJOS DE DATOS.
4.8.2.2 PROCESOS O TRANSFORMACIONES.
4.8.2.3 ALMACENAMIENTOS.
4.8.2.4 TERMINALES, ENTIDADES O AGENTES EXTERNOS.
4.8.2.5 COMO CONSTRUIR UN DIAGRAMA DE FLUJO DE DATOS.
4.8.2.6 NIVELACION.
4.8.2.7 BALANCEO.
4.8.2.8 CONVENCIONES NUMERICAS.
4.8.2.9 OTROS ASPECTOS.
4.8.3 DICCIONARIO DE DATOS (DD).
4.8.3.1 FUENTES Y SUMIDEROS.
4.8.3.2 PROCESOS.
4.8.3.3 ALMACENAMIENTOS.
4.8.3.4 FLUJO DE DATOS.
4.8.3.5 COMPONENTE DE DATOS.
4.8.3.6 ELEMENTO DE DATOS.
4.8.3.7 CONVENCIONES PARA EL DICCIONARIO.
4.8.4 EVENTOS.
4.8.4.1 PROPOSITO.
4.8.4.2 DEFINICION.
4.8.4.3 LISTADO DE EVENTOS.
4.8.4.4 DICCIONARIO DE EVENTOS.
4.8.4.5 MATRICES DE EVENTOS.
4.8.4.6 DESCUBRIMIENTO DE EVENTOS.
4.8.4.7 TIPOS DE EVENTOS.
4.8.4.8 ORGANIZACIÓN DE LA LISTA DE EVENTOS.
4.8.4.9 NIVELACION DE EVENTOS.
4.9 MODELO DE INFORMACION.
4.9.1 PROPOSITO.
4.9.2 ENTIDADES.
4.9.3 RELACIONES.
4.9.4 CARDINALIDAD.
4.9.5 ATRIBUTOS.
4.9.6 TIPOS DE ENTIDADES.
4.9.6.1 ENTIDAD ATRIBUTIVA.
4.9.6.2 ENTIDAD ASOCIATIVA.
4.9.7 DEFINICION DE ATRIBUTOS.
4.9.8 MATRICES DE ENTIDAD.
4.9.8.1 CRUD EVENTO/ENTIDAD.
4.9.8.2 MATRIZ EVENTO/UBICACIÓN DEL NEGOCIO.
4.9.8.3 CRUD UBICACIÓN/ENTIDAD.
4.9.8.4 MATRIZ AUTORIZACION USUARIO/ENTIDAD.
4.9.9 ALGUNOS EJEMPLOS DE MODELOS DE INFORMACION :
4.10 ESPECIFICACIONES DE PROCESO (MINIESPECIFICACIONES).
4.10.1 ASPECTOS A TENER EN CUENTA.
Introducción.
77
77
78
79
79
79
79
80
80
81
82
83
84
84
85
85
86
86
87
87
88
88
88
88
89
90
90
93
94
94
96
97
99
99
100
101
101
102
106
106
107
108
109
109
109
110
110
111
112
112
3
4.10.2 FORMAS DE DESCRIBIR MINIESPECIFICACIONES.
4.10.2.1 ESPAÑOL ESTRUCTURADO.
4.10.2.2 CONVENCIONES.
4.11 RESUMEN.
112
112
113
115
5.
116
DISEÑO.
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.
4
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.
5
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.
6
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.
7
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.
8
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.
9
•
•
Un Sistema de Información es un sistema integrado usuariomá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.
10
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.
11
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
ORGANIZACIONES.
LOS
SISTEMAS
DE
INFORMACIÓN
EN
LAS
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.
12
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.
13
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.
14
• 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.
15
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.
16
• 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.
17
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.
18
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.
19
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).
HERRAMIENTAS
METODOS
PROCESO
UN ENFOQUE DE CALIDAD
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:
Introducción.
20
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.
21
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.
22
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.
23
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 de
sistemas/información
Análisis
Diseño
Código
Prueba
Ingeniería y modelado de Sistemas/Información
Introducción.
24
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.
25
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.
26
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.
27
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.
28
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.
29
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.
2.
3.
4.
Motivar la actividad pretendida.
Ser completa.
Ser modificable en su corrección.
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.
30
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.
Ingeniería de
Sistemas/información
Análisis
Incremento 2
Diseño
Código
Prueba
Análisis
Diseño
Código
Análisis
Diseño
Entrega del
1°. incremento
Prueba
Código
Entrega del
2°. incremento
Prueba
Incremento 3
3°. incremento
Incremento 4
Introducción.
Entrega del
Análisis
Diseño
Código
Prueba
Entrega del
4°. incremento
31
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.
32
ESQUEMA DEL PROYECTO
T
Planeación
A
A’
Z
Ejecución
Real
+1
B
D
E
A
B Duración del desarrollo del proyecto
A’ B Ejecución real del proyecto (Ciclo de vida del desarrollo)
A
A’ Planeación
B
D Ciclo de vida Útil (proyecto en operación por parte del usuario)
En B muere el desarrollo del proyecto.
ESTUDIO DE FACTIBILIDAD
PLANEACION
A’
A
OPORTUNIDAD
SECTOR
Y ENTORNO
MERCADO
TÉCNICO
PREFACTIBILIDAD
SECTOR
Y ENTORNO
MERCADO
TÉCNICO
FACTIBILIDAD
SECTOR
Y ENTORNO
MERCADO
FINANCIERO
FINANCIERO
FINANCIERO
ECONOMICA
ECONOMICA
ECONOMICA
SOCIAL
SOCIAL
SOCIAL
D
D
D
PRIMA
SUPUESTOS
PRIMA
FTE SECUNDARIA
TÉCNICO
PRIMA
FTE PRIMARIA
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.
33
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.
34
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.
35
Introducción.
36
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
37
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
38
• 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
39
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
40
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
41
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
42
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
43
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
44
Software de aplicación,
desarrollo mixto.
software existente en el mercado, desarrollo interno,
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
Anteproyecto
REDUCCIÓN MENSUAL
TIEMPO DE CICLO
DE OPERACIÓN
REDUCCIÓN
TOTAL
45
Papelería
$ 100.000
36(3 Años)
$3’600.000
Se deben mirar aspectos como:
Reducción de personal,
disminución de costos, etc.
mayores
ventas,
mayor
rentabilidad
financiera,
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
46
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
Recurso
Diana Patricia Zuluaga
Diego Paniagua Zapata
Danny Hersain Gomez
PHP 4+
MySQL
Papelería
Internet
Computador
Transporte
Asesor
Total
Totales Recursos Administrativos
Concepto
Recurso Humano
Lenguaje de programación
Gestor de Base de Datos
Material y suministros
Material y suministros
Alquiler de equipos
Transporte
Asesor de Proyectos
Sub Total
6.300,000
0,000
0,000
116,004
90,006
195,000
2.520,000
840,000
10.061,010
PERSONAL:
!"
Anteproyecto
#
47
$
!%
'
(
'
%
&
#
"
' )#
* ! #
"
"
)
+
,+
-
%
•
.
.
./ 011'
*'
234'
31"5
'
'
&"
6 78
3
9
$
% *:'
,+
•
; <=
• ' >
;
!
)
?
-
<
A
!
@
6
,
B
CDE
711122
6
,
6 -
Anteproyecto
,
A
6
#
48
COSTOS
)
*
!
+
,
-
.
!
!
,
!
" '/0&
$$$
*
!
+
,
-
.
!
!
,
!
!
"!#$
!
"$
2
1
)
2
)
!
!
%
&
" 3&
'4$&
$$$
2
'
5
2
!
!
(
" #&
0#$&
$$$
!
" #$%&
$'$(
$$
!
" '$&
$%'&
$'$
BENEFICIOS
Personal
Jefe de
Departamento
Secretaria
Transporte
Mensajero
Anteproyecto
Salario / Mes Reducción Valor
$ 1.000.000
90%
$ 450.000
$ 360.000
$ 200.000
50%
50%
$ 180.000
$ 100.000
Vida Útil /
Sistema
Total
36 $ 16.200.000
36 $ 6.480.000
36 $ 3.600.000
49
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
50
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.
normalmente el diagrama de Gantt.
Se utiliza
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
51
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
52
CRONOGRAMA DE ACTIVIDADES
ACTIVIDADES
TIEMPO
AGOSTO SEPTIEMBRE
1 2 3 4 1 2 3
4
SEMANAS
ANÁLISIS
Sistema actual
Requerimientos
Sistema propuesto
Revisión
DISEÑO
Diseño Global
Diseño Detallado
Base de Datos
Prototipo
Revisión
CONSTRUCCION
PRUEBAS
PUESTA EN
MARCHA
OCTUBRE NOVIEMBRE DICIEMBRE
1 2 3 4 1 2 3 4 1 2 3 4
1
ENERO
2 3 4
FEBRERO
1 2 3 4
1
MARZO
2 3 4
7 SEMANAS
9 SEMANAS
15SEMANAS
2
3 SEMANAS
NOMENCLATURA
ACTIVIDAD RESUMEN
ACTIVIDAD REAL
PUNTOS DE CONTROL
Anteproyecto
53
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
54
3.6 RESUMEN.
ENTRADAS
PROCESO
Requerimientos de 1. Reconocimiento
Información de
General del
usuarios.
sistema.
1.1 Ubicación general
Recursos de
del sistema.
Sistemas.
1.2 Alcance.
Normas, Políticas. 1.3 Objetivos.
2. Definición del
Sistema.
2.1 Medio Ambiente.
2.2 Entradas y
salidas.
2.3 Relaciones.
3. Recursos para el
desarrollo.
3.1 Económicos.
3.2 Personal.
3.3 Hardware.
3.4 Software.
4. Estimativos de
desarrollo.
5. Análisis de
Factibilidad.
5.1 Financiera.
5.2 Técnica.
5.3 Operativa.
6 Alternativas y
Recomendaciones.
7. Decisión Final.
8. Cronograma.
Análisis
PARTICIPACION
Usuario Líder.
Analistas.
Usuarios (Todos).
Analistas.
SALIDAS
Anteproyecto.
Documentación
.
Cronograma.
Usuario Líder.
Analistas.
Analistas.
Usuario.
Analistas.
Analistas.
Usuario Líder.
Analistas.
55
4. ANÁLISIS.
4.1 CONSIDERACIONES GENERALES.
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
56
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
57
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
58
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
59
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
60
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
61
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
62
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
63
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
64
• 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
65
• 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í:
DETALLADA
SUPERFICIAL
INFORMALES
Muy Productiva
No recomendadas
FORMALES
Optimas para el control
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
66
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
67
• 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
68
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 establece 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 entender 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
69
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
70
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
71
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
72
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.
2
Se han propuesto muchos enfoques diferentes de TFEA . 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
1
selecciona lugar, fecha y hora de reunión TFEA 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
73
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 servicios (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.
2
Por ejemplo , 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
74
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
75
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
76
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.
D
c
es
ón
ci
p
ri
de
o
os
et
bj
de
Es
p
s
to
da
Diagrama
Entidad-Relación
(DER)
ec
if
ica
ci ó
n
de
Diagrama de
Flujo de datos
pr
oc
es
o
(E
P)
Diccionario de
Datos (DD)
Diagrama de Transición de datos
Especificación de control (EC)
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
77
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
78
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
79
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
80
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
81
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
82
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
83
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
84
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
85
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
86
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
87
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
88
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.
2.
3.
4.
5.
Todo evento sucede en un momento específico.
Sucede en el ambiente y no dentro del sistema.
La ocurrencia del evento está bajo el control del ambiente y no del sistema.
El sistema debe ser capaz de detectar que el evento sucedió.
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
89
4.
5.
6.
7.
Quen llama cuelga.
El propietario oye un mensaje.
El propietario solicita mensajes.
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
90
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
91
IDENTIFICACION
NOMBRE
DESCRIPCION
ESTIMULO
ACTIVIDAD
RESPUESTA
EFECTO
150
El almacén envía el pedido del cliente.
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.
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.
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
Guía transportadora
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 sujetoverbo-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
92
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
El cliente hace pedido
El departamento de crédito aprueba pedido
MEDELLIN
X
X
CALI
X
RIONEGRO ...
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
93
EVENTO/ENTIDAD
El cliente hace pedido
El departamento de crédito aprueba pedido
CLIENTE
CRU
U
PEDIDO
CR
CPTO PEDI ...
CR
...
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
Medellín
Cali
Rionegro
CLIENTE
CRU
CRU
CRU
PEDIDO
CRU
CR
CR
CPTO PEDI ...
CR
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
94
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
95
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
96
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
97
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
98
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
99
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
100
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
101
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
102
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
Nombre
Apellido
Número telefónico
Fecha de recepción
Fecha de entrega
Hora de entrega
Número Recibo
Tipo prenda
Tipo servicio
Cantidad
Precio unitario
Instrucciones especiales
Análisis
103
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
Nombre
Número telefónico
Fecha de recepción
Fecha de entrega
Hora de entrega
Recibo
Tipo prenda
Tipo servicio
Cantidad
Instrucciones especiales
(Precio unitario)
Tipo servicio
Tipo prenda
Precio unitario
(El precio actual)
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
104
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
Nombre
Apellido
Número telefónico
Recibo
Codigo cliente
Fecha recepción
Fecha entrega
Hora prometida
Recibo
Tipo prenda
Tipo servicio
Cantidad
Instrucciones
(Precio unitario)
Análisis
105
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
106
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
107
A nivel de atributos :
VEHICULO
CRUCE
VIAS
Placa
Modelo
Propietario
Veloc. Promedio
Cilindraje
Fecha Compra
Placa
Código Vía
Fecha y Hora Cruce
Motivo Cruce
Dirección Cruce
Tráfico
Código Vía
Orientación
Número Carriles
Tipo Superficie
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
108
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 hace pedido
Dpto crédito aprueba pedido
...
CLIENTE
CRU
U
PEDIDO CPTO PEDIDO
CR
CR
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
109
EVENTO/UBICACIÓN
Cliente hace pedido
Dpto crédito aprueba pedido
...
MEDELLIN RIONEGRO
X
X
X
CALI
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
Medellín
Rionegro
Cali
....
CLIENTE
CRU
CRU
CRU
PEDIDO CPTO PEDIDO
CR
CR
U
U
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
Representante de Ventas
Gerente de Crédito
Jefe de Bodega
...
CLIENTE
CRU
CRU
U
PEDIDO CPTO PEDIDO
CR
CR
U
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
110
5.3.9 ALGUNOS EJEMPLOS DE MODELOS DE INFORMACION :
Sistema Hospitalario :
Sistema de Inventarios :
Análisis
111
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
112
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
ESCRIBIR
BUSCAR
SUMAR
RESTAR
MULTIPLICAR
DIVIDIR
CALCULAR
IMPRIMIR
ORDENAR
REEMPLAZAR
LLAMAR
MOVER
VALIDAR
ENCONTRAR
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
113
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
114
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
Estudio de
Factibilidad.
PROCESO
1. Analisis Sistema
Actual.
1.1 DFD Sistema Actual.
Sistema Actual. 1.2 DD Sistema Actual.
1.3 DSD si existe.
Requerimientos 1.4 Objetivos del área.
detallados.
2. Requerimientos del
nuevo sistema.
3. Especificaciones del
nuevo sistema.
3.1 Modelo de Procesos.
3.2 Modelo de
Información.
4. Revisión del Análisis.
5. Cronograma Diseño.
Análisis
PARTICIPACION SALIDAS
Usuarios.
Especificaciones
Analistas.
Funcionales.
Cronograma
Diseño.
Usuarios.
Analistas.
Analistas.
Analistas.
Usuarios.
Usuarios.
Analistas.
115
6. DISEÑO.
6.1 CONSIDERACIONES GENERALES.
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.
116
1.
2.
3.
4.
5.
6.
Definir la estructura inicial.
Diseñar los módulos y/o ventanas.
Terminar la base de datos.
Diseñar entradas y salidas.
Generar el prototipo.
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.
117
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.
118
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.
119
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.
120
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.
121
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.
122
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
INICIALIZAR VRCOMISION
LEER REGISTRO VENTAS
MIENTRAS NO FIN ARCHIVO VENTAS
SI VRVENTA > 1’000.000
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
** (VRCOMISION = COMISION * VRVENTA)
LEER REGISTRO VENTAS
FIN
SECUENCIA
REPETICION
CONDICION
RUTINA
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.
123
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.
124
♦
♦
♦
♦
♦
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.
125
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.
126
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.
127
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.
128
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.
129
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.
130
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.
131
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.
132
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.
133
• 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.
134
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.
135
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.
136
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.
137
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.
138
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.
139
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.
140
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.
2
X
Log x
Sen x
El parámetro de entrada al módulo es el dato X. Con éste, se realizan tres
2
funciones individuales A (X ), 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.
141
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.
142
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.
143
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.
144
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.
145
6.7 RESUMEN :
ENTRADAS
Modelo de
Procesos.
Modelo de
Información.
PROCESO
1. Diseño Global.
Estructura del sistema
2. Diseño detallado.
Diseño de módulos.
PARTICIPACION
Analistas.
Usuarios.
Analistas.
Hardware y
Software
existente.
3. Diseño de bases de
datos.
4. Diseño de
entradas/salidas.
4.1 Ventanas.
4.2 Formatos.
Analistas.
4.3 Reportes.
4.4 Informes.
4.5 Interfases.
5. Diseño de operación
del sistema.
Prototipos.
6. Revisión del diseño.
Diseño.
Analistas.
Usuarios.
SALIDAS
Estructura
del sistema.
Diseño de
ventanas,
reportes,
Informes,
formatos,
interfases.
Seudocódigo.
Base de
datos.
Analistas.
Usuarios.
Analistas.
Usuarios.
146
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.
147
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.
148
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.
149
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.
150
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.
GERENCIA
PRODUCCION
PLANTA
VENTAS
ALMACEN
RECURSO HUMANO
LINEA LIVIANA
LINEA CAMPO
VENDEDORES
VENDEDORES
COORDINADORES
FINANZAS
TESORERIA
CUENTAS POR PAGAR
CAJA Y BANCOS
PRESTAMOS
Caso de Estudio.
151
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.
152
• 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.
153
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.
154
Co
ns
BANCOS
ign
ac
s
to
ien
ago
Cr
yp
cim
sp
n
s
éd
ba
e
o
s
laz
rv
nc
ito
res
po
eso
ari
sa
as
Ing
es
aja y egr
as
pro
on
ec
i
c
d
ba
os
e
liga
do
adr ngres
Ob
s
Cu
i
s
n
cale
ó
cci
es lo
n
e
Pag
io
y
ac
os r
Pr o
sign
ealiz
Con
ado
dito
s
e cré
itud d
Solic
SISTEMA DE INFORMACION
No
tas
CLIENTES
GERENCIA
CUENTAS POR
PAGAR
.o
d
ción
ama
Y
gos
e pa
r
ctu
Fa
OBLIGACIONES
FINANCIERAS
as
BANCOS
Recibo de caja
CAJA Y BANCOS
Políticas de
financiamiento
r
Prog
GERENCIA
tra
Pa
go
s
Obliga
ciones
adquir
idas
Ingres
os y p
agos
Cheq
ue y
orden
de pa
go
rea
liza
PROVEEDORES
CLIENTES
CONTABILIDAD
PROVEEDORES
do
s
CUENTAS POR
PAGAR
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
Material de Oficina
Papel
Diskettes
Cinta Impresora
Software de Desarrollo
Salarios Analistas
Salarios Usuarios
TOTAL
$2’000.000
$ 85.000
$1’000.000
$2’500.000
$3’600.000
$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.
155
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.
156
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.
157
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
TOTAL
$85.000
$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.
158
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.
159
CRONOGRAMA DE ACTIVIDADES.
Se presenta a consideración el cronograma de las actividades restantes para
culminar el proyecto.
ACTIVIDAD
ANALISIS
Sistema actual
Requerimientos
Sistema propuesto
Revisión
DISEÑO
Diseño Global
Diseño Detallado
Base de Datos
Prototipo
Revisión
CONSTRUCCION
PUESTA EN
MARCHA
TIEMPO
2 MESES
M1 M2 M3 M4 M5 M6 M7 M8 M9 M0
3 MESES
4 MESES
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.
160
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.
Co
ns
BANCOS
ign
CLIENTES
GERENCIA
CUENTAS POR
PAGAR
ac
.
s
to
ien
ago
Cr
as
yp
cim
n
s
ba
éd
e
o
p
v
laz
nc
ito
os
res
or
ari
sa
res
as
Ing
a
sp
as
eg
caj
ne
pro
y
o
e
i
c
ba
os
ed
liga
do
adr ngres
Ob
s
Cu
i
s
n
cale
ó
cci
es lo
n
e
Pag
io
y
ac
os r
Pr o
sign
ealiz
Con
ado
dito
s
e cré
itud d
Solic
SISTEMA DE INFORMACION
No
tas
CAJA Y BANCOS
Políticas de
financiamiento
nd
ació
ram
g
o
r
P
gos
e pa
PROVEEDORES
as
BANCOS
Recibo de caja
Y
r
ctu
Fa
GERENCIA
otr
OBLIGACIONES
FINANCIERAS
Pa
go
s
Obliga
ciones
adquir
idas
Ingres
os y p
agos
Cheq
ue y
orden
de pa
go
rea
liz
ad
os
CLIENTES
CONTABILIDAD
PROVEEDORES
CUENTAS POR
PAGAR
Caso de Estudio.
161
DIAGRAMA GENERAL O DE NIVEL UNO.
CONTABILIDAD
CLIENTES
MANEJAR
CAJA Y BANCOS
Recibo de caja
Ingresos y pagos
Cuadre de caja
Ingresos recibidos
PROVEEDOR
m
gra
Pro
ació
n
o
Inf
MANEJAR
NOTAS
BANCARIAS
4
s
go
pa
s
go
Pa
li
rea
s
do
za
an
ca
ria
s
o
pag
REALIZAR
PAGOS
ob
lig
ac
io
ne
s
y
ec
ci ó
n
eg
in
gr
re
es
so
os
s
5
No
tas
b
n de
REALIZAR
PROYECCIONES
s
ota
nn
Va
lo
rd
e
ió
ac
rm
ag
ad
os
Ch
eq
ue
sp
que
Che
de
y or
GERENCIA
Obligaciones a tramitar
s
tura
fin
o
2
1
PAGOS
Fac
de
Ingresos
y pagos
Pagos realizados
GERENCIA
Po
BANCOS
as
ic
lít
nt
ie
m
Pr
oy
C on
sign
ac .
otra
Cons
s pla
igna
cione
z as
s loc
ales
BANCOS
a
ci
an
d
Cré
b
pro
d
ud
licit
So
NOTAS
s
ado
BANCOS
ito
r éd
ec
MANEJAR
PRESTAMOS
PRESTAMOS
BANCOS
a
itos
3
SOLICITUDES
GERENCIA
es po
acion
Oblig
iento
im
c
n
ve
Obligaciones
adquiridas
r
CONTABILIDAD
CUENTAS POR
PAGAR
Caso de Estudio.
162
NIVEL 2 : MANEJAR CAJA Y BANCOS.
Cons
ig
BANCOS
otras
nacio
nes
plaza
Ing
s
os
res
GERENCIA
RECIBIR
Pagos realizados
CLIENTES
Recib
o
MANEJAR
NOTAS
BANCARIAS
5
INGRESOS
Ingresos rec
ibidos
INGRESOS
de caja
1.1
s
reso
r ing
s po
ta
o
N
No
Ingresos
po
re
in g
re
so
s
CUADRAR
CAJA
gre
so
s
APLICAR
Valor de obligaciones
EGRESOS
Valor egresos
EGRESOS
1.5
s
Pa
go
s
ELABORAR
CONSIGNACION
REALIZAR
PAGOS
GERENCIA
1.4
1.2
Pagos
os
ad
ag
sp
e
u
eq
Ch
tla
To
so
re
eg
Cuadre de caja
BANCOS
PRESTAMOS
3
ta l
1.3
SUMAR
MANEJAR
To
BANCOS
tas
CONTABILIDAD
SUMAR
1.6
CONTABILIDAD
4
Co
ns
ig
na
cio
lo
ca
ne
le
s
s
GERENCIA
BANCOS
NIVEL 2 : MANEJAR PRESTAMOS.
Caso de Estudio.
163
BANCOS
Cré
So
lic
it
ud
de
dito
apr
oba
do
cr
éd
ito
r
es po
acion
Oblig
to
n
ie
im
venc
CREAR
DILIGENCIAR
SOLICITUD
Obligaciones a tramitar
OBLIGACION
REALIZAR
3.1
PROYECCIONES
GERENCIA
Oblig
acio
3.2
2
Va
lo
2
adq
rd
e
ob
lig
a
PRESTAMOS
SOLICITUDES
nes
uirid
as
cio
n
CONTABILIDAD
es
MANEJAR
CAJA Y BANCOS
1
NIVEL 2 : REALIZAR PAGOS.
CUENTAS
POR PAGAR
P ro
gra
ma
ció
np
ago
s
VERIFICAR
ORDENAR
PROVEEDORES
Facturas
PROGRAMACION
VALOR
4.1
4.2
PAGOS
CUENTAS
POR PAGAR
sr
go
Pa
GENERAR
s
do
liza
ea
REALIZAR
Cheques pagados
PROYECCIONES
CHEQUES
2
4.3
Che
q
ue y
2
orde
n
de p
ago
PROVEEDORES
NIVEL 2 : MANEJAR NOTAS BANCARIAS.
Caso de Estudio.
164
BANCOS
No
ta
s
ba
nc
ar
ia
s
APLICAR
VERIFICAR
NOTAS
Información notas
NOTAS
5.1
2
5.2
NOTAS
REALIZAR
PROYECCIONES
2
PRESTAMOS
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 :
TIPO :
CUENTAS POR PAGAR.
FUENTE, SUMIDERO.
Caso de Estudio.
165
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.
166
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.
167
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.
168
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.
169
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.
170
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.
171
• 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.
172
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.
Co
ns
BANCOS
ign
CLIENTES
GERENCIA
CUENTAS POR
PAGAR
ac
to
os
en
pag
imi
Cr
y
c
s
n
éd
ba
e
os
pla
s
rv
nc
ito
re s
za
po
eso
ari
sa
In g
s
es
aja y egr
as
c
n
pr
e
ob
cio
os
ed
ad
liga
adr ngres
os
Ob
i
Cu
le s
ón
loca
cci
nes
e
Pag
io
y
c
a
os r
Pro
sign
ealiz
Con
ado
dito
s
e cré
ud d
it
c
li
So
SISTEMA DE INFORMACION
No
tas
.o
CAJA Y BANCOS
Políticas de
financiamiento
n
ació
ram
Prog
Fa
PROVEEDORES
GERENCIA
tra
BANCOS
Recibo de caja
CLIENTES
Y
agos
de p
OBLIGACIONES
Asien
tos co
ntable
s
FINANCIERAS
Cheq
ue y
r as
ctu
Pa
go
s
rea
liza
CONTABILIDAD
orden
de pa
go
PROVEEDORES
do
s
CUENTAS POR
PAGAR
Caso de Estudio.
173
DIAGRAMA GENERAL (NIVEL 1).
CONTABILIDAD
Pagos realizados
CLIENTES
BANCOS
Recibo de caja
ica
s
de
to
y
GERENCIA
ec
ci ó
n
eg
in
gr
re
es
so
os
s
lít
Po
REALIZAR
PROYECCIONES
MANEJAR
CAJA Y BANCOS
Ingresos y pagos
Cuadre de caja
GERENCIA
CUENTAS
n
ie
oy
Con
sign
ac.
otra
Cons
s pla
igna
cione
zas
s loc
ales
Asientos
contable
s
m
Pr
BANCOS
a
ci
an
fin
PRESTAMOS
1
PROYECCIONES
2
NOTAS
DETALL PRESTAMOS
MANEJAR
NOTAS
PAGOS
BANCARIAS
5
DETALL NOTAS
que
Che
PROVEEDOR
Pro
ma
gra
ció
pag
os
ag
np
sr
go
Pa
li
ea
o
PAGOS
4
s
do
za
sa
dito
Cré
an
ca
ria
s
de
den
y or
No
tas
b
s
tura
Fa c
REALIZAR
BANCOS
b
pro
d
ud
licit
So
s
ado
ec
BANCOS
ito
r éd
MANEJAR
SOLICITUDES
PRESTAMOS
3
GERENCIA
o
es p
acion
Oblig
to
imien
venc
Asientos
co
r
CONTABILIDAD
ntables
CUENTAS POR
PAGAR
Caso de Estudio.
174
NIVEL 2 : MANEJAR CAJA Y BANCOS.
BANCOS
Cons
ignac
iones
otras
BANCOS
plaza
s
MANEJAR
RECIBIR
CLIENTES
Pagos realizados
Recib
GERENCIA
o de c
CUENTAS
NOTAS
INGRESOS
1.2
1.1
aja
co
ntos
Asie
les
ntab
CONTABILIDAD
sos
Ingre
CUADRAR
CAJA
CUENTAS
Cuadre de caja
GERENCIA
PRESTAMOS
1.4
BANCOS
APLICAR
EGRESOS
1.3
ELABORAR
PAGOS
Pagos
CONSIGNACION
1.5
Co
ns
ig
na
lo
cio
ca
ne
le
s
s
BANCOS
GERENCIA
NIVEL 2 : REALIZAR PROYECCIONES.
PRESTAMOS
Proyección de ingresos
Políticas de finaciamiento
GERENCIA
PROYECTAR
DETALL PRESTAMOS
INGRESOS
Proyección de egresos
PROYECTAR
EGRESOS
2.2
2.1
GERENCIA
Políticas de financiamiento
PROYECCIONES
CUENTAS
NIVEL 2 : MANEJAR PRESTAMOS.
Caso de Estudio.
175
Crédit
BANCOS
So
lic
itu
d
de
c
ré
dit
o
os apro
bados
DILIGENCIAR
CREAR
SOLICITUD
PRESTAMOS
OBLIGACIONES
DETALL PRESTAMOS
3.1
3.2
SOLICITUDES
MODIFICAR
OBLIGACIONES
PRESTAMOS
DETALL PRESTAMOS
3.3
RETIRAR
PRESTAMOS
OBLIGACIONES
DETALL PRESTAMOS
3.4
Asientos contables
CONTABILIDAD
CONSULTAR
OBLIGACIONES
Obligaciones por vencimiento
GERENCIA
3.5
NIVEL 2 : REALIZAR PAGOS.
Caso de Estudio.
176
Programación de pagos
ORDENAR
CUENTAS
POR PAGAR
Factu
GENERAR
PROGRAMACION
ORDEN DE PAGO
4.1
4.2
ras
Pag
os
Ord
en d
PROVEEDORES
PAGOS
rea
liza
dos
e pa
CUENTAS
go
POR PAGAR
Cheque
PROVEEDORES
IMPRIMIR
CHEQUES
4.3
NIVEL 2 : MANEJAR NOTAS BANCARIAS.
CREAR
NOTAS
5.1
s
ta
No
s
ia
ar
c
n
ba
N
NOTAS
DETALL NOTAS
PRESTAMOS
MODIFICAR
ban
otas
as
cari
NOTAS
5.2
NOTAS
BANCOS
Nota
s
ban
cari
DETALL NOTAS
as
RETIRAR
NOTAS
5.3
NOTAS
DETALL NOTAS
NIVEL 3 MANEJAR CUENTAS.
Caso de Estudio.
177
CREAR
CUENTAS
1.2.1
BANCOS
CUENTAS
MODIFICAR
CUENTAS
1.2.2
BANCOS
CUENTAS
RETIRAR
CUENTAS
1.2.3
BANCOS
CUENTAS
Caso de Estudio.
178
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.
179
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.
180
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.
181
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.
182
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.
183
DIAGRAMA DE ESTRUCTURA DE DATOS.
DEFINICION DE ENTIDADES.
Caso de Estudio.
184
Ver diccionario de datos, definición de almacenamientos. (tanto el diccionario del
sistema actual, como el propuesto).
MATRICES DE ENTIDAD.
EVENTO/ENTIDAD.
EVENTO/ENTIDAD
El cliente realiza un
pago.
El banco envía
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.
BANCO CTAS
MVTO
R
CR
R
CR
NOTAS DET.
PREST
NOTAS
DET.
PREST
SOLIC.
CR
R
R
CR
CR
CR
RD
C
R
R
CR
R
CR
CR
R
RD
RD
R
CR
CR
CR
CR
CR
RU
RU
AUTORIZACION USUARIO/ENTIDAD.
Caso de Estudio.
185
EVENTO/ENTIDAD
BANCO CTAS
Cajero.
Analista Proyección
Auxiliar Cajero.
Gerente.
Analista Prestamos.
CRUD CRUD CRUD R
R
R
R
R
CRUD R
R
R
R
CRUD
Caso de Estudio.
MVTO
NOTAS DET.
PREST
NOTAS
R
R
R
R
R
DET.
PREST
SOLIC.
R
R
R
CR
R
R
CRUD
CRUD CRUD CRUD RUD
186
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.
187
DISEÑO DETALLADO.
Caso de Estudio.
188
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.
189
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.
190
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.
191
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.
192
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.
193
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.
194
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.
195
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.
196
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.
197
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.
198
Para proyecciones de Ingresos y Egresos, Consignaciones, Cuadre de Caja y
Consultas.
Ventana de Consultas.
Caso de Estudio.
199
HERRA
MIENT
AS
8. Bibliografía.
• Pressman, Roger. Ingeniería del Software un enfoque práctico, 3 edición,
España, McGraw Hill, 1994.
c
• Senn, James A. Análisis y diseño de sistemas de información. México, M Graw
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.
Bibliografía.
200