UNIVERSIDAD YACAMBÚ
Asignatura: Seminario Especial de Grado
Fase I
Trabajo Nro: 6
Profesora: Mónica Pacheco
Autor: Rusbel R. Dimas G.
1. INTRODUCCIÓN
El proyecto a realizar pretende dar una solución al
problema presentado por la
Gerencia de Servicios, PDVSA-PETRORITUPANO S.A., del Estado
Anzoátegui, por la no existencia de un sistema automatizado, para la
administración y control de suministros y equipos del almacén principal.
La finalidad de este proyecto es desarrollar un Sistema
el cual debe ser capaz de permitir la administración y control de suministros y
equipos del Almacén Principal. Este Sistema va determinar los factores que
influyen en el cálculo de los niveles adecuados de existencias, tiempo de
reposición e inventario de seguridad, control de proveedores, información de
suministros o equipos más solicitados, especificaciones dependiendo del
suministro o equipo solicitado, el precio unitario o total de cada suministro o
equipo, control del personal relacionados al almacén, generar reportes de planta,
motor, entrada/salida de equipo o suministro, inventario general o por mes.
Este proyecto es de gran importancia, ya que, para un
funcionamiento organizado, bien estructurado y adecuado del almacén principal,
a las exigencias de
El trabajo que se presenta a continuación muestra los siguientes
componentes del proyecto: Antecedentes de
2. ANTECEDENTES DE
Para el desarrollo del proyecto que se desea
investigar, se han seleccionado algunos trabajos para el marco de referencia,
realizados por estudiantes de Ingeniería que han realizado pasantía en la
empresa antes mencionada.
• Galanton y
Arocha, (1999) en su trabajo de grado “Desarrollo de un Software para los sistemas
de Admisión y Control del Departamento de Recursos Humanos de la Empresa Petroritupano
• Sambrano y
Lara, (1997) desarrollaron su trabajo de grado “Desarrollo de un Software de
Gestión para modernizar las Dependencias de Contabilidad, Finanzas y
Presupuestos de la Empresa Petroritupano
• Caraballo,
(1996) desarrolló su trabajo de grado “Sistema de Consulta de Datos para la Delegación del
Personal de la Empresa Petroritupano
Estos trabajos de grado, utilizan
la metodología orientada a objeto y herramienta de modelado para lograr la
especificación de los requerimientos del sistema. Este tipo de metodología y
herramienta de modelado serán las empleadas en el proyecto que se desea
investigar.
3. MARCO TEÓRICO
3.1. Proceso Unificado de Desarrollo de Software
El Proceso Unificado de Desarrollo de Software, es el conjunto de
actividades necesarias para transformar los requisitos de un usuario en un
sistema software (Ver Figura 1).
El Proceso Unificado está basado en componentes, lo cual quiere decir
que el sistema software en construcción está formado por componentes software
interconectados a través de interfaces bien definidas. Además utiliza el
Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar
todos los esquemas de un sistema software. De hecho, UML es una parte esencial
del Proceso Unificado. (Booch
& Rumbaugh, 2000).
Los verdaderos aspectos definitorios del Proceso Unificado se resumen en
tres frases claves: Dirigido por casos de uso, centrado en la arquitectura e iterativo
e incremental.
3.1.1. Dirigido por Casos de Uso
Un caso de uso es un fragmento de funcionalidad del sistema que
proporciona al usuario un resultado importante. Los casos de uso representan
los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo
de casos de uso el cual describe la funcionalidad total del sistema. Puede
decirse que una especificación funcional contesta a la pregunta: ¿Qué debe
hacer el sistema? La estrategia de los casos de uso puede describirse añadiendo
tres palabras al final de esta pregunta: ¿…para cada usuario? Estas tres
palabras albergan una implicación importante. Nos fuerzan a pensar en términos
de importancia para el usuario y no sólo en términos de funciones que serían bueno
tener. Sin embargo, los casos de uso no son sólo una herramienta para especificar los requisitos
de un sistema. También guían su diseño, implementación, y prueba; esto es,
guían el proceso de desarrollo. Basándose en el modelo de casos de uso, los
desarrolladores crean una serie de modelos de diseño e implementación que
llevan a cabo los casos de uso. Booch & Rumbaugh, (op. cit).
3.1.2. Centrado en
El concepto de arquitectura software incluye los aspectos estáticos y
dinámicos más significativos del sistema. La arquitectura surge de las
necesidades de la empresa, como las perciben los usuarios y los inversores, y
se refleja en los casos de uso. Sin embargo, también se ve influida por muchos
otros factores, como la plataforma en la que tiene que funcionar el software
(arquitectura hardware, sistema operativo, sistema de gestión de bases de
datos, protocolos para comunicaciones en red) los bloques de construcción
reutilizables de que se dispone (por ejemplo, un marco de trabajo para interfaces
gráficas de usuario) consideraciones de implantación, sistemas heredados, y
requisitos no funcionales (por ejemplo, rendimiento, fiabilidad). La
arquitectura es una vista del diseño completo con las características más
importantes resaltadas, dejando los detalles de lado. Debido a que lo más
significativo depende en parte de una valoración, que a su vez, se adquiere con
la experiencia, el valor de una arquitectura depende de las personas que se
hayan responsabilizado de su creación. La arquitectura software se centra tanto
en los elementos estructurales significativos del sistema, como subsistemas,
clases, componentes y nodos, como en las colaboraciones que tienen lugar entre
estos elementos a través de las interfaces. Booch & Rumbaugh, (op.
cit).
3.1.3. Iterativo e incremental
El desarrollo de un producto software comercial supone un gran esfuerzo
que puede durar entre varios meses hasta posiblemente un año o más. Es práctico
dividir el trabajo en partes más pequeñas o mini-proyectos los cuales equivalen
a una iteración que resulta en un incremento, de allí la característica de
incremental del proceso unificado. Las iteraciones hacen referencia a pasos en
el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una
efectividad máxima, las iteraciones deben estar controladas; esto es, deben
seleccionarse y ejecutarse de una forma planificada.
Las primeras iteraciones se centran en la comprensión del problema y de
la tecnología. En la fase de inicio, las iteraciones se preocupan de producir
un análisis del negocio (estudiar problemas particulares relativos a la
tecnología). En la fase de elaboración, las iteraciones se orientan al
desarrollo de la línea base de la arquitectura. En la fase de construcción, las
iteraciones se dedican a la construcción del producto por medio de una serie de
construcciones dentro de cada iteración, que acaban en un producto preparado
para su distribución a la comunidad de usuarios. Sin embargo, (Ver Figura 2),
todas las iteraciones siguen el mismo patrón. Cada iteración constituye una
pasada a través de los cinco flujos de trabajo fundamentales. Se inicia con una
actividad de captura de requisitos y se concluye con una prueba. Booch & Rumbaugh, (op.
cit).
3.2. Flujos de Trabajo del Proceso Unificado
La forma de dividir las actividades y en el modo de aplicar los flujos
de trabajo es lo que diferencia al Proceso Unificado de Desarrollo de Software
del método tradicional, el trabajo de desarrollo es dividido en fases e
iteraciones. La realización de los flujos de trabajo (captura de requisitos,
análisis, diseño, implementación y pruebas) además de su representación a
través de los modelos del lenguaje UML, están incluidos en las iteraciones. Booch & Rumbaugh, (op.
cit).
3.2.1. Captura de Requisitos
El esfuerzo principal en la fase de requisitos es desarrollar un modelo
del sistema que se va a construir, y la utilización de los casos de uso es una
forma adecuada de crear ese modelo. Esto es debido a que los requisitos
funcionales se estructuran de forma natural mediante casos de uso, ya que la
mayoría de los otros requisitos no funcionales son específicos de un solo caso
de uso y pueden tratarse en su contexto. Los casos de uso proporcionan un medio
intuitivo y sistemático para capturar los requisitos funcionales con un énfasis
especial en el valor añadido para cada usuario individual o para cada sistema
externo. Mediante la utilización de los casos de uso, el analista se ve
obligado a pensar en términos de quiénes son los usuarios y qué necesidades u
objetivos de la empresa pueden cumplir. Booch & Rumbaugh, (op. cit).
3.2.2. Análisis
Durante el análisis, se analizan los requisitos que se describieron en
la captura de requisitos, refinándolos y estructurándolos. El objetivo de
hacerlo es conseguir una compresión más precisa de los requisitos y una
descripción de los mismos que sea fácil de mantener y que ayude a estructurar
el sistema entero. El modelo de análisis nos ayuda a refinar los requisitos y
nos permite razonar sobre los aspectos internos del sistema, incluidos sus
recursos compartidos internos y además nos ofrece un mayor poder expresivo, una
mayor formalización y también nos ayuda a estructurar los requisitos y nos
proporciona una estructura centrada en el mantenimiento, en aspectos tales como
la flexibilidad ante los cambios y la reutilización. Booch & Rumbaugh, (op.
cit).
3.2.3. Diseño
En el diseño se modela el sistema y se encuentra su forma para que
soporte todos los requisitos que se le suponen. Una entrada esencial en el
diseño es el resultado del análisis, esto es, el modelo de análisis el cual
proporciona una comprensión detallada de los requisitos. Y lo que es más
importante, impone una estructura del sistema para la cual hay que esforzarse
por conservarla lo más fielmente posible cuando se da forma al sistema.
Uno de los propósitos del diseño es adquirir
una comprensión en profundidad de los aspectos relacionados con los requisitos
no funcionales y restricciones relacionadas con los lenguajes de programación,
componentes reutilizables, sistemas operativos, tecnologías de distribución y
concurrencia, de interfaz de usuario, etc. Booch & Rumbaugh, (op. cit).
3.2.4. Implementación
La implementación planifica las integraciones del sistema, necesarias en
cada iteración. Siguiendo para ello un enfoque incremental, lo que da lugar a
un sistema que se implementa en una sucesión de pasos pequeños y manejables. La
mayor parte de la arquitectura del sistema es capturada durante el diseño,
siendo el propósito principal de la implementación el desarrollar la
arquitectura y el sistema como un todo. Booch & Rumbaugh, (op. cit).
3.2.5. Prueba
En el flujo de trabajo de la prueba se verifica el resultado de la
implementación probando cada construcción, incluyendo tanto construcciones
internas como intermedias, así como las versiones finales del sistema a ser
entregadas. Además de planificar las pruebas necesarias en cada iteración,
incluyendo las pruebas de integración y las pruebas del sistema. Las pruebas de
integración son necesarias para cada construcción dentro de la iteración,
mientras que las pruebas de sistema son necesarias sólo al final de la
iteración. Booch
& Rumbaugh, (op. cit).
3.3. Fases del Proceso Unificado de Desarrollo de Software
El Proceso Unificado de Desarrollo de Software se divide en varias
fases, atendiéndolas al momento en que se realizan. Cada una de las fases se
divide en una o más iteraciones.
3.3.1. Fase de Inicio
El objetivo global de la fase de inicio es poner en marcha el proyecto.
Antes de esta fase, puede que tenga simplemente una idea interesante rondándole
la cabeza. La idea puede ser sugestiva, si se trata de algo totalmente nuevo y
en un campo nuevo. O puede ser sosegada, si consiste en una nueva versión de un
producto ya existente. Lo importante es que no se considere la fase de inicio
como algo que ha de desarrollarse de una única forma. Después del inicio,
incluso si el sistema es nuevo, se habrá delimitado el problema que se quiere
resolver y se habrá hecho lo necesario para ver, con cierto grado de confianza,
que es a la vez posible y deseable desarrollar un sistema. Booch & Rumbaugh, (op.
cit).
3.3.2. Fase de Elaboración
En la fase de elaboración los principales objetivos son:
·
Recopilar la mayor parte de los requisitos
que aún queden pendientes, formulando los requisitos funcionales como casos de
uso.
·
Establecer una base de la arquitectura
sólida para guiar el proyecto durante las fases siguientes, así como en las
posteriores generaciones del sistema.
·
Continuar la observación y control de los
riesgos críticos que aún queden, e identificar los riesgos significativos hasta
el punto en que se pueda estimar su impacto en el análisis de negocio, y en
particular en lo económico.
·
Completar los detalles del plan del
proyecto.
En esta fase se tiene que acrecentar el entorno de desarrollo, no sólo
para llevar a cabo las actividades de esta fase, sino para estar preparados
para la fase de construcción. Al final de esta fase, se habrá acumulado la
información necesaria para planificar la fase de construcción. Booch & Rumbaugh, (op.
cit).
3.3.3. Fase de Construcción
En la fase de construcción, a partir de una línea base de la
arquitectura ejecutable, y trabajando a través de iteraciones e incrementos, se
desarrolla un producto software listo para su operación inicial en el entorno
del usuario. El producto debería tener la calidad adecuada para su aplicación y
asegurarse de cumplir los requisitos. A medida que el proyecto pasa de la fase
de elaboración a la de construcción, se produce un cambio de enfoque. Mientras
que las fases de inicio y elaboración podrían ser consideradas como
investigación, la fase de construcción es análoga al desarrollo, entonces, el
énfasis se traslada de la acumulación del conocimiento básico necesario para
construir el proyecto a la construcción propiamente dicha de un sistema o
producto dentro de unos parámetros de coste, esfuerzo y agenda. Booch & Rumbaugh, (op.
cit).
3.3.4. Fase de Transición
En esta fase no se busca reformular el producto. El cliente y el
desarrollador del proyecto deberían haber incorporado cambios significativos en
los requisitos durante las fases anteriores. Por el contrario, el desarrollador
busca pequeñas deficiencias que pasaron desapercibidas durante la fase de
construcción y que pueden ser corregidas en el marco de la línea base de la arquitectura
existente. Booch
& Rumbaugh, (op. cit).
3.4. Lenguaje Unificado de Modelado, (UML)
UML: (Unified Modeling Language) es una manera estándar de modelar los
datos de determinada aplicación, con una notación para expresar los datos
(atributos, métodos), las relaciones entre los mismos y el conjunto de
requerimientos que pueden ser satisfechos en la aplicación. Es un lenguaje para
especificar, construir, visualizar y documentar los artefactos de un sistema de
software orientado a objetos (OO). (Moreno, 2000).
El UML, fue promulgado en 1.998 como estándar internacional para
notación de diseño de software. Este estándar ya adoptado por empresas de la
talla de Microsoft, Oracle, IBM y otras mas , es un paso fundamental hacia la
industrialización de las actividades de software, puesto que abarca desde la
especificación de requerimientos, diseños conceptuales, diseños lógicos y
configuración física de sistemas. UML no está limitado al modelado de software.
De hecho, es lo suficientemente expresivo para modelar sistemas que no son
software, como flujos de trabajo (workflows) en el sistema jurídico, estructura
y comportamiento de un sistema de vigilancia médica de un enfermo, y el diseño
de hardware. (Quatrani,
1998).
UML es un lenguaje muy expresivo, que cubre todas las vistas necesarias
para desarrollar y luego desplegar sistemas. Aunque sea expresivo, UML no es
difícil de aprender ni de utilizar. Aprender a aplicar UML de modo eficaz
comienza por crear un modelo conceptual del lenguaje, lo cual requiere aprender
tres elementos principales: los bloques básicos de construcción de UML, las
reglas que dictan como pueden combinarse esos bloques y algunos mecanismos
comunes que se aplican a lo largo del lenguaje. (http://www.ultrasist.com/tecnologias/uml.html).
3.4.1. Artefactos Para el Desarrollo de Proyectos
Un artefacto es una información que es utilizada o producida mediante un
proceso de desarrollo de software. Pueden ser artefactos, un modelo, una
descripción o un software. Los artefactos de UML se especifican en forma de
diagramas, éstos, junto con la documentación sobre el sistema constituyen los
artefactos principales que el modelador puede observar. Moreno, (op. cit).
3.4.2. Diagramas de Casos de Uso
A pesar de ser considerada una técnica de análisis orientado a objetos,
es importante destacar que los casos de uso poco tienen que ver con entender a
un sistema como un conjunto de objetos que interactúan, que es la premisa
básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso
no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a
entender un sistema es a partir de los servicios o funciones que ofrece a su
entorno, independientemente de los objetos que interactúan dentro del sistema
para proveerlos. Un caso de uso es una secuencia de transacciones que son
desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre
el propio sistema. (Herrera, 2001).
La notación de UML, para los elementos que pertenecen al modelo de casos
de uso se muestra en: (Ver Figura 3).
Herrera, (op. cit) señala que los
elementos mostrados en
- Actor:
Un actor representa un papel interpretado por una persona o una cosa que
interactúa con el sistema. Los actores se determinan observando los
usuarios directos del sistema, los responsables de su uso o de su
mantenimiento, así como los otros sistemas que interactúan con el sistema
en cuestión.
- Casos
de Uso: Es una manera específica de utilizar el
sistema. Es la imagen de una funcionalidad del sistema, desencadenada en
respuesta a la estimulación de un actor externo.
- Sistema:
Identifica las diferentes partes del sistema y contiene los casos de uso
que lo forman.
- Relación
de Asociación: Las relaciones de asociación entre actores y
casos de uso, son utilizadas para indicar participación y comunicación
entre estos elementos. Estas relaciones son denotadas como líneas sólidas
o caminos. Las puntas de las flechas indican quién es el destino de la
interacción, es decir, el lado contrario de la asociación al que tiene la
punta de la flecha, es quien inicia la interacción.
- Relación
de Generalización: Las relaciones de generalización de casos de
uso son utilizadas, para indicar que un caso de uso de especialización es
consistente un caso de uso generalizado y puede agregarle más información.
Un caso de uso de especialización puede ser utilizado en lugar de un caso
de uso generalizado y puede utilizar cualquier porción de la interacción
del caso de uso generalizado.
- Relación
de Extensión: Indica que un caso de uso base puede ser
aumentado por un caso de uso de extensión, en caso de que se satisfaga una
condición de extensión. Un caso de uso base define un punto de extensión,
mientras que un caso de uso de extensión define la condición de extensión
que debe ser satisfecha de manera que se inserte la extensión del caso de
uso, en el caso de uso base.
- Relación
de Inclusión: Una relación de inclusión de un caso de uso (A)
a un caso de uso (B) indica que una instancia del caso de uso (A) contiene
el comportamiento especificado por una instancia del caso de uso (B). Se
representa con una línea punteada entre los elementos y una flecha, puede
indicar quién inicia la relación, sobre la línea debe ir la etiqueta
<<include>>.
3.5. Diagramas de Clases
Herrera, (op. cit) señala
que los diagramas de clases representan un
conjunto de elementos del modelo que son estáticos, como las clases y los
tipos, sus contenidos y las relaciones que se establecen entre ellos:
- Paquete:
Es el mecanismo de que dispone UML para organizar sus elementos en grupos,
se representa un grupo de elementos del modelo. Un sistema es un único
paquete que contiene el resto del sistema, por lo tanto, un paquete debe
poder anidarse, permitiéndose que un paquete contenga otro paquete.
- Utilidad:
Es el que se corresponde con una agrupación de variables y procedimientos
globales en forma de declaración de clase, también puede definirse como un
estereotipo (o nueva clase generada a partir de otra ya existente) de un
tipo que agrupa variables globales y procedimientos en una declaración de
clase. Los atributos y operaciones que se agrupan en una utilidad se
convierten en variables y operaciones globales. Una utilidad no es
fundamental para el modelado, pero puede ser conveniente durante la
programación.
- Metaclase:
Es una clase cuyas instancias son clases. Sirven como depósito para
mantener las variables de clase y proporcionan operaciones (método de
clase) para inicializar estas variables. Se utilizan para construir
metamodelos (modelos que se utilizan para definir otros modelos).
- Tipos:
Es un descriptor de objetos que tiene un estado abstracto y
especificaciones de operaciones pero no su implementación. Un tipo
establece una especificación de comportamiento para las clases.
3.6. Diagramas de Secuencias
Los diagramas de secuencias muestran las interacciones entre un conjunto
de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de
este tipo intervienen objetos, que tienen un significado parecido al de los
objetos representados en los diagramas de colaboración, es decir son instancias
concretas de una clase que participa en la interacción. El objeto puede existir
sólo durante la ejecución de la interacción, se puede crear o puede ser
destruido durante la ejecución de la interacción. Un diagrama de secuencia
representa una forma de indicar el período durante el que un objeto está
desarrollando una acción directamente o a través de un procedimiento. Herrera, (op. cit).
3.7. Diagramas de Despliegue
Los diagramas de despliegue muestran la configuración de los componentes
hardware, los procesos, los elementos de procesamiento en tiempo de ejecución y
los objetos que existen en tiempo de ejecución. En este tipo de diagramas
intervienen nodos, asociaciones de comunicación, componentes dentro de los
nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo
es un objeto físico en tiempo de ejecución, es decir una máquina que se compone
habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez
puede estar formada por otros componentes. Herrera, (op. cit).
3.8. Diagramas de Colaboración
Los diagramas de colaboración o de interacción resaltan la organización estructural de los
objetos que envían y reciben mensajes, estos diagramas se utilizan para
describir la vista dinámica de un sistema. (Booch & Rumbaugh, 1999).
3.9. Definiciones
Básicas
Las definiciones y los fundamentos teóricos relacionados con el proyecto
de investigación son mostrados a continuación.
3.9.1. Interfaz Gráfica
La interfaz gráfica es la más utilizada, ya que es de mayor comodidad
para el usuario, implementa un concepto de ventanas, iconos y caja de diálogos
que facilitan el uso de esta interfaz, un medio para insertar datos o
información que un programa o comando ha generado, con éste se puede cambiar el
tamaño o forma para ver la información dentro de ella. (Long, 1996).
3.9.2. Programación Orientada a Objetos (POO)
La orientación a objetos promete mejoras de amplio alcance en la forma
de diseño, desarrollo y mantenimiento del software ofreciendo una solución a
largo plazo a los problemas y preocupaciones que han existido desde el comienzo
en el desarrollo de software: la falta de portabilidad del código y
reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y
técnicas de codificación no intuitivas. (Rodríguez, 2001).
3.9.3. Estructura de un Objeto
Un objeto puede considerarse como una especie de cápsula dividida en
tres partes: Relaciones, Propiedades y Métodos. Las Relaciones permiten que el
objeto se inserte en la organización y están formadas esencialmente por
punteros a otros objetos. (Rodríguez, 2001).
3.9.4. Encapsulamiento y Ocultación
Cada objeto es una estructura compleja en cuyo interior hay datos y
programas, todos ellos relacionados entre sí, como si estuvieran encerrados
conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las
características fundamentales en
3.9.5. Paradigma Orientado a Objeto
Disciplina de ingeniería de desarrollo y modelado de software que
permite construir más fácilmente sistemas complejos a partir de componentes
individuales. Objetos + Mensajes = Programa. (Booch, 1996).
3.10. Base de Datos
La base de datos es un conjunto de información relacionada que se
encuentra agrupada o estructurada. Un archivo por sí mismo no constituye una
base de datos, sino más bien la forma en que está organizada la información es
la que da origen a la base de datos. (Raga, 2001).
3.10.1. Requerimientos de las Bases de Datos
El análisis de requerimientos para una base de datos incorpora las
mismas tareas que el análisis de requerimientos del software. Es necesario un
contacto estrecho con el cliente; es esencial la identificación de las
funciones e interfaces; se requiere la especificación del flujo, estructura y
asociatividad de la información y debe desarrollarse un documento formal de los
requerimientos. Raga, (op. cit).
3.11. Microsoft Access
Es un sistema gestor de bases de datos relacionales (SGBD). El primer
paso para diseñar una base de datos de Microsoft Access es determinar la
finalidad de la base de datos y cómo se utiliza. Debe saber qué información
desea obtener de la base de datos. A partir de ahí, puede determinar sobre qué
asuntos necesita almacenar hechos (las tablas) y qué hechos necesita almacenar
sobre cada asunto (los campos de las tablas). (http://www.club.telepolis.com/ortihuela/access.htm)
3.12. Visual Basic, (vb)
Es uno de los tantos lenguajes de programación que podemos encontrar hoy
en día, dicho lenguaje nace del BASIC (Beginner´s All-purpose Symbolic
Instruction Code) que fue creado en su versión original en el Dartmouth
College, con el propósito de servir a aquellas personas que estaban interesadas
en iniciarse en algún lenguaje de programación. Luego de sufrir varias
modificaciones, en el año 1978 se estableció el BASIC estándar. (Birnios, 1998).
4. MARCO
METODOLÓGICO
4.1. Consideraciones Generales
El Marco Metodológico tiene por finalidad asegurar que los hechos
estudiados así como la relación entre
estos, las evidencias encontradas y las conclusiones obtenidas cumplan con las
condiciones de fiabilidad, objetividad y validez. Además que este proporcionará los instrumentos
y los procedimientos que serán utilizados tanto en la recolección de los datos
como en la tabulación de los mismos.
Esta es la fase del proceso
de investigación donde se plantea la estrategia para el estudio de los hechos o
fenómenos objetos de la investigación, formulando un modelo operativo que le
permita acercarse a éste y conocerlo tal como es. Lo primero que se debe
realizar es definir el tipo de investigación del cual se derivan los
procedimientos, técnicas y métodos a utilizar en la recolección y análisis de
los datos.
4.2. Tipo de Investigación
Es necesario tomar en
cuenta que una investigación es el proceso mediante el cual se trata de conocer
los elementos determinantes, concurrentes e influyentes que intervienen en un
proceso determinado. Mediante una investigación, el hombre persigue su afán de
comprender, conocer y mejorar cada vez más los procesos donde se involucra.
Entre los objetivos principales que persigue una investigación se
encuentra el de conocer los procesos para formular una hipótesis, de esta forma
encontrar soluciones a determinadas situaciones o proporcionar información que
sirva de base para otras investigaciones.
Las investigaciones pueden ser clasificadas en diferentes tipos,
ellos son:
1.
Según la razón de la investigación esta puede ser: Pura o aplicada.
2.
Según el nivel de conocimientos a obtener, puede ser: Exploratoria,
descriptiva o explicativa.
3.
Según la estrategia empleada por el investigador: Documental,
experimental o de campo.
Basándose en la estrategia
utilizada por el investigador, este trabajo de investigación queda definido
como una Investigación Descriptiva, ya que comprenderá la descripción,
análisis e interpretación de la información relativa al mantenimiento y tipo de
fallas del Almacén Principal de
El diseño de la
investigación se refiere al plan o estrategia concebida para responder a las
interrogantes que se ha planteado en el problema. El diseño de la investigación
que sustenta este proyecto será el de campo, ya que se recolectarán datos
obtenidos directamente de la realidad, lo que permitirá que la investigación
adquiera gran valor debido a la posibilidad de levantar la información
necesaria para la elaboración del diagnóstico y la determinación de
requerimientos.
Esta investigación se
apoyará también en el conocimiento y análisis de las fuentes que sean de
utilidad en el desarrollo de esta, como son la bibliografía especializada,
información de proyectos anteriormente realizados y experiencia sobre el tema,
a través de la clasificación y estudio de diversos aspectos relacionados con el
tema que se desea investigar.
4.3. Población del Estudio
Balestrini, (1998) señala: "Desde el
punto de vista estadístico, una población o universo puede estar referida a
cualquier conjunto de elementos de los cuales pretendemos indagar y conocer sus
características, o una de ellas, y para el cual serán válidas las conclusiones
obtenidas en la investigación" .
La población objeto de
estudio en este trabajo de investigación es la perteneciente a
4.4. Muestra
Hernández, (1991), señala
que las muestras se dividen "en dos grandes ramas: Las muestras no
probabilísticas y las muestras probabilísticas. En estas últimas todos los
elementos de la población tienen la misma posibilidad de ser escogidos(...) En
las muestras no probabilísticas, la elección de los elementos no depende de la
probabilidad, sino de causas relacionadas con las características del
investigador o del que hace la muestra. Aquí el procedimiento no es mecánico,
ni con base en fórmulas de probabilidad, sino que depende del proceso de toma
de decisiones de una persona o grupo de personas".
Tomando como referencia
este punto de vista, el presente estudio que se desea realizar tomará una Muestra
no Probabilística conformada por la población antes mencionada en su
totalidad, referida particularmente a las treinta (30) personas que están
relacionadas directamente con las actividades internas del Almacén Principal.
La muestra es obtenida con
la finalidad de investigar, a partir del conocimiento de sus características
particulares, las propiedades de la población.
4.5.
Instrumentos a Aplicar
Al elaborar los
instrumentos de recolección de datos a aplicar en la investigación es necesario
analizar en que forma dicho instrumento de medición cumple con la función para
la cual ha sido diseñado. Este análisis debe realizarse antes de iniciar la
recolección de datos, lo que permitirá introducir las modificaciones necesarias
antes de su aplicación.
Una vez que han sido
elegido el tipo de instrumento que se utilizará en la recolección de datos, lo
cual se hace de acuerdo con una serie de consideraciones, puede pasarse a la
elaboración del instrumento propiamente dicha, lo que puede facilitarse
siguiendo una series de pasos que se explican a continuación:
·
Paso 1. Decidir cuál será la unidad a la se aplicará el instrumento.
·
Paso 2. Considerar las características importantes de la unidad de
observación o sujeto con relación al instrumento.
·
Paso 3. Determinar la información que se recogerá.
·
Paso 4. Determinar la estructura del instrumento: Áreas o secciones
y el formato general.
·
Paso 5. Diseñar el instrumento: Elaboración de preguntas o ítem y
el análisis de preguntas o ítem según alcance y estructura.
·
Paso 6. Probar el instrumento.
·
Paso 7. Revisar y reproducir el instrumento.
Los instrumentos de
recolección de datos a aplicar en la investigación que se desea realizar son:
·
Observación Directa, se refiere al registro
visual de lo que ocurre en una situacional real, clasificando y consignando los
acontecimientos pertinentes de acuerdo con algún esquema previsto y según el
problema que se estudia.
·
Revisión Bibliográfica, se utilizará como base
complementaria a la investigación central, con el fin de recopilar y revisar
todos los documentos que permitan confrontar el aspecto teórico con la situación
que se desea investigar. Es importante señalar que esta revisión se efectuará
antes y durante la investigación, con el objetivo de cotejar información,
obtener nuevas ideas e indagar la naturaleza de los datos.
·
Entrevistas informales no
estructuradas, estas estarán orientadas principalmente en la recopilación de
información y están enfocadas a todo el personal relacionado con el Almacén Principal,
de tal manera de obtener la información necesaria y rápida producto de la
experiencia sobre la realización de las actividades de control y
administración, recursos necesarios, etc. Este tipo de entrevistas suelen efectuarse a manera de conversación
y se conducen en entornos naturales. Los estudios de campo tienden a depender
en gran medida de entrevistas.
4.6. Recolección de Datos
Es importante destacar que
los métodos de recolección de datos, se pueden definir como: al medio a través
del cual el investigador se relaciona con los participantes para obtener la
información necesaria que le permita lograr los objetivos de la investigación.
De modo que para recolectar
la información hay que tener presente:
1.
Seleccionar un instrumento de medición el cual debe ser valido y
confiable para poder aceptar los resultados.
2.
Aplicar dicho instrumento de medición.
3.
Organizar las mediciones obtenidas, para poder analizarlos.
En el trabajo de
investigación que se desea realizar, la recolección de datos se basa
inicialmente en la observación directa del funcionamiento del Almacén Principal
en condiciones normales de servicio, lo que permite tener una descripción más
precisa de las características del almacén, tanto su administración como el control
de todas sus actividades. Estas observaciones se realizarán mediante visitas
guiadas por el personal encargado del almacén.
Luego se procede con la
revisión bibliográfica en la cual se consulta y recopila toda la bibliografía y
documentos internos (disponibles) de la empresa, que se relacionan con el avance
y/o desarrollo de la investigación.
Se analiza el sistema
actual, definiendo los problemas. Para lograr esto, se realizan entrevistas
informales no estructuradas al personal relacionado con el Almacén Principal de
tal manera de obtener la información necesaria de manera rápida, producto de la
experiencia sobre la realización de las labores de administración y control,
las cuales se realizan de una manera poco eficaz para el funcionamiento de
dicho almacén, originando todo esto un aumento en los costos e inversión de
trabajos y así llegando a tener una considerable disminución en el nivel de
servicio.
Al finalizar las
entrevistas y revisiones bibliográficas, se establece el contexto de creación
del Sistema a desarrollar y se determina los distintos requerimientos de
información con los cuales debe cumplir.
4.7. Tabulación de Datos
La tabulación de los datos comparativos obtenidos por medio
de los diferentes instrumentos de medición aplicados consistirá en recopilar la
información para formular conclusiones y recomendaciones inherentes a la
investigación deseada.
4.8. Análisis
e interpretación de los Datos
Una vez que se establecen las
conclusiones y recomendaciones resultantes de la tabulación de los datos queda
por realizar la última etapa que consiste básicamente en proceder a la
estimación de los parámetros poblacionales que interesan, así como
representaciones gráficas, análisis de regresión y correlación, etcétera. La
forma correcta de analizar resultados exige una adecuada combinación entre
hipótesis previas, sobre el tema de estudio, a contrastar con los datos
obtenidos y nuevas proposiciones que nacen justamente de la información
obtenida.
La información recolectada mediante
los datos obtenidos en este estudio, permitirá conocer las fortalezas y
debilidades de la investigación que se desea realizar, para así realizar las
propuestas que conducirán al cumplimiento de los objetivos definidos.
5. CRONOGRAMA DE ACTIVIDADES
A continuación se muestra
el cronograma de actividades relacionadas con la investigación a realizar:
6. REFERENCIAS BIBLIOGRÁFICAS
·
Balestrini A. (1998). Cómo se Elabora el Proyecto de Investigación:
Para los Estudios Formulativos o Exploratorios, Descriptivos, Diagnósticos, Evaluativos, Formulación de
Hipótesis Casuales, Experimentales y los Proyectos Factibles. Caracas: BL
Consultores Asociados, Servicio Editorial. Segunda Edición.
·
Booch, G. y Rumbaugh, J. (2000). “El Proceso Unificado de
Desarrollo de Software”, Editorial Pearson, Educación, Primera Edición, Madrid.
·
Booch, G. y Rumbaugh, J. (1999). “UML el Lenguaje Unificado de
Modelado”, Editorial Addison-Wesley.
·
Booch, G. (1996). “Análisis y Diseño Orientado a Objetos”, Segunda
Edición. Addison-Wesley / Díaz de Santos.
·
Birnios, M. (1998). “Creación de Aplicaciones Multimedia con Visual
Basic”, Editorial MP Ediciones, Primera Edición, Buenos Aires.
·
Caraballo, O. (1996). “Sistema de Consulta de Datos para
·
Galanton, A. y Arocha, O. (1999). “Desarrollo de un Software para
los sistemas de Admisión y Control del
Departamento de Recursos Humanos de
·
Hernández Sampieri, R., Fernández Collado, C. y Baptista Lucio, P.
(1991). Metodología de la investigación. México: McGraw-Hill. Segunda edición.
·
Herrera, L. (2001). “Ingeniería De Requerimientos, Ingeniería De
Software”,
Disponible en: http://www.monografias.com/trabajos6/resof/resof.shtml
·
Long, L. (1996)."Introducción a las Computadoras y Sistemas de
Información".
·
Moreno, G. (2000). “Ingeniería de Software UML”,
Disponible
en: http://www.monografias.com/trabajos5/insof/insof.shtml
·
Sambrano, L. y Lara, A. (1997). “Desarrollo de un Software de
Gestión para modernizar las Dependencias de Contabilidad, Finanzas y
Presupuestos de
·
Quatrani, T. (1998). “Visual Modeling With
Rational Rose and UML”, Editorial Addison-Wesley.
·
Raga, Ch. (2001). “Base de Datos”,
Disponible en:
http://www.monografias.com/trabajos5/basede/basede.shtml
·
Rodríguez, C. (2001). “Sistemas de Procesamiento De Datos,
Programación Orientada a Objetos”,
Disponible en: http://www.monografias.com/trabajos7/orob/orob.sthml
·
(http://www.ultrasist.com/tecnologias/uml.html)
·
(http://www.club.telepolis.com/ortihuela/access.htm)