TP-336 PDF Desarrollo

TRABAJO PRÁCTICO:
ASIGNATURA: Sistemas de Información II
CÓDIGO: 336
FECHA DE ENTREGA AL ESTUDIANTE: A partir de la primera semana de

presentación de pruebas, a través del asesor de la asignatura de su Centro Local
FECHA DE DEVOLUCIÓN: El informe correspondiente al trabajo práctico será

entregado por el estudiante anexo a la segunda prueba integral de la asignatura.
Si el estudiante logró todos los objetivos de la prueba en la primera integral,
entregara el trabajo práctico al supervisor de pruebas de la segunda integral.
NOMBRE DEL ESTUDIANTE: LUIS BERRIO
CÉDULA DE IDENTIDAD: 7953091
TELÉFONO DEL ESTUDIANTE: 0416-6181511
DIRECCIÓN DEL CORREO ELECTRÓNICO: SUMIBER@GMAILCOM
CENTRO LOCAL: METROPOLITANO
CARRERA: 236
NÚMERO DE ORIGINALES: 85
LAPSO: 2020-1
RESULTADO DE CORRECCION
OBJ No. 1 2 3 4 5 6 7 8
O:NL 1:L
Contenido
INTRODUCCION ............................................................................................................... 3
METODOS Y PROCEDIMIENTOS .................................................................................... 5
UNIDAD 1: ......................................................................................................................... 7
SELECCIÓN DE UNA SOLUCIÓN DE SISTEMAS DE INFORMACIÓN. ........................... 7
UNIDAD 2. ....................................................................................................................... 18
ANÁLISIS DE DATOS. .................................................................................................... 18
UNIDAD 3: ....................................................................................................................... 35
ANÁLISIS Y DISEÑO DE PROCESOS. ........................................................................... 35
UNIDAD 4: ....................................................................................................................... 52
DISEÑO DE BASES DE DATOS. .................................................................................... 52
UNIDAD 5: ....................................................................................................................... 58
DISEÑO DE ENTRADAS, SALIDAS E INTERFACES. .................................................... 58
UNIDAD 6: ....................................................................................................................... 72
DISEÑO DE LOS PROGRAMAS ..................................................................................... 72
TP-336
SISTEMAS DE INFORMACION II
INTRODUCCION
A través del presente informe buscaremos cubrir las etapas finales de ciclo de vida del
desarrollo del proyecto en estudio, desarrollaremos las etapas de diseño e implantación
del sistema, lo cual permitirá concluir el proyecto siguiendo una metodología estrictamente
académica (ciclo de vida de Desarrollo del Proyecto o CVDP). Recordemos que
previamente (Sistemas de Información I) se cumplió con las etapas de Planificación
Análisis del Sistema.
El proyecto en culminación, es el diseño e implantación de un sistema de información

automatizado para la gestión de solicitud de vacaciones y permisos del INDR, con el fin
de prestar un servicio de atención a los solicitantes más eficiente, basado en el uso de la
tecnología informática, esto permitirá sustituir un conjunto de procesos manuales, los
cuales retardan la atención, además de no permitir planificación, control y auditoría de
gestión. El objetivo principal es el desarrollo del sistema automatizado para registro de
solicitudes, pero el informe contiene además la mención y análisis de los procesos
manuales que se interrelacionan con el sistema automatizado.
El informe consta de las siguientes unidades:
Unidad 1; Selección de una solución de sistemas de información:
En la cual se definen alternativas de diseños las cuales son sometidas a un análisis

de viabilidad para finalmente recomendar la mejor alternativa de diseño. Aquí se definen
los criterios técnicos para análisis de procura, se solicitan ofertas y presupuestos para
adquisición de sistema, se analizan las ofertas y se escoge la mejor oferta de acuerdos a
un análisis de viabilidad estricto.
Unidad 2: Análisis de datos:
En esta unidad esta la parte medular del diseño del sistema y consta de aspectos tales
como el análisis y distribución de los datos y procesos, definición de las unidades de
diseño.
Unidad 3: Análisis y diseño de procesos:
Continuando con el diseño del sistema, en esta unidad desarrollamos el análisis y

distribución de procesos.
Unidad 4: Diseño de bases de datos:
Esta sección es continuación o complemento de la sección anterior y tiene que ver con el
diseño de la base de datos estableciendo como requisito necesario la normalización de la
misma.
3
Unidad 5: Diseño de entradas, salidas e interfaces:
Igualmente este punto es continuación de la fase de diseño e integración. Aquí se definen

los bocetos de pantallas de entradas y salidas así como los modelos de reportes
requeridos y las interfaces de usuarios para navegar por los módulos o sus aplicaciones
del programa principal. Todas estas especificaciones servirán de insumos para la creación
de los programas y la base de datos.
Unidad 6: Diseño de programas:
Corresponde al inicio de la última fase de diseño del proyecto, en esta sección se

especifican como serán creados Los programas estableciendo una metodología de diseño
modular.
Unidad 7. Construcción de un sistema:
Como indica su descripción, serán creados definitivamente la base de datos y los

programas mediante el uso del manejador de base de datos seleccionado así como el
lenguaje de alto nivel escogido.
Unidad 8. Entrega de un sistema:
Corresponde al final del desarrollo del proyecto y tendremos en esta sección la instalación
de archivos y programas y la formación de usuarios.
Para finalizar, durante el desarrollo de todas estas unidades se incluye la elaboración del
diccionario del proyecto el cual formara parte de la documentación necesaria para la
formación de usuarios del sistema (mantenedores).
4
METODOS Y PROCEDIMIENTOS
Como hemos señalado anteriormente, para el diseño e implantación seguiremos una

metodología dentro de la cual serán aplicados métodos o técnicas para cumplir con los
pasos necesarios, hasta culminar con la implantación del proyecto. La presente sección
hará referencia a estos métodos y técnicas aplicadas, desglosándolas por fase.
FASE SELECCION: Se utilizan las técnicas de matriz de soluciones candidatas para

definir y mostrar las alternativas de diseño. Seguidamente, se usa la matriz de viabilidad
para plasmar las bondades desde los puntos de vistas técnicos, operativos, económicos y
de calendario para cada alternativa de diseño. Con esto se pretende, dar los insumos
necesarios para la selección de la mejor opción. Cabe destacar, que para el análisis de
viabilidad según calendario, se usa los diagramas de Gantt como herramienta de apoyo.
Finalmente, se escoge la mejor opción usando la matriz de valores de muestras (de
Baremo), la cual arrojara unos resultados porcentuales y el de mayor valor representara la
mejor opción o propuesta definitiva de diseño- implantación.
FASE DE ADQUISICION: Durante esta fase la cual es de adquisición de la tecnología a

usar, desde el punto de vista de hardware y software, se seguirán los siguientes pasos:
✓ Investigar los criterios técnicos necesarios para valorar las procuras ofertadas.
✓ Solicitar y recibir las ofertas de tecnología de diferentes proveedores.
✓ Evaluar las ofertas usando las herramientas ya descritas en la fase de selección
(específicamente, matriz de viabilidad y matriz de valores de muestras).Aquí se
obtendrá la oferta ganadora y se recibirá la tecnología a usar en el proyecto.
FASE DE DISEÑO E INTEGRACIÓN (Inicio): En esta sección se tratan primero los

datos del sistema usando la técnica de análisis de datos; con esta herramienta se
definirá el modelo de datos precisando las entidades y claves asociadas necesarias,
además de mostrar el diagrama de entidades-relaciones para asociar los datos como un
sistema integrado. Los datos serán tratados para obtener la normalización en 3FN del
modelo de datos. También se define la tabla de análisis de sucesos para mostrar las
condiciones necesarias para los diferentes sucesos aplicables sobre los datos
(actualización, registro, lectura y eliminación) y la tabla de entidades asociativas para
mostrar los datos (entidades) interrelacionados.
Con respecto a los procesos, será utilizada la técnica de representación gráfica por
Diagramas de Flujo de Datos (DFD) y serán desglosadas las unidades de diseño en tipo
manual y automatizada. Por otra parte, serán definidos los siguientes subsistemas sobre
los cuales se desglosarán las unidades de diseño: SUBSISTEMA EMPLEADO,
SUBSISTEMA SOLICITUD VACACIONES, SUBSISTEMA SOLICITUD PERMISOS.
Continuando con la fase de Diseño e Integración. Esta sección complementa el análisis

de datos previamente estudiado. Se muestra el esquema lógico de la base de datos
relacional mediante una representación gráfica tabular. También se muestra el modelo de
distribución de datos sobre la red reflejado en el DER previamente estudiado.
5
Diseño de entradas y salidas; Continuación fase de Diseño e Integración. Las entradas
y salidas comprenden las pantallas y reportes del sistema. Las pantallas son de entrada,
de salida y de interfaces con usuario.
Para las pantallas de entrada se seguirá la siguiente metodología:
✓ Revisar los requisitos de entradas mediante el análisis de las unidades de diseño

de procesos.
✓ Diseñar los bocetos de documentos fuentes para las aplicaciones que lo requieran
(estos sin los formularios para entrada de datos).
✓ Diseñar los bocetos de pantallas de entradas para los casos de métodos en línea
o por lotes remotos.
✓ Diseñar prototipos de archivos de entradas para los casos de métodos en línea o
por lotes remotos.
Para las pantallas de salidas se seguirá la siguiente metodología:
✓ Revisar los requisitos de salidas mediante el análisis de las unidades de diseño de

procesos.
✓ Definir bocetos de pantallas de salidas, especificando características de diseño y
de los datos a utilizar. Se documentara con estructuras orientadas a usuarios y a
programadores.
✓ Definir bocetos de reportes, especificando características de diseño y de los datos
a utilizar. Se documentara con estructuras orientadas a usuarios y a
programadores.
Para las pantallas de salidas, de tipo interfaz de usuario, se seguirá la siguiente

metodología:
✓ Usando la técnica de diagrama de transición de estados, serán representadas las

estructuras de las interfaces.
✓ Definir bocetos de interfaces de usuario, especificando características de diseño y
mediante gráficos orientados a usuarios.
Finalización de fase de Diseño e Integración; diseño de programas, a continuación la

metodología a seguir:
✓ Efectuar diseño modular de los programas por Subsistema, utilizando

representación mediante gráficos de estructuras señalando las tres funciones
principales de Iniciar Proceso, Proceso Principal y Terminar Proceso.
✓ Extender la representación modular hasta obtener unidades o módulos
primordiales.
✓ Especificar los procesos primordiales mediante la utilización de lenguaje corriente
estructurado.
ETAPA IMPLANTACION
6
FASE CONSTRUIR BASES DE DATOS Y PROGRAMAS:
Para construir la base de datos se procederá como sigue:
✓ Crear la estructura de base de datos relacional mediante la herramienta de

software seleccionado (en nuestro caso manejador de base de datos MYSQL).Se
usarán las especificaciones y diseño de base de datos previamente establecidos.
✓ Llenar base de datos con datos ficticios o de pruebas.
✓ Escribir y probar los programas usando la herramienta de software seleccionada
(en nuestro caso el lenguaje de programación JAVA).
FASE DEFINIR PLAN DE CONVERSION DEL SISTEMA:
Finalización de fase de Implantación y con ello del proyecto.
Para esta etapa se preparara un plan de conversión del sistema, se instalara la base de
datos y se definirá el plan de formación de los usuarios.
UNIDAD 1:
SELECCIÓN DE UNA SOLUCIÓN DE SISTEMAS DE INFORMACIÓN.
En la unidad 1, estudiaremos las fases de selección y adquisición del diseño de sistemas.
FASE DE SELECCION.
ESPECIFICAR SOLUCIONES ALTERNATIVAS.
En la fase de definición del proyecto INDR se presentaron las necesidades del sistema
desde el punto de vista de los modelos de datos, modelos de procesos y modelos de
redes. Estas necesidades del sistema fueron estudiadas y vistas por la parte interesada
del proyecto y las aprobó por lo cual se prosigue con la ejecución del ciclo de vida del
proyecto y llegamos a este punto que consiste en especificar las posibles soluciones
alternativas que satisfagan las necesidades previamente definidas. Para esto usaremos la
técnica de presentación mediante una matriz de soluciones candidatas. En la Fig. 1, se
muestra la matriz de soluciones candidatas para el sistema INDR. Previamente,
detallemos las soluciones candidatas que para este caso solo serán dos, los cuales
llamaremos propuesta 1 y Propuesta 2.
Propuesta 1: Sistema de información automatizado basado, en lo relativo al componente

del software, en lenguaje de programación de ultima generación con capacidad de
implantación en ambiente de red local y con capacidad para interconexión a un manejador
de bases de datos también para aplicaciones en redes. En lo relativo al hardware,
establecer una red entre los usuarios del sistema INDR de tipo LAN en la que se
dependerá de un computador donde residirá la base de datos y el programa de aplicación.
7
Propuesta 2: Sistema de información automatizado basado, en lo relativo al componente
del software, en lenguaje de programación de ultima generación con capacidad de
implantación en ambiente de red extendido y con capacidad para interconexión a un
manejador de bases de datos para aplicaciones en redes. El hardware debe permitir
interconexión entre usuarios del sistema tanto a nivel local como a nivel externo (ambos
requerimientos se logran mediante el acceso a la red global-Internet).
Ahora veamos la Fig. 1:
CARACTERISTICA PROPUESTA 1 PROPUESTA 2

SUBSISTEMA EMPLEADO:
REGISTRO REALIZADADO EL EMPLEADO PUEDE REALIZAR
POR. (DEPARTAMENTO EL EMPLEADO DEBE ASISTIR EL REGISTRO A DISTANCIA
PERSONAL). CARGANDO DATOS DESDE
AL INSTITUTO PARA HACER
COMPUTADOR CONECTADO A
EL REGISTRO
INTERNET.
SUBSISTEMA EMPLEADO
EMISIN COMPROBANTE, DE
REGISTRO EL EMPLEADO DEBE ASISTIR
AL INSTITUTO Y USAR LOS EL EMPLEADO PUEDE VERIFICAR
SERVICIOS DE LA EL REGISTRO A DISTANCIA A
INSTITUCION. TRAVES DE INTERNET.
SUBSISTEMA SOLICITUD DE
VACACIONES.
REGISTRAR SOLICITUD,
CONSULTA DE SOLICITUD PUEDEN EJECUTARSE DE FORMA
PUEDEN EJECUTARSE DE AUTOMATIZADA (IGUAL
VACACIONES, ACTUALIZAR
FORMA AUTOMATIZADA. PROPUESTA 1).
SOLICITUD DE
VACACIONES
SUBSISTEMA SOLICITUD
PERMISOS.
CONSULTA DATOS
PUEDEN EJECUTARSE DE FORMA
SOLICITUD PERMISOS, PUEDEN EJECUTARSE DE AUTOMATIZADA (IGUAL
ACTUALIZAR SOLICITUD DE FORMA AUTOMATIZADA. PROPUESTA 1).
PERMISOS.
VACACIONES.
APROBACION SOLICITUD DE
VACACION.
CONSULTAR DATOS
SOLICITUD VACACION PUEDEN EJECUTARSE DE FORMA
GENERAR REPORTES
SOCIOECONOMICOS
VARIOS, ACTUALIZAR
STATUS SOLICITUD AYUDA.
PERMISOS.
APROBACION SOLICITUD DE
PERMISOS.
CONSULTAR DATOS
SOLICITUD PERMISOS PUEDEN EJECUTARSE DE FORMA
GENERAR REPORTES
VARIOS..
MATRIZ DE SOLUCIONES CANDIDATAS PARA SISTEMA INDR.
8
ANALISIS VIABILIDAD DE SOLUCIONES
Ya con dos propuestas de diseños para satisfacer las necesidades del sistema, se
realizara ahora el análisis de viabilidad de cada propuesta. Para este estudio se usara
como herramienta una matriz de viabilidad en la cual se reflejaran criterios de tipo técnico,
operativos, económico y de calendario. Esta herramienta servirá de soporte para la toma
de decisión definitiva en cuanto a propuesta de diseño. A continuación se muestra en la
Fig. 2 la matriz de viabilidad.
CRITERIO VIABILIDAD PROPUESTA 1 PROPUESTA 2

LA TECNOLOGÕA ES PRACTICA DE IGUAL QUE PROPUESTA 1; SOLO
VIABILIDAD TECNICA FACIL ACCESO Y DISPONIBLE EN EL QUE EL CLIENTE REQUIERE DE
-LA SOLUCION ES PRACTICA Y DE FACIL PAIS, EL PERSONAL TIENE INTERACTUAR CON EL SISTEMA Y DE
MPLANTACION. CONOCIMIENTOS PARA SU USO Y CONOCIMIENTOS BASICOS DE
-EL PERSONAL TIENE CONOCIMIENTOSOPERACION, EL CLIENTE NO REQUIERE COMPUTACION (USO DE INTERNET),
PARA DISEÑOS Y PUESTA ENCONOCIMIENTO O INTERRELACION REQUIERE CONTROLES DE
FUNCIONAMIENTO. CON SISTEMA AUTOMATIZADO, NO SEGURIDAD EXTERNOS (POR
-EL CLIENTE REQUIERE CONOCIMIENTOSREQUIERE CONTROLES DE SEGURIDAD CONEXION A INTERNET).
DE LA TECNOLOGÕA. EXTERNOS.
EL SISTEMA AUTOMATIZADO
PERMITIRA SATISFACCION DE
NECESIDADES, EL USUARIO
DISPONDRA DE UNA HERRAMIENTA
AMIGABLE PARA INTERACTUAR CON EL
INDR. LOS USUARIOS DEL INSTITUTO IGUAL A PROPUESTA 1; SOLO QUE
DESEAN DISPONER DE ESTA EL CLIENTE DEBE USAR UN
HERRAMIENTA PARA MEJORAR SU COMPUTADOR PARA HACER
CONDICION DE TRABAJO. HABRAN SOLICITUD LO CUAL EN ALGUNOS
VIABILIDAD OPERATIVA CAMBIOS EN ENTORNO DE TRABAJO CASOS PRESENTARA DIFICULTADES
-SATISFACCION DE NECESIDADES. POR USO DE RECURSOS FISICOS DEL OPERATIVAS PARA PERSONAS QUE
-REQUIERE CAMBIOS EN ENTORNO. SISTEMA DE COMPUTACION (RED DE NO TIENEN CONOCIMIENTOS DE USO
-OPINION DE USUARIOS. COMPUTACION PARA GESTION DE COMPUTADORAS (INTERNET) O
ADMINISTRATIVA DEL INSTITUTO). EL DE BAJO NIVEL EDUCATIVO.
EMPLEADO ES ATENDIDO EN SITIO POR
PERSONAL DEL INSTITUTO
LOS COSTOS DE DESARROLLO SE

ESTIMAN EN , LOS COSTOS DE
OPERACI”N CONTINUA SE ESTIMAN EN
, PERIODO RECUPERACION
TENIENDO EN CUENTA QUE LOS
VIABILIDAD ECONOMICA
BENEFICIOS OBTENIDOS
-COSTOS DESARROLLO. IGUAL A PROPUESTA 1.
MOYORMENTE SON DE TIPO
-COSTOS OPERACIONES CONTINUAS.
INTANGIBLE. VER DETALLE (RELACION
-PERIODO RECUPERACION.
DE COSTOS DESARROLLO SISTEMA
INDR).
SE PREVEE UNA DURACION ENTRE

VIABILIDAD DE CALENDARIO. REFERIDODISEÑO E IMPLANTACION DE 3 MESES
A DURACIONN DISEÑO Y LAAPROXIMADOS. VER EN FIG. 4, 5 IGUAL A PROPUESTA 1.
IMPLANTACION DEL MISMO. (DETALLES DE PLANIFICACION DEL
PROYECTO Y DIAGRAMA GANTT DEL
MISMO).
FIG. 2 MATRIZ DE VIABILIDAD DE PROPUESTAS DE DISEÑOS PARA EL INDR
9
Costos Estimados Sistema INDR (Anual)
Costos de Desarrollo. $
*Personal:
1 Analista Sistema (600 horas x 5 $/hora). 3.000 $
1 Programador Sistema (240 horas x 25 BsF/hora). 6.000 $
*Compra Equipos/Software:
7 Computadoras personales con accesorios 7.000 $
(Impresoras, pantallas, teclados, etc.).
1 Equipos para formación red local (concentrador, 1.000 $
Cables, conectores)
1 Software para aplicación y base de datos. 1.000 $
*Otros Gastos:
Adiestramiento de usuarios (9 personas, 10 $/persona) 90 $
Adiestramiento a personal de mantenimiento
(1 persona, 40 $/persona) 40 $
Total Desarrollo: 18.130 $
Costos Operación Continua. (Anual).
*Personal:
Solicitudes Servicios Externo (Eventual). 100 $
Contratación T.S.U. Informática ( 100 $
Para Mantenimiento Sistema).
*Suministros y Gastos.
Renovación Licencia Software. 200 $
Repuestos Hardware (Tintas impresoras, mouse, 200 $
Teclados, cables, etc.).
Material Oficina (Papeles impresión, carpetas, 100 $
Ganchos, lápices, etc.).
Total Operación: 700 $
TOTAL GENERAL: 18.830 $
FIG. 3 RELACION DE GASTOS DEL SISTEMA INDR.
En las FIG. 4 Y 5, vemos detalles de la planificación del proyecto INDR mostrando la

identificación de tareas generales para cada fase y su concatenación lógica para
proporcionar el diagrama Gantt que define el plan del proyecto INDR, en sus etapas de
diseño e implantación. Esta información sirve de base para los análisis de viabilidad
desarrollados anteriormente, (viabilidad de calendario). Cabe destacar que, incluimos
detalles de tareas relacionadas con procura, integración, implantación física solo como
muestra hipotética porque desde el punto de vista académico estos aspectos no pueden
ser ejecutados en la práctica.
La información presentada en las FIG. 4 Y 5 corresponden a la metodología ya usada en

el informe del análisis del sistema, solo que se actualiza la información en base a las
nuevas circunstancias y estimaciones.
A continuación la descripción completa de las tareas estipuladas:
Tarea A (Inicio de Fase Diseño del Sistema). Esta es la primera subfase del diseño del
sistema. Una vez recibido el informe con la lista de necesidades, representados en forma
contextual esencial, se procede a seleccionar entre las posibles alternativas de diseño
10
para el desarrollo del sistema INDR. Esta selección debe justificarse con un análisis de
viabilidad que incluya los aspectos técnicos, operativos, económicos y de tiempo.
Tarea B (Continuación Fase Diseño Sistema). Tomando como base el informe de

selección de alternativa de diseño, se precisa a detalle la procura de recursos físicos de
hardware y software especificados. Para el caso del sistema INDR implica la compra de
computadoras, impresoras, cableados, equipos de comunicaciones, conectores, software
(licencias para uso de los programas de manejo bases de datos y de desarrollo de
aplicaciones), etc. Esta subfase culmina con la recepción de todos los equipos o sistemas
procurados.
Tarea C (Culminación Fase de Diseño). Esta subfase toma como insumo el informe de
selección de alternativa de diseño para realizar el diseño e integración del sistema. En
esta subfase del CVDS se entrega un informe de relación de diseño técnico que
contendrá el diseño general o global y el diseño detallado. Serán realizados los diagramas
de estructuras de datos, diagramas de procesos, diagramas de flujo para la red
informática, entradas, salidas, pantallas, estructura y lógica del programa de aplicaciones
y de los archivos y bases de datos. Todo esto será reflejado en la relación técnica del
diseño.
Tarea D (Inicio de Fase Implantación). En esta subfase, tomando como base la relación
técnica del diseño se procede a crear y probar las redes y bases de datos. El programa de
carga y mantenimiento de la base de datos del sistema INDR será creado, al igual que la
red informática. Para esta fase debe estar completada la procura de como producto final
se entregara la red y la base de datos vacíos, pero probadas.
Tarea E (Continuación Fase de Implantación). Esta súbase toma como base la relación
técnica del diseño y es procede a crear y probar el programa de aplicación del
sistema INDR el cual esta interrelacionado con el programa de manejo de bases de
datos (por esto las tareas D y E parten simultáneamente ya que están muy
interrelacionadas técnicamente). Este programa será probado sobre los equipos
programados procurados, por esto requieren de estos para poder completarlo. Como
producto final se entrega el programa depurado y probado pero no instalado para
operación normal en el INDR.
Tarea F (Continuación Fase de Implantación). Una vez creado y probado tanto la base
de datos, el programa de aplicación y la red de comunicaciones, continua esta fase
que corresponde a la instalación y prueba del sistema automatizado INDR. Todo el
sistema INDR, en cuanto a sus componentes de hardware y software, será probado
en funcionamiento para verificar su funcionamiento como sistema integrado. Por
supuesto, será cargado la base de datos y el programa de aplicación para trabajo en
ambiente de red. El producto final será el sistema INDR funcionando correctamente,
luego de cumplir con las pruebas y ajustes necesarios.
Tarea G (Culminación Fase Implantación). Esta es la última súbase de la fase de

implantación y con esta se completa el CVDS. Finalmente, se realizara adiestramiento a
usuarios, entrega de documentación y sistema en operación normal en el INSTITUTO
NACIONAL DE DEPORTE Y RECREACION.
11
SELECCION ALTERNATIVA DE DISEÑO.
Ya presentadas las alternativas de diseño (para nuestro caso son dos) con sus
respectivos análisis de viabilidad tabulados, usando criterios operativos-técnicos-
económicos-calendario, se procederá a seleccionar la mejor opción usando como
herramienta la elaboración de una matriz de valores de muestra o matriz de Baremo
(Fig. 6).
Los pasos expresados en porcentaje (%) para cada criterio se definen como: 0% para
opción menos deseable y 100% para opción más deseable o mejor.
En cuanto a los valores tabulados para cada opción fueron definidos por criterios
personales del usuario del sistema al cotejar los análisis de viabilidad. Veamos estos
resultados en la Fig. 6.
CRITERIO DE VIABILIDAD PROPUESTA 1 PROPUESTA 2

Viabilidad Operativa 100% 80%
Viabilidad Técnico 100% 95%
Viabilidad Económica 80% 80%
Viabilidad Calendario 100% 100%
Resultado (% promedio) 95,25% 88,75%
FIG. 6 MATRIZ DE VALORES DE MUESTRA.
Veamos la justificación de estos valores obtenidos.
Viabilidad Operativa: El usuario considera satisfactoria plenamente la propuesta 1 y

manifiesta preferir que el cliente del sistema (empleado) asista personalmente al instituto
para hacer efectivo el registro. Considera que la propuesta 2, aunque tecnológicamente
es bastante atractiva, puede traer inconvenientes de tipo operativos con el cliente (caso
personas sin conocimientos básicos de computación). De acuerdo a estas apreciaciones
evalúa la propuesta 2 por debajo de la propuesta 1.
Viabilidad Técnica: Las tecnologías a aplicar para ambos casos son plenamente
viables y de fácil desarrollo e implantación. A pesar de esto, el usuario avala la
propuesta 2 ligeramente por debajo de la propuesta 1 alegando razones técnicas
relativas a la necesidad de orientación técnica para los clientes de poco conocimiento
de computación.
Viabilidad Económica: El usuario asigna mismo peso a ambas propuestas.
Viabilidad Calendario: El usuario asigna mismo peso a ambas propuestas.
Finalmente, por los resultados arrojados en la matriz de valores de muestra, la solución

escogida para el desarrollo del sistema es la propuesta 1:
Sistema de información automatizado basado, en lo relativo al componente

Software, en lenguaje de programación de última generación, con capacidad de
12
Implantación en ambiente de red local y con capacidad para interconexión a una base de
datos también para aplicaciones redes. En lo relativo a su componente hardware, se
establecerá una red entre los usuarios del sistema INDR de tipo LAN en lo que se
dispondrá de un computador principal donde residirá la base de datos y el programa de
aplicación.
FASE DE ADQUISICION.
DETERMINAR LA OPCIONES Y CRITERIOS TECNICOS.
Las opciones y criterios técnicos para satisfacer las necesidades generales establecidas
en la propuesta de diseños generales podemos dividirlas en dos aspectos: software y
hardware. Veamos aspectos técnicos para cada una de las partes:
CRITERIOS TECNICOS SOFTWARE: Las opciones para selección de lenguajes de

programación de ˙última generación son variadas, desde los lenguajes de programación
de propietario, los cuales requieren un costo por pago de licencia (Ej.: Visual Basic) hasta
lenguajes de programación abiertos los cuales no requieren costos por derecho de
propietario (Ej.: Java, C+, C++). Para los manejadores de bases de datos se puede
establecer la misma clasificación; entre los manejadores tipos propietario se tienen:
Microsoft SQL, Microsoft Access, etc. y entre los tipos abiertos o públicos Misal. Los
paquetes de programación abiertos o públicos pueden trabajar en la mayoría de los
sistemas operativos existentes (abiertos o cerrados), mientras que los tipos propietario
requieren de un sistema operativo especificado limitado a algunos fabricantes de sistema
operativos. Estos aspectos señalados establecen una diferencia apreciable en costos y
autonomía o seguridad en cuanto a condiciones de operatividad; obviamente los sistemas
abiertos o públicos brindan mayores ventajas en estos aspectos señalados.
CRITERIOS TECNICOS DE HARDWARE: Para cumplir los requerimientos generales de

hardware existen variadas configuraciones para establecer una red de comunicación
entre computadoras que comparten el uso de un sistema de información de tipo contable,
como es el caso del INDR.
TIPOS DE REDES.
Según el tamaño:
➢ LAN (red de área local): de 10 metros a 1 kilómetro, suelen usar brokas y su

velocidad va de 10 a 100 Mbps.
➢ MAN (red de área metropolitana): tamaño máximo 10 kilómetros.
➢ WAN (red de área amplia): tamaño entre 100 y 1000 kilómetros.
➢ INTERNET: más de 10000 kilómetros.
Según su tecnología de transmisión:
➢ redes Broadcast: Son las redes donde los datos llegan a todas las máquinas de
la red, un solo canal de comunicación.
➢ redes point-to-point: Son aquellas donde hay muchas conexiones entre
parejas individuales de máquinas.
Según el tipo de transferencia de datos:
13
➢ Transmisión simple: Los datos solo pueden ir en un sentido.
➢ Half-duplex: Los datos pueden ir en ambos sentidos pero solo en uno a la
vez.
➢ Full-duplex: Los datos pueden ir en ambos sentidos a la vez.
TOPOLOGÍAS DE REDES.
➢ Bus: Todas las máquinas están conectadas a un ˙único cable por donde pasa
toda la información, esta llega a todas las maquinas. Tienen un Hub o un switch al
final.
➢ Anillo: Es un anillo cerrado donde cada nodo o PC está conectado con sus nodos
adyacentes formando un anillo. La información se transmite de nodo en nodo.
➢ Anillo doble: En lugar de un anillo, hay dos para aumentar la fiabilidad de la
red.
➢ Estrella: Es un nodo central q normalmente es un Hub y a Él están
conectados todos los pc, la información pasa por el Hub para luego ir a su
destino.
➢ Estrella extendida: Cada nodo q conecta con el nodo central, es centro de otra
estrella, normalmente los centros los ocupan Hub.
➢ árbol: Tiene un nodo troncal q suele ser un Hub desde el que se ramifican
los demás nodos.
➢ Malla completa: Todos los nodos se comunican directamente entre sí.
➢ Celular: Circunferencias con nodos individuales en el centro, es para redes
inalámbricas.
COMPONENTES HARDWARE DE UNA RED.
En algunas redes los ordenadores trabaja a veces como estaciones de trabajo y otras
como servidor, a estas redes se les denomina redes igualitarias o peer to peer.
SERVIDORES.
Pueden ser dedicados, Ósea q solo funcionan como servidores o no dedicado; Cuando
pueden funcionar tanto de servidores como de estaciones de trabajo.
ESTACIONES DE TRABAJO.
Los ordenadores conectados a la red son estaciones de trabajo.
TARJETAS DE RED.
Son las tarjetas de comunicaciones.
Sistema de cableado Coaxial: se divide en dos.
• coaxial fino: 10base2.
• coaxial grueso: 10base5 Fibra Óptica: 10base-f
Cable par trenzado: se divide en dos.
• Apantallado
• sin apantallar
Cable estructurado:
HUB:
• Socotra ethernet
• token ring
• FDDI.
14
Encaminamiento y enlace a alta velocidad.
Circuitos dedicados entre nodos.
Repetidores multipuerto.
Switch (conmutador)
Dispositivo de red que crea líneas dedicadas entre sus puertos para evitar Colisiones
en la red. Es un bridge multipuerto.
HERRAMIENTAS DE INTERCONEXION.
• Repetidores: Actúan en la capa física y aumenta la señal de transmisión.

• Bridges o puentes: Actúan la capa enlace de datos, trabajan con direcciones
MAC, Envían tramas, Resuelven bucles.
• Routers o encaminadores: Actúan en la capa de red, Trabajan con IP
Cooperan entre sí para encaminar los paquetes Filtran paquetes de datos.
• gateways o pasarelas. Actúan en la capa de aplicación, Intercambian datos
con las aplicaciones
SOLICITAR PRESUPUESTO A VENDEDORES.
La propuesta de diseño establece los requerimientos generales del diseño y el analista

realizó una investigación previa de opciones y criterios técnicos para prepararse en la
solicitud de presupuesto, interrelación y análisis de ofertas de los potenciales
vendedores. Para este caso particular del sistema INDR, se solicitara a los
potenciales vendedores una solicitud de propuesta que incluirá presupuesto.
NORMAS E INSTRUCCIONES.
CALENDARIO DE SUCESOS QUE LLEVAN AL CONTACTO.
Una vez recibido este documento por las partes interesadas; estos deberán presentar
la propuesta con presupuesto estimado a más tardar a los tres días hábiles. El
instituto dará respuesta en un máximo de cinco a tres hábiles siguientes (a partir de
entrega propuesta) e inmediatamente entregara los compromisos o Órdenes de
compras respectivos de acuerdo a especificaciones de la oferta ganadora. Una vez
entregadas las ordenes de compras, la empresa tendrá· un máximo de catorce días
continuos para hacer la entrega del sistema en compra. El instituto se reserva el
derecho de rescindir el contrato en caso de incumplimiento de este calendario.
REGLAS PARA PROCESO DE PROCURA.
La solicitud de propuesta a potenciales vendedores será entregada por el

administrador o persona designada por este en la sede del instituto en reunión fijada
para todos los interesados.
La propuesta u oferta debe ser entregada de acuerdo al calendario establecido al
administrador del instituto o persona designada por este.
La propuesta ganadora será anunciada por el administrador del instituto, en reunión
fijada para tal fin.
15
EVALUAR PROPUESTAS DE VENDEDORES.
Las propuestas ofrecidas por los vendedores previamente deben ser revisadas para
validar que cumplen con los requisitos exigidos. Para nuestro caso se asume que
cumplen con estos y entonces se procede a la evaluación desde el punto de vista de
mejor oferta para los intereses del solicitante. Para realizar este análisis y selección se
usara la técnica de elaboración de matriz de viabilidad ya usada en casos anteriores;
al igual que antes se consideraran los aspectos de viabilidad técnica, viabilidad
operativa, viabilidad económica y viabilidad de calendario.
Una vez recibidas las ofertas, veamos ahora la evaluación de las mismas:
La FIG. 6 (Matriz de viabilidad ofertas sistema INDR) muestra el análisis de las

ofertas.
CRITERIO DE VIABILIDAD OFETA EMPRESA A OFERTA EMPRESA B

-LA TECNOLOGIA OFRECIDA ES PRACTICA
Y DE FACIL ACCESO.
-LA TECNOLOGIA CUMPLE CON LOS -LA TECNOLOGIA OFRECIDA ES
REQUERIMIENTOS ESTABLECIDOS. PRACTICA Y DE FACIL ACCESO.
-LA CONFIGURACION PARA LA RED, -LA TACNOLOGIA CUMPLE CON
PERMITE CAPACIDAD DE EXPANSIONREQUERIMIENTOS ESTABLECIDOS.
FUTURA PARA AUTOMATIZAR OTROS-LA CONFIGURACION PARA LA RED
VIABILIDAD TECNICA: PROCESOS DEL INSTITUTO; ADEMAS DENO PERMITE CAPACIDAD PARA
SER SEGURA EN CUANTO A INTEGRIDAD CRECIMIENTO FUTURO Y LA
-LA SOLUCION ES PRACTICA Y DEDE INFORMACION Y DIDPONIBILIDAD POR INFORMACION DEL INDR NO ESTA
FACIL IMPLANTACION? SU DEDICACION EXCLUSIVA. EN SITIO A DEDICACION
-LA SOLUCION SATISFACE-LOS SOFTWARE PARA APLICACIONES YEXCLUSIVO.
REQUERIMIENTOS? DESARROLLO SON ABIERTOS LO CUAL-LOS SOFTWARE PARA APLICACION
CUMPLE CON LAS PILITICAS NACIONALES Y DESARROLLO SON TIPO
DE INDEPENDENCIA TECNOLOGICA. CERRADOS O PROPIETARIOS LOS
CUALES NO CUMPLEN CON
POLITICAS NACIONALES DE
INDEPENDENCIA TECNOLOGICA.
-LA OFERTA CUMPLE CON LA

NECESIDADES OPERACIONALES
REQUERIDAS POR LOS USUARIOS DE LA
VIABILIDAD OPERATIVA: APLICACIÓN A DISEÑAR EN EL INSTITUTO
-LOS ANALISTAS Y DISEÑAADORES PUEDEN IGUAL A OFERTA EMPRESA A.
-SATISFACCION DENECESIDADES REALIZAR LA APLICACION SIN
OPERACIONALES. INCOVENIENTES TECNICOS.
-OPINION DE DISE—ADORES Y
ANALISTA SISTEMA.
VIABILIDAD ECONOMICA: -COSTO DE PROCURA: . COSTO DE PROCURA:

-GARANTIA COMPONENTES ACEPTABLE: -GARANTIA COMPONENTES
-COSTO DE LA PROCURA. ACEPTABLE:
.GARANTIA SATISFACTORIA.
VIABILIDAD DE CALENDARIO: -TIEMPO DE ENTREGA: (10) DIAS HABILES A-TIEMPO DE ENTREGA: (12) DIAS
-DURACION PUESTA EN SITIO DEPARTIR ENTREGA ORDEN DE COMPRA. HABILES A PARTIR ENTREGA
COMPONENTES. ORDEN DE COMPRA
FIG. 6 MATRIZ DE VIABILIDAD DE OFERTA PARA PROCURA SISTEMA INDR.
16
Finalmente, mediante el uso del sistema de Baremo se escoge la mejor oferta. Se
asume como medida de peso para opciones: 0% oferta menos atractiva y 100% mejor
oferta. En la FIG. 7, está la matriz de valores por sistema de baremo.
CRITERIO DE VIABILIDAD OFERTA DE EMPRESA A OFERTA DE EMPRESA B
Viabilidad Operativa 100 70

Viabilidad Técnico 100 100
Viabilidad Económica 80 90
Viabilidad Calendario 100 98
Resultado Ponderado 92 89,5
FIG. 7 MATRIZ DE VALORES ANALISIS OFERTAS PROCURA SISTEMA INDR.
El analista y propietario da un mayor peso al aspecto técnico relacionado con la topología

de la red, lo cual brinda bondades mayores la oferta de la empresa A en capacidad de
expansión o crecimiento futuro por el hecho de disponer de un servidor, a dedicación
exclusiva. El uso de paquetes de programación abiertos resulta importante para el
propietario y resulta también factor determinante para valorar mejor la oferta A:
finalmente, los costos difieren siendo mejor la oferta B en comparación a la oferta A, pero
el propietario decide que las bondades técnicas resultan determinantes en la selección y
por eso el peso asignado no influye en el resultado final.
La oferta de la empresa A resulta más conveniente para el INSTITUTO NACIONAL

DE DEPORTE Y RECREACION y se declara ganadora del proceso de procura.
17
UNIDAD 2.
ANÁLISIS DE DATOS.
ANALISIS Y DISTRIBUCION DE DATOS.
Para cumplir con esta primera etapa de la fase de diseño e integración efectuaremos un
modelo de datos esencial normalizado aplicando para esto:
a) Técnica de análisis de datos
b) técnica de análisis de sucesos.
ANALISIS DE DATOS.
Partiremos del modelo de datos definido en el análisis del sistema (ver informe 335). Este
modelo es el punto de partida y al final obtendremos un modelo de datos refinado o
normalizado listo para la fase de creación (en códigos) de la base de datos de INDR. Con
esta información proseguimos con el análisis de datos; aplicando la técnica o metodología
mostrado en los pasos siguientes:
Paso 1: Verificar o Añadir Claves a Entidades.
Las claves asignadas durante el análisis del sistema son apropiadas y se mantienen.
18
Paso 2: Poner las Entidades en 1FN.
19
Paso 3: Poner las Entidades en 2FN.
20
21
Paso 4: Poner las Entidades en 3FN
22
23
Paso5: Otras Simplificaciones:
24
Paso 6: Elaborar el DER Refinado
25
26
27
El Impacto del análisis de datos y de sucesos en los DFD
28
Paso7: Revisar y Afinar el Modelo de Datos.
Para este caso, al ser el usuario del sistema el mismo analista y diseñador del sistema, se
asume que el usuario acepta la nueva propuesta y por tanto no requiere más revisión o
afinación.
ANALISIS DE SUCESOS.
Sobre el modelo de datos refinado ya presentado, se identificaran los sucesos de
empresa y las condiciones que hacen que los datos se creen, se modifiquen, o se borren.
La necesidad de llevar a cabo el análisis de sucesos se debe a que aunque hemos

obtenido un modelo normalizado listo para el diseño, no podemos asegurar que todos los
datos han sido tomados en cuenta, en el modelo esencial de procesos (los DFD), a fin de
su creación y actualización. De hecho, el modelo E/R normalizado, es un modelo que muy
probablemente, incluya entidades que no estaban presentes en el modelo esencial de
datos. Recordemos, que en la etapa del análisis de sistemas, el modelo esencial de datos
y el modelo esencial de procesos, estaban sincronizados, es decir, que en éste último, se
garantizaba que los datos eran mantenidos al día por los procesos correspondientes.
Entonces, ahora es necesario revisar y/o modificar los DFD, de modo que incluyan los
procesos y flujos de datos, que garanticen la creación y actualización de las nuevas
entidades que contiene el modelo de datos normalizado.
El análisis de sucesos es una técnica que toma como punto de partida el modelo E-R
normalizado y completa el modelo esencial de procesos con aquellas acciones y
condiciones que hacen posible que se creen, modifiquen o eliminen las entidades de
datos. El modelo esencial de procesos resultante es denominado “modelo de procesos
revisado o sincronizado”.
A continuación se detallan los pasos necesarios para efectuar este análisis:
Paso 1: Identificar Sucesos de las Entidades Fundamentales.
Las entidades fundamentales son:
➢ EMPLEADOS
➢ EMPLEADOS dependencia
➢ SOLICITUD VACACIONES
➢ VACACIONES
➢ SOLICITUD PERMISOS
➢ PERMISOS
Veamos en la FIG. 3.1, la tabla de sucesos para estas entidades. Se escogerán los
sucesos que se consideran más posibles de ocurrir.
FIG 3. 1
DESCRIPCION DEL NOMBRE DEL

ENTIDAD CLAB CONDICIONES
SUCESO SUCESO
Permite registrar todos Registro
EMPLEADO C ninguna
los datos del empleado Empleado
29
Se lleva un registro del
cargo y dependencia a la
que pertenece cada Registro del 1.-debe existir ya
empleado, permitiendo empleado en una presencia de
C
almacenar la información el la entidad
necesaria para hacer los organigrama EMPLEADO
cronogramas de
EMPLEADO vaciones.
dependencia Permite obtener todos
los datos del empleado
concerniente a su cargo 1.-debe existir ya
y ubicación en la Clasificación una presencia de
L
empresa, para del empleado la entidad
clasificarlos (empleados, EMPLEADO
jefes, directores, etc.) y
ubicarlos.
1.-debe existir ya
Se generan las nuevas Solicitud una presencia de
SOLICITUD
solicitudes permitiendo vacaciones C la entidad
VACACION
llevar un control de ellas empleado EMPLEADO
dependencia
1.-debe existir ya
una presencia de
la entidad
Registra todos los datos EMPLEADO
relacionados con las Registro dependencia
VACACION A
vacaciones de vacaciones 2.-debe existir ya
empleados una presencia de
la entidad
SOLICITUD
VACACION
1.-debe existir ya
Se generan las nuevas
Solicitud una presencia de
SOLICITUD solicitudes de permiso,
permisos C la entidad
PERMISO permitiendo llevar un
empleado EMPLEADO
control de ellas.
dependencia
1.-debe existir ya
una presencia de
la entidad
Nos permite acceder al EMPLEADO
registro del record de dependencia
Registro de
PERMISO permisos al empleado A 2.-debe existir ya
permisos
para su información y una presencia de
soporte a su aprobación la entidad
SOLICITUD
PERMISO
SOLICITUD De esta entidad se 1.-debe existir ya

Preparar
VACACION- obtienen parte de los una presencia de
cronograma L
EMPLEADO datos necesarios para la entidad
de vacaciones
dependencia hacer los cronogramas EMPLEADO
30
dependencia
2.-debe existir ya
una presencia de
la entidad
SOLICITUD
VACACION
1.-debe existir ya
una presencia de
la entidad
Una vez elaborados los
EMPLEADO
cronogramas se
Informe a las dependencia
realizara un informe para L
direcciones 2.-debe existir ya
las dependencias
una presencia de
correspondiente
la entidad
SOLICITUD
VACACION
Se harán los reportes
necesarios para que los 1.-debe existir ya
Información
empleados tengan una presencia de
vacaciones A
acceso a esta la entidad
empleados
información de EMPLEADO
vacaciones
1.-debe existir ya
una presencia de
la entidad
Relaciona un informe de EMPLEADO
permisos a las distintas Informe dependencia.
L
dependencias permisos 2.-debe existir ya
correspondientes una presencia de
la entidad
SOLICITUD
SOLICITUD
PERMISO-
PERMISO
EMPLEAADO
1.-debe existir ya
dependencia
una presencia de
la entidad
Nos permite generar un EMPLEADO
informe con los tipos de Tipos dependencia.
L
permisos que lleva el permisos 2.-debe existir ya
empleado una presencia de
la entidad
SOLICITUD
PERMISO
Paso 2: Identificar los Sucesos de las Entidades Asociativas.
Las entidades asociativas son:
31
▪ SOLICITUD VACACION-EMPLEADO dependencia
▪ SOLICITUD PERMISO-EMPLEAADO dependencia
Paso 3: Agrupar Sucesos Comunes.
VEAMOS AHORA LA ACTUALIZACIÓN DEL DICCIONARIO DEL PROYECTO

MODELO DE DATOS.
Para representar las estructuras de datos reflejadas en el modelo de datos ya descrito,

se usaran dos tipos de estructuras: secuénciales y de repetición. Serán documentadas en
el diccionario del proyecto con notación de tipo representación en lenguaje corriente.
Veamos la sección de modelización de datos del diccionario del proyecto:
DICCIONARIO DEL PROYECTO: Sistema de información automatizado para el registro

de las solicitudes de vacaciones y permisos para los trabajadores INDR
a) DESCRIPCION DE LAS ENTIDADES.
EMPLEADO
EMPLEADO dependencia
VACACION
PERMISO
SOLICITUD VACACION
SOLICITUD PERMISO
b) ATRIBUTOS E IDENTIFICADORES.
Nombre de la entidad: EMPLEADOS

Atributos que contiene:
CEDULA DE IDENTIDAD (atributo identificador)
APELLIDOS Y NOMBRES
FECHA DE INGRESO.
ID EMPLEADO
Nombre de la entidad: EMPLEADOS dependencia

ID EMPLEADO (atributo identificador)
DEPARTAMENTO PERTENECE
DIVISION PERTENECE
DIRECCION PERTENECE
Nombre de la entidad SOLICITUD VACACIONES.

NUMERO DE SOLICITUD DE VACACIONES. (Atributo identificador)
32
FECHA DE PREPARACIÓN DEL FORMULARIO
DIRECCIÓN QUE ENVÍA EL FORMULARIO
CEDULA DE IDENTIDAD
PERIODO A DISFRUTAR (EJEMPLO: 2019-2020)
NOMBRE Y APELLIDO DEL DIRECTOR DE RECURSOS HUMANOS
FECHA DE CUANDO FIRMO EL DIRECTOR
Nombre de la entidad VACACIONES.

NUMERO DE VACACIONES. (Atributo identificador)
CEDULA DE IDENTIDAD;
PERIODO PENDIENTE QUE NO LA DISFRUTÓ (EJEMPLO 2018-2019);
FECHA DE INICIO DEL PERIODO VACACIONAL;
FECHA DE CULMINACIÓN DEL PERIODO VACACIONAL;
FECHA DE REINCORPORACIÓN AL TRABAJO;
OBSERVACIONES;
Nombre de la entidad: SOLICITUD PERMISOS.

NUMERO DE SOLICITUD DE PERMISO (atributo identificador)
FECHA DE PREPARACIÓN DEL FORMULARIO;
DIVISIÓN O DEPARTAMENTO AL QUE PERTENECE;
NOMBRE Y APELLIDOS DEL(OS) JEFE(S);
FECHA DEL DÍA QUE EL JEFE FIRMA
Nombre de la entidad: PERMISOS.

NUMERO DE PERMISO (atributo identificador)
DURACIÓN DEL PERMISO (HORAS/DÍAS);
FECHA DE INICIO;
FECHA DE CULMINACIÓN;
BREVE DESCRIPCIÓN DEL MOTIVO DEL PERMISO;
ESPECIFICACIONES ATRIBUTOS DE DATOS.
*Elemento: Cedula Empleado.

Nombre Alternativo: CEDULA empleado.
Definición: Número de cédula de identidad del solicitante.
Pertenece a entidad Datos EMPLEADO.
Input Formato: 99.999.999.
Output Formato: 99.999.999.
Regla Edición: 0 hasta 99.999.999.
Posición Coma Decimal: No.
33
Número Máximo Presencias: 01.
Elemento: Apellidos y Nombre.

Nombre Alternativo: Apellidos y Nombres.
Definición: Apellidos y Nombre del empleado.
Input Formato: X (50).
Output Formato: X (50)
Regla Edición: solo letras.
Elemento: Fecha de ingreso.

Nombre Alternativo: Fecha de ingreso.
Definición: fecha de ingreso del solicitante.
Input Formato dd/mm/aa
Output Formato: dd/mm/aa.
Regla Edición: d= 1 a 31; m= 1 a12; a= 0 a 99.
Elemento: ID Empleado.
Nombre Alternativo: ID empleado.
Definición: atributo que contiene el ID del empleado.
Input Formato: 9999.
Output Formato: 9999
Regla Edición: 0 hasta 9999.
Elemento: Cedula Empleado.

Nombre Alternativo: CEDULA SOLICITANTE.
Elemento: Cedula Empleado.

Nombre Alternativo: CEDULA SOLICITANTE.
34
Número Máximo Presencias:
ESPECIFICACIONES REGISTROS Y ALMACENES DE DATOS.
Posteriormente, en este informe, serán actualizados los registros y almacenes de datos
UNIDAD 3:
ANÁLISIS Y DISEÑO DE PROCESOS.
MODELO DE PROCESOS.
Se mantiene la misma estructura establecida en el diagrama descomposición INDR y en

la descripción de procesos mediante uso de lenguaje estructurado
35
36
37
ANALISIS Y DISTRIBUCION DE PROCESOS/CREAR UNIDADES DE DISEÑO.
Ya con la estructura de base de datos revisada y/o normalizada más el modelo de

procesos esencial revisado podemos pasar a la siguiente actividad en la metodología,
para el diseño del sistema, el modelo de implantación de los procesos. Se usara la
metodología de generación de unidades de diseño de implantación para procesos y
redes, mediante la representación en DFD.
DEFINIR UNIDADES DE DISEÑO MANUAL Y AUTOMATIZADO.
Tomaremos el diagrama de descomposición de procesos como punto de referencia y

haremos los DFD de implantación recuerden que tiene que ser los procesos primordiales
que no se pueden desglosar más, prácticamente todos los procesos van hacer
automatizados sin embargo tenemos procesos manuales como
• llenados de los formularios por parte del empleado.

• traslado de los formularios llenos a los directores o jefes inmediatos para su firma.
• Llevar el archivo físico de estas solicitudes para cuando se realice las
conciliaciones.
• Firmas del jefe de departamento.
• Llevar los expedientes del registro de empleados.
Usando el modelo esencial de procesos como referencia se definirán las siguientes de

unidades de diseño manual.
En esta primera unidad de implantación manual vemos que hay una expansión de los
procesos en comparación al modelo esencial de procesos. Esto es normal debido a que
esta es una fase mucho más elaborada y precisa porque corresponde a la implantación o
diseño propiamente definitivo. Esto lo veremos en las siguientes unidades de diseño tanto
manual como automatizadas. En resumen, vemos en esta primera unidad de implantación
manual, que corresponde al subsistema de solicitud de vacaciones, como el funcionario
responsable es el analista, el cual interactúa con el solicitante de vacaciones para atender
solicitud inicial, atender entrega de la solicitud para la firma del director. Para estos fines
se usa el formulario especificado (FINDR002) y se usan los archivos o base de dato física
(DB1). También vemos que necesariamente, el analista interactúa con elementos de
unidades de implantación automatizadas las cuales se representan como agentes
externos.
UNIDAD DE DISEÑO AUTOMATIZADA /CLIENTE SERVIDOR, ONLINE.
A continuación se muestran en las siguientes figuras 5 las unidades de diseño

automatizada para el INDR.
38
39
40
41
42
43
DEFINIR LOS PROCESOS AUTOMATIZADOS EN LOTE Y EN LÍNEA.
Para el diseño del sistema INDR la mayoría de las transacciones que componen los
procesos se deben de ejecutar inmediatamente y a petición. El sistema requiere de un
procesamiento continuo debido a la interacción permanente con el usuario y le necesidad
de tiempos de respuestas bajos. Esto implica que podemos definir como tiempo de
respuesta máximo 10 seg. Las respuestas a consultas, actualizaciones, registros,
eliminación deben ser IAP (menor a 10 seg.). Por lo antes descrito, estas transacciones
serán procesadas en modo ON LINE, mediante el empleo de la topología de red tipo
cliente/servidor.
En cuanto a los procesos en lotes, solo podemos señalar como tal el de generación de
reportes, en los subsistemas. Estos reportes son generados periódicamente por el mismo
sistema automatizado. Por la característica de esta transacción, puede ejecutarse ASAP
(de hecho puede obtenerse respuesta luego de 10 seg.). Los procesos que se estén
ejecutando en el puesto de trabajo del director deben tener prioridad ante que la
presentación de los reportes, por esto podemos procesarlos en lote (Batch).
CICLOS DE LOS PROCESOS.
En la sección anterior ya se comentó suficiente sobre esto. Recapitulando para el caso del
sistema INDR solo tenemos procesos de tipo ASAP en el subproceso de generación de
reportes. Recordamos que el tiempo de respuesta fijado es 10 seg. (Usado para este
análisis).
44
45
46
MODELO DE IMPLANTACIONES DE REDES.
En la siguiente figura se muestra el modelo de implantación de redes usando la

representación en DFD de topologías de redes los puestos de trabajos involucrados son
en total seis; estos representan el número de clientes del sistema (ordenadores o
plataformas de trabajo). Para el sistema INDR se usara una topología de redes tipo
cliente/servidor por lo que en definitiva se tendrán seis nodos para los clientes y un nodo
para el servidor. Adicionalmente, se considera un nodo adicional para el personal de
sistemas que realiza mantenimiento y soporte del sistema
A continuación en la FIG. Se muestra el DFD de implantación de topología de redes para

el INDR.
47
48
DISTRIBUCION DE ALMACENES.
Para el sistema INDR, el cual es un sistema basado en una red local ubicada en un una
área geográfica concentrada y de tamaño reducido, la distribución de datos requiere de un
solo procesador para su almacenamiento y este corresponde al procesador que funciona
como servidor en la topología seleccionada (cliente/servidor). Sin embargo, en la práctica
esta aplicación debe hacerse con un almacenamiento de datos centralizado el cual estar·
ubicado en el nodo con el servidor. La siguiente fig. 3.2 Muestra la distribución de los
almacenes.
DISTRIBUIR LOS PROCESOS EN LOS PUESTOS.
Veamos (fig. 3.3) la distribución de los procesos en los puestos en forma de DFD de
diseño final.
49
FIG 3. 2
50
FIG 3. 3
51
UNIDAD 4:
DISEÑO DE BASES DE DATOS.
Para el diseño del almacenamiento de datos informático del SISTEMA INDR se usara un
conjunto de archivos interrelacionados para conformar una base de datos relacional. Para
el diseño de esta base datos debemos usar como referencia el DER del INDR
(DIAGRAMA 1) y el modelo de datos del sistema o las especificaciones del modelo de
datos el cual puede verse en la sección de modelo de datos del diccionario del proyecto.
Al tener normalizado el modelo de datos, podemos establecer fácilmente la base de datos
relacional. Para efectos de este informe, la base de datos relacional del INDR
(informática) la llamaremos DB2 y los diversos archivos que la componen ya los hemos
identificados como DB2.1, DB2.2, DB2.3, DB2.4, DB2.5, DB2.6.
ESQUEMA LOGICO.
De acuerdo a lo anterior, la FIG. 4.1 Muestra el esquema lógico de la base de datos

relacional e informática INDR (DB2). En el esquema de la base de datos DB2 del INDR
vemos la representación esquemática de tipo relacional entre tablas o archivos enlazados
por claves externas señaladas en las líneas punteadas que unen las tablas de acuerdo al
DER. En el interior de cada tabla se define el nombre del archivo, los campos que
funcionan como claves y descriptores. Fundamentalmente, el campo cedula solicitante del
archivo (entidad) DATOS EMPLEADOS nos sirve como clave externa para la mayoría de
las tablas, solo tenemos una clave externa diferente (ID empleado) para relacionar el
archivo DATOS EMPLEADO con el archivo EMPLEADO DEPENDENCIA.
52
DIAGRAMA 1.
53
MODELO DE DISTRIBUCION DE BASE DE DATOS.
FIG. 4 1
ACTUALIZACION DICCIONARIO DEL PROYECTO.
A continuación la especificación de los registros en el diccionario del proyecto.
54
VII) REGISTROS DE DATOS.
Para Entidad EMPLEADOS.
Registro: EMPLEADO.
Nombre Alternativo: DB2.1
Definición. Contiene datos personales de los empleados.
Normalización: SI
Elementos del Registro OCC TYPE:
Cedula empleado
Nombre empleado
Apellido empleado
Fecha de ingreso
Id empleado
Para Entidad EMPLEADOS dependencia.

Registro: EMPLEADO.
Definición. Contiene datos de ubicación en el organigrama de la empresa de los
empleados.
Normalización: SI
Dirección pertenece
División pertenece
Departamento pertenece
Cargo
Id empleado
Para Entidad SOLICITUD VACACIONES.

Registro: SOLICITUD VACACIONES.
Definición. Contiene datos personales de los empleados.
Normalización: SI
Fecha de preparación del formulario;
Dirección que envía el formulario;
Apellidos y nombres del empleado solicitante:
Cedula de identidad;
Cargo del empleado;
Periodo a disfrutar;
Periodo pendiente que no la disfrutó;
Fecha de reincorporación al trabajo;
Observaciones;
Nombre y apellido del director de recursos humanos;
Fecha de cuando firmo el director
Para Entidad VACACIONES.

Registro: VACACIONES.
empleados.
55
Normalización: SI
Numero de vacaciones. (Atributo identificador)
Fecha de ingreso al instituto;
Fecha de inicio del periodo vacacional;
Fecha de culminación del periodo vacacional
Periodo a disfrutar;
Periodo pendiente que no disfrutó;
Para Entidad SOLICITUD PERMISOS.

Registro: SOLICITUD PERMISOS.
Definición. Contiene datos de los permisos.
Normalización: SI
Fecha de preparación del formulario;
División o departamento al que pertenece;
Apellidos y nombres;
Cedula de identidad;
Cargo;
Breve descripción del motivo del permiso;
Nombre y apellidos del(os) jefe(s);
Fecha del día que el jefe firma
Para Entidad PERMISOS.

Registro: PERMISOS.
empleados.
Normalización: SI
Numero de permiso (atributo identificador)
Duración del permiso (horas/días);
Fecha de inicio;
Fecha de culminación;
División pertenece
Departamento pertenece
ALMACENES DE DATOS
A continuación las especificaciones, en el diccionario del proyecto para los almacenes de
datos
Sub Almacén DB2.1.

Etiqueta: Datos empleado.
Localización: Departamento de personal.
Manual o Computarizado: C.
Total Numero Registrado: Indeterminado.
Descripción: Almacén de datos digitales que contiene toda la información relacionada
con los datos personales del empleado.
56
Índices Identificadores: Cedula Solicitante
Sub Almacén DB2.2.

Etiqueta: Datos empleado dependencia.
con los datos de ubicación en el organigrama de la empresa de los empleados.
Índices Identificadores: ID empleado
Sub Almacén DB2.3.

Etiqueta: Datos Solicitud de vacaciones.
con los datos de las solicitudes de vacaciones de los empleados.
Índices Identificadores: ID de solicitud de vacaciones
Sub Almacén DB2.4.

Etiqueta: Datos Vacaciones.
con las vacaciones disfrutadas por los empleados.
Índices Identificadores: ID vacación
Sub Almacén DB2.5.

Etiqueta: Datos de solicitud permiso.
con los datos de solicitud permiso de los empleados.
Índices Identificadores: ID solicitud permiso
Sub Almacén DB2.6.

Etiqueta: Datos permiso.
con los datos de los permisos otorgados a los empleado.
Índices Identificadores: ID permiso.
57
UNIDAD 5:
DISEÑO DE ENTRADAS, SALIDAS E INTERFACES.
DISEÑAR ENTRADAS Y SALIDAS INFORMATICAS.
Para cumplir con esta fase del diseño del sistema se usara como base los requerimientos
de entradas y salidas definidas durante el análisis del sistema y los DFD de unidades de
diseño realizados durante el diseño del sistema (presente informe).
DISEÑAR LAS ENTRADAS.
Recordemos que las entradas de datos en el proceso de traducción del documento fuente
a un formato comprensible por la máquina. Implica la construcción de documentos
fuentes, pantallas, archivos de datos, etc. Se trabajara de acuerdo a los subsistemas
definidos en la creación de los DFD de unidades de diseño. Veamos esto a continuación:
ESPECIFICACIONES DE LAS ENTRADAS.

De una vez haremos la implantación al diccionario del proyecto.
PROCESO PE 1 (SUB SISTEMA EMPLEADOS).
A) ENTRADAS DE DATOS: PARA EL PROCESO DE REGISTRO EMPLEADO

REGISTRADO
FLUJO DE DATOS_ENTRADA
NOMBRE: EMPLEADO REGISTRADO

ROTULO: EMPLEADO REGISTRADO
DESCRIPCION:
DOCUMENTO FUENTE: FORMATO REGISTRO DE EMPLEADO. FORMULARIO FINDR
001.
DOCUMENTO DE TIPO: CICLICO.
METODO ENTRADA: ON-LINE.
SOPORTE ENTRADA: PANTALLA.
TIEMPO: DE 8:00 AM A 12:00 M Y 2:00 PM A 5:00 PM (DIAS LABORALES).
VOLUMEN MEDIO: 10 AL DIA VOLUMEN PICO: 15 AL DIA.
CONTROLES: LA ENTRADA USARA COMO SOPORTE UN DOCUMENTO FUENTE
(FORMULARIO FINDR001) DE TIPO CICLICO. SERA ENTREGADO POR EL
DEPARTAMENTO DE PERSONAL. EL EMPLEADO LO DEVOLVERA LLENO. EL
ANALISTA LO REVISA Y LO PROCESA.
B) ATRIBUTOS QUE CONFORMAN ENTRADA DATOS.
ENTRADAS en el diccionario de los atributos que definen el contenido de EMPLEADO NO

REGISTRADO.
58
INFORME DE ATRIBUTOS CONTENIDOS EN EL REGISTRO DE
EMPLEADO REGISTRADO
CARACT. A CARACT. A IMAGEN
NOMBRE DE OC
TIPO LA LA DE INTERVALO DE VALORES
ATRIBUTO C
IZQUIERDA DERECHA ENTRADA
DEBE SER UNICO PARA UN
CI EMPLEADO C 10 0 999999 EMPLEADO. VALOR 000001 A
999999
OBLIGATORIO EL EMPLEADO
NOMBRE DE SER ADMITIDO EN EL
EMPLEADO C 50 0 X(50)
INDR
APELLIDO
EMPLEADO C 50 0 X(50) DE SER ADMITIDO EN EL
INDR
DIRECCION
PERTENECE C 25 0 X(25)
DIVISION
DEPARTAMEN
TO C 25 0 X(25)
PERTENECE
CARGO C 25 0 X(25)
FECHA
INGRESO AL C 8 0 DD/MM/AA
INSTITUTO
CODIGO DE R=DISCO,C=CASSETTE,D=DIS
SOPORTE C 1 0 X CO COMPACTO, 8=PISTA 8
PROCESO PE 2 (SUB SISTEMA SOLICITUD VACACIONES).
A) ENTRADAS DE DATOS: PARA EL PROCESO DE REGISTRO SOLICITUD

VACACIONES
NOMBRE: SOLICITUD VACACIONES

ROTULO: SOLICITUD VACACIONES
DESCRIPCION:
DOCUMENTO FUENTE: FORMATO SOLICITUD VACACIONES. FORMULARIO FINDR
002.
DEPARTAMENTO DE PERSONAL. EL EMPLEADO LO DEVOLVERA LLENO. EL
ANALISTA LO REVISA Y LO PROCESA.

ENTRADAS en el diccionario de los atributos que definen el contenido de SOLICITUD
VACACIONES.
59
SOLICITUD VACACIONES
CARACT. A CARACT. IMAGEN
NOMBRE DE TIP OC
LA A LA DE INTERVALO DE VALORES
ATRIBUTO O C
NUMERO DE
VACACIONES. DEBE SER UNICO PARA UN
(Atributo C 4 0 9999 EMPLEADO. VALOR 0001 A
identificador) 9999
DIRECCIÓN QUE
ENVÍA EL C 25 0 X(25)
FORMULARIO
CEDULA DE DEBE SER UNICO PARA UN
IDENTIDAD C 10 0 999999 EMPLEADO. VALOR 000001 A
999999
NOMBRE OBLIGATORIO EL EMPLEADO
SOLICITANTE INDR
APELLIDO OBLIGATORIO EL EMPLEADO
SOLICITANTE INDR
CARGO DEL
FECHA DE
INGRESO AL C DD/MM/AA
INSTITUTO
FECHA DE INICIO
DEL PERIODO C 25 0 DD/MM/AA
VACACIONAL
PERIODO A
DISFRUTAR C 2 0 50 0 A 50 DIAS
PERIODO
PENDIENTE QUE
NO HA C 2 0 99 0 A 50 DIAS
DISFRUTADO
FECHA DE
REINCORPORACIÓ C 25 0 X(25)
N AL TRABAJO
FECHA DE
CULMINACIÓN DEL
PERIODO C DD/MM/AA
VACACIONAL
OBSERVACIONES C 25 0 X(25)
NOMBRE Y
APELLIDO DEL
DIRECTOR DE C 25 0 X(25)
RECURSOS
HUMANOS
FECHA CUANDO
FIRMO EL
DIRECTOR RRHH C 8 0 DD/MM/AA
PROCESO PE 3 (SUB SISTEMA SOLICITUD PERMISOS).
A) ENTRADAS DE DATOS: PARA EL PROCESO DE REGISTRO SOLICITUD

PERMISOS.
60
NOMBRE: SOLICITUD PERMISOS
ROTULO: SOLICITUD PERMISOS
DESCRIPCION:
DOCUMENTO FUENTE: FORMATO SOLICITUD PERMISOS. FORMULARIO FINDR
003.
DEPARTAMENTO DE PERSONAL. EL EMPLEADO LO DEVOLVERA LLENO. EL JEFE
INMEDIATO LO REVISA Y LO PROCESA.

ENTRADAS en el diccionario de los atributos que definen el contenido de SOLICITUD
VACACIONES.

SOLICITUD PERMISOS
CARACT. A CARACT. IMAGEN
NOMBRE DE TIP OC
LA A LA DE INTERVALO DE VALORES
ATRIBUTO O C
NUMERO DE
PERMISO. (Atributo
identificador) C 4 0 9999 EMPLEADO. VALOR 0001 A
9999
FECHA DE
PREPARACIÓN DEL C 8 0 DD/MM/AA
FORMULARIO
DIVISIÓN O
DEPARTAMENTO
AL QUE C 25 0 X(25)
PERTENECE
CEDULA DE DEBE SER UNICO PARA UN
IDENTIDAD C 10 0 999999 EMPLEADO. VALOR 000001 A
999999
NOMBRE OBLIGATORIO EL EMPLEADO
SOLICITANTE INDR
APELLIDO OBLIGATORIO EL EMPLEADO
SOLICITANTE INDR
CARGO DEL
FECHA DE INICIO C 8 0 DD/MM/AA
FECHA DE
CULMINACIÓN C 8 0 DD/MM/AA
DURACIÓN DEL
PERMISO C 2 0 99 0 A 50 DIAS
(HORAS/DÍAS
BREVE
DESCRIPCIÓN DEL
MOTIVO DEL C 200 0 X(200)
PERMISO
NOMBRE Y C 50 0 X(50)
61
APELLIDOS
DEL(OS) JEFE(S);
FECHA JEFE C 25 0 DD/MM/AA

FIRMA
REALIZAR PROTOTIPO DE DOCUMENTOS FUENTES.
A continuación vemos el modelo del documento fuente para registrar los datos y solicitud
al SISTEMA INDR.
EL DOCUMENTO FUENTE, QUE ELEGIMOS ES EL DE ZONA DE ENTRADA.
ZONA DE IDENTIFICACION NUERO DE SECUENCIA, FECHA.
NOMBRE DE LA EMPRESA Y DE
FORMULARIO
NUMERO DE FORMULARIO OFICIAL
FECHA DE ULTIMA REVISION
ZONA DE INSTRUCCIONES
ZONA DEL CUERPO DEL DOCUMENTO

(DETALLES DE LA TRANSACCIONES)
ZONA DE TOTALES
ZONA DE INSTRUCCIONES
62
No: 00102510
FECHA: sábado, 05 de
FORMULARIO PARA EL REGISTRO DE septiembre de 2020
EMPLEADO
FORMULARIO: FINDR 001
RELLENAR TODAS LAS CASILLAS

NOMBRES: Escriba su nombre.
APELLIDOS Escriba aquí su apellido.
SOLICITUD REGISTRO DE EMPLEADO
CEDULA DE IDENTIDAD:
Escriba su número de cedula
identidad.
CARGO DEL EMPLEADO:
director jefe division jefe departamento empleado
DIRECCIÓN A LA QUE PERTENECE:
direccion personal direccion administrativa direccion finanzas

direccion regional
DIVISION A LA QUE PERTENECE:
Division Administracion Division Desarrollo Division servicio Medico
DEPARTAMENTO A QUE PERTENECE:
Personal Nomina Higiene adiestramiento

NOMBRE Y APELLIDO DEL JEFE DE PERSONAL
FECHA CUANDO FIRMO EL JEFE DE PERSONAL:

PRESIONE F1 AYUDA F2 ENVIAR F3 VOLVER A MENU
63
No: 00102511
FORMULARIO PARA LA SOLICITUD DE septiembre de 2020
VACACIONES

SOLICITUD solicitud de vacaciones
identidad.
CARGO DEL EMPLEADO:
FECHA DE INGRESO AL INSTITUTO: 2-sep.-20

FECHA DE INICIO DEL PERIODOVACACIONAL: 03/09/20
PERIODO A DISFRUTAR (EJEMPLO: 2019-2020 Escriba el periodo a disfrutar
PERIODO PENDIENTE QUE NO HA DISFRUTÓ (EJEMPLO 2018-2019):
FECHA DE CULMINACIÓN DEL PERIODO VACACIONAL:
FECHA DE REINCORPORACIÓN AL TRABAJO:
DIRECCIÓN QUE ENVÍA EL FORMULARIO:
direccion personal direccion administrativa direccion finanzas

direccion regional
OBSERVACIONES:
NOMBRE Y APELLIDO DEL DIRECTOR DE RECURSOS HUMANOS:
FECHA CUANDO FIRMO EL DIRECTOR:
64
FORMULARIO FUENTE FINDR 00 3
No: 00102512
FORMULARIO PARA LA SOLICITUD DE septiembre de 2020
PERMISOS

SOLICITUD solicitud permisos
identidad.
CARGO DEL EMPLEADO:
FECHA DE INGRESO AL INSTITUTO: 2-sep.-20

FECHA DE INICIO DEL PERIODO PERMISO: 03/09/20
PERIODO A DISFRUTAR (EJEMPLO: 2019-2020 Escriba el periodo a disfrutar
FECHA DE CULMINACIÓN DEL PERIODO PERMISO:
FECHA DE REINCORPORACIÓN AL TRABAJO:
OBSERVACIONES:
NOMBRE Y APELLIDO DEL JEFE INMEDIATO:
FECHA CUANDO FIRMO EL JEFE INMEDIAO:
65
DISEÑO DE PANTALLAS DE ENTRADA ORIENTADAS A USUARIOS.
Para el diseño de las pantallas que servirán como interface para la entrada de información
al INDR, se usara la técnica de diseño de salidas gráficas las cuales son de uso extendido
y muy popular en los sistemas de información para el ámbito administrativo y empresarial.
El método de entrada es ON-LINE. Veamos a continuación los prototipos de pantallas de
entradas orientadas hacia los usuarios. Posteriormente, en las especificaciones a los
programadores se explicara las funciones y comandos de las pantallas. Estas figuras
serán incluidas en el diccionario del proyecto como modelos de pantallas orientadas a
usuarios (continuación de punto C del diccionario del proyecto).
ESPECIFICACION DE PANTALLAS ENTRADA (ORIENTADO AL

PROGRAMADOR).
Cabe señalar que al usar la técnica de diseño de salidas gráficas para la definición de las
pantallas, los modelos de pantalla establecidos, se mantendrán igual como estructuras
orientadas a los programadores. En esta sección ampliaremos, estableciendo las
especificaciones necesarias para el uso de los programadores (esta información
corresponde a la que llevara el diccionario del proyecto (continuación punto C del
diccionario del proyecto).
Registro de Datos EMPLEADOS.
Modelo de pantalla entrada.

La FIG. ANTERIOR especifica el modelo de pantalla de entrada.
Especificaciones de atributos de pantalla:
✓ Para introducir datos a registrar se usaran cuadros de textos.
✓ Para introducir datos con opciones de selección se usaran cuadros de texto
Con opciones de selección (S o N).
✓ El numero solicitud será generado automáticamente al introducir cedula
Solicitante y fecha solicitud (será colocado automáticamente la unión de
cédula Y fecha solicitud). Este cuadro de texto no permitirá ser usado por el
usuario (es Registrado solo automáticamente).
✓ Para ejecutar las acciones de registrar, registrar más, salir e imprimir se
usan Botones o comandos de funciones. Estos botones ejecutaran
secuencias de Instrucciones para cumplir con lo siguiente:
• Registrar; ordena cargar toda la información copiada en la pantalla hacia
la Base de datos DB2. Crea los siguientes mensajes consecutivos:
➢ Serán registrados los datos, ¿está seguro de querer registrarlos?
➢ Si pulsa cancelar regresa a pantalla inicial con datos copiados pero
sin registrar.
➢ Si pulsa aceptar, se hace efectivo el registro de datos en DB2 y
coloca el mensaje REGISTRO COMPLETADO SIN PROBLEMAS.
• Registrar Más; esta función fue colocada como una opción para hacer
procesamiento de registro en lote remoto, aunque el proceso está definido
para hacerse en línea ON-LINE. Al pulsar registrar más, se colocan todos
66
los campos o cuadros de texto en blanco y queda listo para otro de
registro. Esto permite acumular varias solicitudes y ser cargadas en otra
ocasión por lotes (caso falla eléctrica o de sistema que no permita realizar
en línea con el cliente el registro de la información. Este comando es de
uso muy eventual).
• Salir; salir de pantalla e ir a menú˙ principal del INDR.
• Imprimir; permite imprimir pantalla una vez hecho efectivo un proceso de
registro. Esta impresión puede usarse como soporte de la transacción y
anexarse a la copia del formulario 001 para almacenar en archivo DB1. Es
una opción de gestión que no está reflejada en las unidades de diseños
manuales o automatizados, pero que consideramos importante reflejar
como opción.
Especificaciones mensajes de error.

Mensajes de error asociado a pantalla entrada. Registro datos Empleados.
➢ Caso 1: mensaje error: “ERROR: EDAD NO DEBE SER MAYOR A 120 O IGUAL
A 0”.
➢ Caso 2: mensaje error: “ERROR: EDO. CIVIL DEL SOLICITANTE DEBE TENER
ALGUNO DE LOS SIGUIENTES VALORES: S, C, D, V, CC”
➢ Caso 3: mensaje error: “ERROR: SEXO DEBE SER M O F”.
➢ Caso 4: mensaje error: “ERROR: FORMATO FECHA INCORRECTO, USE:
DD/MM/AA”.
➢ Caso 5: error mensaje: “ERROR: COMPLETE TODOS LOS CAMPOS DE
ENTRADA”.
DISEÑAR LAS SALIDAS.

ESPECIFICACIONES DE LAS SALIDAS.
Para este punto se usara como apoyo los requisitos de salidas inicialmente expuestos en
el análisis y diseño del sistema, más las especificaciones precisas establecidas durante la
elaboración de las unidades de diseño (en presente informe). De acuerdo a esto, veamos
las especificaciones de salidas, estableciendo de una vez las entradas al diccionario del
proyecto.
ESPECIFICACIONES DE SALIDAS.
PROCESO PE_1 SUBSISTEMA EMPLEADOS
SALIDA DE DATOS PARA CONSULTA DE DATOS GENERALES DE EMPLEADOS
FLUJO DE DATOS_SALIDA
NOMBRE: CONSULTA DATOS EMPLEADO.
ROTULO: CONSULTA DATOS EMPLEADO.
67
VALOR DE DURACION: A PETICION USUARIO.
TIPO DE DURACION: A PETICION DE USUARIO.
DESCRIPCION
DESCRIPCION: PANTALLA DE SALIDA PARA ACCEDER A INFORMACION DE BASE

DE DATOS RELACIONADA CON DATOS GENERALES DEL SOLICITANTE SOPORTE:
PANTALLA DE ESTACION DE TRABAJO
TIPO DE SALIDA: INTERNA
FRECUENCIA DE PREPARACION: A PETICION DEL USUARIO ENTRE 08:00 A.M -
12:00 M Y 02:00 P.M -5:00 P.M
CARACTERISTICAS SALIDA: DISEÑO INTERFACE EN PANTALLA MEDIANTE
USODE TECNICA DE SALIDAS GRAFICAS DISTRIBUIDAS EN AREA DE PANTALLA
SEGUN BOCETO PREESTABLECIDO.
ATRIBUTOS DE SALIDA PARA CONSULTA DE DATOS GENERALES

EMPLEADOS.
EMPLEADO REGISTRADO
CARACT. A CARACT. A IMAGEN
NOMBRE DE OC
TIPO LA LA DE INTERVALO DE VALORES
ATRIBUTO C
CI EMPLEADO C 10 0 999999 EMPLEADO. VALOR 000001 A
999999
NOMBRE DE SER ADMITIDO EN EL
INDR
APELLIDO
INDR
DIRECCION
DIVISION
DEPARTAMEN
TO C 25 0 X(25)
PERTENECE
CARGO C 25 0 X(25)
FECHA
INGRESO AL C 8 0 DD/MM/AA
INSTITUTO
PROCESO PE2 SUBSISTEMA SOLICITUD VACACIONES.

PROCESO PE3 SUBSISTEMA SOLICITUD PERMISOS.
PROTOTIPO DE SALIDA ORIENTADA A USUARIOS.

Para el diseño de las pantallas de salidas se usara la técnica de uso de salidas gráficas,
generadas a partir de los programas de aplicación de cuarta generación y de las
68
facilidades dadas por el manejador de bases de datos utilizado. En las figuras siguientes
se muestran los modelos o bocetos de pantallas e impresos (caso reportes) con la
apariencia definitiva que será vista por los usuarios el sistema. Estas figuras serán
incluidas en el diccionario del proyecto.
ESPECIFICACIONES DE SALIDAS ORIENTADAS A PROGRAMADORES.

Debido a que se usa la técnica de diseño de salidas gráficas o visuales, los modelos de
pantallas establecidos para los usuarios se mantendrán como gráficos de estructuras de
pantallas orientados a los programadores (la técnica de diseños visuales permite esto). A
continuación son documentadas las herramientas para diseños visuales necesarias por
pantalla o reporte. Esta información corresponde a la que llevara el diccionario del
proyecto (continuación del diccionario del proyecto).
PANTALLA 004: CONSULTA DATOS EMPLEADOS.
ESPECIFICACIONES DE ATRIBUTOS DE PANTALLA.
✓ Textos fijos para descripciones serán realizados mediante ETIQUETAS o

CUADROS DE TEXTOS con escritos respectivos.
✓ Campos en blanco que recibirán información requerida de DATOS EMPLEADOS,
serán creadas con CUADROS DE TEXTOS.
✓ Campos en blanco que recibirán información requerida de NOMBRES, CEDULAS
serán creadas mediante lista de textos.
✓ Funciones de IMPRIMIR, MAS CONSULTA, MENU PRINCIPAL, SALIR serán
creados con COMANDOS O BOTONES.
DISEÑAR INTERFAZ DE USUARIOS.

Estas interfaces de usuarios corresponden a las pantallas que tendrán como función
comunicar las diferentes entradas y salidas que manipulan la información de la base de
datos. Estas interfaces permitirán navegar o ubicarse en las funciones requeridas por los
usuarios del sistema. Para documentarlas se utilizarán las herramientas de Elaboración
de Diagramas de Transición de Estado y Bocetos de Pantallas Orientados a
usuarios
DIAGRAMAS DE TRANSICION DE ESTADOS.
Las siguientes figuras, muestran los diagramas de transición de estados los cuales
permitirán documentar la interfaz de usuarios necesarios para gestionar los despliegues
de las diferentes pantallas de entrada - salida y los reportes del sistema.
MODELOS DE PANTALLAS PARA INTERFACES ORIENTADOS A USUARIOS.
Las siguientes figuras, muestran los bocetos de pantallas de interfaces usados para el
acceso a los despliegues de pantallas de entrada-salida y reportes. Como se puede
apreciar corresponden a pantallas en las cuales hay un conjunto de botones o comando el
cual el usuario podrá seleccionar (pulsar) para ejecutar la aplicación respectiva de la
función seleccionada. Son pantallas tipos menú y submenú para acceder a las funciones
deseadas. Al igual que para las pantallas de entrada y salidas, estas también serán
69
diseñadas usando la técnica de salidas gráficas y fundamentalmente se usan botones o
comandos para seleccionar a las funciones.
70
71
UNIDAD 6:
DISEÑO DE LOS PROGRAMAS.

Para el diseño del programa de aplicación del sistema INDR se usara la metodología de
diseño modular. Esta técnica consiste en definir una estructura de alto nivel para los
procesos de las unidades de diseño, identificar los centros de transacciones y dividirlos en
sub módulos. Cada módulo o sub módulo será desglosado en las tres funciones básicas:
INICIAR, PROCESO y TERMINAR.
Recordamos que las unidades de diseño sobre las cuales se aplicara esta metodología
son:
SUBSISTEMA EMPLEADOS
SUBSISTEMA SOLICITUD VACACIONES
SUBSISTEMA SOLICITUD PERMISOS
Para representar estos módulos y sub módulos usaremos la técnica de Gráficos de

estructuras. Veamos esto a continuación teniendo siempre como referencia las unidades
de diseño automatizadas definidas sobre los tres subsistemas.
6.1) REPRESENTACION MODULAR DEL PROGRAMA DE APLICACION. De una vez

será realizada la actualización del diccionario del proyecto (punto F: ESPECIFICACION
DE PROGRAMAS DE APLICACION).
A) SUBSISTEMA EMPLEADOS (MODULO FUNDAMENTAL).
fig. 1 MODULO FUNDAMENTAL
72
B) SUBSISTEMA EMPLEADOS (SUBMODULOS ASOCIADOS).
fig. 2 MODULO ASOCIADOS
fig. 3 MODULOS ASOCIADOS
73
C) SUBSISTEMA SOLICITUD VACACIONES (MODULO FUNDAMENTAL).

74
D) SUBSISTEMA SOLICITUD VACACIONES (SUBMODULOS ASOCIADOS).
fig. 6 MODULO ASOCIADOS
75
fig. 9 MODULO ASOCIADO
76
E) SUBSISTEMA SOLICITUD PERMISOS (MODULO FUNDAMENTAL).
F) SUBSISTEMA SOLICITUD PERMISOS (SUBMODULOS ASOCIADOS).

77
78
79
6. DOCUMENTACION DE LOS MODULOS PRIMORDIALES.
La documentación de los módulos de programación está referida a especificar en el

diccionario del proyecto las entradas, procesos y salidas de los módulos de programación.
Para el caso de las entradas y salidas vamos a hacer solo referencia de ellas sin abundar
demasiado ya que estos elementos fueron suficientemente documentados en las
secciones anteriores de este informe. En cuanto a los procesos, estos serán
especificados usando la técnica de lenguaje corriente estructurado. Veamos esto a
continuación.
ESPECIFICACION DE ENTRADAS. De una vez será actualizado el diccionario del

proyecto (continuación punto F del diccionario del proyecto).
Las especificaciones serán realizadas referidas a los módulos de programación

primordiales.
A) SUBSISTEMA EMPLEADO.
1) SUBMODULO REGISTRO DE EMPLEADO.
* DOCUMENTOS FUENTES DE ENTRADAS.
FORMULARIO DE REGISTRO DE EMPLEADO (formulario FINDR001). Con este

formulario y en presencia del solicitante se efectúa el registro en línea. Por decisión del
departamento de personal, este formulario pudiera ser usado como soporte para realizar
entrada de datos por lotes, pero este es de ocurrencia muy eventual. De modo que, este
formulario puede usarse para el registro tanto en línea como por lotes.
* BASE DE DATOS
La base de datos DB1 y DB2 será accesada para registro y validación. Los registros son:
CEDULA IDENTIDAD, NOMBRE Y APELLIDO, FECHA INGRESO INSTITUTO, ID
EMPLEADO, DIRECCION PERTENECE, DIVISION PERTENECE, DEPARTAMENTO
PERTENECE, CARGO.
2) SUBMODULO ACTUALIZACION DATOS.
* DOCUMENTOS FUENTES DE ENTRADA.
FORMULARIO DE REGISTRO EMPLEADO (formulario FINDR001). Con este formulario

y en presencia del solicitante se efectúa la actualización en línea. Por decisión del
departamento de personal, este formulario pudiera ser usado como soporte para realizar
entrada de datos por lotes, pero este es de ocurrencia muy eventual. De modo que, este
formulario puede usarse para la actualización tanto en línea como por lotes.
* BASE DE DATOS.
La base de datos DB1 y DB2 será accesada para registro y validación. Los registros son:
CEDULA IDENTIDAD, NOMBRE Y APELLIDO, FECHA INGRESO INSTITUTO, ID
EMPLEADO, DIRECCION PERTENECE, DIVISION PERTENECE, DEPARTAMENTO
PERTENECE, CARGO.
B) SUBSISTEMA SOLICITUD DE VACACIONES.
80
1) SUBMODULO REGISTRO DE SOLICITUD.
FORMULARIO DE SOLICITUD VACACIONES (formulario FINDR002). Con este

formulario y en presencia del solicitante se efectúa el REGISTRO en línea. Por decisión
del DEPARTAMENTO DE PERSONAL, este formulario pudiera ser usado como soporte
para realizar entrada de datos por lotes, pero este es de ocurrencia muy eventual. De
modo que, este formulario puede usarse para el registro tanto en línea como por lotes.
* BASE DE DATOS.
La base de datos DB3 Y DB4 serán accesada para registro y validación. Los registros
son: NUMERO DE VACACIONES. (Atributo identificador),FECHA DE PREPARACIÓN
DEL FORMULARIO; DIRECCIÓN QUE ENVÍA EL FORMULARIO; APELLIDOS Y
NOMBRES DEL EMPLEADO QUE DISFRUTARA EL PERIODO VACACIONAL;
CEDULA DE IDENTIDAD; CARGO DEL EMPLEADO; 0PERIODO A DISFRUTAR ;
PERIODO PENDIENTE QUE NO LA DISFRUTÓ; FECHA DE INGRESO AL INSTITUTO;
FECHA DE INICIO DEL PERIODO VACACIONAL; FECHA DE CULMINACIÓN DEL
PERIODO VACACIONAL; FECHA DE REINCORPORACIÓN AL TRABAJO;
OBSERVACIONES; NOMBRE Y APELLIDO DEL DIRECTOR DE RECURSOS
HUMANOS; FECHA DE CUANDO FIRMO EL DIRECTOR.
2) SUBMODULO ACTUALIZACION DATOS Y SOLICITUD
FORMULARIO DE SOLICITUD DE VACACIONES (formulario FINDR002): con este

formulario y en presencia del solicitante se efectúa la ACTUALIZACION en línea. Por
decisión del departamento de personal, este formulario pudiera ser usado como soporte
para realizar entrada de datos por lotes, este formulario puede usarse para la
actualización tanto en línea como por lotes.
* BASE DE DATOS.
La base de datos DB3 y DB4 serán accesada para actualización y validación. Los
registros son: NUMERO DE VACACIONES. (Atributo identificador),FECHA DE
PREPARACIÓN DEL FORMULARIO; DIRECCIÓN QUE ENVÍA EL FORMULARIO;
APELLIDOS Y NOMBRES DEL EMPLEADO QUE DISFRUTARA EL PERIODO
VACACIONAL; CEDULA DE IDENTIDAD; CARGO DEL EMPLEADO; 0PERIODO A
DISFRUTAR ; PERIODO PENDIENTE QUE NO LA DISFRUTÓ; FECHA DE INGRESO
AL INSTITUTO; FECHA DE INICIO DEL PERIODO VACACIONAL; FECHA DE
CULMINACIÓN DEL PERIODO VACACIONAL; FECHA DE REINCORPORACIÓN AL
TRABAJO; OBSERVACIONES; NOMBRE Y APELLIDO DEL DIRECTOR DE
RECURSOS HUMANOS; FECHA DE CUANDO FIRMO EL DIRECTOR.
3) SUBMODULO ACTUALIZACION STATUS DE SOLICITUD.
* BASE DE DATOS.
.Este proceso de actualización ofrece la posibilidad de procesamientos por lotes ya que

dispone de la facilidad con la función ACTUALIZAR MAS. En la práctica estas
81
actualizaciones se realizan una a la vez por orden de ocurrencia o llegada al funcionario
respectivo, pero no se excluye la posibilidad de efectuarlas por lote.
La base de datos DB3 será accesada para actualización y validación. Los registros son:
NUMERO DE CEDULA, ID DE SOLICITUD VACACION. FECHA SOLICITUD,
DIRECCION QUE ENVIA LA SOLICITUD, PERIODO A DISFRUTAR, NOMBRE Y
APELLIDO DEL DIRECTOR RRHH, FECHA FIRMA DEL DIRECTOR RRHH
C) SUBSISTEMA SOLICITUD DE PERMISOS.
1) SUBMODULO REGISTRO DE SOLICITUD.
FORMULARIO DE SOLICITUD PERMISOS (formulario FINDR003). Con este formulario y

en presencia del solicitante se efectúa el REGISTRO en línea. Por decisión del
DEPARTAMENTO DE PERSONAL, este formulario pudiera ser usado como soporte para
realizar entrada de datos por lotes, pero este es de ocurrencia muy eventual. De modo
que, este formulario puede usarse para el registro tanto en línea como por lotes.
* BASE DE DATOS.
La base de datos DB5 Y DB6 serán accesada para registro y validación. Los registros
son: NUMERO DE PERMISO (atributo identificador), FECHA DE PREPARACIÓN DEL
FORMULARIO; DIVISIÓN O DEPARTAMENTO AL QUE PERTENECE; APELLIDOS Y
NOMBRES; CEDULA DE IDENTIDAD; CARGO; DURACIÓN DEL PERMISO
(HORAS/DÍAS); FECHA DE INICIO; FECHA DE CULMINACIÓN; BREVE
DESCRIPCIÓN DELMOTIVODELPERMISO; NOMBRE Y APELLIDOS DEL(OS) JEFE(S)
2) SUBMODULO ACTUALIZACION DATOS Y SOLICITUD
FORMULARIO DE SOLICITUD DE PERMISOS (formulario FINDR003): con este

formulario y en presencia del solicitante se efectúa la ACTUALIZACION en línea. Por
decisión del departamento de personal, este formulario pudiera ser usado como soporte
para realizar entrada de datos por lotes, este formulario puede usarse para la
actualización tanto en línea como por lotes.
* BASE DE DATOS.
La base de datos DB5 y DB6 será accesada para actualización y validación. Los registros
son: FECHA DE PREPARACIÓN DEL FORMULARIO; DIVISIÓN O DEPARTAMENTO AL
QUE PERTENECE; APELLIDOS Y NOMBRES; CEDULA DE IDENTIDAD; CARGO;
DURACIÓN DEL PERMISO (HORAS/DÍAS); FECHA DE INICIO; FECHA DE
CULMINACIÓN; BREVE DESCRIPCIÓN DEL MOTIVO DEL PERMISO; NOMBRE Y
APELLIDOSDEL(OS)JEFE(S).
82
3) SUBMODULO ACTUALIZACION STATUS DE SOLICITUD.
* BASE DE DATOS.
.Este proceso de actualización ofrece la posibilidad de procesamientos por lotes ya que

dispone de la facilidad con la función ACTUALIZAR MAS. En la práctica estas
actualizaciones se realizan una a la vez por orden de ocurrencia o llegada al funcionario
respectivo, pero no se excluye la posibilidad de efectuarlas por lote.
La base de datos DB5 será accesada para actualización y validación. Los registros son:
NUMERO DE CEDULA, ID DE SOLICITUD PERMISO. FECHA SOLICITUD, PERIODO A
DISFRUTAR, NOMBRE Y APELLIDO DEL JEFE INMEDIATO, FECHA FIRMA DEL JEFE
INMEDIATO.
ESPECIFICACION DE SALIDAS. De una vez será actualizado el diccionario del

proyecto (continuación punto F del diccionario del proyecto).
Veamos a continuación las especificaciones de las salidas referidas a los módulos de

programación primordiales.
A) SUBSISTEMA EMPLEADOS.
1) SUBMODULO CONSULTA DE DATOS GENERALES.
* BASE DE DATOS.
La base de datos DB1 Y DB2, serán accesada para consulta de datos generales. Los
registros son: CEDULA IDENTIDAD, NOMBRE Y APELLIDO, FECHA INGRESO
INSTITUTO, ID EMPLEADO, DIRECCION PERTENECE, DIVISION PERTENECE,
DEPARTAMENTO PERTENECE, CARGO.
B) SUBSISTEMA SOLICITUD DE VACACIONES.
1) SUBMODULO CONSULTA DE DATOS GENERALES
* BASE DE DATOS.
registros son: NUMERO DE VACACIONES. (Atributo identificador),FECHA DE
PREPARACIÓN DEL FORMULARIO; DIRECCIÓN QUE ENVÍA EL FORMULARIO;
APELLIDOS Y NOMBRES DEL EMPLEADO QUE DISFRUTARA EL PERIODO
VACACIONAL; CEDULA DE IDENTIDAD; CARGO DEL EMPLEADO; 0PERIODO A
DISFRUTAR ; PERIODO PENDIENTE QUE NO LA DISFRUTÓ; FECHA DE INGRESO
AL INSTITUTO; FECHA DE INICIO DEL PERIODO VACACIONAL; FECHA DE
CULMINACIÓN DEL PERIODO VACACIONAL; FECHA DE REINCORPORACIÓN AL
TRABAJO; OBSERVACIONES; NOMBRE Y APELLIDO DEL DIRECTOR DE
RECURSOS HUMANOS; FECHA DE CUANDO FIRMO EL DIRECTOR.
C) SUBSISTEMA SOLICITUD DE PERMISOS.
1) SUBMODULO CONSULTA DE DATOS GENERALES
* BASE DE DATOS.
83
registros son: FECHA DE PREPARACIÓN DEL FORMULARIO; DIVISIÓN O
DEPARTAMENTO AL QUE PERTENECE; APELLIDOS Y NOMBRES; CEDULA DE
IDENTIDAD; CARGO; DURACIÓN DEL PERMISO (HORAS/DÍAS); FECHA DE INICIO;
FECHA DE CULMINACIÓN; BREVE DESCRIPCIÓN DEL MOTIVO DEL PERMISO;
NOMBRE Y APELLIDOS DEL(OS) JEFE(S).
84

TP-336 PDF Desarrollo

Cargado por

Copyright:

Formatos disponibles

TP-336 PDF Desarrollo

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TP-336 PDF Desarrollo

Cargado por

Copyright:

Formatos disponibles

TRABAJO PRÁCTICO:

ASIGNATURA: Sistemas de Información II

FECHA DE ENTREGA AL ESTUDIANTE: A partir de la primera semana de

FECHA DE DEVOLUCIÓN: El informe correspondiente al trabajo práctico será

NOMBRE DEL ESTUDIANTE: LUIS BERRIO

CÉDULA DE IDENTIDAD: 7953091

TELÉFONO DEL ESTUDIANTE: 0416-6181511

DIRECCIÓN DEL CORREO ELECTRÓNICO: SUMIBER@GMAILCOM

CENTRO LOCAL: METROPOLITANO

El proyecto en culminación, es el diseño e implantación de un sistema de información

El informe consta de las siguientes unidades:

Unidad 1; Selección de una solución de sistemas de información:

En la cual se definen alternativas de diseños las cuales son sometidas a un análisis

Unidad 2: Análisis de datos:

Unidad 3: Análisis y diseño de procesos:

Continuando con el diseño del sistema, en esta unidad desarrollamos el análisis y

Unidad 4: Diseño de bases de datos:

Igualmente este punto es continuación de la fase de diseño e integración. Aquí se definen

Unidad 6: Diseño de programas:

Corresponde al inicio de la última fase de diseño del proyecto, en esta sección se

Unidad 7. Construcción de un sistema:

Como indica su descripción, serán creados definitivamente la base de datos y los

Unidad 8. Entrega de un sistema:

Como hemos señalado anteriormente, para el diseño e implantación seguiremos una

FASE SELECCION: Se utilizan las técnicas de matriz de soluciones candidatas para

FASE DE ADQUISICION: Durante esta fase la cual es de adquisición de la tecnología a

FASE DE DISEÑO E INTEGRACIÓN (Inicio): En esta sección se tratan primero los

Continuando con la fase de Diseño e Integración. Esta sección complementa el análisis

Para las pantallas de entrada se seguirá la siguiente metodología:

✓ Revisar los requisitos de entradas mediante el análisis de las unidades de diseño

Para las pantallas de salidas se seguirá la siguiente metodología:

✓ Revisar los requisitos de salidas mediante el análisis de las unidades de diseño de

Para las pantallas de salidas, de tipo interfaz de usuario, se seguirá la siguiente

✓ Usando la técnica de diagrama de transición de estados, serán representadas las

Finalización de fase de Diseño e Integración; diseño de programas, a continuación la

✓ Efectuar diseño modular de los programas por Subsistema, utilizando

Para construir la base de datos se procederá como sigue:

✓ Crear la estructura de base de datos relacional mediante la herramienta de

FASE DEFINIR PLAN DE CONVERSION DEL SISTEMA:

Finalización de fase de Implantación y con ello del proyecto.

SELECCIÓN DE UNA SOLUCIÓN DE SISTEMAS DE INFORMACIÓN.

En la unidad 1, estudiaremos las fases de selección y adquisición del diseño de sistemas.

Propuesta 1: Sistema de información automatizado basado, en lo relativo al componente

Ahora veamos la Fig. 1:

CARACTERISTICA PROPUESTA 1 PROPUESTA 2

MATRIZ DE SOLUCIONES CANDIDATAS PARA SISTEMA INDR.

CRITERIO VIABILIDAD PROPUESTA 1 PROPUESTA 2

LOS COSTOS DE DESARROLLO SE

SE PREVEE UNA DURACION ENTRE

FIG. 2 MATRIZ DE VIABILIDAD DE PROPUESTAS DE DISEÑOS PARA EL INDR

FIG. 3 RELACION DE GASTOS DEL SISTEMA INDR.

En las FIG. 4 Y 5, vemos detalles de la planificación del proyecto INDR mostrando la

La información presentada en las FIG. 4 Y 5 corresponden a la metodología ya usada en

A continuación la descripción completa de las tareas estipuladas:

Tarea B (Continuación Fase Diseño Sistema). Tomando como base el informe de

Tarea G (Culminación Fase Implantación). Esta es la última súbase de la fase de

CRITERIO DE VIABILIDAD PROPUESTA 1 PROPUESTA 2

Veamos la justificación de estos valores obtenidos.