SISTEMA DE INFORMACION PARA EL CONTROL Y

SEGUIMIENTO DE LA COMERCIALIZACION DE MINERALES

(FEDECOMIN-ORURO)

1.1. INTRODUCCIÓN
Bolivia históricamente ha sido considerada un país minero por excelencia. Desde la
época de la colonia la Gran Audiencia de Charcas tenía como base de su crecimiento la
explotación de minerales especialmente la plata, eran el motor de desarrollo de la región e
incluso de la Corona Española.

Durante la época de la Constitución de la República, la minería fue el principal

motor de crecimiento económico, siendo la plata en un principio el mineral por excelencia,
posteriormente en el Siglo XX pasó a ser el estaño siendo el principal mineral de
exportación. Bolivia se constituyó en uno de los principales países productores de estaño,
encontrándose las principales minas en los departamentos de Oruro, Potosí y parte de La
Paz.

En la actualidad el sector minero es un motor de crecimiento, que genera apoyo

económico hacia otros sectores, con la Reforma del Régimen Impositivo de la Minería
que fue aprobado mediante (Ley 3787 del 24 de Noviembre 2007 y reglamentada por el D.
S. Nº 29577 del 21 de Mayo 2007).

Decreto Supremo Nº 29165 del 13 de Junio del 2007, fue creado para servicio
nacional de registro y control de la comercialización de minerales y metales –
SENARECOM 

Hoy en día las principales exportaciones bolivianas están compuestas por minerales
como el estaño, el zinc y gas natural

Según XX Congreso Ordinario de la FENCOMIN en fecha del 29 al 31 de Enero

del 2009 en la Ciudad de Llallagua, la comisión económica acordó las siguientes
resolución; numeral 6.2 Buscar, en el corto plazo, la creación de comercializadora de
minerales y metales; propias de las Cooperativas Mineras y actualmente se encuentra en
proceso de funcionamiento desde ---------------- en la ciudad de Oruro.
1.2. ANTECEDENTES.

1.2.1. ANTECEDENTES DEL PROYECTO

Como los procesos que se llevan a cabo, especialmente para el control de

comercialización de la producción del estaño y otros minerales son sumamente complejos,
los sistemas de información desarrollados hasta el momento, han resultado ser simples
herramientas de control muy limitados y sectorizados, todos dirigidos al control financiero
exclusivamente y en la mayoría de los casos, cada cooperativa minera vela por su interés al
implementar sistemas de información que sean o no informáticos.

También es prudente mencionar que el desarrollo en sí de sistemas de información

personalizados y acorde a las necesidades y requerimientos de la empresa en nuestro país,
por el momento son bajos y de poco alcance, ya que nuestras empresas aún se encuentran
en el proceso de adaptación de nuevas tecnologías para mejorar los procesos internos y
poder cumplir con todas las demandas y exigencias tanto a nivel local como internacional.

Por otro lado, no existen sistemas desarrollados, que seleccione según porcentaje de
leyes1 y pesos por cada lote2 del mineral producido por cuadrilla3, para generar distribución
según categoría:

Distribución de % leyes según categorías Distribución de lotes según categorías

Ley Baja 25.00% - 45.00% Lote pequeño 26.00 kl hasta 200 Kl

200.01 kilos hasta 650

Ley Media 45.01% - 55.00% Lote mediano Kilos

650.01 kilos hasta 1000

Ley Alta 55.01% - 70.00% Lote grande Kilos

1000.01 kilos hasta xxx

Ley fuera 70.01% - xxx.00% Lote extra grande Kilos no conjugar con
de categoría Penalizar o turna guía otros lotes

FIGURA 1. Distribución según categoría de porcentaje de leyes y lotes

Fuente: Cooperativa la salvadora.

1
Leyes: Termino minería = Calidad del mineral.
2
Lote: Termino minería = Cada una de las partes de un todo que se ha de unir o repartir.
3
Grupo de cuatro o más personas.
 1.2.2. ANTECEDENTES DEL CONTEXTO.

La Federación Departamental de Cooperativas Mineras de Oruro con sigla de

FDEDECOMIN ORURO, fue fundada en fecha 7 de Abril de 1960 con 12 Cooperativas
mineras en diferentes regiones del Departamento de Oruro

Esta organización se creó con gran esfuerzo y una gran diversidad de problemas que fueron
superados en varias reuniones o asambleas y así paulatinamente la Federación fue
controlando el aparato productivo del departamento, En la fundación de FENCOMIN
participó activamente con 24 Cooperativas afiliadas entre las cuales algunas Cooperativas
son consideradas antiguas por su trayectoria tal es el caso de La Cooperativas “Chicote
Grande”, “La Salvadora” y otras más, de las 24 Cooperativas afiliadas de las cuales 11
Cooperativas son de Oruro, 9 Cooperativas de Potosí “Provincia Chayanta y Bustillo”, 3
Cooperativas de Cochabamba “Provincia Ayo Paya”, la Cooperativa de La Paz “Provincia
Inquisivi”, contribuyo en la organización de algunas Centrales como por ejemplo. Central
Colquiri y la desaparecida otrora Central o Federación Huanuni

Tiene Personería Jurídica Numero 01876, tiene como sede oficial la Ciudad de Oruro en la
cual tiene dos inmuebles de su propiedad ubicados en la Calle Montesinos N. 446 entre las
calles Potosí y 6 de Octubre, y el otro ubicado en la carretera a Vinto Km. 3 ½ s/n, Tel.
5247029, son productores de complejos, estaño Zinc, Plata, Plomo y el metal precioso Oro
 ORGANIGRAMA DE UNA COOPERATIVA MINERA
ASAMBLEA GENERAL

CONCEJO DE ADMINISTRACIÓN CONCEJO DE VIGILANCIA

Presidente administración Presidente de Vigilancia

Strio General Strio. Vigilancia

Tesorería Vocal

Representante Pallires Dpto. Transporte Deportes

Representantes C.N.S. Presidente Transporte Presidente Deportes Jefe de Sec. Gerente

Representantes Vocal Vocal Cuadrillas

Casas y Tierras

1° Vocal
UNIDA DE ADMINISTRACIÓN CONTABLE UNIDA TÉCNICA MINERÍA Y METALURGIA

2° Vocal
Minería Ingenio de Concentración
Sistema Contador o Secretaria
Información Cajero
Secciones
Jefe de Punta Jefe de punta
Primera Segunda
Cuadrillas

FIGURA 2. Organigrama de la Cooperativa Minera La Salvadora Ltda.

Oruro
Fuente: cooperativa Salvadora

1.2.3. TRABAJOS REALIZADOS

No se ha realizado ningún trabajo anterior ni se tiene registros de trabajos

foráneos que traten los procesos de comercialización y producción de los
minerales en las cooperativas

1.3. PLANTEAMIENTO DEL PROBLEMA.

1.3.1. ANÁLISIS DEL PROBLEMA.

Como ya se ha mencionado, cada cooperativa, principalmente su departamento

administrativo, es el responsable de velar por el correcto funcionamiento sobre todos los
procesos administrativos existentes en la institución; de esta forma y tras un completo y
profundo análisis de la documentación, se encontraron las siguientes deficiencias.
  No existe un adecuado control de información en la comercialización del
estaño, a Fundición Vinto y a otras comercializadoras de minerales, lo que
ocasiona: sobresaturación de tareas, falta de oportunidad en la información
y existe disconformidad por parte de los socios.

 Para el cálculo de planilla de pagos se utiliza hojas electrónicas (Microsoft

Office Excel), por el cual existen redundancia de datos e inseguridad de la
información; por el cual extiende recibo ha manuscrito a los trabajadores.

 Los informes que se realizan acerca de la producción y comercialización

de los minerales en las cooperativas no son oportunos y no contiene la
información necesaria para efectuar cuadros de producción y
comercialización.

 Los datos e información de los trabajadores no es correctamente

manejado; así como no se cuenta con un registro adecuado de las
papeletas de pago ni los descuentos ni los aportes de los trabajadores que
realizan cada mes. ocasionando grandes problemas en el momento de
realizar transacción o informes.

 No cuenta con un registro de control adecuado de los trabajadores, puesto

que muchos pertenecen a más de una sección o cuadrilla.

 La ley de los minerales alta, media, baja, y lotes por categoría no son
seleccionados correctamente para conjunción4 de varios lotes, causando así
pérdidas económicas a las Cooperativas.

1.3.2. FORMULACIÓN DEL PROBLEMA.

No se cuenta con un adecuado registro de la información obtenida en el

proceso de comercialización de los minerales en las cooperativas así
también en el proceso de cancelación por producción que tienen las
cuadrillas por la extracción de minerales s esto ocasiona pérdidas
económicas a las cooperativistas.

4
mesclar y/o homogenizar las bolsas de barrilla
 1.3.3. OBJETO DE ESTUDIO

El objeto de estudio será el sistema de información que manejan en las

cooperativas sobre los procesos de comercialización y producción de los
minerales extraídos por los trabajadores y sus respetivas cuadrillas.

1.4. OBJETIVOS.

1.4.1. OBJETIVO GENERAL.

Desarrollar e implementar el Sistema de Información Administrativo, que permita a la

FEDECOMIN-OR. Mejorar el procesamiento de la información generada en las
cooperativas, brindando la información en forma oportuna, confiable y actualizada para la
planificación, ejecución y comercialización de los minerales que producen las cooperativas
asociadas como apoyo para la toma de decisiones y evitar pérdidas económicas.

1.4.2. OBJETIVOS ESPECÍFICOS.

Los objetivos específicos que permiten dar cumplimiento al objetivo

general son:

 Identificar los requerimientos funcionales y no funcionales de las

cooperativas que están en FEDECOMIN-OR para lograr un adecuado
estudio y desarrollo del proyecto.

 Diseñar y Normalizar la base de Datos del Sistema de Información para

tener una estructura ordenada y robusta de los datos que genera el sistema

 Construir el sistema de Información con un conjunto de interfaces que

permitan emitir los reportes de manera simple y rápida

 Implementar el software Sistema Información Administrativa en

FEDECOMIN-OR. para desarrollar las pruebas pertinentes, y comprobar así
la robustez y alcances del sistema.
1.5. JUSTIFICACIÓN

1.5.1. JUSTIFICACIÓN ECONÓMICA.

El proyecto se justifica económicamente por la justa razón de que se

automatiza el proceso de registro de la producción, así también se evita malos
manejos en los registros de los pagos, descuentos, penalidades y bonos que tienen
los cooperativistas cada mes al recibir su papeleta e de pago por la mitas
trabajadas. La inversión para el presente proyecto no supera los beneficios
obtenidos por los cooperativistas puestos que el sistema está desarrollado
totalmente con licencias gratuitas (PHP, MYSQL SERVER) en el código fuente y
en el servidor de la base de datos. La inversión alcanzaría a comprar si es necesario
un equipo computacional que sirva como servidor para la aplicación

1.5.2. JUSTIFICACIÓN SOCIAL.

Con la implantación del nuevo sistema de información se benefician directamente

el personal de apoyo y todos los trabajadores de las Cooperativas que pertenecen a
FEDECOMIN-OR, ya que se logró obtener información oportuna y confiable,
proporcionando estabilidad y confiabilidad en los procesos administrativos de las
cooperativas mineras de Oruro.

1.6.1. ALCANCES, LIMITES Y APORTES.

1.6.2. ALCANCES

El sistema a desarrollar contempla:

 Registro de trabajadores y designando a su respectiva Cooperativa y en

en que sección y cuadrilla trabaja.
 Registro de comercializadoras de minerales.
 Registro Recepción de Mineral y alícuotas.

 Registro de descuentos.

 Registrar análisis químico.

 Administrador de la comercialización de los Minerales.

 Genera papeleta de pago y otras consultas que requiera la Cooperativa.

 1.6.3. LIMITES

El sistema es aplicable en cualquier Cooperativa Minera; el prototipo

demostrativo se aplica en la Cooperativa Minera “La Salvadora” Ltda. Oruro,
debiendo ser administrado por una persona responsable y entendida en la
comercialización de minerales, tanto administrativo y financiero.

1.6.4. APORTES.

El aporte más importante que ofrece el software desarrollado, es mejorar los

procesos de comercialización de los minerales, eliminando así los procesos redundantes y
manuales que provocan incertidumbre, disconformidad de los trabajadores y personal de
apoyo de las cooperativas. Para obtener una información útil, oportuna, confiable,
comprensible y verificable que sea soporte adecuado al desempeño de las actividades
administrativas y a la toma de decisiones.

1.7. INGENIERIA DEL PROYECTO

OBJETIVO ESPECIFICO METODO O TECNICA ACTIVIDAD

Identificar los OBSERVACION Analizar los procesos

requerimientos funcionales existentes en las
CUESTIONARIO
y no funcionales de las cooperativas, para
cooperativas que están en ENTREVISTAS estructurar y automatizar los
FEDECOMIN-OR para mismos
lograr un adecuado estudio y REVISION DE

desarrollo del proyecto. REGISTROS

Diseñar y Normalizar la Diseño Conceptual - Construir el modelo que

base de Datos del Sistema represente todos los datos de
Diagrama de clases (UML)
de Información para tener la institución
una estructura ordenada y Modelo E-R
- Construir el modelo de la
robusta de los datos que
genera el sistema Homogenización de la Base organización basado en el
de datos modelo de datos

Normalización - Generar como va ser la

implementación de la base
 de datos

Lenguaje unificado de Modelado del sistema de

Modelación (UML) Información

Diagrama de Casos de Uso

Diagramas de Secuencia

Diagramas de Actividades

Diagramas de Estado

Diagramas de Clases

Construir el sistema de Implementación Diseño41 de la interfaz de

Información con un usuarios
PHP, AJAX, SQL, HTML,
conjunto de interfaces que
CSS Programar código PHP
permitan emitir los reportes
HTML, SQL, CSS, AJAX
de manera simple y rápida MYSQL
Desarrollar pruebas de
APACHE
excepciones

Contratación e Instalación la
aplicación web en el
servidor del servidor de
páginas web y la Base de
Datos

Realizar pruebas de caja

Blanca

Realizar pruebas de caja

Negra

CAPITULO II
 MARCO TEÓRICO

2.1. PROCESO DE PRODUCCIÓN Y COMERCIALIZACIÓN DE MINERALES

La producción y la comercialización son partes importantes de todo un sistema

comercial destinado a suministrar a los consumidores los bienes y servicios que satisfacen
sus necesidades. Al combinar producción y comercialización, se obtienen las cuatro
utilidades económicas básicas: de forma, de tiempo, de lugar y de posesión, necesarias para
satisfacer al consumidor.

Las cooperativas mineras explotan minerales; por lo cual comercializan sus

productos a las empresas comercializadoras y a empresas fundidoras. El proceso de
comercialización de minerales es la cadena de compra y venta de minerales en bruto o
concentrados.

CONCENTRADOR
MINERAL Ingenio de Coop.
BRUTO
RESCATADOR

Coop. Min. INDUSTRIA

FUNDIDOR
Coop-Min

COMERCIALIZADOR
MANUFACTUREROS
EXTERNO CORREDORES BOLSA
MINERAL
CONCENTRADO
Coop. Min.
FUNDIDOR
INTERNO
(Empresa Metalúrgico Vinto)

FIGURA 3. Flujo de caja en el proceso de comercialización

Fuente: FEDECOMIN-OR

2.1.2. CONTRATO DE COMPRA Y VENTA DE MINERALES

 Debe reunir por lo menos las siguientes condiciones: Forma legal de los contratos:
Cantidad, calidad, precios (base, fijo o por formula), castigos, forma de pago,
forma de muestreo, humedad, granulado, lugar de entrega y conforme al reglamento
de SENARECOM5 .

Finalmente, la elaboración de un contrato de compra y venta de minerales

debe ser llevado a cabo con las mejores relaciones, porque será el instrumento que
sirva para la estabilidad de la cooperativa.

PRECIO BASE.

Se utiliza en base a la calidad determinada, la cotización se establece por tonelada,

la calidad ideal debería ser constante, sin embargo esto no acontece generalmente,
por lo que se establecen premios y castigos cuando las leyes del producto se alejan,
ya sea ascendente o descendente de la ley base. Considerando este análisis es
desventajoso para los Cooperativistas

. PRECIO FIJO.

El valor del producto es independiente de toda variable, dependiendo más

bien determinadas cualidades o características ya sean físicas o químicas y que se
clasifican por ello en diversas categorías para cada producto; el precio está de
acuerdo a los valores netos recibidos por concentrados.

PRECIO POR FORMULA.

Para la determinación del producto se utilizan fórmulas que tienen en cuenta

los siguientes aspectos:
- Cotización del mineral.

5
“Servicio Nacional de Registro y Control de la Comercialización de Minerales y Metales” se crea a través
del D.S. 29165 de 13 - 06 - 08. es una entidad pública descentralizada
 - Gastos de tratamiento, gastos de realización seguro, penalidades,
bonos, regalías mineras y etc.

La relación de precio entre el mineral y el metal, las fluctuaciones o

variaciones del precio del mineral se reflejan necesariamente en el valor del metal y
sería ilógico considerar que pueda subir o bajar el precio del mineral sin que
simultáneamente no suba o baje el precio del metal, entonces a una fecha
determinada, el precio del metal y mineral es el mismo considerando la ley o
porcentaje contenido de metal en el mineral [2].

ANÁLISIS QUÍMICO.
Se realiza en laboratorio químicos, y ellos extienden certificados con sus
respectivas leyes del mineral, impurezas y humedad [2].

LEY DEL MINERAL.

Es la cantidad de metal existente en un mineral y que se determine mediante

ensayes.

Cuando se dice: Estaño mineral de 600%, quiere decir que en 100 partes de
mineral hay 60 partes de estaño metálico [2].

LIQUIDACIÓN-

Es el valor en dinero del mineral luego de haber obtenido su ley, es

realizada por el vendedor, comercializador o comprador según formula: Valor
Bruto de Ventas y Valor Neto venta, etc.

2.1.3 DETERMINACIÓN DE HUMEDAD EN LOS MINERALES.

Para conocer la cantidad de agua contenida en los minerales se procede con los
siguientes pasos:

1.- Se pesa en un recipiente una cantidad determinada de mineral.

 2.- Del peso anterior se resta el peso del recipiente. Calentando fuertemente el
mineral para eliminar la humedad y en absoluta sequedad.
3.- Se pesa el secado juntamente con el recipiente. Ejemplo:
1.- Peso del mineral húmedo y recipiente: => 40 Gramos
2.- Peso del recipiente: => 15 Gramos
3.- Peso del mineral y recipiente en seco => 25 Gramos
4.- Peso del mineral seco y recipiente => 37 Gramos
5.- En 25 gramos de mineral la cantidad de agua es de 3 gramos
6.- (3 * 100) / 25 = 12% de Humedad [2].

2.1.4. PENALIDAD Y/O CASTIGOS.

El desconocimiento sobre los contenidos de los diferentes elementos, tanto

en el mineral bruto como en el estéril y en los concentrados, es a menudo una causa de
que los resultados económicos sean deficientes, o sea no óptimos para los cooperativistas.
Generalmente se analizan solo los contenidos de los metales o impurezas deseados en el
concentrado.

Muchos metales y elementos no deseados por las fundiciones, cuando

sobrepasan un límite en el concentrado, son motivo de castigo que se traducen en
descuentos en los precios. De estos elementos de impurezas están determinados en tablas
estándar en fundiciones de acuerdo a la situación del mercado. Por lo cual es imposible
obtener datos exactos sobres estos elementos y sus límites.

Los castigos pueden llevar a grandes disminuciones de ganancias en las

operaciones mineras. De esta manera es bueno investigar las impurezas en zona de trabajo,
antes del inicio las actividades mineras.
Formula de penalidades es el siguiente:
PENALIDAD = (((ley limite – ley exceso) / % acertada)*penalidades )/factores de peso*peso del mineral

ELEMENTO QUÍMICO
DESCRIPCION
DE IMPUREZA
Bi Bismuto En casi todos los concentrados.
Hg Mercurio En casi todos los concentrados.
Se Selenio En casi todos los concentrados.
As Arsénico En concentrados de Sn, Pb y Ag.
Cu Cobre En concentrados de Sn, Pb y Ag.
Cd Cadmio En concentrados de Sn, Pb y Ag.
S Azufre En concentrados de minerales óxidos con calor.

FIGURA 4. Espectrolack elementos de impurezas

Fuente: Investigación Carrera de Metalurgia F.N.I.

CONJUNCIÓN.

Es el proceso de mezclar y/o homogenizar las bolsas de barrilla entregado por el

trabajador; para formar un solo lote, para su comercialización.

TOMA DE MUESTRA.

Se siguen los siguientes pasos:

 Se vacía en el suelo el mineral, depositando siempre en el centro, para que forme

un cono creciente.

 Se retira el material por los laterales del cono hasta que se pierda el vértice, luego
se lo aplasta y extiende hasta formar una torta, de esta manera se homogeniza en
parte el material.
 Se divide la torta en cuatro partes, las dos partes: que se encuentran frente a frente
se coloca las otras dos partes al saco, y las dos otras partes nuevamente se realiza el
mismo proceso anterior es decir que se vuelve a formar un nuevo cono y así
sucesivamente hasta llegar a la muestra representativa de 100%.
La muestra final se divide en tres partes:
 A. Muestra para el vendedor
B. Muestra para el comprador
C. Muestra para una posible seguridad (arbitraje)

Las muestras A y B, son enviados al mismo laboratorio con una numeración clave
diferente.

TARA O MERMA

Tara unidad multiplicado por sacos barrilleros

Tara (T)= Tara unidad * sacos barrileros

RECEPCIÓN Y PESAJE.

Es la entrega del mineral en sacos de barrila6 más tara7; tonado el pesaje en

balanzas de alto tonelaje; decepcionado en bodega barrilero de la cooperativa.

Peso Mineral (PM)= Peso Bruto Húmedo + T

PESO BRUTO HÚMEDO (PBH).

Es la determinación del PBH; Tara unidad por sacos barrilleros menos peso
mineral:

Peso Bruto Húmedo (PBH) = (Tara unidad * Sacos barrileros) - PM

PESO NETO SECO.

Es el peso bruto húmedo por porcentaje de humedad entre cien menos peso bruto
húmedo:

Peso Neto Seco (PNS) = (PBH * % de Humedad)/100 – PBH

6
Barrilla: en el mismo nombre de mineral o metal.
7
Tara: Es el peso de sacos barrilleros.
 PESO FINO (PF).

Es el contenido del metálico que contiene el concentrado (PF), al que se aplica el

porcentaje de la Ley determine mediante ensayes.

Peso Fino (PF) = (PNS x Ley) / 100

2.1.5. CONVERSIONES DE FACTORES DE PESO (CFP).

Son conversiones factores de peso según matemática, físicas y químicas.

Conversión de Peso (CP) = (PF * CFP)/unidad equivalente

VALOR BRUTO VENTAS (VBV).

Se obtiene con los datos de Peso Fino por conversión de peso y cotización del
mercado internacional en la fecha que realiza la entrega y multiplicando por tipo de cambio
oficial o quincenal.

VALOR VENTA NETA (VVN).

Valor Bruto Ventas (VBV) = (CP * Cot. Ofi.) * Tip. Cam. Oficial. O quincenal

Se obtiene según los contratos realizados entre la cooperativa y comercializadoras

VALOR VENTA NETA (VVN) = ((PF* Ley de Cotiz. Pagable Sn)/ 100* Cotización Oficial) * CFP
2.2. SISTEMAS DE INFORMACIÓN.

Un sistema de información (SI) es un conjunto organizado de elementos, estos

elementos son de 4 tipos:

 Personas.
 Datos.
 Actividades o técnicas de trabajo.
 Recursos materiales en general (típicamente recursos informáticos y de
comunicación, aunque no tienen por qué ser de este tipo obligatoriamente).

Todo ese conjunto de elementos interactúan entre sí para procesar los datos y la
información (incluyendo procesos manuales y automáticos) y distribuirla de la manera más
adecuada posible en una determinada organización en función de sus objetivos.

Los Sistemas de Información cumplen tres objetivos básicos dentro de las

organizaciones:

1. Automatización de procesos operativos.

2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
3. Lograr ventajas competitivas a través de su implantación y uso.

Reporte e
Entrada Informes
De Datos

Procesos

Interface De Almacenamiento Interface De

Entrada Salida

FIGURAN 4 Objetivos de un sistema de información

Fuente: [18]
 2.2.1. TIPOS DE SISTEMAS DE INFORMACIÓN.

Según la función a la que vayan destinados o el tipo de usuario final del mismo, los SI
pueden clasificarse en:

 Sistema de procesamiento de transacciones (TPS).- Gestiona la información

referente a las transacciones producidas en una empresa u organización.
 Sistemas de información gerencial (MIS).- Orientados a solucionar problemas
empresariales en general.
 Sistemas de soporte a decisiones (DSS).- Herramienta para realizar el análisis de
las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de
decisiones.
 Sistemas de información ejecutiva (EIS).- Herramienta orientada a usuarios de
nivel gerencial, que permite monitorizar el estado de las variables de un área o
unidad de la empresa a partir de información interna y externa a la misma.
 Sistemas de automatización de oficinas (OAS).- Aplicaciones destinadas a ayudar
al trabajo diario del administrativo de una empresa u organización.
 Sistema experto (SE).- Emulan el comportamiento de un experto en un dominio
concreto.
 Sistema Planificación de Recursos (ERP).- Integran la información y los procesos
de una organización en un solo sistema.

2.2.2. ACTIVIDADES QUE REALIZA UN SISTEMA DE INFORMACIÓN.

Un sistema de información realiza cuatro actividades básicas: entrada,

almacenamiento, procesamiento y salida de información.

Entradas:

 Datos generales del cliente: nombre, dirección, tipo de cliente, etc.

 Políticas de créditos: límite de crédito, plazo de pago, etc.
 Facturas (interface automático).
 Pagos, depuraciones, etc.
Proceso:

 Cálculo de antigüedad de saldos.

 Cálculo de intereses moratorios.
 Cálculo del saldo de un cliente.

Almacenamiento:

 Movimientos del mes (pagos, depuraciones).

 Catálogo de clientes.
 Facturas.

Salidas:

 Reporte de pagos.
 Estados de cuenta.
 Pólizas contables.
 Consultas de saldos.

2.2.3. CLASIFICACION DE SISTEMAS DE INFORMACIÓN.

De acuerdo a sus características los sistemas de información se clasifican en:

Sistemas Transaccionales. Sus principales características son:

 A través de éstos suelen lograrse ahorros significativos de mano de obra, debido a

que automatizan tareas operativas de la organización.

 Con frecuencia son el primer tipo de Sistemas de Información que se implanta en

las organizaciones. Se empieza apoyando las tareas a nivel operativo de la
organización.

 Son intensivos en entrada y salida de información; sus cálculos y procesos suelen

ser simples y poco sofisticados.
  Tienen la propiedad de ser recolectores de información, es decir, a través de estos
sistemas se cargan las grandes bases de información para su explotación posterior.

 Son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles
y palpables.

Sistemas de Apoyo a la toma de Decisiones. Las principales características de estos son:

 Suelen introducirse después de haber implantado los Sistemas Transaccionales más

relevantes de la empresa, ya que estos últimos constituyen su plataforma de
información.
 La información que generan sirve de apoyo a los mandos intermedios y a la alta
administración en el proceso de toma de decisiones.

 Suelen ser intensivos en cálculos y escasos en entradas y salidas de información.

Así, por ejemplo, un modelo de planeación financiera requiere poca información de
entrada, genera poca información como resultado, pero puede realizar muchos
cálculos durante su proceso.

 No suelen ahorrar mano de obra. Debido a ello, la justificación económica para el

desarrollo de estos sistemas es difícil, ya que no se conocen los ingresos del
proyecto de inversión.

 Suelen ser Sistemas de Información interactivos y amigables, con altos estándares

de diseño gráfico y visual, ya que están dirigidos al usuario final.

 Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de

decisiones no estructuradas que no suelen repetirse. Por ejemplo, un Sistema de
Compra de Materiales que indique cuándo debe hacerse un pedido al proveedor o
un Sistema de Simulación de Negocios que apoye la decisión de introducir un
nuevo producto al mercado.

 Estos sistemas pueden ser desarrollados directamente por el usuario final sin la
participación operativa de los analistas y programadores del área de informática.
 Este tipo de sistemas puede incluir la programación de la producción, compra de
materiales, flujo de fondos, proyecciones financieras, modelos de simulación de negocios,
modelos de inventarios, etc.

Sistemas Estratégicos. Sus principales características son:

 Su función primordial no es apoyar la automatización de procesos operativos ni

proporcionar información para apoyar la toma de decisiones.

 Suelen desarrollarse in mouse, es decir, dentro de la organización, por lo tanto no

pueden adaptarse fácilmente a paquetes disponibles en el mercado.

 Típicamente su forma de desarrollo es a base de incrementos y a través de su

evolución dentro de la organización. Se inicia con un proceso o función en
particular y a partir de ahí se van agregando nuevas funciones o procesos.

 Su función es lograr ventajas que los competidores no posean, tales como ventajas
en costos y servicios diferenciados con clientes y proveedores. En este contexto, los
Sistema Estratégicos son creadores de barreras de entrada al negocio. Por ejemplo,
el uso de cajeros automáticos en los bancos en un Sistema Estratégico, ya que
brinda ventaja sobre un banco que no posee tal servicio. Si un banco nuevo decide
abrir su puerta al público, tendrá que dar este servicio para tener un nivel similar al
de sus competidores.

 Apoyan el proceso de innovación de productos y proceso dentro de la empresa

debido a que buscan ventajas respecto a los competidores y una forma de hacerlo
en innovando o creando productos y procesos.

2.3. ERP.

La Planificación de Recursos Empresariales, o simplemente ERP (Enterprise

Resourse Planning), es un conjunto de sistemas de información gerencial que permite la
integración de ciertas operaciones de una empresa, especialmente las que tienen que ver
con la producción, la logística, el inventario, los envíos y la contabilidad.
 Un ERP comprende todos los paquetes de software comercial que prometen la
completa integración de toda la información que fluye a través de la compañía:
financiera, contable, de recursos humanos, la cadena de proveedores y la información
del cliente.

De esta manera, a través del software ERP, en vez de estar los programas
trabajando de manera independiente uno del otro y sin tener una conexión entre sí,
trabajan de una forma integrada que permite la interconexión entre todos ellos. Tampoco
hay que considerar que es un ERP un sistema que integre sólo un sector de la compañía
(por ejemplo la contabilidad), sino que tienen que estarlo todas las partes que permiten
los procesos de negocios de la empresa.

La integración de todos estos datos en una base de datos centralizada permite la

optimización de los procesos y la obtención de la información de manera más rápida y
precisa y además, todos los usuarios pueden compartir la información y acceder a ella en
forma constante.

2.3.1. CARACTERÍSTICAS DE LOS SOFTWARE ERP.

- Sus componentes interactúan entre si consolidando todas las operaciones.

- Base de datos centralizada
- Entrada de la información al sistema solo una vez
- Permite la personalización.
- Está basado en una estructura confiable
- Proporciona funcionalidad para interactuar con otros módulos
- Proporciona las herramientas para consultas complejas.

2.4. SISTEMAS WEB

Todo profesionista que viva desarrollando sistemas se enfrenta en algún momento a retos
de interacción, organización y trabajo humanos radicalmente diferentes a la vez que
inevitablemente vinculados a la tarea del desarrollo del software. Los desfases en los
calendarios, los continuos cambios, las horas extra y sistemas con fallas o que no ahorran
tanto trabajo como deberían, parecen ser constantes en la industria de software y el sector
de sistemas WEB no es la excepción. Una de las muchas aportaciones para disminuir estos
problemas es MoProSoft, el Modelo de Procesos para la Industria de Software en México.
Es resultado de un esfuerzo conjunto de la industria de software y el gobierno mexicanos
para ayudar a las empresas del sector a operar de manera más eficiente y eficaz. Este
modelo de procesos resume y adapta a la realidad mexicana las prácticas, normas y
modelos más efectivos utilizados por la industria de software a nivel mundial.

Dentro del contexto de la industria de software el desarrollo de sistemas WEB ha cobrado

vital importancia por sus efectos sociales, versatilidad y costos. A pesar de esta creciente
importancia por la relativa novedad de las tecnologías WEB y su gran dinamismo la
cantidad de empresas y equipos de trabajo adecuadamente capacitados para desarrollar
eficientemente sistemas WEB es muy pequeña. Es en este contexto que se ha desarrollado
esta que guía que es para pequeños equipos de desarrollo de aplicaciones WEB que deseen
mejorar sus metodologías de trabajo.

2.4.1. CARACTERISTICAS DE LOS SISTEMAS WEB

Cada sistema es único sin embargo hay características que se repiten en casi todos los
sistemas WEB.

Estas características están directamente relacionadas con la naturaleza de la propia Internet,

con las funciones y usos de los sistemas así como con las dificultades en el desarrollo de
los mismos.

2.4.1.1. Comunicación

La función intrínseca de todos los componentes de Internet es transmitir y recibir

información, o en otros términos: comunicar. “La comunicación es obviamente el factor
subyacente del éxito de la WEB a la vez que la mayor fuente de complejidad y retos para el
desarrollo WEB” Los sistemas de software tradicionales almacenan, procesan y organizan
la información, pero en comparación con los sistemas WEB, sus posibilidades de
transmitirla son limitadas. Lo sistemas WEB pueden o no cumplir alguna o todas las
funciones “tradicionales”, pero inevitablemente deben transmitir información. En este
contexto la generación, actualización, confiabilidad y adecuación de la información de un
sitio o sistema WEB es un factor de singular importancia.
2.4.1.2. Interacción

Un factor adicional, que da aún más versatilidad y complejidad a la WEB, es la

bidireccionalidad del flujo de la información. Los usuarios no solo reciben información,
también pueden enviarla. Esto permite que los usuarios puedan asumir una amplia gama de
roles al usar un sistema. Pueden ser desde simples lectores, como en el caso de un portal de
noticias, hasta los responsables casi absolutos de los contenidos de los sistemas, como
ocurre en Wikipedia. La tendencia general es involucrar a los usuarios en algún grado en
todos los sistemas. Los sitios de noticias permiten a los lectores hacer cometarios, sobre las
mismas, los de ventas permiten evaluar los productos, etc., etc.

2.4.1.3. Estética y diseño gráfico preponderantes

El esquema Cliente/Servidor implica que el cambio de un sistema a otro es simple e

inmediato para los usuarios. Internet da a los sistemas instantáneamente millones de
usuarios en potencia, pero a la vez miles de sistemas competidores. La utilidad, la facilidad
de uso, el precio, la accesibilidad, la oportunidad y el atractivo visual son los factores más
significativos para retener usuarios. Ante la gran oferta, los usuarios hacen juicios
velozmente basándose a veces en un solo vistazo. Esto hace que la estética y el diseño
gráfico sean más importantes que en los sistemas tradicionales, pues resultan claves para
retener al usuario lo suficiente para que decida evaluar las otras características

2.4.1.4. Intuitivos y auto explicativos

Los mismos factores que causan C3 también fuerzan que los sitios sean fáciles de usar e
intuitivos. Los usuarios que decidan usar el sitio, lo abandonarán si no logran lo que
pretenden fácilmente.

2.4.1.5. Vinculados

La abundancia de sitios y la facilidad de cambiar de uno a otro no representa únicamente

retos, también es una oportunidad. Los sistemas WEB pueden valerse de otros para atraer
visitantes y cubrir funciones y contenidos si gastar en implementarlos o mantenerlos.
2.4.1.6. Cambio continuo

La tecnología de Internet permite el cambio continuo y además el mercado lo exige. La

información es un bien perecedero, y el cambio continúo una herramienta para atraer a más
usuarios. Estos factores refuerzan la necesidad de cambios muy frecuentes a todos los
niveles en la mayoría de los sistemas WEB.

2.4.1.7. Tecnología diversa

La estandarización de los protocolos y la tecnología Cliente/Servidor permite la

integración de una red muy heterogenia. El hecho de que la interoperabilidad sea posible
fomenta la diversidad de los sistemas.

La variedad de sistemas existe tanto en características relacionadas al hardware como al

software. En cuanto a hardware existen una gran variedad de tipos de computadoras,
tamaños y resoluciones de la pantalla así como diversos dispositivos de entrada como
ratones, pantallas táctiles, teclados, lápices apuntadores, etc. En el terreno del software
varía el navegador, su versión, y los plugins (complementos) que tenga para interpretar
formatos adicionales de archivos.

Los estándares permiten que sistemas muy diversos puedan inter operar y ser remplazados
sin alterar a los sistemas restantes pero no cambia las diferencias entre un sistema y otro.
Así aunque un celular un una PC puedan acceder a un sistemas WEB especifico el celular
nunca podrá presentar en su pequeña la información del mismo modo en que se esta se
presenta en la pantalla de PC. En el caso del software posible que en dos sistemas idénticos
en hardware y con el mismo navegador uno pueda desplegar animaciones multimedia y
otro no. Esto puede ocurrir si el plugin para tal fin se instaló sólo en un navegador.

2.4.1.8. Usuarios simultáneos y diversos

La diversidad de los usuarios es igual o más compleja que la de la tecnología. Hay que
considerar factores variables en cada individuo como el idioma, la familiaridad con la
información del sistema, el tiempo disponible, etc. También es necesario evaluar si la
información es sensible al acceso simultáneo.

En sitios dependientes de operaciones con fechas y horas se debe atender las confusiones y
problemas que puede causar el acceso desde lugares con otro uso horario. La meta
generalmente es satisfacer lo mejor posible a un amplio número de miembros de un
segmento de mercado específico, pues satisfacer plenamente a todos es imposible.

2.4.1.9. Múltiples involucrados con múltiples áreas de especialización

La transferencia de información es crítica en Internet y no es un elemento puramente

tecnológico.

Intervienen muchos otros factores relativos a la experiencia y cognición humana. Este

fenómeno ocasiona la necesidad de roles e involucrados en los sistemas WEB que son
inexistentes o muy poco frecuentes en los sistemas tradicionales. Debe haber quienes
generen la información, quienes diseñen como organizarla para hacerla accesible, quienes
la actualicen, quienes la validen y evidentemente quienes la consulten. Para cumplir estas
tareas suelen ser necesarias personas de diversas especialidades.

2.4.2. DIFICULTADES EN EL DESARROLLO DE SISTEMAS WEB

Las características comunes de los sistemas WEB hacen que a su vez se presenten con
frecuencia diversas dificultades en casi todos los desarrollos de sistemas WEB. Las más
significativas de estas son:

2.4.2.1 Necesidades de usuarios frecuentemente relegadas

Los criterios para diseñar los sistemas suelen considerar a las preferencias, necesidades y
capacidades de los usuarios. El uso a distancia, que permite Internet, implica que no sea
fácil o viable un contacto presencial con ellos. Por esta razón es común que los usuarios
estén físicamente ausentes durante el desarrollo de los sistemas WEB. Esta ausencia
presencial ocasiona muchas veces que se omitan algunos de los aspectos importantes. Por
la misma razón muchos otros aspectos se diseñen con base en suposiciones,
interpretaciones y preferencias, de otros involucrados, como el cliente patrocinador, con
mayor injerencia directa en el proyecto. Generalmente dichos involucrados reflejan sus
gustos personales y no las necesidades de quienes serán los verdaderos usuarios.

2.4.2.2 Requisitos altamente cambiantes

Aunado al factor de cambio constante de Internet, los propios requisitos de los sistemas
suelen cambiar antes de que estos estén terminados. El iniciar con objetivos muy generales,
las nuevas ideas que surgen a partir del aprendizaje que causa la interacción de los diversos
involucrados y el mismo número de involucrados, son solo algunos ejemplos de posibles
causas. En cualquier caso el cambio de requisitos es muy frecuente y sus efectos son muy
importantes en los desarrollos de sistemas WEB

2.4.2.3. Dificultades de comunicación

Las comunidades generan sus propios sub-lenguajes. Dan usos particulares a expresiones
generales, tienen expresiones propias y utilizan términos que desconocen otros grupos de
personas. En los desarrollos WEB, aun en el caso de sistemas pequeños, intervienen
personas de diversas disciplinas.

Esto ocasiona dificultades de comunicación que suelen ser muy costosas.

2.4.3. TECNICAS PARA EL DESARROLLO WEB

Si bien el proceso general permanece prácticamente inalterado en cuanto a sus fases

requerimientos, diseño, construcción y pruebas. En el área de técnicas y/o metodologías
específicas para alguna de las etapas encontramos varias propuestas.

2.4.3.1 Análisis de requerimientos enfocado a objetivos

El desarrollo WEB involucra información, navegabilidad, estética y personas de diversas
disciplinas además de la funcionalidad fundamental en todo sistema de software. En [7] se
propone el levantamiento de requerimientos enfocado a objetivos. Consiste en términos
generales en listar a los diversos involucrados y sus objetivos. Posteriormente
descomponer dichos objetivos en sub-objetivos que si son complementarios se marcan con
–y- (AND) y si son alternativos se marcan con – o - (OR).
Después se marcan las relaciones entre los diversos árboles y/o ramas con líneas
punteadas. Los objetivos contradictorios se marcan con una línea cruzada con una X. “Las
raíces de los árboles son los objetivos mientras que las hojas son los requerimientos. Las
hojas o requerimientos se pueden catalogar después como:
 Content (labeled with C); -Contenido-
 Structure of Content (SC); -Estructura del contenido-
 Access Paths to Content (A); -Ruta a contenido-
 Navigation (N); -Navegación-
 Presentation (P); -Presentación-
 User Operation (U); -Operación del usuario-
 System Operation (O); -Operación del sistema-
 Interaction (I). -Interacción-

El árbol resultante del ejemplo utilizado en [7] se muestra en la figura 2-4.

FIGURA 6. Ejemplo de árbol de requerimientos por objetivos,

Fuente: [19].
En este ejemplo se muestra que entre otros objetivos el museo desea aumentar el interés en
colecciones poco conocidas de su acerbo. El turista desea ver que hay para ver de su
interés en el museo y los patrocinadores desean atraer público a los eventos que patrocinan.
Después e muestra la descomposición de estos objetivos hasta llegar a los requerimientos
puntuales como Ver que cuadros Hay por sala, hacer una revisión general de la colección,
destacar el trabajo de E. Munch.

Los requerimientos resultantes se pueden listar y priorizar para resolver los que sean
posible de acuerdo al alcance del proyecto. Los conflictos se resuelven haciendo
propuestas y discutiendo con los involucrados.

Este procedimiento es inicialmente poco específico. Esto es una ventaja, en los desarrollos
WEB, pues no obliga a hacer decisiones de diseño cuando aún no se tienen todos los
elementos necesarios. Por su propia definición y proceso, el levantamiento de
requerimientos enfocado a objetivos también obliga a considerar a todos los involucrados
en el sistema, por ejemplo: El que encarga el sistema, quienes lo usaran tanto del grupo (u
organización) de clientes como fuera de este, quienes lo administraran, quienes generar la
información inicial y quienes al actualizaran. Adicionalmente una vez terminado este tipo
de análisis proporciona datos tanto de los requerimientos funcionales como de la
información e inclusive varios requerimientos no funcionales. Es importante tener en
cuenta que esta técnica permite resolver de mejor manera las dificultades que causan
usuarios con objetivos difusos o muy generales.

Millones de cibernautas acceden a sitios sin más objetivo que ver que encuentran. En los
sistemas tradicionales este tipo de usuario es muy improbable pero en los sistemas WEB es
más bien la norma.

2.4.4. TECNICAS PARA LA MODELACION

Aun no existe un estándar para modelar los sistemas WEB. Existen muchas propuestas
como son OOWS [2], WebML, UWE, entre otros. Estos lenguajes no son idénticos pero en
general todos siguen la misma estrategia y paradigmas. Toman como base UML y lo
extienden para poder modelar también los contenidos y la navegación. El uso de diagramas
se ha vuelto indispensable al documentar los sistemas. La versatilidad, expresividad y
simplificación que implican, ha llevado incluso al planteamiento de una nueva forma de
desarrollo de sistemas conocida como MDA o Model Driven Arquitecture por sus siglas en
ingles.
OOWS es uno de los nuevos metalenguajes de desarrollo basado en modelos aunque aún
es muy limitado y está en etapa experimental pero que ya permite la generación de sitios a
partir únicamente de modelos como se muestra en [2]. El desarrollo WEB 100% basado en
modelos es aún muy limitado y carece de herramientas profesionales y estables. Sin
embargo es un área con mucho potencial y es conveniente mantenerse atento a los
desarrollos de la misma.

2.4.5. USO DE PATRONES

En la sección de arquitecturas de [1] se puede ver que en los sistemas WEB se pueden usar
la mayoría de los patrones del diseño de software tradicionales. Sin embargo si se pone
atención a la búsqueda de patrones al navegar la propia Internet y se consultan sitios
dedicados al tema como [19] y [20] veremos que el uso de patrones no se limita a éstos.
Los usuarios de sistemas WEB están poco dispuestos a leer indicaciones y manuales. Por
esto los sitios deben ser intuitivos y fáciles de usar para sus usuarios objetivos. Los
patrones para sitios WEB (son diferentes de los diseño) son una gran herramienta para
lograr la simplicidad y familiaridad de los usuarios con el sistema. El uso de elementos
comunes en muchos sitios facilita a los usuarios el uso de los mismos. Así podemos
encontrar patrones casi universales en los sitios WEB como son la barra de navegación, las
tablas o los contenidos indexados. Hay también patrones para sistemas o componentes con
funciones específicas, por ejemplo los buscadores básicamente constan de un campo de
texto y un botón para iniciar la búsqueda; en el caso de los sistemas que venden productos
utilizan alguna variante de los “carritos de compras”. Otro caso son patrones para mostrar
cierto tipo de información como las ligas o secciones tituladas “Inicio”, “Acerca de” o
“Contacto”. Otros patrones se encargan de la presentación de la información así podemos
encontrar contenidos indexados, tablas, pestañas, paginación, mosaicos de imágenes, etc.
La taxonomía y clasificación de los diversos patrones WEB aún no está unificada sin
embargo esto no impide su uso. La observación de los sitios WEB similares resulta crítica
en este sentido.
2.4.6. TECNICAS PARA EL DESARROLLO DE ARQUITECTURAS

En diversas aéreas como el diseño gráfico y funcional las variaciones entre los patrones
utilizados en los sistemas WEB y los tradicionales son notorias. Sin embargo en el área
correspondiente a la arquitectura y la programación en sí, estas diferencias son más sutiles
y en general en los sistemas WEB se utiliza un subconjunto de los muchos patrones de
arquitectura que se pueden utilizar en los sistemas tradicionales. Esto se debe a que las
arquitecturas WEB deben poder funcionar en el esquema cliente/servidor y es muy
deseable que permitan separar las funciones de la información.
En la sección de arquitecturas de [3] se describen muchas posibles arquitecturas de los
sistemas WEB como modelo de N capas, JSP Modelo-2, Struts o OOHDM-Java2 en su
mayoría son adaptaciones de la arquitectura de los sistemas de software tradicional. Las
bases de la mayoría son la arquitectura por capas y la de modelo, vista, controlador. La
primera se plantea generalmente con una capa de interfaz con la que interactúa el usuario,
una o varias capas de procesamiento de información una última capa persistente donde se
almacenan los datos. Los datos y comandos en este modelo son propagados capa por capa
y cada capa puede interactuar directamente sólo con las capas superior y/o inferior. La
segunda arquitectura presenta un módulo de vista, uno de procesamiento de datos o control
y uno de almacenamiento persistente. En este caso los tres módulos pueden interactuar
indistintamente con los otros dos. Estas arquitecturas se utilizan porque tienden a aislar y
facilitar el manejo de la información que como se mencionó en las características C1
Comunicación, C2 Interacción son preponderantes en los sistemas WEB. Aun cuando los
paradigmas y estructura básica de estas arquitecturas no varían es importante tener en
cuenta la influencia de la información en los sistemas WEB. Las arquitecturas de N capas y
las basadas en modelo-vista-controlador permiten un manejo separado de los datos y la
información del sistema y en este puto convergen también con las nuevas tecnologías de
lenguajes de marcado como XML, por esto son de las más utilizadas en los sistemas WEB.

2.4.7. TECNICAS DE DISEÑO GRAFICO

La Estética y diseño gráfico preponderantes son muy importantes y tienen un rol

fundamental en retener a los navegantes en los primeros instantes en que visitan un sistema
WEB.
Sin embargo, resultan inservibles si el sistema no resulta útil al usuario. El diseño gráfico
debe entonces procurar una presentación clara de la información en forma estética. En
sistemas WEB el mejor lenguaje para manejar estos aspectos son las hojas de estilos CSS
que, con un poco de práctica, permiten el manejo y manipulación de los siguientes
elementos.

Tipografía (tipo, tamaño, color y decorado de las letras): En este caso se recomienda
utilizar tipografía más grande y clara que en medios impresos, pues leer en la pantalla es
incómodo. El tamaño y la decoración se deben utilizar para destacar la información más
importante.
Agrupación: La información y elementos visuales deben agruparse para facilitar su
entendimiento al lector. Las categorías pueden ser por función, tipo de dato, formato de
presentación, etc. Los diferentes grupos pueden hacerse evidentes por proximidad de sus
elementos e incluso el uso de elementos agrupadores como márgenes, líneas, recuadros e
imágenes. También se puede usar el color o la tipografía.

Orden: El orden de lectura de arriba abajo y de izquierda a derecha o el que venga al caso
según la lengua de los usuarios objetivo. Debe considerarse al momento de ubicar los
contenidos dentro de la pantalla pues determina en buena medida en que zona de la misma
pondrá su atención en primera instancia el lector.

Imagen y color: El uso de colores e imágenes es una de las formas más sencillas de hacer
Visualmente atractivo un sistema WEB. El poder de estas herramientas es tal que muchas
veces se cae en el abuso. El primer punto es evitar que la combinación de colores dificulte
la lectura el color de las letras debe tener un alto contraste con el color que se use de fondo.
Si se usan imágenes como fondo es muy recomendable utilizarlas como sello de agua con
los colores muy atenuados. Las imágenes deben usarse como elementos que sean a la vez
informativos y decorativos. Iconos, delimitadores de conjuntos de elementos, botones,
títulos o encabezados son excelentes opciones para utilizar imágenes que aporten tanto al
fácil entendimiento del sistema, como a la estética del mismo. La selección cuidadosa del
color las combinaciones de colores son un tema delicado no solo pueden hacer fácil o
difícil la lectura alteran drásticamente la percepción de los usuarios. Una de las mejores
herramientas para hacer dicha selección es el círculo de color. El círculo de color es un
acomodo de los colores en una circunferencia que utilizando simples separaciones de
diversos grados como 180 o 120 permite encontrar los colores que combinan con aquel que
seleccionamos. En la propia Internet se pueden encontrar gran variedad de versiones de
esta herramienta y lograr fácilmente buenas combinaciones decolores.

Es importante además tener constancia y congruencia en todo el sistema. Mantener

procesos, criterios de clasificación y formas de presentación similares para el mismo tipo
funciones, datos y/o elementos a lo largo de todo el sistema para evitar que los usuarios
deban aprender e interpretar en cada pantalla.

2.4.8. TECNICAS PAR EL DISEÑO DE NAVEGACION

Un factor único de los sistemas WEB es la navegación, la información y su presentación

no pueden ser usadas ni apreciados si no se encuentran. El acceso a la información debe
también diseñarse. En [2] y [3] se señalan lineamientos generales que es recomendable
seguir en la mayoría de los sistemas WEB y estos son:

1. Siempre informar al usuario donde se encuentra: La versatilidad de ir de un sitio

WEB a otro y de una sección a otra con un solo clic, puede causar rápidamente
desorientación en el usuario. Ya sea por ligas poco claras o distracciones ajenas al sistema
el usuario puede perder noción de lo que está viendo. Por eso casi 100% de los sitios utiliza
un encabezado presente en todas sus pantallas que indica de que sitio se trata. Además es
recomendable indicar exactamente en qué pantalla del sistema está el usuario mostrando un
título en cada una. En sistemas medianos y grandes también se debe poner la ruta o
clasificación de la pantalla dentro del sistema.

2. Tres clics de distancia: Los contenidos deben ser accesibles. La regla de los tres clics
Sugiere hacer una estructura del sitio muy horizontal en donde no se necesiten más de tres
Ligas o pasos para llegar a cualquier contenido. Si se deben dar más pasos dificultan que se
encuentren los contenidos en primera instancia y que los usuarios logren recordar cómo
Encontrarlos en visitas posteriores.

3. Ligas externos: Un sistema no está aislado, se deben generar ligas desde y hacia otros
sitios relacionados. Esto facilitará que los usuarios encuentren la información y que se
aprovechen desentenderte de tareas e información útil para los objetivos del sistema pero
que están más allá de su alcance. Al apoyarse en otros sistemas los contenidos y funciones
pueden mantenerse simples y actualizados facilitando entre otras cosas cumplir con la regla
de los tres clics.

2.4.9. TECNICAS PARA PRESENTAR LA INFORMACION

Como se constata en [21] la información en Internet puede ser video, imagen, audio o
texto pero en todos los casos estos elementos deben adaptarse al medio. La Tecnología
diversa, los Usuarios simultáneos y diversos y limitaciones como la velocidad de
transmisión o el tamaño de las pantallas, influyen sobre la efectividad de estas formas
de comunicación. En todos los casos se debe buscar un equilibrio de dos factores
contrapuestos al presentar información clara y completa pero a la vez breve y concisa.

En el marco del Cambio continuo que impone Internet la información es el aspecto

que más cambia de todos. La generación de información clara y completa pero a la vez
breve y concisa es muy costosa y tardada por lo tanto es muy importante distribuir esta
tarea entre diversos miembros de la organización cliente e involucrar a los propios
usuarios de sistema, lo más posible, en las tareas de generación y actualización de la
información.

En el caso de los textos deben ser breves, generalmente es recomendable elaborar

resúmenes de la información que manejan diariamente los clientes o usuarios en otros
medios. En los casos en que los objetivos del sistema incluyan justamente el acceso a
grandes volúmenes de información lo más recomendable es presentarla en formatos
descargables para su consulta fuera de línea y/o diseñados para ser impresos. Los datos
en texto ofrecen una gran variedad de patrones de presentación como son la
tabulación, el paginado, el indexado, el listado, etc.

En el caso de las imágenes se deben adaptar la resolución y el formato para que se vean
bien en pantalla pero ocupen el menor espacio posible.

El audio y el video deben también codificarse en formatos de alta compresión y a baja

resolución para que puedan ser vistos y/o escuchados aun en enlaces que presenten baja
velocidad. En el caso de video es recomendable generar video donde el fondo cambie poco
y/o cambie lentamente.

2.4.10. TECNICAS PARA PROBAR LAS APLICACIONES WEB

En la sección de pruebas en [3] se puede apreciar que las pruebas de las aplicaciones WEB
son similares a las de aplicaciones tradicionales pero presentan dos diferencias
fundamentales. Primero debido a la Tecnología diversa son necesarias muchas pruebas
para probar la misma funcionalidad en diversas plataformas. Segundo, gracias a la
facilidad con que se puede actualizar el sistema y a que se cuenta con Usuarios
simultáneos y diversos estos se pueden involucrar más fácilmente en las pruebas de la
aplicación, como se sugiere en [5]. Dentro del espectro de pruebas que puede desarrollar
un equipo pequeño se recomienda lo siguiente:
 Probar la combinación de las tecnologías a utilizar en varios navegadores antes
de incorporarlas al desarrollo.
 Seguir un procedimiento de pruebas tradicional para probar la funcionalidad de
la aplicación.
 Utilizar la retroalimentación de clientes y usuarios para mejorar la detección de
errores y reducir costo y tiempo de las pruebas. Un extremo de este enfoque
apoyándose en los propios usuarios es la técnica de Prototipos operativos.

2.4.11. PRODUCTOS

Es importante destacar que se habla de productos y no de documentos porque no se

generan forzosamente documentos de texto convencional. El tipo y profundidad de cada
producto debe adaptarse a cada equipo de trabajo y proyecto. Documentar y organizar es
sin duda útil pero también costoso; no tiene sentido realizar un proyecto donde la
documentación en si cueste más que el valor que aportará el proyecto. Normalmente entre
más involucrados, tiempo y esfuerzo requiera el proyecto más formal debe de ser la
documentación pero intervienen muchos otros factores.
En un trabajo muy sencillo, para un amigo cuya necesidad se conoce bien, puede ser
suficiente (pero poco recomendable) simplemente platicar y establecer oralmente qué se
requiere, escribir un breve listado, desarrollar el sistema y entregarlo. El mismo trabajo
para un desconocido probablemente requiera no solo mas dialogo sino esquemas y una
lista completa de las secciones y prestaciones del sistema. Algo muy similar para una
empresa requiere, además de las secciones y prestaciones del sistema, especificar tráfico
esperado, tiempo de garantía, etc.

Lo mismo ocurre con otros productos si hay más involucrados o el proyecto es más
complejo. Si el equipo de trabajo prefiere XP (extreme Programming) o RUP (Rational
Unified Process) el plan de desarrollo y otros productos son, en su forma, muy diferentes
pero en su fondo y objetivos similares.

Lo importante es tener en mente que los productos son útiles, deben adaptarse según las
circunstancias para optimizar el trabajo presente y futuro del equipo así como la calidad del
sistema. Los productos son unidades de información que se deben generar y/o conseguir y
organizar. Se pueden usar diversos medios y técnicas, siempre que la información se pueda
plasmar, consultar y comunicar cuando sea necesario. Los productos tampoco implican que
se requiere un documento o elemento por cada uno, solo que es necesario tener esa
información. Es necesario encontrar un punto medio, demasiada documentación y detalle
volverá su consulta más compleja que el volver a enfrentar los problemas en sí. Por otra
parte productos breves e incompletos generan problemas durante el proyecto y resultaran
inútiles en el futuro.

2.5 HERRAMIENTAS PARA MODELAR APLICACIONES

2.5.1. UML

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified

Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es
un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML
ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocio y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, esquemas de bases de datos y
componentes reutilizables.

Es importante resaltar que UML es un "lenguaje" para especificar y no para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los
 artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje
en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas

para dar soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso
usar.

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera

concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la
derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema
modelado:

 Diagrama de clases
 Diagrama de componentes
 Diagrama de objetos
 Diagrama de estructura compuesta (UML 2.0)
 Diagrama de despliegue
 Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema

modelado:

 Diagrama de actividades
 Diagrama de casos de uso
 Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos entre los
elementos del sistema modelado:

 Diagrama de secuencia
 Diagrama de comunicación, que es una versión simplificada del Diagrama de
colaboración (UML 1.x)
 Diagrama de tiempos (UML 2.0)
 Diagrama de vista de interacción (UML 2.0)

2.5.2. UWE

WE (UML-Based Web Engineering) es una propuesta basada en UML y en el

proceso unificado para modelar aplicaciones web. Esta propuesta está formada por
una notación para especificar el dominio (basada en UML) y un modelo para llevar a
cabo el desarrollo del proceso de modelado. Los sistemas adaptativos y la
sistematización son dos aspectos sobre los que se enfoca UWE.

Además de estar considerado como una extensión del estándar UML, también se
basa en otros estándares como por ejemplo: XMI como modelo de intercambio de
formato, MOF para el meta modelado, los principios de modelado de MDA, el
modelo de transformación del lenguaje QVT y XML. El modelo que propone UWE
está compuesto por 6 etapas o sub-modelos:
1. Modelo de Casos de Uso: modelo para capturar los requisitos del sistema.
2. Modelo de Contenido: es un modelo conceptual para el desarrollo del
contenido.
3. Modelo de Usuario: es modelo de navegación, en el cual se incluyen
modelos estáticos y modelos dinámicos.
4. Modelo de estructura: en el cual se encuentra la presentación del sistema y
el modelo de flujo.
5. Modelo Abstracto: incluye el modelo a de interfaz de usuario y el modelo
de ciclo de vida del objeto.

6. Modelo de Adaptación.
En cuanto a los requisitos, UWE los clasifica dependiendo del carácter de
cada uno. Además distingue entre las fases de captura, definición y
validación de requisitos.
2.5.2.1 UWE y su relación con UML

UWE define una extensión del Lenguaje Unificado de Modelado (UML). Ésta, es
considerada como una extensión ligera de peso e incluye en su definición tipos, etiquetas
de valores y restricciones para las características específicas del diseño Web, las cuales,
unidas a las definiciones de UML forman el conjuntos de objetos de modelado que se
usarán para el desarrollo del modelo utilizado en UWE. Las funcionalidades que cubren
UWE abarcan áreas relacionadas con la Web como la navegación, presentación, los
procesos de negocio y los aspectos de adaptación. Una de las ventajas de que UWE
extienda el estándar UML es la flexibilidad de éste para la definición de un lenguaje de
modelado específico para el dominio web y sobretodo la aceptación universal de dicho
estándar en el campo de la ingeniería del software. Otra gran ventaja es que actualmente
existen múltiples de herramientas CASE basadas en UML, con lo cual es relativamente
sencillo su utilización y ampliación para utilizar los objetos de modelado definidos en
UWE. Estas herramientas se verán en el siguiente punto.

2.5.2.2 MODELOS UWE

En esta sección se explicarán los modelos para cada una de los aspectos web que cubre la
metodología UWE, recordemos que estos aspectos eran navegación, presentación, los
procesos de negocio y adaptación. Así procedemos a explicar con un breve ejemplo cada
uno de estos modelos.

2.5.2.2.1 MODELO DE CONTENIDO

Este modelo especifica cómo se encuentra relacionados los contenidos del sistema, es
decir, define la estructura de los datos que se encuentran alojados en el sitio web. A
continuación se muestra un ejemplo de este modelo contenido en la página web de UWE.
 Name

Contactos
* *
Nombre:String
Email:String

Telefono Primario
direccioPostal
Primaria
TelefonoOpcional
direccioPostal
1
1
Direcciones Telefonos

Nombre:String
CodigoPostal:String CodigoInternacional:Integer
ciudad:String Prefijo:String

FIGURA 7. Modelo de contenido

Fuente: [20]
En este ejemplo se puede ver representado que el contenido web está formado por una
agenda básica de contactos, está agenda representada por la clase AddressBook contiene un
conjunto de uno o más contactos (clase Contact) , cada uno de ellos tiene un nombre, un
email una dirección y un teléfono de los cuales los dos primeros son de tipo String y los
dos últimos son estructuras de otros atributos, representadas por las clases address y pone
cada contacto puede tener una dirección y un teléfono principal y otros secundarios.

2.5.2.2.2 MODELO DE NAVEGACION

Este modelo indica como el sistema de páginas web está relacionado internamente.
Es decir cómo se enlazan los elementos de navegación.
Para ello se utilizan unidades de navegación llamadas “Nodos” conectadas por enlaces de
navegación. Estos nodos pueden ser mostrados en la misma página web no tienen por qué
estar en páginas diferentes.

Al mismo tiempo que explicamos este modelo con el ejemplo de la agenda de contactos,
podemos ir viendo los distintos elementos que introduce la metodología UWE, los
elementos introducidos son los siguientes.
 Nombres de los Estereotipos y sus símbolos

Aquí tenemos el ejemplo de navegación del sitio web que representa una agenda de
contactos.
<<Clase Navegacion>>
Inicio

<<consulta>> <<menu>> <<Clase Proceso>>

Buscar <<Enlace Proceso>> Menu Principal <<Enlace Proceso>> Creacion de un Contacto

<<Enlace N avegacion>>
<<Enlace Proceso>>
<<index>>
Lista de Contactos

<<Enlace N avegacion>>
<<Clase Navegacion>> <<Enlace Proceso>>
Contacto

FIGURA 8. Modelo de Navegación

Fuente: [20]
Para empezar tenemos AddressBook como página de inicio, así que está etiquetada como
{isHome} y como clase de navegación con el símbolo correspondiente (ver símbolos más
abajo). La página de inicio enlaza con un menú, que sería nuestra página de índice, para
ello la clase Main Menu esta etiquetada como página Menú. Desde la clase Main Menú
enlazamos con las clases Search (que implementará la función de buscar un contacto y es
etiquetada con la etiqueta de query) que es un proceso predefinido, y con la clase
ConctactCreation (que creará un contacto), esta clase es un proceso no definido con lo cual
llevará la etiqueta de processClass, así ambos enlaces serán del tipo process link. Para
finalizar vemos que la clase ConctactCreation está enlazada con Conctact ya que cuando
se crea un nuevo contacto, este se debe mostrar. Como también cuando se realiza una
búsqueda se debe mostrar la lista con los contactos del resultado, de ahí que exista otro
processLink entre las clases Search y ConctactList, esta última además etiquetada como
index, al ser una lista.
2.5.2.2.2 MODELO DE PRESENTACION
En este modelo se representan las clases de navegación y procesos que pertenecen a cada
página web. Estos son los elementos que introduce la Metodología UWE en este modelo.
Nombres de Estereotipos y sus símbolos

A continuación se muestra el diagrama de presentación del ejemplo de la agenda de

contactos:

Libro de Direcciones
: Introduccion

:Formulario Busqueda

: Criterio de Busqueda : Search

:Crear Contacto Mostrar Pagina de Creacion
de Contacto

: Contactos(*)

: Correo

:Telf Principal
:Nombre Actualizar Mostrar
:Telf Alternativo Pagina de Actualizacion de
Contacto
:Dir Principal Eliminar

Mostrar y recorrer la
:Dir Alternativo busqueda de los Contactos
en forma ordenada segun el
criterio de busqueda

FIGURA 9. Modelo de Presentación

Fuente: [20]
Como se puede ver la clase contacto es presentada como Presentation_Class, cubriendo
también diferentes textos y botones, esto significa que por cada contacto, tiene que ser
mostrado un email, direcciones y teléfonos. También se puede observar que la página de
 Inicio AndressBook contiene un texto de introducción y un formulario de búsqueda con un
capo de texto y un botón para lanzar la búsqueda

2.5.2.2.3 MODELO DE PROCESO

Este modelo específico las acciones que realiza cada clase de proceso, en este modelo se
incluye:
- Modelo de Estructura de Procesos: que define las relaciones entre las diferentes clases
proceso. Un ejemplo de diagrama de clases de este modelo siguiendo el caso de la Agenda
de contactos sería:
Confirmacion

:Pregunta

Proceso Contacto

Actualizacion de Contacto Campos de Actualizacion de Creacion de contacto

Contacto

:nombre:String
:email:String
:Telf:Principal:String
:Telf Alternativo:Sting
Confirmacion de Actualizacion Guarda Contacto
Dir Principal:String
DirAlternatrivo:String

Eliminacion de contacto

Error de Validacion

Confirmacion de eliminacion
 FIGURA 10. Modelo de Proceso
Fuente: [20]

En este diagrama se puede ver que hay clases para definir 3 operaciones que necesita una
confirmación. Así por ejemplo si el usuario quiere borrar un contacto el mensaje será
mostrado y después haciendo clic en “ok” el contacto será borrado. Las operaciones de
actualización y creación funcional de manera similar, ambas heredan de
ConctacProcessing, asegurando que los campos de datos tienen valores válidos.

2.5.2.4. MODELO DE FLUJO DE PROCESOS

Que especifica las actividades conectadas con cada proceso. Describe los comportamientos
de una clase proceso. Lo que ocurre en detalle dentro de cada una. Por ejemplo para la
operación de borrado de contactos tenemos el siguiente diagrama:

«Accion de Usuario» «Contacto»

Confirmacion Borrar

«ok» contacto:Contacto
«Cancelar»

«Contacto»
Borrar «Contacto»

«error»
Mostrar Mensaje
«Regresar y adicionar un nuevo registro»
«Eliminacion exitosa»
Mostrar Libro de direcciones
 FIGURA 11. Modelo de Flujo de Procesos
Fuente: [20]

Aquí se puede ver que la etiqueta <<userAction>> es usada para indicar las interaccione
entre el usuario y la página web iniciando un proceso o respondiendo a una petición de
información. Se puede ver el flujo que ocurre en cada operación con sus distintas rutas en
caso de éxito en la operación o en caso de error.

2.5. MYSQL.

MySQL es un sistema de gestión de base de datos relacional, multadillo y

multiusuario basado bajo la licencia GNU GPL.

Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de

programación, acceder a las bases de datos MySQL, incluyendo C, C++, C#, Pascal,
Delphi , Eiffel, Smalltalk, Java, Lisp, Perl, PHP, Python, Ruby,Gambas, REALbasic
(Mac), FreeBASIC, y Tcl; cada uno de estos utiliza una API específica. También existe un
interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de programación que
soporte ODBC comunicarse con las bases de datos MySQL. También se puede acceder
desde el sistema SAP, lenguaje ABAP.

MySQL es muy utilizado en aplicaciones web como. Drupal o phpBB, en

plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de
seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy
ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de
datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM. En
aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno
es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones

2.6. LENGUAJE DE PROGRAMACION PHP.

PHP (Hypertext Pre-processor), es un lenguaje de programación interpretado,

diseñado originalmente para la creación de páginas web dinámicas. Es usado
principalmente en interpretación del lado del servidor (server-side scripting) pero
actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación
de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las
bibliotecas Qt o GTK+.

Fue creado originalmente por Rasmus Lerdorf en 1994; sin embargo la

implementación principal de PHP es producida ahora por The PHP Group y sirve como el
estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP
License, la Free Software Foundation considera esta licencia como software libre.

Generalmente se ejecuta en un servidor web, tomando el código en PHP como su

entrada y creando páginas web como salida. Puede ser desplegado en la mayoría de los
servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno. PHP
se encuentra instalado en más de 20 millones de sitios web y en un millón de servidores.

Cuando el cliente hace una petición al servidor para que le envíe una página web, el
servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el
contenido de manera dinámica (por ejemplo obteniendo información de una base de datos).
El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente.
PHP permite la conexión a diferentes tipos de servidores de bases de datos tales como:
MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite.

PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas

operativos, tales como UNIX (y de ese tipo, como Linux o Mac OS X) y Windows, y
puede interactuar con los servidores de web más populares ya que existe en versión CGI,
módulo para Apache, e ISAPI.
2.6.1. CARACTERÍSTICAS DE PHP.

Ventajas
 Es un lenguaje multiplataforma.
 Capacidad de conexión con la mayoría de los manejadores de base de datos que se
utilizan en la actualidad, destaca su conectividad con MySQL
 Capacidad de expandir su potencial utilizando la enorme cantidad de módulos
(llamados ext's o extensiones).
 Posee una amplia documentación en su página oficial ([2]), entre la cual se destaca
que todas las funciones del sistema están explicadas y ejemplificadas en un único
archivo de ayuda.
 Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
 Permite las técnicas de Programación Orientada a Objetos.
 Biblioteca nativa de funciones sumamente amplia e incluida.
 No requiere definición de tipos de variables.
 Tiene manejo de excepciones (desde php5).

Desventajas

Si bien PHP no obliga a quien lo usa a seguir una determinada metodología

a la hora de programar (muchos otros lenguajes tampoco lo hacen), aun estando
dirigido a alguna en particular, el programador puede aplicar en su trabajo cualquier
técnica de programación y/o desarrollo que le permita escribir código ordenado,
estructurado y manejable. Un ejemplo de esto son los desarrollos que en PHP se
han hecho del patrón de diseño Modelo Vista Controlador (o MVC), que permiten
separar el tratamiento y acceso a los datos, la lógica de control y la interfaz de
usuario en tres componentes independientes

2.7 AJAX.

AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y

XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich
Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el
navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor
en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin
necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y
usabilidad en las aplicaciones.

Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se

requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el
comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en
el que normalmente se efectúan las funciones de llamada de Ajax mientras que el acceso a
los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores
actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en
XML.

Ajax es una técnica válida para múltiples plataformas y utilizable en muchos

sistemas operativos y navegadores dado que está basado en estándares abiertos como
JavaScript y Document Object Model (DOM).

AJAX es una combinación de cuatro tecnologías ya existentes:

 XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que

acompaña a la información.
 Document Object Model (DOM) accedido con un lenguaje de scripting por parte
del usuario, especialmente implementaciones ECMAScript como JavaScript y
JScript, para mostrar e interactuar dinámicamente con la información presentada.
 El objeto XMLHttpRequest para intercambiar datos de forma asíncrona con el
servidor web. En algunos frameworks y en algunas situaciones concretas, se usa un
objeto iframe en lugar del XMLHttpRequest para realizar dichos intercambios.
 XML es el formato usado generalmente para la transferencia de datos solicitados al
servidor, aunque cualquier formato puede funcionar, incluyendo HTML
preformateado, texto plano, JSON y hasta EBML.

CAPITULO III

ANALISIS DE REQUERIMIENTOS

3.1. INTRODUCCION
En el proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se
enfrenta al problema de la identificación de requisitos. La definición de las Necesidades
del sistema es un proceso complejo, pues en él hay que identificar los Requisitos que el
sistema debe cumplir para satisfacer las necesidades de los usuarios Finales y de los
clientes.

Para realizar este proceso, no existe una única técnica estandarizada y estructurada que
Ofrezca un marco de desarrollo que garantice la calidad del resultado. Existe en cambio Un
conjunto de técnicas, cuyo uso proponen las diferentes metodologías para el Desarrollo de
aplicaciones web. Se debe tener en cuenta que la selección de las técnicas y el éxito de los
resultados que se obtengan, depende en gran medida tanto del equipo de análisis y
desarrollo, como de los propios clientes o usuarios que en ella participen. El proceso de
especificación de requisitos se puede dividir en tres grandes actividades. (Lowe & Hall,
1999):
1- captura de requisitos
2- definición de requisitos
3- validación de requisitos

CAPTURA DE
CLIENTES USUARIOS ANALISTAS
REQUISITOS

INFORMACION
DEFINICION DE
REQUISISTOS

VALIDACION DE CATALOGOS DE
REQUISITOS REQUISITOS

CORRECCIONES

Figura 12: Proceso de Ingeniería de Requisitos

Fuente [25]
El proceso comienza con la realización de la captura de requisitos, el grupo de técnicos
toma la información suministrada por los usuarios y clientes. Esta información puede
provenir de fuentes muy diversas: documentos, aplicaciones existentes, a través de
entrevistas, etc. En base a esta información, el equipo de desarrollo elabora el catálogo de
requisitos. Finalmente con la validación de requisitos se realiza la valoración de los
mismos, comprobando si existen inconsistencias, errores o si faltan requisitos por 6 definir.
El proceso de definición-validación es iterativo y en algunos proyectos complejos resulta
necesario ejecutarlo varias veces.

Modelos de
Defina el alcance del requerimientos de
Modelado del Negocio
Proyecto usuario al detalle

Priorizar los
requerimientos

FIGURA 13. Proceso para la determinación de requisitos

Fuente: [26]
 3.2. MODELADO DEL NEGOCIO

Calculo de
Entrega de Produccion de
Produccion Calculo de Peso Analisi del Mineral
Mineral
acumulada

Solicitud de analisis
Directorio

Trabajor Comercial
Coopera izadora
tivista Solicitud de
Liquidacion
Control de Mitas

Cuadrilla Proceso Liquidacion

Calculo de Descuentos
Fijos y Variables

Contratacion de
Personal

Sistema Contable

Secretaria
Hacienda

FIGURA 14. Modelo del Negocio

Fuente: Elaboración Propia

3.2.2. ALCANCE DEL PROYECTO

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a
la sincronización con otros proyectos, que puedan interferir en la planificación y futura
puesta a punto del sistema objeto del estudio.

Una vez Elaborado el Modelo del Negocio determinamos el alcance que tiene nuestro
sistema identificando el contexto de los procesos que se llevan a cabo en la cooperativa
El Objeto de estudio que en nuestro caso es el proceso de comercialización y pago del
Mineral extraído por los cooperativistas, Pasan por varios Procesos de análisis repartición
y valoración estos procesos forman el modelo del negocio del sistema.
No se tomara en cuenta para el análisis de los requisitos del sistema otros subsistemas
como por ejemplo el sistema contable que tienen las cooperativas ni tampoco sistema de
seguro social que tienen para los trabajadores.

Por lo que este estudio se limitará al análisis de los procesos de Pago de Salarios por
mineral extraído, Procesos de Registros de Mineral extraído, Proceso del análisis del
mineral extraído y proceso de consultas

3.2.3. CAPTURA DE REQUISITOS

Para La captura de requisitos existen una variedad de técnicas según el tipo de sistema a
desarrollar y para este trabajo se vio por conveniente utilizar la técnica de “LA
ENTREVISTA”

3.2.3.1. ENTREVISTA
Resultan una técnica muy aceptada dentro de la ingeniería de requisitos y su uso está
ampliamente extendido. Las entrevistas le permiten al analista tomar conocimiento del
problema y comprender los objetivos de la solución buscada. A través de esta técnica el
equipo de trabajo se acerca al problema de una forma natural. Existen muchos tipos de
entrevistas y son muchos los autores que han trabajado en definir su estructura y dar guías
para su correcta realización (Durán, Bernáldez, Ruíz & Toro, 1999 y Pan, Zhu & Jonhson,
2001). Básicamente, la estructura de la entrevista abarca tres pasos: identificación de los
entrevistados, preparación de la entrevista, realización de la entrevista y documentación de
los resultados (protocolo de la entrevista).

3.2.3.2. PLANIFICAION Y DESARROLLO DE CAPTURA DE

REQUISITOS A PARTIR DE LA ENTREVISTA

3.2.3.2.1. IDENTIFICACION DE LOS ENTREVISTADOS

Se ha determinado que se hará la entrevista a los siguientes actores del negocio:
o Trabajador Cooperativista de Base.
o Jefe Encargado de Cuadrilla
o Encargado de comercializadora
o Secretaria de Hacienda
3.2.3.2.2. PREPARACION DE LA ENTREVISTA
Las entrevistas se Realizaran en el mismo Lugar de Trabajo de las Persona
hacer entrevistadas en los días que los entrevistados y el analista convengan el
tiempo de cada entrevista se ha determinado como 30 min como máximo y 15
mínimo.

3.2.3.2.3. DISEÑO DE LA ENTREVISTA

o Trabajador Cooperativista de Base.

¿Cuál es la Función que desempeña a en la cooperativa?
¿Cuál es el método o Registro que utilizan para registrar su producción de
mineral?
¿Quién hace el registro?
¿Cómo lo hace y cada cuánto tiempo?
¿Cómo clasifican el mineral que extraen?
¿Cuál es la forma de Pago que usted tiene por el mineral extraído?
¿Qué problema o dificultad tiene en la forma de pago y en los registros de su
producción?

o Jefe Encargado de Cuadrilla

¿Cuál es su función en la cuadrilla?
¿Cómo está Organizado la cuadrilla?
¿Cómo funcionan las cuadrillas en el proceso de extracción del mineral?
¿Existen registros históricos de la producción de las cuadrillas?
¿Qué problema o difunta tiene con respecto a los registros de la producción de su
cuadrilla?
¿Tiene usted alguna observación con respecto a cómo debería ser los registros de
producción su cuadrilla?
¿Cómo o cual es el método que utilizan en su cuadrilla para repartirse la producción
total por cuadrilla?

¿Usted reporta la producción de su cuadrilla al a cooperativa?

¿Cómo lo hace?
 ¿Cuál es el método que utilizan para clasificar el mineral?
o Encargado de comercializadora
¿Cuál es la función en la cooperativa?
¿Cómo funciona la recepción del mineral que ustedes reciben de la cooperativa?
¿Cómo Es el registro que tienen ustedes del mineral entregado?
¿Me puede dar más detalles?
¿Cómo es la forma de pago que se hace y a quien se hace?
¿Cómo y cuál es el método de valoración que tienen para pagar un determinada
entrega de mineral?
¿Existe algún tipo de penalización o descuentos por impuestos o regalías. Si es así
como se hace ese descuento y a quienes?
¿Tiene alguna observación o sugerencia en el proceso de entrega y pago del mineral
que entregan, los cooperativistas. Si es así cuál es esa Observación o sugerencia?

o Secretaria de Hacienda
¿Cuál es la función que Realiza en la cooperativa?
¿Cómo se hacen Las liquidaciones de salarios en la cooperativa?
¿Me puede proporcionar más detalles?
¿Cómo son Las papeletas de Pago que la cooperativa tienen y como las hacen?
¿Me puede explicar detalladamente la estructura de las papeletas?
¿Quién o quienes autorizan el pago a los cooperativistas?
¿Cómo se hace el proceso de cálculo de cada parte de la papeleta de pago de un
cooperativista?
¿Me podría proporcionar más detalles sobre la forma de cálculo que se hace para
liquidar los pagos?
¿Existen algunas penalizaciones o descuentos en la cancelación de las papeletas de
pago. Si es así Cuál es?
¿Quién o quienes están autorizados a poder cancelar y registrar los pagos hechos a
los cooperativistas?
¿Qué tipo de informes Tienen o requieren para la parte de registro de los pagos a los
cooperativistas?
¿Tiene alguna observación o sugerencia sobre el proceso de cancelación de las
papeletas de pago. Si es así cuál es su observación o sugerencia?
3.2.3 DEFINICION DE LOS REQUISITOS
Unas ves realizadas el análisis de la información y la documentación obtenida a través de
las entrevistas se identificaron los siguientes requerimientos

Usuarios del sistema

Deben existir roles en los usuarios del sistema para el acceso al a información.
Documentación y consultas
Deben existir Documentos de consulta y Reportes para que aporten a la toma de
decisiones de la cooperativa.
Administración de socios.
Registro de Socios o trabajadores.
Clasificación de socios según su rol en el sistema.
Control de producción.
Registrar cotización diaria del mineral para su valorización monetaria.
Registrar Producción. Por cuadrillas y trabajadores.
Registro análisis químico. Del mineral extraído por la cuadrilla o trabajadores.
Registro la humedad y la ley del mineral.

Control de la comercializadora.

Registro de comercializadoras.

Formulario de deducciones.

Se registran los costos de tratamiento.

Se registran gastos de realización.

Se registran gastos de seguro.

Formulario de penalidades.

Registro de tara, factor, reducción, seguro, retenciones, penalidades y

observaciones, de la producción

Registro el bono de producción, bono cantidad, bono calidad y observaciones si

existiese.
CAPITULO IV

ANALISIS DEL SISTEMA

4.1. INTRODUCCIÓN.

En esta etapa se determinan las necesidades y requerimientos del usuario, que se

consigue mediante la descripción de los requisitos del sistema, definidas como las
condiciones que el sistema debe cumplir, representada mediante el modelo del negocio, los
casos de uso del negocio, la descripción de los actores, los requisitos funcionales y no
funcionales, etc.

El modelo de negocio, es el mecanismo por el cual un negocio trata de generar

ingresos y beneficios. Es un resumen de cómo una compañía planifica servir a sus clientes.
Implica tanto el concepto de estrategia como el de implementación. Comprende el
conjunto de las siguientes cuestiones:

 Cómo seleccionará sus clientes

 Cómo define y diferencia sus ofertas de producto
 Cómo crea utilidad para sus clientes
 Cómo consigue y conserva a los clientes
 Cómo sale al mercado (estrategia de publicidad y distribución)
 Cómo define las tareas que deben llevarse a cabo
 Cómo configura sus recursos
 Cómo consigue el beneficio

Los requisitos no funcionales son característica requerida del sistema, del proceso
de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala
una restricción del mismo; mientras que los requisitos no funcionales son las característica
requerida del sistema que expresa una capacidad de acción del mismo o una funcionalidad;
generalmente expresada en una declaración en forma verbal.
 4.2. MODELO DE CASOS DE USO DEL NEGOCIO

Calculo de
Entrega de Produccion de
Produccion Calculo de Peso Analisi del Mineral
Mineral
acumulada

Solicitud de analisis
Directorio

Trabajor Comercial
Coopera izadora
tivista Solicitud de
Liquidacion
Control de Mitas

Cuadrilla Proceso Liquidacion

Calculo de Descuentos
Fijos y Variables

Contratacion de
Personal

Sistema Contable

Secretaria
Hacienda

FIGURA 15. Modelo de Casos de uso del Negocio

Fuente: Elaboración Propia
4.3. DIAGRAMA DE ACTIVIDAD – MODELO DEL NEGOCIO

Trabaj ador Comercializadora Secretaría de Hacienda Directorio

Contrata Personal
de Apoyo

Registro y Afiliación
del Trabajador

Solicita Registro a Verifica Parentesco y

C.N.S. y A.F.P. Registros de Beneficio

Inicia Trabajo Autoriza Registro a

de Producción C.N.S y A.F.P.

Entrega Producción Verifica si Existe

de Estaño producción Acumulada

Analiza Ley y Humedad

de Estaño
Solicita Análisis
de Estaño

Calcula Peso
Verifica de Estaño
Conformidad
de
Transacción

NO

SI
Inicia Proceso
Solicita de Liquidación
Liquidación

Controla Mitas

Calcula de
Descuentos

Realiza Boleta Calcula Gastos

de Liquidación de Cooperativa

FIGURA 16. Diagrama De Actividad del Negocio.

Fuente: Elaboración propia.

4.4. DESCRIPCIÓN DE CASOS DE USO DEL NEGOCIO

Caso de Uso: Producción y comercialización de mineral
Objetivo: Describir el negocio.
Actores: Directorio, cuadrilla, trabajador, comercializadora, Secretaria de hacienda.
Precondiciones: Debe existir una producción de estaño.
Resumen: El caso de uso inicia cuando un trabajador entrega una cantidad de mineral
(estaño) al jefe de cuadrilla el cual lleva a realizar un análisis químico donde se determina el
peso y la humedad existente. Una vez que se conocen las características del mineral se
entrega un informe a secretaria de hacienda donde se determina el precio del mineral de
acuerdo a leyes existentes, descuentos fijos y variables de la cooperativa.

4.4.1. DESCRIPCION DE LOS ACTORES. DEL NEGOCIO

DIRECTORIO. Es elegido mediante una asamblea general acompañado de

los dirigentes de la FEDECOMIN Oruro, tiene la función de administrar toda la
cooperativa y está divida en:
- Consejo de administración, Es el que coadyuva entre el consejo de vigilancia
y los trabajadores.

- Consejo de vigilancia, Se hace cargo del control de trabajadores por cuadrilla

o sección.

TRABAJADOR COOPERATIVISTA
Cumple la función de explotar mineral de una determinada área en convenio
con COMNIBOL. Los trabajadores existentes en la cooperativa son:

- Jefe de cuadrilla, Es el encargado de controlar a una cuadrilla y cumple la

función de contabilizar las mitas.
- Jefe de sección, Es el encargado de control de un número determinado de
cuadrillas para realizar diferentes actividades grupales.
COMERCIALIZADORA MINERAL
 Se encarga de la compra de minerales de acuerdo a convenios con la
cooperativa.

SECRETARIA DE HACIENDA O ENCARGADO DE REGISTRAR LA

PRODUCCION
Se encarga del manejo económico de la cooperativa en cuanto a las
liquidaciones de los minerales, sueldo al personal de apoyo, gastos de la
cooperativa.

4.5. DIAGRAMA DE CLASES DEL NEGOCIO.

FIGURA 17. Diagrama de clases del Negocio

Fuente: Elaboración Propia

4.6. ESPECIFICACION DE REQUERIMIENTOS DEL SISTEMA

 4.6.1. REQUERIMIENTOS FUNCIONALES DEL SISTEMA

REQUISITO DESCRIPCION USUARIOS

R1 Es sistemas debe Asignar roles en los usuarios del U1
sistema para el acceso al a información.
R1.1 El sistema debe Generar un rol de usuario U1
Administrador el cual tenga los privilegios de control
total del sistema de información. Este debe tener un
nombre de usuario y contraseña para poder ingresar al
sistema.
R1.2 El sistema debe Generar un rol de usuario el cual tenga U1
los privilegios Restringidos para el sistema. Este debe
tener un nombre de usuario y contraseña para poder
ingresar al sistema.
R4 Registro, edición y eliminación de Trabajadores de la U1,U2
cooperativa este registro lo realiza usuario
Administrador del sistema. Previa validación de los
datos del trabajador.
R5 Registro, edición, eliminación de cuadrillas, asociación U1,U2
de los trabajadores a estas cuadrillas. lo realiza el
usuario administrador.
R6 Registrar cotización diaria del mineral para su U1,U2
valorización monetaria, lo realiza el usuario
administrador del sistema y el usuario asignado.
R7 Registrar la Producción por cuadrillas. U1,U2
R8 Registrar la Producción por Trabajador. U1,U2
R9 Registro de análisis químico del mineral según planilla U1,U2
del laboratorio de una cuadrilla o trabajador.
R10 Registro de la Humedad y ley del mineral de un lote de U1,U2
producción del mineral por cuadrilla o trabajador.
R11 Registro, edición , eliminación de comercializadoras U1,U2
R12 Generar reporte de Gastos , deducciones, gastos de U1,U2
 equipo, gastos de seguro de un lote que es entregado
a una comercializadora
R13 Registro de tara, factor, reducción, seguro, retenciones, U1,U2
penalidades y observaciones, de la producción

R14 Registro el bono de producción, bono cantidad, bono U1,U2

calidad y observaciones si existiese.
R15 Generar reportes Listado de los datos de los U1,U2
trabajadores y a que cuadrilla corresponden
R16 Generar Reporte de la producción por cuadrilla y U1,U2
fechas
R17 Generar Reporte de producción por trabajador y fechas U1,U2
R18 Generar Papeleta de pago de un lote entregado por U1,U2
Trabajador
R19 Generar reporte de Producción Total de la cooperativa U1,U2
por fechas
R20 Calculo de repartición del mineral de una cuadrilla a los U1,U2
trabajadores de la cuadrilla
R21 Realizar copias de respaldo de toda la información del U1,U2
sistema

4.6.2. REQUERIMIENTOS NO FUNCIONALES

REQUERIMIENTO DESCRIPCION PREREQUISITO
R1 El lenguaje de programación debe ser Servidor apache
PHP versión 5 hacia adelante versión 2 o 3
R2 El Motor de Base de datos debe ser N.N
MYSQL versión 5 hacia adelante
R3 La interfaces grafica de usuario deben ser N.N
amigables al usuario no deben contener
demasiado texto y solo se deben usar
máximo 3 colores
R4 El servidor debe tener instalado Windows N.N.
versión XP, 7, 8
R5 El cliente debe tener instalado un N.N.
 navegador WEB ( se recomienda chrome o
Firefox)
R6 el cliente debe tener instado Una
impresora
R7 El servidor Debe contar con un Antivirus N.N.
y un firewall para evitar ataques de virus o
ingresos no autorizados al sistema para el
robo o manipulación de la información
R8 Se deben Contar con un plan de Políticas de
mantenimiento Mensual para el servidor mantenimiento
para evitar conflictos en la Red

CAPOITULO V
 DISEÑO DEL SISTEMA

En este capítulo se realizara el diseño del sistema, para lo cual se aplicara la

metodología UWE que es la extensión estándar de UML para el modelamiento de
aplicaciones web
El número de diagramas dependerá de la complejidad del sistema, concentrándose
estos en los más representativos e importantes.
La metodología UWE está compuesto en 6 etapas las cuales forman la metodología que
nos ayudara a diseñar de una forma adecuada nuestra aplicación. Estas etapas son las
siguientes.
1. Definir Actores. Aquí definiremos los actores que interactúan con nuestro
sistema.

2. Definir la relación entre los Actores: definiremos las relaciones implícitas

y explicitas que puedan existir entre los actores de sistema

3. Modelo de Casos de Uso para cada Actor: modelo para capturar los
requisitos del sistema. Estos se deben modelar para cada actor del sistema

4. Modelo de Contenido: es un modelo conceptual para el desarrollo del

contenido.

5. Modelo de Usuario o Navegación: es modelo de navegación, en el cual se

incluyen modelos estáticos y modelos dinámicos.

6. Modelo de estructura o Presentación: en el cual se encuentra la

presentación del sistema y el modelo de flujo.

5.1. DEFINIR ACTORES DEL SISTEMA

 ACTORES DESCRIPCION
ADMINISTRADOR Representa al usuario del sistema que tiene acceso total a
todos los módulos del sistema y que además puede crear
otros usuarios con permisos limitados o totales también
USUARIO (Con Representa un usuario con privilegios totales o parciales
Privilegios Limitados) dependiendo como el usuario administrador haya designado
los permisos de este usuario.
BASE DE DATOS Es un Actor abstracto ya que no interactúa de forma directa
o con voluntad con el sistema sino lo hace a petición de los
otros actores y con determinadas funciones establecidas para
cada petición

5.2. DEFINIR RELACION ENTRE ACTORES

FIGURA 18. Relación de actores del sistema

Fuente: Elaboración Propia

1. El actor Administrador Puede hacer todo lo que el actor usuario puede

hacer.
2. El actor Administrador creao actores usuario con distintos privilegios en el
sistema incluso puede crear actores con el mismo nivel de privilegios que el
actor administrador
3. El actor administrador es el que se crea inicialmente en el sistema comio
parte de los prerequisitos que tienen el sistema
 4. Los dos actores necesitan autentificarse en el sistema para poder ingresar al
mismo
5. Solo el actor administrador es puede borrar a un actor usuario y no al reves
6. El actor administrador y el actor usuario manadan peticiones al actor Base
de Datos
7. El actor Base de datos Responde alas peticiones echas por los actores
Aadministrador y Usuario
8. El actor Base de Datos no Es Independiente Responde a las reglas del
negocio del sistema ya predefinidas

5.3. MODELO DE CASOS DE USO DEL SISTEMA

FIGURA 19. Modelo de Casos de Uso del Sistema

Fuente: Elaboración Propia
5.3.1. CASO DE USO GESTIONAR TRABAJADORES

FIGURA 20. Modelo de Casos de Uso Gestionar Trabajadores

Fuente: Elaboración Propia

5.3.2.CASO DE USO GESTIONAR CUADRILLAS

FIGURA 21. Modelo de Casos de Uso Gestionar Cuadrillas

Fuente: Elaboración Propia
5.3.3.CASO DE USO GESTIONAR SECCIONES

FIGURA 22. Modelo de Casos de Uso Gestionar Secciones

Fuente: Elaboración Propia

5.3.4. CASO DE USO GESTIONAR USUARIOS

FIGURA 23. Modelo de Casos de Uso Gestionar Usuarios

 Fuente: Elaboración Propia
5.4. DESCRIPCION DE CASOS DE USO
5.4.1. DESCRIPCION CASO DE USO: AUTENTICACION

Caso de Uso: AUTENTICACION

Objetivo: Validar el ingreso de usuarios registrados al sistema
Actores: Administrador del sistema
Resumen: El usuario hace la autenticación de su nombre de usuario y contraseña para
ingresar al sistema
Acción del Actor Respuesta del Sistema

1. El Administrador ingresa al
sistema.

2. El sistema presenta formulario de

autenticación pidiéndole nombre
de usuario y contraseña

3. El Administrador introduce su
nombre de usuario y contraseña.

4. El sistema busca y valida la

información obtenida y procesa la
solicitud

5. En caso de ser correctos los datos

el sistema lo redirección al menú
principal del sistema en caso
contrario despliega un mensaje de
error.
 5.4.2. DESCRIPCION CASO DE USO: REGISTRAR TRABAJADOR
Caso de Uso: Gestionar TRABAJADOR
Objetivo: registrar un nuevo trabajador en el sistema
Actores: Administrador, usuario con privilegio de registrar trabajadores, base de datos
Resumen: se registra en el sistema un nuevo usuario

Acción del Actor Respuesta del Sistema

1.- El Administrador o el usuarios ingresa 1.-El sistema presenta una lista de todos
al Modulo trabajadores los trabajadores con un resumen de sus
datos personales
2.- El administrador o el usuarios 2.- El sistema despliega el formulario de
elige la opción de nuevo trabajador registro de nuevo trabajador

3.- administrador ingresa los datos que le 3.-el sistema valida los datos
solicita el en el formulario de registro de
trabajador

3.1.- En caso de ser correctos los

datos el sistema
registra un nuevo usuarios

3.2.- En caso de encontrar fallas en

los datos el sistema despliega los
datos erróneos

Precondición El usuario cuenta con los privilegios de

gestionar el módulo de trabajadores para
registrar nuevos usuarios

Postcondicion El nuevo trabajador es registrado en el

sistema

Presunción La base de datos de registro de nuevo

trabajador está disponible
 5.4.3. DESCRIPCION CASO DE USO: REGISTRAR CUADRILLA
Caso de Uso: REGISTRAR CUADRILLA
Objetivo: registrar una cuadrilla en el sistema
Actores: Administrador del sistema , usuario con privilegio de módulo de cuadrilla
Resumen: se registra en el sistema un nuevo cuadrilla

Acción del Actor Respuesta del Sistema

1.- El Administrador o el usuarios ingresa 1.-El sistema presenta una lista de todos
al Modulo Cuadrillas las cuadrilla

2.- El administrador o el usuarios 2.- El sistema despliega el formulario de

elige la opción de nuevo cuadrilla registro de nuevo trabajador

3.- administrador ingresa los datos que le 3.-el sistema valida los datos
solicita el en el formulario de registro de
cuadrilla

3.1.- En caso de ser correctos los

datos el sistema
registra una nueva cuadrilla

3.2.- En caso de encontrar fallas en

los datos el sistema despliega los
datos erróneos

Precondición El usuario cuenta con los privilegios de

gestionar el módulo de cuadrilla para
registrar nuevas cuadrillas

Postcondicion El nueva cuadrilla es registrado en el

sistema

Presunción La base de datos de registro de nuevo

cuadrilla está disponible
 5.4.4. DESCRIPCION CASO DE USO: FORMAR CUADRILLA
Caso de Uso: Asignar Jefe de Cuadrilla
Objetivo: Formar o agrupar trabajadores que formen una cuadrilla
Actores: Administrador del sistema , usuario con privilegio de módulo de cuadrilla
Resumen: se agrupan los trabajadores registrados en el sistema para formar una nueva
cuadrilla
Acción del Actor Respuesta del Sistema

1.- El Administrador o el usuarios ingresa 1.-El sistema presenta las opciones del
al Modulo Cuadrillas módulo cuadrilla

2.- El administrador o el usuarios elige la 2.- El sistema despliega una lista de todos
opción de asignar jefe de cuadrilla los trabajadores de esas cuadrilla

3.- administrador o usuario selecciona un 4.-El sistema agrega el código del

trabajador trabajador a un campo de texto y espera
confirmación
5.- El administrador o el usuarios elige la 5.1El sistema valida la información
opción de guardar y manda la solicitud
6.- La base de datos recibe la petición y 6.1El sistema registra como jefe de
gestiona el guardado dela información cuadrilla al trabajador seleccionado
recibida
Precondición El usuario cuenta con los privilegios de
gestionar el módulo de cuadrilla para
registrar nuevas cuadrillas

Postcondicion El nueva cuadrilla es registrado en el

sistema

Presunción La base de datos está disponible

5.5. MODELO DE CONTENIDO

FIGURA 24. Modelo de Contenido

Fuente: Elaboración Propia
5.6. MODELO DE USUARIO O NAVEGACION

FIGURA 25. Modelo de Usuario o Navegación

Fuente: Elaboración Propia
5.7. MODELO DE ESTRUCTURA O PRESENTACION
5.7.1. MODELO PRESENTACION MENU PRINCIPAL

FIGURA 26. Diagrama de Presentación “Menú Principal”

Fuente: Elaboración Propia

5.7.2. MODELO DE PRESENTACION SUBMENU TRABAJADORES

FIGURA 27. Diagrama de Presentación “Sub Menú Trabajadores”

Fuente: Elaboración Propia
5.7.3. MODELO DE PRESENTACION CREAR O EDITAR TRABAJADOR

FIGURA 28 Diagrama de Presentación “Crear o Editar Trabajador”

Fuente: Elaboración Propia
5.7.4. MODELO DE PREASENTACION CREAR O EDITAR CUADRILLA

FIGURA 29. Diagrama de Presentación “Crear o editar Cuadrilla”

Fuente: Elaboración Propia

5.7.5. MODELO DE PRESENTACION CREAR O EDITAR SECCIONES

FIGURA 30. Diagrama de Presentación “Crear o editar Secciones”

Fuente: Elaboración Propia
5.7.6. MODELO DE PRESENTACION CREAR O EDITAR PRODUCCION.

FIGURA 31. Diagrama de Presentación “Crear o editar Producción”

Fuente: Elaboración Propia
5.7.6. MODELO DE PRESENTACION SUBMENU COTIZACIONES.

FIGURA 32. Diagrama de Presentación “Submenú cotizaciones”

Fuente: Elaboración Propia
5.6. DIAGRAMAS DE PROCESOS Y FLUJO DE PROCESOS.

5.6.1 DIAGRAMA PROCESO GESTIONAR TRABAJADOR.

FIGURA 33. Diagrama de Proceso “Gestionar Trabajador”

Fuente: Elaboración Propia
5.6.2. DIAGRAMA DE PROCESOS GESTIONAR PRODUCCION

FIGURA 34. Diagrama de Proceso “Gestionar Producción”

Fuente: Elaboración Propia
5.6.3. DIAGRAMA DE FLUJO D PROCESO NUEVO TRABAJADOR

FIGURA 35. Diagrama de Flujo de Proceso “Nuevo trabajador”

Fuente: Elaboración Propia
5.6.4. DIAGRAMA DE FLUJO DE PROCESO EDITAR TRABAJADOR

FIGURA 36. Diagrama de Flujo de Proceso “Actualizar trabajador”

Fuente: Elaboración Propia
5.6.5. DIAGRAMA DE FLUJO D PROCESO BORRAR TRABAJADOR

FIGURA 37. Diagrama de Flujo de Proceso “Borrar trabajador”

Fuente: Elaboración Propia
5.6.6. DIAGRAMA DE FLUJO DE PROCESO NUEVA CUADRILLA

FIGURA 38. Diagrama de Flujo de Proceso “Nueva cuadrilla”

Fuente: Elaboración Propia
5.6.7. DIAGRAMA DE FLUJO DE PROCESO EDITAR CUADRILLA

FIGURA 39. Diagrama de Flujo de Proceso “Editar cuadrilla”

Fuente: Elaboración Propia
5.6.8. DIAGRAMA DE FLUJO DE PROCESO BORRAR CUADRILLA

FIGURA 40. Diagrama de Flujo de Proceso “Borrar cuadrilla”

Fuente: Elaboración Propia
CAPITULO VI

CONSTRUCCION Y CODIFICACION DEL SISTEMA

En el presente Capitulo se tratara la producción del sistema, una vez hecho el diseño del
sistema pasamos a la parte de programación y diseño de la base de datos.
Para este fin consideraremos varios aspectos que tienen que ver enteramente con la parte de
lenguajes de programación, lenguajes de consulta de base de datos, modelos entidad
relación, lenguajes de presentación, y tratamiento de imágenes. Consideramos los
siguientes puntos siguiendo los requerimientos no funcionales del sistema

1. Se utilizara como lenguaje de servidor la versión 5.3 de PHP

2. El servidor de Base de datos es MYSQL versión 5

3. Servidor APACHE.

4. Lenguajes del lado del cliente HTML 5 , JavaScript ,CSS, AJAX y XML

6.1. DISEÑO DE LA PERSISTENCIA

6.1.1. DIAGRAMA ENTIDAD RELACION DE LA BASE DE DATOS

Se obtiene a partir del diagrama de contenido del capítulo anterior.

FIGURA 41. Diagrama Entidad relación de la Base de Datos
Fuente: Elaboración Propia
 6.1.2. MODELO RELACIONAL DE LA BASE DE DATOS

6.2 ARQUITECTURA MODELO VISTA CONTROLADOR (MVC)

Vamos a construir una aplicación web para elaborar y consultar la producción y

comercialización de los minerales que tienen las cooperativas minera con datos acerca de.
Utilizaremos una base de datos para almacenar dichos datos que consistirá en unas varias
tablas descritas en el punto anterior. Para esto Dividiremos la Aplicación en Módulos Para
una Usabilidad mayor para nuestro usuario

Siguiendo patrón MVC. Comprobaremos como esta estrategia nos ayuda a mejorar las
posibilidades de crecimiento (escalabilidad) y el mantenimiento de las aplicaciones que
desarrollamos.

6.2.1. ORGANIZACIÓN DE ARCHIVOS

El servidor web únicamente puede acceder a una parte del sistema de ficheros que
se denomina Document Root. Es ahí donde se buscan los recursos cuando se realiza
una petición a la raíz del servidor a través de la URL http://el.servidor.que.sea/. Sin
embargo, el código ejecutado para construir dinámicamente la respuesta puede
“vivir” en cualquier otra parte, fuera del Document root [3].

Todo esto sugiere una manera de organizar el código de la aplicación para que no se
pueda acceder desde el navegador más que al código estrictamente imprescindible
para que esta funcione. Se trata, simplemente, de colocar en el Document root sólo
los activos y los scripts PHP de entrada a la aplicación. El resto de archivos,
fundamentalmente librerías PHP’s y ficheros de configuración (XML, YAML,
JSON, etcétera), se ubicarán fuera del Document Root y serán incluidos por los
scripts de inicio según lo requieran.

Siguiendo estas conclusiones, nuestra aplicación presentará la siguiente estructura

de directorio:
 FIGURA 42. Diagrama Estructura de Directorios
Fuente: Elaboración Propia

6.2.2. CONTROLADOR FRONTAL Y MAPEO DE RUTAS

En cualquier aplicación web se deben definir las URL’s asociadas a cada una de sus
páginas. Para la nuestra definiremos las siguientes:
URL ACCION
http://tu.servidor/fedecomin/index.php? mostrar pantalla inicio o logeo del
accion=index sistema
http://tu.servidor/fedecomin/index.php? Mostrar la pantalla principal del
accion=home usuario
http://tu.servidor/fedecomin/index.php? Mostrar la pantalla del listado de los
accion=trabajadores Trabajadores registrados en el sistema
http://tu.servidor/fedecomin/index.php? Muestra la pantalla de registro de
accion=addTrabajadores trabajadores al sistema
http://tu.servidor/fedecomin/index.php? Muestra la pantalla de editar
accion=editTrabajadores&it=# trabajadores
http://tu.servidor/fedecomin/index.php? Mostrar la pantalla del listado de las
accion=cuadrillas cuadrillas registrados en el sistema
http://tu.servidor/fedecomin/index.php? Muestra la pantalla de registro de
accion=addCuadrillas cuadrillas al sistema
http://tu.servidor/fedecomin/index.php? Muestra la pantalla de editar cuadrillas
accion=editCuadrillas&it=#

A cada una de estas URL’s les vamos a asociar un método público de la clase
Controller. Estos métodos se suelen denominar acciones. Cada acción se encarga de
calcular dinámicamente los datos requeridos para construir su página. Podrá utilizar,
si le hace falta, lo servicios de la clase Model. Una vez calculados los datos, se los
pasará a una plantilla donde se realizará, finalmente, la construcción del documento
HTML que será devuelto al cliente.

Todos estos elementos serán “orquestados” por el controlador frontal, el cual lo

implementaremos en un script llamado index.php ubicado en el directorio web. En
concreto, la responsabilidad del controlador frontal será:

 cargar la configuración del proyecto y las librerías donde implementaremos la parte

del Modelo, del Controlador y de la Vista.
 Analizar los parámetros de la petición HTTP (request) comprobando si la página
solicitada en ella tiene asignada alguna acción del Controlador. Si es así la
ejecutará, si no dará un error 404 (page not found).

Llegados a este punto es importante aclara que, el controlador frontal y la clase

Controller, son distintas cosas y tienen distintas responsabilidades. El hecho de que
ambos se llamen controladores puede dar lugar a confusiones.

El controlador frontal tiene el siguiente aspecto. (index.php).

 FIGURA 43 Diagrama de Archivo indexController.php
Fuente: Elaboración propia
 En las líneas 2 se realiza la carga de la configuración de la conexión a la base de
datos
 En las líneas 11 se define como index a nuestro controlador primario se declara un
controlador de error en la línea 23

6.2.3. LA IMPLEMENTACION DE LA VISTA

Ahora vamos a pasar a estudiar la parte de la Vista, representada en nuestra solución

por las plantillas. Aunque en el análisis que estamos haciendo ya hemos utilizado la
palabra plantilla” en varias ocasiones, aún no la hemos definido con precisión. Así
que comenzamos por ahí.
Cuando desarrollamos aplicaciones web con PHP, la forma más sencilla de
implementar plantillas es usando el propio PHP como lenguaje de plantillas. Para
nuestro Controlador “index” tenemos su Plantilla index.phtml (.phtml es la
extensión de las plantillas de nuestra aplicación)

FIGURA 44. Imagen del archivo index.phtml

Fuente: Elaboración Propia

Esencialmente no es más que un trozo de documento HTML donde la información

dinámica se obtiene procesando código PHP. La característica principal de este
código PHP es que debe ser escueto y corto. De manera que no “contamine” la
estructura del HTML. Por ello cada instrucción PHP comienza y termina en la
misma línea. La mayor parte de estas instrucciones son echo's de variables
escalares. Pero también es muy usuales la utilización de bucles foreach endforeach
para recorrer arrays de datos, así como los bloques condicionales if - endif para
pintar bloques según determinadas condiciones.
6.2.4. LOS MODELOS

Ya sólo nos queda presentar al Modelo. En nuestra aplicación se ha implementado

en la clase Model y está compuesto por una serie de funciones para persistir datos
en la base de datos, recuperarlos y realizar su validación.

Dependiendo de la complejidad del negocio con el que tratemos, el modelo puede

ser más o menos complejo y, además de tratar con la persistencia de los datos puede
incluir funciones para ofrecer otros servicios relacionados con el negocio en
cuestión. Crea el archivo app/Model.php y copia el siguiente código

FIGURA 45. Imagen del archivo administracionModel.php

Fuente: Elaboración Propia
6.3. INTERFACES DE USUARIO
6.3.1 INTERFAZ DE USUARIO LOGIN

FIGURA 46. Pantalla Login

Fuente: Elaboración Propia
6.3.2. INTERFAZ DE USUARIO HOME

FIGURA 47. Pantalla de usuario Home

Fuente: Elaboración Propia
6.3.3. INTERFAZ DE USUARIO CUADRILLAS

FIGURA 48 Pantalla de usuario CUADRILLAS

Fuente: Elaboración Propia

6.3.4. INTERFAZ DE USUARIO REGISTRO CUADRILLAS

FIGURA 49 Pantalla de usuario REGISTRO CUADRILLAS

Fuente: Elaboración Propia
 CAPITULO VII
PRUEBAS

7.1. PRUEBAS DE SOFTWARE.

Las pruebas de software son los procesos que permiten verificar y revelar la calidad
de un producto software. Se integran dentro de las diferentes fases del Ciclo del software
dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas
experimentales se trata de descubrir que errores tiene.

Las pruebas de software, testing o beta testing es un proceso usado para identificar
posibles fallos de implementación, calidad, o usabilidad de un programa. Únicamente un
proceso de verificación formal puede probar que no existen defectos. Para las pruebas del
Software se utilizan las técnicas de cajas negras y cajas blancas.

7.2. PRUEBAS DE CAJA BLANCA.

A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente o

de Cristal. Este método se centra en cómo diseñar los casos de prueba atendiendo al
comportamiento interno y la estructura del programa. Se examina así la lógica interna del
programa sin considerar los aspectos de rendimiento.

El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos

una vez, todas las sentencias del programa, y todas las condiciones tanto en su vertiente
verdadera como falsa.
 Para realizar estas pruebas se utilizara la Cobertura de Caminos: Se escriben casos
de prueba suficientes para que se ejecuten todos los caminos de un programa. Entendiendo
camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta
su salida.

7.3. PRUEBAS DE CAJA NEGRA

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es

estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que
produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja
negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros
elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin
dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien
definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni
conocer los detalles internos de su funcionamiento.

En pruebas de software, conociendo una función específica para la que fue diseñado
el producto, se pueden diseñar pruebas que demuestren que dicha función está bien
realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la
función, actuando sobre ella como una caja negra, proporcionando unas entradas y
estudiando las salidas para ver si son o no las esperadas.

7...4. PRUEBAS DE CAJA NEGRA SISTEMA SICOPRE 1.0

El sistema SICOPRE cuenta con los siguientes módulos:

- SOCIO
- APOYO
 - PRODUCCION
- COMERCIALIZACORA
- DESCUENTOS
- LIQUIDACION

7.4.1. MODULO TRABAJADOR.

ENTRADAS MODULO DE TRABAJADOR

SUB – MODULO REGISTRO DE TRABAJADOR

Identificación Cod. Archivo, C.I., Fotografía.
Datos personales Nombre, apellido paterno, apellido materno, sexo, fecha de
nacimiento, lugar de nacimiento, dirección, calle, localidad, estado
civil, teléfono, celular.
Datos cooperativa Nombre de la cooperativa, cargo actual, número de cuadrilla, Fecha
Ingreso al Trabajo, fecha de censo, numero de sección.
Datos C.N.S. Código C.N.S de asegurado, salario mensual, número del empleador,
lugar, fecha de afiliación a C.N.S., grado de educación.
Nota adicional Información adicional.

SUB – MODULO REGISTRO DE AFILIACION C.N.S

Códigos de C.I. Afiliado, C.I. Socio.
Identificación
Datos personales Nombre, apellido paterno, apellido materno.
Datos de afiliación Nombre, apellido paterno, apellido materno, fecha de
nacimiento, sexo, parentesco, código, fecha de extensión,
causas
Observaciones Información adicional.
SUB – MODULO REGISTRO DE CUADRILLA
Datos de cuadrilla Código de cuadrilla, nombre de cuadrilla
Nota adicional Fecha de apertura, jefe de cuadrilla.

SUB – MODULO REGISTRO DE SECCION

Datos de cuadrilla Código de sección, nombre de sección.
Nota adicional Fecha de apertura, jefe de sección.

SALIDAS DEL MODULO DE SOCIO

SUB – MODULO ADMINISTRAR SOCIO

N. COD NOMBRE APELLIDOS COOPERATIVA FECHA IN.

SUB – MODULO ADMINISTRAR CUADRILLA

N. COD CUADRILLA ENCARGADO FECHA AP.

SUB – MODULO ADMINISTRAR SECCION

N. COD SECCIÓN ENCARGADO FECHA AP.

7.4.3. MODULO PRODUCCION

ENTRADAS MODULO DE PRODUCCION

SUB – MODULO FORMULARIO DE PRECIOS

Códigos Código de cooperativa o productor, código intermediario.
Nombre de los Nombre de la cooperativa o productor, nombre de intermediario,
intermediarios fecha de contrato
Reducción Reducción. Unitaria, Valor ley de Sn
unitaria
Ventas Venta bruto, venta neta.
Deducciones Costo de tratamiento, gastos de realización.
Total deducciones Total tratamiento, total gastos
Seguro Tasa, seguro, deducciones en dólares.
Retenciones Regalías mineras, C.N.S. canon COMIBOL, otros, total retenciones
conforme a las acumulado
leyes.
Penalidades Elementos que se penalizan en el momento de liquidación, exceso
de ley.
Bono producción. Bono dólares, Bono en bolivianos.
Bono Cantidad. Bono dólares, Bono en bolivianos.
Bono Calidad Bono dólares, Bono en bolivianos, suma de bonos en dólares, suma
de bonos en bolivianos.
Total pago Bono dólares, Bono en bolivianos.
Observación. Información adicional.

SUB – MODULO COTIZACIÓN DIARIA

Código C.I. Afiliado., C.I. Socio.
Datos de registro Libra fina, tipo de cambio moneda extranjera (dólar), fecha.
Observación. Información adicional.
SUB – MODULO PRODUCCION
Código producción Código.
Código Socio Código Socio.
Datos personales Nombre, cuadrilla.
Destino Nombre de la comercializadora
Datos producción Kilos, sacos.
Análisis químico Ley, Humedad.
Kilos netos KN, Humedad, KN Secos.
Nota adicional Información adicional.

SUB – MODULO ANÁLISIS QUÍMICO

Código
Datos Socio
Fecha de análisis fecha
Datos del análisis Ley, humedad.
Nota adicional Información adicional.

SUB – MODULO CONTROL DE MITAS MENSUAL POR SOCIO

Código de identificación C.I del socio, mes, gestión.
Datos Socio Nombre completo
Datos mitas Cuadrilla, total mitas mes, porcentaje, porcentaje de costos,
costos de días ganados, total pagable.
Datos del análisis Ley, humedad.
Nota adicional Información adicional.

SALIDAS MODULO DE PRODUCCION

SUB – MODULO ADMINISTRADOR DE PRODUCCION

FECHA
N. COD SOCIO DESTINO PESO SACOS LEY LOTE
REG.
 SUB – MODULO ADMINISTRADOR DE MITAS

N. CI SOCIO CUADRILLA MITAS TOTAL GESTION

7.4.4. MODULO COMERCIALIZADORA.

SUB – MODULO REGISTRO COMERCIALIZADORA

Código
Nombre
Datos Ciudad, dirección, NIT, Teléfono
Encargado – Gerente
Observación

SUB – MODULO FORMULARIO DE DEDUCCIONES

Código Código comercializadora
Comercializadora Nombre de la comercializadora
Tratamiento Políticas de tratamiento, tratamiento, dólares.
Realización Política de realización, gastos de realización, dólares.
Retenciones Retención unidad porcentaje
SUB – MODULO FORMULARIO DE PENALIDADES
Código Código comercializadora
Comercializadora Nombre de la comercializadora
Tara Valor, unidad.
Factor Regalía minera Valor, unidad.
Reducción unitaria Reducción unitaria, media de la reducción (+/-)
Seguro de producción Tasa, unidad, seguro
Penalidades Impurezas, unidad, porcentaje, limite y dólares

SUB – MODULO FORMULARIO DE BONOS

Código Código comercializadora
Comercializadora Nombre de la comercializadora
Bono producción Mayor, unidad, dólares.
Bono cantidad Mayor, unidad, dólares.
Bono calidad Porcentaje de estaño, unidad, dólares.
Observaciones

7.4.5. MODULO DESCUENTOS

SUB – MODULO INDICE DE PORCENTAJES PARA DESCUENTO FIJO

Fecha actualización Código comercializadora
Descuentos Fijos Administración, Pro – Comercialización, FEDECOMIN,
FENCOMIN, COMIBOL, AFP, CNS, PROVIDA, ICM
interior, ICM exterior, otros.
Nota adicional

SUB – MODULO REGISTRAR DESCUENTO VARIABLE POR SOCIO

Código de identificación C.I. socio, mes, gestión.
Datos personales Nombre, apellido paterno, apellido materno.
Descuentos variables Anticipo entrega, anticipo mes, multas, sanciones, energía,
luz, agua, sereno, transporte, ayudas, pro-deporte, cuota
mortuoria, detalle, monto.
Nota Adicional.
CAPITULO VIII

CONCLUSIONES Y RECOMENDACIONES

8.1 CUMPLIMIENTO DE OBJETIVOS.

En base a toda la documentación realizada, el planteamiento del problema detallado

y redactado, el objetivo general propuesto, y los objetivos específicos que han intervenido
en la correcta y satisfactoria conclusión del presente proyecto, se debe indicar que se
lograron cubrir y dar solución a todos los problemas existentes en la empresa. Soluciones
que las mencionamos como:

8.2. CONCLUSIONES.

Por todo lo expuesto en los capítulos anteriores se llega a las siguientes

conclusiones:

Los aspectos generales basados en la metodología de la investigación en el capítulo

I justifica la investigación.

Los fundamentos teóricos para lograr el alcance de los objetivos con relación al área
de conocimiento se detallan en el capítulo II, Proceso de Producción Minera de Estaño,
Proceso de Comercialización de minerales, Lenguajes de programación de vanguardia,
Metodología de Desarrollo de Software OOP.

En el Capítulo 3 se analiza el contexto y caso de aplicación con los respectivos

diagramas que proporciona UWE para el posterior modelado.

En el Capítulo 4, se diseña la lógica del sistema, obteniendo así toda la secuencia y

desarrollo documental del proyecto de grado. Logrando así obtener el sistema
completamente desarrollado y funcional.
8.3. RECOMENDACIONES.

Se recomienda seguir con el estudio y optimización del sistema de información para

conseguir una herramienta completamente escalable que pueda implementar otros módulos
adicionales como el administración de aportes a la CNS y el modulo contable para el
departamento de contabilidad de las cooperativas.
REFERENCIA BIBLIOGRÁFICA

[1] “Comercialización de minerales” (CISEP); Oruro- Bolivia 2005

[2] “Procesos de concentración” (CISEP); Oruro- Bolivia 2005

[3] Servicio Nacional de Registro y Control de la Comercialización de Minerales y Metales

D.S. 29165 de 13 - 06 - 08. La Paz - Bolivia 2008

[4] SCH Müller Joseph, Aprendiendo UML en 24 horas, 1ª edición México, Ed.
Pearson Educación, 2000

[5] Ajeno-Caldera-Martínez, Proyecto Monográfico UML. Única edición, Nicaragua,

Ed. universitaria, 1999

[6] Laman Craig, UML y Patrones, 1ª edición México, Ed. Prentice Hall, 1999.

[7] James Martin, Análisis y Diseño Orientado a Objetos, 1ª edición, México, Ed,
Prentice Hall, 1994

[8] Pressman Roger, Ingeniería del Software un Enfoque Práctico, 5ª edición España,
Ed. Mc Graw Hill, 2004

[9] Ramírez Luis, Aplicando Herramientas UML, 1º edición Perú, Ed. Macro, 2002

[10] Rumbaugh James, El lenguaje Unificado de Modelado, 1º edición España, Ed.

Addison Wesley, 1999

[11] Muñoz-Niño-Vizcaino, Introducción a la Programación con Orientación a Objetos,

2º edición España, Ed. Prentice Hall, 2002

[12] Laundon Laundon, Administración de los Sistemas de Información, 2º edición

México, Ed. Prentice Hall, 2001

[13] Romero Gesvin, UML con Rational Rose, 1ª edición Perú, Ed. Megabyte, 2004

[14] De la Cruz Joel, Php y Mysql, 1º edición Perú, Ed. Megabyte, 2004

[15] Kendall, Kendall, “Análisis y Diseño de Sistemas, 3ª edición México, Ed. Prentice
Hall, 1999

[16] Jacobson-Booch-Rumbaugh, El proceso Unificado de Desarrollo de Software, 2ª

edición España, Ed. Addison Wesley, 2000
[17] Booch, Jacobson, Rumbaugh, The rational unified process, 2ª edición España, E.
Addison Welesy, 2000
.

REFERENCIA DE INTERNET

[18] El Servicio Nacional de Geología y Técnico de Minas

Disponible en URL: www.sergeomin.gov.bo

[19] Patricio Orlando Letelier, Ejemplo de desarrollo software utilizando la metodología

RUP, 16-11-06, 7 páginas,

Disponible en URL:
http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Pruebas.html,

[20] achile, Arquitectura de Información, 17-09-2006, 11 páginas.

Disponible en URL: www.aichile.org/glosario.htm

[21] Muñoz, Publicaciones, 15-05-06, 23 pantallas

Disponible en URL: http://www.unica.edu.ni/pub-estudiantes.html

[22]

Disponible en URL: http://es.wikipedia.org/wiki/RUP.