UNIVERSIDAD NACIONAL DE HUANCAVELICA

(Creada por ley N° 25265)

FACULTAD DE INGENIERÍA ELECTRÓNICA - SISTEMAS

ÁREA DE PRÁCTICAS PRE-PROFESIONALES

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“CABLEADO ESTRUCTURADO DE RED DE DATOS DEL

CUARTO PISO DE LA MUNICIPALIDAD PROVINCIAL DE

ACOBAMBA PROVINCIA DE HUANCAVELICA”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO

ACADÉMICO DE BACHILLER EN INGENIERÍA DE SISTEMAS

INSTITUCIÓN : ESCUELA PROFESIONAL DE INGENIERÍA

DE SISTEMAS

LUGAR DE EJECUCIÓN : PROVINCIA DE ACOBAMBA - HUANCAVELICA

PERIODO DE PRÁCTICA : 03 MESES

FECHA DE INICIO : 09 DE AGOSTO DEL 2021

FECHA DE CULMINACIÓN : 09 DE NOVIEMBRE DEL 2021

PRESENTADO POR : MANCILLA HUAMAN YESENIA

ASESOR : Dr.: RAFAEL WILFREDO ROJAS BUJAICO

PAMPAS – TAYACAJA

2021
 UNIVERSIDAD NACIONAL DE HUANCAVELICA

(Creada por ley N° 25265)

FACULTAD DE INGENIERÍA ELECTRÓNICA - SISTEMAS

ÁREA DE PRÁCTICAS PRE-PROFESIONALES

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“CABLEADO ESTRUCTURADO DE RED DE DATOS DEL

CUARTO PISO DE LA MUNICIPALIDAD PROVINCIAL DE

ACOBAMBA PROVINCIA DE HUANCAVELICA”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO

ACADÉMICO DE BACHILLER EN INGENIERÍA DE SISTEMAS

INSTITUCIÓN : ESCUELA PROFESIONAL DE INGENIERÍA

DE SISTEMAS

LUGAR DE EJECUCIÓN : PROVINCIA DE ACOBAMBA - HUANCAVELICA

PERIODO DE PRÁCTICA : 03 MESES

FECHA DE INICIO : 09 DE AGOSTO DE 2021

FECHA DE CULMINACIÓN : 09 DE NOVIEMBRE DE 2021

PRESENTADO POR : MANCILLA HUAMAN YESENIA

ASESOR : Dr.: RAFAEL WILFREDO ROJAS BUJAICO

PAMPAS – TAYACAJA

2021
El siguiente trabajo está dedicado a mis
padres quienes han sido mi gran apoyo
incondicional en todo momento, quienes me
ayudaron a culminar satisfactoriamente este
trabajo, el cual fue llevado a cabo con mucho
esfuerzo y dedicación.
 AGRADECIMIENTO
A Dios por la vida, por regalarme el don de salir adelante pese a las muchas dificultades
por ayudarme a crear nuevas ideas, fortalecer mi capacidad intelectual, por llenarme de
aprendizajes vividos llenos de sabiduría y superación en momentos difíciles.

A mi familia en especial a mis padres y hermanos por haberme inculcado valores, por
apoyarme a seguir adelante guiándome por el buen camino de conseguir un buen futuro.
A los docentes por ser guía de esta etapa de formación académica profesional como
estudiante, por enseñarme saberes aprendidos y practicados por ellos, por inculcarme a
seguir adelante en la vida, por enseñarme que un error lo tenemos todos pero que con
ayuda de ellos y voluntad mía superaría los obstáculos y por despejar mis dudas.

Al área de informática de la Municipalidad Provincial de Acobamba, por haber aceptado el

desarrollo de mis de prácticas pre-profesionales y permitir demostrar mis conocimientos
adquiridos en las aulas de la misma casa de estudios.
 INTRODUCCION
El presente informe de prácticas pre-profesionales realizado en el área de Informática de la
Municipalidad provincial de Acobamba Departamento de Huancavelica, consta sobre la
implementación del cableado estructurado de red de datos del cuarto piso de la
Municipalidad Provincial de Acobamba.

El presente informe está enfocado en desarrollar, diseñar un sistema para el área de

Secretaria Docente, que será implementado dentro de un ERP de la Facultad de Ingeniería
Electrónica y Sistemas.

El objetivo de este Sistema de Proceso Operativo es de organizar, minimizar las

actividades físicas es decir automatizar procesos primordiales de dicha área como el de
generar y emitir documentos como oficios, solicitudes, cartas y memorandos, este se basa
en un modelo único de formato para la creación de las mismas, dicho modelo de
documentos serán usados en las distintas áreas de la Escuela profesional de Ingenieri de
Sistemas, a la vez cuenta con un registro de estudiantes egresados de la Escuela
Profesional de Ingenieria de Sistemas.

El presente informe se detalla de manera secuencial y por capítulos:

El Capítulo I, presenta los datos de la institución donde se realizó las practicas pre
profesionales.
El Capítulo II, presenta el plan que se siguió durante la realización del sistema.
El Capítulo III, describe de todo el marco teórico consultado y utilizado para el buen
desarrollo de las tareas planeadas.
El Capítulo IV, presenta la descripción en detalle de cada una de las actividades y tareas
ejecutadas señalando los procedimientos desarrollados.
El Capítulo V, presenta la descripción de los aportes y propuestas que se ejecutaron en la
entidad.
En el Capítulo VI, Se plasma las dificultades o limitaciones que se tuvo en el desarrollo
del trabajo realizado.
 CAPITULO I

GENERALIDADES DE LA ENTIDAD
En este capítulo se detalla la información respecto a la institución, una breve descripción
de la Municipalidad Provincial de Acobamba, también se detallará la información
necesaria del área donde se realizó las prácticas pre profesionales.
1.1. DATOS GENERALES:
 NOMBRE DE LA INSTITUCION
Municipalidad Provincial de Acobamba
 NOMBRE DEL AREA DE PRACTICAS
Área de Tecnología de Información y Sistemas

1.2. ACERCA DE LA MUNICIPALIDAD PROVINCIAL DE SISTEMAS

La facultad de Ingeniería Electrónica –Sistemas de la Universidad Nacional de
Huancavelica es un órgano público, académico del más alto nivel de formación
profesional, autónoma, de carácter humanístico, científico y tecnológico y de
configuración democrática. Que tienen sus núcleos operativos en las Escuelas
Profesionales, Unidades de Investigación, Postgrado y de Extensión Cultural y
Proyección Social. Dedicándose con sentido crítico y creativo al estudio,
investigación, difusión del saber de las tecnologías y la cultura universal:

La facultad de Ingeniería Electrónica – Sistemas cuentan con las siguientes escuelas:

 Escuela Profesional de Ingeniería Electrónica

  Escuela Profesional de Ingeniería de Sistemas

La Facultad de Ingeniería Electrónica – Sistemas de la Universidad Nacional de

Huancavelica se rige por la Constitución Política del Perú, la ley Universitaria
23373; la ley de la creación 25265, y la Resolución Nº 698-R-UNH que la crea como
Facultad con sede en la provincia de Tayacaja; así como el Estatuto de la
Universidad Nacional de Huancavelica y los Reglamentos Internos.

1.3. MISION
Somos una facultad, conformada por docentes, estudiantes y graduados, con alto
nivel académico y científico, que practicamos el cogobierno dentro de un espíritu
democrático.

Formamos ingenieros competitivos, con sentido humanístico y crítico que lideran el

desarrollo. Mediante la investigación, generamos conocimientos y tecnología de
avanzada, los cuales solucionan los problemas de la región y del país, y son
globalmente compartidos.

Nuestro desarrollo es sostenible, y nos involucramos en la sociedad de nuestro

entorno mediante la extensión cultual y la proyección social, contribuyen a mejorar
la calidad de vida.

Practicamos la solidaridad, respeto, equidad, trabajo en equipo, puntualidad,

honestidad, responsabilidad, sentido crítico, identidad y la cultura de la confianza.

1.4. VISION
La facultad de Ingeniería Electrónica- Sistemas es líder, innovadora, competitiva,
humanista, protagonista del desarrollo regional y nacional, integra la red de
universidades, mediante convenios e intercambios nacionales e internacionales de
alumnos y docentes, predispuestas al cambio, con docentes de alto nivel académico,
que garantiza la excelencia académica, orientada al desarrollo sostenible, incidiendo
en la conversación del medio ambiente. Genera conocimientos científicos y
tecnológicos en base a la investigación, acorde a los requerimientos de la sociedad y
de la impresa. Tiene capacidad auto gestionada y se gobierna democráticamente.

Sus egresados son competitivos con valores éticos, insertándose fácilmente al

mercado laboral.
1.5. OBJETIVOS ESTRATÉGICOS DE LA FIES
1.5.1. Objetivo General:
Consolidar el sistema científico – tecnológico del área de ingeniería
electrónica y sistemas y su vinculación con la realidad productiva y social, en
armonía con el ambiente.

1.5.2. Objetivos Específicos:

Formar profesionales científicos, tecnológicos y humanistas competitivos que
exigen los sectores productivos y el entorno.

Optimizar y garantizar la formación profesional de los estudiantes en base a

servicios de bienestar, infraestructura, equipamiento y recursos financieros
que contribuyen con su formación integral.

Mejorar la gestión y gobierno asegurando la gobernabilidad con calidad de

servicio, en la formación profesional, investigación, extensión y proyección
social.

1.6. UBICACIÓN DE LA FACULTAD DE INGENIERIA ELECTRONICA

SISTEMAS
1.6.1. UBICACION POLITICA
 DISTRITO
Pampas
 PROVINCIA
Tayacaja
 DEPARTAMENTO
Huancavelica
1.6.2. UBICACIÓN GEOGRAFICA
1.7. ORGANIGRAMA ORGANIZAIONAL DE LA FACULTAD DE INGENIERIA
ELECTRONIA Y SISTEMAS
1.8. FUNCIONES DE LA FACULTAD DE INGENIERIA ELECTRONICA Y
SISTEMAS
Consolidar el sistema científico – tecnológico del área de ingeniería electrónica y
sistemas y su vinculación con la realidad productiva y social, en armonía con el
ambiente.

Formar profesionales científicos, tecnológicos y humanistas competitivos que exigen

los sectores productivos y el entorno.

Optimizar y garantizar la formación profesional de los estudiantes en base a servicios

de bienestar, infraestructura, equipamiento y recursos financieros que contribuyen
con su formación integral.

Mejorar la gestión y gobierno asegurando la gobernabilidad con calidad de servicio,

en la formación profesional, investigación, extensión y proyección social.

1.9. FINALIDADES DE LA FACULTAD DE INGENIERIA ELECTRONICA Y

SISTEMAS
1.10. DESCRIPCION DEL AREA DE SECRETARIA DOCENTE
El área donde se realizó las practicas pre profesionales, es el área de Secretaria
docente, en el cual se desarrolló un sistema de diseño e implementación de tramite
documentario para dicha área.

El área esta encargad de prestar servicios

1.10.1. RESPONSABLE DEL AREA DE SECRETARIA DOCENTE

Apellidos y Nombres: Mg. Julio Elvis Valero Cajahuanca

Cargo: Jefe del Área de Prácticas Pre Profesionales
Correo: valerocajahuanca@hotmail.com
Teléfono: 950892915
1.10.2. FUNCIONES
 CAPITULO II

PLAN DE ACTIVIDADES DE PARCTICAS PRE PROFESIONALES

Para la implementación del sistema durante las practicas pre profesionales se planteó lo

siguientes objetivos, metas y actividades que a continuación se describen.

2.1. OBJETIVOS
2.1.1. OBJETIVO GENERALE
Desarrollar e implementar un sistema que permita administrar la información
y disminuir el tiempo del trámite documentario en el Área de Secretaria
Docente de la Facultad de Ingeniería Electrónica y Sistemas.
2.1.2. OBJETIVOS ESPECIFICOS
 Recopilar información para realizar el análisis del sistema.

 Diseñar la interfaz del usuario siendo este interactivo a la vez programar

el código fuente.

 Definir los requerimientos funcionales y no funcionales para la

elaboración del sistema

 Realizar las pruebas para el adecuado funcionamiento del sistema.

 Mejorar los procesos del trámite documentario en el área de Secretaria

Docente con la implementación del sistema.
2.2. METAS
Entre las metas trazadas en el desarrollo del sistema se fijaron los siguientes:
  Realizar entrevistas personales al jefe encargado del área para obtener los

requerimientos necesarios del sistema.

 Cumplir con los objetivos durante el plazo establecido según el cronograma

de actividades.

 Construir una base de datos adecuado al sistema para su correcto

funcionamiento.

 Implementar el sistema en el área de Secretaria Docente, efectuando sus

funciones con total normalidad.

2.3. CRONOGRAMA DE ACTIVIDADES

FECHA DE INICIO : 06 de setiembre del 2019

FECHA DE TERMINO : 06 de diciembre del 2019

HORARIO :Lunes a Viernes de 3.00 pm a 6.30 pm

2.3.1. CRONOGRAMA DE ACTIVIDADES

Tabla 1: Cronograma de actividades para la elaboración del sistema.

N ACTIVIDADES 2019
º SETIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE
2 3 4 1 2 3 4 1 2 3 4 1
S S S S S S S S S S
E S S E E E E E E E E E
M E E M M M M M M M M M
M M

01 Determinación de los X X
requerimientos del
sistema.
02 Diseño de la base de X X X X X
datos y la interfaz del
sistema.
03 Desarrollo del X X X X X
sistema.
04 Prueba de X X
 funcionalidad del
sistema.
05 Implementación y X X
mantenimiento del
sistema.

2.4. METODOLOGIAS
Para el desarrollo del presente sistema se empleó la metodología RUP(Rational
Unified Process), por ser un proceso que integra las mejores prácticas de desarrollo
del software a través de la definición de procesos, flujos de actividades, roles, guías,
documentos patrón, ejemplos y métricas. Las fases a utilizar de esta metodología son
las fases de inicio, elaboración, construcción y transición, para el cumplimiento de
estas fases se utilizaron las siguientes disciplinas:

 Modelado de negocio: Se Analizará y entenderá las necesidades del área para

el cual se está desarrollando el software. Es decir, se diseñará para el área de
Secretaria Docente, se analizará las necesidades del área para su posterior
mejora a través del diseño que se planteará.
 Requisitos: Se identifica todos los requisitos necesarios para la construcción y
funcionalidad del sistema.
 Análisis y diseño: Se traslada los requisitos analizados anteriormente a un
sistema automatizado y desarrollar una arquitectura para el sistema.
 Implementación: Se realizará la implementación del sistema en la FIES,
parael área de Secretaria Docente.
 Pruebas: Se realizará las pruebas del sistema para asegurarse de que el
comportamiento requerido es correcto y que todo lo solicitado está presente.

2.5. INSTRUMENTOS, EQUIPOS Y HERRAMIENTAS

Para que la implementación del sistema se realice con normalidad se requirió el uso
de los siguientes materiales:

a) EQUIPOS
 Laptop LENOVO,(Procesador Intel Core i 5, RAM 5 GB, Se utilizó
para el desarrollo y elaboración del Software.
  Escáner: Se utilizó para escanear los documentos de Secretaria
Docente.
 USB 16 GB: Utilizado para trasladar información, software e
instaladores.
b) SFTWARE
Lenguaje de programación
 Visual Basic 2012

Gestor de base de datos

 SQL SERVER 2012

Otros

 Google Chrome
c) MATERIALES BIBLIOGRAFICOS, DE CONSULTAS Y DE
ESCRITORIO
Se desarrolló varios modelos, diseños, estructuras en forma física y/o manual,
etapas que pasaron por modificación en el momento del desarrollo, por ello se
usaron diferentes materiales:
 Libros y tutoriales.
 Videos y audios.
 Internet.
 MOF (Reglamento de Organización y Funciones) EPIS.
 ROF (Reglamento de Organización y Funciones ) EPIS.
 Entre otros.
 CAPITULO III

DOCUMENTACION BIBLIOGRAFICA

En este capítulo se realizará una breve descripción de todo el marco teórico utilizado y

consultado para el uso correcto y normal desarrollo del sistema.

3.1. SOFTWARE Y SISTEMAS

3.1.1. DEFINICION DE SOFTWARE
Es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados. Que forman parte de las operaciones de un
sistema de computación.

Considerando esta definición, el concepto de software va más allá de los

programas de computación en sus distintos estados: código fuente, binario o
ejecutable; también su documentación, los datos a procesar e incluso la
información de usuario forman parte del software: es decir, abarca todo lo
intangible, todo lo (no físico) relacionado.

El concepto de leer diferentes secuencias de instrucciones(programa) desde la

memoria de un dispositivo para controlar los cálculos fue introducido por
Charles Babbage como parte de su máquina diferencial.

3.1.2. DEFINICION DE UN SISTEMA

Un sistema es un conjunto de elementos relacionados entre sí que funciona

como un todo.
 Los elementos que componen un sistema pueden ser variados, como una serie
de principios o reglas estructuradas sobre una materia o teoría. Por ejemplo:
un sistema político o un sistema económico.

La palabra sistema no se debe confundir con el término aparato, ambas tienen

significados y usos diferentes.

3.1.3. DEFINICION DE UN SISTEMA DE INFORMACION

Un sistema de información (SI) es un conjunto de elementos orientados al

tratamiento y administración de datos e información, organizados y listos para

su uso posterior, generados para cubrir una necesidad o un objetivo. Dichos

elementos formarán parte de alguna de las siguientes categorías:

 Personas

 Actividades o técnicas de trabajo

 Datos

 Recursos materiales en general (recursos informáticos y de comunicación,

generalmente, aunque no necesariamente).

Todos estos elementos interactúan para procesar los datos (incluidos los
procesos manuales y automáticos) y dan lugar a información más elaborada,
que se distribuye de la manera más adecuada posible en una determinada
organización, en función de sus objetivos.

kmfdjjcuuhiudhudvdhbcg

yhhfyy
3.1.4. LENGUAJE UNIFICADO DE MODELADO
El Lenguaje Unificado de Modelado(UML) es un lenguaje de modelado
visual de propósito general que es usado para especificar, visualizar, construir
y documentar los artefactos de un sistema software.

El UML captura información acerca de la estructura estática y el

comportamiento dinámico de un sistema. Un sistema es modelado como una
colección de objetos discretos que interactúan para desempeñar un trabajo
que en última instancia beneficia a un usuario externo. La estructura estática
define el tipo de objetos importantes para un sistema y su implementación, así
como la relación entre los objetos.

El comportamiento dinámico define la historia de los objetos sobre el tiempo

y la comunicación entre objetos para culminar metas.

Partiendo del hecho las diferencias entre los métodos disminuyen y que la
guerra de métodos no hace progresar la tecnología de objetos, Jim Rumbaugh
y Grady Booh decidieron a finales de 1994, unificar sus trabajos en un
método único: El Método Unificado (The Unified Method). Un año más tarde
se les unió Iván Jacobson. Los tres autores fijaron cuatro objetivos:

 Representar sistemas complejos ( más allá de un solo programa) por

conceptos de objetos.
 Establecer una relación explicita entre los conceptos y los artefactos
ejecutables.
 Tener en cuenta los factores de escala inherentes a los sistemas complejos
y críticos.
 Crear un lenguaje de modelado utilizable tanto por los humanos como por
las maquinas.

3.1.5. MODELOS
Un modelo es la representación en un cierto medio de algo en el mismo u otro
medio. El modelo captura los aspectos importantes del ente que será
modelado desde un cierto punto de vista, simplificando u omitiendo el resto.
 Modelo de Casos de Uso: el modelo de casos de uso permite que los
desarrolladores de software y los clientes lleguen a un acuerdo sobre los
requisitos. Contiene actores, casos de uso y sus relaciones.

Modelo de Análisis: el modelo de análisis se representa mediante un sistema

de análisis que denota el paquete de más alto nivel del modelo. La utilización
de otros paquetes de análisis es por tanto una forma de organizar el modelo de
análisis en partes más manejables que representan abstracciones de
subsistemas y posiblemente capas completas del diseño del sistema.

Modelo de Diseño: El modelo de diseño es un modelo de objetos que

describe la realización física de los casos de usos centrándose en cómo los
requisitos funcionales y no funcionales, junto con otras restricciones
relacionadas con el entorno de implementación, tienen impacto en el sistema
a considerar.

3.1.6. DIAGRAMAS
Un diagrama es la representación gráfica de un conjunto de elementos,
usualmente representado como un grafo conectado de vértices (elementos) y
arcos(relaciones).

a) DIAGRAMAS DE CASOS DE USO

Un diagrama de casos de uso es un diagrama que muestra un conjunto
de casos de uso, actores y sus relaciones. Los mismos sirven para
especificar la funcionalidad y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros sistemas. O lo que es
igual, un diagrama que muestra la relación entre los actores y los casos
de uso dentro de un sistema. A continuación, se explican los elementos
del diagrama de caso de uso con detalle:
 Casos de usos: Un caso de uso describe un conjunto de
secuencias, donde cada una representa la interacción de los
elementos externos al sistema (Actores) con el mismo sistema.
 Actor (es): Un actor es la representación de un conjunto
coherente de roles que los usuarios de los casos de uso jueguen
cuando interactúan con estos. Por lo general, representan el
 papel desempeñado por una persona, un dispositivo, un objeto e
incluso otro sistema que interactúa con el sistema propuesto.
 Relación de Dependencia: Es una conexión de uso que indica
que cualquier cambio en un elemento puede afectar a otro
elemento que la utiliza, pero no necesariamente de modo
inverso. Esta es representada por una flecha, de línea no
continua, orientada hacia el elemento del que se depende.
 Relación de Generalización: Es la relación que existe entre un
elemento general y un caso específico de ese mismo elemento.
La generalización significa que los objetos hijos se pueden
emplear en cualquier lugar donde pueda aparecer el padre, más
no a la inversa. Esta relación se representa por una flecha
continua con punta vacía orientada hacia el padre.
 Relación de Asociación: Se entiende por la relación estructural
que indica que los objetos de un elemento están conectados con
los objetos de otro. Una asociación se representa por una línea
continua que conecta las clases.
3.1.7. ACTIVIDADES DE UN SISTEMAS DE INFORMACION
Los Sistemas de Información realizan las diversas actividades principales
haciendo uso de la computadora, lo cual permite un mejor desempeño de los
sistemas de información en las organizaciones públicas y privadas.
Las actividades básicas de un sistema de información son las siguientes:
 Entrada de datos: Proceso mediante el cual se captura y prepara datos
para su posterior procesamiento. Las entradas pueden ser manuales o
automáticas. Las manuales se realizan por el operador o el usuario, y las
automáticas surgen de otros sistemas.
 Almacenamiento de datos: El almacenamiento es una de las actividades
o capacidades más importantes que tiene una computadora, ya que a
través de esta propiedad el sistema puede recordar la información
guardada en la sección o proceso anterior.
 Procesamiento de datos: Es la capacidad de efectuar operaciones con los
datos guardados en las unidades de memoria. Durante este procesamiento
se evidencia lo siguiente:
  Aumenta, manipula y organiza la forma de los datos.
 Analiza y evalúa su contenido.
 Selecciona la información para ser usada en la toma de decisiones, y
constituye un componente clave en el sistema de información
gerencial.
 Salida de datos: Actividad que permite transmitir información útil y
valiosa a los usuarios finales.

3.1.8. ANALISIS Y DISEÑO DEL SISTEMA

El análisis y diseño del sistema se refiere al proceso de explorar la situación
de la organización con el propósito de mejorarla con métodos y
procedimientos más adecuados, en el caso de este sistema se utilizó el
Lenguaje de Modelado Unificado (UML).
El análisis de sistemas, es el proceso de clasificación e interpretación de
hechos, diagnósticos de problemas y empleo de la información para
recomendar mejoras al sistema. El análisis especifica que es lo que el sistema
debe hacer y cómo se va realizar.
3.1.9. DESARROLLO DEL DISEÑO DEL SISTEMA
Es un proceso que consta de las siguientes actividades:

a) INVESTIGACIÒN PRELIMINAR

La solicitud para recibir ayuda de un sistema de información puede

originarse por varias razones; sin importar cuales sean éstas, el
 proceso se inicia siempre con la petición de una persona
(administrador, empleado, o especialista en sistemas).
Cuando se formula la solicitud, comienza la primera actividad: la
investigación preliminar. Esta tiene tres partes: Aclaratoria de la
solicitud, estudio de factibilidad y aprobación de la solicitud.
b) ACLARACION DE LA SOLICITUD
Muchas solicitudes que provienen de empleados y usuarios no están
formuladas de manera clara. Por consiguiente, antes de considerar
cualquier investigación de sistemas, la solicitud de proyecto debe
examinarse para determinar precisión lo que el solicitante desea. Si el
solicitante pide ayuda sin saber qué es lo que está mal o donde se
encuentra el problema, la aclaración del mismo se vuelve más fácil y
más complicado.
c) ESTUDIO DE FACTIBILIDAD
El sistema solicitado debe ser factible en tres aspectos:
 Factibilidad técnica: El trabajo para el proyecto, ¿puede
realizarse con el equipo actual, la tecnología existente de software
y el personal disponible?, y si se cuenta con la tecnología ¿cuál es
la posibilidad de desarrollarla?
 Factibilidad económica: Al crear el sistema, ¿los beneficios que
se obtienen serán suficientes para aceptar los costos?, ¿los costos
asociados con la decisión de no crear el sistema son tan grandes
que se debe aceptar el proyecto.
 Factibilidad operacional: Si se desarrolla e implanta, ¿será
utilizado el sistema?, ¿existirá cierta resistencia al cambio por
parte de los usuarios?
d) CONFORMIDAD DE LA SOLICITUD
El diseño de un sistema de información produce los detalles que
establecen la forma en la que el sistema cumplirá con los
requerimientos identificados durante la fase de análisis.
Los especialistas en sistemas se refieren, con frecuencia, a esta etapa
como diseño lógico en contraste con la de desarrollo de software a la
que denominan diseño físico.
 Los analistas de sistemas comienzan el proceso de diseño
identificando los reportes y demás salidas que debe producir el
sistema. Hecho lo anterior se determinan con toda precisión los datos
específicos para cada reporte y salida.
El diseño de un sistema también indica los datos de entrada, aquellos
que serán calculados y los que deben ser almacenados. Los
documentos que contienen las especificaciones de diseño representan
a éste de muchas maneras (diagramas, Tablas, y símbolos especiales).
La información detallada del diseño se proporciona al equipo de
programación para comenzar la fase de desarrollo de software.
3.2. BASE DE DATOS
3.2.1. DEFINICION DE BASE DE DATOS
Una base de datos es una colección de datos relacionados. Por datos, se
requiere decir, hechos conocidos que puedan registrarse y que tienen un
significado implícito. Una base de datos tiene las siguientes propiedades
implícitas:

Una base de datos representa algunos aspectos del mundo real, en ocasiones
denominado mini mundo o Universo del Discurso.

Los cambios en el mini mundo se reflejan en la base de datos. Una base de

datos es una colección de datos lógicamente coherentes, con algunos
significados inherentes. Un conjunto aleatorio de datos no puede considerarse
como una base de datos.
Las bases de datos se diseñan, construyen y pueblan con datos para un
propósito específico. Está destinada a un grupo de usuarios y tiene algunas
aplicaciones preconcebidas de interés para dichos usuarios.
3.2.2. SISTEMA DE GESTOR DE BASE DE DATOS
Un gestor de base de datos o sistema de gestión de base de datos (SGBD o
DBMS) es un software que permite introducir, organizar y recuperar la
información de las bases de datos; en definitiva, administrarlas. El propósito
general de los sistemas de gestión de bases de datos es el de manejar de
manera clara, sencilla y ordenada un conjunto de datos que posteriormente se
convertirán en información relevante para una organización.
 Algunas operaciones básicas que podemos realizar con un gestor de bases de
datos son:
 crear una base de datos,
 introducir datos en una base de datos,
 modificar información existente,
 eliminar información de la base de datos,
 buscar un dato en concreto,
 clasificar los registros de la base de datos,
 copiar el contenido de una base de datos en otra,
 realizar consultas sobre el contenido de una base de datos,
 realizar cálculos basándose en el contenido de una base de datos,
 imprimir los datos existentes,
 eliminar una base de datos,
 asignar nombre a una base de datos.
3.2.3. PRINCIPALES COMPONENTES DE UNA BASE DE DATOS
 Tablas: son el corazón de la Base de datos y aparecen en una hoja
electrónica formada por filas y columnas. La fila contiene una voz de la
Base de datos, mientras que la columna contiene cada uno de los detalles.
 Consultas: son herramientas que sirven para eliminar todos los datos que
no interesan haciendo aparecer únicamente aquellos que interesan.
 Máscaras o formularios: permiten la visualización y la gestión de los
datos contenidos en las tablas y en las consultas. Normalmente
representan la interface principal entre el programa y el usuario para que
de este modo resulte más fácil la introducción de los datos.
 Report o informes: recopilan los datos de las tablas o consultas para
permitir su impresión o análisis, facilitando la individualización de los
datos más importantes.
 Macros: automatizan las funciones de la base de datos.
3.2.4. LENGUAJE ESTRUCTURADO DE CONSULTAS SQL
El lenguaje de consulta estructurado o SQL (por sus siglas en
inglés Structured Query Language) es un lenguaje declarativo de acceso a
bases de datos relacionales que permite especificar diversos tipos de
operaciones en ellas. Una de sus características es el manejo del álgebra y el
 cálculo relacional que permiten efectuar consultas con el fin de recuperar de
forma sencilla información de interés de bases de datos, así como hacer
cambios en ella.

3.2.5. MICROSOFT SQL SERVER

Microsoft SQL Server es un sistema de gestión de base de datos relacional,
desarrollado por la empresa Microsoft.

El lenguaje de desarrollo utilizado(por línea de comandos o mediante la

interfaz gráfica de Management Studio) es Transact-SQL, una
implementación del estándar ANSI de lenguaje SQL, utilizado para
manipular y recuperar datos(DML), crear tablas y definir relaciones entre
ellas(DDL).
3.3. PROGRAMACIÒN ORIENTADA A OBJETOS
3.3.1. DEFINICIÓN DE LA PROGRAMACIÓN ORIENTADA A OBJETOS
La programación orientada a objetos (POO) es un paradigma de lenguaje de
programación que emplea el concepto de objetos en sus interacciones con el
fin de desarrollar programas informáticos. En otras palabras, esta
programación utiliza objetos como elementos fundamentales en la
construcción de la solución.
Emplea técnicas de programación como: herencia, cohesión, abstracción,
polimorfismo, acoplamiento y encapsulamiento.
La POO es diferente de la programación estructurada tradicional, en la que
los datos y los procedimientos están separados y sin relación, ya que lo único
que se busca es el procesamiento de unos datos de entrada para obtener otros
de salida.
Los programadores que emplean POO, definen primero los objetos para luego
enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.
3.3.2. CARACTERÌSTICAS ESPECÌFICAS DE LA PROGRAMACIÒN
ORIENTADA A OBJETOS
Los lenguajes de programación orientada a objetos (como Visual Basic, C++,
C# y Java) se caracterizan por 4 conceptos clave: Abstracción, encapsulación,
herencia y polimorfismo, que son compatibles con este aspecto natural de
identificación y clasificación de objetos.
a) ABSTRACCIÒN
La abstracción a objetos expresa las características esenciales de un
objeto, las cuales distinguen al objeto de los demás (la abstracción
genera la ilusión de simplicidad). Además de distinguir entre los
objetos provee límites conceptuales. Entonces se puede decir que la
encapsulación separa las características esenciales de las no esenciales
dentro de un objeto. Si un objeto tiene más características de las
necesarias los mismos resultarán difíciles de usar, modificar, construir
y comprender.
b) ENCAPSULAMIENTO
La encapsulación facilita la compresión de los grandes programas; la
ocultación de datos les hace más eficaces. Los objetos pueden
 interactuar con otros objetos sólo a través de los atributos y métodos
del objeto que se muestran públicamente. Cuantos más atributos y
métodos se muestren públicamente, más difícil será modificar la clase
sin que ello afecte al código que utiliza la clase. Una variable oculta se
podría cambiar de un long a un double, sin que ello afecte al código
que utilicen los objetos creados (instanciados) de esa clase.

El programador solo se debería preocupar por los métodos en la clase

que han tenido acceso a esa clase, en lugar de por todos los sitios en el
programa que un objeto ha instanciado desde los que se puede llamar
a la clase.
c) HERENCIA
Proporciona dos ventajas evidentes a los programadores. La primera,
y más importante, es que permite crear jerarquías que expresen las
relaciones entre los diferentes tipos. Imagine que tiene dos clases,
Cuenta Ahorro y Cuenta Corriente, que proceden de la clase principal
Cuenta. Si tiene una función que necesite una clase Cuenta como
argumento, podrá pasarle una Cuenta Ahorro o una Cuenta Corriente,
ya que ambas clases son de tipos de Cuenta.
d) POLIMORFISMO
Polimorfismo significa, fundamentalmente, que las clases pueden
tener el mismo comportamiento, pero implementarse de distintas
maneras. Esto resulta muy útil en términos de programación, ya que
permite trabajar con tipos de objetos genéricos cuando lo que interesa
no es cómo implementa cada clase las funciones.
3.3.3. VENTAJAS DE LA PROGRAMACIÒN ORIENTADA A OBJETOS
La primera ventaja del concepto de objetos es que todo el código que tiene
algo que ver con las naves espaciales se encuentra en un solo lugar. Otra
ventaja es que los objetos pueden poseer atributos inherentes de la clase a la
que pertenecen, por ejemplo, naves espaciales y asteroides podrían tener
ambos una posición XY porque todos los objetos que pertenecen a la clase de
los objetos en movimiento tiene una posición XY. Escribir códigos es más
fácil porque se pueden conceptualizar como algo que le sucede a un objeto.
 Otra ventaja es que POO hace que los programas grandes sean más
manejables. Si todas las ventanas pertenecen a una jerarquía de clases de
ventanas y todo el código que se refiere a una ventana particular está dentro
de esa ventana, todas las manipulaciones de ventana se pueden escribir como
una sencilla transferencia de mensajes.

3.4. LENGUAJE DE PROGAMACIÒN VISUAL STUDIO

Visual Studio.NET es un entorno de desarrollo integrado que nos ayuda a diseñar,
desarrollar, depurar e implantar con rapidez soluciones basadas en el.NET
Framework. Podemos acceder a un conjunto común de herramientas, diseñadores y
editores desde cualquiera de los lenguajes de programación de Visual Studio.NET.
podemos crear aplicaciones Windows Forms y Web Forms que integren datos y
lógica de negocio.

En palabras más específicas, Visual Studio es un conjunto completo de herramientas

de desarrollo para la generación de aplicaciones web ASP.NET, Servicios Web
XML, aplicaciones de escritorio y aplicaciones móviles. Visual Basic, Visual C# y
Visual C++ utilizan todos el mismo entorno de desarrollo integrado (IDE), que
habilita el uso compartido de herramientas y facilita la creación de soluciones en
varios lenguajes. Asimismo, dichos lenguajes utilizan las funciones de .NET
Framework, las cuales ofrecen acceso a tecnologías clave para simplificar el
desarrollo de aplicaciones web ASP y Servicios Web XML.
3.5. PRCESO UNIFICADO DE DESARROLLO DE SOFTWARE (RUP)
3.5.1. DEFINICIÒN DEL PROCESO DE DESARROLLO DE SOFTWARE
El proceso Unificado es un proceso de desarrollo de software. Un proceso de
desarrollo de software es el conjunto de actividades necesarias para
transformar los requisitos de un usuario en un sistema de software. Sin
embargo, el proceso Unificado es más que un simple proceso; es un marco de
trabajo genérico que puede especializarse para una gran variedad de sistemas
de software, para diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de
proyecto.
El proceso Unificado está basado en componentes, lo cual quiere decir que el
sistema software en construcción está formado por componentes de software
interconectados a través de interfaces bien definidas.
El proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para
preparar todos los esquemas de un sistema software; de hecho, UML es una
parte esencial del proceso Unificado.
El proceso unificado de desarrollo nace en vista de la necesidad de crear un
estándar para el desarrollo de software con la finalidad de satisfacer la
creciente demanda de sistemas más grandes, modernos y poderosos y que a su
vez permita disminuir el tiempo de desarrollo de los mismos.
3.5.2. PRINCIPIOS BASICOS DEL PROCESO UNIFICDO DE
DESARROLLO DE SOFTWARE
Los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres
frases claves: dirigidos por casos de uso, centrados en la arquitectura, iterativo
e incremental. Esto es lo que hace único al proceso Unificado. A continuación,
se explican los principios básicos del Proceso Unificado de Desarrollo de
Software:

a) PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO

Cuando un usuario utiliza el sistema, se lleva a cabo una interacción
que consiste en una secuencia de acciones (tanto por parte del usuario
como del sistema) que proporcionan al usuario un resultado de valor
importante para él.
 Un caso de uso es precisamente una interacción de ese tipo, que deriva
en que el sistema debe incluir un fragmento de funcionalidad para
proporcionar al usuario el resultado de valor esperado.
Por tanto, los casos de uso representan los requisitos funcionales del
sistema, es decir, las necesidades de los usuarios y de la organización
en donde se desplegará el sistema.
b) PROCESO CENTRADO EN LA ARQUITECTURA
La arquitectura del software sirve para poder contemplar el futuro
sistema desde varios puntos de vista antes de que se construya y
durante la construcción.
El concepto de arquitectura software incluye los aspectos estáticos y
dinámicos más significativos del sistema, es decir, especifica la forma,
estructura y comportamiento del sistema desde diversos puntos de
vista, todos ellos a un nivel de detalle que permita tener una idea
global clara sin perderse en detalles insignificantes que, precisamente,
no influyen en la arquitectura del sistema. De esta forma quedan
cubiertos los dos aspectos fundamentales del sistema.
3.5.3. CICLO DE VIDA DEL PROCESO UNIFICADO
El proceso unificado se repite a lo largo de una serie de ciclos que constituyen
la vida de un sistema. Cada ciclo consta de cuatro fases: inicio, elaboración,
construcción y transición.
En la ilustración 3, se puede visualizar las diferentes actividades: Requisitos,
Análisis, Diseño, Implementación y Prueba que tienen lugar sobre las 4 fases:
Inicio, Elaboración, Construcción y Transición.

Imagen N.ºJHJKLÑLKJHGFDGHHJKL
 Cada ciclo produce una nueva versión del sistema, y cada versión es un producto
preparado para su entrega; consta de un cuerpo de código fuente incluido en
componentes que puede compilarse y ejecutarse, además de manuales y otros
productos asociados. Sin embargo, el producto terminado no sólo debe ajustarse
a las necesidades de los usuarios, sino también a las de todos los interesados, es
decir, toda la gente que trabajará con el producto.
El producto terminado incluye los requisitos, casos de uso, especificaciones no
funcionales y casos de prueba.
Incluye el modelo dela arquitectura y el modelo visual (artefactos modelados
con el UML).

3.5.4. CARACTERISTICAS DE RUP

 Interactivo. Refinamiento sucesivo
 Controlado. Gestión de requisitos y control de cambios
 Construcción de modelos
 Centrado en arquitectura
 Desarrollo de software basado en componentes
 Conducido por los casos de uso
 Soporta técnicas OO (Orientadas a objetos) uso del UML
 Configurable
 Fomenta al control de calidad del software
 Soportado por herramientas
 Reconoce que las necesidades del usuario y sus requerimientos no se
pueden definir completamente al principio
 Permite evaluar tempranamente los riesgos en lugar de descubrir
problemas en la integración final del sistema. Reduce el costo del riesgo
a los costos de un solo incremento.
3.5.5. FASES DEL PROCESO UNIFICADO DE DESARROLLO DEL
SOFTWARE (RUP)
La metodología RUP, llamada así por sus siglas en inglés Rational Unified
Process, divide en 4 fases el desarrollo del software. Cada Fase tiene definido
un conjunto de objetivos y un punto de control especifico.

a) FASE DE INICIO
 Durante la fase de inicio se desarrolla una descripción del producto
final, y se presenta el análisis de negocio. Esta fase responde las
siguientes preguntas.
1) ¿Cuáles son las principales funciones del sistema para sus
usuarios más importantes?
2) ¿Cómo podría ser la arquitectura del sistema?

En estas fases se identifican y priorizan los riesgos más importantes.

Artefactos que típicamente sobreviven en esta fase.

 Un enunciado de los mayores requerimientos planteados

generalmente como casos de uso.
 Un boceto inicial de la arquitectura.
 Una descripción de los objetivos del proyecto.
 Una versión muy preliminar del plan del proyecto.
 Alcance del proyecto.
 Un documento de visión general.
 Modelo inicial de casos de uso.
b) FASE DE ELABORACION
Durante la fase de elaboración se especifican en detalle la mayoría de
los casos de uso del producto y se diseña la arquitectura del sistema.
 Las iteraciones en la fase de elaboración.
 Establecen una firme comprensión del problema a solucionar.
 Establecer la fundación arquitectural para el software.
 El cuerpo básico del software en la forma de un prototipo
arquitectural.
 Casos de prueba.
 Se realizan pruebas de riesgo.

La fase de elaboración finaliza con el hito de la arquitectura del ciclo

de vida, este hito se alcanza cuando el equipo de desarrollo y los
stakeholders llegan a un acuerdo sobre:

 Los casos de uso que describen la funcionalidad del sistema.

 La línea base de la arquitectura.
  Los mayores riesgos han sido mitigado.
c) FASE DE CONSTRUCCION
Durante la fase de construcción se crea el producto. La línea base de
la arquitectura crece hasta convertirse en el sistema completo.
Al final de esta fase, el producto contiene todos los casos de uso
implementados, sin embargo puede que no esté libre de defectos.
Los artefactos producidos en esta fase son:
 El sistema software.
 Los casos de prueba.
 Los componentes se desarrollan e incorporan al producto.
 Todo es probado para eliminar posibles errores y riesgos.

La fase de construcción finaliza con el hito de capacidad operativa

inicial, este hito se alcanza cuando el equipo de desarrollo y los
stakeholders llegan a un acuerdo sobre:

 El producto es estable para ser usado

 El producto provee alguna funcionalidad de valor.
 Todas las partes están listas para comenzar la transición.
d) FASE DE TRANSICIÒN
La fase de transición cubre el período durante el cual el producto se
convierte en la versión beta
Sin embargo, las características se agregan a un sistema que el usuario
se encuentra utilizando activamente (ambiente de desarrollo).
Los artefactos construidos en esta fase son el mismo que en la fase de
construcción. El equipo se encuentra ocupando fundamentalmente en
corregir y extender la funcionalidad del sistema desarrollado en la fase
anterior.
 El objetivo es realizar el lanzamiento del software desarrollado a
los usuarios.
 Enviar el producto a otros lados donde también se va a usar el
producto.
 Usuarios satisfechos.
 Verificación de gastos.
 La fase de transición finaliza con el hito de lanzamiento del producto
Este hito se alcanza cuando el equipo de desarrollo y los
stakeholders llagan a un acuerdo sobre:
 Se han alcanzado los objetivos fijados en la fase de inicio.
 El usuario está satisfecho.
3.6. METODOLOGIAS
3.6.1. DEFINICIÓN DE LENGUAJE UNIFICADO DE MODELADO (UML)
UML (Unified Modeling Language) es un lenguaje que permite modelar,
construir y documentar los elementos que forman un sistema software
orientado a objetos. UML entrega una forma de modelar cosas conceptuales
como lo son procesos de negocio y funciones de sistema, además de cosas
Concretas como lo son escribir clases en un lenguaje determinado, esquemas
de base de datos y componentes de software reusables. La estandarización de
un lenguaje de modelado es invaluable, ya que es la parte principal del
proceso de comunicación que requieren todos los agentes involucrados en un
proyecto informático. Si se quiere discutir un diseño con alguien más, ambos
deben conocer el lenguaje de modelado y no así el proceso que se siguió para
obtenerlo.

3.6.2. CARACTERISTICAS DEL LENGUAJE (UML)

 Desplegar los límites de un sistema, sus principales funciones mediante
casos de uso y actores.
 Representar la estructura estática de un sistema usando diagramas de
clases.
 Modelar los límites de un objeto con diagramas de estados
 Mostrar la arquitectura de la implementación física con diagramas
componentes y de emplazamiento o despliegue.
3.6.3. MODELADO
Un modelo es la representación en un cierto medio de algo en el mismo u otro
medio. El modelo captura los aspectos importantes del ente que será
modelado desde un cierto punto de vista, simplificando u omitiendo el resto.
Modelo de Casos de Uso: El modelo de casos de uso permite que los
desarrolladores de software y los clientes lleguen a un acuerdo sobre los
 requisitos. Contiene actores, casos de uso y sus relaciones.
Modelo de Análisis: El modelo de análisis se representa mediante un sistema
de análisis que denota el paquete de más alto nivel del modelo. La utilización
de otros paquetes de análisis es por tanto una forma de organizar el modelo de
análisis en partes más manejables que representan abstracciones de
subsistemas y posiblemente capas completas del diseño del sistema.
Modelo de Diseño: El modelo de diseño es un modelo de objetos que
describe la realización física de los casos de usos centrándose en cómo los
requisitos funcionales y no funcionales, junto con otras restricciones
relacionadas con el entorno de implementación, tienen impacto en el sistema
a considerar. Además, el modelo de diseño sirve de abstracción de la
implementación del sistema y es, de ese modo, utilizada como una entrada
fundamental de las actividades de implementación.
3.6.4. DIAGRAMAS
Los diagramas se utilizan para dar diferentes perspectivas del problema lo que
nos interesa representar en un determinado momento, también un diagrama es
la representación gráfica de un conjunto de elementos, usualmente
representado como un grafo conectado de vértices (elementos) y arcos
(relaciones).

a) DIAGRAMA DE CASOS DE USO

Un caso Diagrama de Casos de Uso puede existir tanto a nivel del
Modelo de Negocio como en el nivel de Modelo de Construcción del
Software. A nivel de Negocio muestra el Caso de Uso del Negocio
relacionado con los actores internos y externos de negocio. A nivel de
Sistema muestra la funcionalidad total del Sistema Software que se
construye. El Diagrama de Casos de Uso a nivel de Sistema permite
definir los privilegios del Sistema por actor, teniendo en cuenta aspectos
de auditoría al considerar el módulo de identificación, como obligatorio.
b) DIAGRAMAS DE CLASE
Es un diagrama que muestra un conjunto de clases, interfaces y
colaboraciones y las relaciones entre éstos. Los diagramas de clases
muestran el diseño de un sistema desde un punto de vista estático.
También se puede decir que es un diagrama que muestra una colección
de elementos (estáticos) declarativos.
Un diagrama de clases también puede contener interfaces, paquetes,
relaciones e instancias y se representa gráficamente mediante una
colección de nodos y arcos.

Por lo general, un diagrama de clases está compuesto por: clases,

interfaces, colaboraciones y relaciones de dependencia,
generalización y asociación.
 Clase: Una clase describe un conjunto de objetos con estructura
similar, su comportamiento y sus relaciones. Representa un
concepto dentro del sistema a ser modelado; las clases tienen
estructura de datos, comportamiento y relaciones con otros
elementos. Una clase es dibujada como un rectángulo sólido con
tres compartimentos separados por líneas horizontales. El primer
compartimiento contiene el nombre de la clase y otras
 propiedades generales de la clase. El segundo compartimiento
contiene los atributos de la clase. El tercer compartimiento
contiene la lista de operaciones de la clase.
 Interface: Una interface utiliza un tipo para describir el
comportamiento visible de una clase, de un componente o de un
paquete. Una interface es un estereotipo de un tipo. (Muller P,
1997) Pueden ser mostradas con un rectángulo que se identifica
con la palabra clave “interface” y que además tiene
compartimentos. La lista de operaciones soportadas por la
interface se coloca en el compartimiento de operaciones. El
comportamiento de sus atributos puede ser omitido debido a que
siempre estará vacío. Una interface también puede ser
representada con un círculo con el nombre de la interface
colocado debajo del símbolo. El círculo puede estar conectado
por una línea sólida con las clases que implementan la interfaz.
 Relación de dependencia: Una relación de dependencia se
establece entre clases cuando un cambio en el elemento
independiente del modelo puede requerir un cambio en el
elemento dependiente. Durante el análisis del sistema, los
diagramas de clases son utilizados para mostrar las partes
comunes y las responsabilidades de las entidades que proveen el
comportamiento del sistema. Durante el diseño del sistema,
capturan la estructura de la clase que forma la arquitectura del
sistema.
 Relación de asociación: Las relaciones de asociación permiten
especificar que objetos van a estar asociados con otro objeto
mediante un calificador. El calificador es un atributo o conjunto
de atributos de una asociación que determina los valores que
indican cuales son los que se asocian. Las asociaciones
representan relaciones estructurales entre clases y objetos. Una
asociación simboliza una información cuya duración de vida no
es relevante respecto a la dinámica general de los objetos
instancias de las clases asociadas. (Booh, Rumbaugh, Jacobson,
 1999).
 Relación de generalización: La generalización entre dos clases
consiste en considerar a una clase como superclase y a la otra
como la subclase. Puede haber más de una clase que se
comporte como subclase.
c) DIAGRAMS DE SECUENCIA
Un diagrama de Secuencia muestra una interacción ordenada según la
secuencia temporal de eventos. En particular, muestra los objetos
participantes en la interacción y los mensajes que intercambian
ordenados según su secuencia en el tiempo. El eje vertical representa el
tiempo, y en el eje horizontal se colocan los objetos y actores
participantes en la interacción, sin un orden prefijado. Cada objeto o
actor tiene una línea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se
pueden colocar etiquetas (como restricciones de tiempo, descripciones de
acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones
o activaciones a las que se refieren.

d) DIAGRAMA DE COLABORACION
Un Diagrama de Colaboración muestra una interacción organizada
basándose en los objetos que toman parte en la interacción y los enlaces
entre los mismos (en cuanto a la interacción se refiere). A diferencia de
los Diagramas de Secuencia, los Diagramas de Colaboración muestran
las relaciones entre los roles de los objetos. La secuencia de los mensajes
y los flujos de ejecución concurrentes deben determinarse explícitamente
mediante números de secuencia. Los diagramas de colaboración permiten
 mostrar mejor como se vinculan los objetos, a cambio de hacer más
difícil observar el orden de ejecución, pues enumeran los mensajes en
lugar de mostrar al tiempo como una dimensión, tal como lo hacen los
diagramas de secuencia.
e) DIAGRAMA DE OBJETOS

Los diagramas de objetos modelan las instancias de elementos contenidos

en los diagramas de clases. Un diagrama de objetos muestra un conjunto
de objetos y sus relaciones en un momento concreto. Los diagramas de
objetos se emplean para modelar la vista de diseño estática o la vista de
procesos estática de un sistema al igual que se hace con los diagramas de
clases, pero desde la perspectiva de instancias reales o prototípicas. Esta
vista sustenta principalmente los requisitos funcionales de un sistema.
Los diagramas de objetos permiten modelar estructuras de datos
estáticas.
f) DIAGRAMA DE ESTADOS

Se usan para representar gráficamente máquinas de estados finitos. Las

Tablas de Transiciones son otra posible representación. El Lenguaje
Unificado de Modelado (UML) especifica una notación estandarizada
para diagramas de estado que puede utilizarse para describir clases,
sistemas, subsistemas o incluso procesos de negocio. Los elementos
básicos de notación que pueden usarse para componer un diagrama son:
 Círculo lleno, apuntando a un estado inicial
 Círculo hueco que contiene un círculo lleno más pequeño en el
interior, indicando el estado final (si existiera)
 Rectángulo redondeado, denotando un estado. En la parte superior
del rectángulo está el nombre del estado. Puede contener una línea
horizontal en la mitad, debajo de la cual se indican las actividades
que se hacen en el estado
 Flecha, denotando transición. El nombre del evento (si existiera) que
causa esta transición etiqueta el cuerpo de la flecha. Se puede añadir
una expresión de Guarda, encerrada en corchetes ([]) denotando que
esta expresión debe ser cierta para que la transición tenga lugar. Si se
 realiza una acción durante la transición, se añade a la etiqueta
después de “/”. Nombre De Evento [Expresión Guarda] / acción
Línea horizontal gruesa con x>1 líneas entrando y 1 línea saliendo o
1 línea entrando y x>1 líneas saliendo. Estas denotan
Unión/Separación, respectivamente.

g) DIAGRAMA DE ACTIVIDAD

Muestra la realización de operaciones para conseguir un objetivo.

Presentan una visión simplificada de lo que ocurre en un proceso,
mostrando los pasos que se realizan. Los diagramas de actividad, son una
extensión de los diagramas de estado. Los diagramas de estado resaltan
los estados y muestran las actividades que dan lugar a cambios de estado,
mientras que los diagramas de actividad, resaltan justamente las
actividades. Comúnmente los diagramas de actividad se utilizan en dos
formas. En el modelado de flujos de trabajo, haciendo hincapié en las
actividades tal y como son vistas por los actores que colaboran con el
sistema, esto es, modelando procesos de negocios. En el modelado de
una operación, utilizando los diagramas de actividad como diagramas de
flujo para mostrar detalles de un algoritmo, haciendo amplio uso de las
condiciones y modelado de procesos concurrentes.
h) DIAGRAMA DE COMPONENTES

Los diagramas de componentes permiten visualizar las partes de un

sistema, mostrando las diversas formas en que pueden ensamblarse para
construir ejecutables. Un diagrama de componentes muestra las
dependencias entre componentes físicos de software, tales como archivos
 de código fuente, binarios, de configuración, de instalación y
desinstalación, ejecutables, tablas, etc. Los diagramas de componentes
modelan la vista estática de los sistemas, es decir sólo los componentes y
sus conexiones y no como funcionan.
i) DIAGRAMA DE DESPLIEGUE

El diagrama de despliegue, modela la topología del hardware sobre el

cual correrá nuestra aplicación y nos indica en donde se ejecutará cada
uno de nuestros componentes; muestra las relaciones físicas entre los
componentes de software y el hardware de nuestro sistema. Los
diagramas de despliegue muestran la forma en que físicamente lucirá
nuestro sistema, sólo deben mostrarse los nodos y componentes que
utilizarán en su versión ejecutable. El término original para estos
diagramas es deployment diagram que en nuestro idioma ha sido
traducido como diagramas de distribución, emplazamiento, implantación
o despliegue.
 CAPITULO IV

ACTIVIDADES Y PROCEDIMIENTOS
En este capítulo detallaremos el desarrollo e implementación del sistema, como se
describen el Capítulo II en presente informe se tiene básicamente cinco objetivos
específicos muy importantes los cuales fueron desarrollados de manera secuencial.
Estos objetivos específicos son las siguientes:
 Procedimiento 1:Recopilación de la información para realizar el análisis del
sistema.
Para la recopilación de información se usaron las técnicas e instrumentos de
recolección de datos, una vez analizado los datos e información se pasaron a definir
y detallar los requerimientos funcionales, no funcionales, una vez obtenido los
requerimientos se pasó a la creación de la base de datos del sistema.
 Procedimiento 2:Diseño de la interfaz de usuario interactivo y programación
de código fuente.
Para lograr este procedimiento se definió haciendo uso de los diagramas de Caso de
uso para analizar la funcionalidad del sistema, teniendo en cuenta este paso se
inició con el diseño de la interfaz del sistema para el área de Secretaria Docente a la
vez se programó todo el código fuente.
 Procedimiento 3: Prueba, mejoras y puesta en marcha del sistema.
En este procedimiento se realiza las pruebas necesarias para comprobar el buen
funcionamiento del sistema para el área de Secretaria Docente, para así poder
mejorarlo y ejecutar de forma correcta el sistema.
 Procedimiento 4: Implementar el sistema de área en el área de trabajo.
 En este procedimiento se realizará la implementación del sistema de proceso
Operativo en el área de Secretaria Docente de la FIES.
 Procedimiento 5: Realizar el mantenimiento adecuado al Sistema:
La función de este procedimiento es la de brindar una solución a posibles errores en
el proceso de ejecución del sistema y otros que puedan existir en el desarrollo.
4.1. RECOPILACION DE INFORMACION DE LA BASE DE DATOS
4.1.1. REQUISITOS DEL SISTEMA DEL PROCESO OPERATIVO
Para detallar los procesos primordiales del área e iniciar con el desarrollo del
software se obtuvo por medio de entrevistas personales al jefe de área, para
usarlo como guía principal en el proceso, para obtener resultados de desarrollo
del sistema de forma eficaz y eficiente.
La técnica inmediata para identificar los requisitos del sistema se basa en los
casos de usos, éstos capturan tanto los requisitos funcionales como los no
funcionales que son específicos de cada caso de uso.
a) REQUISITOS FUNCIONALES

METDOLOGIAS