Capítulo II – Marco Teórico

Antecedentes de la Investigación
Se revisaron diversas fuentes referentes a los sistemas de información y sobre el control
de inventario, pudiéndose recolectar investigaciones relacionadas sobre el diseño,
desarrollo e implementación de sistemas de información pero encontrando un vacío de
información sobre el control de inventario de la empresa Inversiones MIWILL, C.A.
Como investigación resaltante en el área, se puede destacar:
Arias, J. (2007), elaboró un proyecto titulado: "Programa para el Control de Entrada y
Salida de Materiales Escolares y Limpieza del Colegio Internacional Monagas, Maturín
Estado Monagas". Propone un programa computarizado de inventario que lleve a cabo
todos los registros del material de limpieza de la institución de manera segura para poder
preservar más tiempo los materiales de limpieza en el depósito sin perder el control de lo
que allí se encuentra ya que ciertos extravíos de mercancía acarreaban grandes pérdidas
al colegio.
Figueroa, N. (2007), elaboró un proyecto titulado: "Diseño de un Sistema Computarizado
para el Proceso de Facturación de la Empresa Inversiones BELMON PARR, C.A del
Estado Monagas". Propone un sistema que lleve el control de la facturación de forma más
segura, con claves únicas de acceso para cada facturador aplicando e implementando las
modernas técnicas de administración y control. Y así poder garantizarle a la empresa la
tranquilidad y el rendimiento de las inversiones hecha en ella.
Medina, M. (2008), elaboró un proyecto titulado: "Sistema Desarrollo de un Sistema de
Información para el Registro y Control de los Materiales y Equipos de la Empresa
Venezolana de Construcciones y Mantenimiento VECHAA, C.A, Maturín Estado Monagas"
en el cual propone un sistema automatizado que de apoyo a la gestión administrativa de
la empresa, la cual consta con el diseño e implantación de una aplicación que lleve los
registros y controles de todos los materiales y equipos de la empresa Venezolana de
Construcciones y Mantenimiento VECHAA.
Bases Teóricas

Control de inventario
El control del inventario es uno de los aspectos de la administración que la micro y
pequeña empresa es muy pocas veces atendido, sin tenerse registros fehacientes, un
responsable, políticas o sistemas que le ayuden a esta fácil pero tediosa tarea.
Inventarios son bienes tangibles que se tienen para la venta en el curso ordinario del
negocio o para ser consumidos en la producción de bienes o servicios para su posterior
comercialización. Los inventarios comprenden, además de las materias primas, productos
en proceso y productos terminados o mercancías para la venta, los materiales, repuestos
y accesorios para ser consumidos en la producción de bienes fabricados para la venta o
en la prestación de servicios; empaques y envases, y los inventarios en tránsito.
La base de toda empresa comercial es la compra y venta de bienes o servicios; de aquí la
importancia del manejo del inventario por parte de la misma. Este manejo contable
permitirá a la empresa mantener el control oportunamente, así como también conocer al
final del período contable un estado confiable de la situación económica de la empresa.
Ahora bien, el inventario constituye las partidas del activo corriente que están listas para
la venta, es decir, toda aquella mercancía que posee una empresa en el almacén
valorada al costo de adquisición, para la venta o actividades productivas.
 Método de Control de Inventarios
Las funciones de control de inventarios pueden apreciarse desde dos puntos de vista:
Control Operativo y Control Contable.
El control operativo aconseja mantener las existencias a un nivel apropiado, tanto en
términos cuantitativos como cualitativos, de donde es lógico pensar que el control
empieza a ejercerse con antelación a las operaciones mimas, debido a que si compra si
ningún criterio, nunca se podrá controlar el nivel de los inventarios. A este control pre-
operativo es que se conoce como Control Preventivo.
El control preventivo se refiere, a que se compra realmente lo que se necesita, evitando
acumulación excesiva.
La auditoria, el análisis de inventario y control contable, permiten conocer la eficiencia del
control preventivo y señala puntos débiles que merecen una acción correctiva. No hay que
olvidar que los registros y la técnica del control contable se utilizan
como herramientas valiosas en el control preventivo.
Algunas técnicas son las siguientes:
 Fijación de existencias máximas y mínimas
 Índices de Rotación
 Aplicación del criterio especialmente cuando las especulaciones entra en juego
 Control Presupuestal.
Para una compañía comercial, el inventario comprende todas las mercancías de
su propiedad, que se tiene para la venta en el ciclo regular comercial.
El Inventario final de un año es también el inventario inicial del próximo año. Por tanto, un
error de inventario de fin de año afecta el estado de resultados de los dos años
consecutivos. Por ejemplo, una sobreestimación del inventario final causara una
sobreestimación del ingreso neto de este año y una subestimación compensatoria del
ingreso neto del año siguiente.
El inventario significa la suma de aquellos artículos tangibles de propiedad personal los
cuales están disponibles para la venta en una operación ordinaria comercial y están en un
proceso de producción para tales ventas. Así como estarán disponibles para
el consumo corriente en la producción de bienes y servicios disponibles para la venta.
Sistemas
Un sistema es un conjunto de partes o elementos organizados y relacionados que
interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía
o materia del ambiente y proveen (salida) información, energía o materia.
Un sistema puede ser físico o concreto (una computadora, un televisor, un humano) o
puede ser abstracto o conceptual (un software).
Cada sistema existe dentro de otro más grande, por lo tanto un sistema puede estar
formado por subsistemas y partes, y a la vez puede ser parte de un supersistema.
Los sistemas tienen límites o fronteras, que los diferencian del ambiente. Ese límite puede
ser físico (el gabinete de una computadora) o conceptual. Si hay algún intercambio entre
el sistema y el ambiente a través de ese límite, el sistema es abierto, de lo contrario, el
sistema es cerrado.
El ambiente es el medio en externo que envuelve física o conceptualmente a un sistema.
El sistema tiene interacción con el ambiente, del cual recibe entradas y al cual se le
devuelven salidas. El ambiente también puede ser una amenaza para el sistema.
Un grupo de elementos no constituye un sistema si no hay una relación e interacción, que
de la idea de un "todo" con un propósito (ver holismo y sinergía).
En informática existen gran cantidad de sistemas:
 Sistema operativo.
 Sistema experto.
 Sistema informático.
 Aplicación o software.
 Computadora.
Sistema de Información
Un sistema de información se puede definir como un conjunto de funciones, componentes
o elementos que interactúan entre sí con la finalidad de apoyar la toma de
decisiones, coordinación, análisis de problema, visualización de aspectos complejos y el
control de una organización.

Ciclo de Vida del Desarrollo del Software

Un sistema de información tiene un origen (nacimiento) generalmente ocasionado por
necesidades, a partir de las cuales emprende su desarrollo que va desde la definición del
proyecto hasta la puesta en operación (crecimiento); seguidamente se inicia su operación
y mantenimiento por un periodo mayor a los demás, durante el cual alcanza el máximo
rendimiento posible (maduración). Luego, factores tales como la dinámica de la
organización, los avances tecnológicos y las personas internas o externas vuelven
obsoletos o ineficaz al sistema (decaimiento), lo cual origina su paralización (muerte). En
éste último se toma la decisión de renovar el sistema, lo que origina un nuevo ciclo de
vida, o desecharlo por completo, lo cual marca su fin definitivo. Como se muestra en la
Figura 1.1 (Ciclo de vida del desarrollo del software).
Visual Basic
Es un lenguaje de programación desarrollado por Ala Cooper para Microsoft. El
lenguaje de programación es un dialecto de BASIC, con importantes añadidos. Su primera
versión fue presentada en 1991 con la intención de simplificar la programación utilizando
un ambiente de desarrollo completamente gráfico que facilitara la creación de
interfaces gráficas y en cierta medida también la programación misma. Desde el 2001
Microsoft ha propuesto abandonar el desarrollo basado en la API Win32 y pasar a trabajar
sobre un framework o marco común de librerías independiente de la versión del sistema
operativo, .NET Framework, a través de Visual Basic .NET (y otros lenguajes como C
Sharp (C#) de fácil transición de código entre ellos) que presenta serias
incompatibilidades con el código Visual Basic existente.
Visual Basic constituye un IDE (entorno de desarrollo integrado o en inglés Integrated
Development Enviroment) que ha sido empaquetado como un programa de aplicación, es
decir, consiste en un editor de código (programa donde se escribe el código fuente), un
depurador (programa que corrige errores en el código fuente para que pueda ser bien
compilado), un compilador (programa que traduce el código fuente a lenguaje de
máquina), y un constructor de interfaz gráfica o GUI (es una forma de programar en la que
no es necesario escribir el código para la parte gráfica del programa, sino que se puede
hacer de forma visual).
Acceso a Base de Datos (DAO)
Los gestores de bases de datos son, un conjunto de funciones capaces de realizar
cuantas tareas son precisas para la manipulación de los datos que guardan. Visual Basic
gestiona los datos a través de lo que se conoce como motor JET para bases de datos.
Este motor dispone de unas funciones que se encargan de comunicarse con la aplicación,
mientras que otro grupo de funciones gestiona el acceso a los controladores de la base de
datos. La parte accesible de este motor JET es lo que se conoce con el nombre de IDAPI
(Programa Interfaz Integrado para Aplicaciones de bases de datos – Integrated Database
Aplication Program Interface-. Este interfaz posibilita el acceso a bases de datos a
gestores como Microsoft Access, Paradox, Dbase y Otros.
Bases de Datos y Visual Basic
 Las mayorías de las aplicaciones precisan de algún modo de poder almacenar y
manipular los datos. Visual Basic proporciona un grupo de herramientas que cubren estas
necesidades, siendo las mas utilizadas las que acompañan a los controles de acceso a
datos. Algunas de estas herramientas solo están disponibles en la versión profesional y
en la de empresa. Bien es cierto que el uso exclusivo de los controles para gestión de
datos limitan la operatividad para la manipulación de los registros. Para poder gestionar
los datos de una base de datos con un control completo sobre las posibles operaciones,
Visual Basic dispone del lenguaje de programación a través del cual se puede conseguir
una completa operatividad sobre los datos.
Base de Datos
Ramez, E. (2002), señala que "Una base de datos es un conjunto de datos relacionados
entre sí. Por datos se denominan los hechos conocidos que pueden registrarse y que
tienen un significado implícito" (p. 95).
Una base de datos representa algún aspecto del mundo real, es un conjunto de datos
relacionados, con cierto significado inherente. Toda base de datos se diseña, construye y
puebla con datos para un propósito específico. Esta dirigida a un grupo de usuarios.
Un Sistema de Gestión de Base de Datos (SGBD) es un conjunto de programas que
facilitan la definición, construcción y manipulación de base de datos.
Modelo Entidad – Relación
Los diagramas o modelos entidad-relación son una herramienta para el modelado de
datos de un sistema de información. Estos modelos expresan entidades relevantes para
un sistema de información, sus interrelaciones y propiedades.
El Modelo Entidad-Relación es un concepto de modelado para bases de datos, propuesto
por Peter Chen, mediante el cual se pretende visualizar los objetos que pertenecen a la
Base de Datos como entidades las cuales tienen unos atributos y se vinculan mediante
relaciones.
Los componentes de un diagrama entidad-relación son:
Entidad: es cualquier objeto discreto sobre el que se tiene información. Se representa
mediante un rectángulo o "caja" etiquetada en su interior mediante un nombre.
Relación: describe cierta interdependencia (de cualquier tipo) entre entidades. Se
representa mediante un rombo etiquetado en su interior mediante un verbo. Además,
dicho rombo debe unirse mediante líneas con las entidades que relaciona (es decir, los
rectángulos).
Atributos: son propiedades relevantes propias de una entidad y/o relación. Se representan
mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un
atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
Manejador de Bases de Datos
    El sistema  manejador   de bases de datos es la porción más importante del software
de un sistema de base de datos. Un DBMS es una colección de numerosas rutinas de
software interrelacionadas, cada una de las cuales es responsable de alguna tarea
específica.
Las funciones principales de un DBMS son:
 Crear y organizar la Base de datos.
 Establecer y mantener las trayectorias de acceso a la base de datos de tal forma
que  los datos puedan ser accesazos rápidamente.
  Manejar los datos de acuerdo a las peticiones de los usuarios.
 Registrar el uso de las bases de datos.
 Interacción con el manejador de archivos: Esto a través de las sentencias en DML
al comando del sistema de archivos. Así el Manejador de base de datos es el responsable
del verdadero almacenamiento de los datos.
 Respaldo y recuperación: Consiste en contar con mecanismos implantados que
permitan la recuperación fácilmente de los datos en caso de ocurrir fallas en el sistema de
base de datos.
 Control de concurrencia: Consiste en controlar la interacción entre los usuarios
concurrentes para no afectar la inconsistencia de los datos.
 Seguridad e integridad: Consiste en contar con mecanismos que permitan el
control de la consistencia de los datos evitando que estos se vean perjudicados por
cambios no autorizados o previstos.
El DBMS es conocido también como Gestor de Base de datos.
    En sí, un sistema manejador de base de datos es el corazón de la base de datos ya
que se encarga del control total de los posibles aspectos que la puedan afectar.
Microsoft Access
Posiblemente, la aplicación más compleja de la suite Microsoft Office, sea Access, una
base de datos visual. Como todas las modernas bases de datos que trabajan en el
entorno Windows, puede manejarse ejecutando unos cuantos click de mouse sobre la
pantalla. Access contiene herramientas de diseño y programación reservadas a los
usuarios con mayor experiencia, aunque incluye bases de datos listas para ser usadas;
están preparadas para tareas muy comunes, que cualquiera puede realizar en un
momento determinado –ordenar libros, archivar documentación, entre otros.
Arquitectura de Access.
Objetos que podemos encontrar:
 Tabla: objeto para definir y almacenar los datos.
 Consultas: objeto para visualizar de forma personal los datos de una tabla.
 Formularios: objeto para introducir y visualizar los datos obtenidos de una
consulta.
 Informes: objeto para imprimir los datos obtenidos de una consulta.
 Módulos: objeto formado por programas escritos en Visual Basic.
SQL
El Lenguaje de Consulta Estructurado (Structured Query Languaje) es un lenguaje
estándar de comunicación con base de datos relacionales que permite especificar
diversos tipos de operaciones sobre las mismas. Permite proyectar consultas a fin de
presentar información de interés de una base de datos.
Según García, A. (2003), "SQL es un lenguaje de base de datos normalizado, utilizado por
los diferentes motores de bases de datos para realizar determinadas operaciones sobre
los datos o sobre la estructura de los mismos". (p. 45)
SQL es el lenguaje normalizado que permite con cualquier tipo de lenguaje (ASP, PHP,
etc.) en combinación con cualquier base de datos (Access, SQL Server, MySQL, etc.) por
lo que se convierte en la actualidad en el estándar de la mayoría de los SGBD
comerciales.
SQL posee un lenguaje declarativo de alto nivel, permite la concesión y denegación de
permisos, implementa restricciones de integridad y controles de transacción, además que
se encuentra orientado a un conjunto de registros y no a registros individuales.
Metodología XP y AM
La metodología AM (Agile Modeling), es una metodología práctica para modelar y
documentar efectivamente el ciclo de vida del software. AM es simplemente una colección
de valores, principios y prácticas para el modelado del software, que se puede aplicar en
un proyecto de desarrollo del mismo de manera eficaz y ligera. Como se puede ver en la
Figura 1.5 la metodología AM puede ser adaptada a otras metodologías para el desarrollo
completo del software tales como XP o RUP, permitiéndole desarrollar un proceso del
software que cubra realmente sus necesidades.
La metodología XP, por sus siglas en ingles (eXtreme Programming), es un enfoque de
la ingeniería de software surgida a partir de la metodología de trabajo empleada por Kent
Beck, Wark Cunningham y Martin Fowler en el desarrollo del proyecto C3 para Chrysler.
XP se funda en cuatro valores: comunicación, simplicidad, feedback y coraje. Es la más
destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, XP se
diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Se puede considerar la programación extrema
como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se
pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de
vida del software.

Fases de la Programación Extrema

Fase: Planificación del proyecto.
Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P es
definir las historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas
escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles;
no se debe hablar ni de posibles algoritmos para su implementación ni de diseños de
base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte
de la aplicación que describen. También se utilizan en la fase de pruebas, para verificar si
el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de
implementar una historia de usuario, el cliente y los desarrolladores se reúnen para
concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal
para una historia de usuario es entre 1 y 3 semanas.
Release planning*: .Después de tener ya definidas las historias de usuario es necesario
crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias
de usuario que se crearán para cada versión del programa y las fechas en las que se
publicarán estas versiones. Un "Release plan" es una planificación donde los
desarrolladores y clientes establecen los tiempos de implementación ideales de las
historias de usuario, la prioridad con la que serán implementadas y las historias que serán
implementadas en cada versión del programa. Después de un "Release plan" tienen que
estar claros estos cuatro factores: los objetivos que se deben cumplir (que son
principalmente las historias que se deben desarrollar en cada versión), el tiempo que
tardarán en desarrollarse y publicarse las versiones del programa, el número de personas
que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado.
(*Release plan: Planificación de publicaciones).
Iteraciones Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes
deben seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron
el test de aceptación que se realizó al terminar la iteración anterior. Estas historias de
usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los
programadores.
Velocidad del proyecto: La velocidad del proyecto es una medida que representa la
rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el
número de historias de usuario que se pueden implementar en una iteración; de esta
forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas iteraciones.
Usando la velocidad del proyecto controlaremos que todas las tareas se puedan
desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta
medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con
el cliente un nuevo "Release Plan.
Programación en pareja: La metodología X.P. aconseja la programación en parejas pues
incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja
involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica
haciendo hincapié en la calidad de la función o método que está implementando, el otro
analiza si ese método o función es adecuado y está bien diseñado. De esta forma se
consigue un código y diseño con gran calidad.
Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y
expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que
ser fluidas y todo el mundo tiene que tener voz y voto.
Fase: Diseño.
Diseños simples: La metodología X.P sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y
esfuerzo desarrolla.
Glosarios de términos: Usar glosarios de términos y un correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que
supone ese problema.
Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que
implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar: es mejorar y modificar la estructura y codificación de códigos ya creados sin
alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para
procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que
contienen funcionalidades que no serán usadas y diseños obsoletos. Esto es un error
porque puede generar código completamente inestable y muy mal diseñado; por este
motivo, es necesario refactorizar cuando se va a utilizar código ya creado.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration)
permiten al programador centrarse y apreciar el desarrollo orientado a objetos
olvidándose de los malos hábitos de la programación procedural clásica.
Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede
escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden
escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las
clases que colaboran con cada responsabilidad.
Fase: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo;
su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una
historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son
los que crean las historias de usuario y negocian los tiempos en los que serán
implementadas. Antes del desarrollo de cada historia de usuario el cliente debe
especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando
se realicen los test que verifiquen que la historia implementada cumple la funcionalidad
especificada.
La codificación debe hacerse ateniendo a estándares de codificación ya creados.
Programar bajo estándares mantiene el código consistente y facilita su comprensión y
escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos implementados nos
ayudará a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es
exactamente lo que tiene que hacer el código a implementar y sabremos que una vez
implementado pasará dichos test sin problemas ya que dicho código ha sido diseñado
para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar en
pequeñas unidades, de esta forma se crearán primero los test para cada unidad y a
continuación se desarrollará dicha unidad, así poco a poco conseguiremos un desarrollo
que cumpla todos los requisitos especificados.
Como ya se comentó anteriormente, X.P opta por la programación en pareja ya que
permite un código más eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de código dónde las parejas de
programadores publican cada pocas horas sus códigos implementados y corregidos junto
a los test que deben pasar. De esta forma el resto de programadores que necesiten
códigos ajenos trabajarán siempre con las últimas versiones. Para mantener un código
consistente, publicar un código en un repositorio es una acción exclusiva para cada pareja
de programadote.
X.P también propone un modelo de desarrollo colectivo en el que todos los
programadores están implicados en todas las tareas; cualquiera puede modificar o
ampliar una clase o método de otro programador si es necesario y subirla al repositorio de
código. El permitir al resto de los programadores modificar códigos que no son suyos no
supone ningún riesgo ya que para que un código pueda ser publicado en el repositorio
tiene que pasar los test de funcionamiento definidos para el mismo.
La optimización del código siempre se debe dejar para el final. Hay que hacer que
funcione y que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el
planificado para ser finalizados no podrán ser terminados a tiempo se haga lo que se
haga, aunque se añadan más desarrolladores y se incrementen los recursos. La solución
que plantea X.P es realizar un nuevo "Release plan" para concretar los nuevos tiempos
de publicación y de velocidad del proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de
funcionamiento con entornos de desarrollo antes de programar. Nuestros test los
obtendremos de la especificación de requisitos ya que en ella se especifican las pruebas
que deben pasar las distintas funcionalidades del programa, procurando codificar
pensando en las pruebas que debe pasar cada funcionalidad.
Fase: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para comprobar el
funcionamiento de los códigos que vayamos implementando.
El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los métodos más
triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código que en
un futuro evaluará. Hay que crear los test abstrayéndose del futuro código, de esta forma
aseguraremos la independencia del test respecto al código que evalúa.
Como se comentó anteriormente los distintos test se deben subir al repositorio de código
acompañados del código que verifican. Ningún código puede ser publicado en el
repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el
uso colectivo del código (explicado en el apartado anterior).
El uso de los test es adecuado para observar la refactorización. Los test permiten verificar
que un cambio en la estructura de un código no tiene porqué cambiar su funcionamiento.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario. Para asegurar el
funcionamiento final de una determinada historia de usuario se deben crear "Test de
aceptación"; estos test son creados y usados por los clientes para comprobar que las
distintas historias de usuario cumplen su cometido.
Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se
harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en
la descripción de requisitos

Bases Legales
Este Proyecto se basa legalmente en la Constitución de la República Bolivariana
de Venezuela. (2000)
Artículo 57.
Toda persona tiene derecho a expresar libremente sus pensamientos, sus ideas u
opiniones de viva voz, por escrito o mediante cualquier otra forma de expresión, y de
hacer uso para ello de cualquier medio de comunicación y difusión, sin que pueda
establecerse censura. Quien haga uso de este derecho asume plena responsabilidad por
todo lo expresado. No se permite el anonimato, ni la propaganda de guerra, ni los
mensajes discriminatorios, ni los que promuevan la intolerancia religiosa.
Se prohíbe la censura a los funcionarios públicos o funcionarias públicas para dar cuenta
de los asuntos bajo sus responsabilidades. (p. 54)
Las personas tienen derecho a expresarse a viva voz y sin censura Pero tienen que
asumir las responsabilidades de lo dicho o expresado si causara daño a otras personas.
Artículo 58.
La comunicación es libre y plural, y comporta los deberes y responsabilidades que indique
la ley. Toda persona tiene derecho a la información oportuna, veraz e imparcial, sin
censura, de acuerdo con los principios de esta Constitución, así como a la réplica y
rectificación cuando se vea afectada directamente por informaciones inexactas o
agraviantes. Los niños, niñas y adolescentes tienen derecho a recibir información
adecuada para su desarrollo integral. (p. 55)
La comunicación es libre y plural y todos tenemos derecho a ella de manera veraz y
oportuna, y así como también un derecho a réplica cuando nos veamos afectados de
alguna manera .por alguna información.
Artículo 110.
El Estado reconocerá el interés público de la ciencia, la tecnología, el conocimiento, la
innovación y sus aplicaciones y los servicios de información necesarios por ser
instrumentos fundamentales para el desarrollo económico, social y político del país, así
como para la seguridad y soberanía nacional. Para el fomento y desarrollo de esas
actividades, el Estado destinará recursos suficientes y creará el sistema nacional
de ciencia y tecnología de acuerdo con la ley. El sector privado deberá aportar recursos
para los mismos. El Estado garantizará el cumplimiento de los principios éticos y legales
que deben regir las actividades de investigación científica, humanística y tecnológica. La
ley determinará los modos y medios para dar cumplimiento a esta garantía. (p. 98)
El Estado garantizara los recursos necesarios para la innovación de aplicaciones y los
servicios informáticos ya que son de gran interés para la nación también garantizaran el
cumplimiento de los principios éticos y legales.
Ley sobre derecho de autor. (2000)
Artículo 1°
Las disposiciones de esta Ley protegen los derechos de los autores sobre todas las obras
del ingenio de carácter creador, ya sean de índole literaria, científica o artística,
cualesquiera sea su género, forma de expresión, mérito o destino. Los derechos
reconocidos en esta Ley son independientes de la propiedad del objeto material en el cual
esté incorporada la obra y no están sometidos al cumplimiento de ninguna formalidad.
Quedan también protegidos los derechos conexos a que se refiere el Título IV de esta
Ley. (p. 9)
La ley protege los derechos de autor cualquiera sea su índole, genero, forma de
expresión, etc.
Artículo 2°
Se consideran comprendidas entre las obras del ingenio a que se refiere el artículo
anterior, especialmente las siguientes: los libros, folletos y otros escritos literarios,
artísticos y científicos, incluidos los programas de computación, así como su
documentación técnica y manuales de uso; las conferencias, alocuciones, sermones y
otras obras de la misma naturaleza; las obras dramáticas o dramático-musicales, las
obras coreográficas y pantomímicas cuyo movimiento escénico se haya fijado por escrito
o en otra forma; las composiciones musicales con o sin palabras; las obras
cinematográficas y demás obras audiovisuales expresadas por cualquier procedimiento;
las obras de dibujo, pintura, arquitectura, grabado o litografía; las obras de arte aplicado,
que no sean meros modelos y dibujos industriales; las ilustraciones y cartas geográficas;
los planos, obras plásticas y croquis relativos a la geografía, a la topografía, a la
arquitectura o a las ciencias; y, en fin, toda producción literaria, científica o artística
susceptible de ser divulgada o publicada por cualquier medio o procedimiento" (p. 9)
El artículo 2 se refiere a cuales son todas las obras de ingenio que se mencionan en el
artículo uno de la misma ley de derechos de autor, clasificándolas a cada una de ellas.
Artículo 6°
Se considera creada la obra, independientemente de su divulgación o publicación, por el
solo hecho de la realización del pensamiento del autor, aunque la obra sea inconclusa. La
obra se estima divulgada cuando se ha hecho accesible al público por cualquier medio o
procedimiento. Se entiende por obra publicada la que ha sido reproducida en forma
material y puesta a disposición del público en un número de ejemplares suficientes para
que se tome conocimiento de ella. (p. 12)
Una obra se considera creada con el simple hecho de haber sido pensada por el autor
sea publicada o no sea concluida o no. La obra publicada es aquella que se reproduce y
se pone a la disposición del público.
Artículo 9°
"Se considera obra hecha en colaboración, aquélla a cuya creación han contribuido varias
personas físicas. Se denomina compuesta la obra nueva en la cual esté incorporada una
obra preexistente sin la colaboración del autor de esta última". (p. 14)
Se considera una obra en colaboración cuando es realizada por varias personas, y obra
compuesta cuando se le agrega a una obra ya realizada a una nueva.
Artículo 10º
El derecho de autor sobre las obras hechas en colaboración pertenece en común a los
coautores. Los coautores deben ejercer sus derechos de común acuerdo. Se presume,
salvo prueba en contrario, que cada uno de ellos es mandatario de los otros en relación
con los terceros. En caso de desacuerdo, cada uno de los coautores puede solicitar del
Juez de Primera Instancia en lo Civil que tome las providencias oportunas conforme a los
fines de la colaboración.
Cuando la participación de cada uno de los coautores pertenece a géneros distintos, cada
uno de ellos podrá, salvo pacto en contrario, explotar separadamente su contribución
personal, siempre que no perjudique la explotación de la obra común. (p. 14)
Las obras hechas por un grupo de autores pertenecen a todos, en caso de alguno no
querer permanecer más en el grupo se le debe solicitar a un juez para que tome las
providencias necesarias.
Artículo 17º
Se entiende por programa de computación a la expresión en cualquier modo, lenguaje,
notación o código, de un conjunto de instrucciones cuyo propósito es que un computador
lleve a cabo una tarea o una función determinada, cualquiera que sea su forma de
expresarse o el soporte material en que se haya realizado la fijación. El productor del
programa de computación es la persona natural o jurídica que toma la iniciativa y la
responsabilidad de la realización de la obra. Sin perjuicio de lo dispuesto en el artículo
104 de esta Ley, y salvo prueba en contrario, es producto del programa de computación la
persona que aparezca indicada como tal de la manera acostumbrada. Se presume salvo
pacto expreso en contrario, que los autores del programa de computación han cedido al
productor, en forma ilimitada y por toda su duración, el derecho exclusivo de explotación
de la obra, definido en el artículo 23 y contenido en el Título II, inclusive la autorización
para ejercer los derechos a que se refieren los artículos 21 y 24 de esta Ley, así como el
consentimiento para decidir sobre su divulgación y la de ejercer los derechos morales
sobre la obra, en la medida que ello sea necesario para la explotación de la misma. (p.
21)
Lenguaje de programación es una expresión realizada por códigos que sirven para hacer
funcionar las computadoras las personas que realizan los lenguajes pueden ser naturales
o jurídicas.
Ley De Impuesto Sobre La Renta (2001)
Artículo 179.
Se acumulará en la cuenta de reajuste por inflación como un aumento o disminución de la
renta gravable, el mayor o menor valor que resulte de reajustar el valor neto actualizado
de los activos y pasivos no monetarios, existentes al cierre del ejercicio gravable, distintos
de los inventarios y las mercancías en transito, según la variación anual experimentada
por el Índice de Precios al Consumidor (1PC) del Área Metropolitana de Caracas,
elaborado por el Banco Central de Venezuela, si dichos activos y pasivos provienen del
ejercicio anterior, o desde el mes de su adquisición, si han sido incorporados durante el
ejercicio gravable.
El valor neto actualizado de los activos y pasivo no monetario deberá depreciarse,
amortizarse o realizarse, según su naturaleza, en el resto de la vida útil.
Parágrafo Único: El valor neto actualizado de los activos y pasivos no monetarios es igual
al valor actualizado del costo de adquisición menos el valor actualizado de
la depreciación, amortización o realización acumulados. (p. 165)
Reajustar al cierre de cada ejercicio gravable, sus activos y pasivos no monetarios,
el patrimonio al inicio del ejercicio y los aumentos y disminuciones del patrimonio durante
el ejercicio, distintos de las ganancias o las pérdidas. El mayor o menor valor que se
genere al actualizar los activos y pasivos no monetarios.
Artículo 183
Se cargará o abonará a la cuenta de activos correspondiente, y se abonará o cargará a la
cuenta de reajuste por inflación, el mayor o menor valor que resulte de reajustar los
inventarios existentes en materia prima, productos en proceso o productos terminados
para la venta, mercancía para la venta o mercancía en transito, a la fecha de cierre del
ejercicio gravable, utilizando el procedimiento que se especifica a continuación: 
a. El inventario final ajustado en el ejercicio fiscal anterior se reajusta con la variación
experimentada por el Índice de Precios al Consumidor (IPC) del Área Metropolitana de
Caracas, elaborado por el Banco Central de Venezuela, correspondiente al ejercicio
gravable. 
b. Se efectuará una comparación de los totales al costo histórico de los inventarios de
materia prima, productos en proceso, productos terminados o mercancía para la venta y
mercancía en transito, al cierre del ejercicio gravable con los totales históricos al cierre del
ejercicio gravable anterior. Si de esta comparación resulta que el monto del inventario final
es igual o menor al inventario inicial, se entiende que todo el inventario final proviene del
inicial. En este caso, el inventario final se ajustará en forma proporcional al inventario
inicial reajustado, según lo establecido en el literal a del presente artículo. 
c. Si de la comparación prevista en el literal anterior, resulta que el inventario final excede
al inventario inicial, la porción en bolívares que excede del inventario inicial, no se
ajustara. La porción que proviene dl inventario inicial se actualizará en forma proporcional
al inventario inicial reajustado según lo establecido en el literal a del presente artículo. 
d. El inventario final actualizado según la metodología señalada en los literales anteriores,
se comparará con el valor del inventario final histórico. La diferencia es el ajuste
acumulado al inventario final. 
e.  Se comparará el ajuste acumulado al inventario final obtenidos por la comparación
prevista en el literal d, con el ajuste acumulado en el inventario final en el cierre del
ejercicio tributario anterior. Si el ajuste acumulado al inventario final del ejercicio tributario
es superior al ajuste acumulado al inventario final en el cierre del ejercicio tributario
anterior, la diferencia se cargará a la respectiva cuenta de inventario del activo del
contribuyente con crédito a la cuenta Reajuste pro Inflación. 
f.  Si la comparación del literal anterior se deduce que el ajuste acumulado al inventario
final del cierre tributario es inferior al ajuste acumulado al inventario en el cierre del
ejercicio tributario anterior, la diferencia se acreditará a la respectiva cuenta de inventario
del activo del contribuyente y se cargará a la cuenta Reajuste por Inflación. 
Parágrafo Primero: Si los inventarios de accesorios y repuestos se cargan al costo de
venta por el procedimiento tradicional del costo de venta deben incluirse en este
procedimiento. Si el cargo al costo de venta se hace a través de cargos a los gastos de
fabricación u otra cuenta similar, los inventarios de accesorios y repuestos deben tratarse
como otras partidas no monetarias y actualizarse de conformidad con el artículo 179 de
esta Ley. 
Parágrafo Segundo: Cuando el contribuyente utilice en su contabilidad de costos el
sistema de valuación de inventarios denominado de identificación especifica o de precios
específicos, podrá utilizar las fechas reales de adquisición de cada producto
individualmente considerado, previa aprobación por parte de la Administración Tributaria,
para actualizar los costos de adquisición de los saldos de los inventarios al cierre de cada
ejercicio gravable. El ajuste correspondiente al ejercicio gravable será la diferencia entre
los ajustes acumulados del ejercicio gravable y los ajustes acumulados al ejercicio
gravable anterior. Si el ajuste al ejercicio gravable es superior al ajuste al ejercicio
gravable anterior, se hará un cargo a la cuenta de inventario y un crédito a ola cuenta
Reajustes por Inflación, caso contrario el asiento será al revés. (p. 170)
Tanto en la cuenta de activos como en la cuenta de reajuste, esta ultima por inflación. Se
cargaran y/o abonaran el resultado que este arroje en cuanto a inventarios en materia
prima, los productos y materiales que se encuentren en proceso o ya terminados para la
venta.
Definición y Operacionalización de Variable
La identificación y operacionalización de las variables se utilizan sobre todo en las
investigaciones para poder comprobar empíricamente las variables de la hipótesis o
encontrar las evidencias de los aspectos o dimensiones de los objetivos.
Según Bernardo y Caldero, (2000), "las variables se refieren a las propiedades que se van
a estudiar y responder a la pregunta: ¿Qué medimos o estudiamos?, ¿Qué aspectos o
dimensiones podemos observar?, ¿Qué dimensiones podemos experimentar?" (p. 2)
Cuadro N° 1 Operacionalización de Variables
Objetivo General: Diseñar un sistema para el control del inventario de la empresa
Inversiones MIWILL, C.A
Definición
Obj. Especifico Variables Dimensiones Indicadores
Conceptual
- ¿Requiere la
empresa
Diseñar un software Inversiones
que permita llevar el MIWILL,C.A, el
control de inventario de diseño de un
la empresa Inversiones software de
MIWILL,C.A, el cual Control de Mide todo lo control de
permitirá realizar un inventario referente a Procedimental inventario?
efectivo control en   inventario - ¿Cómo le
tiempo real de los gustaría que el
productos existentes inventario se
dentro del almacén o clasificara:
depósito de la empresa. por familia, por
proveedor, por
producto?
Establecer a
Diagramar el proceso través de - ¿Cuál es el
actual para el control de diagramas proceso mediante
inventario de la Proceso actual cuales son los Procedimental el cual se lleva el
empresa Inversiones pasos a seguir control de
MIWILL,C.A, para el control inventario?
de inventario
- ¿Cuál es tu nivel
de instrucción?
- ¿Tienes
conocimientos en
el manejo de
Realizar cursos de Computadoras?
Capacitación
adiestramiento para el - ¿Posees alguna
del personal
personal encargado del Adiestramiento experiencia con
para un mejor
manejo del sistema para el Humana sistemas de
manejo del
computarizado, para la personal inventario?
sistema a
puesta en marcha del - ¿Desearía usted
implantar.
mismo. realizar cursos de
adiestramiento en
caso de
implementar algún
sistema de
inventario?