Ingeniera Del Software

TABLA DE CONTENIDO
1.
INTRODUCCIN
1.1 SISTEMA.
1.2 LA ORGANIZACIN.
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 INFORMACIN EN LAS ORGANIZACIONES.
1.4.4 ADMINISTRACIN DE SISTEMAS DE INFORMACIN.
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 PREANLISIS O ANTEPROYECTO.
1.6.2 ANLISIS.
1.6.3 DISEO.
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 INGENIERA DEL SOFTWARE: UNA TECNOLOGA 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 RPIDO 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 MTODOS FORMALES
2.2.8 TCNICAS DE CUARTA GENERACIN
Introduccin.
16
17
18
18
18
18
18
18
20
22
22
24
26
27
28
28
30
30
31
31
32
32
32
32
3.
ANTEPROYECTO O PREANLISIS.
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 Ubicacin General.
3.5.1.2 Delimitacin 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 Econmicos.
3.5.4.2 Recursos de Personal.
3.5.4.3 Recursos Tcnicos.
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 Tcnica.
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.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 DISEO.
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.
Introduccin.
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.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 ORGANIZACIN 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/UBICACIN DEL NEGOCIO.
4.9.8.3 CRUD UBICACIN/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.
Introduccin.
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 ESPAOL ESTRUCTURADO.
4.10.2.2 CONVENCIONES.
4.11 RESUMEN.
112
112
113
115
5.
116
DISEO.

116
5.1.1 OBJETIVOS.
116
5.1.2 DEFINICION.
116
5.2 IMPORTANCIA DEL DISEO.
117
5.3 CARACTERISTICAS DEL DISEO.
117
118
5.5 PASOS EN EL DESARROLLO DEL DISEO.
118
5.5.1 DEFINIR LA ESTRUCTURA DEL SISTEMA (DISEO 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 DISEO DE MODULOS. (DISEO DETALLADO).
121
5.5.2.1 REQUERIMIENTOS PARA EL DISEO DE MODULOS.
122
5.5.2.2 ATRIBUTOS DE UN MODULO.
122
5.5.3 DISEO DE BASES DE DATOS.
123
5.5.4 DISEO DE ENTRADAS Y SALIDAS.
124
5.5.4.1 DISEO DE DOCUMENTOS FUENTES.
124
5.5.4.2 DISEO DE VENTANAS.
125
5.5.4.3 DISEO DE REPORTES.
132
5.5.5 DISEO DE OPERACION DEL SISTEMA (PROTOTIPOS).
132
5.5.6 DOCUMENTACION Y REVISION.
134
5.6 DISEO 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 DISEO.
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 DISEO ESTRUCTURADO.
145
5.7 RESUMEN :
146
6.
CASO DE ESTUDIO.
147
7.
BIBLIOGRAFA.
200
Introduccin.
PREFACIO
Este documento se desarroll con un solamente acadmico, partiendo de la necesidad de los
estudiantes de ingeniera del software de tener una gua prctica que les ayude a comprender el
desarrollo de un sistema de informacin basado en tecnologas de informacin computarizadas
(S.I.B.T.I.C).
Este libro es la primera edicin, y se bas en experiencias propias del autor en desarrollo de
S.I.B.T.I.C, al igual que experiencias en la asesora de proyectos de grado de carreras informticas
en diferentes instituciones de educacin superior.
Para su referente temtico se bas en libros tales como: Notas de Ingeniera de Carlos Builes,
Ingeniera del software, Un enfoque prctico edicin 5 de Roger Pressman, UML y patrones de
Larman entre sus principales fuentes de informacin.
Introduccin.
1. INTRODUCCIN
El presente trabajo pretende recopilar algunas de las teoras y tcnicas para el
desarrollo de sistemas de informacin basados en tecnologas de informacin
computarizadas( S.I.B.T.I.C), dando un referente a aquellos autores que lo han
venido trabajando durante los ltimos 20 aos.
Este documento permite al estudiante tener una gua prctica para la elaboracin
de sistemas de informacin ( S.I.B.T.I.C), adems de tener una referencia
bibliogrfica 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 informacin, presentando en cada etapa de ste, sus
caractersticas, objetivos y herramientas disponibles para su elaboracin y
verificacin.
Concluye con varios ejemplos prcticos, de proyectos desarrollados por docentes
y estudiantes.
Introduccin.
1.1 SISTEMA.
Es un conjunto de elementos que se INTERRELACIONAN para lograr un objetivo
comn. Ejemplos:
La Organizacin (EMPRESA), El Sistema Circulatorio, La Universidad, etc.
Un sistema posee caractersticas, tales como:
Lmites, Objetivos, Medio Ambiente, Entradas (del medio al sistema), Salidas (del
sistema al medio), Elementos, Relaciones (interrelacin entre elementos),
funciones (Transformacin de entradas en salidas), RETROALIMENTACION.
1.2 LA ORGANIZACIN.
Por definicin, la organizacin es un sistema conformado por elementos tales
como:
La Gerencia, Relaciones Industriales, Finanzas, Produccin (Servicios), Mercadeo
y Ventas; que se unen (se relacionan), para alcanzar los objetivos de la
organizacin. Grficamente:
La Organizacin
De esta manera, podemos decir que la organizacin esta influenciada por el

medio ambiente y a su vez sta misma lo modifica.
Introduccin.
El medio ambiente en donde se desenvuelve la organizacin, est conformado

bsicamente por:
Sistema Poltico, Sistema Econmico, Sistema Cultural, La Competencia, Los
Accionistas, Los Sindicatos, Los Proveedores, Los Clientes y Los Acreedores.
1.3 ENFOQUE DE SISTEMAS.
Parntesis conceptual
Antes se presentarn algunos referentes conceptuales para mayor comprensin
del enfoque de sistemas.
Sistematizacin: Accin y efecto de estructurar, organizar algo con un

conjunto ordenado de normas y procedimientos acerca de una determinada
materia
Automatizacin: Supresin total o parcial de la intervencin humana en la
ejecucin de diversas tareas (Sin.: Automacin)
Computarizacin: Someter datos al tratamiento de un computador.
Informatizacin: Accin y efecto de
Dotar un servicio, organismo, etc., de medios informticos,
asegurar
su gestin mediante medios informticos
Utilizar la informtica para tratar con ayuda del computador las
necesidades de un sector profesional, para solucionar un problema
(CAPITULO 18 Sistemas de informacin gerencial-Kenneth Laudon y
Jane Laudon 6 Edicin)
Informacionalizacin: representa la importancia creciente de la
informacin, y su explotacin, como recurso econmico
Cultura de la Informacin: Una sociedad constituida por
ciudadanos y organizaciones informacionalmente cultas (orden
espontneo).
Economa de la Informacin : Economa en la que se ha desarrollado un
sector Informacin que contribuya de forma relevante a su crecimiento
(planificable)
Infraestructura: Abarca la Economa de la Informacin, es decir, una
industria potente en el sector de la informacin (contenidos, distribucin,
proceso de informacin)
Como vemos, en la organizacin existe un elemento importante que relaciona o

vincula a los dems componentes y les proporciona la materia prima para lograr
la consecucin de sus objetivos particulares, disminuyendo la incertidumbre.
Dicho elemento es la INFORMACION.
Como elemento importante, surge entonces una nueva manera de mirar la
organizacin, mediante una serie de herramientas que le proporcionan a sta, una
Introduccin.
METODOLOGIA de trabajo para resolver problemas, utilizando el concepto de

Sistema.
Una definicin de problema podra 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
gustara que estuviera sucediendo, todava no tiene un problema.
Simplemente se est quejando. Kenneth Blanchard y Spencer Johnson.
CARACTERISTICAS DEL ENFOQUE:
Es una manera ms de mirar los fenmenos del mundo exterior.
Proporciona una visin 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 desempea en
el sistema.
La funcin 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 INFORMACIN, podran ser:
La informacin es la respuesta a una pregunta previamente planteada, la
cual disminuye la incertidumbre y proporciona elementos para la toma de
decisiones.
La informacin debe ser vista como un recurso no como un producto del
procesamiento de datos
La informacin se ve como un recurso de toda la organizacin, no slo del
departamento o proyecto que la genera o recibe
La informacin proviene de varias fuentes, no slo de las actividades
tradicionales del procesamiento de datos.
Algunas definiciones de Sistemas de informacin:
Introduccin.
Un Sistema de Informacin es un sistema integrado usuariomquina/usuario-usuario, que provee informacin que es de apoyo a las
operaciones, la administracin 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 funcin consiste en manejar y administrar el recurso
de la informacin, con el fin de integrar cada uno de los elementos
constitutivos de una organizacin.
Algunos elementos de la organizacin son:

DINERO (FINANZAS).
MATERIALES (PRODUCCION).
INSTALACIONES (SERVICIOS GENERALES).
PERSONAL (RELACIONES INDUSTRIALES).
INFORMACION (SISTEMAS).
GERENCIA (TOMA DE DECISIONES).
Los sistemas de informacin, son bsicos 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.
Mtodos y Procedimientos: Define las instrucciones detalladas para delinear las
obligaciones, responsabilidades y operacin del sistema. Se parte de la
Organizacin para la cual se va a desarrollar el S.I.B.T.I.C.
Equipo (hardware): Equipos de Cmputo.
Personal: De sistemas, Usuarios, Auditora y Mtodos y Procedimientos.
Aplicativo (Software): Se compone de los diferentes programas de computador
que permiten la elaboracin de datos e informacin, de forma ms rpida
utilizando el computador.
Bases de datos : Son los almacenamientos de datos de forma estructurada y
organizada.
Metodologa y Documentacin: Son las formas estandarizadas para el
desarrollo del sistema de informacin, estas se componen de herramientas y
Introduccin.
10
tcnicas. La documentacin debe estar relacionada con cada uno de los

componentes del sistema de informacin.
Grado de Participacin de la Personas en el Desarrollo de un Proyecto.
Ejemplo: Sistema de Informacin de Nmina.
Introduccin.
11
De la grfica podemos apreciar que el sistema de informacin de nmina consta

de los siguientes elementos:
Pagos y novedades, manejo de los datos del empleado, manejo de deducciones,
generacin de estadsticas e impresin de cheques. Todos ellos interactuando (a
travs de datos e informacin), para lograr el objetivo bsico de generar la nmina
para el personal de una organizacin especfica.
1.4.3 PAPEL DE
ORGANIZACIONES.
LOS
SISTEMAS
DE
INFORMACIN
EN
LAS
LEY DE LA ESPECIALIZACIN:
Entre ms adaptado se encuentre un organismo a un ambiente especfico,
ms difcil le ser adaptarse a un ambiente diferente.
La organizacin conforma un gran sistema en el cual sobresalen dos cualidades:
Tiene un mecanismo de evaluacin o autocontrol (Retroalimentacin).
Es ABIERTO; Recibe gran influencia del medio ambiente.
El papel de los sistemas de informacin es soportar un manejo ms gil y eficaz
de las variables externas e internas de la organizacin, para asistir en la toma de
decisiones y retroalimentar informacin para el control de ella misma.
Introduccin.
12
Los sistemas de informacin deben suministrar datos e informacin suficiente

para cada nivel dentro de la organizacin:
Niveles en la Organizacin.
Sistemas Transaccionales: Se utilizan para automatizar los procesos operativos.
Son sistemas intensivos en entrada de datos y salida de informacin, ya que a
travs de ellos se cargan las bases de datos de la organizacin.
Los clculos y frmulas que contienen son, en la mayora de los casos, simples
de entender.
Ejemplo : Facturacin, Nmina, Cartera, Ventas, etc.
Sistemas Tcticos : Son sistemas de apoyo a las decisiones. La informacin que
generan le sirve a los mandos medios y a la alta gerencia. Suelen ser intensivos
en clculos y escasos en entradas de datos. Son dirigidos a un usuario final.
Ejemplo: Simulaciones, Proyecciones Financieras, etc.
Sistemas Gerenciales (Estratgicos): Suelen ser In House (hechos en casa).
Su funcin es lograr ventajas que los competidores no posean, tales como
ventajas en costos o en servicios.
Apoyan el proceso de innovacin de productos y procesos dentro de la empresa.
Ejemplo: MRP (Manufacturing Resource Planning).
A nivel estratgico, los sistemas de informacin deben apoyar la toma de
decisiones a travs de la informacin 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 estratgico (Sistemas Tcticos).
Introduccin.
13
1.4.4 ADMINISTRACIN DE SISTEMAS DE INFORMACIN.

Administrar los sistemas de informacin, como un recurso ms de la organizacin,
Implica PLANEACION, ORGANIZACION Y CONTROL.
Dichos elementos administrativos, los proporciona la aplicacin de la INGENIERIA
DE SOFTWARE, un conjunto de herramientas y tareas que tienen como objetivo
la planeacin, ejecucin, control y puesta en marcha de sistemas de informacin.
A este punto, surgen preguntas importantes acerca de la computarizacin y uso
de los diferentes sistemas de informacin en una organizacin:
Por qu no debieran computarizarse algunos sistemas de procesamiento
de datos?
Por algunas variables como:
Costo.
Conveniencia.
Seguridad.
Polticas.
Facilidad de mantenimiento.
Naturaleza de los procesos.
Por qu se han presentado malos resultados aplicando la tecnologa

informtica en las organizaciones?
El factor humano (humanware) ha sido descuidado, comparndolo con el
hardware y el software. No hay formacin.
Los sistemas no son integrados. Son islas de computarizacin.
Se produce demasiados datos en las organizaciones, lo cual genera
embotellamientos y carga.
Se computarizan sistemas ineficientes, mejorando lo que no debera hacerse.
Los usuarios no participan en el diseo de los sistemas que van a utilizar.
Por qu la tecnologa informtica no ha mejorado las medidas de xito en
las organizaciones?
Los beneficios de las tecnologas informticas no son inmediatamente visibles.
La inversin en tecnologa informtica no se retorna en forma financiera, sino
en forma intangible, en muchos casos.
El impacto de la tecnologa informtica es muy poco, sino se hace con cambios
en la organizacin.
El uso de herramientas de desarrollo de software es limitado en las
organizaciones.
Introduccin.
14
Los sistemas de informacin son depurados en produccin.

Se entregan sistemas con defectos obvios.
Los sistemas son entregados tarde e incompletos, con desfases de ms del
200%.
Ms del 84% de los sistemas entregados, no logran las expectativas originales.
1.5 CONSIDERACIONES DE SOFTWARE.
1.5.1 DEFINICION.
Es la especificacin, diseo, programacin, prueba, implementacin y operacin
de S.I.B.T.I.C. (Sistemas De Informacin Basados en Tecnologas de Informacin
Computarizadas).
Es el hbil y disciplinado uso de herramientas de desarrollo de software, con el fin
de producir S.I.B.T.I.C:
Principales caractersticas:
Funcionales, econmicos, flexibles, confiables, eficientes, fciles de entender y de
modificar, extensibles, seguros, de respuesta rpida, abiertos para comunicarse
con otros sistemas.
Se debe usar entonces esta tecnologa de software, para aumentar la efectividad
(hacer las cosas correctas) ms que para aplicar la eficiencia (hacer las cosas
correctamente). Dado que computarizar tareas innecesarias aminora la
productividad de la organizacin.
1.5.2 EVOLUCION.
La evolucin del software se ha motivado por el avance y desarrollo en el
hardware. El desarrollo del software se puede agrupar en cinco generaciones:
Primera Generacin : Sistemas Batch, no portables, monoprogramacin.
Aos: 50's - 60's.
Segunda Generacin: Multiprogramacin, sistemas en lnea, ms portables,
bases de datos. Aos: 60's - mediados 70s.
Tercera Generacin: Sistemas distribuidos, comunicacin entre computadores,
mayor complejidad de bases de datos. Aos: mediados 70's - principios 80's.
Cuarta Generacin: Micros con mucha velocidad de proceso, gran capacidad de
almacenamiento, facilidad de desarrollo. Aos : principios 80's - fines 80's.
Introduccin.
15
Quinta Generacin: Inteligencia artificial, objetos, programacin parametrizada,

Cliente/Servidor, Internet, Intranet. Aos : fines 80's - hoy.
Una divisin en categoras ms til de los sistemas automatizados es la siguiente:
En lnea.
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 aparicin de los equipos
IBM 370.
Debido al desarrollo acelerado del hardware, que permiti realizar mltiples
sistemas en un momento donde no haba personal capacitado para hacerlo.
Existan 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.
Insatisfaccin del usuario.
Resultados diferentes a los deseados.
Tcnicas de desarrollo muy variadas.
Documentacin tediosa.
Mantenimiento de sistemas que consuma 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 metodologa de trabajo
clara para desarrollar S.I.B.T.I.C.(Sistemas de Informacin Basados en
Tecnologas de Informacin Computarizadas) con una base tcnica apropiada.
1.5.4 FACTORES CRITICOS DE XITO EN EL DESARROLLO DE SISTEMAS

DE INFORMACION.
Identificar el verdadero problema.
Introduccin.
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 direccin.
Planear las actividades del proyecto.
Obtener los recursos suficientes.
Mantener una cartera balanceada de proyectos de sistemas.
Establecer un sistema de administracin de proyectos.
Usar los mecanismos apropiados para ejercer un adecuado control del
proyecto.
Tomar en cuenta la evolucin de los sistemas.
Garantizar adecuados canales de comunicacin.
Asegurar la conformidad con los estndares.
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 LEDO) SOBRE EL ESCRITORIO DE TODO
ANALISTA Y PROGRAMADOR. Edward Yourdon.
Dada la veracidad de la afirmacin 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 organizacin.
3. Proporcionar puntos de control y revisin 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:
PREANLISIS (ANTEPROYECTO)
ANLISIS.
DISEO.
CONSTRUCCIN.
PRUEBAS
IMPLEMENTACIN (ENTREGA AL USUARIO).
Introduccin.
17
1.6.1 PREANLISIS O ANTEPROYECTO.

Cobija las actividades necesarias para determinar si un sistema particular ser
desarrollado.
1.6.2 ANLISIS.
Es la coleccin, organizacin y evaluacin 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 DISEO.
Es la especificacin de la concepcin y estructura del nuevo sistema, donde se
definen sus mdulos, a nivel general y detallado. Responde a la pregunta:
Como se va a hacer el nuevo sistema?
1.6.4 CONSTRUCCION.
Es la programacin en un lenguaje especfico de sistemas, del diseo antes
realizado.
Traduce el diseo 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 anlisis.
Las Pruebas Operacionales son las que deben realizar en el rea de sistemas
para verificar la calidad del diseo de las bases de datos y la calidad de los
programas desarrollados. Estas verifican la calidad de las tcnicas y mtodos
aplicados.
1.6.6 IMPLEMENTACION. (PUESTA EN MARCHA DEL SISTEMA).
Introduccin.
18
Es la validacin del nuevo sistema con datos ficticios, para luego colocarlo a
funcionar realmente, con datos verdicos.
Se deben hacer capacitacin e induccin 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 implcito,
latente e incompleto en gran medida, es un proceso social de aprendizaje. El
proceso es un dialogo en el que se rene el conocimiento y se incluye en el
software para convertirse en software. El proceso proporciona una interaccin
entre los usuarios y los diseadores, entre los usuarios y las herramientas de
desarrollo, y entre los diseadores y las herramientas de desarrollo (La
tecnologa). ES un proceso interactivo donde la herramienta de desarrollo se
usa como medio de comunicacin, con cada iteracin del dilogo 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
metdica para desarrollar software de calidad.
Un proceso de software define el enfoque que se toma cuando el software es
tratado por la ingeniera. Pero la ingeniera del software tambin comprende las
tecnologas
que tiene el proceso Mtodos tcnicos y herramientas
automatizadas--.
Quin 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 organizacin a una actividad que si no se
controla desde su comienzo tiende a volverse catica.
Cmo 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.
Introduccin.
19
2.1 LA INGENIERA DEL SOFTWARE: UNA TECNOLOGA ESTRATIFICADA

La ingeniera del software
es la aplicacin de un enfoque sistemtico,
disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del
software. IEEE.
LA ingeniera del software es una tecnologa multicapas, donde el fundamento es
la capa de PROCESO.
El proceso de la ingeniera del software es la unin que mantiene juntas las capas
de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera 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 ingeniera del software se puede dividir en tres (3)
fases genricas, con independencia del rea de aplicacin, tamao o complejidad
del proyecto.
Fase de Definicin:
Intentar identificar que informacin ha de ser procesada, que funcin y
rendimiento se espera, que compartimiento del sistema, interfaces , restricciones
de diseo y que criterios de validacin se necesitan para definir un sistema
correcto.
Fase de Desarrollo:
Se define como han de disearse las estructuras de datos y como se traduce este
diseo en un lenguaje de programacin, se define tambin como hacer pruebas al
software.
Fase de Mantenimiento:
Introduccin.
20
Cambio que va asociado al a correccin 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 Adaptacin
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 tecnolgica o
polticas de realizacin de clculos. Este mantenimiento produce modificacin 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 ms all de sus requisitos funcionales.
Mantenimiento Preventivo
El software de computadora se deteriora debido al cambio, y por esto el

mantenimiento preventivo tambin llamado reingeniera 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 ms fcilmente.
Adems de estas actividades de mantenimiento, los usuarios del software
desarrollado requieren un mantenimiento continuo. Los asientes tcnicos a
distancia, telfonos de ayuda y sitios Web de aplicaciones especficas se
actualizan frecuentemente como parte de la fase de mantenimiento.
El mantenimiento es mucho ms que una simple correccin de errores. Dentro de
las actividades se encuentra:
Seguimiento y control del proyecto de software.

Revisiones Tcnicas Formales.
Garanta de Calidad del Software.
Gestin de Configuracin del software.
Preparacin y Produccin de Documentos.
Gestin de Reutilizacin.
Gestin de Riesgos.
Introduccin.
21
2.2 EL PROCESO DEL SOFTWARE

Se establece un marco comn del proceso definiendo un pequeo nmero de
actividades del marco de trabajo que son aplicables a todos los proyectos del
software, un nmero de tareas.
En los ltimos aos 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 ingeniera del software que debera estar
presente y alcanzar diferentes niveles de madurez del proceso. El SEI utiliza un
cuestionario de evaluacin y un esquema de 5 grados:
NIVEL 1 INICIAL
Se caracteriza segn el caso, se definen pocos procesos y el xito depende del
esfuerzo individual.
NIVEL 2 REPETIBLE
Se establecen los procesos de gestin 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 organizacin para el desarrollo y mantenimiento del software. En este
nivel se incluyen todas las caractersticas del nivel 2.
NIVEL 4 GESTIONADO
Se recopilan medidas detalladas del proceso del software y de la calidad del
producto. Se incluyen todas las caractersticas del nivel 3.
NIVEL 5 OPTIMIZACION
Se posibilita una mejora del proceso. Se incluyen todas las caractersticas
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, mtodos y capas de herramientas.
Introduccin.
22
Todo el desarrollo del software se puede caracterizar como bucle de resolucin de

problemas en el que se encuentran cuatro etapas distintas:
Definicin Del Problema

Identifica el problema especfico a resolverse.
Desarrollo Tcnico
Resuelve el problema especfico a travs de la aplicacin de alguna tecnologa,
como pueden ser documentos, programas, datos etc.
Integracin de Soluciones
Estas dos etapas se dividen las fases y los pasos genricos de ingeniera de
software.
Integracin de Soluciones y Estado Actual
Estas dos etapas se dividen las fases y los pasos genricos de ingeniera de
software.
Introduccin.
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 tcnica, mtodo y
metodologa.
Mtodo: Forma estandarizada de realizar una tarea.
Tcnica: Mtodo estructurado y repetible para lograr una tarea especfica.
Ejemplo: Diagramas de Flujo de Datos, Diagrama de Estructura de Datos.
Metodologa: Es el acomodo ordenado de las tcnicas en un enfoque sistemtico
para la construccin o adquisicin de sistemas de informacin (en el caso de
inters).
Modelo: Forma o manera de realizar una actividad o un proceso, de forma
sistematizada y sistmica.
Existen diferentes tipos de modelos de desarrollo de sistemas de informacin:
2.2.1.1 MODELO LINEAL SECUENCIAL
Ingeniera de
sistemas/informacin
Anlisis
Diseo
Cdigo
Prueba
Ingeniera y modelado de Sistemas/Informacin
Introduccin.
24
El trabajo comienza estableciendo requisitos de todos los elementos del sistema y

asignando al software algn subgrupo de estos requisitos.
Esta visin del sistema es esencial cuando el software se debe interconectar con
otros elementos.
La ingeniera y el anlisis del sistema comprende los requisitos que se recogen en
el nivel del sistema con una pequea parte de anlisis y de diseo.
ANLISIS DE LOS REQUISITOS DEL SOFTWARE

El proceso de reunin 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 informacin del software
as como la funcin requerida, comportamiento, rendimiento e interconexin.
DISEO
El diseo del software es realmente un proceso de muchos pasos que se centra
en cuatro atributos distintos de programa: Estructura de Datos, Arquitectura de
Software, Representacin de la Interfaz y Detalle Procedimental (Algoritmo)
GENERACIN DE CDIGO
El diseo se debe traducir en forma legible por la maquina. El paso de generacin
de cdigo lleva a cabo esta tarea. Si se lleva a cavo el diseo de una forma
detallada, la generacin de cdigo se realiza mecnicamente.
PRUEBAS
El proceso de pruebas se centra en los procesos lgicos internos del software, y el
los procesos externos funcionales: realizar las pruebas para la deteccin de
errores y asegurar que la entrada definida produce resultados reales de acuerdo
con los resultados requeridos.
MANTENIMIENTO
El software indudablemente sufrir cambios despus de ser entregado al cliente,
porque debe adaptarse a los cambios de su entorno externo.
Introduccin.
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 confusin
cuando el equipo del proyecto comienza.
2. A menudo es difcil que el cliente exponga explcitamente 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 versin 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 variacin del anterior, aunque bsicamente son el mismo. Se basa en un
plan para el proyecto y luego se realiza el anlisis del dominio del problema.
Terminado el anlisis, se comienza el diseo. Terminado el diseo, se sigue con
la construccin. Las salidas de una etapa son las entradas para la siguiente; A
esto se debe su nombre.
Modelo en Cascada.
Introduccin.
26
Su enfoque es conveniente para la enseanza de las tcnicas de Ingeniera de

Software.
Los proyectos reales se ejecutan en fases y no en ese estricto orden de
actividades. No se puede pretender terminar TODO el anlisis de un proyecto, por
ejemplo, sin empezar nada de diseo.
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
revisin, en muchos casos, de tareas ya culminadas.
El desarrollo as visto, en fases y con cierto grado de iteracin de ajuste, es una
prctica exitosa en los mtodos de cascada.
Cascada con Iteracin de Ajustes Integradas.

CONSIDERACIONES:
La implantacin ascendente es buena para el montaje de automviles en lnea,
pero slo despus de que el prototipo este completamente libre de fallas. (Ciclo
de vida en cascada).
El agua, siendo vctima de la gravedad, no tiende a regresar hacia arriba de la
colina. De manera similar, la gente tiende a tratar los regresos hacia el anlisis o
el diseo 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 travs 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 organizacin.
Introduccin.
27
Cascada en Fases.
2.2.3 MODELO DE CONSTRUCCION DE PROTOTIPOS

La construccin 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 construccin de prototipos
2.2.4 MODELO DESARROLLO RPIDO DE APLICACIONES.

FALTA modelo de DRA completarlo
Introduccin.
28
Desarrollado en el Pentgono, como un mtodo para controlar los costos de

proyectos de defensa. La idea es dividir el proyecto en fases ms cortas de
anlisis, diseo, construccin y evaluacin. Despus de cada fase se evala la
viabilidad del trabajo terminado, con una estimacin de lo que falta.
Este modelo se conoce con el nombre de DRA (Desarrollo Rpido de
Aplicaciones) y resuelve el problema de la entrega rpida de cdigo.
El DRA divide el proyecto en CUADROS DE TIEMPO, que son un conjunto de
caractersticas definido que se promete entregar a los usuarios dentro de un
marco de tiempo fijo, digamos 90 das. Se realiza algo de anlisis, un diseo
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 codificacin y refinacin del prototipo de realiza tres
veces, yendo en espiral, volviendo a analizar, disear y evaluar. Al final del cuadro
de tiempo, se instala la aplicacin resultante.
La ventaja del DRA es la produccin de cdigo muy temprano, que a su vez se
convierte en desventaja, dado que se tiende a abandonar todas las actividades de
anlisis y diseo previas. Otro aspecto de fortaleza, es el hecho de involucrar al
usuario en la creacin de prototipos.
Los cuadros de tiempo hacen, por otra parte, difcil el enfoque de realizar
componentes de cdigo reutilizables.
Introduccin.
29
Tres Iteraciones Espirales en Cuadros de Tiempo.

Tanto el enfoque de cascada como el DRA, tienen sus puntos fuertes y dbiles.
Lo importante es saberlos aplicar a las diversas situaciones del mundo real.
En general, un buen modelo ya sea de anlisis o diseo, debe cumplir con cinco
caractersticas principales:
1.
2.
3.
4.
Motivar la actividad pretendida.

Ser completa.
Ser modificable en su correccin.
Producir elementos contra los que se pueda medir el avance.
5. Ser fcilmente 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
Introduccin.
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 pequeas, 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 bsicos, pero muchas funciones
suplementarias quedan sin extraer.
Ingeniera de
Sistemas/informacin
Anlisis
Incremento 2
Diseo
Cdigo
Prueba
Anlisis
Diseo
Cdigo
Anlisis
Diseo
Entrega del
1. incremento
Prueba
Cdigo
Entrega del
2. incremento
Prueba
Incremento 3
3. incremento
Incremento 4
Introduccin.
Entrega del
Anlisis
Diseo
Cdigo
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 MTODOS FORMALES

FALTA MODELOS METODOS FORMALES
2.2.8 TCNICAS DE CUARTA GENERACIN
FALTA TECNICAS DE 4 GENERACION
2.3 FASES O ETAPAS DE UN PROYECTO INFORMTICO

Un proyecto de desarrollo de sistemas de informacin basado en tecnologas de informacin
computarizadas, requiere, de forma general tres fases, que son:
Planeacin (preanlisis o anteproyecto)

Ciclo de Vida de Desarrollo (Ejecucin real)
Ciclo de Vida de Operacin (entrega y ejecucin por parte de los usuarios)
Introduccin.
32
ESQUEMA DEL PROYECTO

T
Planeacin
Ejecucin
Real
+1
A
B Duracin del desarrollo del proyecto
A B Ejecucin real del proyecto (Ciclo de vida del desarrollo)
A
A Planeacin
B
D Ciclo de vida til (proyecto en operacin por parte del usuario)
En B muere el desarrollo del proyecto.
ESTUDIO DE FACTIBILIDAD
PLANEACION
A
A
OPORTUNIDAD
SECTOR
Y ENTORNO
MERCADO
TCNICO
PREFACTIBILIDAD
SECTOR
Y ENTORNO
MERCADO
TCNICO
FACTIBILIDAD
SECTOR
Y ENTORNO
MERCADO
FINANCIERO
FINANCIERO
FINANCIERO
ECONOMICA
ECONOMICA
ECONOMICA
SOCIAL
SOCIAL
SOCIAL
PRIMA
SUPUESTOS
PRIMA
FTE SECUNDARIA
TCNICO
PRIMA
FTE PRIMARIA
Ver libro : Ingeniera del software: Un enfoque prctico Roger Presuman, 5 edicin, Parte Segunda: Gestin
de proyectos de software.
Introduccin.
33
PLANEACIN (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 Tcnico
(Nota: El alcance de este libro no es profundizar en estos temas, sino solamente dar un referente
temtico)
El Estudio del Sector y del Entorno, consiste bsicamente en Ubicar en que sector de la economa
se encuentra la empresa donde se va ha desarrollar el proyecto, tipo de servicios o productos que
maneja, Ubicacin con la Competencia, Sucursales etc.
Como inters de este libro solo se definirn los elementos del entorno bsicos.
El Estudio de Mercados, consiste en analizar Lneas de distribucin, los productos de la empresa
versus los mercados potenciales; Realizar un anlisis de las cuatro Ps (Precio, Producto,
Produccin, Plaza), realizar un anlisis de Oferta-Demanda-Precio.
Se realiza unos Estimativos para el Desarrollo, tendiendo en cuenta un anlisis de los Proveedores
de tecnologa, y si el Software desarrollado es un Producto para comercializar, se analizan los
Clientes potenciales, la Competencia y sus precios etc.
Como inters de este libro es solo realizar un anlisis Costo / Beneficio
El Estudio Tcnico consiste en el anlisis de la plataforma tecnolgica de la empresa(actual),
Anlisis de la plataforma tecnolgica requerida, conocimientos de los Analistas y desarrolladores,
de los usuarios etc.
2.3.1 CICLO DE VIDA DE DESARROLLO (EJECUCIN REAL)

Esta fase depende del Modelo de Desarrollo seleccionado. Bsicamente se enfoca en las
siguientes etapas:
Anlisis, Diseo, Construccin (codificacin), Pruebas, Implementacin (entrega al usuario).
Ver: Proceso del software
2.3.2 CICLO DE VIDA DE OPERACIN (ENTREGA Y EJECUCIN 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
Introduccin.
34
informacin desarrollado, una vez este tiempo transcurra, el sistema de informacin debe ser
cambiado o debe ser realizado un proceso de Reingeniera, para seguir operndolo
Introduccin.
35
Introduccin.
36
3. ANTEPROYECTO O PREANLISIS.
3.1.1 OBJETIVOS.
Definir todos los elementos que se requieren para desarrollar el proyecto.
Desarrollar el ESTUDIO DE FACTIBILIDAD (Determinar la factibilidad
financiera, tcnica y operativa de un proyecto de software, surgido de la
necesidad de un rea especfica).
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 informacin 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 direccin adquiera bases suficientes para decidir cul es la alternativa a
implementar.
Realizar una planeacin general de actividades para el desarrollo efectivo del
sistema. (En caso de ser factible el sistema).
3.1.2 DEFINICION.
La actividad de Preanlsis o Anteproyecto, permite realizar un anlisis de los
requerimientos generales y definir si es posible o no realizar el proyecto de
desarrollo del sistema de informacin planteado.
En esta actividad se lleva a cabo un Estudio de Factibilidad el cual contiene la
definicin organizada de esos requerimientos, los recursos con que se cuenta
para solucionar dichas necesidades, los estimativos de desarrollo del nuevo
sistema, el anlisis de factibilidad, alternativas de desarrollo y cronograma de
actividades futuras.
Grficamente:
Anteproyecto
37
Aplicando el enfoque de sistemas, tenemos:

1. Reconocer el problema (objetivo).
2. Definir el sistema (lmites).
3. Determinar recursos disponibles (Equipos, personas, dinero).
4. Estimar elementos de desarrollo.
5. Anlisis 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 anlisis.
Evita el desarrollo de sistemas que a nivel financiero, tcnico u operativo,
seran 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 evaluacin y control del
desarrollo de un sistema.
"Aterriza" al personal administrativo, usuarios, tcnicos en sistemas y auditores,
respecto a las expectativas reales del sistema.
Evita que se caiga el proyecto y ayuda a encontrar la solucin a las
necesidades del negocio, con base en una comprensin de ellas mismas,
ajustndose dicha solucin 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 tpico la dificultad en evaluar aspectos financieros a este nivel de
conocimiento del sistema.
Anteproyecto
38
Es la base para la planeacin futura del sistema a desarrollar.
3.4 TALENTO HUMANO NECESARIOS.

El desarrollo del estudio de factibilidad implica la participacin de un grupo
interdisciplinario de personas de reas distintas, cada uno con sus propios
intereses:
GESTORES SUPERIORES (Usuarios lderes): Son quienes definen
los
aspectos de negocios que a menudo tienen una significativa influencia en el
proyecto
GESTORES TCNICOS (Comit tcnico): 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 tcnicas necesarias para la ingeniera de un producto o aplicacin.
CLIENTES (Usuarios tcnicos): Son quienes especifican los requerimientos para
la ingeniera del software y otros elementos que tienen menor influencia en el
resultado.
USUARIOS FINALES: Son quienes interactan con el software unea vez que se
ha entregado para produccin
Es conveniente que participe directamente el usuario responsable del rea, o sea,
el directivo encargado de la dependencia.
AUDITORES: Son quienes controlan la buena ejecucin 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 informacin. 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 ubicacin a nivel general, por parte del
grupo desarrollador, acerca de la organizacin, el rea en estudio y el sistema
mismo.
Proporciona una primera visin de lo que ser el alcance del nuevo sistema.
Dicha tarea debe contemplar:
3.5.1.1 Ubicacin General.
Pretende generar una ubicacin a nivel general del sistema, dentro del medio
ambiente de la organizacin. Debe contener:
Descripcin y definicin de las caractersticas generales de la empresa (objeto
social, estructura organizacional, ubicacin geogrfica, recursos informticos,
sector al que pertenece).
Descripcin y definicin del rea donde se va a desenvolver el sistema.
Ubicacin del sistema dentro del rea.
Anteproyecto
40
3.5.1.2 Delimitacin o Alcance del Sistema.

Busca definir los lmites hasta donde se piensa, el nuevo sistema resolver las
necesidades de informacin 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 anlisis, donde se conoce ms 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 tcnico.
Un alcance tpico sera:
El propsito del sistema de procesamiento de libros XXX es manejar todos los
detalles de los pedidos de libros de los clientes, adems del envo, facturacin y
cobro retroactivo a clientes con facturas vencidas. La informacin 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, especficos y cuantificables (que se puedan medir). Deben
reflejar la satisfaccin de las necesidades de informacin, beneficios organizativos
y beneficios econmicos. Se dividen en generales y especficos.
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 cmo formular un objetivo:
Ante el problema hipottico:
El personal de ventas proporciona informacin 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 oracin positiva:
El personal de ventas necesita proporcionar informacin 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 relacin entre la obtencin de informacin de clientes y productos y el
incremento de ventas.
Anteproyecto
42
Lo que se ve es que la informacin 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.
Tambin mejorar el servicio al cliente, dado que se les molestar menos, para
pedirles informacin.
Usando entonces los trminos IR AC IS, nuestro objetivo se planteara as :
Evitar el costo de llamar a los clientes para aclaraciones (por x$) haciendo que el
personal de ventas proporcione informacin completa sobre nuevos productos.
Esto tambin mejorar el servicio al cliente reduciendo la cantidad de veces que
se hace contacto con l (nmero de llamadas).
3.5.3 DEFINICIN DEL SISTEMA.
Tiene como objetivo definir en forma COHERENTE y ESTRUCTURADA, las
caractersticas y necesidades de informacin existente, identificando sus
componentes, las relaciones existentes entre ellos, sus entradas y sus salidas. Se
puede hacer de dos formas diferentes:
Descripcin Narrativa.
Aplicacin del Enfoque de Sistemas: Se trata de asimilar las necesidades de
informacin, como un sistema que tiene un medio ambiente, entradas, salidas,
componentes y relaciones. Este sistema as definido, sera una
APROXIMACION inicial a lo que puede ser el sistema de informacin por
desarrollar.
Medio Ambiente: Se busca definir el marco bajo el cual el nuevo sistema se
desenvolver. Implica la identificacin de los sistemas fsicos o de informacin que
INTERACTUAN con el sistema en estudio.
Entradas y Salidas: Establecer aquellos flujos de informacin que entran del
medio ambiente, al sistema (Entradas). Como tambin los flujos de informacin
que el sistema entrega al medio ambiente (Salidas).
Componentes: Se busca identificar los diferentes grupos de funciones o
elementos generales que conforman el desempeo global del sistema. Para cada
componente se realiza una descripcin general.
Relaciones: Es la informacin 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 administracin
para poder solucionar las necesidades de informacin expuestas por el usuario y
poder definir la factibilidad tcnica, financiera y operativa. Estos elementos son:
3.5.4.1 Recursos Econmicos.
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 Tcnicos.

Plataforma tecnolgica: Recursos de hardware y de software disponibles en la
organizacin. Mtodos y Procedimientos del rea de informtica y sistemas.
Procedimientos y funciones del rea o reas donde se va a desarrollar el sistema,
y Auditora.
3.5.4.3.1 Hardware o Equipo Disponible.
Establecer caractersticas y capacidades del equipo o equipos que se tienen:
Memoria principal, almacenamiento, velocidad de procesador, Dispositivos
perifricos (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 mquina,
sistemas operacionales, lenguajes de
programacin, manejadores de bases de datos, rutinas de acceso, herramientas
de consulta, etc.
3.5.4.3.2.2 De Utilidad.
Anteproyecto
44
Software de aplicacin,
desarrollo mixto.
software existente en el mercado, desarrollo interno,
3.5.5 ESTIMATIVOS DE DESARROLLO DEL SISTEMA.

Se busca proyectar, de acuerdo a la definicin y caractersticas del sistema
propuesto y recursos disponibles para el mismo, el tamao, tiempo de duracin,
nmero de personas, esfuerzo y costos de desarrollo que tendra la duracin del
proyecto de desarrollo (ciclo de vida de desarrollo).
Un ejemplo de estimativos, es el hecho de proyectar, para una aplicacin con GUI
(Interfases Grficas), el costo de la misma. Dichas aplicaciones se concentran
altamente en la creacin 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 ANLISIS 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, Tcnica, 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 Econmicos.
Estos se determinan a partir de los objetivos cuantificables. Expresados en
perodos de tiempo (por ejemplo: Reduccin del costo de papelera en $100.000
mensuales) y definidos segn la duracin del ciclo de operacin o ejecucin.
Si el ciclo de vida de operacin del proyecto, en el ejemplo es de 36 meses(3
aos), entonces el beneficio econmico sera
ITEM
Anteproyecto
REDUCCIN MENSUAL
TIEMPO DE CICLO
DE OPERACIN
REDUCCIN
TOTAL
45
Papelera
$ 100.000
36(3 Aos)
$3600.000
Se deben mirar aspectos como:

Reduccin de personal,
disminucin 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 estn definidos en trminos
de incrementos de utilidades y rebajas de costos, aspectos que son tangibles
financieramente hablando.
3.5.6.1.1.2 No Econmicos.
Se involucran los siguientes aspectos:
Organizacin y control, Informacin ms completa y segura, oportunidad en la
informacin, mejor ambiente operativo, mayor good will, etc.
Aqu tambin 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, conversin y preparacin de
archivos y documentos, pruebas del sistema, capacitacin, 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
cdigos de barras, impresoras de fines especficos, plotters, etc.
Estos costos se adicionarn al sistema.
3.5.6.1.2.3 De Operacin.
Anteproyecto
46
Se debe tratar de llegar a evaluar costos para factores como:

Resistencia al cambio, mayor carga de trabajo, indisposicin 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
duracin real del proyecto, sin tener en cuenta el los egresos durante el tiempo
de operacin del proyecto .
Ejemplo: A continuacin 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
Papelera
Internet
Computador
Transporte
Asesor
Total
Totales Recursos Administrativos

Concepto
Recurso Humano
Lenguaje de programacin
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
$
% *:'
,+
; <=
' >
;
!
<
CDE
711122
6
,
6 -
Anteproyecto
48
COSTOS
)
" '/0&
$$$
!
"!#$
!
"$
2
1
%
&
" 3&
'4$&
$$$
2
'
(
" #&
0#$&
$$$
" #$%&
$'$(
$$
" '$&
$%'&
$'$
BENEFICIOS
Personal
Jefe de
Departamento
Secretaria
Transporte
Mensajero
Anteproyecto
Salario / Mes Reduccin 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
Finalizacin 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 operacin.
Que los beneficios sean mayores a los costos.
Si los beneficios no se pueden expresar en trminos econmicos, los no
econmicos deben tener el suficiente peso administrativo, como para
incurrir en los costos econmicos.
Que los costos intangibles no sean lo suficientemente altos como para
anular los beneficios econmicos.
Si todo esto se cumple, el proyecto es factible financieramente.

3.5.6.2 Factibilidad Tcnica.
Se determina evaluando el software y hardware de soporte necesarios para el
sistema, teniendo en cuenta los recursos que consumira su desarrollo y
operacin posterior.
En caso de no existir algunos de estos recursos en la empresa, el sistema seguir
siendo factible tcnicamente 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 disposicin 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 adecuacin y cambio de normas administrativas y operativas
necesarias para que el sistema funcione.
d) Viabilidad en la adecuacin fsica 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, tcnica y operativa, es la actividad ms
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 idneos (factibilidad operativa), no se puedan implementar por falta de
Anteproyecto
50
presupuesto (factibilidad financiera) o no se puedan realizar dado que la

tecnologa de la organizacin no es adecuada (factibilidad tcnica).
Lo anterior, para concluir que el sistema debe cumplir los tres aspectos de
factibilidad para que sea viable su realizacin. En caso de que alguna se
cumpliera y fuera de vital importancia se puede tomar tambin la decisin de llevar
a cabo el proyecto
3.5.7 ALTERNATIVAS Y RECOMENDACIONES.
El desarrollo de un sistema ofrece mltiples 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 accin a la administracin para que tome la decisin ms acertada.
Para cada alternativa deben existir ventajas y desventajas que se deben
bosquejar por parte del grupo.
Las alternativas pueden ser muy variadas y dependern de las circunstancias de
cada proyecto y del entorno tecnolgico.
Las alternativas variarn de acuerdo con:
Alcance del sistema, modo de procesamiento, nivel de detalle del desarrollo,
recursos requeridos, situacin financiera, situacin tcnica, etc.
El grupo, por ltimo, deber recomendar la alternativa ms adecuada, de acuerdo
con su juicio, para que los directivos (usuarios dueos), tomen la decisin ms
adecuada posible.
Se deben plantear como mnimo tres alternativas de solucin 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 ejecucin del sistema.
Da la base para la evaluacin y control del avance del proyecto.
normalmente el diagrama de Gantt.
Se utiliza
Al final de la encuesta o estudio de factibilidad:

Una estimacin puede variar en ms o menos un 50 por ciento. Se puede decir
entonces, que el sistema tardar un ao y costar $2000.000, ms o menos un
Anteproyecto
51
50 %. En realidad puede demorarse 18 meses y costar $3000.000.

Al final de anlisis, la estimacin puede variar en ms o menos un 25%
Al final del diseo, puede variar en ms o menos un 10%.
En la fase de programacin, cuando faltan las pruebas, se desfasar en ms 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
ANLISIS
Sistema actual
Requerimientos
Sistema propuesto
Revisin
DISEO
Diseo Global
Diseo Detallado
Base de Datos
Prototipo
Revisin
CONSTRUCCION
PRUEBAS
PUESTA EN
MARCHA
OCTUBRE NOVIEMBRE DICIEMBRE

1 2 3 4 1 2 3 4 1 2 3 4
ENERO
2 3 4
FEBRERO
1 2 3 4
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 DECISIN FINAL.

Tan pronto se desarrollen todos los puntos anteriores, se efectuarn los siguientes
pasos:
Revisin final del documento generado en el Anteproyecto, por parte del grupo.
Entrega del documento al comit de sistemas (Si existe el comit).
Anlisis del documento por parte del comit y decisin final sobre la alternativa
de desarrollo ms apropiada.
En otro caso, la no realizacin del proyecto.
Anlisis
54
3.6 RESUMEN.
ENTRADAS
PROCESO
Requerimientos de 1. Reconocimiento
Informacin de
General del
usuarios.
sistema.
1.1 Ubicacin general
Recursos de
del sistema.
Sistemas.
1.2 Alcance.
Normas, Polticas. 1.3 Objetivos.
2. Definicin del
Sistema.
2.1 Medio Ambiente.
2.2 Entradas y
salidas.
2.3 Relaciones.
3. Recursos para el
desarrollo.
3.1 Econmicos.
3.2 Personal.
3.3 Hardware.
3.4 Software.
4. Estimativos de
desarrollo.
5. Anlisis de
Factibilidad.
5.1 Financiera.
5.2 Tcnica.
5.3 Operativa.
6 Alternativas y
Recomendaciones.
7. Decisin Final.
8. Cronograma.
Anlisis
PARTICIPACION
Usuario Lder.
Analistas.
Usuarios (Todos).
Analistas.
SALIDAS
Anteproyecto.
Documentacin
.
Cronograma.
Usuario Lder.
Analistas.
Analistas.
Usuario.
Analistas.
Analistas.
Usuario Lder.
Analistas.
55
4. ANLISIS.
CONCEPTOS Y PRINCIPIOS DEL ANLISIS LIBRO

PRESSMAN PAG 181 A LA 189, 196, 199 a la 216
El anlisis de requisitos del sistema constituye el primer intento de comprender
cul va a ser la funcin y mbito de informacin de un nuevo proyecto. El objetivo
es conseguir representar un sistema en su totalidad, incluyendo hardware,
software y personas, mostrando la relacin entre los diversos componentes y sin
entrar en la estructura interna de los mismos. En algunos casos se nos plantearn
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:
Cunto tiempo debe dedicarse al anlisis del sistema? Depender de la

naturaleza, el tamao y la complejidad de la aplicacin. Una directriz que
se podra aplicar es dedicar entre un 10% y un 20% del esfuerzo total
estimado al anlisis del sistema y otro 10% o 20% al anlisis de requisitos
del software. El esfuerzo que se le dedica normalmente es mucho menor:.
En la mayora de los proyectos la mayor parte del esfuerzo se va en la
codificacin, precisamente por la dificultad de realizar la codificacin
cuando no se ha hecho un buen anlisis previo.
Quin debe hacerlo? La respuesta es fcil: el analista de sistemas. Este

debe ser una persona con buena formacin tcnica y con experiencia. No
obstante, el analista no trabaja de forma aislada sino en estrecho contacto
con el personal de direccin, tcnico y administrativo tanto del cliente como
del que desarrolla el software.
Por qu es una tarea tan difcil? Bsicamente porque consiste en la

traduccin de unas ideas vagas de necesidades de software en un
conjunto concreto de funciones y restricciones. Adems el analista debe
extraer informacin dialogando con muchas personas y cada una de ellas
se expresar de una forma distinta, tendr conocimientos informticos y
tcnicos distintos, y tendr unas necesidades y una idea del proyecto muy
particulares.
Anlisis
56
4.1.1 OBJETIVOS.
El papel del analista de sistemas es el de definir los elementos de un sistema
informtico 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 representacin de la funcin del sistema, de la
informacin que maneja, de sus interfaces y del rendimiento y las restricciones del
mismo.
En la mayora de los casos, el proyecto empieza con un concepto ms bien vago y
ambiguo de cul es la funcin 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 rpidamente en caso de que la seal de entrada supere
los lmites de seguridad sino que hay que definir cules son los lmites de
seguridad de la seal de entrada, en cunto tiempo debe producirse la reaccin y
cmo ha de ser esta reaccin.
Una vez que se ha logrado delimitar la funcin, el mbito de informacin, las
restricciones, el rendimiento y las interfaces del sistema, el analista debe proceder
a la asignacin 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 asignacin (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
decisin. Para explicar todo lo anterior podemos poner el siguiente ejemplo:
Especificacin informal del sistema de clasificacin de paquetes.
El sistema de clasificacin 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 cdigo numrico) 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
distribucin aleatoria y estn espaciados de manera uniforme. La velocidad de la cinta
debe ser tan alta como sea posible; como mnimo 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 mxima de 20 paquetes por minuto. El sistema debe funcionar las 24 horas
del da, siete das a la semana.
Anlisis
57
Funcin del sistema.
Realizar la clasificacin de paquetes que llegan por una cinta transportadora en

seis compartimentos distintos, dependiendo del tipo de cada paquete.
Informacin que se maneja.
Los paquetes disponen de un cdigo numrico de identificacin.

Debe existir una tabla o algoritmo que asigne a cada nmero de paquete el
contenedor donde debe ser clasificado.
Interfaces del sistema.
El sistema de clasificacin se relaciona con otros dos sistemas. Por un lado

tenemos la cinta transportadora. Parece conveniente que el sistema de clasificacin 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 clasificacin (por ejemplo si se produce una avera). Por otro
lado, el sistema deposita paquetes en los contenedores, pero no se establece ningn
mecanismo de vaciado o sustitucin de los contenedores si se llenan. El sistema debera
ordenar la sustitucin o vaciado del contenedor o esperar mientras un contenedor est
lleno.
Como la descripcin 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 ms 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
averen.
El documento no indica restricciones sobre la eficacia del sistema, es decir, sobre
cul es el porcentaje mximo que se puede tolerar de paquetes que pueden ser clasificados
de forma errnea. Estos detalles tambin deben ser aclarados con el cliente.
Anlisis
58
Asignacin de funciones.
Podemos considerar tres asignaciones posibles:

Asignacin 1.
Esta asignacin propone una solucin manual para implementar el sistema. Los
recursos que utiliza son bsicamente personas, y se requiere adems algo de
documentacin, definiendo las caractersticas del puesto de trabajo y del sistema de turnos
y una tabla que sirva al operador para relacionar los cdigos de identificacin de los
paquetes con el contenedor donde deben ser depositados.
La inversin necesaria para poner en marcha este sistema es mnima, pero
requiere una gran cantidad de mano de obra (varios turnos de trabajo y operadores de
guardia) con lo que los costes de funcionamiento sern elevados. Adems hay que tener en
cuenta que lo rutinario del trabajo provocar una falta de motivacin 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 opcin.
Asignacin 2.
En este caso, la solucin es automatizada. Los recursos que se utilizan son:
hardware (el lector de cdigos de barras, el controlador, el mecanismo de distribucin),
software (para el lector de cdigos de barras y el controlador, y una base de datos que
permita asignar a cada cdigo su contenedor) y personas (si en caso de avera la
distribucin se va a hacer manualmente). Cualquiera de los elementos hardware y
software tendrn la correspondiente documentacin sobre cmo han sido construidos y un
manual de usuario.
Aqu si hay que realizar una cierta inversin, para comprar o desarrollar los
componentes del sistema, pero los costes de funcionamiento sern sin duda menores (slo
el consumo de energa elctrica). Hay que tener en cuenta que el uso de dispositivos
mecnicos (el mecanismo de distribucin) va a introducir unos costes de mantenimiento y
paradas por avera o mantenimiento con una cierta frecuencia.
Asignacin 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 clasificacin) y la
documentacin y manuales correspondientes a estos elementos.
En este caso la inversin inicial es, sin duda, la ms elevada. Los costes de
funcionamiento son bajos pero hay que considerar tambin el coste de mantenimiento del
robot, que posiblemente tenga que ser realizado por personal especializado. Los nicos
motivos que nos haran decidir por esta opcin en vez de la anterior vendran dados por
una mayor velocidad, un menor nmero de errores o unas menores necesidades de
mantenimiento o frecuencia de averas.
Por otra parte esta solucin puede tener problemas de viabilidad (si no
encontramos un brazo robot que sea capaz de atrapar los paquetes segn pasan por la
cinta).
Anlisis
59
Adems de las tres opciones propuestas, el ingeniero de sistemas debe

considerar tambin la adopcin de soluciones estndar al problema. Hay que
estudiar si existe ya un producto comercial que realice la funcin 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 tambin en
cuenta los costes del mantenimiento y el riesgo que se asocia al depender de una
tecnologa que no es propia (es la empresa proveedora estable?, cul 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.
Despus, 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 informacin actual y de

TODOS los requerimientos y necesidades de informacin adicionales.
Realizar una reevaluacin del preanlisis, con base en un conocimiento ms
detallado del sistema, que permita hacer estimativos ms reales, llegando a
determinar factibilidades, alternativas y cronogramas ms precisos, adems de
confirmar o aclarar completamente el alcance planteado anteriormente.
Servir de puente de comunicacin entre la parte administrativa y la parte
tcnica. Se traduce el lenguaje del usuario a un lenguaje de sistemas, que
permita su desarrollo posterior.
Emitir una formulacin especfica de los modelos lgicos, 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 diseo.
Encontrar lo que la organizacin requiere que se haga antes de comenzar a
imaginarse cmo hacerlo.
4.1.2 DEFINICION.
Anlisis
60
Es la transformacin disciplinada de los requerimientos de informacin de un

sistema o rea, en una ESPECIFICACION FUNCIONAL, expresada en trminos
lgicos y usando metodologas estndares.
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?
Grficamente:
De la definicin anterior, es conveniente aclarar los siguientes trminos:

REQUERIMIENTO:
Es una necesidad de informacin que debe satisfacer un sistema. Slo
representa lo que el usuario piensa, debe contemplar el sistema. No es
necesariamente lo que en realidad necesita o es conveniente.
ESPECIFICACIN FUNCIONAL:
Es el documento donde se consigna en forma lgica y ordenada lo que el sistema
debe hacer, a travs de la descomposicin del mismo en subsistemas. Para ello,
se ESPECIFICAN a travs de diferentes herramientas tcnicas, 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 informacin.
Anlisis
61
3. Revisar el preanlisis.
4. Proponer el nuevo sistema.
5. Planear actividades futuras.
4.2 IMPORTANCIA DEL ANLISIS.
Logra integrar las necesidades y requerimientos de informacin de un rea, en un
modelo ordenado, entendible por directivos y usuarios, permitiendo la maduracin
y perfeccionamiento del nuevo sistema de informacin, llegando a los ms
mnimos niveles de detalle.
4.3 CARACTERSTICAS DEL ANLISIS.
Existe dificultad de comunicacin entre analistas y usuarios. No hay un

lenguaje comn entre usuarios y analistas.
Se crean relaciones interpersonales, que en ocasiones desvan al grupo de los
objetivos del proyecto.
El desarrollo del anlisis se efecta basado en el continuo dilogo 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 informacin de un rea no son estticas; 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 PARTICIPACIN REQUERIDA.
La elaboracin de sta etapa, supone un grupo de trabajo conformado por
usuarios, analistas y auditores.
USUARIOS:
Personas de la administracin que de una u otra forma se beneficiarn de la
informacin suministrada por el sistema. Se clasifican en :
USUARIO DUEO:
Corresponde al dueo de la empresa o al alto directivo que tiene como
responsabilidad velar por los objetivos generales de la organizacin. Decide si el
sistema se desarrolla o no, con base en el estudio de factibilidad.
USUARIO RESPONSABLE:
Anlisis
62
Define el nuevo sistema, de acuerdo a los requerimientos de informacin

existentes. Es una persona de mandos medios.
USUARIO FINAL:
Es quien utiliza directamente el sistema.
La participacin del usuario es importante porque :
Asegura que el sistema sea aceptado.

Reduce la oposicin 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 implementacin (en ocasiones, el grupo de
implementacin, son los mismos analistas).
Debe tener conocimientos
administrativos, de las reas de la empresa, de relaciones humanas, de sistemas.
Debe ser un gua, un orientador para canalizar inquietudes del usuario respecto a
las posibilidades tcnicas.
Debe ser lder, con capacidad de influir sobre el grupo.
Debe demostrar seguridad y confianza y ser un gran comunicador.
Debe ser un investigador, ya que el anlisis es un proceso de descubrimiento.
Se puede dar el lujo de suponer una tecnologa perfecta, ya que su trabajo va ms
enfocado a descubrir procesos y requerimientos.
AUDITORES DE SISTEMAS:
Tienen como finalidad velar por la inclusin de los controles internos en el sistema
y de los requerimientos propios de la auditoria.
4.5 PASOS EN EL DESARROLLO DEL ANALISIS.
en el anlisis de un sistema de informacin. Cada una de estas tareas debe estar
claramente documentada, en el manual de factibilidad del sistema.
Anlisis
63
4.5.1 ANALISIS DEL SISTEMA ACTUAL.

Se busca conocer con todo el detalle, cul es el funcionamiento actual del rea y
en especial, cul es el MANEJO Y FLUJO DE LA INFORMACIN PRODUCIDA Y
QUE LLEGA AL REA. Es una labor totalmente descriptiva y de conocimiento por
parte del grupo. Incluye:
Definicin de objetivos y funcionamiento del rea.

Informacin que alimenta al sistema.
Definicin de los procesos de informacin existentes, qu hacen, cmo lo
hacen, con qu informacin lo hacen y qu resultados arrojan.
Esto se logra a travs de diferentes medios:
Manuales de normas administrativas y operativas.

Manuales de procedimientos administrativos y operativos.
Diagramas de flujo de documentos.
Entrevistas con usuarios.
Observacin directa de los procesos y manejo de la informacin.
4.5.2 ANLISIS REQUERIMIENTOS DEL NUEVO SISTEMA.

Se pretende conocer con todo el detalle, cules son los requerimientos de
informacin del usuario. El usuario presenta inquietudes que l mismo NO sabe si
pueden ser resueltas y omite otras que considera secundarias. Comprende:
Anlisis
64
Conocimiento de la lista de necesidades y nuevos requerimientos de

informacin del usuario (al detalle).
Exploracin de otros posibles requerimientos del sistema, teniendo en cuenta
las posibilidades tcnicas de cmputo y las necesidades futuras del rea.
Clasificacin y agrupacin de los requerimientos.
Normalmente esta informacin se obtiene a travs de entrevistas con el usuario y
de observacin directa de los procesos.
4.5.3 REVALUACIN DEL PREANLISIS.
Luego de conocer en detalle el funcionamiento del sistema actual y la definicin
concreta de los requerimientos del nuevo sistema, se debe hacer una
reevaluacin de los puntos tratados en el estudio de factibilidad, debido a que en
la primera etapa no se conoca en forma detallada el sistema. Puede incluir:
Modificacin de la definicin del sistema.

Modificacin de los recursos asignados.
Modificacin de los estimativos.
Inclusin de nuevas alternativas de desarrollo.
Cambios en la factibilidad del sistema.
Modificacin al cronograma.
Slo se revala 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 anlisis, donde se representan los requerimientos del
sistema (nuevos y actuales), en un MODELO LOGICO y ESTRUCTURADO que
de respuesta a las verdaderas necesidades de informacin 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 ANLISIS ESTRUCTURADO. Las especificaciones
deben contener:
Definicin del flujo o recorrido de informacin en el sistema, partiendo de donde

se origina hasta llegar a su destino final. Puede ser en forma narrativa o a
travs de grficas.
Anlisis
65
Definicin de las estructuras de informacin requeridas en el sistema.

Descripcin de cada uno de los procesos o funciones que realiza el sistema.
Definicin de las interfases o relaciones existentes entre los procesos del
sistema.
Definicin de relaciones entre los almacenamientos de informacin requeridos
por el sistema.
Una herramienta para la elaboracin de especificaciones funcionales es el
Anlisis Estructurado, que se ver en detalle ms tarde.
4.5.5 REVISIN DEL ANLISIS.
Busca obtener aprobacin de lo realizado en el anlisis. Participantes:
Usuario dueo, usuarios responsables, analistas, auditor, director de sistemas.
Se debe revisar:
Que estn completos todos los requerimientos formulados por el usuario.

Que sea factible la adecuacin de normas y procedimientos para la
implantacin del sistema.
Que las especificaciones estn bien definidas tcnicamente: procesos,
almacenamientos, relaciones.
Que estn considerados los requerimientos de auditora.
Que las especificaciones contemplen todos los aspectos necesarios para el
diseo.
Que exista documentacin.
Que haya acuerdo entre las partes.
TCNICAS DE REVISIN.
Existen mltiples tcnicas que ayudan al grupo en la tarea de revisin de las
especificaciones resultantes en la etapa del anlisis. Puede decirse que cada
sistema define su propia tcnica de revisin. Sin embargo, formalmente, estas
tcnicas se pueden clasificar as:
DETALLADA
SUPERFICIAL
INFORMALES
Muy Productiva
No recomendadas
FORMALES
Optimas para el control
No recomendadas
La eleccin del grado de detalle y formalidad, depende de la importancia del

sistema, estilo administrativo de la empresa y de la auditora.
La revisin obliga a reforzar la calidad del anlisis y resuelve dudas entre los
interesados.
Anlisis
66
4.5.6 ENTREGA A LA ETAPA DE DISEO.

Despus de efectuar la revisin de las especificaciones y realizar los ajustes del
caso, se hace entrega de las especificaciones al diseador.
4.6 METODOLOGAS DE ANLISIS.
Existen diferentes enfoques metodolgicos para acometer esta fase del desarrollo
de sistemas de informacin. Algunos son:
4.6.1 METODOLOGIAS TRADICIONALES.
Se originaron a partir de los aos 50, con el uso del computador, como
herramienta para procesar datos. Sus caractersticas son:
Son totalmente narrativas.

No hay una definicin clara de las diferentes actividades que encierra el
anlisis.
No existen ayudas grficas.
Con stas metodologas, se presentan algunos inconvenientes como :
No se puede obtener una visin global e integrada del sistema.
No hay documentacin completa, se dificulta la revisin y administracin del
sistema.
Se generan mayores costos, pues hay mayor mantenimiento.
No se puede realizar diseo estructurado.
Existe poca estandarizacin de tareas y actividades.
4.6.2 METODOLOGIAS ESTRUCTURADAS.
Se originan a partir de los aos 70. Se fundamentan en una visin global del
sistema que luego se detalla para cada una de las funciones, logrando un mejor
entendimiento y organizacin de cada una de ellas.
Su clasificacin se mir anteriormente en el captulo de Introduccin.
Caractersticas:
Enfatiza en el mtodo TOP DOWN (visin que va de lo general a lo especfico).

Se tiene una visin integral del sistema a estudiar.
Es totalmente grfica.
Posee un alto grado de estandarizacin en sus tareas.
Se presta para posibles inclusiones de modificaciones futuras.
La parte textual es complementaria de la grfica, a nivel de apoyo y aclaracin.
Permite ver el sistema por segmentos, en forma descendente.
Anlisis
67
Se trata de manejar redundancia mnima en cuanto a las tareas a ejecutar.

Es transparente para el lector, otorgando un entendimiento rpido y global del
sistema.
Ayuda a predecir el comportamiento del sistema en el futuro.
Algunos inconvenientes que se presentan en estas metodologas, son:
Se debe preparar una documentacin muy extensa, para las diferentes tareas
que se deben realizar.
Se emplea mayor tiempo para su desarrollo, ya que exige mayor planeacin y
conocimiento del sistema.
Se debe contar con personal capacitado en la metodologa.
4.7 ANLISIS DE REQUISISTOS.

La ingeniera de requisitos del software es un proceso de descubrimiento,
refinamiento, modelado y especificacin. 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 informacin y
control, y del comportamiento operativo. Se analizan soluciones alternativas y el
modelo completo del anlisis es creado. Donald Reifer describe el proceso de
ingeniera de requisitos del software en el siguiente prrafo:
La ingeniera de requisitos es el uso sistemtico de procedimientos, tcnicas,
lenguajes y herramientas para obtener con un coste reducido el anlisis,
documentacin, evolucin continua de las necesidades del usuario y la
especificacin del comportamiento externo de un sistema que satisfaga las
necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniera
son semejantes, la ingeniera de requisitos no se gua por conductas espordicas,
aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemtico de
aproximaciones contrastadas.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de
requisitos del software un conjunto de actividades que son denominadas
anlisis. El cliente intenta replantear un sistema confuso, a nivel de descripcin de
datos, funciones y comportamiento, en detalles concretos. El desarrollador acta
como un interrogador, como consultor, como persona que resuelve problemas y
como negociador.
4.7.1 VISTAZO RPIDO
Qu es? El papel global del software en un gran sistema es identificado durante la
ingeniera del sistema (Libro: Ingeniera del software 5 edicin Roger Pressman
Captulo 10). De cualquier manera, es necesario considerar una visin lo ms
profunda posible del papel del software para comprender los requisitos
Anlisis
68
especficos que deben ser considerados en la construccin de un software de alta

calidad. Este es el trabajo del anlisis de requisitos del software. Para realizar el
trabajo adecuadamente, se deben seguir un conjunto de conceptos y principios
fundamentales.
Quin lo hace? Generalmente, el ingeniero del software es quin realiza el
anlisis de requisitos. En cualquier caso, para aplicaciones de negocio complejas,
un analista de sistemas formado en los aspectos del negocio del dominio de
la aplicacin puede realizar esta tarea.
Por qu es importante? Si no analizas, es muy probable que construyas una
solucin software muy elegante que resuelva incorrectamente el problema. El
resultado es tiempo y dinero perdido, frustracin personal y clientes descontentos.
Cules son los pasos? Los requisitos de datos, funciones y comportamiento son
identificados por la obtencin de informacin facilitada por el cliente. Los
requisitos son refinados y analizados para verificar su claridad, completitud y
consistencia. La especificacin se incorpora al modelo del software y es validada
tanto por el ingeniero del software como por los clientes/usuarios.
Cul es el producto obtenido? Una representacin efectiva del software debe
ser producida como una consecuencia del anlisis de requisitos. Tanto los
requisitos del sistema como los requisitos del software pueden ser representados
utilizando un prototipo, una especificacin o un modelo simblico.
Cmo puedo estar seguro de que lo he hecho correctamente? El resultado
obtenido del anlisis de requisitos del software debe ser revisado para conseguir:
claridad, completitud y consistencia.
El anlisis y la especificacin de los requisitos puede parecer una tarea
relativamente sencilla, pero las apariencias engaan. El contenido de comunicacin
es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de
informacin. Es muy probable que haya ambigedad. El dilema al que se enfrenta el
ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un
cliente annimo: 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 anlisis de los requisitos es una tarea de ingeniera del software que cubre el
hueco entre la definicin del software a nivel sistema y el diseo del software
(Figura a continuacin) El anlisis de requisitos permite al ingeniero de sistemas
especificar las caractersticas operacionales del software (funcin, datos y
rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El anlisis de requisitos del software puede dividirse en cinco reas de esfuerzo: (1)
reconocimiento del problema, (2) evaluacin y sntesis, (3) modelado. (4)
especificacin y (5) revisin. Inicialmente, el analista estudia la Especificacin 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 planificacin. A continuacin, se debe
establecer la comunicacin para el anlisis de manera que nos garantice un
Anlisis
69
correcto reconocimiento del problema. El objetivo del analista es el reconocimiento

de los elementos bsicos del problema tal y como los percibe el cliente/usuario.
La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal
de esfuerzo en el anlisis. El analista debe definir todos los objetos de datos
observables externamente, evaluar el flujo y contenido de la informacin, definir y
elaborar todas las funciones del software, entender el comportamiento del software
en el contexto de acontecimientos que afectan al sistema, establecer las
caractersticas de la interfaz del sistema y descubrir restricciones adicionales del
diseo. Cada una de estas tareas sirve para describir el problema de manera que
se pueda sintetizar un enfoque o solucin global.
Por ejemplo, un mayorista de recambios de automviles 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 rpidamente el estado
de un componente: (2) dos o tres das de media para actualizar un archivo a base
de tarjetas; (3) mltiples 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 informacin va a producir
el nuevo sistema y qu informacin se le proporcionar al sistema. Por ejemplo, el
cliente desea un informe diario que indique qu piezas se han tomado del inventario
y cuntas piezas similares quedan. El cliente indica que los encargados del
inventario registrarn el nmero de identificacin de cada pieza cuando salga del
inventario.
Figura. 4.7.1 Anlisis como puente entre la ingeniera y el diseo de software.
Una vez evaluados los problemas actuales y la informacin deseada (entrada y

salida), el analista empieza a sintetizar una o ms soluciones. Para empezar,
se definen en detalle los datos, las funciones de tratamiento y el comportamiento
Anlisis
70
del sistema. Una vez que se ha establecido esta informacin, se consideran

las arquitecturas bsicas para la implementacin. Un enfoque cliente/servidor
parecera apropiada, pero est dentro del mbito esbozado en el Plan del
Software'? Parece que sera necesario un sistema de gestin de bases de
datos, pero, est justificada la necesidad de asociacin del usuario/cliente? El
proceso de evaluacin y sntesis contina 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 evaluacin y sntesis de la solucin, el enfoque primario del
analista est en el qu y no en el cmo. 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 evaluacin y sntesis de la solucin, 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 informacin. El
modelo sirve como fundamento para el diseo del software y como base para la
creacin de una especificacin del software.
4.7.2 IDENTIFICACIN DE REQUISITOS PARA EL SOFTWARE

Antes que los requisitos puedan ser analizados, modelados o especificados, deben
ser recogidos a travs de un proceso de obtencin. Un cliente tiene un problema que
pretende sea resuelto con una solucin basada en computadora. Un desarrollador
responde a la solicitud de ayuda del cliente. La comunicacin ha empezado. Pero
como ya hemos sealado, el camino de la comunicacin al entendimiento est a
menudo lleno de baches.
4.7.2.1 Inicio del proceso
La tcnica de obtencin de requisitos ms usada es llevar a cabo una reunin o
entrevista preliminar. La primera reunin 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 estn preocupados de que lo que digan sea malentendido;
ambos piensan qu pasar (los dos pueden tener expectativas radicalmente diferentes);
los dos estn deseando que aquello termine, pero, al mismo tiempo, ambos desean
que la cita sea un xito.
Sin embargo, hay que empezar la comunicacin. Gause y Weinberg [GAU89]
sugieren que el analista empiece preguntando cuestiones de contexto libre. Es decir,
Anlisis
71
un conjunto de preguntas que llevarn a un entendimiento bsico del problema, qu

solucin busca, la naturaleza de la solucin 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
podra preguntar:
Quin est detrs de la solicitud de este trabajo?
Quin utilizar la solucin?
Cul ser el beneficio econmico del xito de una solucin?
Hay alguna otra alternativa para la solucin que necesita?
Estas preguntas ayudan a identificar todos los participantes que tienen un inters en el
software a construir. Adems, las preguntas identifican los beneficios medibles en una
implementacin 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 solucin:
Cmo caracterizara una buena salida (resultado) generada para una buena
solucin?
A qu tipo de problema(s) va dirigida esta solucin?
Puede mostrarme (o describirme) el entorno en que se utilizar la solucin?
Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de
enfocar la solucin?
El ltimo conjunto de preguntas se concentra en la eficacia de la reunin. 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 ms que pueda proporcionar informacin adicional?
Hay algo ms que debera preguntarle?
Estas preguntas (y otras) ayudarn a romper el hielo e iniciar la comunicacin tan
esencial para el xito del anlisis. Pero el formato de reunin tipo pregunta y
respuesta no es un enfoque que haya tenido mucho xito. De hecho, esta sesin
de preguntas y respuestas debera emplearse solamente en el primer encuentro y
sustituirse despus por una modalidad que combine elementos de resolucin del
problema, negociacin y especificacin. En la siguiente seccin se presenta un enfoque
a reuniones de este tipo.
4.7.2.2 Tcnicas para facilitar las especificaciones de una aplicacin
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
travs de una serie de memorandos, papeles de posiciones formales, documentos y
sesiones de preguntas y respuestas. La historia ha demostrado que este mtodo no
Anlisis
72
funciona muy bien. Abundan los malentendidos, se omite informacin importante y

nunca se establece una buena relacin de trabajo.
Con estos problemas en mente es por lo que algunos investigadores independientes
han desarrollado un enfoque orientado al equipo para la reunin de requisitos que
se aplica durante las primeras fases del anlisis y especificacin. Denominadas
Tcnicas para facilitar las especificaciones de la aplicacin (TFEA), este enfoque es
partidario de la creacin 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
solucin. Hoy en da, las TFEA son empleadas de forma general por los sistemas
de informacin, pero la tcnica 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 variacin en las siguientes
directrices bsicas:
La reunin se celebra en un lugar neutral y acuden
tanto los clientes como los desarrolladores.
se establecen normas de preparacin y de participacin.
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 reunin.
Se usa un mecanismo de definicin (que puede ser hojas de trabajo, grficos,
carteles o pizarras).
El objetivo es identificar el problema, proponer elementos de solucin, negociar
diferentes enfoques y especificar un conjunto preliminar de requisitos de la
solucin en una atmsfera que permita alcanzar el objetivo.
Para comprender mejor el flujo de acontecimientos tal y como ocurren en una
reunin TFEA, presentamos un pequeo escenario que esboza la secuencia de
acontecimientos que llevan a la reunin, los que ocurren en la reunin y los que la
siguen.
En las reuniones iniciales entre el desarrollador y el cliente, se dan preguntas y
respuestas bsicas que ayudan a establecer el mbito del problema y la percepcin
global de una solucin. Fuera de estas reuniones iniciales, el cliente y el
desarrollador escriben una solicitud de producto de una o dos pginas. Se
1
selecciona lugar, fecha y hora de reunin 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 reunin.
1
Dos de los enfoques ms populares de TFEA son Desarrollo Conjunto de Aplicaciones/UAD), desarrollado por IBM, y
The METHOD, desarrollado por Performance Resources, Irte, Falls Church, VA.
Anlisis
73
Mientras se revisa la solicitud das antes de la reunin, 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. Adems, se pide a todos los asistentes que hagan otra lista de servicios (procesos o funciones) que manipulan o interactan con los objetos.
Finalmente, se desarrollan tambin listas de restricciones (por ejemplo, costes,
tamao, peso) y criterios de rendimiento (por ejemplo, velocidad, precisin). 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 , imagnese que a un equipo de trabajo TFEA de una compaa de

productos para el consumidor se le ha dado la siguiente descripcin 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 gustara 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 situacin, puede programarse por el propietario del hogar y llamar automticamente a una
agencia de vigilancia cuando se detecte alguna de estas situaciones.
En realidad, se proporcionara considerablemente ms informacin en esta fase.

Pero incluso con informacin adicional, habra ambigedades presentes, existirn
omisiones probablemente y podran ocurrir errores. Por ahora, la descripcin de
producto anterior bastar.
El equipo TFEA est compuesto por representantes de marketing, ingeniera del software
y del hardware, y de la fabricacin tambin participar un coordinador externo.
Todos los componentes del equipo TFEA desarrollan las listas descritas anteriormente.
Los objetos descritos para HogarSeguro podran 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, nmeros de telfono,
una llamada de telfono, etc. La lista de servicios podra incluir la instalacin de la
alarma, vigilancia de los sensores, marcado de telfono, programacin del panel de
control y lectura de la pantalla (fjese que los servicios actan sobre los objetos). De
igual manera, todos los asistentes TFEA desarrollarn una lista de restricciones (por
ejemplo, el sistema debe tener un coste de fabricacin de menos de 80, debe
tener una interfaz amigable con el usuario y debe conectar directamente con una
lnea telefnica estndar) y de criterios de rendimiento (por ejemplo, un acontecimiento
detectado por un sensor debe reconocerse en un segundo; se debera implementar
un esquema de prioridad de acontecimientos).
Cuando empieza la reunin TFEA, el primer tema de estudio es la necesidad y
justificacin del nuevo producto, pues todo el mundo debera estar de acuerdo en
que el desarrollo (o adquisicin) del producto est justificada. Una vez que se ha
2
Ejemplo tomado del libro de Ingeniera del software: Un enfoque prctico De Roger Presuman,
5 Edicin
Anlisis
74
conseguido el acuerdo, cada participante presenta sus listas para su estudio. Las
listas pueden exponerse en las paredes de la habitacin usando largas hojas de
papel, pinchadas o pegadas, o escritas en una pizarra. Idealmente debera poderse
manejar separadamente cada entrada de las listas para poder combinarlas,
borrarlas o aadir otras. En esta fase, est estrictamente prohibido, el debate o las
crticas.
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 aade
las ideas nuevas que se les ocurran durante la presentacin, pero no se elimina nada
ms. 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). Despus 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-especificacin de una o ms
entradas de cada lista4. La mini-especificacin es una elaboracin de la palabra o
frase contenida en una lista. Por ejemplo, la mini-especificacin del objeto panel
de control de HogarSeguro podra ser: montado en la pared; tamao aproximado 23
* 13 centmetros; contiene el teclado estndar de 12 teclas y teclas especiales;
contiene una pantalla LCD de la forma mostrada en el bosquejo (no presentado
aqu); toda la interaccin del cliente se hace a travs 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 aadidos, 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
aadirn a las listas originales. Durante todos los estudios, el equipo sacar a relucir
aspectos que no podrn resolverse durante la reunin. Se har una lista de estas
ideas para tratarlas ms adelante.
Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA
hace una lista de criterios de validacin del producto/sistema y presenta su lista al
equipo. Se crea as una lista de consenso de criterios de validacin. Finalmente,
uno o ms participantes (o algn tercero) es asignado para escribir el borrador entero
de especificacin con todo lo expuesto en la reunin 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 instantneo y un paso adelante hacia
el desarrollo de una especificacin.
Anlisis
75
Lecturas importantes: Capitulo 11 del Libro: Ingeniera del software de

Roger Pressman, 5 edicin.
Aqu voy
MIRAR ESTE DOCUMENTO(ISE3.DOC)
Ya se paso la parte de presuman hasta la pagina 186 Despliegue de la

funcion de calidad
5. ANLISIS ESTRUCTURADO
5.1.1 CONCEPTOS GENERALES.
5.1.1.1 DEFINICIN.
Es una metodologa para desarrollar especificaciones funcionales, usando el
enfoque Top Down. Para generar especificaciones estructuradas de un sistema
de informacin, usa como tcnicas:
Los diagramas de flujo de datos
Los diagramas de estructura de datos
Las miniespecificaciones
Diccionarios de datos.
Anlisis
76
5.1.1.2 CARACTERSTICAS.
Utilizacin de grficas para representar el sistema, evitando al mximo,

descripciones narrativas.
Enfatiza en el flujo de informacin y no en los flujos de control de un sistema.
Presenta una documentacin extensa de cada tarea a realizar.
5.1.2 COMPONENTES.
c
es
n
ci
p
ri
de
os
et
bj
de
Es
p
s
to
da
Diagrama
Entidad-Relacin
(DER)
ec
if
ica
ci
de
Diagrama de
Flujo de datos
pr
oc
es
o
(E
P)
Diccionario de
Datos (DD)
Diagrama de Transicin de datos
Especificacin de control (EC)
Figura 5.1 La Estructura del modelo de anlisis

Se fundamenta en los siguientes componentes:
Descripcin de objetos de datos

Especificaciones de Proceso (EP) o Miniespecificaciones.
Especificacin de control (EC)
Diagramas de Flujo de Datos.
Diccionario de datos.
Diagrama de Transicin de Datos
Diagrama Entidad-Realcin
Anlisis
77
Aqu voy
MIRAR ESTE DOCUMENTO(ISE3.DOC)
Ya se paso la parte de presuman hasta la pagina 186 Despliegue de la

funcion de calidad pagina 200 de pressman
Como se expres anteriormente, el anlisis estructurado es una herramienta para

resolver el problema que plantea la fase de anlisis de un proyecto, el cual es la
construccin 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 situacin
actual del rea a sistematizar, para luego generar la estructura, a travs de estos
modelos, de lo que ser el nuevo sistema de informacin.
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 continuacin, los modelos en detalle.
5.2 MODELO DE PROCESOS.
Busca definir, a travs de las tcnicas anteriores, todos los procesos existentes en
el sistema en estudio, sus funciones, datos de entrada, informacin de salida,
relaciones entre procesos y clculos realizados, con el fin de tener una base
apropiada para disear la estructura futura del sistema.
Anlisis
78
5.2.1 PROPSITO.
Los procesos son parte importante de cualquier sistema de informacin.

Comprenden la serie de transformaciones y clculos que sufre la informacin a
travs del mismo.
Un modelo de procesos completo debe ser lo suficientemente detallado para
que sea til en el diseo 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.
Definicin clara de entradas, salidas, relaciones y procesos.
Una de las tcnicas usadas para determinar un buen modelo de informacin es el
anlisis estructurado, con sus componentes de diagramas de flujo de datos,
diccionario de datos y especificaciones de proceso, que se detallarn a
continuacin.
5.2.2 DIAGRAMAS DE FLUJOS DE DATOS. (DFD).
Es la representacin de un sistema de informacin 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 travs de los cuales fluyen paquetes de informacin de
composicin conocida. Representacin :
Ejemplos :
Asientos Contables, Recibo de Caja, Liquidacin de Matricula.
5.2.2.2 PROCESOS O TRANSFORMACIONES.
Anlisis
79
Son los lugares lgicos donde la informacin sufre cambios o transformaciones,

como consecuencia de clculos u operaciones matemticas y/o lgicas.
Representacin :
Existen algunas reglas con relacin a los procesos :

Ley de Transformacin : Un proceso debe modificar los datos de alguna forma
(la salida debe ser diferente a la entrada).
Ley de Conservacin : La salida de un proceso, debe ser derivable de su
entrada. Slo se le debe dar la informacin suficiente al proceso, para que haga
su trabajo.
Ejemplos :
Validar Datos Cliente, Generar Reportes de Ventas, Calcular Devengados,
Son los lugares donde se acumula la informacin dentro del sistema, con el fn de
ser utilizada por procesos posteriores. Representacin :
Ejemplos :
Clientes, Cuentas, Estudiantes.
Los almacenamiento son pasivos y los datos no viajarn a lo largo del flujo, a
menos que el proceso los solicite explcitamente.
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
informacin del sistema.
Se distinguen dos tipos :
Anlisis
80
FUENTE :
Persona (cargo), organizacin, rea o sistema de donde se origina la informacin
de entrada.
SUMIDERO O DESTINO :
Persona (cargo), organizacin, rea o sistema hacia donde va dirigida la
informacin generada por el sistema.
Representacin :
Ejemplos :
Contabilidad, Nmina, Gerencia.
5.2.2.5 COMO CONSTRUIR UN DIAGRAMA DE FLUJO DE DATOS.
1. Definir flujos de entrada y salida del sistema, adems de fuentes y sumideros,
de donde y hacia donde se dirige la informacin
2. Identificar los procesos.
3. Identificar los almacenamientos necesarios.
4. Identificar los flujos de informacin 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 desempear el sistema ?

Cules 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 dnde obtiene la informacin para llevar a cabo dicha labor ?
Dnde entrega los resultados de su labor ?
Anlisis
81
5.2.2.6 NIVELACION.
Es la divisin de un sistema en subsistemas y de stos en otros, para lograr una
mayor claridad en los procesos, almacenamientos y flujos de informacin
Es el proceso de expandir el Diagrama de flujo de datos general (Nivel 1), en otros
Diagramas que detallan cada vez ms las funciones que se realizan en cada uno
de los procesos.
Nivelacin de un Diagrama de Flujo de Datos.

De la grfica 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 interacta el sistema con el medio ambiente, a travs 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 ms de nueve elementos generales.
Anlisis
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 funcin principal del sistema.
Se detallan las tareas que componen la funcin bsica descrita en el nivel 1.
5.2.2.6.4 Diagrama de Flujo de Datos de Nivel 3 al Nivel N.
Es la expansin sucesiva de procesos del nivel 2 al nivel N-1.
La expansin se realiza hasta que el sistema quede lo suficientemente claro. Es
decir, hasta encontrar la funcin primitiva o atmica, funcin que tiene como
caracterstica 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 nivelacin trata con los procesos, existe tambin otra tcnica que se
interesa en los flujos de datos que aparecen en los diferentes diagramas. Dicha
tcnia 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 expansin.
Se puede realizar una descomposicin ms explcita de las entradas y salidas, en
el diagrama hijo, respetando la equivalencia.
Ejemplo :
Anlisis
83
De la grfica podemos ver por ejemplo, que el flujo de datos F1 se ha

descompuesto en los componentes F11, F12 y F13, para detallar ms el nivel
siguiente del diagrama de flujo de datos.
Un caso real en un sistema de nmina, sera 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 : Cdula,
Nmero de hijos y Direccin, cada uno de los anteriores, afectando la funcin
especfica de nivel ms bajo en el diagrama derivado del nivel 1.
5.2.2.8 CONVENCIONES NUMERICAS.
Cada proceso recibe el nmero del proceso padre, un punto (.) y otro nmero
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 ms expansin se conocen como Procesos o
Funciones Primitivas.
Es importante tener en cuenta el balanceo en los diagramas, dado que son
base para la definicin posterior del modelo de informacin del sistema.
Cada nivel no debe contener ms de nueve procesos.
Llamar cada proceso con un verbo que indique la accion que se realiza.
Numerar los procesos en el orden lgico de operacin del sistema.
Los procesos deben tener informacin que entra (flujos de entrada) e
informacin que sale (flujos de salida).
Si no podemos escribir una especificacin de proceso razonable para una
burbuja en una pgina, es probable que sea demasiado compleja y debiera
partirse en diagramas de menor nivel antes de tratar de escribir la
especificacin.
No se debe hacer en un diagrama :
Anlisis
84
5.2.3 DICCIONARIO DE DATOS (DD).

Es el conjunto organizado de los trminos 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 comn de todas las entradas, salidas, almacenamientos y
clculos intermedios.
Sirve de instrumento para buscar definiciones de trminos 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 revisin 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 :
Anlisis
85
NOMBRE AGENTE :
TIPO AGENTE :
SIGNIFICADO :
OBSERVACIONES :
5.2.3.2 PROCESOS.
Son descritos a travs de otra especificacin funcional llamada Especificaciones
de Proceso Miniespecificaciones.
Formato :
NOMBRE PROCESO :
SIGNIFICADO :
ESPECIFICACION :
OBSERVACIONES :
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 descripcin del almacenamiento, a nivel de
definicin del mismo.
Formato :
Anlisis
86
NOMBRE ALMACENAMIENTO :
SINONIMOS :
COMPOSICION :
OBSERVACIONES :
5.2.3.4 FLUJO DE DATOS.
Se debe definir la composicin de la informacin que fluye por un canal
determinado.
Ejemplo :
Asientos Contables : fecha + nro doc + cta + nit + ident (deb/cred) + valor +
descrip.
Tambin se debe dar una explicacin de cada flujo de datos.
Formato :
NOMBRE FLUJO :
SINONIMOS :
COMPOSICION :
OBSERVACIONES :
Este formato sirve para la definicin de componentes y elementos de datos
tambin.
5.2.3.5 COMPONENTE DE DATOS.
Se debe definir la descomposicin de un flujo de datos, en los diferentes subflujos
que lo conforman, cuando se debe dar mayor claridad a determinados procesos.
Ejemplo :
Informacin empleados = cdigo + nombre + datos personales.
A su vez, datos personales esta conformado as :
Anlisis
87
Datos Personales = direccion + tel + estado civil + profesion + nro hijos.

5.2.3.6 ELEMENTO DE DATOS.
Se define aqu, la composicin de los flujos, a nivel da cada atributo componente,
si as lo amerita el mismo. Si se tiene claridad en la definicin del flujo, esto no se
hace aqu. Es conveniente definirlos ms tarde, en el diseo de la base de datos.
Ejemplo :
edad : Edada de la persona.
Cdula : Nmero de la cdula de ciudadana.
5.2.3.7 CONVENCIONES PARA EL DICCIONARIO.
=
___
+
[ ]
/
{ }
( )
**
Equivalente a.
Clave de almacenamiento.
Adicin de elementos (AND).
Ocurrencia de una sola opcion dentro del corchete.
Separa opciones dentro del corchete.
Repeticin.
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 mximo, pues
originan problemas de integidad, redundancia e interpretacin.
5.2.4 EVENTOS.
5.2.4.1 PROPOSITO.
La tcnica de eventos tiene como propsito 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 relacin con el negocio, en
trminos que ellos pueden comprender fcilmente. Describen el sistema desde la
perspectiva del usuario.
Los teclazos y clics de ratn que son codificados son, a fin de cuentas, una
implementacin directa de los eventos del negocio. Es decir, los programas
responden directamente a los clics y al teclado, tan pronto como estos suceden.
Anlisis
88
A diferencia de la interfase texto, donde haba limitado nmero de eventos, esta

herramienta es til para las interfases grficas, dado que ellas manejan ilimitado
nmero de eventos.
Esta tcnica puede en un momento dado, reemplazar o aclarar la nivelacin 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 organizacin los eventos suceden por todos lados :
Los clientes solicitan productos, los vendedores entregan mercancas, etc. Y cada
vez que pasan cosas de ste tipo, se espera que la organizacin responda de
alguna forma.
Podramos decir entonces, que un evento es algo que sucede a algn elemento
de la organizacin y que adems se espera que esta responda de una forma
adecuada a dicho estmulo.
Algunas reglas para reconocer eventos son :
1.
2.
3.
4.
5.
Todo evento sucede en un momento especfico.

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 modificacin a stos, har variar
notablemente la lista citada.
Ejemplos :
Supongamos el sistema de un contestador automtico de telfonos. Algunos
candidatos a eventos para ste sistema podran ser :
1. Quien llama hace una llamada al propietario.
2. La mquina reproduce saludos previamente grabados.
3. Quien llama se equivoca.
Anlisis
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 reproduccin del saludo es generada por
el sistema, luego no cumple con las reglas 2. y 3. Es una respuesta del sistema.
La oracin (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 lnea, en la lista.
Ejemplo :
El cliente hace un pedido.
El cliente cancela un pedido.
El almacn enva 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 transaccin.
Anlisis
90
Un hilo de evento
De la grfica :
Estmulo : 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 tpica de un evento al diccionario, sera :
Anlisis
91
IDENTIFICACION
NOMBRE
DESCRIPCION
ESTIMULO
ACTIVIDAD
RESPUESTA
EFECTO
150
El almacn enva el pedido del cliente.
Cuando el almacn enva los productos al cliente, se
identifica la compaa 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.
Identificacin del pedido del cliente.
Identificacin de la compaa transportadora.
Nmero de vehculo.
Fecha de envo.
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
Gua transportadora
El transportador debe salir del lugar con la gua. Si el pedido
esta cerrado, entonces se facturar al cliente.
Los componentes del diccionario son :

Identificador : Es un nmero, no significativo.
Nombre : Es una oracin clara que identifica el evento, bajo la sintaxis sujetoverbo-objeto.
Descripcin : Se define cules son las polticas de la organizacin, para el
evento.
Estmulos : 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 estmulo en una respuesta adecuada
para el evento. Es una miniespecificacin de proceso.
Anlisis
92
Se puede apreciar que la tcnica de eventos cubre adecuadamente las

actividades del modelo de procesos, al nivel de identificar requerimientos de
informacin y componentes de proceso.
Aunque el papel de los diagramas de flujo de datos ha disminuido, esta tcnica
sigue siendo til para desarrollar sistemas grandes. El diagrama de flujo de datos
no hace suposiciones acerca de cul programa alojar cualquier poltica de la
organizacin y por esa nica razn es una tcnica valiosa para capturar los
requerimientos antes de disear una estrategia de implementacin.
La actividad es neutral en relacin con el lenguaje de programacin 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 organizacin.
Efecto : Es la poscondicin deseada del ambiente, despus 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/UBICACIN DEL NEGOCIO.
Sirve para determinar que eventos ocurren en qu ubicaciones o sucursales de la
organizacin. Muestra que eventos deben ser reconocidos en cada ubicacin.
EVENTO/UBICACIN
El cliente hace pedido

El departamento de crdito aprueba pedido
MEDELLIN
X
X
CALI
X
RIONEGRO ...
X
...
Por ejemplo, en la sede de Medelln, es posible que sucedan los eventos de

colocar pedidos por parte de los clientes y adems 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 informacin.
Anlisis
93
EVENTO/ENTIDAD
El cliente hace pedido

El departamento de crdito 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
actualizndolas.
5.2.4.5.3 CRUD UBICACIN/ENTIDAD.
Muestra los requerimientos de distribucin de datos de la organizacin y dice
como debe ser el acceso a los datos (local, remoto o una combinacin de ambas).
UBICACIN/ENTIDAD
Medelln
Cali
Rionegro
CLIENTE
CRU
CRU
CRU
PEDIDO
CRU
CR
CR
CPTO PEDI ...

CR
CR
CR
...
Necesitaramos, por ejemplo, ubicar las tablas de Cliente, Pedido y Concepto de

Pedido en Medelln, Cali y Rionegro.
5.2.4.6 DESCUBRIMIENTO DE EVENTOS.
Es fcil descubrir eventos, si tenemos la panormica de nuestro sistema, como
una accin estmulo/respuesta y no como un problema de procesamiento interno.
Algunas tcnicas usadas para descubrir eventos, son :
Entrevistas con usuarios.

Documentacin existente del rea.
El diagrama de contexto.
El modelo de informacin.
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.
Anlisis
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 vehculos 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
facturacin enva 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 mayora de los eventos son inesperados. La clasificacin 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) ?
Cul es el evento predecesor que establece la expectativa ?
Para los eventos inesperados o esperados,
Anlisis
95
El ambiente es (reconocimiento directo) o el sistema (reconocimiento

indirecto) el responsable del reconocimiento del evento ?
Cules son eventos predecesores en la cadena ?
Cules son eventos sucesores en la cadena ?
Estas preguntas ayudarn a crear un modelo ms completo del comportamiento
deseado del sistema.
5.2.4.8 ORGANIZACIN 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 cronolgica, en la forma en que generalmente
suceden. Esta organizacin hace fcil la validacin de ellos por parte del usuario.
Se puede identificar fcilmente los eventos predecesores y sucesores,
inesperados y esperados y buscar seudoeventos que puedan faltar en la lista.
Ejemplo :
El departamento de crdito confirma el lmite de crdito del cliente.
El cliente paga el anticipo sobre el pedido.
El gerente de ventas aprueba el pedido.
El departamento de produccin programa el pedido.
La planta produce el pedido.
La planta enva 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 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.
Anlisis
96
La planta produce el pedido.

La planta enva 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 informacin para poder referirse ms
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
tambin 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 planeacin del proyecto. Se pretende que los
eventos a este nivel definan las reas funcionales del sistema.
Ejemplo :
Area : Captura de Pedidos.
5.2.4.9.2 NIVEL DE NEGOCIOS.
Es el nivel adecuado para la fase de anlisis 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.
Anlisis
97
Despachos programa el envo.

Esta lista pone en evidencia los subtipos de eventos que el sistema deber
reconocer, y ayuda a descubrir los datos requeridos, adems de las polticas
asociadas a cada evento.
Qu tanto se debern aplicar niveles al modelo de eventos, puede ser tema de
discusin. Sin embargo, la experiencia gua al analista hacia una solucin
prctica. Cuando la seccin de actividad del diccionario de eventos comienza a
exceder de una a tres pginas de especificaciones, o cuando existen numerosas
estructuras CASE, probablemente se necesita descomponer ms el evento, ya
sea mediante subtipos o buscando una divisin lgica en la cadena.
5.2.4.9.3 NIVEL DE DIALOGO.
Toma cada evento y lo divide en un dilogo entre el sistema y el usuario. Es til
para la realizacin de prototipos del sistema, adems de ser un buen inicio para la
fase de diseo de la interfase hombre-mquina.
5.2.4.9.4 NIVEL DE DISEO.
El evento es descompuesto todava ms hacia la accin especfica que debe
realizar el usuario para informar completamente al sistema que el evento ha
ocurrido. Incorpora la navegacin por el sistema, botones y menes de las
ventanas.
En resumen, el modelo de eventos es el pegamento que mantiene juntas las
piezas del anlisis, diseo, construccin y prueba. Es la razn por la cual se
contrata la elaboracin de determinado sistema.
La clave de un buen diseo grfico, es la comprensin 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 disear y decidir lo que el usuario no pueda hacer en un momento dado. Un
modelo de eventos slido, tambin ayuda a organizar esta tarea.
Anlisis
98
Niveles de Eventos.
5.3 MODELO DE INFORMACION.
Es la representacin de las relaciones existentes entre los almacenamientos.
Tiene como propsito establecer los caminos de acceso que permitan integrar
toda la informacin almacenada de un sistema.
Es un modelo de red que describe con un alto nivel de abstraccin la distribucin
de datos almacenados en un sistema y sus relaciones.
5.3.1 PROPOSITO.
Los datos son la parte medular de cualquier sistema de informacin.

Comprenden el mapa de la memoria empresarial de cualquier organizacin.
Un modelo de informacin completo que sea lo suficientemente detallado para
que sea til en el diseo, debe incluir :
Diagrama de Estructura de Datos (Entidad Relacin).
Estimaciones de volumen y retencin por entidad.
Atributos por entidad.
Definicin clara de cada entidad, relacin y atributo.
Anlisis
99
Propiedades de los atributos (opcionalidad, tipo de dato, rango, unidad de medida,

precisin y valores restringidos).
Diagrama de Estado-Transicin.
Matrices de Entidad.
5.3.2 ENTIDADES.
Es una cosa que tiene una existencia individual definida en la realidad o en la
mente.
En trminos de ingeniera de software :
Es un sustantivo. Adems puede representar una idea del mundo real como
Cliente, Pedido, etc. o puede representar una abstraccin tal como : Concepto de
Pedido, Acuerdo de Descuento, etc.
Cada instancia individual de cada entidad es nica. Sin embargo, todas tienen
caractersticas 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 caractersticas similares y se
comportan de forma parecida.
Representacin :
Ejemplo :
Anlisis
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 polticas 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 mnimo y un mximo.
El mnimo describe si la relacin es opcional o requerida.
El mximo describe si la relacin es singular o plural.
Del ejemplo anterior, Persona-Perro, se puede preguntar :
1. Debe una persona poseer un perro ?
2. Se puede poseer ms de un perro ?
3. Debe un perro ser siempre propiedad de una persona ?
4. Puede un perro ser propiedad de ms de una persona a la vez ?
La pregunta 1 est diseada para obtener la cardinalidad mnima, cuando se lee
de izquierda a derecha la relacin (persona-perro).
Anlisis
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 dueo hasta que obtenga un
nuevo perro ?. Debemos darle un reemplazo ?.
La pregunta 2 est diseada 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 direccin opuesta (perro-persona).
La pregunta 3 comienza con la entidad perro y se lee hacia atrs, hacia persona,
preguntando si la relacin entre un perro y su dueo es opcional o requerida.
La pregunta 4 se refiere a si permitimos una custodia mltiple de perros o si el
propietario slo puede ser una persona.
La relacin quedara :
En resumen, la cardinalidad de una relacin, est expresada por la cantidad de

ocurrencias mnima y mxima 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.
Anlisis
102
Ejemplo :
Dado el evento EL CLIENTE DEJA PRENDAS EN LA LAVANDERIA, los
elementos de datos identificados all, pueden ser :
Nombre del cliente
Apellido
Nmero telefnico
Fecha de recepcin
Nmero 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 normalizacin 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 antigo problema de los grupos repetidos en conjuntos de
datos.
Nuestro ejemplo en 1FN sera :
PEDIDO
CONCEPTO PEDIDO
Nmero Recibo
Nombre
Apellido
Nmero telefnico
Fecha de recepcin
Fecha de entrega
Hora de entrega
Nmero Recibo
Tipo prenda
Tipo servicio
Cantidad
Precio unitario
Anlisis
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, sera :
PEDIDO
CONCEPTO PEDIDO
TIPO SERVICIO
Recibo
Nombre
Nmero telefnico
Fecha de recepcin
Fecha de entrega
Hora de entrega
Recibo
Tipo prenda
Tipo servicio
Cantidad
(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 negociacin realizada.
La entidad Tipo Servicio, tendra siempre el Precio unitario actual, es decir, el
valor que se cobra por cada servicio de una prenda dada.
Si slo interesa el precio actual, se tendra dicho atributo en la entidad Tipo
Servicio nicamente, con la observacin de que cuando exista un cambio en el
precio, todos los negocios se liquidaran al nuevo precio.
Anlisis
104
Quien aclara la situacin anterior, es slo el usuario, a la luz de las reglas y

polticas establecidas en la organizacin. 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 ms QUE LA CLAVE. (Se eliminan
dependencias transitivas).
De nuestro ejemplo, el nombre, apellido y nmero telefnico del cliente, no son
atributos de Pedido, ya que no dependen de la clave (recibo). Son ms bien
atributos de la entidad Clientes. Tcnicamente se desperdicia espacio cuando
esta informacin se repite por cada pedido colocado.
La 3FN se puede conseguir rpidamente si simplemente se usa una fuerte dosis
de sentido comn 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 quin lo describe completa y
funcionalmente. En otras palabras, que atributo o conjunto de atributos es su
verdadera MADRE. Nuestro ejemplo en 3FN sera :
CLIENTE
PEDIDO
CONCEPTO PEDIDO
Codigo cliente
Nombre
Apellido
Nmero telefnico
Recibo
Codigo cliente
Fecha recepcin
Fecha entrega
Hora prometida
Recibo
Tipo prenda
Tipo servicio
Cantidad
Instrucciones
(Precio unitario)
Anlisis
105
TIPO SERVICIO
Tipo servicio
Tipo prenda
Precio unitario
Tercera Forma Normal.

En general, la normalizacin es un tcnica de correccin de errores para los
modelos de informacin y no una tcnica de construccin.
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 concatenacin de la clave
de la entidad madre y al menos otro atributo de la entidad.
Notacin :
Ejemplo :
Anlisis
106
Si quisiramos guardar la informacin referente a los diferentes precios que ha

tenido un producto en especfico, deberamos contemplar la posibilidad de
manejarlos a travs de una entidad de tipo atributivo, ya que se est haciendo
ms claridad acerca de la entidad producto. Adems, debido a aspectos de
normalizacin, es conveniente manejar dichos precios, como entidad aparte, dado
que stos, son atributos repetidos y no se estara cumpliendo con la 1FN.
5.3.6.2 ENTIDAD ASOCIATIVA.
Es una entidad que surge de una asociacin o relacin entre dos o ms
entidades. Sirve para resolver el problema de las relaciones muchos a muchos
(redundancia de datos), creando una nueva entidad para la relacin.
Notacin :
Ejemplo :
Dada la siguiente relacin :
La entidad asociativa resultante se puede utilizar para :
Resolver la relacin muchos a muchos.

Guardar atributos adicionales que son caractersticos de la relacin y no de las
entidades participantes.
Para permitir que una relacin, al convertirse en entidad, participe en otras
relaciones.
La solucin a nuestro ejemplo, sera :
Existe un patrn importante :
Anlisis
107
A nivel de atributos :
VEHICULO
CRUCE
VIAS
Placa
Modelo
Propietario
Veloc. Promedio
Cilindraje
Fecha Compra
Placa
Cdigo Va
Fecha y Hora Cruce
Motivo Cruce
Direccin Cruce
Trfico
Cdigo Va
Orientacin
Nmero Carriles
Tipo Superficie
Si deseramos ampliar Motivo de Cruce a entidad, tendramos :
5.3.7 DEFINICION DE ATRIBUTOS.

Cada atributo requiere para su definicin los siguientes tems :
Nombre : Debe ser conciso y comprensible.
Definicin : Es el significado y propsito del atributo. Se debe verificar por los
usuarios. Sirve para implementar la ayuda en lnea.
Anlisis
108
Opcionalidad o no : Se debe indicar si el atributo es requerido u opcional.

Tipo de Dato : Longitud y valores vlidos. Debe ser consistente a lo largo del
modelo y lo ms apropiado posible a la realidad del atributo.
Rango : Si el atributo es numrico, se debe especificar los lmites inferior y
superior vlidos.
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 cohesin del mismo.
Algunas son :
5.3.8.1 CRUD EVENTO/ENTIDAD.
Busca identificar que eventos modifican las entidades en cuanto a Creacin (C),
Lectura (R), Modificacin (U) y Borrado (D) de filas o registros.
Ejemplo :
EVENTO/ENTIDAD
Cliente hace pedido
Dpto crdito 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 mnimo, en la entidad
Concepto de Pedido.
5.3.8.2 MATRIZ EVENTO/UBICACIN DEL NEGOCIO.
Muestra de la totalidad de eventos identificados, cules pueden ocurrir en las
diferentes sedes de la organizacin, si esta posee varias sucursales.
Ejemplo :
Anlisis
109
EVENTO/UBICACIN
Cliente hace pedido
Dpto crdito aprueba pedido
...
MEDELLIN RIONEGRO
X
X
X
CALI
X
....
Podemos observar que slo es viable que ocurra el evento El departamento de

crdito aprueba pedidos, en la oficina de Medelln. En las dems sucursales, no
es viable que ocurra dicho evento.
Esta matriz sirve para confirmar, a nivel de ocurrencias de eventos, cules pueden
darse en ubicaciones diferentes a las oficinas centrales y cules slo son de
manejo exclusivo de las mismas.
5.3.8.3 CRUD UBICACIN/ENTIDAD.
Es una combinacin de las dos anteriores. Dice a nivel de ubicaciones, a que
entidades se les puede crear, modificar o retirar filas.
Ejemplo :
UBICACIN/ENTIDAD
Medelln
Rionegro
Cali
....
CLIENTE
CRU
CRU
CRU
PEDIDO CPTO PEDIDO

CR
CR
U
U
CR
CR
....
La oficina de Rionegro, por ejemplo, slo 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 Crdito
Jefe de Bodega
...
CLIENTE
CRU
CRU
U
PEDIDO CPTO PEDIDO

CR
CR
U
U
....
El Gerente de Crdito, slo tiene permiso para crear, leer y actualizar la entidad
de Clientes. Solo puede actualizar el encabezado de Pedidos.
Anlisis
110
5.3.9 ALGUNOS EJEMPLOS DE MODELOS DE INFORMACION :

Sistema Hospitalario :
Sistema de Inventarios :
Anlisis
111
5.4 ESPECIFICACIONES DE PROCESO (MINIESPECIFICACIONES).

Es la descripcin detallada y ordenada de los procesos o transformaciones,
definidos en un sistema de informacin.
Su propsito 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 funcin primitiva,

descritas en los diagramas de flujo de datos.
Se describe el clculo y la transformacin que se hace sobre la informacin
No se debe describir :
La estructura o composicin de los datos (Se hace en el Diccionario de Datos).
El recorrido que sigue la informacin en el sistema (se refleja en los diagramas de
flujo de datos).
Relaciones entre estructuras de datos (se describen en el modelo de
informacin).
5.4.2 FORMAS DE DESCRIBIR MINIESPECIFICACIONES.
Existen diferentes herramientas para construir una especificacin. Aunque todas
son vlidas, unas son ms convenientes que otras, dependiendo del medio en el
cual se usen.
Por ejemplo, los arboles de decisin son apropiados cuando se trata de resolver
especificaciones que involucren decisiones en forma binaria.
En general, se usar la tcnica de espaol estructurado que por ser genrica, es
la que ms se acomoda al trabajo de definicin de procesos desde el punto de
vista algortmico.
Algunas tcnicas son :
Espaol Estructurado.
Tablas de Decisin.
Arboles de Decisin.
5.4.2.1 ESPAOL ESTRUCTURADO.
Consiste en definir un proceso en forma ordenada, describiendo los diferentes
clculos y comparaciones que se realizan all y que transforman los datos de
entrada al proceso, en informacin de salida til para procesos siguientes o toma
de decisiones.
Anlisis
112
Se realiza a travs de la utilizacin 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 numricos
(>,<,=,<=,>=,etc.) y palabras estructuradas (Mientras, Hasta, Si, Entonces,
Sino, Caso).
Evitar la puntucin y oraciones compuestas que contengan explicaciones,
aclaraciones, repeticiones, etc.
Utilizar marginacin para resaltar la jerarqua interna de la miniespecificacin.
Los verbos deben escogerse de entre un pequeo grupo y deben ser
orientados a la accin. Una lista aproximada sera :
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
Anlisis
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
ENTONCES
LEER NEGOCIO
SI NEGOCIO EXISTE
ENTONCES
MODIFICAR NEGOCIO
SINO
ENVIAR NEGOCIO NO EXISTE. VERIFIQUE.
FIN
SINO
FIN
FIN CAMBIO NEGOCIOS
RETIRAR NEGOCIOS
ENTONCES
LEER NEGOCIO
SI NEGOCIO NO EXISTE
ENTONCES
RETIRAR NEGOCIO
SINO
ENVIAR NEGOCIO NO EXISTE. VERIFIQUE.
FIN
SINO
FIN
FIN RETIRO NEGOCIOS
Anlisis
114
Como se puede apreciar, el ejemplo anterior describe las diferentes

especificaciones involucradas en la descripcin 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 diseo del sistema.
Se puede deducir tambin, que mnimo existen dos niveles de diagramas de flujo
de datos para las especificaciones anteriores. Un nivel general, dnde se narran
las tres funciones bsicas del proceso Manejar Negocios y un nivel de segundo
grado, donde se describen las funciones de ingreso, modificacin 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
Informacin.
4. Revisin del Anlisis.
5. Cronograma Diseo.
Anlisis
PARTICIPACION SALIDAS
Usuarios.
Especificaciones
Analistas.
Funcionales.
Cronograma
Diseo.
Usuarios.
Analistas.
Analistas.
Analistas.
Usuarios.
Usuarios.
Analistas.
115
6. DISEO.
6.1.1 OBJETIVOS.
Descubrir y construir una estructura lgica que de solucin al sistema planteado

en el anlisis.
Servir de enlace y comunicacin entre las especificaciones detalladas del
sistema y el ambiente y posibilidades especificas de programacin e
implementacin.
Garantizar la adecuada calidad del sistema, a travs del cumplimiento y
optimizacin de sus caractersticas ms importantes.
Desarrollar la forma como los mdulos o ventanas de la estructura del sistema
realizarn su trabajo, con miras a facilitar la fase de construccin del sistema.
Definir con todo el detalle, el diseo de la base de datos generada en el modelo
de informacin.
Definir concretamente el diseo de entradas y salidas del sistema (documentos,
pantallas (ventanas), reportes, interfases).
Definir cmo ser la interaccin usuario-sistema.
Garantizar que todos los requerimientos plasmados en el anlisis, sean
considerados e incluidos en la estructura generada.
6.1.2 DEFINICION.
Es la transformacin de las especificaciones funcionales de un sistema, en un
modelo que defina "COMO" se va a lograr su implementacion fsica.
Grficamente :
Aplicando el enfoque de sistemas, tenemos :

Diseo.
116
1.
2.
3.
4.
5.
6.
Definir la estructura inicial.

Disear los mdulos y/o ventanas.
Terminar la base de datos.
Disear entradas y salidas.
Generar el prototipo.
Revisar el diseo.
6.2 IMPORTANCIA DEL DISEO.
Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el

trabajo por realizar en la etapa de construccin.
Define claramente los componentes que tendr el nuevo sistema, a nivel de
bases de datos, procesos e interfases.
Descubre la estructura fsica que tendr el nuevo sistema.
Toma en cuenta el diseo de formatos tanto de entrada de datos, como de
salidas del propio sistema.
Proporciona una visin inicial para los usuarios, de cmo ser su interaccin
con el sistema, a travs de los prototipos.
Da claridad para definir la arquitectura necesaria que soportar al nuevo
sistema.
6.3 CARACTERISTICAS DEL DISEO.
Es una representacin abstracta del sistema, que plantea una solucin que
ser implementada luego.
Se preocupa de la "forma" del sistema en todos sus aspectos, definiendo con
todo el detalle como se ira a obtener esa forma planteada. Para esto es
necesario desarrollar ciertas actividades como :
ABSTRACCION : Generalizar un problema con el fn de asignar prioridades a su
solucin y establecer una jerarqua.
OPERACIONALIDAD : Convertir la estructura generada en algo realizable y
funcional.
VERIFICACION : Comprobar que se cumple con lo especificado en el anlisis.
Es una etapa limitada por el ambiente tecnolgico de hardware y software

existente en la organizacin.
Busca que la construccin del sistema se vuelva ms rutinaria y elemental.
La estructura a disear debe ser modular, donde cada mdulo exhiba
caractersticas funcionales independientes.
Un buen diseo debe ser :
COMPLETO : Debe abarcar todos los requerimientos planteados anteriormente.
CONSISTENTE : Se deben definir bien las interfases con otros sistemas.
CLARO : Que sea fcil de traducir a un lenguaje de programacin.
Diseo.
117
MANTENIBLE : Que evale la posibilidad de modificaciones futuras.

PRACTICO : Que pueda ser realizable fcilmente, con las herramientas
tecnolgicas existentes en la organizacin.
EVALUABLE : Que permita revisarse y mejorarse.
Es una etapa muy tcnica que requiere gran participacin del personal de
sistemas y del usuario, en lo que respecta a evaluaciones de prototipos y de
diseo de pantallas (ventanas) del nuevo sistema.
ANALISTAS :
Elaboran las especificaciones del diseo, con base en el anlisis elaborado
anteriormente.
El papel que desempea en sta etapa el analista de sistemas, es el de
diseador.
La habilidades de un buen diseador difieren algo de las del analista. Veamos :
Se debe enfocar a la tecnologa, sin olvidar los procesos definidos en el anlisis,
mientras el analista hace lo contrario. Se enfrenta con la tarea de traducir los
requerimientos del negocio a la tecnologa disponible en la organizacin.
Un buen diseador es creativo, lleno de recursos e inteligente para evaluar
opciones entre soluciones que no son perfectas. Las habilidades de un diseador
estan ms cercanas a las de un programador, ya que se debe tener claro el
ambiente tecnolgico, para poder sacar el mayor provecho de l.
USUARIOS :
Aprueban aspectos como operacin del sistema, diseo de entradas y salidas,
diseo de archivos y funcionalidad del sistema (Interfase de usuario).
6.5 PASOS EN EL DESARROLLO DEL DISEO.
en el diseo de un sistema de informacin. Cada una de stas tareas debe estar
claramente documentada, en el manual de desarrollo del sistema.
Diseo.
118
6.5.1 DEFINIR LA ESTRUCTURA DEL SISTEMA (Diseo Glogal).

Su objetivo es presentar el sistema bajo una estructura funcional que coordine y
oriente la ejecucin de todos los mdulos que lo componen. Se construye a partir
del diagrama de flujo de datos y el Diccionario de datos.
Se visiona la composicin del sistema desde el punto de vista de componentes de
desarrollo para la etapa de construccin.
Esta estructura se evala con base en tcnicas de diseo estructurado como
cohesin y acople, que se describirn ms 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. Derivacin 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 relacin de uno a uno entre procesos del diagrama de flujo
de datos y mdulos de la estructura).
2. Identificacin de los mdulos que comprendern el sistema y representacin
grfica de la relacin existente entre ellos.
3. Definicin de las relaciones e interfases existentes entre los mdulos.
Diseo.
119
4. Evaluacin y depuracin de la estructura, con base en consideraciones de

diseo estructurado como acople, cohesin, factorizacin.
5. Retomar de nuevo desde el paso 2, hasta encontrar una estructura acorde a lo
planteado en el anlisis y a la tecnologa disponible para la realizacin del
sistema.
6.5.1.2 DESCOMPOSICION FUNCIONAL DE MODULOS.
Esta tcnica es la empleada para elaborar la estructura del sistema. Consiste en
descomponer en forma sucesiva un mdulo en otros mdulos de ms baja
jerarqua, hasta lograr el detalle suficiente en la asignacin de funciones a estos.
Reglas para la descomplosicin :
Cualquier estructura tendr un mdulo general o coordinador.

Cada mdulo, si lo requiere, se subdividir en otros.
Cada mdulo subordinado, ser coordinado por sus padres (un mdulo puede
tener varios padres).
Deben existir por lo menos dos mdulos al mismo nivel de descomposicin.
Ejemplo :
Sistema de Informacin de Nmina.
Diseo.
120
La descomposicin del mdulo de devengados es igual a la anterior.
De la anterior estructura podemos observar :
Siempre existe un mdulo coordinador. En ste caso es el mdulo llamado S.I.

NOMINA.
No todos los mdulos se descomponen al mismo nivel, como es el caso de
PRODUCIR CHEQES, que slo tiene un nivel de descomposicin. Un mdulo
se debe descomponer, hasta obtener una medida alta de cohesin en la
funcin que realiza.
En primera instancia se est tratando de utilizar los mismos mdulos tanto para
el clculo de devengados, como para el de deducciones, con el objetivo de
ahorrar ms tarde, tiempo de construccin. Obviamente, se debe mirar si esto
es posible, a la luz del concepto de acople, que veremos ms tarde.
Existe un mdulo, cuya descomposicin est mal enfocada, dado que slo se
subdivide en otro mdulo, lo que atenta contra las reglas antes mencionadas.
Tal mdulo es el denominado ESTRACTAR BASICO.
6.5.2 DISEO DE MODULOS. (Diseo Detallado).
Es la descripcin y representacin detallada de cmo cada mdulo de la
estructura definida, ejecutar su trabajo con el fn de facilitar el proceso de
construccin.
Es bsico en este punto, retomar las especificaciones de proceso o
miniespecificaciones desarrolladas en el anlisis, ya que el diseo de mdulos, no
Diseo.
121
es ms que un refinamiento de la especificacin de proceso elaborada

anteriormente.
6.5.2.1 REQUERIMIENTOS PARA EL DISEO DE MODULOS.
Tener plenamente definida la estructura del sistema y las relaciones entre los
mdulos, ya que de stas dependen el diseo de las entradas y salidas.
Conocer las herramientas tecnolgicas y en especfico el lenguaje de
programacin que se utilizar.
Considerar las miniespecificaciones desarrolladas en el anlisis.
6.5.2.2 ATRIBUTOS DE UN MODULO.
Un mdulo consta de los siguientes atributos, que se deben tener en cuenta para
su adecuada definicin :
Entradas : Son datos o parmetros de control que recibe el mdulo de quien lo
llama.
Salidas : Son datos que entrega el mdulo a quien lo llam, una vez finalice su
operacin o mecnica.
Funcin : Es la transformacin que realiza el mdulo de los datos de entrada en
datos de salida.
Mecnica : Es la lgica con que cada mdulo ejecuta su funcin.
Tiene cuatro elementos bsicos : Condicin, secuencia, repeticin y rutina.
Datos Internos : Es el conjunto de datos que utiliza internamente el mdulo para
realizar su mecnica.
El mdulo se describe a travs de la herramienta anteriormente vista en el
anlisis : Espaol estructurado.
Es conveniente anotar que bajo las actuales herramientas de desarrollo, que
enfocan a tener interfases grficas, la unidad de programacin no es el mdolo
entero, como se desarrolla bajo las tcnicas estructuradas, sino ms 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 mdulos completos.
Dicho de otra forma, es tomar el mdulo completo y dispararlo contra la ventana,
quedeando ste fragmentado en los diferentes eventos que puede manejar la
ventana, con su correspondiente especificacin.
Diseo.
122
Con las nuevas tendencias entonces, se tiende a fragmentar la especificacin de

cada mdulo, en las porciones de cdigo, que cada componente de la ventana
controla.
Se observa entonces un principio bsico de construccin con herramientas
grficas : 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
descripcin de las especificaciones de los mdulos, a tener especificaciones por
eventos en cada pantalla o ventana.
La especificacin as realizada, puede dar una buena medida de cunto tiempo
tradar la construccin del nuevo sistema, dado que podemos determinar el grado
de dificultad de cada ventana, a travs de dichas especificaciones.
Ejemplo :
Mdulo : Generar Comisiones de Ventas.
ABRIR ARCHIVO VENTAS
INICIALIZAR VRCOMISION
LEER REGISTRO VENTAS
MIENTRAS NO FIN ARCHIVO VENTAS
SI VRVENTA > 1000.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 DISEO DE BASES DE DATOS.

Se debe establecer en detalle como ser la estructura fsica, tablas, atributos,
relaciones y formas de acceso de la informacin que almacenar el sistema.
Diseo.
123
Es la ltima oportunidad que se tiene de refinar, corregir y definir la base de datos

generada en el modelo de informacin, pues de esta actividad se desprende la
construccin fsica 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
definicin de esta tarea, traer como consecuencia el fracaso en la construccin
del sistema, y el consecuente fracaso de la culminacin del mismo. Requisitos :
Tener un conocimiento detallado del diagrama de estructura de datos generado

en el modelo de informacin.
Conocer en detalle los recursos tecnolgicos 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 definicin detallada de mdulos, no es ms que la
confirmacin de lo definido en el anlisis o en caso contrario, la realizacin y
correccin del nuevo modelo de informacin, basados en la estructura funcional
del sistema, definida anteriomente.
6.5.4 DISEO DE ENTRADAS Y SALIDAS.
Se define aqu, con todo el grado de detalle, cmo sern los documentos de
entrada requeridos por el sistema, las diferentes pantallas de dilogo, 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 carcter grfico de la
tecnologa usada.
Se deben tener estndares claros de diseo, para evitar que cada analista realice
a su amao estas definiciones. Sino se tiene estndares, es conevniente hacer un
alto en este punto y definirlos claramente, para evitar ambigedades en la
presentacin y diseo del sistema.
Es conveniente seguir los lineamientos que ofrece la tecnologa Windows, ya que
stos son estndares a nivel mundial.
6.5.4.1 DISEO 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 :
Diseo.
124
Logotipo de la Organizacin.
Nombre de la Organizacin.
Nombre del departamento, seccin o divisin.
Cdigo del documento.
Nmero del documento.
En el cuerpo del documento :

Presentar un orden lgico de campos, de acuerdo con el orden de los
datos que muestran las pantallas.
Mostrar una descripcin clara de cada campo a diligenciar.
Permitir suficiente espacio para diligenciar cada campo.
Manejar una presentacin agradable y armnica.
Permitir un espacio para posibles observaciones.
6.5.4.2 DISEO DE VENTANAS.
Las ventanas son la forma bsica de comunicacin con el usuario y la unidad de
programacin a tener en cuenta en la construccin. Se deben disear, teniendo
en cuenta los estndares antes mencionados y el tipo de ventana (entrada de
datos, consultas, de men, etc.). Se debe tener en cuenta :
Mostrar informacin que indique dnde 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 lneas de mensajes de ayuda y de error.

Mostrar los mensajes resaltados y en cajas de dilogo.
Otorgar un primer nivel de ayuda en la lnea de ayudas para cada
opcin.
El orden de datos en la pantalla debe ser claro y asemejarse al orden de los
datos en los documentos fuentes.
La tecnologa actual direcciona el diseo de las ventanas, hacia la utilizacin de
herramientas grficas, por sus ventajas comparativas con otras tecnologas. Dicha
tcnica se conoce en el mercado con el nombre de GUI (Graphical User Interface)
o Interfase Grfica de Usuario. Miremos algunos de sus aspectos ms
importantes :
Diseo.
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. ms bien el
reto consiste en elaborar interfases que estn bien diseadas, satisfagan las
necesidades del negocio y satisfagan las expectativas cada vez mayores de los
usuarios.
Algunos criterios a tener en cuenta en el diseo de GUI, son :
Control del Usuario : Un buen diseo 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 diseador es restringir a lugares donde no puede ir el usuario, ms
que a los lugares donde puede acceder.
Una buena aplicacin GUI debe tener facilidad para el uso del mouse o para el
teclado, indistintamente. Por ello se deben incluir aspectos como el orden de
tabulacin y teclas aceleradoras (hot key) para que cualquier accin que se realce
con el mouse, se pueda realizar tambin con el teclado.
Sensibilidad : El sistema debe proporcionar retroalimentacin tangible e
inmediata para cada accin. Puede ser tan simple como cambiar un apuntador por
el reloj de arena. Se deben usar cuadros de dilogo para indicar errores de
usuario, a travs de mensajes claros y entendibles. Nunca mensajes generados
por el sistema operativo, por ejemplo.
Personalizacin : 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.
Direccin : Se debe tener presente que la memorizacin de comandos no aplica
bajo GUI. Especialmente el hecho de ubicar un objeto en el sistema, debe ser tan
intuitivo como sealarlo con el mouse y realizar la operacin deseada con el
objeto. Algo as como apunte y dispare.
Se pueden usar para tal propsito iconos y barras de herramientas que aclaren la
ubicacin 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.
Diseo.
126
Una clave aqu de estndares, 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 informacin presentada en la interfase debe ser inmediatamente
comprensible y el uso de la aplicacin debe ser visualmente evidente. Se deben
usar tablas de control a travs de listas desplegables para dar mayor informacin
a los usuarios, cuandos se necesitan digitar datos como por ejemplo, sexo, estado
civil, departamento, etc.
Esttica : La composicin y disposicin de una ventana debe ser visualmente
agradable. Deber atraer la vista hacia la informacin que es ms 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 tamao
de la misma. No se deben presentar ventanas muy atiborradas de objetos ; es
mejor dividirlas en otras ventanas, para evitar confusiones.
Indulgencia : Un buen diseo de interfase debe motivar la exploracin. El usuario
debe sentirse libre para husmear por la aplicacin y dar vistazos rpidos en las
diversas ventanas y caractersticas.
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 tambin una forma de salida agradable cuando se decide abandonar ya sea
una transaccin o la aplicacin misma.
En general, una de las consideraciones ms importantes a recordar es que las
computadoras estn diseadas para ser usadas por gente real, y siendo personas
todos tenemos limitaciones. El reconocer es ms fcil que recordar. Por sta
razn, la lnea de comandos es cosa del pasado.
Tipos de Ventanas :
Ventana Principal o de Aplicacin.
Es la ventana ms comn.
Es independiente de cualquier otra ventana.
Puede traslapar y ser traslapada por otras ventanas.
Es movible, redinmensionable, puede ser minimizada.
Generalmente tienen un men.
Diseo.
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 despus de que se cierra la ventana madre.
Diseo.
128
Ventana Pop Up.

Ventana Hija.
Es muy similar a una ventana desplegable, pero ms 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 despus de cerrar la ventana madre.
Diseo.
129
Ventana Hija.
Ventana de Respuesta.
Es la ms 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 travs de una ruta particular.
Diseo.
130
Ventana MDI.
Traduce : Marco de Interfase para Documentos Mltiples.

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 Pestaas.
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 pestaa.
Carpeta con Fichas o Pestaas.
Diseo.
131
6.5.4.3 DISEO DE REPORTES.

Se diferencian de los informes, por ser impresos y tener un lmite de columnas
para su presentacin.
Se deben disear 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 Informacin.
Mostrar el Ttulo del reporte.
La fecha de elaboracin 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 informacin en una forma clara, ordenada y armnica.
6.5.5 DISEO DE OPERACION DEL SISTEMA (PROTOTIPOS).
Es la tarea clave en lo que respecta a la definicin de la forma como van a
interactuar el usuario y el sistema, ya que se define, por parte de los analistas la
navegacin y comunicacin 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 creacin de prototipos
es una disculpa para codificar algo rpidamente y ver si los usuarios lo aceptan.
Solo se busca que los usuarios tengan una idea de cmo ser el dilogo y la
navegacin a travs del sistema y en consecuencia se le debe aclarar al mismo el
objetivo anteriormente expuesto.
Se debe construir un modelo sencillo que muestre cmo ser la operacin del
sistema, con el fn de probar con el usuario la dinmica, funcionalidad y
caractersticas de implementacin.
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 simulacin de cmo 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
Diseo.
132
una cara. Inevitablemente, despes de ver el prototipo, alguien encontrar un

evento que hasta el momento no se habia detectado, aadir elementos a las
ventanas y eliminar otros innecesarios. Por ello, el prototipo enriquecer an ms
el modelo de informacin y de procesos definidos anteriormente.
Una buena idea para construir prototipos es la elaboracin 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 construccin.

La estructura general del sistema.
Los modelos definidos en el anlisis (procesos e informacin).
El modelo de informacin es una gua crtica para la disposicin de ventanas. El
marco organizacional de los datos est dictado por la cardinalidad de la relacin
en el diagrama entidad-relacin. Si un pedido tiene varios conceptos de pedido,
se podra esperar una relacin encabezado-detalle en la ventana de
mantenimiento de pedidos :
Los diferentes mdulos del sistema.

Algunas caractersticas propias del usuario :
Usuarios dedicados (Exigen poca documentacin y capacitacin).
Usuarios casual (Desean un sistema amistoso y detallado).
Grado de escolaridad.
Funciones que desarrolla en la organizacin.
Nivel de jerarqua.
No mostrar caractersticas que no se puedan luego implementar.

No se debe comenzar a construir el sistema, con la creacin temprana de
prototipos.
Diseo.
133
Corregir los modelos de procesos e informacin, si surgen comentarios con la

exposicin del prototipo.
6.5.6 DOCUMENTACION Y REVISION.
Luego de realizada cada una de las tareas anteriores, es conveniente revisar la
documentacin generada, con el fn de verificar que el diseo sea consistente con
lo propuesto y no se halla quedado ningn requerimiento por fuera de este.
Los participantes en la revisin debern conocer de antemano, al igual que en el
anlisis, la documentacin generada en esta etapa, para que la revisin sea
fructfera y no se convierta en una reunin explicativa del documento del diseo.
Las tareas anteriores se pueden realizar con varias tcnicas informticas. Dentro
de stas, se encuentra el diseo estructurado, que a diferencia del anlisis
estructurado, tiene una alta dosis de dependencia de la experiencia que puedan
presentar los analistas para su desarrollo.
Miremos entonces, en detalle, el diseo estructurado.
6.6 DISEO ESTRUCTURADO.
Es una metodologa de diseo orientada a procesos, basada en el mtodo de
solucin de problemas TOP DOWN y que al igual que el anlisis estructurado, es
grfica.
6.6.1 CARACTERISTICAS.
Ataca la complejidad de sistemas grandes, usando la particin y la jerarqua de

los mismos en partes funcionales ms pequeas.
Usa smbolos grficos.
Transforma el diagrama de flujo de datos a la estructura funcional del sistema.
No es la solucin total. La experiencia, la creatividad e intuicin combinados
con stas herramientas, sern la clave de un buen diseo.
6.6.2 COMPONENTES.
Los componentes ms importantes del diseo estructurado son :
6.6.2.1 IDENTIFICACION DE MODULOS.
El Diseo estructurado se fundamenta en la particin sucesiva de un mdulo en
otros mdulos, cada uno con una funcin especfica a desarrollar o cumplir.
Por mdulo se entiende :
Una porcin de lgica que tiene un nombre y un conjunto de atributos (Entradas,
salidas, funciones, mecnica y datos internos).
Diseo.
134
Representacion :
6.6.2.1.1 TIPOS DE MODULOS.

Mdulo Aferente : Es un mdulo cuya caracterstica importante es la de permitir
tomar informacin del medio externo y llevarla al medio interno. Un ejemplo tpico
de stos mdulos, son los encargados del manejo de entrada de datos (data
entry).
Mdulo Eferente : Son mdulos que tienen como caracterstica importante tomar
la informacin del medio interno y llevarla al medio ambiente. Son clsicos en sta
categora, los mdulos generadores de reportes.
Mdulo Coordinador : Su funcin bsica es orientar y coordinar la labor de otros
mdulos. Es un mdulo definitivo en los niveles altos de la estructura. Un ejemplo
seran los mdulos encargados de ejecutar los men de opciones de un sistema
dado.
Mdulo Transformador : Son mdulos que realizan una labor o funcin
especfica. Por ejemplo, un mdulo que siempres calcula una raz cuadrada, con
base en un nmero que le es enviado como parmetro.
6.6.2.1.2 INTERFASES ENTRE MODULOS.
Son las diferentes relaciones o llamadas que existen entre los mdulos de un
sistema. Pueden ser :
LLamado Sencillo :
El mdulo A llama al mdulo B.
LLamado a s mismo :
Diseo.
135
El mdulo A se llama a s mismo (Recursividad).

LLamado Mltiple :
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 mdulo pueda ser llamado por otros mdulos (A es
llamado por 2 ms mdulos). Lo anterior sirve para establecer las relaciones de
qu mdulos llaman a otros mdulos.
6.6.2.2 DIAGRAMA DE ESTRUCTURA.
Diseo.
136
Como se mencion al inicio del diseo, el diagrama de estructura sirve para

mostrar la organizacin relacional y en muchos casos jerrquica, de los diferentes
mdulos que componen el sistema de informacin, adems de las relaciones
existentes entre ellos.
No expresan la lgica del procedimiento, tarea que se deja a las especificaciones
de proceso, ni las diferentes interfases fsicas que puedan existir.
Los componetes principales de un diagrama de estructura son :
El diagrama anterior se debe leer as :
El mdulo A es el mdulo de nivel superior, que consulta el mdulo B. (Ningn

otro mdulo llama a A).
El mdulo B se llama subordinado de A.
El mdulo A es quin pasa los parmetros al mdulo B, como parte de la
llamada y el mdulo B puede o no regresar parmetros de salida, cuando
regresa al mdulo A. Los parmetros de entrada y salida deben estar definidos
en el diccionario de datos.
6.6.3 CARACTERISTICAS A EVALUAR EN EL DISEO.
6.6.3.1 ACOPLAMIENTO.
Es el grado de interdependencia entre mdulos. Es la medida de interaccin de
los mdulos. Mide el grado de relaciones que existen entre los diferentes mdulos
de la estructura.
Los buenos diseadores buscan desarrollar la estructura de un sistema, de tal
forma que un mdulo tenga poca dependencia de cualquier otro mdulo.
Diseo.
137
Se dice que un buen diseo debe contemplar un acople mnimo, controlando

variables como :
Nmero de parmetros que se transfieren entre mdulos.
Transferencia de datos innecesaria a los mdulos que se llaman.
Transferencias de datos, no informacin de control.
Se puede tener un espectro de acople, asi :
Espectro de Acople.
Se busca minimizar el acople para :
Controlar la propagacin de errores de mdulo a mdulo.

Que los cambios planteados a un mdulo, no afecten otros mdulos.
Que al trabajar en los detalles de un mdulo, no se tenga que agrupar o pensar
en muchos mdulos.
La conectividad sencilla da como resultado un software fcil de mantener y menos
propenso al efecto onda producido cuando los errores aparecen en una posicin
y se propagan a lo largo del sistema.
Los niveles altos de acople, se producen cuando los mdulos estn ligados a un
entorno externo. Por ejemplo, entradas de dispositivos, protocolos de
comunicacin, etc. Aunque esto es esencial, debe limitarse a un pequeo nmero
de mdulos dentro de la estructura.
Existen diferentes tipos de acople, que se pueden dar durante el diseo de un
sistema. A continuacin se presentan en forma ordenada, es decir, del acople
menos malo al acople no deseable :
Acople de Datos : Sucede cuando la comunicacin entre mdulos se hace a
travs de los datos estrictamente necesarios para que opere el mdulo
subordinado (Parmetros). Es el mejor acoplamiento.
Acople de Estampa : Se da a travs del envo de parmetros que no son los
estrictamente necesarios para el desempeo del mdulo subordinado.
Diseo.
138
Acople de Control : Sucede cuando la comunicacin de mdulo a mdulo, se da

a travs de parmetros de control.
Antes de ejecutar un mdulo, se realiza una accin de control. Por ejemplo,
verificar si existe un cdigo de cliente antes de crearlo.
Acople de Ambiente Comn : Se presenta cuando la comunicacin entre
mdulos se da a travs de otro mdulo de datos (mdulo intermedio).
Acople de Contenido : Ocurre cuando entre mdulos fluyen parmetros que
afectan la lgica del otro mdulo. Es el acople menos deseable. Por ejemplo, el
mdulo A envia al mdulo B el valor de N, para que ste realice un ciclo.
6.6.3.2 COHESION.
Es la medida con que cada mdulo ejecuta su trabajo. Evala al interior del
mdulo. El acoplamiento evalua interfases entre mdulos. Se dice que a mayor
cohesin, mejor es el diseo y se tiende a disminuir la comunicacin o acople
entre mdulos.
Es un principio bsico en la construccin de cdigo reutilizable. Un mdulo con
buena cohesin es ms barato de mantener en el largo plazo.
Un mdulo cohesivo, ejecuta una tarea sencilla de un procedimiento de software y
requiere poca interaccin con procedimientos que ejecutan otra parte de un
programa.
Podemos manejar un espectro de cohesin, as :
Espectro de Cohesin.
Una tcnica para determinar si un mdulo es altamente cohesivo es escribir una
frase que describa la funcin del mdulo y luego examinar dicha frase. Puede
hacerse la siguiente prueba :
Si la frase es una sentencia compuesta, contiene una coma o ms de un verbo,
probablemente el mdulo realiza ms de una funcin. Puede tener vinculacin
secuencial o de comunicacin.
Diseo.
139
Si la frase contiene palabras relativas al tiempo, tales como primero, a

continuacin, entonces, despus, cundo, al comienzo, etc., entonces
probablemente el mdulo es secuencial o temporal.
Si el predicado de la frase no contiene un objeto especfico sencillo a continuacin
del verbo, el mdulo puede presentar cohesin lgica.
Palabras como : inicializar, limpiar, etc., implican cohesin temporal.
Los mdulos con cohesin funcional siempre se pueden describir en funcin de
sus elementos usando una sentencia compuesta. Pero si no se puede evitar el
lenguaje anterior, siendo an una descripcin completa de la funcin del mdulo,
entonces el mdulo no presenta cohesn funcional.
A nivel de ventanas, la cohesin 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 aplicacin.
Los diferentes tipos de cohesin, de nuevo ordenados de mejor a peor, son :
Cohesin Funcional : Se presenta cuando un mdulo ejecuta una sola labor.
Por ejemplo un mdulo que calcula devengados.
Una ventana funcionalmente cohesiva, maneja un evento a nivel de negocio. Por
ejemplo, se debera tener una ventana para manejar datos de un cliente, dado el
evento el empleado de ventas registra/actualiza el nombre y la direccin del
cliente. Otra ventana para capturar un pedido de un cliente, etc.
Se presenta una ventaja con stas ventanas y es que son ms sencillas de
controlar y ms especializadas y eficientes en reconocer el evento dado, lo cual
hace posible tambin la reutilizacin de ellas por varios sistemas. La desventaja
es que se generan muchas ventanas para el sistema.
Cohesin Secuencial : Ocurre cuando un mdulo 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 funcin :
X = A * (B2 * C)
Grficamente, la cohesin secuencial sucede as :
Diseo.
140
Los datos de entrada al mdulo X son A, B y C, como se observa en el grfico. Al

ejecutarse la actividad D ( B*B), su resultado es la entrada para la siguiente
actividad del mdulo, la actividad E (D * C). Para finalizar la tarea del mdulo, la
actividad F retoma el resultado de la actividad E y realiza su clculo (E * A).
Las ventanas que presentan sta cohesin tienen los eventos agrupados, debido
a que stos suceden en secuencia.
Por ejemplo, se puede disear una ventana que pida datos de un cliente, genere
un pedido y permita el pago del mismo.
La ventaja de sta cohesin es que se aproxima mucho a cmo es el flujo del
trabajo normal del usuario en la organizacin. Es adecuada cuando se manejan
tareas repetitivas.
La desventaja es que existe una mezcla compleja de cdigo no relacionado, es
ms compleja de disear, usar y de mantener.
Siempre supone que los eventos suceden en forma ordenada. Es poco probable
que se reuse en otros sistemas.
Cohesin de Comunicacin : Ocurre cuando los componentes de un mdulo
toman la misma entrada y producen diferentes salidas. El orden de las
componentes del mdulo no es importante.
Log x
Sen x
El parmetro de entrada al mdulo 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 ejecucin de ellas dentro del mdulo.
Diseo.
141
Una ventana con este tipo de cohesin, 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 cdigo de acceso de
datos y las mismas reglas del negocio.
Su problema es que regularmete las ventanas son utilizadas por ms 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 difciles de codificar.
Cohesin Procedimental : Sucede cuando fluye control en el mdulo. La
secuencia de ejecucin de las funciones es importante.
La grfica anterior trata de explicar la poltica de algn departamento de ventas,

con respecto a aprobar o no crditos a sus clientes. Se puede ver que existen
varios controles para lograr la aprobacin final, como son :
Averiguar por el lmite de crdito del cliente y controlar las fechas de vencimiento
de las facturas. Dependiendo de estos dos controles, se aprueba o no el crdito
correspondiente.
Es conveniente, bajo ste esquema, particionar an ms el mdulo para evitar
repetir cdigo, como se ve el la grfica cuando ocurre la aprobacin del crdito
por diferentes ramificaciones de los controles mencionados antes (se repite
APROBAR tres veces en el mdulo).
Una ventana con cohesin procedimental organiza las tareas de acuerdo a la
descripcin de trabajo de un usuario particular. Los eventos son agregados para
dar al usuario todo lo que necesita en una ventana.
Diseo.
142
Esto da como resultado ventanas que son complejas, atiborradas, lentas en

responder y extremadamente sensibles a los cambios organizacionales dentro del
negocio.
Cualquier aplicacin tendr una mezcla de cohesin entre sus ventanas. La
mayora de las ventanas bien diseadas, caern en los primeros tres niveles
descritos. La cohesin funcional produce las mejores ventanas reutilizables,
comprensibles y mantenibles, pero se tendran muchas ventanas en el sistema.
La cohesin secuencial es un mtodo bueno para disear tareas que se ejecutan
regularmente. La cohesin de comunicacin 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 cohesin procedimental engendran el riesgo adicional de ser
inflexibles ante los cambios de la descripcin del puesto del usuario.
6.6.3.3 FACTORIZACION.
Es el proceso de particionar el trabajo o funcin de un mdulo, a travs de las
especificaciones de otros mdulos subalternos.
La factorizacin da como resultado una estructura de programa en la que los
mdulos de nivel superior toman las decisiones de ejecucin y los de nivel inferior
ejecutan la mayora del trabajo de entrada, computacional y de salida. Los
mdulos de nivel intermedio ejecutan algn control y realizan moderadas
cantidades de trabajo.
Se busca factorizar para :
Disminuir el tamao de mdulos grandes.

Dar ms independencia entre mdulos, para facilitar el cambio de los
requerimientos (mejorar acoplamiento).
Mejorar cohesin, dado que se realizan funciones ms particulares dentro de
cada mdulo.
El particionamiento no debe exceder ms de nueve mdulos. Se busca tener un
particionamiento entre siete y nueve mdulos, por nivel.
Ejemplo :
El mdulo INGRESAR FACTURA, se puede factorizar de la siguiente forma :
LEER FACTURA
VALIDAR FACTURA
REPORTAR FACTURA.
Diseo.
143
Se suspende la factorizacin cuando se llegue a una funcin bien definida.

6.6.3.4 FAN IN.
Se define como el nmero de mdulos que llaman a otro mdulo. Un buen FAN IN
implica optimizacin en construccin, dado que se hace uso del mismo mdulo,
desde diferentes funciones que lo requieren y no se repite la construccin de la
funcin en cada mdulo.
Es el caso tpico de la funcin Imprimir bajo windows, que slo se invoca desde
donde se necesite, por ejemplo desde un documento en Word o desde una hoja
electrnica en Excel.
Dicha funcin esta escrita una sola vez como mdulo. Es usada por qun la
necesite.
Un buen nmero de FAN IN por mdulo, puede ser tres. Quiere decir lo anterior,
que un mdulo puede ser usado por mximo otros tres mdulos diferentes.
Podemos apreciar en la grfica, que los mdulos A, B y C, llaman al mdulo D,

cuyo Fan In es tres en ste caso.
6.6.3.5 FAN OUT.
Se define como el nmero de mdulos que son llamados por otro mdulo.
Debe ser mayor de uno y menor o igual a nueve.
Un buen FAN OUT implica un adecuado particionamiento de mdulos a nivel de
funciones especficas, lo cual mejora la cohesin en los mdulos.
Es una medida que refuerza el hecho de evitar cohesiones como la procedimental
y la de comunicacin.
Se dice que un buen Fan Out es de nueve por mdulo. Quiere decir, que un
mdulo puede llamar a otros nueve como buena medida de Fan Out.
Diseo.
144
De la grfica podemos ver que el Fan Out de A es tres. El mdulo A llama a los
mdulos B, C y D.
6.6.4 PROCEDIMIENTO PARA CONSTRUIR LA ESTRUCTURA DEL SISTEMA
A TRAVES DEL DISEO ESTRUCTURADO.
El procedimiento descrito a continuacin, tiene como objetivo, convertir los
diagramas de flujo de datos en una estructura inicial que se vaya mejorando y
puliendo a travs de la evaluacin sucesiva de la misma.
Pasos :
1. Revisar y si es posible perfeccionar los diagramas de flujo de datos.
2. Identificar tipos de flujos de informacin en los diagramas de flujo de datos.
Existen diferentes tipos como :
Flujos de Transformacin : La informacin 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 informacin del medio externo a los
procesos (Informacin de entrada).
Flujos Eferentes : Son flujos que llevan informacin del medio interno al
exterior (Informacin de salida).
Flujos Centrales : LLevan informacin dentro del medio interno, para realizar
clculos y operaciones en el sistema.
Flujos de Transaccin : 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 travs de los conceptos de :
Acoplamiento, cohesin, factorizacin, fan in y fan out.
6. Repetir los dos pasos anteriores hasta obtener una estructura aducuada para el
diseo detallado.
Diseo.
145
6.7 RESUMEN :
ENTRADAS
Modelo de
Procesos.
Modelo de
Informacin.
PROCESO
1. Diseo Global.
Estructura del sistema
2. Diseo detallado.
Diseo de mdulos.
PARTICIPACION
Analistas.
Usuarios.
Analistas.
Hardware y
Software
existente.
3. Diseo de bases de
datos.
4. Diseo de
entradas/salidas.
4.1 Ventanas.
4.2 Formatos.
Analistas.
4.3 Reportes.
4.4 Informes.
4.5 Interfases.
5. Diseo de operacin
del sistema.
Prototipos.
6. Revisin del diseo.
Diseo.
Analistas.
Usuarios.
SALIDAS
Estructura
del sistema.
Diseo de
ventanas,
reportes,
Informes,
formatos,
interfases.
Seudocdigo.
Base de
datos.
Analistas.
Usuarios.
Analistas.
Usuarios.
146
7. CASO DE ESTUDIO.
Con la presentacin del siguiente caso, se pretende aplicar todos los conceptos
antes expuestos, para que se pueda tener un caso prctico que sirva de gua 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 Tesorera hipottica, de alguna
organizacin. Para lograr aplicar los conceptos metodolgicos, se suponen
algunas entrevistas con los diferentes empleados del departamento, adems de la
observacin directa del funcionamiento del rea.
Cabe aclarar que dicho caso slo persigue fines netamente acadmicos. No
pretende ser aplicado comercialmente a ninguna organizacin.
Veamos a continuacin 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 tambin poder obtener ingresos que por diferentes motivos, llegan a la
Tesorera. 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), entregndoles un recibo de caja asociado al pago. Adems paga a los
proveedores las diferentes facturas que llegan al rea de caja.
Tambin recibe informacin de consignaciones que envan los bancos por
concepto de pago en otras plazas. Nuestro funcionario adems elabora las
consignaciones locales y las enva a los bancos respectivos. Finalmente, con la
informacin de pagos e ingresos, cuadra la caja.
Al final del da, me enva el informe de cuadre de caja y el informe de ingresos y
egresos.
Los ingresos recibidos tambin los enva a su compaero del rea de
proyecciones, que tiene como funcin bsica proyectar los pagos en el tiempo,
con base en las polticas 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

adems enva 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 prstamos por adquirir; si el banco acepta la
solicitud, enva all el informe de las obligaciones aceptadas. Con dicha
informacin, el rea de prestamos enva el valor de las obligaciones adquiridas al
funcionario que maneja caja y bancos, para actualizar las cuentas bancarias.
Tambin genera para el departamento de contabilidad un informe de obligaciones
adquiridas, para que se asienten en la contabilidad. A mi, me enva un informe
de las obligaciones adquiridas por fecha de vencimiento.
Se me olvidaba decirles que el funcionario de caja y bancos tambin genera para
la contabilidad, toda la informacin 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 prstamos, son manejadas por el encargado de prstamos, quien las verifica y
las aplica a los respectivos prstamos 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 programacin
de pagos, para que en mi rea se realice el pago respectivo a los diferentes
proveedores consignados en la programacin, a travs de la caja. Para ello, se
ordena la programacin, se verifican los valores a pagar y se generan los
cheques. Finalmente, despus 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 funcin bsica, es mantener actualizados los diferentes saldos de las cuentas
de los bancos con los cuales tenemos negocios, adems de manejar tambin 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 envan los bancos
por concepto de pagos de clientes en otras ciudades. Tambin debo aplicar los
egresos por conceptos de notas y cheques pagados. Sumarizo los ingresos y
egresos del da y genero informes de ingresos y egresos para Contabilidad, la
Caso de Estudio.
148
Gerencia y el rea de proyecciones. Con la informacin sumarizada, cuadro la

caja al final del da y remito dicho cuadre a la Gerencia.
A cada cliente que paga, le entrego su correspondiente recibo de caja.
Dos veces al da, 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 programacin
semanal de pagos, que contiene la informacin 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 programacin 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 enva dicha informacin 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 polticas de
financiamiento que semanalmente me enva el Gerente.
Realizo las proyecciones en Excel y envo el resultado al Gerente y a mi
compaero del rea de Prstamos.
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 trmite y manejo de los
diferentes prstamos u obligaciones bancarias adquiridas por la compaa.
Me envan del rea de proyecciones un informe con las diferentes obligaciones a
adquirir, con su valor. Yo tramito una solicitud a determinado banco y la envo.
Todas las solicitudes son almacenadas en un archivador, hasta que stas son
respondidas por el banco.
Una vez el banco enva la respuesta, las solicitudes aceptadas se convierten en
obligaciones y se genera otro archivo con dicha informacin.
Es mi obligacin elaborar un informe para la Gerencia que contiene las diferentes
obligaciones adquiridas ordenadas por fecha de vencimiento, as como tambin
entregar un listado de las nuevas obligaciones para Contabilidad.
Caso de Estudio.
149
El valor de cada obligacin tambin 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 prstamos y de notas que se
manejan aqu.
Si son notas vlidas, debo aplicarlas a cada prstamo, consignando en el archivo
los respectivos valores cobrados por los bancos.
Genero tambin 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.
UBICACIN GENERAL.
La empresa Alfa S.A. esta dedicada a la produccin de alimentos para animales,
siendo una de las ms reconocidas en el medio. Comenz labores hace diez aos
y su objetivo es producir el mejor suplemento alimenticio para animales, al mejor
precio del mercado.
Sus oficinas estn ubicadas en Pereira, en las afueras de la ciudad. La compaa
pertenece al sector secundario de la economa, pues est dedicada al ramo de la
produccin.
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 direccin financiera, ms especficamente

en la gerencia de Tesorera, que maneja lo relacionado con los ingresos y egresos
de la compaa y el manejo de todo lo relacionado con las obligaciones adquiridas
con los bancos.
Se pretende construir un sistema de informacin 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 compaa, tales como : ingresos, egresos, cuadre de
caja, y generacin de informes de gestin de las tareas anteriores para la
Gerencia y otras reas de la compaa como Contabilidad y Cuentas por pagar.
Se dar informacin a terceros que estn relacionados con el sistema, como :
Clientes directos, Proveedores y Bancos.
Tambin se pretende cubrir el total manejo de las operaciones relacionadas con el
rea de Prstamos bancarios, como : Solicitud de prstamos, generacin y
manejo de las obligaciones de la compaa y administracin de las notas enviadas
por los bancos.
Se tendr opcin de manejar proyecciones de ingresos, para la Gerencia y el
departamento de Prstamos.
OBJETIVOS DEL SISTEMA.
Disponer de una herramienta automatizada que mejore en alto grado el
desempeo del personal involucrado en el manejo de las reas de Caja y bancos
y de Prstamos, permitiendo incrementar la disponibilidad de sta informacin
tanto para los usuarios internos de la compaa, as como para los externos.
Especficamente :
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 informacin.
Mejorar la atencin a los clientes de la compaa, mediante la elaboracin
automatizada de los diferentes recibos de caja, que se elaboran cuando stos
realizan pagos en la Caja.
Evitar el costo de papelera de $890,000 mensuales, ocasionada por la compra
de recibos de caja, imprimiendo en formas continuas dichos recibos.
Caso de Estudio.
152
Mejorar la atencin a los proveedores, agilizando la entrega de pagos en dos

das, mediante una adecuada organizacin e impresin de cheques.
Evitar el costo de chequeras por valor de $1340.000 mensuales, imprimiendo
en formas continuas los cheques para pago a proveedores.
Reducir el tiempo de elaboracin y entrega de solicitudes de prstamo a los
diferentes bancos en dos das, al disponer semanalmente, al principio de la
semana, de las proyecciones de obligaciones a adquirir.
Evitar el costo de aproximadamente $3260.000 en promedio mensual, de
multas ocasionadas por la mala aplicacin de las notas bancarias a los
prstamos adquiridos, hacindolo en forma automatizada y sin errores.
Reducir el tiempo de disponibilidad de reportes de caja, ingresos y egresos a un
da, 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 Tesorera.
A nivel externo, con los Proveedores, quienes son los que surten a Produccin de
materia prima. Su relacin es a travs de los pagos de materia prima que se
generan en la Caja.
Los clientes locales y remotos, a travs de los pagos directos y por medio de
consignaciones que se hacen en la Caja.
Los diferentes Bancos, quienes manejan las cuentas de la compaa, otorgan
prstamos y envan notas de cobro.
A nivel de informacin que genera el medio ambiente para que el sistema cumpla
con sus objetivos, tenemos :
Consignaciones de otras plazas, que envan los bancos de los clientes remotos.
Formato de los crditos aprobados, enviados por los Bancos.
Notas bancarias, para cobrar interese y capital de las obligaciones.
Pagos directos realizados por los clientes.
Las diferentes polticas de financiamiento que la Gerencia emite.
La programacin de pagos que genera el departamento de Cuentas por Pagar.
Las facturas que envan los Proveedores.
Con respecto a la informacin 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.
Informacin de obligaciones, ingresos y egresos, para Contabilidad.
Informacin de caja, ingresos, egresos, obligaciones y proyecciones para la
Gerencia de Tesorera.
Informe de ordenes de pago y cheques pagados, para el departamento de
Cuentas por Pagar.
Solicitudes de crdito elaboradas por el rea de prstamos, 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 compaa.
Proyecciones, que calcula las diferentes proyecciones de ingresos y egresos.
Prestamos, que se encarga de todo lo relacionado con el manejo de crditos
otorgados por los bancos.
Pagos, que realiza la funcin 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 tambin algunas relaciones entre los elementos anteriores. Dichas
relaciones son :
El informe de ingresos recibidos que enva la Caja a Proyecciones.
Los cheques pagados que son importantes para realizar la funcin 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.
Grficamente, podramos 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
cin
ama
Y
gos
e pa
r
ctu
Fa
OBLIGACIONES
FINANCIERAS
as
BANCOS
Recibo de caja
CAJA Y BANCOS
Polticas 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 relacin de los recursos de que se dispone para el desarrollo del
sistema.
Econmicos.
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
$2000.000
$ 85.000
$1000.000
$2500.000
$3600.000
$9185.000
Personal.
Se cuenta con un grupo de personas que ejecutarn el proyecto, entre analistas y
usuarios. Ellos son :
Caso de Estudio.
155
Analistas :
Juan Prez
Mnica Ramirez
Pedro Juan Gmez
Usuarios :
Julian Medina (Usuario Dueo del sistema).
Susana Prez (Usuario Responsable y operativo).
Tcnicos.
Los recursos de hardware y software disponibles son :
Equipo de cmputo :
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 tamao del sistema, las
personas participantes y la tecnologa disponible, se estima que el proyecto puede
presentar una duracin de 10 meses, con dedicacin de medio tiempo, por parte
tanto de los analistas como de los usuarios.
Se proyecta un costo de desarrollo con base en el nmero de ventanas a
construir, siendo esta la unidad de mnima de codificacin para el sistema.
Aproximadamente, el costo total, sera de $2500.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 sera de $6100.000, por concepto de mano de obra.
ANALISIS DE FACTIBILIDAD.
Se pretende mostrar en detalle el anlisis de factibilidad realizado al sistema, para
determinar su viabilidad financiera, tcnica y operativa.
FACTIBILIDAD ECONOMICA.
De acuerdo con los beneficios que otorgar el sistema al rea de Tesorera 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 continuacin :
Beneficios Econmicos.
Para las cifras mostradas, se aplica una base mensual.
Costos de chequeras
$1340.000
Multas bancarias
$3260.000
Reduccin de gastos telefnicos

por concepto de llamadas a los bancos
$350.000
Papelera de recibos de caja
$890.000
TOTAL
$5840.000
Beneficios No Econmicos.
Mejoras en la atencin a los clientes de la compaa, al realizar los pagos en
forma automatizada.
Evidente mejora en los pagos a los proveedores.
Reduccin del tiempo de elaboracin y entrega de solicitudes de prstamo 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 elaboracin del sistema son
bsicamente de desarrollo y de equipo de procesamientos. A continuacin se
detallan.
De Desarrollo.
Salarios Analistas
$2500.000
Salario Usuarios
$3600.000
Material de Oficina
TOTAL
$85.000
$6185.000
Los equipos necesarios y el software de desarrollo, se encuentra disponible en la

empresa, lo cual no ocasiona costos de adquisicin de los mismos.
Cabe aclarar que aunque los costos son mayores que los beneficios econmicos,
el sistema es factible, dado que los beneficios no econmicos planteados
anteriormente, tienen el suficiente peso, para cubrir la inversin en el sistema.
FACTIBILIDAD TECNICA.
Con base en la plataforma tecnolgica 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 tecnologa se ajusta completamente para la elaboracin del
sistema planteado.
FACTIBILIDAD OPERATIVA.
Los usuarios Julian Medina y Susana Prez, cuentan con la capacitacin
necesaria para administrar el futuro sistema y no presentan oposicin 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 Prez, Mnica Ramirez y Pedro Juan Gmez, poseen los
conocimientos tcnicos adecuados para la elaboracin del sistema.
Lo anterior lleva a concluir que el sistema, a nivel operativo tambin es factible.
Caso de Estudio.
158
ALTERNATIVAS Y RECOMENDACIONES.
De acuerdo con el estudio realizado, se puede tener en cuenta las siguientes
alternativas de solucin 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 tendra un sistema hecho a la medida para la
compaa.
De otro lado, es ms demorado su desarrollo, dado que el personal de
Informtica, 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 ms costosa, pero a su vez es ms rpida, 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 dependera completamente de los desarrolladores externos.
Se debe tener capacitado personal de Sistemas de la compaa, para que ste
asuma el mantenimiento del sistema, cuando los desarrolladores no puedan
atenderlo directamente.
Comprar el Sistema de Informacin.
Aunque es la solucin ms rpida, la mayora de los paquetes se deben adecuar
a las necesidades del rea, lo cual dificulta su adquisicin y funcionamiento
posterior.
Es la alternativa ms costosa.
Lo anterior hace concluir que la mejor alternativa de solucin, dada sus ventajas
comparativas, es la que trata de desarrollar el sistema por personal interno y es la
que se sugiere, para la ejecucin del sistema.
Caso de Estudio.
159
CRONOGRAMA DE ACTIVIDADES.
Se presenta a consideracin el cronograma de las actividades restantes para
culminar el proyecto.
ACTIVIDAD
ANALISIS
Sistema actual
Requerimientos
Sistema propuesto
Revisin
DISEO
Diseo Global
Diseo Detallado
Base de Datos
Prototipo
Revisin
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 : Nmero del mes de trabajo.
La fecha de comienzo de actividades est planteada para el mes de marzo de
1999.
La duracin 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 compaa.
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 programacin de pagos que enva 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
No
tas
CAJA Y BANCOS
Polticas de
financiamiento
nd
aci
ram
g
o
r
P
gos
e pa
PROVEEDORES
as
BANCOS
Recibo de caja
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
o
Inf
MANEJAR
NOTAS
BANCARIAS
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
ec
ci
n
eg
in
gr
re
es
so
os
s
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
PAGOS
Fac
de
Ingresos
y pagos
Pagos realizados
GERENCIA
Po
BANCOS
as
ic
lt
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
CONTABILIDAD
CUENTAS POR
PAGAR
Caso de Estudio.
162
NIVEL 2 : MANEJAR CAJA Y BANCOS.
Cons
ig
BANCOS
otras
nacio
nes
plaza
Ing
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
CUADRAR
CAJA
gre
so
s
APLICAR
Valor de obligaciones
EGRESOS
Valor egresos
EGRESOS
1.5
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
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
Va
lo
adq
rd
ob
lig
a
PRESTAMOS
SOLICITUDES
nes
uirid
as
cio
n
CONTABILIDAD
es
MANEJAR
CAJA Y BANCOS
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
Informacin notas
NOTAS
5.1
5.2
NOTAS
REALIZAR
PROYECCIONES
PRESTAMOS
DICCIONARIO DE DATOS.
Se definen a continuacin, las diferentes entidades o agentes externos, los
almacenamientos de informacin, 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 travs de cuentas corrientes y/o prstamos.
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 Tesorera.
OBSERVACIONES :
NOMBRE :
TIPO :
CUENTAS POR PAGAR.

FUENTE, SUMIDERO.
Caso de Estudio.
165
SIGNIFICADO : Es el rea encargada de enviar la programacin de pagos a la

Tesorera.
OBSERVACIONES :
NOMBRE : PROVEEDORES.
TIPO :
FUENTE, SUMIDERO.
SIGNIFICADO : Empresas que suministran la materia prima para la elaboracin
de los diferentes productos que la compaa 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+direccin+{nmero cuenta+saldo}}
OBSERVACIONES : Se almacena la informacin de cada banco con sus
respectivas cuentas. Se tiene carpeta por banco.
NOMBRE : NOTAS.
SINONIMO :
COMPOSICION : {nombre banco+nmero nota+fecha nota+fecha aplicacin+tipo
nota+valor nota}
OBSERVACIONES : Se lleva informacin archivada de las notas que envan los
bancos, por diferentes conceptos (tipo nota).
NOMBRE : PRESTAMOS.
SINONIMO :
COMPOSICION : {nombre banco+nmero de prstamo+fecha inicial+fecha
final+valor+tasa inters}
OBSERVACIONES : Carpetas que contienen los diferentes prstamos que
adquiere la empresa. Se lleva carpeta por banco.
NOMBRE : SOLICITUDES.
SINONIMO :
COMPOSICION : {Nmero solicitud+nombre banco+fecha envo+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 prstamo.

NOMBRE : PAGOS.
SINONIMO : MOVIMIENTOS.
COMPOSICION : {[Nombre banco/Nombre proveedor]+Nmero de
cheque+Nmero 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+ Nmero cuenta+ Detalle
cheques+Valor efectivo+Nombre cliente+Total consignacin
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 aplicacin+Valor
OBSERVACIONES : Son las notas de cobro y dbito que envan los bancos a la
Caja, para actualizar los saldos de las cuentas.
NOMBRE : Crditos Aprobados.
SINONIMO :
COMPOSICION : Nombre banco+Fecha aprobacin+Fecha pago+Tasa
inters+Perodos de pago+Valor crdito.
OBSERVACIONES : Es la informacin que el banco enva, al aprobar un crdito
para la empresa.
NOMBRE : Pagos realizados.
SINONIMO :
COMPOSICION : [Nombre banco/Nombre proveedor]+Concepto pago+Fecha
pago+Nmero cheque+Valor pagado.
OBSERVACIONES : Pagos efectuados a los bancos y a los proveedores, por
Caso de Estudio.
167
materia prima y cuotas de prstamos.

NOMBRE : Polticas de Financiamiento.
SINONIMO :
COMPOSICION : Tipo de financiamiento+Valor
OBSERVACIONES : Son las diferentes opciones de financiamiento que expide la
Gerencia, para que la compaa disponga de fondos.
NOMBRE : Programacin de Pagos.
SINONIMO :
COMPOSICION : Fecha de pago+Beneficiario+Valor.
OBSERVACIONES : Es la lista de pagos que enva el rea de Cuentas por pagar
a la Caja, para que se elaboren los cheques y las ordenes de pago.
NOMBRE : Facturas.
SINONIMO :
COMPOSICION : Nmero 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+Nmero obligacin+Valor a pagar+Fecha
vencimiento.
OBSERVACIONES : Listado de obligaciones por fecha de vencimiento para la
Gerencia.
NOMBRE : Cuadre de Caja.
SINONIMO :
COMPOSICION : Nombre banco+Nmero de cuenta+Total entradas+Total
salidas+Saldo.
OBSERVACIONES : Informe diario del estado de las cuentas.
Caso de Estudio.
168
NOMBRE : Proyeccin ingresos y egresos.

SINONIMO :
COMPOSICION : Fecha Proyeccin+Ingresos proyectados+Egresos proyectados.
OBSERVACIONES : Informe de proyecciones de ingresos y egresos, por fecha.
NOMBRE : Consignaciones locales.
SINONIMO :
COMPOSICION : Nombre banco+ Fecha+ Nmero cuenta+ Detalle
cheques+Valor efectivo+Total consignacin
COMPOSICION :
OBSERVACIONES : Consignaciones realizadas por la empresa, en los diferentes
bancos.
NOMBRE : Solicitud de crdito.

SINONIMO :
COMPOSICION : Nmero solicitud+Nombre banco+valor solicitado.
OBSERVACIONES : Solicitudes enviadas la los bancos, para obtener los
prstamos para la empresa.
NOMBRE : Recibo de Caja.
SINONIMO :
COMPOSICION : Nmero 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+Nmero obligacin+Valor obligacin.
OBSERVACIONES : Informe entregado a Contabilidad, para realizar los asientos
contables.
NOMBRE : Cheques
SINONIMO :
COMPOSICION : Nombre banco+Nmero cheque+Fecha+Beneficiario+Valor.
OBSERVACIONES :
NOMBRE : Orden de Pago.
SINONIMO :
COMPOSICION : Nmero orden de pago+Nmero cheque+Beneficiario+Nmero
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 programacin.
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 Prstamo.
Caso de Estudio.
170
Crear Obligacines 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 Programacin de Pagos.
Verificar Valores.
Generar Cheques.
OBSERVACIONES :
NOMBRE PROCESO : MANEJAR NOTAS BANCARIAS.

SIGNIFICADO : Se encarga de administrar las diferentes notas bancarias que
envan 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 informacin planteadas por el rea, que debe resolver el
nuevo sistema, son :
Disponer de un mecanismo gil para cuadrar la caja automticamente.

Poder manejar los ingresos de la caja.
Manejar todos los egresos por concepto de pago a proveedores y a prstamos
bancarios.
Generar automticamente las consignaciones locales.
Diligenciar en forma automtica las diferentes solicitudes de prstamos
enviadas a los bancos.
Permitir el manejo de las obligaciones financieras, en lo que respecta a
creacin, modificacin, retiro y consultas.
Poder generar proyecciones de ingresos y egresos para la compaa.
Manejar las diferentes notas bancarias, con respecto a creacin, modificacin,
retiro y consultas.
Caso de Estudio.
171
Generar automticamente 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 continuacin 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 informacin
planteadas, adems de los objetivos expuestos inicialmente y sirva como una
base slida para la elaboracin del diseo 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
No
tas
.o
CAJA Y BANCOS
Polticas 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
de
to
GERENCIA
ec
ci
n
eg
in
gr
re
es
so
os
s
lt
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
Pr
BANCOS
a
ci
an
fin
PRESTAMOS
PROYECCIONES
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
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
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
Proyeccin de ingresos
Polticas de finaciamiento
GERENCIA
PROYECTAR
DETALL PRESTAMOS
INGRESOS
Proyeccin de egresos
PROYECTAR
EGRESOS
2.2
2.1
GERENCIA
Polticas de financiamiento
PROYECCIONES
CUENTAS
NIVEL 2 : MANEJAR PRESTAMOS.

Caso de Estudio.
175
Crdit
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
Programacin 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
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 enva las consignaciones de otras plazas.
El gerente emite nuevas polticas de financiamiento.
El banco aprueba un crdito.
Tesorera emite una solicitud de crdito.
El banco enva notas bancarias.
Se crean nuevas cuentas corrientes.
Se retiran cuentas corrientes existentes.
Tesorera genera consignaciones.
Tesorera paga proveedores.
Caso de Estudio.
179
DICCIONARIO DE DATOS SISTEMA PROPUESTO.

Para la definicin del diccionario del sistema propuesto, slo se tendrn en cuenta
aquellos trminos nuevos a nivel de flujos de datos y almacenamientos.
Se definen los diferentes procesos, a nivel de especificaciones de proceso o
miniespecificaciones. Los dems 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 dbito+cuentas crdito+fecha+comprobante+valores.
OBSERVACIONES : Son los diferentes asientos contables que se generan en
forma automtica, por cada transaccin realizada en el sistema.
ALMACENAMIENTOS.
NOMBRE : CUENTAS.
SINONIMO :
COMPOSICION : {nombre banco+nmero 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+nmero prestamo+{fecha pago inters+fecha
pago capital+valor}}
OBSERVACIONES : Contiene la programacin terica de pago de los diferentes
prstamos.
NOMBRE : DETALLE NOTAS.
SINONIMO :
COMPOSICION : {nombre banco+nmero 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
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

envan las entidades financieras, para el pago de las obligaciones adquiridas.
ESPECIFICACION :
LEER OPCIONES MANEJAR NOTAS
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, definicin 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 enva
consignaciones de
otras plazas.
El gerente emite
nuevas polticas de
financiamiento
El banco aprueba un
crdito.
Tesorera emite una
solicitud de crdito.
El banco enva notas
bancarias.
Se crean nuevas
cuentas corrientes.
Se retiran cuentas
corrientes existentes.
Tesorera genera
consignaciones.
Tesorera paga
proveedores.
BANCO CTAS
MVTO
CR
CR
NOTAS DET.
PREST
NOTAS
DET.
PREST
SOLIC.
CR
R
CR
CR
CR
RD
C
CR
CR
CR
RD
RD
CR
CR
CR
CR
CR
RU
RU
AUTORIZACION USUARIO/ENTIDAD.
Caso de Estudio.
185
EVENTO/ENTIDAD
BANCO CTAS
Cajero.
Analista Proyeccin
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
DISEO.
DISEO GLOBAL.
La estructura que se presenta a continuacin pretende soportar completamente el
funcionamiento del nuevo sistema, a travs de los diferentes mdulos
identificados en ella.
Se defini y se refin a la luz de los diferentes diagramas de flujo de datos
generados en el anlisis del sistema propuesto y los conceptos de cohesin y
acople del diseo estructurado.
Caso de Estudio.
187
DISEO DETALLADO.
Caso de Estudio.
188
Con base en la estructura planteada, se detallan los diferentes mdulos del

sistema en forma de seudocdigo, con miras a facilitar la tarea de construccin de
los mismos.
Dichos mdulos 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
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
FINCASOS
LEER OPCION
FIN MIENTRAS
PROYECCIONES
LEER OPCION
Caso de Estudio.
189

CASO OPCION = PROYECTAR INGRESOS
LLAMAR PROYECTAR INGRESOS
CASO OPCION = PROYECTAR EGRESOS
LLAMAR PROYECTAR EGRESOS
OTRO CASO
FINCASOS
LEER OPCION
FIN MIENTRAS
PRESTAMOS
LEER OPCION
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
FINCASOS
LEER OPCION
FIN MIENTRAS
NOTAS BANCARIAS
LEER OPCION
CASO OPCION = CREAR NOTAS
LLAMAR CREAR NOTAS
CASO OPCION = MODIFICAR NOTAS
LLAMAR MODIFICAR NOTAS
CASO OPCION = RETIRAR NOTAS
LLAMAR RETIRAR NOTAS
OTRO CASO
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
GRABAR VALOR PAGO
GENERAR RECIBO DE CAJA
CASO ES POR CONSIGNACIONES
GRABAR VALOR PAGO
OTRO CASO
FINCASOS
LEER INFORMACION INGRESOS
FIN MIENTRAS
EGRESOS
LEER INFORMACION EGRESOS
MIENTRAS EXISTA INFORMACION EGRESOS
CASO ES POR PRESTAMOS
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
FINCASOS
LEER INFORMACION EGRESOS
FIN MIENTRAS
CONSIGNACIONES
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
CASO OPCION = CREAR CUENTAS
LLAMAR CREAR CUENTAS
CASO OPCION = MODIFICAR CUENTAS
LLAMAR MODIFICAR CUENTAS
CASO OPCION = RETIRAR CUENTAS
LLAMAR RETIRAR CUENTAS
OTRO CASO
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
FIN MIENTRAS
MODIFICAR CUENTAS
Caso de Estudio.
192

SI CUENTAS EXISTE
ENTONCES
GRABAR CUENTAS(COD BANCO+COD CUENTA)
SINO
MENSAJE ERROR CUENTA NO EXISTE
FIN
FIN MIENTRAS
RETIRAR CUENTAS
SI CUENTAS EXISTE
ENTONCES
BORRAR CUENTAS(COD BANCO+COD CUENTA)
SINO
MENSAJE ERROR CUENTA NO EXISTE
FIN
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

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
SI PRESTAMO EXISTE
ENTONCES
MENSAJE ERROR PRESTAMO EXISTE
SINO
GRABAR PRESTAMOS(COD PRESTAMO)
GRABAR DETALL PRESTAMOS
FIN
FIN MIENTRAS
MODIFICAR PRESTAMOS
SI PRESTAMO EXISTE
ENTONCES
GRABAR PRESTAMOS(COD PRESTAMO)
GRABAR DETALL PRESTAMOS
SINO
MENSAJE ERROR PRESTAMO NO EXISTE
FIN
FIN MIENTRAS
RETIRAR PRESTAMOS
Caso de Estudio.
194

SI PRESTAMO EXISTE
ENTONCES
BORRAR PRESTAMOS(COD PRESTAMO)
BORRAR DETALL PRESTAMOS
SINO
MENSAJE ERROR PRESTAMO NO EXISTE
FIN
FIN MIENTRAS
CONSULTAR PRESTAMOS
LEER 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
FIN MIENTRAS
MODIFICAR NOTAS
Caso de Estudio.
195
SI NOTAS EXISTE
ENTONCES
GRABAR NOTAS(COD NOTA)
GRABAR DETALL NOTAS
SINO
MENSAJE ERROR NOTA NO EXISTE
FIN
FIN MIENTRAS
RETIRAR NOTAS
SI NOTAS EXISTE
ENTONCES
BORRAR NOTAS(COD NOTA)
BORRAR DETALL NOTAS
SINO
MENSAJE ERROR NOTA NO EXISTE
FIN
FIN MIENTRAS
Caso de Estudio.
196
DISEO DE BASES DE DATOS.

Como se defini anteriormente en el anlisis 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 diseo que se propone. Para
ms detalle, vea anlisis del sistema propuesto, modelo de datos y diccionario de
datos, en lo que atae a almacenamientos.
DISEO DE ENTRADAS Y SALIDAS.
PANTALLAS.
A continuacin se presentan los diferentes tipos de diseo estndar de ventanas
que sern usadas en la construccin posterior del sistema.
Ventana Men.
Caso de Estudio.
197
Ventana de Entrada, Modificacin, Retiro, Consulta Simple de Datos.
Ventana de Entrada, Modificacin, Retiro, Consulta Simple, OPCION 2.
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. Bibliografa.
Pressman, Roger. Ingeniera del Software un enfoque prctico, 3 edicin,

Espaa, McGraw Hill, 1994.
c
Senn, James A. Anlisis y diseo de sistemas de informacin. Mxico, M Graw

Hill, 1987.
Ruble, David A. Anlisis y diseo prctico de sistemas cliente/servidor con GUI.
Mxico, Prentice Hall, 1998.
Price Waterhouse. Metodologa de desarrollo SMM/SD, 1984.
Universidad EAFIT. Anlisis y diseo de sistemas de informacin. 1989.
Bibliografa.
200

Ingeniera Del Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ingeniera Del Software

Загружено:

Авторское право:

Доступные форматы

TABLA DE CONTENIDO

EL PROCESO DE DESARROLLO DEL SOFTWARE

2.1 LA INGENIERA DEL SOFTWARE: UNA TECNOLOGA ESTRATIFICADA

3.1 CONSIDERACIONES GENERALES.

4.1 CONSIDERACIONES GENERALES.

4.10.2 FORMAS DE DESCRIBIR MINIESPECIFICACIONES.

5.1 CONSIDERACIONES GENERALES.

De esta manera, podemos decir que la organizacin esta influenciada por el

El medio ambiente en donde se desenvuelve la organizacin, est conformado

Sistematizacin: Accin y efecto de estructurar, organizar algo con un

Como vemos, en la organizacin existe un elemento importante que relaciona o

METODOLOGIA de trabajo para resolver problemas, utilizando el concepto de

1.4 SISTEMAS DE INFORMACION.

Algunos elementos de la organizacin son:

tcnicas. La documentacin debe estar relacionada con cada uno de los

Grado de Participacin de la Personas en el Desarrollo de un Proyecto.

Ejemplo: Sistema de Informacin de Nmina.

De la grfica podemos apreciar que el sistema de informacin de nmina consta

Los sistemas de informacin deben suministrar datos e informacin suficiente

1.4.4 ADMINISTRACIN DE SISTEMAS DE INFORMACIN.

Por qu se han presentado malos resultados aplicando la tecnologa

Los sistemas de informacin son depurados en produccin.

Quinta Generacin: Inteligencia artificial, objetos, programacin parametrizada,

1.5.3 CRISIS DEL SOFTWARE.

Costos : alto costo de desarrollo, comparado con el costo del hardware.

Esta crisis se trata de solucionar mediante el uso de herramientas que ayuden al

1.5.4 FACTORES CRITICOS DE XITO EN EL DESARROLLO DE SISTEMAS

Definir claramente los objetivos del proyecto.

1.6.1 PREANLISIS O ANTEPROYECTO.

2.1 LA INGENIERA DEL SOFTWARE: UNA TECNOLOGA ESTRATIFICADA

Cambio que va asociado al a correccin de errores, a las adaptaciones requeridas

Aunque el software se haya desarrollado bien, el cliente puede descubrir algunos

El software de computadora se deteriora debido al cambio, y por esto el

Seguimiento y control del proyecto de software.

2.2 EL PROCESO DEL SOFTWARE

2.2.1 MODELOS DE DESARROLLO DEL SOFTWARE

Todo el desarrollo del software se puede caracterizar como bucle de resolucin de

Definicin Del Problema

Antes de comenzar a hablar de las diferentes clases de modelos de procesos del

2.2.1.1 MODELO LINEAL SECUENCIAL

Ingeniera y modelado de Sistemas/Informacin

El trabajo comienza estableciendo requisitos de todos los elementos del sistema y

ANLISIS DE LOS REQUISITOS DEL SOFTWARE

POR QUE FALLA ALGUNAS VECES EL MODELO LINEAL SECUENCIAL?

2.2.1.2 MODELO EN CASCADA.

Su enfoque es conveniente para la enseanza de las tcnicas de Ingeniera de

Cascada con Iteracin de Ajustes Integradas.

2.2.3 MODELO DE CONSTRUCCION DE PROTOTIPOS

Ojo ver las diapositivas de las exposiciones

Importante ver las paginas WEB y las

2.2.4 MODELO DESARROLLO RPIDO DE APLICACIONES.

Desarrollado en el Pentgono, como un mtodo para controlar los costos de

Tres Iteraciones Espirales en Cuadros de Tiempo.

Motivar la actividad pretendida.

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

FALTA MODELOS EN ESPIRAL WIN WIN

2.2.5.3 MODELO INCREMENTAL

El modelo incremental entrega el software en partes pequeas, pero utilizables,

Cuando se utiliza un modelo incremental, el primer incremento en muchos casos es

2.2.5.4 MODELO DE DESARROLLO CONCURRENTE

2.2.6 DESARROLLO BASADO EN COMPONENTES

2.2.7 MODELO DE MTODOS FORMALES