I.

De la estructura y contenido del proyecto de grado

El contenido del documento de Proyecto de Grado debe ser un informe de los resultados
finales del análisis, investigación y del modelo propuesto, este debe cumplir con los
objetivos propuestos en el perfil de Proyecto de Grado. Este informe debe estar redactado
siguiendo determinadas normas y formato que responda a las características propias de un
Trabajo de Grado, de tal forma que le confiera validez profesional.

La estructura del Proyecto de Grado debe considerar la siguiente organización:

CARATULA
DECLARACION DE DERECHOS DEL AUTOR
AGRADECIMIENTOS (Opcional)
DEDICATORIA (Opcional)
RESUMEN o ABTRACTO
INDICE
INTRODUCCION
PRIMERA PARTE. MARCO CONTEXTUAL
SEGUNDA PARTE. MARCO TEORICO
TERCERA PARTE. MODELO TEORICO
CUARTA PARTE. CONCRECION DEL MODELO
CONCLUSIONES
RECOMENDACIONES
REFERENCIA BIBLIOGRAFICA
BIBLIOGRAFIA
GLOSARIO (Opcional)
ANEXOS (Opcional)
REFERENCIA TECNICA (Si se aplica)

Este contenido temático le da sentido a la lectura de la tesis, porque es fácil ver cómo el
objeto de estudio pasa de una situación inicial (problema) a una situación final (problema
superado).

CARATULA

Estará presente en la tapa dura y dentro del documento, contiene fundamentalmente el título
del proyecto, el nombre del tesista y el nombre del asesor y de la Institución.

El título es un elemento de especial importancia en cualquier informe. Un buen título puede

definirse como aquel que con el menor número de palabras describe adecuadamente el
contenido del Proyecto. El título debe emplear términos específicos en lugar de términos
genéricos. Es de destacar que el título es un rótulo y no una oración donde aparece
irremisiblemente el sujeto, el verbo y el predicado.
Es mejor seleccionar el título después de haber terminado el proyecto y sobre la base de
varias posibles opciones.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
1
El nombre del tesista debe estar presente en la carátula de la tapa como en la carátula
interna, en cambio el nombre del asesor debe estar presente sólo en la carátula interna.

Además, es importante indicar la modalidad (proyecto de grado, trabajo dirigido, etc.) y el

propósito del documento ( Optar el título de ..)

DECLARACION DE DERECHOS DE AUTOR

Contiene la declaración del tesista mencionando la autoría académica, y permitiendo que la

Universidad y los estudiantes puedan utilizar como base de consulta el contenido del
Proyecto.

RESUMEN O ABSTRACTO

Es la versión extractada del contenido fundamental del Proyecto. Contiene esencialmente

información sobre “qué se ha estudiado”, “cómo”, “por qué ”y “cuáles son los resultados
finales”, brindando suficiente información para comprender el trabajo desarrollado.

El resumen se extiende a una página y debe considerar los siguientes aspectos:

• Que plantee el problema y el objetivo.

• Que describa la metodología empleada.
• Que resuma los resultados, tanto teóricos como prácticos.
• Que exprese las conclusiones finales.

INDICE

Se deben incorporar tres tipos de índices:

• El índice del contenido.

• El índice de figuras.
• El índice de tablas.

INTRODUCCION

El propósito de la introducción es brindar la suficiente información que permita la

compresión, y la evaluación de los resultados del proyecto desarrollado. Debe ofrecer la
fundamentación teórica del Proyecto y debe expresar de forma clara las diferentes partes de
que se compone.

1. Antecedentes
2. Situación problemática
Revisión Mayo 2008
Comisión de Grado de la Carrera de Ingeniería de Sistemas
2
 3. Problema
4. Objeto de estudio y campo de acción
5. Objetivos
6. Idea a defender / Propuesta a Justificar / Solución a Comprobar
7. Alcance y limitaciones
8. Aporte teórico
9. Aporte práctico
10. Métodos y medios de investigación
11. Métodos y medios de ingeniería

Antecedentes

Presenta la introducción al tema propuesto, la idea de dónde surge el problema, los

antecedentes que llevan a identificar el problema y la solución propuesta, los antecedentes
de otros proyectos desarrollados en la organización, además del escenario del proyecto
junto con una explicación breve del contexto del problema y los principales conceptos y
elementos del marco teórico.

Situación Problemática

Describe el contexto del problema en el entorno de la organización. Se deben detallar los

factores, causas y consecuencias de la existencia del problema.

Problema

Expresar el problema consiste en argumentar “el por qué” del proyecto. El problema debe
expresar la situación no deseada del objeto de estudio. El problema debe enfatizar su
carácter de actualidad y pertinencia, justificando así su necesidad de desarrollar este
proyecto.

Los criterios para formular correctamente el problema son:

• Expresar la situación más crítica del objeto de estudio (situación no

deseada).
• Formular claramente y sin ambigüedades en un sólo párrafo.
• Implica la posibilidad de prueba empírica, o factible de observarse en
la realidad.
• También puede estar expresada como pregunta.

Objeto de Estudio y Campo de Acción

El objeto de estudio de la investigación es el “qué” se estudia, y no es más que la parte de

la realidad objetiva donde se manifiesta el problema, y sobre la cual actúa el tesista práctica
o teóricamente en busca de una solución adecuada.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
3
El campo de acción es la delimitación y precisión más detallada del área en la cual el tesista
desarrollará su trabajo. El campo de acción es una perspectiva de solución con la cual se
aborda el problema. El campo de acción permite establecer puntualmente las propiedades,
cualidades y leyes que caracterizan al objeto de estudio.

Objetivos

Esta compuesto por el objetivo general y los objetivos específicos.

El objetivo general debe explicar el “para que” se realizó el trabajo de investigación. Son
los propósitos que motivaron al tesista para realizar el trabajo y solucionar así una
necesidad o problema planteado, o aprovechar una oportunidad. Los objetivos deben
plantear una situación deseada en el objeto de estudio.

Debe además expresarse un conjunto de objetivos específicos, de manera clara y precisa,

siendo estas las “guías de la investigación” que permitirán alcanzar el objetivo general, y
por supuesto deben transmitir la certeza de ser alcanzables. Estos objetivos se los puede
clasificar en cuatro tipos:

• Funcionales (módulos generales del sistema).

• Técnicos ( herramientas, plataforma, tecnologías a utilizarse)
• Calidad ( aplicada al software y al desarrollo)
• Tareas investigativas ( hitos importantes en el tiempo con resultados
entregables)

Idea a Defender / Propuesta a Justificar / Solución a Comprobar

Se trata de expresión, propuesta o solución que debe probarse, argumentarse y defenderse

con argumentos teóricos y prácticos expuestos en el proyecto. La misma debe tener las
siguientes características

• Las variables expresadas, las situaciones, las soluciones y sus componentes

tienen que ser comprensibles, precisas y concretas, y la relación entre ellas debe
ser lógica.
• Las mismas deben ser observadas y medidas en la realidad, si no se poseen
instrumentos o técnicas para ser verificadas dejan de ser útiles.

Delimitación del Proyecto

Define explícitamente hasta dónde llegará el desarrollo del proyecto, esto implica también
describir los límites del mismo o lo que no considerará el producto final.

Aporte Teórico

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
4
En el proceso de desarrollo del proyecto de grado deben quedar claro cuáles son los aportes
teóricos alcanzados, estos pueden describirse a partir de:

• Qué conocimientos nuevos fueron encontrados.

• Qué tecnología nueva no ha sido aplicada en nuestro entorno.
• Los resultados específicos obtenidos podrán ser generalizados.
• Servirá la información obtenida para la sustentación o apoyo de una teoría.
• Permitirá expresar nuevas ideas, recomendaciones, soluciones, propuestas o
hipótesis de futuros proyectos.

Aporte Práctico

No sólo el aporte teórico es importante, sino también su significación práctica, La misma

puede describirse a partir de:

• Cuál es su relevancia social.

• Quiénes y de qué modo se beneficiarán con los resultados obtenidos.
• Ayudará a la solución de un problema práctico.

Métodos y Medios de Investigación

Los métodos y medios son el camino o la vía por donde transita el proceso del proyecto
planteado, y permiten transformar el objeto de estudio desde su estado no deseado hasta el
estado propuesto o deseado.

Los métodos pueden ser empíricos (encuestas, entrevistas, recopilación de información,

muestreo) y/o teóricos (análisis, síntesis, abstracción, dialéctico, histórico, etc.) y se
corresponderán con una etapa del desarrollo.

Métodos y Medios de Ingeniería

En el caso de desarrollos de software debe indicarse claramente el enfoque de desarrollo de

software, ciclo de vida adoptado, el método de desarrollo de software utilizado y las
herramientas y técnicas utilizadas. Estos deben estar convenientemente justificados en
función del tipo de aplicación desarrollada.

PRIMERA PARTE. MARCO CONTEXTUAL

Esta parte debe describir el contexto económico, social, cultural, político, humano,
espiritual, organizacional etc. donde el tesista desarrolla su proyecto en relación con el
objeto de estudio.

Esta parte debe expresar de forma clara las diferentes partes:

1. Entorno del objeto de estudio

Revisión Mayo 2008
Comisión de Grado de la Carrera de Ingeniería de Sistemas
5
 2. Relación tesista y objeto de estudio
3. Análisis de los problemas observados
4. Antecedentes de proyecto similares

Entorno del objeto de estudio

Este acápite debe describir al entorno en donde existe y se desarrolla el objeto de estudio,
desde su creación, desarrollo y situación actual. Esta descripción NO debe incluir
información irrelevante y demasiado general que no aporte nada al entendimiento del
objeto de estudio.

Relación tesista y objeto de estudio

Debe explicarse la relación de objeto de estudio con el tesista, y los factores que
condicionan y exigen el desarrollo del proyecto (necesidades y problemas presentes).

Análisis de los problemas observados

Debe analizarse el problema a partir de las causas hasta a llegar a los efectos o defectos
que estos causan. Este contenido se basa en la situación problemática y problema de la
introducción de proyecto, haciendo un análisis más profundo de los mismos.

Es necesario citar fechas o eventos específicos que documenten la existencia del problema
planteado, así como conclusiones de entrevistas y encuestas aplicadas a la población
relacionada con el objeto de estudio.

Al finalizar este análisis el tesista debe convencer al lector de la existencia del problema, lo
que justifica el desarrollo del proyecto.

Antecedentes de Proyectos Similares

Como ningún proyecto es del todo inédito, este ha sido desarrollado o aplicado en otra
situación y circunstancia, lo que debe analizarse y documentarse en este punto.

La similitud puede estar en el objeto de estudio, donde cambie el contexto donde se analizó,
o el objeto de estudio y el campo de acción que se estudió, o el campo de acción con
diferente objeto de estudio, o alguna otra similitud que relaciona este proyecto con otros
proyectos.

Estos proyectos pueden haberse desarrollado en nuestra ciudad, en nuestro país o en

cualquier otro país, pero es importante citar las fuentes, los autores y una descripción breve
del problema abordado y la solución planteada.

SEGUNDA PARTE. MARCO TEORICO

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
6
El marco teórico permite describir antecedentes, teorías, tecnologías, tendencias y otros
conceptos teóricos que es necesario estudiar, analizar y dominar para plantear una solución
al problema planteado.

El marco teórico cumple las siguientes funciones:

• Ayuda a prevenir errores cometidos o tecnologías mal usadas en proyectos

anteriores.
• Orienta cómo se realizará el estudio.
• Inspira nuevas líneas y áreas de investigación.
• Proporciona un marco adecuado para la interpretación y análisis de
resultados.

Esta parte puede dividirse en más de un capítulo, los que deben hacer referencia al siguiente
contenido.

1. Marco teórico de objeto de estudio (Si se aplica)

2. Marco teórico del campo del acción.
3. Diagnóstico.

El marco teórico debe mostrar que el tesista ha investigado varias fuentes de información
de absoluta confiabilidad que le permiten tener un dominio profundo del objeto de estudio y
del campo de acción abordado. Por tanto, es necesario además incluir la referencia
bibliográfica, citar explícitamente a autores y, de ser posible, obras que analizaron estos
conceptos.

Marco Teórico del Objeto de Estudio

El marco teórico del objeto de estudio debe corresponder a un exhaustivo estudio y revisión
bibliográfica realizada por el tesista para explicar antecedentes, teorías, tecnologías,
tendencias y otros conceptos teóricos asociados al objeto de estudio.

Esta revisión debe incluir al menos a dos autores con nombre y apellido que hayan
analizado y opinado sobre el concepto teórico que se describe. Los autores consultados, si
son de Internet, deben ser de reconocida trayectoria y/o estar respaldados por
organizaciones conocidas o ser docentes o investigadores de Universidades de prestigio.

Además, el tesista debe tomar postura sobe los conceptos analizados: a favor o en contra,
justificando su inclinación.

Marco Teórico del Campo de Acción

Idéntico al punto anterior, debe describir antecedentes, teorías, tecnologías, tendencias y

otros conceptos teóricos asociados al campo de acción.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
7
Nótese que un concepto teórico del campo de acción puede estar presente en varios
proyectos de grado, por tanto, la diferencia debe estar en los autores consultados en la
revisión bibliográfica.

Conceptos teóricos triviales o que han sido ampliamente estudiados en la carrera del tesista
o en proyectos anteriores NO deberían ser analizados. Estos conceptos son por ejemplo
ciclos de vida en cascada, prototipos e iterativo incremental, métodos de desarrollo de
software como RUP, Booch, Jacobson, estructurado de Yourdon, Jackson, herramientas de
modelado como RUP, DER, DFD, tecnologías de redes Lan y Wan , topologías de redes,
protocolo TCP/IP, etc..

Diagnóstico

Es el proceso mediante el cual conocemos o descubrimos el conjunto de fenómenos y

hechos no explicables que dan surgimiento al problema en el objeto.

Es necesaria la adopción de una teoría o modelo que pueda revelar en relación al problema
investigado lo siguiente:

• Que existe una teoría o varias completamente desarrolladas aplicables al

problema o situación.
• Que hay partes de teorías que con apoyo empírico pueden ser aplicables al
problema o situación.
• Que existen guías aún no estudiadas que se relacionan vagamente con el
problema estudiado o situación observada.

Los proyectos que utilizan tecnologías y herramientas para el desarrollo de software deben
realizar un análisis comparativo de varias de estas, justificando y argumentando la elección
de una de ellas para la construcción de software.

TERCERA PARTE. MODELO TEORICO

Si el capítulo anterior es la referencia teórica de otros autores, esta parte debe contener los
aportes teóricos y prácticos del tesista.

El autor debe plantear de forma teórica el modelo para la solución del problema o el
desarrollo de la propuesta.

En proyectos de simulación se deben describir los modelos matemático y lógico, siguiendo

las etapas que propone algún autor.

En proyectos de redes, se deben describir los modelos lógico y físico de la red.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
8
En proyectos que construyen aplicaciones de software se deben considerar las siguientes
partes:

1. Planificación
2. Requerimientos
3. Análisis y diseño

Es importante observar que esta parte debe permitir una lectura agradable que describa el
modelo propuesto para dar solución al problema observado, y NO debe contener sólo un
compendio de diagramas que adolece de una explicación textual.

Deben incluirse sólo diagramas generales que hacen a todo el sistema identificado con un
número de figura seguido con la explicación del mismo. También es posible hacer esta
descripción de las funciones más relevantes del sistema donde se hayan tomado
determinadas decisiones de diseño que es necesario explicarlas, pero todos los demás
diagramas deben describirse en la Referencia Técnica del Sistema.

Planificación

La planificación del desarrollo de software debe describir las actividades, los responsables
y los recursos necesarios para la realización de cada actividad. Las actividades deben ser
tan específicas que alcancen a inclusive trabajo desarrollado en días.

Esta planificación debe utilizar herramientas automáticas como MS Proyect, o cualquiera

que permita además de planificar el desarrollo, controlar luego su ejecución.

El plan resultante debe responder coherentemente al ciclo de vida adoptado y a las

actividades que propone el método de desarrollo.

Requerimientos

Debe empezar identificando a las personas relacionadas con el sistema, en términos de

actores principales y secundarios.

Describir todas las funciones que debe realizar el sistema, en términos de casos de uso para
métodos OO, y listas de eventos o diagramas de contexto para métodos ADE.

Describir los requerimientos no funcionales que explican las restricciones y limitaciones

del sistema en su desarrollo y operación.

Análisis y Diseño

Debe describir la arquitectura del software construido en términos de diagramas de

paquetes o diagramas de descomposición funcional. Algunas arquitecturas genéricas que se
puede adoptar son el modelo cliente/servidor el modelo multicapas por ejemplo. En cada
modelo es importante explicar la funcionalidad de cada componente.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
9
Debe haberse identificado un conjunto de riesgos del proyecto, los que han tenido que ser
eliminados o mitigados utilizando prototipos, o alcanzando las primeras versiones del
software.

Debe describir el diagrama de clases y el diagrama entidad relación. Además, explicar qué
clases son del tipo entidad, control e interfaz. Además, una explicación de las clases más
importantes con sus atributos y operaciones.

Debe explicar las principales decisiones de diseño introducidas en alguna funcionalidad

expresada en los diagramas de colaboración y/o de actividades.

Debe incluir la explicación de la reutilización de clases, componentes VCL, o componentes

COM y DCOM de otros fabricantes.

Debe describir el mapeo de clases o diagrama DER a tablas, explicando las relaciones entre
ellas por medio de claves foráneas.

CUARTA PARTE. CONCRECION DEL MODELO

Esta parte permite describir la introducción de la tecnología al medio, a la situación

problema. Describir y analizar los resultados obtenidos. Probar la hipótesis o solución
propuesta.

Las preguntas a responder son: ¿se ha resuelto el problema?, o ¿se han cumplido los
objetivos?

En muchos proyectos no es posible experimentar si se ha alcanzado el objetivo, puesto que

algunos objetivos son a largo plazo, y en este caso no existe experimentación.

Los proyectos que desarrollan software deben considerar al menos los siguientes puntos:

1. Implementación
2. Pruebas
3. Puesta en marcha
4. Prefactibilidad

Implementación

Debe describir la forma en la que las clases han sido traducidas al código en un lenguaje de
programación específico.

Debe explicar la arquitectura de la aplicación final, identificando los procesadores y las

funciones que se ejecutan en cada uno de ellos.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
10
Debe explicar cómo está estructurado (directorios y archivos) cada uno de los artefactos del
producto de software construido.

Debe explicar la especificación técnica del hardware y software y la infraestructura

utilizada.

Pruebas

Debe haberse ejecutado la aplicación analizándose cada uno de los datos de entrada y los
resultados obtenidos.

Estas pruebas deben ser de dos tipos, las que permiten probar alguna característica
especifica (usabilidad, ergonomía, velocidad, etc.), y las pruebas beta que permiten tener
una opinión de algunos usuarios del sistema. Es recomendable el uso mayormente de
técnicas de caja negra en mayor proporción a las de caja blanca. Es recomendable pero no
obligatorio seguir un estándar para la documentación de las pruebas, por ejemplo el
IEEE829.

Puesta en Marcha

Permite describir las principales acciones a realizar para que el modelo o solución
propuesta sea aplicada a la realidad, esto debe incluir lo siguiente:

Un conjunto de opciones y la recomendación del autor para adquirir la infraestructura

computacional donde se ubicará y funcionará la aplicación.

El conjunto de cotizaciones que permitirá la adquisición de algún componente de la

infraestructura computacional (equipos, hardware, software, etc.).

La capacitación de usuarios, sus costos, y la capacitación de personal técnico.

Prefactibilidad

Debe describir el análisis de prefactibilidad de aplicar el proyecto en la organización,

debiendo considerar los aspectos técnicos, operativos, funcionales, y económicos.

CONCLUSIONES

Comprenden las convicciones derivadas de la evidencia aportada por los resultados, su

interpretación y proyecciones.

Es necesario esquematizar las conclusiones en un orden coherente, estas no deben ser

muchas, de manera que resalten los aspectos más importantes aportados con el proyecto.

Deben responder en qué grado y precisión se han cumplido los objetivos, por lo que
consecuentemente guardan una estrecha relación con estos.
Revisión Mayo 2008
Comisión de Grado de la Carrera de Ingeniería de Sistemas
11
 REFERENCIA BIBLIOGRAFICA

La referencia bibliográfica es una aspecto importante que refleja el grado de seriedad con
que se ha abordado el tema, además indica si se ha partido de fuentes bibliográficas
actuales y confiables, como también fuentes base importantes. Le da importancia al trabajo,
un grado de actualidad y conocimiento profundo del tema.

No cualquier página de Internet puede convertirse en fuente bibliográfica, sino sólo

aquellas que están respaldadas por una organización o empresa reconocida y/o autores
conocidos (docentes o investigadores).

La diferencia con el punto siguiente es que la fuente bibliográfica debe contener la página
que se referencia.

BIBLIOGRAFIA

La bibliografía son todas las fuentes bibliográficas que han sido consultadas o no, y que
sirven de sustento bibliográfico del proyecto planteado.

Tanto la bibliografía como las referencias bibliográficas deben estar asentadas siguiendo el
estándar Vancouver.

GLOSARIO

Si en el contenido del proyecto se utilizan términos o acrónimos poco usuales, es

importante explicar estos términos en este acápite.

Como por ejemplo:

OO Enfoques y métodos que utilizan el enfoque Orientado a Objetos.

ADE Métodos de desarrollo de software tradicional, conocidos como análisis y diseño
estructurado.

ANEXOS

Contiene documentos e información adicional que no puede ser parte del cuerpo del
proyecto por su especificidad, complejidad o amplitud del mismo que puede dificultar la
lectura del proyecto.

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
12
 I. De la estructura y contenido de la Referencia Técnica del proyecto

Modelo de Requerimientos

1. Plan de requerimientos
2. Visión de los requerimientos
5. Solicitudes de usuarios (stakeholders)
6. Especificación de casos de uso (diagramas de casos de uso o diagrama de contexto)
7. Especificación de requerimientos de software (detalle de casos de uso o lista de
eventos)
5. Requerimientos no funcionales (especificación suplementaria)

Modelo de Análisis

1. Acercamiento a la arquitectura (diagrama de paquetes o diagrama de descomposición

funcional)
2. Prototipos (interfaces de todos los casos de uso o eventos)
3. Modelo de datos (diagrama de clases, diagrama de actividades, diagrama de
colaboraciones, descripción de clases, atributos y operaciones o diagrama de flujo de
datos, entidad relación, estados, diccionario de datos).

Modelo de Diseño

1. Arquitectura de software
3. Realización de los casos de uso (diagramas de colaboración y diagramas de secuencia)
4. Detalle de clases (clases, atributos y operaciones, detalle de entidades)
5. Mapeo a tablas (Mapeo de clases persistentes o mapeo DER a tablas)

Modelo de Implementación

1. Arquitectura de la implementación (diagrama de despliegue, diagrama de paquetes,

diagrama de componentes o diagrama conversacional)
2. Plan de integración
3. Descripción del código (código en el lenguaje de programación de las clases o
funciones más relevantes)

Pruebas

1. Pruebas de unidades (hechas por el desarrollador)

2. Pruebas del diseño de la aplicación (hechas por el desarrollador)
3. Pruebas de validación del usuario (hechas por el usuario)
Usar preferentemente un estándar de documentación de pruebas como el IEEE829

II. Requisitos para la defensa oral del proyecto

Para habilitarse a la defensa oral de su proyecto de grado, el alumno deberá presentar:

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
13
 1. Tesis o Proyecto.
Recomendación: En caso de que el proyecto de grado implique el desarrollo de un
sistema, de acuerdo a una metodología, entonces se incluirán sólo los aspectos más
importantes del análisis y diseño.
De los anexos: Es toda la información que complementa a la tesis o proyecto de grado
de tal forma que esta pueda ser claramente entendida.

2. Referencia Técnica del Sistema:

Importante: En este documento no se incluye el código fuente.

3. Manual del Usuario (opcional)

La comisión de proyecto de grado no exige el manual del usuario, sin embargo muchos
alumnos que lleguen a una implementación total del sistema pueden incluirlo.
También se puede incluir como tercer documento a cualquier otro cuyo contenido no
cumpla con los anteriores citados.

4. CD.
Que contenga los puntos 1, 2, y 3 y además el código fuente e instaladores del sistema
desarrollado.

III. Del formato y otros

Del tipo de letra, márgenes y otros relacionados

Todo el texto de la tesis se escribe en una sola carilla.

Tipo de letra Times New Roman 12 puntos

Interlineado 1.5 líneas
Tamaño de hoja A4
Margen superior 2,5 cm
Margen inferior 2,5 cm
Margen izquierdo 3 cm
Margen derecho 2,5 cm
Encabezado de página Contiene: nombre del proyecto, carrera,
universidad
Pie de página Contiene: número de capítulo, título del
capítulo, página del proyecto (derecha
inferior)
Titulo de capítulo 16 puntos negrita
Titulo de primer nivel 14 puntos
Titulo de segundo nivel 12 puntos negrita
Titulo de tercer nivel 12 puntos itálica, sin negrita
Espacio máximo entre titulo de cualquier 1 línea
nivel y texto

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
14
De la Paginación

 La paginación iniciará desde la página de firmas y continuará hasta la última de ellas.

 Se usarán las letras "i, ii, iii, iv, ...". para numerar desde la página de firmas hasta las
páginas preliminares.

 A partir del índice de contenido las páginas se numerarán progresivamente usando los
números arábigos. “1, 2, 3, 4, ...”

 Cada capítulo deberá iniciarse en una nueva página.

De las Tablas

 Los datos presentados en forma de columnas se reconocerán como tablas; en el caso en

que los datos puedan acomodarse en cinco líneas o menos, no necesitan ser
identificados como tablas, a menos que se haga referencia posterior a dicha
información en el texto.

 Todas las tablas tienen que llevar un número de tabla en función al número de capítulo
y número consecutivo de tabla.
Por ejemplo la tabla 1 del cap. 1 será : Tabla 1.1, luego Tabla 1.2 (tabla 2 del cap 1), y
así sucesivamente.

 Cada tabla tiene que llevar un título, centrado en la parte superior de los datos.

 Las tablas se tienen que denominar en orden progresivo y tienen que aparecer también
en orden progresivo, colocándose en el texto de acuerdo a lo siguiente:

a. Inmediatamente después de que se menciona por primera vez la tabla.

b. Si no hubiera espacio suficiente para insertarla en la misma página de la
primera mención, se colocará en la(s) página(s) contigua(s).
c. En casos especiales, determinados por el tamaño o extensión de la tabla, se
podrán colocar al final del capítulo en el que la tabla se menciona por
primera vez.

 Al pie de la tabla se tienen que incluir:

a. La(s) referencia(s) de las fuentes donde se tomó la tabla o algunas de sus partes
específicas.
b. En su caso, la indicación de que se trata de "elaboración propia".
c. Notas generales y específicas.

De las Figuras

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
15
  Se reconocerán como figuras todos los materiales ilustrativos que incluye, pero no
necesariamente están limitadas a: gráficas, diagramas de cuerpo libre, mapas, dibujos
hechos manualmente o en computadora, fotografías o cualquier otro tipo de
representación gráfica. A continuación se dan las características que deben tener.

 Respecto a la numeración, se sigue el mismo criterio que el que se sigue para las tablas,
pero esta vez usando el apócope Fig. x.xx

 El título de la figura debe colocarse en la parte inferior de la misma y centrado, además

de indicar la fuente bajo los mismos criterios que para las tablas.

IV. Del trabajo con la bibliografía

El tesista requiere de un estudio científico, bibliográfico, exploratorio y exhaustivo de una

literatura especial. Para poder desarrollar su trabajo siempre se apoya en la suma de
conocimientos obtenidos en etapas anteriores del desarrollo de la ciencia. Es por esto que el
tesista invierte a menudo mucho tiempo en la búsqueda de la información requerida.

1. Propósitos de la revisión bibliográfica

- Analizar, delimitar y definir el problema
- Evitar la duplicación de datos.
- Permite deducir recomendaciones para investigaciones posteriores.

2. Formato para las referencias bibliográficas según las Normas VANCOUVER

(Consultar Internet para ampliar información sobre estas normas.)

Revisión Mayo 2008

Comisión de Grado de la Carrera de Ingeniería de Sistemas
16