Implantación del ERP Odoo en el almacén de la Escuela Universitaria

de Posgrado - UMSS

Gustavo Villegas Velasco.

Mayo 2018.

Universidad Mayor de San Simón.

Facultad de Ciencias y Tecnología.
Diplomado en Gestión de Tecnologías de la Información.
Metodología de la Investigación
 Tabla de Contenidos

Capítulo 1 ............................................................................................................................ 1
EL PROBLEMA ................................................................................................................. 1
1.1 Introducción .............................................................................................................. 1
1.2 Antecedentes ............................................................................................................. 2
1.3 Problema ................................................................................................................... 3
1.3.1 Situación Problemática (descripción del problema). - ....................................... 3
1.3.2 Formulación del Problema. -.............................................................................. 4
1.4 Objetivos ................................................................................................................... 4
1.4.1 Objetivo General. -............................................................................................. 4
1.4.2 Objetivos Específicos. - ..................................................................................... 4
1.5 Hipótesis ................................................................................................................... 5
1.6 Alcances .................................................................................................................... 5
1.6.1 Alcance del Proyecto. - ...................................................................................... 5
1.6.2 Alcance del Producto. - ...................................................................................... 5
1.7 Límites ...................................................................................................................... 5
1.8 Justificación .............................................................................................................. 6
1.8.1 Justificación Social. - ......................................................................................... 6
1.8.2 Justificación Técnica. - ...................................................................................... 6
1.9 Estudio de Factibilidad.- ........................................................................................... 6
1.9.1 Factibilidad Técnica. - ....................................................................................... 6
1.9.2 Factibilidad Económica. - .................................................................................. 7
1.9.3 Factibilidad Operacional. -................................................................................. 9
1.10 Anexos .................................................................................................................. 10
Anexo Nro1. .................................................................................................................. 10
Anexo Nro2. .................................................................................................................. 10
Capítulo 2 .......................................................................................................................... 11
MARCO TEÓRICO.......................................................................................................... 11
2.1 Técnicas de Recolección de Datos .......................................................................... 11
2.1.1 Técnicas de Recolección de Datos Primarios. - ............................................... 11
2.1.2 Técnicas de Recolección de Datos Secundarios. - ........................................... 16
2.1.3 Selección de la técnica de recolección de información ................................... 17
2.2 Modelado de Negocio ............................................................................................. 17
2.3 Ingeniería de Software ............................................................................................ 25
2.3.1Metodologías de Desarrollo de Software. - ...................................................... 25
Modelo Incremental o Iterativo y Creciente ............................................................. 28
Metodología Scrum ................................................................................................... 31
2.3.2 Arquitectura de Software. - .............................................................................. 34
2.3.3 Pruebas de Software. - ..................................................................................... 37
2.4 ERP ......................................................................................................................... 39
Capítulo 3 .......................................................................................................................... 43
DISEÑO METODOLÓGICO ........................................................................................... 43
3.1 Enfoque de Investigación.- ..................................................................................... 43
 3.2 Tipo de Investigación.- ........................................................................................... 44
3.3 Alcance de la Investigación.- .................................................................................. 44
3.3.1 Descriptiva. - .................................................................................................... 44
3.3.2 Correlacional. - ................................................................................................ 44
Capítulo 4 .......................................................................................................................... 45
MARCO PRÁCTICO ....................................................................................................... 45
4.1 Técnicas de recolección de datos.-.......................................................................... 45
4.2 Modelado de Negocio.-........................................................................................... 45
4.3 Ingeniería de Software.- .......................................................................................... 47
4.3.1 Metodología de desarrollo. - ............................................................................ 47
4.3.2 Arquitectura de software. - .............................................................................. 48
4.4 Instalación de Odoo.- .............................................................................................. 49
4.5 Módulos de Odoo.- ................................................................................................. 52
4.6 Configuración de Odoo. - ....................................................................................... 55
4.7 Conclusiones. -........................................................................................................ 66
4.8 Recomendaciones. - ................................................................................................ 66
4.8 Bibliografía. - .......................................................................................................... 67
 1

Capítulo 1

EL PROBLEMA

1.1 Introducción

La Escuela Universitaria de Posgrado (EUPG) de la Universidad Mayor de San

Simón (UMSS) ha tenido un crecimiento exponencial en cuanto a los programas de

Posgrado ofertados: Diplomados, Especialidades, Maestrías y Doctorados. Esto debido a

la demanda de la sociedad en aéreas especificas de formación e investigación.

La EUPG maneja gran cantidad de información que resulta ser estratégica para

alcanzar los objetivos de la institución, por tal motivo es necesario implementar

soluciones tecnológicas que ayuden a tener un mejor manejo de esta información.

El uso e implantación un sistema ERP (Planificación de Recursos Empresariales,

Enterprise Resource Planning por sus siglas en ingles) en la EUPG es primordial para la

automatización de los procesos internos, la disponibilidad de información para la toma de

decisiones, la integración con otros sistemas y la disminución de tiempos y costes. Esto

evitará que se queden atrás en un mercado que cada vez es más competitivo por la

aparición de nuevas tecnologías.

El propósito de este proyecto es el de ayudar a mejorar los procesos internos de la

unidad de almacenes de la Escuela Universitaria de Posgrado, mediante la correcta

manipulación de la información necesaria para la oportuna toma de decisiones en cuanto

a la provisión y distribución de material de escritorio.

 2

1.2 Antecedentes

La Escuela Universitaria de Posgrado (EUPG) de la Universidad Mayor de San

Simón (UMSS), atiende y procesa los trámites administrativos (contratos, planillas y

presupuestos) y académicos (revisión de programas, registro de docentes, emisión de

títulos y certificados) de 17 unidades de posgrado; distribuidas en las facultades, escuelas

y centros universitarios. Estos trámites son atendidos a través de sus 4 departamentos; el

Departamento de Gestión Administrativa Y Financiera, el Departamento de Formación

Docente y Educación Continua, el Departamento de Educación a Distancia y el

Departamento de Coordinación Académica (ver organigrama en anexo Nro. 1).

Por el gran volumen de trámites procesados diariamente, se requiere también de

una gran cantidad de material de escritorio, este material es administrado por la unidad de

almacenes dependiente del Departamento de Gestión Administrativa y Financiera.

La unidad de almacenes cuenta con un funcionario que registra el ingreso y salida

de material de manera manual en formularios pre-impresos (ver formulario en anexo Nro.

2), no teniendo un control del stock y kardex de material que garantice el

aprovisionamiento de material a los funcionarios de los 4 departamentos de la DEUPG,

tampoco se cuenta con una proyección de material necesario para los próximos años,

tomando en cuenta que el aprovisionamiento de material de escritorio para toda la gestión

se lo realiza a principio de año por el tema presupuestario.

El proceso de pedido empieza cuando un funcionario realiza su solicitud mediante

el formulario pre-impreso, previa autorización de su jefe de departamento. Cuando la

solicitud llega a almacenes el funcionario verifica la existencia del material solicitado y

 3

lo prepara para la entrega mediante otro formulario pre-impreso, en muchas ocasiones se

realizan entregas parciales debido a la falta de material en almacenes ya que no se tiene

un control de stock de los materiales.

Todo esto provoca demora en trámites por falta de material, insatisfacción y

descontento por parte de las unidades de posgrado y mala imagen de la DEUPG como

institución.

1.3 Problema

1.3.1 Situación Problemática (descripción del problema). -

Como se puede observar en los antecedentes, el ingreso y salida de material es

realizado mediante procedimientos manuales es el principal problema que se tiene, en el

caso del ingreso de material se realiza mediante un acta de recepción y la verificación

visual del material. En el caso de la salida de material se realiza mediante un formulario

pre-impreso, llenado a mano con la autorización del Jefe de departamento. Este trabajo

manual provoca que no se tenga un correcto control de kardex y stock de material en

almacén.

El formulario de salida de material no siempre es llenado en el momento de la

entrega del material, también puede ser llenado horas o días después de realizada la

entrega el material, esto debido a la falta de algún material en almacén o a la excesiva

carga de trabajo del funcionario encargado de almacén, el formulario pre-impreso lleva

las firmas del funcionario del almacén, el funcionario solicitante y el jefe de

departamento.
 4

Todo lo expuesto provoca que no se puedan tomar las decisiones oportunas sobre

previsiones de presupuesto para la compra de nuevo material al no tener información del

stock en almacén.

1.3.2 Formulación del Problema. -

Los procesos manuales e ineficientes en la gestión de ingreso y distribución de

material de escritorio en la Escuela Universitaria de Posgrado provocan

desabastecimiento en almacén, retraso en trámites, descontento en las unidades de

posgrado y mala imagen de la institución.

1.4 Objetivos

1.4.1 Objetivo General. -

Proponer la implantación del sistema ERP Odoo para la gestión de ingreso y

distribución de material de escritorio en el almacén de la Escuela Universitaria de

Posgrado.

1.4.2 Objetivos Específicos. -

 Analizar los aspectos más relevantes de planificación de recursos empresariales.

 Conocer la situación actual de la empresa.

 Diseñar el modelo de negocio actual y alternativo para el proceso de ingreso y

salida de material de escritorio en almacén.

 Implantar el Sistema ERP Odoo en el almacén de la empresa.

 5

1.5 Hipótesis

La implantación del ERP Odoo en el almacén de la Escuela Universitaria de

Posgrado de la UMSS, permite mejorar la gestión de material de escritorio y optimizar

tiempos en los trámites de cada departamento, además de información útil y detallada

acerca del movimiento diario de material de escritorio.

1.6 Alcances

1.6.1 Alcance del Proyecto. -

Conocer los procesos internos de la oficina de Almacén.

Conocer reglamentos y procedimientos internos de la UMSS sobre TI.

Evaluar requisitos técnicos del Sistema ERP Odoo.

Optimizar procedimientos en el proceso de entrada salida de material de almacén.

Realizar test de validación de usuario.

1.6.2 Alcance del Producto. -

Aplicación de reglamentos y procedimientos internos de la UMSS sobre TI.

Crear y Configurar la base de datos.

Instalar y configurar el Sistema ERP Odoo con los módulos necesarios para su

funcionamiento en almacén.

Adecuar el Sistema de Recursos Empresariales de acuerdo a necesidades de la empresa.

1.7 Límites

Los pagos a los proveedores no serán realizados mediante la aplicación.

Los módulos del Sistema de Recursos Empresariales serán los necesarios para su

funcionamiento en el almacén.

El Sistema de Recursos Empresariales correrá solo en la intranet de la Empresa.

 6

El Sistema de Recursos Empresariales solo tendrá acceso vía WEB.

1.8 Justificación

1.8.1 Justificación Social. -

El Sistema de Recursos Empresariales permitirá lograr procesos eficientes en el

ingreso y salida de material de escritorio en almacén, brindando a los funcionarios de la

Escuela Universitaria de Posgrado un aprovisionamiento oportuno del material requerido

para su trabajo.

También se mejorará la imagen de la institución al no tener demora en trámites a causa de

la falta de material de escritorio.

1.8.2 Justificación Técnica. -

El Sistema de ERP proveerá información de manera rápida, confiable y oportuna

para la toma de decisiones ejecutivas y mejora de tiempos en los trámites,a través de la

correcta gestión de la información y reportes en tiempo real, disponibles mediante la

interfaz web del sistema.

1.9 Estudio de Factibilidad.-

1.9.1 Factibilidad Técnica. -

Desde un punto de vista técnico para la implantación del sistema ERP Odooson

necesarios recursos tecnológicos, por lo cual se recolectó información sobre tecnología

existente con respecto al Hardware y Software para utilizarla en la implantación del ERP.

Hardware.-

Los equipos de computación actuales utilizados por los funcionarios de la Escuela

Universitaria de Posgrado y la infraestructura de RED actual, son los adecuados y

suficientes para utilizar sin problemas el sistema ERP Odoo.

 7

Para la implantación del ERP Odoo es necesario contar con un servidor conectado a la

red de datos de la UMSS para atender a los pedidos de los usuarios, en este caso la

UMSS cuenta con un Data Center con los equipos necesarios para la implantación a corto

plazo del software ERP.

Software.-

Para la implantación del software ERP Odoo es necesario contar con un servidor

con sistema operativo LINUX con el manejador de base de datos PostgreSQL, al ser

estos Open Source no requieren de inversión alguna de software.

En el caso de los usuarios del sistema será suficiente contar con un navegador web para

poder interactuar con el sistema, independientemente del sistema operativo utilizado.

Al existir los recursos tecnológicos disponibles en la UMSS, técnicamente es factible la

implantación del software ERP

1.9.2 Factibilidad Económica. -

Como se mencionó anteriormente, la UMSS cuenta con los recursos necesarios

para poder implantar con software ERP Odoo por lo que no se requiere de una inversión

inicial.

Costos Generales.-

Datos generales Costo

Material de oficina 200 bs

Papel para impresoras 40 bs

Consumibles 700 bs

Total 940 bs
 8

Costos de personal.-

Dado que el presente proyecto solo contempla la parte de la implantación del

software ERP Odoo, será necesario contar con personal calificado para realizar las

configuraciones necesarias en el servidor. La UMSS ya cuenta con este personal, por lo

que durante el periodo de implantación del software ERP no será necesario contratar

personal adicional.

Costos operativos durante la implantación.-

Los costos de operación se muestran a continuación:

Concepto Pago único

Energía Eléctrica 100 bs
Agua potable 0 bs
Teléfono 50 bs
Total 150 bs

Costos totales de implantación del sistema.-

En la siguiente tabla se muestran los costos totales necesarios para la implantación

del sistema.

Concepto Costo único

Costos generales 940 bs
Costos del personal 0
Costos de operación 150 bs
Total 1090 bs
Total + IVA 1253.5 bs

El total mostrado en la anterior tabla representa el costo único durante el periodo

de implantación del software ERP.

 9

Al tener los recursos necesarios, económicamente es factible la implantación del

software ERP

1.9.3 Factibilidad Operacional. -

Para la factibilidad operacional se tomo en cuenta el impacto que tendrá este

proyecto en la Escuela Universitaria de Posgrado, el sistema ERP Odoo producirá

cambios importantes en los procedimientos de la unidad de almacenes y el pedido de

material por parte del los funcionarios.

Se realizara una inversión de tiempo por parte de los funcionarios que utilizaran el

sistema para capacitarlos, lo que dará como resultado una familiarización con el sistema y

una total adecuación y confianza al momento de manipular el sistema.

Con la implantación del sistema ERP Odoo se optimizará tiempos y las decisiones

se tomaran de manera oportuna, evitando en desabastecimiento en la unidad de

almacenes y consecuentemente la fluidez en los tramites.

Al estar los usuarios del sistema consientes de los cambios que representa la

utilización del sistema, operacionalmente es factible la implantación del software ERP

 10

1.10 Anexos

Anexo Nro1.

Anexo Nro2.
 11

Capítulo 2

MARCO TEÓRICO

2.1 Técnicas de Recolección de Datos

En la recolección de datos se utilizará una diversidad de técnicas y herramientas

que serán utilizadas por el analista para desarrollar los sistemas de información. Estos

instrumentos se aplicarán en diferentes momentos, con la finalidad de buscar información

que será útil a una investigación. Existen dos tipos de recolección de datos: Primarios y

Secundarios.

2.1.1 Técnicas de Recolección de Datos Primarios. -

En estas técnicas los datos se obtienen de la realidad misma, sin ningún tipo de

elaboración previa, se recogen por el contacto directo del investigador con la realidad,

por medio de observación, cuestionarios, entrevistas, etc.

La Observación.-

Es el registro visual de lo que ocurre en una situación real, clasificado y

consignando los datos de acuerdo con algún esquema previsto y de acuerdo al problema

que se estudia.

La Observación Participante: El investigador se involucra total o parcialmente con la

actividad objeto de investigación.

 La observación se hace desde el interior del grupo.

 Pueden intervenir las emociones del investigador.

La Observación NO Participante: El investigador no se involucra en la actividad objeto

de estudio.
 12

 Los datos pueden ser más objetivos.

 Al no integrarse al grupo los datos pueden no ser exactos.

La Observación Simple, No estructurada, No regulada, No controlada: El

investigador utiliza lineamientos generales para observar y luego escoge lo que estima

relevante a los efectos de la investigación propuesta.

 Fundamentalmente usada para estudios exploratorios.

La Observación Sistemática, estructurada, regulada o controlada: El investigador

dispone de un instrumento estructurado y estandarizado para medir las variables en

estudio de una manera uniforme.

 Se utiliza para probar hipótesis en que se especifica claramente que se estudia.

 Se usan listas de cotejo, grabadoras, filmadoras, etc.

Ventajas de la Observación:

 Permite registrar datos cualitativos y cuantitativos.

 Se observan características y condiciones de los individuos.

 Puede ser utilizada en cualquier tipo de investigación y en cualquier área del

saber.

 Es un método que no depende de terceros o de registros.

Desventajas de la Observación:

 Se requiere de mucha habilidad y agudeza para “ver” los fenómenos estudiados.

 Demanda gran cantidad de tiempo.

 Tiene sesgos; el humano ve lo que quiere ver.

 13

 Al momento de la interpretación pueden distorsionarse los hechos e ir más allá de

lo que vimos en realidad.

Consejos para reducir los problemas en la observación:

 Definir claramente los objetivos perseguidos.

 Determinar claramente la unidad de observación.

 Las condiciones en que se asumirá la observación y las conductas que deberán

registrarse.

La Entrevista.-

Las respuestas son formuladas verbalmente y se necesita de la presencia

del entrevistador, existe una comunicación interpersonal entre el investigador y el sujeto

de estudio a fin de obtener respuestas verbales a las interrogantes planteadas sobre el

problema propuesto.

Entrevista estructurada.-

 Se elabora un formulario estandarizado.

 Idénticas preguntas y en el mismo orden a todos los sujetos.

 Los sujetos eligen la respuesta de 2, 3 o pocas más alternativas.

 Los comentarios y explicaciones son los mismos para todos.

Ventajas:

 Respuestas cortas y precisas.

 Información fácil de procesar.

 El entrevistador no requiere de gran entrenamiento.

 Información uniforme.
 14

Desventajas:

 La información puede ser muy superficial.

 Limitada la posibilidad de profundizar en un aspecto determinado.

 Difícil obtener información confidencial.

Entrevista no estructurada.

 Es flexible y abierta, pero regida por los objetivos de la investigación.

 Las preguntas, su contenido, orden y formulación es controlado por el

investigador, el que puede adaptarlas dependiendo de las situaciones y

características de los sujetos en estudio.

 El entrevistado también cuenta con libertad para dar sus respuestas.

 Se utiliza un instrumento guía que contiene las orientaciones de los temas a tratar.

 Muy útil para estudios exploratorios, descriptivos y cualitativos.

Ventajas:

 Adaptable y aplicable a toda clase de sujetos en diversas situaciones.

 Permite profundizar en los temas de interés.

 Orienta posibles hipótesis y variables cuando se exploran áreas nuevas.

Desventajas:

 Requieren mucho tiempo.

 Muy costosos por el tiempo de las entrevistas.

 Limitado para personas con problemas de comunicación.

 Dificultad para tabular datos que han sido recopilados de distinta forma.

 Se requiere crear confianza y comodidad entre el entrevistado y el entrevistador.

 15

 Se requiere habilidad técnica para obtener la información y mayor conocimiento

respecto del tema.

 Debido a que son entrevistas en profundidad habitualmente se utilizan muestras

pequeñas.

Consideraciones a tomas en cuenta en la entrevista.-Para evitar el rechazo o atrasos al

aplicar entrevistas se debe tomas las siguientes consideraciones:

 Establecer los contactos necesarios para el buen fin de las entrevistas.

 Entrevistador debe estar bien capacitado. El entrevistador debe establecer una

buena comunicación con el entrevistado, uso de vestuario adecuado, lenguaje

adecuado, escuchar adecuadamente, no apresurar al entrevistado, etc.

 Buen registro de la información a fin de poder interpretarla adecuadamente.

 El entrevistador debe:

o Dejarle un mensaje positivo al entrevistado.

o Jamás dar consejos.

o Jamás hacer juicios morales.

o Jamás rebatir al entrevistado.

El Cuestionario.-

Es un método que utiliza un instrumento o formulario impreso, destinado a

obtener respuestas sobre el problema en estudio y que el sujeto investigado llena por sí

mismo.

El cuestionario puede aplicarse a grupos o individuos estando presente el

investigador e incluso puede enviarse por correo a los destinatarios.

 16

Ventajas:

 Costo relativamente bajo.

 Proporciona información sobre un mayor número de personas en un período

breve.

 Fácil para obtener, cuantificar, analizar e interpretar datos.

 Menores requerimientos de personal capacitado.

 Mayor posibilidad de mantener anonimato de los encuestados.

 Eliminación de los sesgos que introduce el encuestador.

Desventajas:

 Es poco flexible, la información no puede variar ni profundizarse.

 Si el cuestionario se envía por correo, es posible que no sean devueltos o que no

se obtengan respuestas.

 No utilizable en personas que no saben leer ni escribir.

 No permite aclarar dudas.

 Resulta difícil obtener cuestionarios completamente contestados.

 Se deben obtener grandes muestras.

2.1.2 Técnicas de Recolección de Datos Secundarios. -

Los datos provienen también del contacto con la realidad, pero que son recogidos

y procesados por los investigadores; documentos como; historia clínica, ficha académica,

estadísticas, datos epidemiológicos, Censo, encuestas nacionales, etc.

 17

Mucha de esta información se puede encontrar en internet, lo que ayuda a reducir

tiempos al momento de buscar información. A través de internet se facilita enormemente

la antes tediosa y lenta tarea de obtener datos secundarios.

Una vez concluido el trabajo de fichado de las fuentes se estará en condiciones de

continuar con las operaciones propias del diseño bibliográfico: cotejo y evaluación de la

información, análisis, síntesis y redacción del informe de investigación

2.1.3 Selección de la técnica de recolección de información

Para el presente estudio se utilizaran las técnicas de recolección de datos

Primarios, ya que para el proceso de recolección de datos para la implantación del

software ERP es necesario estar en constante contacto con el entorno real donde se

aplicaran todos estos procesos.

2.2 Modelado de Negocio

Los sistemas organizativos son difíciles de comprender sin un método apropiado

de análisis debido a su amplitud y complejidad. Una organización puede estar formada

por un buen número de áreas funcionales, departamentos y puestos, con múltiples puntos

de contacto entre sí. Un modelo proporciona la oportunidad de organizar y documentar la

información sobre un sistema (Vernadat, 1996). Por lo tanto, la finalidad del modelado

del negocio es describir cada proceso, especificando sus datos, actividades (o tareas),

roles (o agentes) y reglas de negocio (García-Molina, 2007). Kosanke (2003), resume los

objetivos del modelado en: (1) la adquisición de conocimiento explícito sobre los

procesos de negocio en la operativa del negocio, (2) la explotación de dicho

conocimiento en proyectos de reingeniería o mejora, (3) la ayuda a la toma de decisiones

y (4) la facilidad de interoperabilidad entre los procesos de negocio.

 18

Curtis et al. (1992), afirman que existen cuatro puntos de vista en cuanto al

modelado de los procesos de negocio: vista funcional (qué), la cual representa la

dependencia funcional entre los elementos del proceso; vista dinámica (cuándo, cómo),

que proporciona una secuenciación y control de la información sobre el proceso; vista

informacional, que incluye la descripción y relación entre las entidades que son

producidas, consumidas o incluso manipuladas por los procesos, y la vista organizacional

(quién, dónde) que describe quién desarrolla cada tarea o función y dónde se desarrolla

dentro de la organización.

Debido a la naturaleza compleja y dinámica de las organizaciones, los modelos

son necesarios para entender el comportamiento de las mismas y diseñar los nuevos

sistemas así como mejorar el funcionamiento de los existentes. Las siguientes técnicas se

han desarrollado para facilitar la comunicación y la captura de información. A

continuación se enumeran y explican brevemente algunas de las técnicas más

significativas en el modelado de procesos de negocio.

Diagrama de flujo - Flow Chart: Los diagramas de flujo, que datan de los años 60

(Schriber, 1969), se definen como una representación gráfica de una secuencia lógica de

procesos de trabajo (Lankin et al., 1996). Mediante la utilización de diferente simbología,

representa operaciones, datos, direcciones de flujo y recursos; para la definición, análisis

o solución de un problema. Este formalismo es muy flexible, el estándar ofrece la

nomenclatura, pero será quien diseñe el proceso, quien estructure los diferentes bloques

del diagrama según el conocimiento que posea de éste. Se caracteriza por su gran

facilidad de uso y aporta gran cantidad de información ya que muestra la totalidad del
 19

sistema, aunque presenta la problemática de su extensión, lo que dificulta la visión global

de todo el sistema así como que los límites del proceso no suelen estar muy claros

(Aguilar-Savén, 2004).

Diagramas de flujo de datos- Data Flow Diagram (DFD): Los DFD, son

representaciones de información a través de entidades externas, pasos internos de

procesado y elementos de almacenamiento de datos de un proceso de negocio (Kettinger

et al., 1995). Estos diagramas permiten ver cómo fluyen los datos a través de la

organización, los procesos así como las transformaciones que sufren dichos datos y los

diferentes tipos de salidas, aunque no modela representaciones de flujos de materiales,

recursos humanos, y otros elementos relacionados con los procesos de negocio (Yourdon,

1989).

Diagrama entidad-relación - Entity-Relationship (ER) Diagram: El diagrama ER es

un modelo de red, que describe con un alto nivel de abstracción, la distribución de datos

almacenados en un sistema. Los diagramas ER se centran en los datos y en sus

interrelaciones y por ello, no representan la estructura para el modelado de otros

elementos del proceso. Dichos diagramas son representaciones completamente estáticas y

no proporcionan la información en el tiempo para poder analizarla y medirla (Giaglis,

2001).

Diagrama estado-transición – State Transition (ST) Diagram: Los diagramas ST, se

originan para la descripción de la perspectiva dinámica de sistemas dependientes en el

tiempo y consiste en círculos que representan los estados, definidos como el modo

perceptible de comportamiento de un sistema, y flechas, que representan las transiciones

 20

entre estados. Son muy útiles ya que proporcionan información explícita acerca de la

secuencia de tiempo relacionado con los diferentes eventos dentro del sistema. Las

limitaciones las presenta en la descripción de la colaboración entre los objetos que causan

dichas transiciones.

IDEF – Integrated Definition for Function Modelling: IDEF es una familia de técnicas

de modelado, que ofrecen una perspectiva integrada para representar y modelar procesos

y estructuras de datos. Sus inicios se remontan a la necesidad de las Fuerzas Armadas

Estadounidenses por mejorar sus operaciones de producción, iniciándose así el programa

ICAM (Integrated Computer-Aided Manufacturing). La familia IDEF, consiste en un

gran número de técnicas, entre las cuales se destaca IDEF0 e IDEF3, que son aquellas

relacionadas con los procesos de negocio, aunque existen otras versiones como IDEF1,

IDEF1X, IDEF2, IDEF4 e IDEF5.

La técnica IDEF0, está diseñada para modelar las decisiones, acciones y

actividades de una organización u otro sistema, y representa la perspectiva funcional de

modelado, es decir, el qué (Mayer et al., 1995). Es considerada una técnica sencilla pero

poderosa, ampliamente usada en la industria durante la etapa de análisis en la reingeniería

de procesos. Permite identificar apropiadamente los procesos y sus interfaces así como

elaborar los documentos que permitan su control en cualquiera de sus etapas de

desarrollo. IDEF0 utiliza solo un tipo de anotación en sus representaciones gráficas

conocido como ICOM (Input-Control-Output-Mechanism). La representación estática de

sus diagramas no permite visualizar las perspectivas de modelado de comportamiento o

informacional. Para vencer dichas limitaciones, se desarrolló IDEF3 (Process Description

 21

Capture), que describe a los procesos como secuencias ordenadas de hechos o

actividades, representando el cómo, y mostrando la visión dinámica o de

comportamiento.

Diagramas de actividad de roles - Role Activity Diagram (RAD): Los RAD son

utilizados para esquematizar las actividades bajo la responsabilidad de cada rol así como

la interacción entre ellos y con sucesos externos, entendiendo por rol, el comportamiento

deseado de los individuos dentro de la organización (Huckvale y Ould, 1995). Los

diagramas RAD centran su atención en el concepto de rol, por ello su idoneidad en

aquellos contextos en los que la perspectiva organizacional, es un factor clave que debe

ser modelado.

Diagrama de interacción de roles - Role Interaction Diagram (RID): Los RID, son

gráficos que representan los roles de los procesos de negocio. Las actividades están

conectadas a los roles en una matriz. Aunque dichos diagramas son más complejos que

los de flujo, son muy intuitivos y aportan facilidad en su lectura, a pesar que tienden al

desorden debido a la gran cantidad de flechas relacionando diferentes puntos. Los RID,

no son tan flexibles como los de flujo, aunque lo son más que muchas otras técnicas. Su

mejor uso se centra en el diseño del flujo de trabajo y suelen ser utilizados para procesos

que implican la coordinación de actividades interrelacionadas (Aguilar-Savén, 2004).

Redes Petri - Petri Nets (PN): Las PN fueron creadas por el alemán Carl Adam Petri en

1962. En su tesis doctoral "kommunikation mit automaten" (Comunicación con

autómatas), establece los fundamentos para el desarrollo teórico de los conceptos básicos

de las PN que representan una alternativa para modelar el comportamiento y la estructura

 22

de un sistema (Adam, 1962). La manipulación de los datos, tiene que ser representada

directamente en la estructura de la red y esto le confiere un tamaño excesivamente

grande. Además, no tiene en cuenta la estructura jerárquica, y no permite construir un

modelo global mediante la separación de sub modelos con interrelaciones bien definidas.

Técnica Orientada a Objetos - Object-Oriented (OO) Technique: La técnica OO, se

utiliza para modelar y programar procesos caracterizados como objetos, que son

desarrollados y transformados por actividades. Utiliza los objetos como bloque esencial

de construcción y combina la estructura de datos (atributos) y funciones (operaciones) en

una sola entidad. Existen diversidad de técnicas basadas en la programación orientada a

objetos, pero de todas ellas, la más importante es UML (Unified Modelling Language),

lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que

comprende el desarrollo de software. UML ofrece una forma de modelar entes

conceptuales como son los procesos de negocio y funciones de sistema, además de entes

concretos como son escribir clases en un lenguaje determinado, esquemas de base de

datos y componentes de software reusables. UML consiste en nueve diagramas

diferentes, cada uno de los cuales muestra el aspecto estático o dinámico del sistema:

diagrama de clases, de objetos, de estados, de actividad, de secuencia, de colaboración,

de casos de uso, de componentes y de despliegue.

Metodologías Genéricas.-

Normalmente cuando se realiza una búsqueda sobre las técnicas de modelado, se

obtienen resultados que representan a más de una técnica. Dichos resultados son

metodologías generales con facultades para el modelado de procesos.

 23

Desafortunadamente, existe una gran confusión de conceptos, ya que las metodologías

son utilizadas tanto para indicar la propia metodología como las técnicas asociadas a la

misma.

Análisis y diseño estructurado – Structured Systems Analysis and Design

Method (SSADM): Metodología que engloba un sistema de procedimientos, técnicas y

documentación de estándares para el análisis y diseño de las diferentes fases del

desarrollo de sistemas. Se caracteriza por una estructura en cascada, donde cada fase

precedente tiene que estar terminada para poder iniciar la siguiente. Su estructura consiste

en cinco módulos principales, los cuales se dividen en fases, pasos y tareas: estudio de

fiabilidad, análisis de requerimientos, especificación de las necesidades, especificación

del sistema lógico y diseño físico. SSADM utiliza tres técnicas clave para el estudio de

sistemas, denominadas modelado lógico de datos, diagramas de flujos de datos y

modelado entidad/evento (Hutchings, 1996).

Metodología de los sistemas blandos – SoftSystems Methodology (SSM): La

metodología trata con situaciones problemáticas en las cuales existe un alto componente

social, político y humano. El enfoque sistémico atiende al estudio de las relaciones que

conforman numerosos factores de un sistema, tomando muy en cuenta la intensidad con

que dichos elementos se comunican, al integrar una estructura organizacional

determinada. Dicha metodología plantea una visión inter, multi y transdisciplinaria que

ayuda a analizar la empresa de manera integral. Se divide en las siguientes etapas;

reconocer y expresar la situación problemática, producir "definiciones básicas" de

sistemas relevantes, desarrollar modelos conceptuales de los sistemas relevantes,

 24

comparar modelos conceptuales con la situación percibida, identificar cambios deseables

y factibles, y tomar acción para mejorar la situación. Presenta problemas en el análisis

estructurado o para informar sobre una descripción (Checkland y Scholes, 1999).

Metodología GRAI – Graphwith Results and Activities Interrelated: La metodología

GRAI fue desarrollada como análisis del sistema decisional de la empresa. El modelo

GRAI consiste en un macro-modelo de referencia conceptual para los sistemas de

fabricación y un micro-modelo conceptual para los centros de decisión, que son

representados mediante la Rejilla y la Red GRAI respectivamente. La Rejilla GRAI

permite modelar el sistema de decisión, mientras que las Redes permiten modelar las

actividades de decisión de cada centro de decisión identificado en la Rejilla (Doumeingts,

1984). Utiliza cuatro vistas: funcional, física, decisional e informacional, para proveer al

analista de una descripción genérica de los procesos de fabricación. Estas vistas permiten

generar modelos parciales de la empresa.

Evaluación de las Técnicas de Modelado de Procesos de Negocio.-

Las diferentes técnicas y metodologías difieren unas de otras, en el sentido en que

proporcionan la habilidad para modelar diferentes perspectivas de los sistemas de

negocio. Muchas técnicas se centran principalmente en funciones, otras lo hacen en datos

e incluso existen aquellas basadas en los diferentes roles. El caso ideal, sería aquel, en el

que se desarrollase una única técnica que pudiera representar de manera eficiente todas

las perspectivas de forma concisa y rigurosa, para de este modo, poder ser aplicada a

todas las situaciones de modelado. En la Tabla 1, se muestra una clasificación de las

diferentes técnicas vistas anteriormente, junto con una valoración de su idoneidad para la
 25

representación de las diferentes perspectivas de modelado. La evaluación y selección de

una técnica, depende de las características del proyecto en cuestión, así como de la

capacidad y el conocimiento que el diseñador posea de cada una.

Tabla 1: Representación de las diferentes técnicas de gestión de los procesos de negocio

mediante las perspectivas de modelado. Tomado de Giaglis (2001).

Técnicas PERSPECTIVAS DE MODELADO

Funcional Dinámica Organizacional Informacional
Diagrama de flujo Sí No No Limitada
IDEF0 Sí No Limitada No
IDEF3 Limitada Limitada No Limitada
Redes de Petri Sí Sí No No
Diagrama RAD No Limitada Sí No
Diagrama de flujo de Sí No Limitada Sí
datos
Diagrama entidad- No No No Sí
relación
Diagrama estado- No Limitada No Limitada
transición
Técnica Orientada a Sí Limitada Limitada Sí
Objetos

2.3 Ingeniería de Software

2.3.1Metodologías de Desarrollo de Software. -

Una Metodología de desarrollo de software, consiste principalmente en hacer uso

de diversas herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente

este tipo de metodología, tienen la necesidad de venir documentada, para que los

programadores que estarán dentro de la planeación del proyecto, comprendan

perfectamente la metodología y en algunos casos el ciclo de vida del software que se

pretende seguir.
 26

Aunque actualmente existen mucha variedad en metodologías de programación.

La realidad es que todas están basadas en ciertos enfoques generalistas que se crearon

hace muchos años, algunos tipos de metodologías de desarrollo de software que se

utilizaron e inventaron al principio de nuestra era tecnológica y son las que veremos a

continuación.

Metodología en cascada: Framework Lineal.-

El modelo de desarrollo de Software en cascada, es una metodología de la

programación muy antigua. Si bien su creador nunca lo menciona como metodología en

cascada, el funcionamiento y lineamiento de los procesos de la planeación, son

exactamente iguales. Básicamente, el estilo del modelo en cascada, es que se podrá

avanzar a la siguiente fase, si la anterior no se encuentra totalmente terminada, pues no

tiene porque haber vuelta atrás. Vamos a ver cuáles son las fases de desarrollo de

software del modelo en cascada.

1.- Análisis de Requisitos.

2.- Diseño del Sistema.

3.- Diseño del Programa.

4.- Codificación.

5.- Ejecución de Pruebas.

6.- Verificación.

7.- Mantenimiento.

Como se puede observar, el proceso de desarrollo de software es bastante

complejo. Sin embargo uno de sus principios es que cada una de las fases elaboradas, se
 27

encuentre documentada perfectamente, de este modo, si el desarrollo queda suspendido

en alguna fase, cualquier usuario que quiera continuar con el proyecto lo podrá hacer

leyendo la documentación.

Método de Prototipos.-

Esta metodología de la programación todavía sigue siendo la favorita de muchos.

Consiste básicamente en que en base a los requerimientos y necesidades que tiene el

cliente, se realiza de forma rápida un prototipo, este no vendrá completo ni mucho menos

terminado, pero si permitirá contar con las bases necesarias para que cualquier

programador pueda seguir trabajando en el hasta llegar al código final.

Un prototipo es una versión no terminada del producto que se le entregará al

cliente o usuario final. Esto nos genera cierta ventaja en el desarrollo de productos

similares con funciones distintas.

A continuación se mencionan las etapas de desarrollo de software de la

metodología de prototipos.

1.- Planeación.

2.- Modelado.

3.- Elaboración del Prototipo.

4.- Desarrollo.

5.- Entrega y retroalimentación.

6.- Comunicación con el cliente.

7.- Entrega del producto final.

 28

El modelo de prototipos puede llegar a ser un poco más tedioso, aunque todo

dependerá del ámbito en que lo utilices. Sin embargo uno de sus principios básicos que

seguramente habrás notado, es que con el método de prototipos el proyecto se va

dividiendo en partes cada vez más pequeñas, para evitar el peligro ante los riesgos frente

a los que estamos expuestos.

Modelo Incremental o Iterativo y Creciente

El modelo Incremental, es una metodología de la programación muy utilizada hoy

en día, pues su comodidad de desarrollo permite que te obtenga un producto final mucho

más completo y exitoso. Se trata especialmente de la combinación de los modelos lineal e

iterativo o bien, modelo de cascada y prototipos. Básicamente consiste en completar

varias iteraciones de lo que es el modelo de cascada, pero sin completar ninguna,

haciendo iteraciones lo que se hace es crear una evolución en el producto, permitiendo

que se agreguen nuevas especificaciones, funcionalidades, opciones, funciones y lo que el

usuario requiera después de cada iteración.

El Modelo Incremental repite el modelo de cascada una y otra vez, pero con

pequeñas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De

este modo el usuario final se ve sumamente sumergido en el desarrollo y puedes

proporcionarle un resultado óptimo.

El modelo iterativo o incremental, cuenta con algunas fases de desarrollo de

software que se mencionan a continuación.

1.- Inicialización.

2.- Periodos de Iteración.

3.- Lista de Control

 29

La idea de un modelo incremental, es utilizar una serie de mini modelos de

desarrollo de software en cascada, segmentando requerimientos y permitiendo que el

usuario vaya de la mano con el proyecto durante la realización.

Modelo en Espiral.-

El modelo en espiral, fue utilizado y diseñado por primera vez por Barry

Boehm en 1986. Se trata nuevamente de una combinación entre el modelo lineal o de

cascada y el modelo iterativo o basado en prototipos, sin embargo a este sistema lo que

debemos añadirle es la gestión de riesgos, algo que en los modelos anteriores ni siquiera

se menciona.

Este modelo, consiste en ciertas fases que se van realizando en modo de espiral,

utilizando procesos de la misma forma en que se utilizan en el modelo de cascada, sin

embargo aquí estos no son obligatorios y no llevan precisamente el orden establecido.

Básicamente se trata de un modelo evolutivo, que conforme avancen los ciclos, irá

incrementando el nivel de código fuente desarrollado, un incremento en la gestión de

riesgos y por supuesto un incremento en los tiempos de ejecución y planificación del

sistema, esto es lo que tiene el modelo en espiral.

El modelo en espiral es principalmente utilizado para el desarrollo de grandes

proyectos como la creación de un sistema operativo. Sin embargo necesitas de ciertos

requisitos, como el hecho de contar con personal completamente capacitado para las

funciones que se requieran. A continuación se mencionan las fases o tareas dentro del

modelo de espiral.
 30

1.- Determinar Objetivo.

2.- Análisis de Riesgo.

3.- Desarrollar, Validar y Probar.

4.- Planificación.

En el modelo de espiral, toda la atención está enfocada hacia el análisis de

riesgos, pues el objetivo primario será reducir los riesgos que se vayan generando, de otra

forma el sistema no llegará a ser seguro jamás.

Modelo RAD: Desarrollo Rápido de Aplicaciones (Rapid Applicacion

Development).-

La metodología RAD o desarrollo rápido de aplicaciones, no cuenta con una serie

de fases ordenadas por así decirlo. Aunque si está basada en lo que es el modelo de

cascada y la creación de prototipos, sin embargo el proceso es muy independiente a

contar con ciertas fases estipuladas como los modelos que hemos visto anteriormente. Así

que vamos a ver los principios del modelo RAD.

El Modelo RAD, está basado en el uso de las iteraciones y principalmente en el

manejo de prototipos. Sin embargo a diferencia del resto, la metodología RAD hace uso

de las Herramientas CASE, las cuales permitirán acelerar el proceso considerablemente.

Metodologías Agiles.-

Con el paso del tiempo, estaba claro que las metodologías tradicionales,

simplemente no se iban a acoplar con las nuevas tecnologías, los nuevos lenguajes y

sobretodo los programadores modernos. Es por eso que desde principios del Siglo, se han

desarrollado lo que son las metodologías ágiles. Una metodología ágil, consiste
 31

principalmente en trabajar con menos documentación de la que, como vimos, las

metodologías tradicionales utilizan en todo momento.

Existen una gran cantidad de metodologías ágiles de desarrollo de software y

todas las vamos a ver a continuación.

Metodología SCRUM.-

Metodología Scrum

Para que un proyecto ingrese al marco de lo que es el modelo Scrum, debe contar

con las siguientes características:

 Desarrollo Incremental.

 Calidad de Personas.

 Adiós al secuencial y cascada.

La metodología Scrum, es bastante amigable y fomenta lo que es el trabajo en

equipo en todo momento, con la finalidad de conseguir los objetivos de una forma rápida.

Los procesos de la metodología son los siguientes:

 Product Backlog.

 Sprint Backlog.

 Sprint Planning Meeting.

 Daily Scrum o Stand-up Meeting.

 Sprint Review.

 Sprint Retrospective.

Los equipos que conforman la metodología Scrum y con los cuales se trabajará

arduamente son los siguientes:

 32

 Product Owner.

 Scrum Master.

 Scrum Team.

 Cliente.

Metodología Kanban.-

Se trata de una metodología Japonesa, la cual consiste en ir etiquetando con

tarjetas cada uno de los procesos que se deben llevar a cabo, también se le ha

denominado como “Un sistema de producción de alta efectividad y productividad”. De

hecho, empresas como la marca de autos Toyota, fueron una de las primeras en

implementarla para acelerar los procesos de producción.

Una de las principales ventajas de Kanban, es que además de ser una metodología

Ágil, también es muy fácil de usar e implementar, sobretodo porque el equipo de trabajo

se unirá y empezarán a trabajar a la par en diferentes aspectos del desarrollo. A

continuación se mencionan los principios básicos de la metodología Kanban.

 Garantía de calidad.

 Desperdicios.

 Mejora Continua.

 Es Flexible.

Realmente una de las cosas que diferencian a Kanban del resto, es que acá se

necesitará un tablero de verdad. No es nada extraño ni loco, con el avance de los días de

trabajo se notará que fue una magnífica idea comprar ese tablero y los post-it para
 33

escribir objetivos. Así que vamos a ver los pasos para realizar bien la configuración de

una metodología Kanban.

1.- Definir el Flujo de Trabajo.

2.- Fases del Ciclo de Producción.

3.- Stop Starting, Start Finishing.

4.- Tener un Control.

Metodología XP.-

Esta metodología es posiblemente la más destacada de las metodologías ágiles y

esto se debe a su gran capacidad de adaptación ante cualquier tipo de imprevisto que

surja. Pues la idea no es mantener ciertos requisitos desde que se está elaborando el

proyecto, sino que durante el proceso, estos vayan cambiando o vayan evolucionando

gradualmente sin complicaciones. Básicamente los creadores de esta metodología XP,

consideran que es mejor adaptarte en el proceso a los requisitos que vayan apareciendo,

que iniciar con requisitos y desarrollar un proyecto en base a eso.

Si queremos ver la metodología con otra perspectiva, se podría decir que la

metodología XP o metodología de programación extrema, como también se le conoce. Es

la combinación de las demás metodologías, solamente que se van utilizando de acuerdo a

como sea necesario, por eso es considerada como la más destacada de las metodologías

ágiles. Así que es momento de entrar en detalles y vamos a ver cuáles son los valores que

conforman a la metodología de programación XP. Las características que componen la

metodología XP son las siguientes:

 Tipo de desarrollo iterativo e incremental.

 34

 Pruebas unitarias.

 Trabajo en equipo.

 Alguien del equipo trabaja con el cliente.

 Corrección de errores.

 Reestructuración del código.

 El código es de todos.

 Código simple es la clave.

El equipo de trabajo que compone la metodología XP está compuesta por los siguientes

roles:

 Programador.

 Tester.

 Tracker.

 Entrenador.

 Consultor.

 Gestor.

2.3.2 Arquitectura de Software. -

La arquitectura de software es un conjunto de patrones que proporcionan un

marco de referencia necesario para guiar la construcción de un software, permitiendo a

los programadores, analistas y todo el conjunto de desarrolladores del software compartir

una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación. Es

considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto que

establecen la estructura, funcionamiento e interacción entre las partes del software.

 35

Componentes e interacciones.-

Componentes.-La arquitectura de software se compone por:

 Clientes y servidores.

 Bases de datos.

 Filtros.

 Niveles en sistemas jerárquico.

Interacciones.-Entre los componentes de la arquitectura de software existe un conjunto

de interacciones entre las que sobresalen:

 Llamadas a procedimientos.

 Comportamiento de variables.

 Protocolos cliente servidor.

 Transmisión asíncrona de eventos.

Características.-

La arquitectura de software forma la columna vertebral para construir un sistema

de software, es en gran medida responsable de permitir o no ciertos atributos de calidad

del sistema entre los que se destacan la confiabilidad y el rendimiento del software.

Además es un modelo abstracto reutilizable que puede transferirse de un sistema a otro y

que representa un medio de comunicación y discusión entre participantes del proyecto,

permitiendo así la interacción e intercambio entre los desarrolladores con el objetivo final

de establecer el intercambio de conocimientos y puntos de vista entre ellos.

Tipos de arquitecturas.-Para utilizar la arquitectura de software se sigue un conjunto de

patrones arquitectónicos, entre los cuales podemos encontrar:

 36

 Cliente-Servidor

 Blackboard.

 Modelo entre capas.

 Intérprete.

 Orientado a servicios.

Niveles de un diseños de software.-El diseño de software tiene varios niveles los cuales

están relacionados entre sí, cada nivel tiene sus propios problemas, técnicas de análisis y

componentes los que pueden ser simples o complejos, reglas de composición las cuales

permiten construir componentes complejos.

Modelos de la arquitectura de software.-La arquitectura de software cuenta con varios

modelos, ellos son:

Modelos estructurales.-Son similares a la vista estructural, pero su énfasis primario

radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de

concentrarse en su composición. Los modelos de framework a menudo se refieren a

dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante

incluye arquitecturas de software específicas de dominios, como CORBA, o modelos

basados en CORBA, o repositorios de componentes específicos, como PRISM.

Modelos dinámicos.- Enfatizan la cualidad conductual de los sistemas ,“Dinámico”

puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada

en el progreso de la computación, tales como valores cambiantes de datos.

Modelos de proceso.-Se concentran en la construcción de la arquitectura, y en los pasos

o procesos involucrados en esa construcción. En esta perspectiva, la arquitectura es el

 37

resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el

actual trabajo sobre programación de procesos para derivar arquitecturas.

2.3.3 Pruebas de Software. -

Las pruebas de software consisten en la dinámica de la verificación del

comportamiento de un programa en un conjunto finito de casos de prueba, debidamente

seleccionados de por lo general infinitas ejecuciones de dominio, contra la del

comportamiento esperado. Son una serie de actividades que se realizan con el propósito

de encontrar los posibles fallos de implementación, calidad o usabilidad de

un programa u ordenador; probando el comportamiento del mismo.

Pruebas como proceso.- La prueba es un proceso que se enfoca sobre la lógica interna

del software y las funciones externas. Es un proceso de ejecución de un programa con la

intención de descubrir un error, no puede asegurar la ausencia de defectos; sólo puede

demostrar que existen defectos en el software.

Objetivos de las pruebas de software.-La prueba de software es un elemento crítico

para la garantía del correcto funcionamiento del software. Entre sus objetivos están:

 Detectar defectos en el software.

 Verificar la integración adecuada de los componentes.

 Verificar que todos los requisitos se han implementado correctamente.

 Identificar y asegurar que los defectos encontrados se han corregido antes de

entregar el software al cliente.

 Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes

clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

 38

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los

principios básicos que guían las pruebas del software.

Principios de las pruebas de software.- Las pruebas se rigen por una serie de principios,

una buena comprensión de estos facilitará el posterior uso de los métodos en un

efectivo diseño de casos de prueba. A continuación se citan:

 La prueba puede ser usada para mostrar la presencia de errores, pero nunca su

ausencia.

 La principal dificultad del proceso de prueba es decidir cuándo parar.

 Evitar casos de pruebas no planificados, no reusables y triviales a menos que

el programa sea verdaderamente sencillo.

 Una parte necesaria de un caso de prueba es la definición del resultado esperado.

 Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada

válidas y esperadas sino también para condiciones no válidas e inesperadas.

 El número de errores sin descubrir es directamente proporcional al número de

errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software

ayudan a refinar el producto de software a través de las etapas involucradas.

Etapas involucradas en las pruebas de software.-

 Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo,

para qué exactamente se hace la prueba.

 39

 Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a

utilizar para medir la calidad y qué clase de elementos de prueba se deben

usar.

 Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o

situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o

para revelar algo sobre el atributo de calidad que se está midiendo.

 Determinar cuáles deberían ser los resultados esperados de los casos de

prueba y crear el documento que los contenga.

 Ejecutar los casos de prueba.

Evaluación de resultados.-Comparar los resultados de la prueba con los resultados

esperados. Cualquier discrepancia entre ellos significa un error. Típicamente el error está

en el sistema o unidad probada, pero también puede ser generado por algún aspecto del

mismo proceso de prueba.

2.4 ERP

Un ERP (Planificación de Recursos Empresariales, Enterprise Resource Planning

por sus siglas en ingles), es un software que integra varias operaciones de una empresa en

un único sistema, esto con la finalidad de optimizar tiempos, minimizar costos, dar

respuesta rápida a los problemas/necesidades y realizar un manejo adecuado y oportuno

de la información de la empresa.

La mayor fortaleza de un ERP es su poder integrador en diferentes procesor como

ser: Logística, Inventarios, Compras, Ventas, Distribución, Producción, Recursos

Humanos, entre otros.

 40

A continuación se citan conceptos con sus respectivos autores:

"ERP representa un amplio espectro de funciones que intenta abarcar todas las

entidades de una empresa. Requiere de la profundidad organizacional y funcional de una

gran variedad de empresas de manera que se pueda examinar y modificar un concepto de

empresa único" (Gartner Group. E.R.P. vendorGuide 1997).

"Solución de software que se enfoca a las necesidades de la empresa, tomando

una visión de los procesos para cumplir todos los objetivos corporativos, buscando

integrar todas las funciones de la empresa." (Hernández, José Antonio. (1999). SAP R/3.

Ed. Mc GrawHill)

"Un Sistema de planificación diseñado para reducir el tiempo de respuesta, ciclo

de producción, optimizar calidad, mejorar el manejo de activos, reducir los costos,

optimizando la comunicación" (Glovia, citado por Camacho, Salvador. (1997).

Planificación de Recursos Empresariales.).

Código Abierto (Open Source).-

Open source o código abierto es el término empleado al software distribuido bajo

una licencia que permite al usuario acceso al código fuente. Este tipo de licencia

posibilita el estudio y la modificación del software con total libertad. Además, su

redistribución está permitida siempre y cuando esta posibilidad vaya en concordancia con

los términos de licencia bajo la que se adquiere el software, los principales ideales del

movimiento Open Source son:

 Apostar por la excelencia técnica como el objetivo prioritario, siendo la

compartición del código fuente un medio para esto.

 41

 Darle mayor relevancia a los beneficios prácticos de compartir el código fuente.

 Interesar a las principales casas de software y otras empresas de la industria de la

alta tecnología en el concepto.

 Evitar la ambigüedad del término inglés free (gratis o libre) en “Free Software”.

Oddo.-

Conocido antes como OpenERP, es un software ERP de código abierto,

desarrollado en Phyton con base de datos PostgreSQL, diseñado para cubrir todas las

necesidades de las empresas mediante aplicaciones específicas, orientadas a la gestión

empresarial.

En un principio fue diseñado para las PYMEs, pero con el tiempo fue

evolucionando hasta el punto de ser utilizado en grandes empresas, ofreciendo un

software

Ventajas.-

 Código abierto.

 Completo.

 Fiable.

 Amigable.

 Fácil de usar.

 Dinámico.

 Escalable.

 Multiplataforma.

Desventajas.-
 42

 Las opciones de soporte en soluciones de código abierto suelen quedar cortas en

comparación al soporte que brinda una empresa de pago.

 43

Capítulo 3

DISEÑO METODOLÓGICO

3.1 Enfoque de Investigación.-

La optimización de los procedimientos internos de la unidad de almacenes de la

dirección de la Escuela Universitaria de Posgrado mediante la implantación de un

software ERP será el enfoque principal de esta investigación.

Se propondrá la implantación de un software ERP para la gestión y

administración de pedidos de material de escritorio, utilizando una base de datos

centralizada para un correcto manejo de la información que ayude en la toma de

decisiones oportuna para evitar el desabastecimiento de material de escritorio en almacén,

con lo que se automatizaran muchos de los procesos manuales mediante el manejo del

software ERP.

Las técnicas de recolección de datos que se utilizara para este proyecto serán la

Observación y la Entrevista, debido a que son técnicas que interactúan directamente con

la realidad misma y no requieren de elaboración previa, por lo que pueden ser utilizadas

en cualquier momento.

La técnica de modelado del negocio a utilizar será el diagrama de actividad de

roles por esquematizar las actividades bajo la responsabilidad de cada rol así como la

interacción entre ellos y con sucesos externos, además de ser idóneos en contextos

organizacionales.
 44

3.2 Tipo de Investigación.-

El tipo de investigación en el presente proyecto será la descriptiva, debido a que

se busca describir el estatus actual de la organización y se recolectara la información de

manera sistemática.

3.3 Alcance de la Investigación.-

3.3.1 Descriptiva. -

Por medio de esta investigación se pretende conocer más a fondo los procesos

internos de la unidad de almacenes de la Escuela Universitaria de Posgrado, así también

identificar todos los problemas identificados y no identificados.

3.3.2 Correlacional. -

También se desea conocer e identificar la relación con las demás unidades,

proveedores y otras partes involucradas en los procesos.

 45

Capítulo 4

MARCO PRÁCTICO

4.1 Técnicas de recolección de datos.-

Las técnicas de recolección de datos en el presente proyecto serán los siguientes:

Observación participante.-El investigador deberá involucrarse completamente con las

actividades y procedimientos internos de la unidad de almacenes.

Entrevista no estructurada.-El investigador deberá realizar las entrevistas al personal

de almacenes y partes involucradas con un enfoque dirigido a los objetivos de la

investigación, las preguntas deberán ser adaptadas dependiendo de las situaciones y

características de los sujetos en estudio.Los temas de interés a tratar para la entrevista no

estructurada son los siguientes:

 Ingreso de material

 Salida de material

 Control interno de kardex

4.2 Modelado de Negocio.-

Para el modelado del negocio se eligió el diagrama de actividad de roles (RAD)

porque esquematizan las actividades bajo la responsabilidad de cada rol así como la

interacción entre ellos y con sucesos externos. Además de ser ideales para proyectos con

perspectivas organizacionales. A continuación se describen los roles, actividades e

interacciones.
 46

Roles.-

 Funcionario.

 Jefe de departamento.

 Almacenes.

 Proveedor.

 Comisión de adjudicación.

Actividades.-

Salida de material.-
 47

Ingreso de material.-

4.3 Ingeniería de Software.-

4.3.1 Metodología de desarrollo. -

La metodología de desarrollo para las modificaciones en el software ERP en caso

de ser necesarias será Programación Extrema (XP), por su capacidad de adaptación ante

cualquier tipo de imprevisto.

 48

4.3.2 Arquitectura de software. -

Para el presente estudio y se realizara una comparación de los sistemas ERP Odoo

y SAP por ser estos los más populares dentro de lo que es la gran oferta de sistemas ERP

en el mercado tanto de Código Abierto como de pago. Esto hace suponer que por su

popularidad son los sistemas más completos en su categoría y cuentan con

documentación amplia para su estudio. A continuación veremos características, ventajas

y desventajas de cada uno de los ERPs.

Arquitectura de Odoo.-

La arquitectura del sistema Odoo es cliente-servidor, lo que permite que todos los

usuarios trabajen sobre la misma base de datos. Teniendo como principal ventaja el de

tener la información disponible y sincronizada en todo momento, además de utilizar

también la capacidad de procesamiento de datos de las maquinas del cliente.

A Continuación se muestra gráficamente la arquitectura del software ERP Odoo.

 49

4.4 Instalación de Odoo.-

La instalación de Odoo se realizó en el sistema operativo Linux con los siguientes

detalles:

 Distribución: Ubuntu Server

 Version: 18.04.1 LTS

 DBMS:

Existen varias formas de instalar Odoo, pero la forma más rápida y confiable es

mediante los repositorios oficiales, a continuación, se listan los comandos necesarios para

instalar el ERP Odoo en Ubuntu Server:

Instalación de PostgreSQL.-

 sudo apt-getinstallpostgresql

 sudo su - postgres -c "createuser -s odoo"

Instalación de wkhtmltopdf.-

 Wgethttps://builds.wkhtmltopdf.org/0.12.1.3/wkhtmltox_0.12.1.3-

1~bionic_amd64.deb

 sudo aptinstall /wkhtmltox_0.12.1.3-1~bionic_amd64.deb

Instalación y configuración de Odoo.-

 sudo su – odoo

 whoami

 git clone https://www.github.com/odoo/odoo --depth 1 --branch 11.0

/opt/odoo/odoo11

 cd /opt/odoo
 50

 python3 -m venv odoo11-venv

 source odoo11-venv/bin/activate

 pip3 install Wheel

 pip3 install -r odoo11/requirements.txt

 deactivate

 exit

 sudo mkdir /opt/odoo/odoo11-custom-addons

 sudo chownodoo: /opt/odoo/odoo11-custom-addons

 sudo cp /opt/odoo/odoo11/debian/odoo.conf /etc/odoo11.conf

 editar el archivo /etc/odoo11.conf con el siguiente contenido:

[options]
; Thisisthepasswordthatallowsdatabaseoperations:
admin_passwd=my_admin_passwd
db_host=False
db_port=False
db_user=odoo
db_password=False
addons_path=/opt/odoo/odoo11/addons
; Ifyou are usingcustom modules
; addons_path = /opt/odoo/odoo11/addons,/opt/odoo/odoo11-custom-addons

 Crear el servicio de Odoo en /etc/systemd/system/odoo11.service con el siguiente

contenido:

[Unit]
Description=Odoo11
Requires=postgresql.service
After=network.targetpostgresql.service

[Service]
Type=simple
SyslogIdentifier=odoo11
PermissionsStartOnly=true
User=odoo
 51

Group=odoo
ExecStart=/opt/odoo/odoo11-venv/bin/python3 /opt/odoo/odoo11/odoo-bin
-c /etc/odoo11.conf
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target

 sudo systemctldaemon-reload

 sudo systemctlstart odoo11

 sudo systemctl status odoo11

 sudo systemctlenable odoo11

 sudo journalctl -u odoo11

Si la instalación fue correcta, veremos la siguiente ventana mediante el navegador

con la siguiente dirección:

http://192.168.1.4:8069/
 52

4.5 Módulos de Odoo.-

Tomando en cuenta el modelo de negocio de la Dirección de la Escuela

Universitaria de Posgrado, los módulos necesarios para el correcto funcionamiento del

ERP Odoo en el almacén de la EUPG son los siguientes:

Gestión de Inventario. –

Este módulo se utilizará para organizar el almacén, utilizando el método de

almacenamiento más eficiente para mejorar los procesos internos de la oficina de

almacenes de la EUPG y de esta manera evitar desabastecimiento de material.

Gestión de Ventas. –

Con este modulo tendremos todas las herramientas necesarias que permitan a los

funcionarios de la EUPG revisar y solicitar material de escritorio fácilmente, además de

contar con reportes sobre la salida de material de almacén.

Gestión de Compras. –

Con este módulo podremos gestionar fácilmente a los proveedores de material y

también las órdenes de compra, podremos mejorar el rendimiento de nuestro inventario

 53

en base a los niveles de stock y también obtener reportes y estadísticas de nuestras

compras

Comercio Electrónico. -

Mediante este modulo podremos disponer de una interfaz personalizable para

ofrecer el material de escritorio a los funcionarios, mostrando los productos disponibles

al detalle con información actualizada en todo momento.

Ventas y vales de compra. –

Con este módulo podremos generar fácilmente recibos y vales de compra, en vista

de que los productos distribuidos internamente no requieren de factura.

También se instalaron aplicaciones adicionales, dependientes de los modulo antes

instalados, son los siguientes:

 54

Debates. –

Con este modulo se lograra mejorar la comunicación de los funcionarios con

herramientas como el chat grupal chat privado, integrados en todos los módulos

instalados.

Gestión de facturas. –

Modulo que permite emitir facturas con el mínimo esfuerzo, para el presente

proyecto no se emitirán facturas.

Constructor de sitios web. –

Modulo que permite personalizar fácilmente nuestro sitio web de acuerdo a los

requerimientos y necesidades del negocio.

 55

4.6 Configuración de Odoo. -

Odoo cuenta con asistentes de configuración en la mayoría de los módulos, lo que

facilita en gran manera la configuración de estos módulos, de manera que se ajusten a

nuestro modelo de negocio. Estos asistentes aparecen en la parte superior del panel de

navegación.

Asistente de configuración modulo “sitio web”

 56

Después de terminar con el asistente de configuración del módulo “sitio web”

tendremos una interfaz de usuario limpia y amigable.

Vista de página principal del sistema.

Asistente de configuración modulo “inventario”

 57

Creación de productos. –

Para la creación de productos se tomaron las siguientes consideraciones:

 Los productos son publicados en el sitio web para visualización de los

usuarios del sistema.
 El precio de venta es igual al precio de venta, porque el material de almacén
es para la distribución interna.
 Se quitaron los impuestos porque no se manejaran facturas.
 Se crearon reglas de desabastecimiento para los productos con 5 unidades
como mínimo.
 58

Vista de administrador de la página de productos

Vista usuarios de la página de productos

 59

Los productos que no tienen existencias son bloqueados y no es posible añadirlos al

carrito.

Vista compra o pedido de un producto sin existencia.

 60

Creación de proveedores. –

Para el registro de proveedores se requiere de la siguiente información:

 Nombre
 Dirección
 Teléfono

Vista del sistema registro de proveedores

 61

Compras. -

Mediante el modulo de compras podemos emitir solicitudes de presupuestos o

cotizaciones.

Vista del sistema reporte solicitud de presupuesto o cotización

 62

También es posible generar las confirmaciones de pedido de compra u órdenes de

compra.

Vista del sistema reporte confirmación pedido u orden de compra.

Al finalizar el proceso de compra los productos recibidos se añaden automáticamente al

stock del almacén y quedan disponibles para la compra o distribución.
 63

Clientes. -

Para el presente caso de estudio los clientes serán los funcionarios de la EUPG y
serán registrados con los siguientes datos:
 Nombre.
 Dirección.
 Puesto de trabajo.
 Teléfono.
 Correo electrónico.

Vista del sistema registro de clientes

 64

Ventas. -

Los clientes seleccionan los productos desde la página web y generan una orden
de cotización o pedido de material.

Vista del sistema reporte de pedido de material

 65

Una vez validado el pedido se genera el vale o recibo de entrega.

Vista del sistema reporte de vale de entrega

Al finalizar la venta se actualizan automáticamente los inventarios, restando los

productos solicitados.
 66

4.7 Conclusiones. -

Tomando en cuenta la estructura organizacional de la Dirección de la Escuela

Universitaria de Posgrado, concluimos que:

El software más adecuado para su implantación en almacenes es Odoo.

 Por su simplicidad al momento de instalar y manipular el software.

 Por permitir la posibilidad de expansión de la empresa e integración con

otro software sin la necesidad de recurrir a terceros.

 Por su bajo costo con soluciones en la nube.

 Existe amplia documentación en la WEB.

 La UMSS cuenta con el personal necesario y calificado para realizar la

implantación a corto plazo.

4.8 Recomendaciones. -

Para la implantación del software ERO Odoo se debe tomar en cuenta las
siguientes recomendaciones.

 La implantación del sistema ERP podría producir cambios estructurales

en la organización.

 Podría producirse resistencia al cambio hacia nuevas tecnologías por parte

de los usuarios finales del sistema.

 En caso de requerir modificaciones o adecuaciones en el sistema se

requerirá de personal capacitado.

 67

4.9 Referencias. -

Odoo. Odoo Documentation. [En línea]. Disponible en:

https://www.odoo.com/documentation/user/11.0/index.html [2018, 5 de marzo].

Richard Marcelo Mora Guallimba. Estudio de factibilidad para la creación de una

empresa de servicio de implementación y adaptación del sistema ERP de código libre
para las pymes en el distrito metropolitano de Quito. [En línea]. Disponible en:
http://repositorio.espe.edu.ec/xmlui/bitstream/handle/21000/8254/T-ESPE-
047490.pdf?sequence=1&isAllowed=y [2018, 10 de agosto]

Linuxize. How to deploy Odoo 11 on Ubuntu 18.04. [En línea].Disponible en:

https://linuxize.com/post/how-to-deploy-odoo-11-on-ubuntu-18-04/#install-and-
configure-postgresql [2018, 10 de agosto]

Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, P. (2010).
Metodología de la investigación: Roberto Hernández Sampieri, Carlos Fernández Collado
y Pilar Baptista Lucio (5a. ed. --.). México D.F.: McGraw-Hill.

Martí Picó, Francesc. Estudio comparativo de paquetes ERP en el ámbito del SW libre.
[En línea].Disponible en:
https://riunet.upv.es/bitstream/handle/10251/10947/Memoria.pdf [2018, 6 de marzo]