Esquema para la Elaboracin de la Documentacin

del Trabajo de Titulacin Propuesta Tecnolgica

Manual de Diseo
CARATULA

INSTITUTO TECNOLOGICO SUPERIOR ALMIRANTE ILLINGWORTH

TRABAJO DE GRADUACIN TITULACIN PREVIO A LA OBTENCIN DEL

TTULO DE TCNOLOGO SUPERIOR EN INFORMTICA

TEMA
Descripcin de tema

Manual de DISEO

AUTOR
Apellidos y Nombres del Estudiante

DIRECTOR DEL TRABAJO DE GRADUACIONTITULACIN:

Apellidos y Nombres del Tutor asignado

Guayaquil, April de 2016

Elaborado por: Ing. Ernesto Robles

PORTADA INTERIOR
Debe contener los mismo parmetros establecidos en la caratula (La
portada interior debe ser considerada al momento de
presentar el empastado de su propuesta tecnolgica)

PRELIMINARES

AGRADECIMIENTOS
Redaccin en donde el autor dedica su trabajo de titulacin o
propuesta tecnolgica a una persona; o expresa su gratitud a una
deidad, familiar, institucin o persona, etc.
RESUMEN
Ser una sntesis que expone los elementos de la propuesta, para una
audiencia amplia consistente en lectores, tanto familiarizados como
los que no, con el tema.
En consecuencia, el resumen es una presentacin abreviada y precisa
del contenido de la tesis. Debe bastarse por s mismo, con la finalidad
que el lector pueda saber el tema tratado, ha de ser lo ms conciso
posible, comprensible, sencillo, exacto e informativo respetando el
contenido de la tesis (debe contener un mximo de 300 palabras).
Bsicamente como estructura tendr que llevar lo siguiente:

El Objetivo de la propuesta.- Cual sera el objetivo principal que

tendra su propuesta tecnolgica y la finalidad de realizarla.
o Cul es el problema?
o Qu funcin va a cumplir el desarrollo del software?
Mtodos que utilizara la propuesta.- Hace referencia a los
procedimientos seguidos y a las tcnicas utilizadas, debiendo
describrselas slo en la medida que ayuden a la explicacin del
desarrollo de la propuesta desarrollada.
o Cmo se va a desarrollar la propuesta?
o Cules sern las herramientas, plataforma y aplicaciones
que va a utilizar?
Resultados esperados.- Es la identificacin precisa del alcance
que se desea obtener con el desarrollo de su trabajo de
investigacin o propuesta tecnolgica.
Recomendaciones o Conclusiones.- Son deducciones que
Elaborado por: Ing. Ernesto Robles

justifican los resultados obtenidos, en tanto que son

consecuencia de ellos. Da contestacin al objetivo y a los
mtodos utilizados, las recomendaciones pueden exponerse
conjuntamente con las conclusiones.
CERTIFICACION DEL TUTOR
La Certificacin del Tutor o Director de Trabajo de Titulacin, es un
documento obligatorio que el tutor deber firmar, dando fe que el
trabajo ha sido debidamente revisado y est en condiciones de ser
entregado para que se siga lo dispuesto por el Instituto, en cuanto a
la sustentacin y defensa del mismo.
CERTIFICACION DE LA EMPRESA
Se debe adjuntar un certificado que indique que su propuesta de
trabajo, va a ser implementado u orientado dentro de un lugar
especfico (Empresa u otra entidad que lo requiera)
AUTORIA NOTARIADA
Es un certificado notarizado, que permite indicar que todo, criterio,
ideas expuestas en el documento que est desarrollando son de
propiedad del autor. (La autora debe estar de forma obligatoria
al momento de presentar el empastado)
INDICE
Inicia con las pginas preliminares enumeradas con nmeros romanos
en minsculas, luego se empieza desde el Captulo I que corresponde
a las Generalidades en el orden que corresponda su numeracin
empezando desde el Uno(las descripcin de cada captulo no va
numerado). Puede contener:
ndice de contenidos
ndice de tablas.-Usa los mismos ttulos que aparecen en el
texto, de las tablas.
ndice de grficos.- Usa las mismas leyendas que aparecen en
el texto.
ndice de anexos.- Usa los mismos ttulos que aparecen en los
apndices o anexos (En caso de requerirlo).

Elaborado por: Ing. Ernesto Robles

CAPITULO I
1. Generalidades
1.1.
Planteamiento del Problema.- En esta parte se podrn
incluir los beneficiarios y la localizacin donde se llevar a cabo
el proyecto. Previamente, se hace necesario realizar un
diagnstico de la situacin actual en la sitio (empresa u
organizacin) donde se piensa realizar el proyecto; para ello, se
debe entender que el problema o la situacin no aparecen de
manera aislada; por el contrario, siempre guardar una relacin
con las circunstancias colindantes que, en la mayora de los
casos, lo determinan.
Existen algunas recomendaciones para plantear el problema,
entre ellos, estn los siguientes:
a) Describir la realidad objeto de estudio partiendo de lo
general a lo especfico
b) Explicar la situacin actual en la que se encuentra el
problema que est planteando
c) Indicar los elementos o situaciones relacionadas con el
problema; y
d) Destacar la relevancia del problema, entre otros.
Tambin es aconsejable dar respuesta a las siguientes
interrogantes: Cules son los elementos del problema: datos,
situaciones y conceptos relacionados con el mismo? Cules
son los hechos anteriores que guardan relacin? Cul es la
situacin actual? Cul es la relevancia? De esta forma, se har
referencia a la comunidad donde se realizar el servicio y su
ubicacin: entidad, regin o institucin, esto es, el lugar exacto
donde se ejecutar el proyecto: comunidad, parroquia,
municipio, estado; de la misma manera, se podr especificar de
qu manera la comunidad puede integrarse durante la
ejecucin del proyecto y cul ser su papel durante el desarrollo
del mismo.
1.2.
Justificacin.- En esta seccin es necesario justificar las
razones que motivan la realizacin de la propuesta tecnolgica.
Por otra parte, es necesario explicar por qu es conveniente
llevarlo a cabo y cules son los beneficios que se derivaran
hacia su implementacin. En este tpico, conviene tomar en
consideracin los siguientes aspectos: conveniencia, relevancia
y la solucin de un problema especfico; as como tambin,
sealar los posibles efectos positivos que se produciran al
desarrollarse. De la misma forma, en esta seccin deben

Elaborado por: Ing. Ernesto Robles

sealarse las razones, las causas y las consecuencias por las

cuales se realiza la propuesta tecnolgica, al momento de
conceptualizarlo, se recomienda responder a las siguientes
preguntas: Por qu se desarrolla la propuesta? Cules sern
sus aportes? A quines pudiera beneficiar?
Puede seguir el siguiente orden para su estructuracin:
Exponga las razones, causas, argumentos que valor
para realizar la propuesta, desde el punto de vista
tcnico
Plantee la trascendencia y utilidad prctica, terica o
metodolgica que proporcionar el trabajo, as como el
impacto, relevancia y el aporte que constituir su
desarrollo.
Considere a quienes se va a beneficiar con los resultados
Factibilidad del estudio
1.3.
Objetivos
1.3.1.Objetivo General.- Es el propsito central de la
propuesta, es decir, tener una visin general de que se
requiere para la propuesta tecnolgica. Por lo tanto, se
podra definir de tal manera que nos indique lo que se
espera lograr con el estudio en trminos de conocimiento;
debe dar una nocin clara de lo que se pretende describir,
determinar, identificar, comparar y verificar, etc.
Se debe considerar que los objetivos generales deben estar
redactados en trminos de resultados y solamente utiliza
un verbo en infinitivo
1.3.2.Objetivos
Especficos.Son
aquellos
pasos
o
especificaciones que hay que alcanzar para la obtencin del
objetivo general. En funcin del objetivo general, deber
escribir dos o ms objetivos especficos en funcin de las
caractersticas de su estudio.
1.3.3.
Alcance de la Propuesta.- Se trata de establecer cules
sern las delimitaciones de la propuesta tecnolgica sin que
este indique lmite del mismo, ya que es una descripcin de lo
que el software realizar como solucin al problema planteado
en su propuesta, es decir, aborda y documenta las
caractersticas y los lmites del proyecto que es lo que se va a
lograr con la propuesta tecnolgica.
Factibilidad
Tcnica.- Se debe hacer un anlisis de la tecnologa requerida
para conseguir la funcionalidad y el rendimiento del sistema
propuesto, cul es el riesgo de desarrollo y cmo afectan stos
elementos el costo del proyecto. Adems, se debe definir si el

Elaborado por: Ing. Ernesto Robles

problema se puede resolver con los medios actualmente

existentes y el grado de adaptacin de la solucin a la
tecnologa con la que cuenta la organizacin.
Existe la tecnologa requerida para el desarrollo del sistema?
Puede la organizacin acceder a dicha tecnologa?
Operativa.- Explica cmo hacer funcionar el sistema
propuesto en las operaciones de la organizacin. Muestra cmo
puede cambiar el sistema el entorno del usuario y las
actividades que realiza. Comprende dos aspectos:
Impacto sobre los usuarios: cuenta el proyecto con respaldo y
compromiso verdadero, en trminos de actitud y asignacin de
recursos Consideran que el proyecto beneficia a la
organizacin? Est la alta direccin comprometida?
Impacto sobre los dems sistemas de la organizacin: Cul
ser el impacto del sistema sobre otros procesos de la
organizacin? Ser positivo? Negativo?
Econmica.- Detalla los gastos necesarios para el desarrollo
del proyecto, tomando en cuenta diferentes aspectos como
bibliografa, materiales de oficina, depreciacin de equipo,
diseador, programadores, etc.

Elaborado por: Ing. Ernesto Robles

CAPITULO II
2.

Marco Terico.Es el conjunto de teoras, doctrinas, ideas y datos que actan

como premisas de una investigacin que se requiere para la
propuesta tecnolgica. Est integrado, adems, por supuestos,
leyes, principios cientficos.
Es el fundamento de la investigacin, integrado por un
conjunto de conocimientos que se elabora para apoyar el
estudio que se propone hacer. Puede seguir el siguiente
orden para su estructuracin:
Realice una cuidadosa revisin de los estudios
tericos y prcticos que se hayan efectuado hasta la
fecha.
Realice la bsqueda de informacin, fundamentada
en la ms amplia bibliografa, procurando que sta
sea actualizada, sobre el problema que investiga y las
variables que maneja su propuesta tecnolgica.
Aplique las normas de elaboracin de referencias,
citas, notas a pies de pginas etc., para que no se
constituya en un plagio
Todo el desarrollo del fundamento terico debe
responder a las orientaciones cientficas, psicolgicas,
sociolgicas, etc.; qu usted eligi para fundamentar
su propuesta, acompaado de citas y su criterio
personal.
Por lo tanto, se debe tener presente que este marco terico
debe estar contextualizado en el desarrollo de su propuesta

Elaborado por: Ing. Ernesto Robles

CAPITULO III
3. Metodologa
3.1.
Fase de Inicio.- Esta fase tiene como propsito definir y
acordar el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto, proponer una
visin muy general de la arquitectura de software y producir el
plan de las fases y el de iteraciones posteriores. En
consecuencia definir el modelado de los negocios.
Durante la fase de inicio se define el modelo del negocio y el
alcance del proyecto. Se identifican todos los actores y Casos de
Uso, y se disean los Casos de Uso ms esenciales. Se
desarrolla, un plan de negocio para determinar que recursos
deben ser asignados al proyecto.
3.1.1.Modelo de Casos de Uso del Negocio y Modelos de Objetos
del negocio
Los Casos de Uso son una tcnica de captura de requisitos que fuerza
a pensar en trminos de importancia para el usuario y no slo en
trminos de funciones que sera bueno contemplar.
Se define un Caso de Uso como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor aadido. Los Casos de
Uso representan los requisitos funcionales del sistema. Los Casos de
Uso no son slo una herramienta para especificar los requisitos del
sistema. Tambin guan su diseo, implementacin y prueba. Los
Casos de Uso constituyen un elemento integrador y una gua del
trabajo.
Los objetivos de esta fase son:

Establecer el mbito del proyecto y sus lmites.

Encontrar los Casos de Uso crticos del sistema, los escenarios
bsicos que definen la funcionalidad.

Mostrar al menos una

escenarios principales.

arquitectura

candidata

para

los

EntrevistasSin importar la metodologa orientada a objetos, lo primero

se debe definir los problemas y objetivos en el sistema. stos forman
la base para determinar qu debe lograr el sistema.
3.1.1.1. Casos de uso

Elaborado por: Ing. Ernesto Robles

Aqu ir el diagrama del Caso de Uso

3.1.1.2. Descripcin del Caso de Uso

Nombre
:
Actores:
Propsit
o:

Nombre del caso de uso

Descripcin
Precondiciones
Flujo Normal
Flujo Alternativo
Poscondiciones
3.1.2.Alcance de la Propuesta.- Se trata de establecer cules
sern las delimitaciones de la propuesta tecnolgica sin que
este indique lmite del mismo, ya que es una descripcin de
lo que el software realizar como solucin al problema
planteado en su propuesta, es decir, aborda y documenta
las caractersticas y los lmites del proyecto que es lo que
se va a lograr con la propuesta tecnolgica.
3.1.3.Viabilidad tcnica
Se debe averiguar si es posible desarrollar el nuevo sistema teniendo
en cuenta los recursos tcnicos actuales. De no ser as, Se puede
actualizar o complementar el sistema de tal forma que pueda cumplir
con lo que se requiere?
Si no es posible complementar o actualizar los sistemas existentes, la
siguiente pregunta es si existe o no la tecnologa que cumpla con las
especificaciones.
Al mismo tiempo, se puede preguntar si la organizacin cuenta con el
personal que tenga la habilidad tcnica suficiente para lograr los
objetivos.
Otra de las preguntas es si hay o no paquetes de software disponibles
que puedan lograr sus objetivos, o si hay que personalizar el software
Elaborado por: Ing. Ernesto Robles

para la organizacin.
3.1.4.Viabilidad econmica
La viabilidad econmica es la determinacin de recursos. Los recursos
bsicos a considerar son el tiempo de anlisis (segn sea el caso) y el
tiempo de su equipo de anlisis de sistemas, el costo de realizar un
estudio de sistemas completo (incluyendo el tiempo de los empleados
con los que usted va a trabajar), el costo del tiempo del empleado de
la empresa, el costo estimado del hardware y el costo estimado del
software o del desarrollo de software.
La empresa afectada debe ser capaz de ver el valor de la inversin
que est considerando antes de comprometerse con un estudio de
sistemas completo. Si los costos a corto plazo no se ven eclipsados
por las ganancias a largo plazo o no producen una reduccin
inmediata en los costos de operacin, entonces el sistema no es
econmicamente viable y el proyecto no debe continuar.
3.1.5.Viabilidad operacional
Si suponemos que tanto los recursos tcnicos como econmicos se
consideran adecuados. Adicionalmente, se debe considerar la
viabilidad operacional del proyecto solicitado.
La viabilidad operacional depende de los recursos humanos
disponibles para el proyecto e implica la accin de pronosticar si el
sistema funcionar y se utilizar una vez instalado.
Si los usuarios estn prcticamente casados con el sistema actual, no
ven problemas con l y por lo general no estn involucrados en el
proceso de solicitar un nuevo sistema, habr mucha resistencia a la
implementacin del nuevo. Las probabilidades de que se vuelva
funcional en algn momento dado sern bajas.
Por otro lado, si los mismos usuarios han expresado la necesidad de
un sistema que sea funcional por ms tiempo, de una forma ms
eficiente y accesible, hay ms probabilidades de que el sistema
solicitado se llegue a utilizar en un momento dado.
3.1.6.
Especificacin de Requerimientos
3.2.
Fase de Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del
problema, establecer los cimientos de la arquitectura, desarrollar el
plan del proyecto y eliminar los mayores riesgos. En esta fase se
construye un prototipo de la arquitectura, que debe evolucionar en

Elaborado por: Ing. Ernesto Robles

iteraciones sucesivas hasta convertirse en el sistema final. Este

prototipo debe contener los Casos de Uso crticos identificados en la
fase de inicio. Tambin debe demostrarse que se han evitado los
riesgos ms graves.
Los objetivos de esta fase son:

Definir, validar y cimentar la arquitectura.

Completar la visin.
Crear un plan fiable para la fase de construccin. Este plan
puede evolucionar en sucesivas iteraciones. Debe incluir los
costes si procede.

Demostrar que la arquitectura propuesta soportar la visin con

un coste razonable y en un tiempo razonable.
3.2.1.Casos de uso en el modelo del sistema

Se definir el diagrama el Artefacto narrativo que describe, bajo la

forma de acciones y reacciones, el comportamiento del sistema
desde el punto de vista del usuario
3.2.2.Descripcin del caso de uso del sistema
Nombre del caso de uso
Nombre:
Actores:
Propsito:
Descripcin
Precondiciones
Flujo Normal
Flujo Alternativo
Poscondiciones
3.2.3.Diagramas de Actividades del Sistema
Estos diagramas muestran bsicamente actividades, representando la
realizacin de operaciones y las transiciones son disparadas por la
finalizacin de estas operaciones
3.2.4.
3.2.5.Diagramas de Caso de uso del negocio
3.2.6.Especificacin de Requerimientos
Un requerimiento es una caracterstica que el sistema debe tener o es
Elaborado por: Ing. Ernesto Robles

una restriccin que el sistema DEBE satisfacer para ser aceptada por
el cliente. En consecuencia, el levantamiento de requerimientos es la
especificacin del sistema en trminos que el cliente entienda, de
forma que se constituya en el contrato entre el cliente y los
desarrolladores.
3.2.6.1. Funcionales
Un requisito funcional define una funcin del sistema de software o
sus componentes, de tal manera que una funcin es descrita como un
conjunto de entradas, comportamientos y salidas.
Los requerimientos funcionales pueden ser: clculos, detalles
tcnicos, manipulacin de datos y otras funcionalidades especficas
que se supone, un sistema debe cumplir.
A continuacin se presentan algunos ejemplos de estos
requerimientos funcionales para un sistema de biblioteca
universitaria, denominada LIBSYS, utilizada por estudiantes y
personal docente que solicitan libros y documentos de otras
bibliotecas.

El usuario deber tener la posibilidad de buscar en el conjunto

inicial de la base de datos o seleccionar un subconjunto de ella.
El sistema deber proporcionar visores adecuados para que el
usuario lea documentos en el almacn de documentos.
A cada pedido se le deber asignar un identificador
nico(ID_PEDIDO), que el usuario podr copiar al rea de
almacenamiento permanente de la cuenta

En principio, la especificacin de requerimientos funcionales de un

sistema debe estar completa y ser consistente.

La completitud significa que todos los servicios solicitados por

el usuario deben estar definidos.
La consistencia significa que los requerimientos no deben tener
definiciones contradictorias.
3.2.6.2. No funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema,

incluyen restricciones de tiempo, sobre el proceso de desarrollo y
estndares.
Los requerimientos no funcionales a menudo se aplican al sistema en
su totalidad; por lo tanto normalmente apenas se aplican a
caractersticas o servicios individuales del sistema.

Elaborado por: Ing. Ernesto Robles

De forma alternativa, definen las restricciones del sistema como la

capacidad de los dispositivos de entrada/salida y las representaciones
de datos que se utilizan en las interfaces del sistema
Por tanto, se refieren a todos los requisitos que no describen informacin a guardar, ni
funciones a realizar. Algunos ejemplos de requisitos no funcionales tpicos son los
siguientes:

Rendimiento

Disponibilidad

Seguridad

Accesibilidad

Usabilidad

Estabilidad

Portabilidad

Costo

Operatividad

Interoperabilidad

Escalabilidad

Concurrencia

Mantenibilidad

Interfaz

3.2.7.
3.3.
Fase de Construccin
La finalidad principal de esta fase es alcanzar la capacidad
operacional del producto de forma incremental a travs de las
sucesivas iteraciones. Durante esta fase todos los componentes,
caractersticas y requisitos deben ser implementados, integrados y
probados en su totalidad, obteniendo una versin aceptable del
producto.
Los objetivos concretos incluyen:

Minimizar los costes de desarrollo mediante la optimizacin de

recursos y evitando el tener que rehacer un trabajo o incluso
desecharlo.
Conseguir una calidad adecuada tan rpido como sea prctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de
prueba) tan rpido como sea prctico
Elaborado por: Ing. Ernesto Robles

Los diccionarios de datos de estar contemplado en el siguiente

esquema:
<NOMBRE DE LA TABLA>
Fecha de Diseo:

Autor:

Descripcin:
Descripcin de los Campos
Campo

Tipo

Campos que se relacionan (FK):

Tamao

Descripcin

Campo claves (PK):

3.3.1.Vista lgica
3.3.1.1. Diagramas de Clase
3.3.1.2. Modelo E-R
Se debe colocar el modelo de datos que est usando.
3.3.1.3. Diccionarios de Datos
Se debe tomar en consideracin la tabla en la parte superior que ser
la plantilla a seguir en el desarrollo de este aspecto de la propuesta.
3.3.2.Vista Implementacin
3.3.2.1. Diagrama de Secuencia del Sistema
Permite mostrar como un objeto interacta con otros, representados
por lneas continuas en el tiempo para su progresin vertical, es decir
que muestra grficamente los eventos que fluyen de los actores del
sistema
3.3.2.2. Diagrama de Estados del Sistema
Muestran un conjunto de estados por los cuales pasan un objeto
durante su vida en la aplicacin en respuestas a eventos, junto con
sus respuestas o acciones.
Los diagramas de estado son una tcnica conocida para describir el
comportamiento de un sistema. Describen todos los estados posibles
en los que puede entrar un objeto particular y la manera en que
cambia el estado del objeto, como resultado de los eventos que
llegan a l.
Elaborado por: Ing. Ernesto Robles

3.3.2.3. Diagrama de colaboracin

3.3.3.
Vista conceptual
3.3.3.1. Modelo de Dominio
3.3.4.
Vista Fisica
3.4.
Mapa de comportamiento a nivel de Har Fase de
Transicin
La finalidad de la fase de transicin es poner el producto en manos de
los usuarios finales, para lo que se requiere desarrollar nuevas
versiones actualizadas del producto, completar la documentacin,
entrenar al usuario en el manejo del producto, y en general tareas
relacionadas con el ajuste, configuracin, instalacin y facilidad de
uso del producto. Algunas de las cosas que puede incluir esta fase:

Prueba de la versin Beta para validar el nuevo sistema frente a

las expectativas de los usuarios
Funcionamiento paralelo con los sistemas legados que estn
siendo sustituidos por nuestro proyecto.
Conversin de las bases de datos operacionales.
Entrenamiento de los usuarios y tcnicos de mantenimiento.
3.4.1.Implementacin de la propuesta
3.4.1.1. Instalacin del Sistema.- La instalacin del
sistema proporciona detalles completos sobre la forma
de instalar el sistema en un ambiente particular.
3.4.1.2. Guas de Uso
3.4.1.2.1. Acceso a la Aplicacin.- En este punto se
explica cmo iniciarse en el sistema y cmo se
pueden utilizar sus cualidades comunes.
3.4.1.2.2. Detalles de Opciones de la Aplicacin del
Sistema.- Deben especificarse los archivos de
entrada, salida, los resultados, revisiones y
procesos manuales.
El proceso principal que se desarrolla.
La entrada de la informacin.
La obtencin de un resultado parcial.
El envo de informacin a otra dependencia.
Reportes
Etc.
3.4.1.2.3. Preguntas Frecuentes.- En esta seccin se
establecern las soluciones a posibles problemas
frecuentes que puedan presentarse ante la
manipulacin del sistema y que resultan comunes
dentro del sistema de informacin.
3.4.2.Glosario.- En l, se incluyen todos aquellos trminos poco
conocidos, de difcil interpretacin, o que no sean

Elaborado por: Ing. Ernesto Robles

comnmente utilizados en el contexto en que aparecen.

Elaborado por: Ing. Ernesto Robles

CAPITULO IV

3.5.
Fase de Transicin
3.6.
Diagrama de Flujo de Datos.- Es un grfico lgico del
plan de trabajo que se ejecutara para la solucin de un
determinado problema. Las capacidades humanas necesarias
para elaborar un diagrama de flujo correcto son: Lgico,
Prcticas, y Atencin. Se debe considerar que el diagramado
estar orientado al proceso de desarrollo de software (no
confundirse con los diagramas de programas)
La secuencia en que debern ejecutarse las operaciones tendr
que definirse claramente, y cuando se combine con los datos a
los que debe aplicarse, esa secuencia creara el flujo de
informacin. Objetivos de un diagrama de flujo:
Estructura la solucin del problema independiente del
lenguaje a utilizar.
Separar la solucin lgica de programacin de la parte de
reglas y sintaxis de codificacin con esta divisin del
trabajo se obtiene mayor eficiencia.
Dar una visin completa del problema al programador ya
que pierde en un programa ya codificado.
Permitir una compresin ms rpida del programa a otros
programadores.
*Cada DFD debe ir en hojas individuales y antes de detallar cada uno
de los DFD, se debe dar a conocer la simbologa que se va a utilizar
DFD DESCRIPCION DEL MODULO A ESQUEMATIZAR
NOMBRE DEL SISTEMAS QUE
AREA A LA QUE PERTENECE EL
ESTA ESQUEMATIZANDO
ESQUEMA
FECHA DE DISEO:
DIAGRAMA DE FLUJO DE DATOS

DFD DEL MODULO A ESQUEMATIZAR

NOMBRE DEL SISTEMAS QUE
AREA A LA QUE PERTENECE EL
ESTA ESQUEMATIZANDO
ESQUEMA
FECHA DE DISEO:
NARRATIVA DEL PROCESO QUE SE ESTA ESQUEMATIZANDO
Elaborado por: Ing. Ernesto Robles

3.7.
Diagrama de Flujo de Informacin.- Se lo establece
de igual forma que un DFD (es decir que se acoge el
esquema anterior) con la diferencia que se definir los procesos
de reportera que generara el sistema de informacin que se
est desarrollando (Esta enfocado a mostrar el diagrama de los
reportes que vayan a tener su propuesta tecnolgica).
3.8.
Diagrama Jerrquico del Sistema.- Se debe ddisear
un diagrama que permita al lector conocer cmo estarn
clasificadas las opciones que intervienen en el sistema a
manera de procesos, definiendo que opciones sern principales
y qu opciones sern secundarias, es decir una figura
orientada a mostrar bloques que resumen cada uno de los
otros tems. (2.1 y 2.2)
CAPITULO III
4. Diseos de Entrada y Salida
4.1.
Diseo de Pantallas.- En esta seccin se mostrara las
pantallas a utilizarse dentro del sistema de informacin que se
est desarrollando
DISEO DE PANTALLA DE ?
DESCRIPCION PARA SU UTILIZACION:

NOMBRE DEL
SISTEMA QUE SE
ESTA
ESQUEMATIZANDO
FECHA DE DISEO:

NOMBRE DEL FORMULARIO:

LISTA DE ELEMENTOS QUE CONTIENE

NOMBRE DE LOS CONTROLES A
DESCRIPCION DE SU USO
UTILIZAR
4.2.
Diccionario de Datos.- Es un listado organizado
de todos los elementos de datos pertinentes al sistema, con
definiciones precisas y rigurosas para que el usuario y el
analista de sistemas puedan conocer todas las entradas,
salidas, componentes de depsitos y clculos intermediarios
Elaborado por: Ing. Ernesto Robles

dentro del sistema

desarrollando

de

informacin

la

cual

se

est

DD <NOMBRE DE LA TABLA>
Nombre de la Base de Datos:
Fecha de Diseo:

Descripcin:
Descripcin de los Campos

Campo

Tipo

Tamao

Campos que se relacionan(FK):

Descripcin

Campo claves (PK):

4.3.
Diagrama de Clases del Modelo Entidad-Relacin.Debe insertar un esquema de cmo quedar el diseo de
modelado de datos de la Base.
CAPITULO IV
5. Requerimientos
Nota: Un requerimiento es una caracterstica que el sistema DEBE
tener o es una restriccin que el sistema DEBE satisfacer para ser
aceptada por el cliente. Levantamiento de requerimientos es la
especificacin del sistema en trminos que el cliente entienda, de
forma que se constituya en el contrato entre el cliente y los
desarrolladores.
5.1.
Hardware.- Se debe definir las necesidades que requiere,
la arquitectura del ordenador para poder implantar el sistema
de informacin, tales como:
Arquitectura
Capacidad de Almacenamiento
Capacidad de Procesamiento
Cableados (si lo amerita)
Ect.
5.2.
Software.- Se deben establecer Los paquetes de
software, programas de aplicacin, as como tambin, paquete
de software apropiado para todo el sistema o parte de l y su
uso implique un mnimo de adaptaciones.
5.3.
Funcionales.- Son declaraciones de los servicios que

Elaborado por: Ing. Ernesto Robles

debe proporcionar el sistema, de la manera en que ste debe

reaccionar a entradas particulares y de cmo se debe
comportar en situaciones particulares. En algunos casos, los
requerimientos funcionales de los sistemas tambin pueden
declarar explcitamente lo que el sistema no debe hacer.
En consecuencia, los requerimientos funcionales de un sistema
describen lo que el sistema debe hacer. Estos requerimientos
dependen del tipo de software que se desarrolle, de los posibles
usuarios del software y del enfoque general tomado por la
organizacin al redactar requerimientos. Cuando se expresan
como requerimientos del usuario, habitualmente se describen
de una forma bastante abstracta. Sin embargo, los
requerimientos funcionales del sistema describen con detalle la
funcin de ste, sus entradas y salidas, excepciones, etc.
5.4.
No Funcionales.- Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo y estndares. Los
requerimientos no funcionales a menudo se aplican al sistema
en su totalidad. Normalmente apenas se aplican a
caractersticas o servicios individuales del sistema.
Los requerimientos no funcionales, como su nombre sugiere,
son aquellos requerimientos que no se refieren directamente a
las funciones especficas que proporciona el sistema, sino a las
propiedades emergentes de ste como la fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento. De forma
alternativa, definen las restricciones del sistema como la
capacidad de los dispositivos de entrada/salida y las
representaciones de datos que se utilizan en las interfaces del
sistema
CAPITULO V
6. Sistema de Seguimiento y Control
6.1.
Cronograma de Actividades para el desarrollo del
Sistema de Informacin.- Consiste en determinar el tiempo
que comprender cada una de las actividades que se irn a
realizar para el desarrollo de la propuesta tecnolgica; as
como tambin, para definir los tiempoel tiempo de redaccin
de la documentacin (manuales de diseo y usuario)
establecida; por lo tanto establezca , as como la fechalas

Elaborado por: Ing. Ernesto Robles

fechas aproximadas en la que se terminara dicha

propuestatoda las propuesta (Software y Documentacin).

Tarea o
Actividad

Fechas
Comienz
o

Da
s
Fin

Detalle de cada actividad

segn lo estimado por el
cronograma de trabajo
Da 1 o
Mes 1

Da 2 o
Mes 2

Da N o
Mes N

6.2.
Seguridad.- En esta seccin se detallar las medidas de
validacin de datos y/o seguridad en que se implementara en
el sistema de informacin; tales como, Backup, invalidacin
para la insercin, consultas de datos, etc.
6.2.1.Seguridades Fsicas.- Nos referimos a todos aquellos
mecanismos, generalmente de prevencin y deteccin,
destinados a proteger fsicamente cualquier recurso del
sistema; estos recursos son desde un simple teclado hasta
una cinta de backup con toda la informacin que hay en el
sistema.
6.2.2.Seguridades Lgicas.- Consiste en la aplicacin de
barreras y procedimientos que resguarden el acceso a los
datos y slo se permita acceder a ellos a las personas
autorizadas para hacerlo.
6.2.3.Revisiones y Actualizaciones.- En esta seccin se deben
precisar cules seran los posibles mantenimientos que
realizara al programa;
6.2.4.Actualizaciones.- as como tambinEn este contexto se
debe indicar los futuros procesos de actualizacin del
sistema de informacin segn lo requiera y el estudio de
mejoras lo amerite.

Elaborado por: Ing. Ernesto Robles

CAPITULO V

7. Bibliografa.Es el conjunto de publicaciones, libros, pginas web o textos de

consulta, etc., que se haya utilizado para el desarrollo de la propuesta
tecnolgica. (verifiqueVerifique el uso de normas APA 6
establecida en cada cita)

Elaborado por: Ing. Ernesto Robles

Esquema para la Elaboracin del Manual de

Usuario
PRELIMINARES
CARATULA
INSTITUTO TECNOLOGICO ALMIRANTE ILLINGWORTH

TRABAJO DE GRADUACIN PREVIO A LA OBTENCIN DEL TTULO DE

TCNOLOGO SUPERIOR EN INFORMTICA

TEMA
Descripcin de tema

Manual de USUARIO

AUTOR
Apellidos y Nombres del Estudiante

DIRECTOR DEL TRABAJO DE GRADUACION:

Apellidos y Nombres del Tutor asignado

Guayaquil, April de 2016

PORTADA INTERIOR
Debe contener los mismo parmetros establecidos en la caratula
CERTIFICACION DEL TUTOR
La Certificacin del Tutor o Director de Trabajo de Titulacin, es un

Elaborado por: Ing. Ernesto Robles

documento obligatorio que el tutor deber firmar, dando fe que el

trabajo ha sido debidamente revisado y est en condiciones de ser
entregado para que se siga lo dispuesto por el Instituto, en cuanto a
la sustentacin y defensa del mismo.
INDICE
Inicia desde el Captulo I que corresponde a la Generalidades con el
orden que corresponda su numeracin empezando desde el Uno.
Puede contener:
ndice de contenidos
ndice de tablas.-Usa los mismos ttulos que aparecen en el
texto, de las tablas.
ndice de grficos.- Usa las mismas leyendas que aparecen en
el texto.
ndice de anexos.- Usa los mismos ttulos que aparecen en los
apndices o anexos.

Elaborado por: Ing. Ernesto Robles

CAPITULO I
8. Generalidades
1.1.
A quien va dirigido el Manual.- Se debe especificar
cul sera el perfil de las personas que podran utilizar el
software desarrollado, de tal manera que tambin tenga la
capacidad de comprender la documentacin que permite
utilizar el sistema informtico o propuesta tecnolgica.
1.2.
Acerca del Manual.- Aqu se detallara las caractersticas
generales en las que est constituido la propuesta tecnolgica
o sistema de informacin que se haya desarrollado, es decir
que contemplar al momento de aplicar la solucin de su
sistema.
1.3.
Requerimientos del Sistema.- Se deben detallar los
requisitos mnimos que se van a necesitar para la instalacin e
implementacin de la propuesta tecnolgica (Hardware y
Software).
CAPITULO II
9. Operacionalidad del Sistema
9.1.
Funcionalidades del Sistema.- Expone los procesos que
el usuario debe realizar de ser posible para todos aquellos
requisitos previos que necesitara sus sistema a implementar.
Para lograr esto, es necesario que se detallen todas y cada una
de las caractersticas que necesita el programa y la forma de
acceder e instalarlos adecuadamente.
9.2.
Instalacin del Sistema.- La instalacin del sistema
proporciona detalles completos sobre la forma de instalar el
sistema en un ambiente particular.
9.3.
Diagrama General del Sistema.- Muestra en forma
condensada el flujo general de la informacin y de las
actividades que se realizan en el sistema. Proporciona una
visin general del sistema.
1.1.
Solucin de Problemas.- Esta seccin se indicara las
posibles soluciones a problemas que pueden ocurrir durante la
instalacin o funcionamiento del sistema de informacin.
CAPITULO III
10.

Usos del Sistema

10.1.

Guas de Uso
Elaborado por: Ing. Ernesto Robles

10.1.1.
Acceso a la Aplicacin.- En este punto se explica
cmo iniciarse en el sistema y cmo se pueden utilizar sus
cualidades comunes.
10.1.2.
Detalles de Opciones de la Aplicacin del
Sistema.- Deben especificarse los archivos de entrada,
salida, los resultados, revisiones y procesos manuales.
11. El proceso principal que se desarrolla.
12. La entrada de la informacin.
13. La obtencin de un resultado parcial.
14. El envo de informacin a otra dependencia.
15. Reportes
16. Etc.
16.1.
Preguntas Frecuentes.- En esta seccin se establecern
las soluciones a posibles problemas frecuentes que puedan
presentarse ante la manipulacin del sistema y que resultan
comunes dentro del sistema de informacin.
16.2.
Glosario.- En l, se incluyen todos aquellos trminos poco
conocidos, de difcil interpretacin, o que no sean comnmente
utilizados en el contexto en que aparecen.
17.

Bibliografa.-

Es el conjunto de publicaciones, libros, pginas web o textos de

consulta, etc., que se haya utilizado para el desarrollo de la propuesta
tecnolgica.

Elaborado por: Ing. Ernesto Robles

Elaborado por: Ing. Ernesto Robles

Estndares y Normas para la Presentacin de los Manuales de Diseo

y Usuario
Esta gua va a permitir establecer los aspectos que se requieren para
la presentacin de la Documentacin, en los respectivos Manuales de
Diseo y Usuario.
En consecuencia, se incorporaran, ciertas referencias del Manual de
estilo de la American Psychological Association (APA).
Estndares a considerar:
De acuerdo a las Normas APA se debe contemplar las siguientes
reglas:

Las referencias bibliogrficas deben ser insertadas en el texto

(no se coloca a pie de pgina) en minscula
Todas las referencias usadas en el texto, debern ser ubicadas
en estricto orden alfabtico en la Bibliografa

Por lo tanto, tenemos lo siguiente:

Las referencias van a permitir al lector la oportunidad de

comprobar la existencia de las fuentes originales de su trabajo.
Es un indicador directo del grado de profundidad de la
investigacin
No deben haber citas en el texto
que no tengan su
correspondiente referencias ni referencias que no respondan a
citas en el texto del trabajo de graduacin.
Sin
embargo
podemos
establecer:
Bibliografa,
Otras
bibliografas consultadas.
Recuerda que la bibliografa debe ser actualizada
Es aconsejable utilizar bibliografa de los ltimos cinco aos y
con ISBN (Definiciones de ISBN en la web: El international
standard book number (en espaol, nmero estndar
internacional de libro), abreviado ISBN, es un identificador
nico para libros, previsto para uso comercial)

Normas para las Escritura:

Texto: La calidad, opacidad y su color deben facilitar la lectura,

impresin y reproduccin. Se escribe por una sola cara de las
hojas.
Redaccin: Redacte el texto de manera impersonal, es decir,
use los verbos conjugados en la tercera persona del singular.

Elaborado por: Ing. Ernesto Robles

Todos los prrafos comienzan contra el margen izquierdo y sin

dejar sangra.
Cada captulo comienza en una hoja aparte. Escriba de forma
ntida y ordenada, no debe contener errores dactilogrficos,
gramaticales, de redaccin o puntuacin. Los trminos que
aparezcan en otro idioma se escriben en bastardilla (cursiva).
Numeracin: Las pginas preliminares se numeran en romanos,
al centro e inferior. La pasta y portada interior se cuentan
pero NO SE NUMERAN.
Las Tablas y Figuras. Las tablas exhiben datos cuantitativos que
se disponen en una presentacin ordenada de columnas y filas.
La figura es cualquier tipo de ilustracin distinta a una tabla:
diagrama, grfica, fotografa, dibujo u otro tipo de
representacin.
Debe utilizarse papel blanco 8075g. INEN A4, de la misma
calidad y corte.
Numeracin de la pgina en la parte centro e inferior
Tipo de letra: 12 puntos en letra Times New Roman
Ttulos se escriben con mayscula y con dos puntos ms que el
texto normal. (14 Ptos.)
Los subttulos van en negrita y tamao normal.
Espacio entre lneas: Espacio y medioSencillo; Espacio 12 Ptos.
entre prrafos.
Mrgenes: superior e inferior 3 cm; Derecho: 3 cm, izquierdo 4
cm.

Elaborado por: Ing. Ernesto Robles