Tes Is Zuri LK A Bolivar

UNIVERSIDAD DE ORIENTE
NCLEO MONAGAS
INGENIERA DE SISTEMAS
COMISON DE TRABAJOS DE GRADO
MATURN / MONAGAS / VENEZUELA
DESARROLLO DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE,

GESTIONE Y CONTROLE LAS REQUISICIONES DE LA EMPRESA
EXTERRAN VENEZUELA, C.A. MATURN EDO MONAGAS.
Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de

Grado, como requisito para optar al ttulo de Ingeniero de Sistemas.
Br: Zurilka A. Bolvar. C.I: 17.420.916

Asesor Acadmico:
Ing. Desiree Andrico C.I: 11.781.658
Asesor Laboral:
Ing. Antonio Villegas. C.I: 12.539.838
Maturn, Agosto de 2010.
DEDICATORIA
Dedico este trabajo de grado muy especialmente a Dios todopoderoso y
a la virgen de la Candelaria, porque siempre he contado con sus
bendiciones.
A mis padres Zurilma y Carlos, quienes con su ayuda y apoyo

incondicional que me brindas desde el cielo pap y tu madre que has sabido
ser padre y madre estos ltimos 5 aos gracias a ustedes y a su infinito amor
nos han sabido guiar a mis hermanos y a m por el buen camino de la vida.
Junto a ustedes siempre batallando y luchando para que nunca nos

faltara nada, sobre todo mucho amor, cario y fuerzas para poder seguir
adelante eres sin duda alguna el pilar fundamental de mi vida. Sin su ayuda
no hubiese podido alcanzar las metas que a lo largo de mi vida he logrado.
As mismo, dedico este trabajo de manera muy especial a mi hermana,

Karla Bolvar, quien siempre ha sido fuente de apoyo y ayuda no puedo tener
quejas de la persona que siempre ha estado a mi lado dndome fuerzas en
mis momentos ms difciles.
A mi hermano Marvel Bolvar que a pesar de su corta edad se que le ha

tocado vivir cosas muy difciles que poco a poco hemos podido ir superando,
a Gissel Azacn; sabes que eres una hermana para mi gracias por estar
siempre all, a mi hermano Carlos Bolvar muy a pesar de la distancia has
sido mi hermano mayor y siempre te he querido mucho gracias por tu ayuda
iii
desde que muri pap se que no nos has abandonado, mil gracias te quiero
mucho.
Gracias hermanas, Gracias hermanos!!!!
A mi familia por todo el apoyo y por creer en m, este sueo cumplido

es para ti abuelas, tas, tos, primas, primos, sobrinos, etc.
A mi cuado Wilmer Gonzlez que me ha ayudado mucho, en los

momentos ms difciles, por tu valiosa colaboracin y tenaz convivencia eres
parte de este sueo cumplido, gracias cuado.
De igual forma dedico este trabajo de grado a la familia Marn Alfaro

que ha estado conmigo en los momentos ms difciles y ha sabido brindarme
de manera desinteresada su gran ayuda y apoyo. Gracias por todo que Dios
les bendiga siempre.
iv
AGRADECIMIENTOS
A Dios por haberme obsequiado una hermosa familia y unos excelentes
padres.
A la Virgen de la Candelaria siempre estas cuidndonos gracias por

todas tus bendiciones.
A mis padres porque sin ellos no hubiese logrado esta importante meta.
A toda mi familia, a mis abuelitas Sobella y Leonides las quiero

muchsimo gracias por tanto cario, a mis tas, Norma, Nelly, Onolys, Mirian,
Mireya, Hilda, Deyaneria, Zoraida, Yirtza, a mis tos, Julio Guevara, Luis
Bolvar y Luis Andrade a mis primas, Neliana, Neliand, Neliangela, Yessika,
Virginia, Ma. Beatriz, Ma. Gabriela, Victoria, Vernica, Yil, a mis primos, Julio,
Luis, Cesar, Cruz, Danny, Jubal, Jos, Hctor, Rafael, Hctor, Roberto por
apoyarme siempre en los buenos y malos momentos.
A una Familia muy especial que llego a mi vida en el momento donde

ms necesite una mano extendida en una ciudad totalmente ajena, Oslenia y
Hctor Marn mil gracias por todo lo que me han dado son merecedores de
este ttulo son personas muy especiales en mi vida. Gracias Familia.
A la Universidad de Oriente, por haberme dado la oportunidad de

estudiar y formarme profesionalmente durante todos estos aos.
A todos mis profesores quienes tuvieron la labor de impartirme sus

conocimientos.
A todos mis compaeros de la UDO y amigos(as) con quienes compart

momentos muy gratos e inolvidables; Karla, Lucy, Henro, Flor, Silvia,
Yanniela, Florisbeth, Ma. Daniela, Ma. Emilia, Rosanyelis, Marivic, Luisana,
Ytza, Alex, Chopite, Cesar, Reinaldo, Ernesto, Carlos, Omarsito, Lenin,
Doennys, Pedro, gracias por todo su apoyo y cario incondicional.
A mis asesores la Ing. Nelsy Vvenes, Ing. Desiree Andrico y el Ing.

Antonio Villegas quienes fueron mi gua para la elaboracin de este humilde
trabajo.
A todos Mil gracias!
Zurilka A. Bolvar A.
vi
UNIVERSIDAD DE ORIENTE
NCLEO DE MONAGAS
PROGRAMA DE INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO
MATURN / MONAGAS / VENEZUELA
DESARROLLO DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE,
GESTIONE Y CONTROLE LAS REQUISICIONES DE LA EMPRESA
EXTERRAN VENEZUELA, C.A. MATURN ESTADO MONAGAS.
Autor: Zurilka A. Bolvar A.
C.I. 17.420.916
Asesor Acadmico: Ing. Desiree Andrico
Asesor Laboral: Ing. Antonio Villegas
Fecha: Agosto de 2010.
RESUMEN
La presente investigacin tuvo como finalidad el desarrollo de un Sistema
Automatizado que optimice, gestione y controle las requisiciones del departamento
de compras y logstica de la empresa Exterran Venezuela. Dicho sistema se realizo
bajo plataforma Windows utilizando la metodologa gil de desarrollo de software
XP, el lenguaje de programacin Visual Basic 6.0 concluyendo con un entorno que
permiti llevar un control eficiente del flujo de requisiciones que se genera en el
departamento. Mediante esta aplicacin se permiti crear requisiciones de todas y
cada una de las plantas en las que opera la empresa, donde los empleados pueden
acceder a realizar sus requisiciones de acuerdo a sus necesidades, por planta, por
prioridad, por status, llevando un mejor control de las partes que son despachadas y
de las partes que estn por despachar permitiendo hacerla de manera objetiva y
veraz.
Logrando as un mejor funcionamiento del proceso cumpliendo con todos los
requisitos establecidos por el cliente donde solo el administrador del sistema tiene el
acceso de poder modificar y eliminar requisiciones. El proyecto estuvo enmarcado
en el nivel de investigacin descriptiva y en un diseo de campo, ya que los datos
se obtuvieron de fuentes directas y con el contacto real del proceso llevado da a
da, de igual manera se usaron las tcnicas de entrevista no estructurada y la
observacin directa, siendo el proyecto factible, dicha poblacin es menor a 50
individuos por lo que se asume en estos casos que la poblacin es igual a la
muestra.
Descriptores: Windows, Software Libre, Extreme Programming (XP), Visual Basic
6.0, Access.
vii
INDICE GENERAL
DEDICATORIA
iii
AGRADECIMIENTOS
v
RESUMEN
vii
INDICE GENERAL
viii
INDICE DE FIGURAS
xiiii
INDICE DE TABLAS
xiv
INTRODUCCIN
1
CAPTULO I
4
CONTEXTO ORGANIZACIONAL
4
1.1 IDENTIFICACIN DE LA EMPRESA
4
1.1.1 Nombre de la Empresa:
4
1.1.2 Resea Histrica:
4
1.1.3 1990-2000: El comienzo de la Empresa lder en la compresin de
gas:
6
1.1.4 1990- 2000: La Fundacin:
7
1.1.5 1992-1997: Expansin y Modernizacin de la Produccin:
7
1.2 DESCRIPCIN DE LA EMPRESA
8
1.2.1 Finalidad de la Empresa
8
1.3 FILOSOFA DE LA EMPRESA
9
1.3.1 Misin
9
1.3.2 Visin
9
1.4 VALORES Y PRINCIPIOS OPERATIVOS
9
1.5 OBJETIVO DE LA EMPRESA
10
1.6 DIRECCIN:
12
1.7 ESTRUCTURA GERENCIAL DE LA EMPRESA EXTERRAN
VENEZUELA EDO MONAGAS
13
1.7.1 ORGANIGRAMA:
13
1.7.2 UBICACIN GEOGRFICA
14
CAPTULO II
15
EL PROBLEMA Y SUS GENERALIDADES
15
2.1 Planteamiento del Problema
15
2.2 Objetivos de la Investigacin
188
2.2.1 Objetivo General
188
2.2.2 Objetivos Especficos
19
2.3 Justificacin de la Investigacin
20
2.4 Alcance del Problema
211
2.5 Delimitacin del proyecto
22
CAPTULO III
23
MARCO REFERENCIAL
23
3.1 Antecedentes de la Investigacin
23
viii
3.2 Bases Tericas

28
3.2.1 Visin General de la Ingeniera de Software
28
3.2.1.1 Ingeniera de Software
28
3.2.1.2 Caractersticas de Software
28
3.2.1.3 Definicin de Ingeniera del Software
29
3.2.1.4 Situacin Actual de la Ingeniera de Software
30
3.2.1.5 Fases de la Ingeniera de Software
30
3.2.1.6 Ciclo de vida y Modelo de ciclo de vida
311
3.2.1.7 El proceso de desarrollo de software
32
3.2.1.8 Modelos de procesos de software
344
3.2.2 Mtodos de desarrollo de software
355
3.2.2.1 Metodologa
355
3.2.2.2 Definicin de mtodo de desarrollo de software
366
3.2.2.3 Metodologas estructuradas
366
3.2.2.4 Metodologas orientadas a objetos
377
3.2.2.5 Metodologas tradicionales (no giles)
377
3.2.2.6 Adaptacin del mtodo
388
3.2.3 Metodologas giles de desarrollo de software
388
3.2.3.1 The Agile Alliance - La gil Alianza
39
3.2.3.2 El Manifiesto gil
400
3.2.3.2.1 Principios del Manifiesto gil
411
3.2.3.3 Revisin de las principales metodologas giles
422
3.2.3.3.1 SCRUM
422
3.2.3.3.2 Crystal Methodologies
432
3.2.3.3.3 Feature-Driven Development (FDD)
444
3.2.4 Programacin Extrema XP - Extreme Programming
444
3.2.4.1 Los objetivos de XP
444
3.2.4.2 Las cuatro variables
454
3.2.4.3 Los cuatro valores
455
3.2.4.4 Las Actividades Bsicas de XP
466
3.2.4.5 Los Principios de XP
488
3.2.4.6 Las Prcticas en XP
48
3.2.4.7 Combinacin entre prcticas
511
3.2.4.8 El Proceso de XP Ciclo de Vida
522
3.2.4.9 Roles en XP
555
3.2.4.10 Historias de Usuario y dems artefactos XP
566
3.2.5 Elementos Esenciales en el Desarrollo de Sistemas de Informacin
600
3.2.5.1 Lenguaje de Programacin
611
3.2.5.2 Bases de datos
611
3.2.5.3 Sistema Gestor de Base de Datos (SGBD)
622
3.2.5.4 Sistemas de Control y Gestin
644
3.2.5.5 Control y Gestin de Requisiciones
655
ix
3.2.5.6 Sistemas para el Control y Gestin de Inventarios

3.2.5.7 Visual Basic 6.0
3.3 Bases Legales
3.4 Definicin de Trminos
CAPTULO IV
MARCO METODOLGICO
4.1 Tipo y Nivel de la Investigacin
4.2 Poblacin y Muestra
4.3 Tcnicas e Instrumentos de Recoleccin de Datos
4.3.1 Observacin directa:
4.3.2 Entrevista no estructurada:
4.3.3 Recopilacin documental a travs de la Web:
4.3.4 Libretas de anotaciones, diario de actividades y ordenadores:
4.3.5 Historias de Usuario:
4.4 Tcnicas de Anlisis de Datos:
4.5 Diseo Operativo
4.5.1 Fase I: Exploracin y Planificacin del proyecto
4.5.2 Fase II: Produccin y Diseo del proyecto
4.5.3 Fase III: Codificacin y Mantenimiento del proyecto
4.6 Cuadro Operativo
CAPTULO V
RESULTADOS
5.1 El Proyecto
5.1.2 Requerimientos del sistema
5.1.2.1 Requerimientos para la primera iteracin
5.1.2.2 Requerimientos para la segunda iteracin
5.1.2.3 Requerimientos para la tercera iteracin
5.1.2.4 Requerimientos para la cuarta iteracin
5.1.2.5 Requerimientos para la quinta iteracin
5.2 Herramientas utilizadas para el desarrollo del sistema
5.3 Planes de entregas
5.3.1 Plan de entrega para la primera iteracin
5.3.2 Plan de entrega para la segunda iteracin
5.3.3 Plan de entrega para la tercera iteracin
5.3.4 Plan de entrega para la cuarta iteracin
5.4 Fase II: Produccin y Diseo del proyecto
5.4.1 Tareas de Ingeniera
5.4.1.1 Tareas de Ingeniera de la primera iteracin
5.4.1.2 Tareas de Ingeniera de la segunda iteracin
5.4.1.3 Tareas de Ingeniera de la tercera iteracin
5.4.1.4 Tareas de Ingeniera de la cuarta iteracin
5.4.1.5 Tareas de Ingeniera de la quinta iteracin
x
678
69
700
733
800
800
802
822
833
833
844
844
855
855
866
87
88
89
900
900
922
922
922
922
96
97
98
99
100
100
101
103
103
104
105
106
107
107
107
108
109
111
111
5.5 Diseo de la base de datos

5.5.1 Mdulo Principal
5.5.2 Mdulo Usuarios
5.5.3 Mdulo Requirientes
5.5.4 Mdulo Planta
5.5.5 Mdulo Partes
5.5.6 Mdulo Requisiciones
5.6 Descripcin de la base de datos
5.7 Modelo de Casos de Uso del Sistema
5.8 Diseo y codificacin de interfaces
5.8.1 Interfaces de la primera iteracin
5.8.2 Interfaces de la segunda iteracin
5.8.3 Interfaces de la tercera iteracin
5.8.4 Interfaces de la Cuarta iteracin
5.8.5 Interfaces de la Quinta iteracin
5.9 Fase III: Codificacin y Mantenimiento del proyecto
6.1 Pruebas de aceptacin
6.1.1 Pruebas de aceptacin de la primera iteracin
6.1.2 Pruebas de aceptacin de la segunda iteracin
6.1.3 Pruebas de aceptacin de la tercera iteracin
6.1.4 Pruebas de aceptacin de la cuarta iteracin
6.1.5 Pruebas de aceptacin de la Quinta iteracin
6.2 Requisitos mnimos para instalacin y uso del sistema
6.3 Anlisis Costo Beneficio
6.3.1 Costos de desarrollo
6.3.2 Costos por depreciacin de equipos
6.3.3 Costos de operacin
6.3.4 Beneficios
CONCLUSIONES
RECOMENDACIONES
BIBLIOGRAFA
xi
112
112
112
113
113
114
114
117
124
128
128
131
132
135
142
144
144
144
145
146
147
148
148
149
149
151
152
154
156
158
159
INDICE DE FIGURAS
1. Organigrama gerencial de la empresa exterran Maturn EdoMonagas..

2. Ubicacin geogrfica de la empresa exterran en Venezuela.
13
14
3. Proceso de desarrollo de software..
32
4. Relacin entre elementos del proceso de software.
33
5. Modelo de desarrollo iterativo incremental....
35
6. Practicas se refuerzan entre s....
51
7. Ciclo de vida XP.
52
8. Diagrama de flujo del proceso de requisiciones actual...
95
9. Orden de mdulos con sus actividades.
115
10. Esquema relacional de la base de datos.
116
11. Tabla empleados.
117
12. Tabla clave
118
13. Tabla planta..
119
14. Tabla partes..
120
15. Tabla requisiciones.. 121

16. Tabla partes por despachar...
123
17. Diagrama de CU general del sistema de requisiciones. 124

18. Diagrama de CU del sistema - ingresar usuarios y/o requirientes...... 125
19. Diagrama de CU del sistema ingresar plantas y/o partes.
126
20. Diagrama de CU del sistema ingresar requisiciones.
127
21. Interfaz 1. Agregar nuevos requirientes...
128
22. Interfaz 2. Agregar nuevos requirientes...
129
xii
23. Interfaz 3. Agregar nuevos usuarios.
130
24. Interfaz 4. Agregar nuevos usuarios.
130
25. Interfaz 5. Acceder al sistema...
131
26. Interfaz 6. Carga de plantas..
131
27. Interfaz 7. Carga de partes....
132
28. Interfaz 8. Creacin de requisiciones...
134
29. Interfaz 9. Modificacin de PR O requisiciones.....
135
30. Interfaz 10. Partes por despachar.
137
137
138
138
139
139
140
141
141
39. Interfaz 19. Partes despachadas..
142
142
143
42. Interfaz 22. Salir del sistema.....
143
xiii
INDICE DE TABLAS
1. Modelo propuesto para una historia de usuario..
56
2. Modelo propuesto para una prueba de aceptacin
58
3. Modelo propuesto para una tarea de ingeniera.....
58
4. Modelo de tarjeta CRC
59
5. Cuadro operativo..
91
6. Historia de usuario Nro. 1...
97
97
98
98
10. Historia de usuario Nro. 5.....
99
100
12. Historia de usuario Nro. 7.
100
101
14. Plan de entrega primera iteracin...
104
15. Plan de entrega segunda iteracin.....
105
16. Plan de entrega tercera iteracin....
105
17. Plan de entrega cuarta iteracin..
106
18. Plan de entrega quinta iteracin..
106
19. Tarea de ingeniera Nro. 1
108
108
109
109
110
110
xiv
111
111
27. Descripcin de la tabla empleados.....
118
28. Descripcin de la tabla clave
119
29. Descripcin de la tabla planta..
120
30. Descripcin de la tabla partes..
121
31. Descripcin de la tabla requisicin..
122
32. Descripcin de la tabla partes por despachar...
123
33. DCU ingresar usuarios y/o requirientes.....
125
34. DCU ingresar plantas y/o partes.....
126
35. DCU ingresar requisiciones..
127
36. Caso de prueba de aceptacin Nro. 1
144
145
145
146
40. Caso de prueba de aceptacin Nro. 5......................
146
147
147
148
44. Requisitos mnimos para la instalacin y uso del sistema..
148
45. Costos del personal...
149
46. Costos de materiales y suministros....
150
47. Costos total de desarrollo.....
151
48. Costos por depreciacin de equipos..
151
49. Costo de operacin del nuevo sistema..
152
xv
50. Costo de operacin del sistema actual..
153
51. Comparacin de costos de operacin sistema actual Vs. Nuevo

sistema
154
52. Beneficios tangibles e intangibles...
155
xvi
INTRODUCCIN
En el transcurrir del tiempo la tecnologa ha tenido grandes avances
en el mundo empresarial brindando conocimientos de nuevas ramas y
herramientas que hacen posible su uso de manera rpida y fcil; agilizando
el trabajo diario y obteniendo a la vez excelentes resultados. Actualmente en
el mundo del negocio, donde surgen continuas mejoras en lo que a
capacidad de cambios, consulta y almacenamiento de datos se refiere; el
control de los procesos y la gestin de los mismos se ha convertido en una
de las herramientas fundamentales para que las empresas puedan obtener
productos, servicios y/o soluciones con una eficiencia relevante, que le
permitan el acceso al mundo competitivo de hoy en da, en el que
continuamente exigen mejores ndices de desempeo.
Los sistemas de informacin son herramientas desarrolladas con

propsitos diferentes dependiendo de las necesidades de la empresa, pero
siempre con el fin de poder lograr un excelente resultado mejorando las fallas
de las actividades, procesos, y servicios que son parte esencial de la vida
empresarial y del desarrollo de un pas.
De igual forma estos se caracterizan por dirigir en la mayora de los

casos en un 95% todos los datos, servicios y procesos que ofrece una
empresa realizando la respectiva transformacin, respaldo y recuperacin de
informacin, representando una fuente de apoyo que proporciona los
conocimientos bsicos para la realizacin de actividades en cualquier mbito,
donde interactan varios elementos como: equipo computacional, recurso
humano, fuente de informacin, programas implementados en el desarrollo
de la empresa, procedimientos y objetivos a fin.
En la actualidad son muchas las instituciones que acuden a
aplicaciones, o sistemas automatizados para la ejecucin de aquellas tareas
1
rutinarias para las cuales es necesario llevar un control preciso, y donde las
actividades de almacenamiento de informacin continuas y consultas
recurrentes son claves para la gestin de esas actividades. Las labores y
procesos relacionados con el control de requisiciones, necesitan cada vez
ms de este tipo de sistemas, dada la importancia a nivel operativo y de
costos relacionadas directamente con dichas tareas; aportando de esta forma
ventajas significativas en lo que a eficiencia, integridad y seguridad se refiere,
si se compara con labores de control no sistematizadas.
Lo antes expuesto, trae como consecuencia que constantemente se

estn desarrollando sistemas, permitindole a las diferentes organizaciones
obtener un producto que se adapte a las necesidades informticas de su
entorno, procesando tareas en forma automtica y generando respuestas en
corto tiempo. Aparece entonces la ingeniera del software como rama
primordial en la elaboracin de dicha tarea, la cual se puede apoyar en reglas
de desarrollo que se alejan del modelado estricto de requerimientos y se
enfocan ms en la satisfaccin del cliente y en la comunicacin de los
miembros desarrolladores, actividades propias de las metodologas giles de
desarrollo de sistemas y que estn definidas para lograr productos con altos
niveles de calidad.
Por todo esto, dentro del departamento de compras y logstica de la

Empresa Exterran, surge la necesidad de automatizar los procesos
relacionados con la creacin de requisiciones, utilizando la ingeniera del
software como base inicial para el desarrollo de la investigacin. La cual est
dividida en cinco (05) captulos que contemplan lo siguiente:
Captulo I (Contexto Organizacional), en el cual se hace referencia al

mbito en donde se desarroll esta investigacin, as como tambin su
misin, visin, creencias y valores.
Captulo II (Planteamiento del Problema), en el que se realiza el

planteamiento del problema, adems de sealar el objetivo general y los
objetivos especficos del estudio, la justificacin y el alcance del mismo.
Captulo III (Marco Referencial), en esta seccin se exponen los

antecedentes de los trabajos titulados, Metodologas giles en el desarrollo
de software, Diseo de una metodologa gil de desarrollo de software, Caso
prctico de la metodologa gil XP al desarrollo de software, entre otros; los
cuales presentarn relacin directa con el tema de trabajo. En este captulo
tambin se desarrollar las bases tericas, las bases legales y la definicin
de trminos.
Captulo IV (Marco Metodolgico), en l se desarrollar el tipo y nivel de

investigacin empleada, las tcnicas e instrumentos de recoleccin de datos,
las tcnicas de anlisis de dichos datos, adems de plantear el diseo
operativo.
El Captulo V (Resultados), es donde se muestran los resultados y

conclusiones obtenidas de la investigacin, as como su anlisis costo
beneficio.
Posteriormente se exponen las referencias bibliogrficas que sirvieron

como base para el desarrollo del proyecto, y los anexos relacionados
directamente con el trabajo realizado.
CAPTULO I
CONTEXTO ORGANIZACIONAL
El referido captulo describe todos aquellos aspectos relacionados con
la empresa tales como: su resea histrica, misin, visin, objetivos de la
organizacin y estructura gerencial de la Empresa Exterran Venezuela, C.A.
1.1 IDENTIFICACIN DE LA EMPRESA

1.1.1 Nombre de la Empresa:
EXTERRAN VENEZUELA C.A.
1.1.2 Resea Histrica:
Exterran, nace en el 2007, de la fusin de dos grandes empresas de

servicios energticos, como lo eran The Hanover Company y Universal
Compression, conformando as la empresa lder a nivel mundial en la
prestacin de servicios de compresin de gas natural, bajo la modalidad de
alquiler, con presencia en ms de treinta pases.
En Amrica del Norte, Exterran opera y mantiene los equipos de

compresin en cada uno de los principales productores de petrleo y gas,
incluyendo la regin del Golfo, oeste de Texas, las Montaas Rocallosas,
California, y Mid-Continent. En el hemisferio oriental, Exterran opera en
lugares de frica, Europa, Reino Unido, Rusia, Kazajstn, India, China,
Indonesia, Singapur y Australia.
En cuanto a servicios de Ingeniera y Manufactura Exterran tiene el
el diseo, la ingeniera y fabricacin de instalaciones estratgicamente

ubicadas en todo el mundo, incluyendo Houston y Columbus, Texas, Tulsa,
Oklahoma; el Reino Unido, Italia, y el Oriente Medio. En Amrica Latina,
Exterran opera en Argentina, Bolivia, Brasil, Colombia, Mxico, Trinidad y
Tobago, y Venezuela.
Actualmente, Exterran Venezuela, C.A., tiene una capacidad instalada

por encima de los 460 mil HP (caballos de fuerza) distribuidos en las 54
plantas compresoras en todo el pas. Luego de la fusin entre las dos
gigantes, se posiciona como el lder en compresin de gas natural a nivel
mundial, dejando atrs a sus ms cercanos competidores.
Las operaciones de Exterran Venezuela, C.A., se desarrollaron antes

de su creacin, por parte de Hanover Venezuela, C.A., desde hace 14 aos,
y se encuentran a lo ancho del territorio nacional en los Estados Anzotegui,
Apure, Barinas, Monagas, Delta Amacuro y Zulia. Desde su llegada al pas,
en el ao 1994, ha acrecentado la potencia de compresin instalada hasta
alcanzar valores cercanos a los 450.000 HP (Caballos de Fuerza), ms de
10% de la potencia total de Exterran TM., a escala mundial lo cual la
convierte en la primera empresa de compresin de gas en el pas, con una
ventaja que supera con creces la potencia instalada de los ms cercanos
competidores.
Durante estos aos de evolucin, adems, ha empezado a

incursionar con xito en el rea de los servicios de alquiler de generacin
elctrica; teniendo un crecimiento importante de participacin en este ltimo
sector. De la misma manera, el capital humano local, es el ms valioso
insumo de la organizacin, experimentando un aumento considerable desde
22 personas a mediados de los aos 90 hasta llegar a los de 542 empleados
en la actualidad. Es as como de alguna manera, ha cumplido con su misin

social.
Exterran cuenta actualmente con ms de 10.700 empleados a nivel

mundial, de los cuales 542 estn en Venezuela. Con presencia en ms de 30
pases, posee entre sus clientes a prestigiosas compaas como PDVSA,
Repsol YPF, Petrobras, Oxy, Pluspetrol, Tecpetrol, Camuzzi, Chevron,
Apache, Pan American Energy, entre otras. La empresa ofrece soluciones
energticas a travs de una amplia gama de productos y servicios. Se centra
en brindar una solucin total para la produccin de petrleo y gas.
Recientemente se realizo una importante reorganizacin donde

Latinoamrica quedo dividida en dos: Latinoamrica Norte (Venezuela,
Mxico, Colombia y Trinidad y Tobago) a cargo de Robert Price, con base en
Houston y Latinoamrica Sur (Argentina, Brasil y pases emergentes), bajo la
supervisin de Lus Otao. Estas personas dependen directamente de Joe
Kishkill.
Exterran es una empresa que participa en el mercado mundial de

servicios integrales para compresin de gas natural, suministrando servicios
de operacin, mantenimiento y equipos para la produccin, procesamiento y
transporte de petrleo y gas natural. La empresa opera en tres segmentos
bsicos de negocio: contratos de servicios, fabricacin y venta de equipos, y
servicios de post-venta.
1.1.3 1990-2000: El comienzo de la Empresa lder en la compresin

de gas:
HANOVER PGN Compressor, C.A., es una filial de "HANOVER
Compressor", que, conjuntamente con las siguientes empresas, forma parte
de la Corporacin Energtica "Trie Hanover Company", cuyos cuarteles

generales estn ubicados en Houston Texas, U.S.A
a. Hanover Smith, Production Equipment

b. Hanover Power Systems
c. Hanover Pumping Systems
d. Hanover Maintech
Hanover Compressor, con un poco ms de diez aos de fundada, se

ha convertido en el lder mundial en la prestacin de servicios de compresin
de gas natural, bajo la modalidad de alquiler, con presencia en mbitos tan
dismiles como, U.S.A., Canad, Mxico, Trinidad, Venezuela, Colombia,
Brasil, Bolivia, Argentina, Espaa, Italia, Rusia, Nigeria, China, Vietnam,
Indonesia, Tnez, Gran Bretaa, etc.
1.1.4 1990- 2000: La Fundacin:
Hanover PGN Compressor, C.A., en Venezuela fue fundada en la

ciudad de Maturn el 17 de julio de 1990, con el objeto de prestar servicio y
asesora relacionada con la compresin y manejo de gas natural, la misma
fabrica paquetes compresores, ubicndose entre los paquetalizadores de
compresin ms importantes del mundo.
Respecto a los equipos de
produccin de petrleo y gas se puede decir que es la segunda mayor

suplidora en el mercado mundial de productos como separadores,
calentadores y deshidratadores, adems mantiene un amplio inventario de
equipos reacondicionados como nuevos.
1.1.5 1992-1997: Expansin y Modernizacin de la Produccin:
Una vez decidido el cambio total de la antigua empresa HANOVER
por la gran unin entre las dos empresas de servicios, nace Exterran en el
2007, logrando as la modernizacin y expansin de la produccin,
colocandose en primer lugar como empresa lder, prestadora de servicios,
en la compresin de gas e incluso podemos decir que a partir de esta unin
se expande los clientes que nos permite abarcar diversas actividades en el
mercado bajo la modalidad de alquiler, con presencia en ms de treinta
pases.
Una empresa como Exterran a medida que se consolida en los

resultados obtenidos, madura hacia un plan de accin solid. Esto hace que
los aos venideros sean el plan y el corazn de todo, pues solo a travs del
excelente trabajo realizado se construye una base para nuevos proyectos y
se pueden vislumbrar nuevas posibilidades de cara al futuro.
1.2 DESCRIPCIN DE LA EMPRESA

1.2.1 Finalidad de la Empresa
La finalidad principal de la compaa, es la prestacin de servicios y

asesora relacionada con la compresin y manejo de gas natural, a fin de
facilitar los procesos de extraccin, orimulsin y refinacin de la industria
petrolera. En este sentido, mantiene contratos suscritos con empresas
nacionales y extranjeras dedicadas a las mencionadas actividades.
Exterran Venezuela, C.A. por pertenecer a un grupo de reconocida

trayectoria dentro del campo de la compresin para la industria petrolera,
mantiene una tecnologa de punta en sus plantas con el objeto de desarrollar
el proceso de compresin de gas natural en forma eficiente, lo cual le permite
liderar el mercado nacional y por ende cumplir con la visin establecida por
los responsables de la administracin estratgica de la compaa.
1.3 FILOSOFA DE LA EMPRESA
1.3.1 Misin
Prestar servicios y asesoras en el rea de compresin de gas natural

en Venezuela a travs de la constancia, profesionalismo, planificacin,
integridad del recurso humano y rentabilidad en la ejecucin de sus
operaciones.
1.3.2 Visin
Constituirse como la compaa que lidere el mercado de compresin de

gas en Venezuela, prestando atencin a las necesidades de calidad de los
clientes, apoyando la actuacin de su personal y respetando su entorno con
el fin de impulsar el desarrollo y crecimiento profesional, as como mantener
su rentabilidad financiera.
1.4 VALORES Y PRINCIPIOS OPERATIVOS

a. Compromiso.
b. nfasis en Seguridad Industrial.
c. nfasis en entrenamiento (optimizacin de recursos para el
incremento del margen de rentabilidad).
d. Honestidad.
e. Conocimiento.
f. Orientacin al cliente (ganar ganar).
g. Servicio de calidad.
h. Respeto.
i. Globalidad.
j. Integridad.
k. Enfoque al cliente.
l. Trabajo en equipo.
m. Responsabilidad.
n. Empoderamiento.
o. Balance del riesgo.
p. Comunicacin.
q. Excelencia.
1.5 OBJETIVO DE LA EMPRESA
La empresa Exterran Venezuela, tiene como objetivo primordial seguir

siendo la nmero uno en el mercado venezolano en la compresin de gas
natural y en el avance de otros servicios para el sector energtico.
De los cuales se derivan los siguientes objetivos especficos:

I.
Desarrollar un servicio de calidad y ofrecer a todos sus clientes

mejoras en la produccin, ampliando sus conocimientos a nivel
geogrfico y tecnolgico, incluyendo a todos los segmentos del mundo
del negocio incluyendo precios estndares para promover y mantener
un nivel optimo de competencia.
II.
Potenciar la participacin y el ingreso de nuevos clientes, promoviendo

la calidad de los servicios prestados a dichas organizaciones,
obteniendo buenos resultados en cada una de sus operaciones.
III.
Avanzar hacia el desarrollo de la tecnologa apoyando cada una de las

implantaciones de proyectos y programas; Exterran trabaja bajo la
licencia intranet de Windows realizando su acceso mediante los datos
de usuario y contrasea con que se accede a la red para visualizar la
informacin sobre la que se tiene autorizacin, impulsado hacia la
10
apropiada y correcta tecnologa por parte de los usuarios, empleados

y clientes promoviendo el crecimiento de la empresa.
IV.
Apoyar
la integracin Nacional
e Internacional de todos los
operadores y personal humano que se integre como recurso nuevo en

el desarrollo de la empresa, brindndole a cada uno de ellos los
conocimientos fundamentales de la operacin de las plantas; para
poder lograr de esta manera conciencia de la importancia de las
maniobras seguras y brindar la oportunidad de realizar practicas
constantes de los temas y mantenimientos ocasionados en los
equipos.
V.
Apoyar la seguridad y la defensa de todo el recurso humano que

opera en todas y cada una de las plantas por estado, proveyendo una
herramienta de comunicaciones seguras y de alcance mundial.
VI.
Crear la concepcin de mantener vigente su alta produccin en todos

los tiempos abriendo espacios para el correcto manejo de los activos y
capital de la empresa; ya que en momentos donde finalizan los
proyectos el reto seria buscar nuevas y novedosas propuestas que le
permitan a la empresa mantenerse estable en tiempos difciles.
VII.
Enaltecer los valores de la empresa enfocndose en la gestin del da

a da con iniciativas claras para que los resultados sean de hecho
positivos y de esa manera ni siquiera sea tan importante explicarlos.
lograr ser preactivos en lugar de reactivos, a travs de la unin de las
sedes principales el compromiso con la
empresa y su misin, la
orientacin al negocio, al servicio y al cliente; tener una alta

responsabilidad, poseer adems alto nivel de profesionalismo y
11
contribuir al desarrollo por medio de una poltica de responsabilidad

social comprometida.
VIII.
La certificacin de todos los cursos y entrenamientos que se realizan

intensamente en las locaciones de las distintas sedes de la empresa
aumenta el procedimiento de calidad en empresas como Exterran que
ofrecen bienes y servicios a un mercado determinado, representa en
cualquier circunstancia, un posicionamiento de carcter estratgico
con respecto al resto de competidores como as tambin un
compromiso asumido con las demandas de los clientes.
1.6 DIRECCIN:
Exterran se encuentra ubicada actualmente en la avenida Alirio Ugarte

Pelayo, Edificio Exterran. Urbanizacin Tipuro Caruno, Diagonal a PDVSA,
en la Ciudad de Maturn, Estado Monagas.
A continuacin se mostrara las figuras representativas de la estructura

organizacional de la empresa exterran y su ubicacin a nivel nacional.
12
1.7
ESTRUCTURA
GERENCIAL
DE
LA
EMPRESA
EXTERRAN
VENEZUELA EDO MONAGAS
1.7.1 ORGANIGRAMA:
Fuente: Empresa Exterran Venezuela
Figura 1. Organigrama gerencial de la empresa exterran, Maturn Edo

Monagas
13
1.7.2 UBICACIN GEOGRFICA

Fuente: Empresa Exterran Venezuela
Figura 2. Ubicacin geogrfica de la empresa exterran en Venezuela
14
CAPTULO II
EL PROBLEMA Y SUS GENERALIDADES
El siguiente captulo aborda el planteamiento del problema, objetivo
general y objetivos especficos, la justificacin de la investigacin, adems
del alcance y delimitacin del estudio.
2.1 Planteamiento del Problema
Los sistemas de informacin proporcionan la comunicacin y el poder

de anlisis que muchas empresas requieren para llevar a cabo el comercio y
administrar los negocios a una escala global. En trminos generales, stos
no son ms, que simplemente, un conjunto de elementos relacionados que
procesan la informacin, de forma que sta pueda ser usada para la toma de
decisiones acertadas.
Hoy en da las compaas orientadas hacia el control de los activos

necesitan excelentes beneficios, basndose principalmente en realizar sus
actividades de manera efectiva y con el menor uso de recursos econmicos y
humanos. Entre las
ventajas que ha proporcionado la tecnologa en el
mbito organizacional, se encuentran principalmente la automatizacin de

procesos, administracin de la informacin de un rea o departamento,
aumentos considerables en la produccin de servicios, entre otras. El uso de
estas tecnologas en una empresa permite gestionar procesos y servicios de
manera eficaz.
El mayor aporte de los sistemas de informacin es que han cambiado

la forma en que operan las organizaciones actuales en todo el mundo,
15
permitiendo a distintos niveles de la organizacin (estratgicos, gerenciales,

administrativos, operativo, entre otros), la modernizacin de muchos de los
procedimientos normales de operacin, maximizando las ventajas de la
computacin, haciendo ms eficiente los procesos de produccin y de
generacin de informacin valiosa para la toma de decisiones.
En cada nivel de la organizacin acta un sistema de informacin, que

se ha especializado para servir a las principales reas funcionales segn la
tarea que se realice, en muchos casos relacionados entre ellos; dentro de los
cuales se encuentran los sistemas para soporte ejecutivo, de informacin
administrativos, para tomas de decisiones, y de trabajo de conocimiento, por
mencionar algunos de los que son generalmente aceptados en diversas
clasificaciones.
Pero al tratarse de operaciones de rutina como las que se realizan al

gestionar las entradas y salidas de materiales de un almacn y la gestin de
toda una serie de reportes relacionados a dichas operaciones, es necesario
referirse a sistemas transaccionales, que funcionan al nivel operativo de la
organizacin, generando toda una serie de informacin clave para la
administracin de los almacenes e inventarios de la empresa.
En Venezuela Exterran es conocida como empresa lder en el proceso

de compresin de gas; presta servicios de operaciones de plantas, se
encuentra distribuida en 5 sedes brindando sus mejores tecnologas y
servicios de calidad en el proceso de operaciones y produccin; estando la
sede principal de la empresa Exterran Venezuela en Maturn Edo Monagas
ubicada en la Avenida Alirio Ugarte Pelayo Sector Tipuro Caruno, Diagonal a
PDVSA.
Esta empresa tiene como actividad principal el proceso de
requisiciones el cual es respuesta clave en la situacin econmica y en su
16
buen funcionamiento. Dicho proceso es el objeto de esta investigacin,

mediante el cual se lograr estudiar y determinar que el sistema actual est
ocasionando desgastes de tiempo y dinero en las actividades del
departamento y en consecuencia genera prdidas a la empresa.
Los factores que inciden sobre esta problemtica del proceso de

requisiciones son diversos, en primer lugar el sistema no est desarrollado,
se lleva a cabo de manera manual, por lo tanto la seguridad que proporciona
es muy baja, cuya principal caracterstica es el almacenamiento de datos en
carpetas ordenadas por plantas, ofreciendo servicios y procesos a pocos
usuarios. No existe un orden especfico de recibimiento de solicitudes, lo cual
es una de las principales causas de errores y fallas a la hora de ofrecer
reportes y resultados en un tiempo determinado, producto del gran nmero
de requisiciones que se realizan semanalmente de todas las plantas y de las
que en un futuro se espera incrementen.
En segundo lugar; el descontento por parte de la gerencia de la

empresa debido a la falta de control e informacin del proceso; trajo como
consecuencia la necesidad de un cambio en el sistema que permita llevar un
orden y cronograma desde el momento en que se realiza la requisicin hasta
el momento en que es entregada, ya que es aqu cuando ocurre retraso,
extravo, precisamente por no llevar un seguimiento completo a dichas
requisiciones, lo cual ocasiona errores en los resultados obtenidos por la
gerencia. Dentro del contexto se evaluar el proceso de requisiciones que
lleva actualmente el departamento el cual, por ser nico y manual, se hace
sujeto al acceso de un slo usuario a la vez, lo cual genera una dependencia
y limitacin para el desenvolvimiento del mismo.
As mismo dentro del estudio del sistema actual que es utilizado por
los empleados, se observaron los inconvenientes que presenta este
departamento al momento de realizar reportes de cuntas solicitudes se han
17
ejecutado semanal, mensual, anual y
toda aquella informacin que sea
exigida entre los parmetros necesitados por la gerencia, funciones que son
desempeadas con frecuencia de forma
manual, que comprende varios
pasos como generar orden de compra, solicitar aprobacin, generar solicitud

interna de compra, contactar a los proveedores enviando dichas solicitudes
por e mail o fax entre otros; lo que implica un esfuerzo y tiempo muy valioso
que puede ser aprovechado en otras labores.
De igual manera el tener que archivar carpetas tras carpetas

organizndolas por planta, ocasiona desgaste y perdida de informacin
aparte de ser un trabajo engorroso e interminable, por tal razn se
recomienda hacer un estudio del mismo para obtener resultados coherentes
y adaptables a la realidad. Este proceso de manipulacin de requisiciones es
una funcin delicada que deber contar con los mecanismos adecuados,
proporcionando as integridad y seguridad a su contenido que es lo
importante y necesario en la creacin del sistema.
Debido a las deficiencias y fallas antes mencionadas se decidir

desarrollar un sistema automatizado, el cual proporcionar mayor seguridad,
precisin, eficiencia y confiabilidad sobre la informacin manipulada. Sin
embargo, se debe permitir a los usuarios manejar eficazmente las
actividades del proceso de requisiciones; ya que stas son obligatorias para
el buen desarrollo de la compaa beneficiando todas sus reas y muy
directamente al departamento de compras y logstica.
2.2 Objetivos de la Investigacin
2.2.1 Objetivo General
18
Desarrollar un Sistema Automatizado de Requisiciones que optimice,

gestione y controle los procesos para el departamento de compras y logstica
de la empresa Exterran Venezuela, C.A. Maturn, Estado Monagas, con el
fin de ayudar a la toma de decisiones.
2.2.2 Objetivos Especficos
I.
Identificar la situacin problemtica del Departamento de compras y

logstica a travs del levantamiento de informacin directa e
indirectamente relacionada con todas las deficiencias y errores del
proceso manual existente.
II.
Determinar
cmo
fluye
la
informacin
entre
los
distintos
departamentos que forman parte de la empresa.

III.
Elaborar de acuerdo a su importancia el sistema automatizado acorde

con las actividades de gestin del departamento y sus necesidades
principales.
IV.
Disear un sistema automatizado que controle el proceso de

requisiciones para el buen funcionamiento del departamento.
V.
Construir el sistema automatizado, de manera ordenada por mdulos y

fases a travs de cdigos que sean entendibles y fciles de modificar
en un momento dado evitando incrementar costos y gastos
innecesarios.
VI.
Realizar pruebas en cada fase de culminacin del sistema para

verificar su correcto funcionamiento; lo cual es recomendable hacer
para su uso eficaz.
19
2.3 Justificacin de la Investigacin
El propsito de Desarrollar un Sistema Automatizado de Requisiciones

que optimice, gestione y controle el
proceso para el departamento de
compras y logstica, se justifica por el hecho de que a travs de este se podr

optimizar en forma significativa los procesos o transacciones relacionadas a
la gestin y el control de los materiales en el almacn del departamento, se
obtendr mejores beneficios para todo el personal que all labora
especialmente al departamento al cual estar asignado dicho sistema
haciendo uso de algunas herramientas que son necesarias para el buen
desenvolvimiento del programa en el tiempo estipulado. Como lo es en este
caso un lenguaje de programacin conocido como visual Basic 6.0 que se ha
diseado para facilitar el desarrollo de aplicaciones en un entorno Como
Windows 98, Windows XP o superior, cuya versin 6.0 soportan
caractersticas propias de los lenguajes orientados a objetos.
Para realizar el desarrollo del sistema, fue necesario aplicar las

diversas prcticas que plantea la metodologa XP (juego de la planificacin,
entregas pequeas, uso de metforas, pruebas, sencillez, programacin en
parejas, refactoreo, cliente en sitio, entre otras), as mismo, se utilizaron los
artefactos bsicos de desarrollo (historias de usuario, tareas de ingeniera y
pruebas de aceptacin), que dieron pie a un sistema automatizado para el
control y gestin de las requisiciones del departamento que funciona bajo
una plataforma de Windows, compilado en lenguaje libre Visual Basic
Access como sistema de gestin de la base de datos relacional.
Su desarrollo y posterior uso, facilitar la creacin, modificacin,

eliminacin y sobre todo el almacenamiento y consulta de los datos de
manera rpida, sencilla y segura para as limitar al mximo los posibles
errores, permitiendo ahorrar tiempo, costos, y lograr una mejor atencin y
20
nivel de desempeo dentro del departamento, aspectos que justifican por si

solos la importancia de la realizacin del proyecto.
Adems, por medio de la automatizacin de los procesos para la

gestin de requisiciones de materiales se evitar que los tiempos de
respuesta (en lo que a disponibilidad de requisiciones se refiere) afecten la
gestin del departamento, pues los mantenimientos urgentes de las plantas,
que constituyen los objetivos primordiales del departamento, sern realizados
en forma ms efectiva, es decir, con materia prima (materiales, herramientas
y equipos) siempre a la mano, cumpliendo con los tiempos establecidos por
el sector de operaciones y de esta manera mejorando significativamente los
ndices de desempeo de la empresa, en relacin al mantenimiento y
operacin de los equipos que se encuentran bajo su operatividad.
Indudablemente, lo anterior se traduce, en una serie de beneficios

tangibles y muy significativos, pues el sistema propuesto aportar mayor
facilidad a la hora de ejecutar las tareas del departamento relacionadas a la
realizacin de requisiciones, igualmente sern mnimos los errores y fallas
presentes en los reportes e informes correspondientes, dando adems mayor
eficiencia en la gestin de dichos documentos, generando mayor integridad
en la labores realizadas, incidiendo en forma positiva en la gestin general
del departamento.
2.4 Alcance del Problema
Primeramente se realiz un estudio para obtener un amplio

conocimiento no solo sobre la empresa y el rea de la misma en la cual se
desarrollo la investigacin (departamento de compras y logstica de la
empresa Exterran Venezuela); si no tambin, sobre el flujo de los procesos y
las actividades que se realizan para la gestin de requisiciones en dicha rea
21
de trabajo. Igualmente a travs de la consulta en diferentes fuentes

bibliogrficas y recursos de internet se estudiaron a profundidad los diversos
factores involucrados con la ingeniera de software, las metodologas giles
de desarrollo (sobre todo Extreme Programming), y el uso de administracin
de los recursos que cumpla en forma eficiente y efectiva con los
requerimientos existentes dentro del rea de trabajo, contribuyendo en
trminos generales a las labores que en el rea de trabajo se realizan y las
cuales constituyen los objetivos primordiales del departamento
2.5 Delimitacin del proyecto
El estudio se desarroll en el seno del Departamento de compras y

logstica de la empresa Exterran Venezuela, ubicada en la Avenida Alirio
Ugarte Pelayo Sector Tipuro Caruno, Diagonal a PDVSA., a la vez que se
desempean las funciones de usuario y analista de sistemas (Manager del
Proyecto y Tester), siguiendo las pautas metodolgicas impuestas por
Extreme Programming o XP, en el periodo comprendido entre el dos (02) de
Octubre de 2008 hasta el dos (02) de Abril de 2009. (02/10/2008
02/04/2009).
22
CAPTULO III
MARCO REFERENCIAL
En este captulo se muestran los conocimientos existentes relacionados
al tema de la investigacin, constituye la exposicin y anlisis de la teora o
grupo de teoras y leyes, que sirven como base para el desarrollo del
proyecto planteado; constituyendo as, una fuerte base de conocimientos, a
partir de la cual se derivan los planteamientos del investigador para el
Desarrollo de un Sistema automatizado que optimice, gestione y controle las
requisiciones de la Empresa Exterran Venezuela, C.A. Maturn Edo
Monagas.
3.1 Antecedentes de la Investigacin
Los antecedentes de la investigacin consisten en una revisin de

documentos contentivos de estudios que directa o indirectamente estn
relacionados con el problema de la investigacin planteada. Por tal motivo, a
continuacin se presenta una recopilacin de los antecedentes que se
pudieron obtener para documentar el estudio que se desarrolla, analizando
para ello el contexto internacional, nacional y regional; evitando as la
duplicacin de esfuerzos, en el caso de contar con los aportes de
investigaciones previamente realizadas.
Esta es la filosofa de las metodologas giles, las cuales dan mayor

valor al individuo, a la colaboracin con el cliente y al desarrollo incremental
del software con iteraciones muy cortas. Este enfoque est demostrando su
efectividad en proyectos con requisitos muy cambiantes y cuando se exige
23
reducir drsticamente los tiempos de desarrollo, pero manteniendo una alta

calidad, razn por la cual, las metodologas giles estn revolucionando la
manera de producir software.
Echeverry, L y Delgado, L. (2007), para la Universidad Tecnolgica de

Pereira, en la ciudad de Pereira, Colombia, titulado Caso prctico de la
metodologa gil XP al desarrollo de software, en el cual se plante realizar
una experiencia real en la aplicacin de XP al desarrollo de software con el fin
de determinar, para unas circunstancias especficas, que tan bien se ajustaba la
metodologa.
En este estudio, el autor demuestra que tal problemtica se sufre

cotidianamente en las empresas de desarrollo de software que necesitan
estimar esfuerzo con pocos datos; es decir, tomando distancia de los conceptos
acadmicos de estimacin de esfuerzo, la realidad de las organizaciones de
desarrollo de software implica que ante la necesidad de los clientes, slo se
cuenta con una o dos reuniones para tomar conocimiento y comprender la
problemtica.
El aporte de este estudio consiste en que actualmente es un desafo

constante para las empresas de desarrollo de software convertirse en una
entidad seria que logre la confianza de sus clientes, donde para ellos el objetivo
de cumplir con los plazos establecidos, comprende las necesidades de los
clientes y ser prudentes en identificar sus propios lmites se convierte en una de
las principales herramientas competitivas y factor de diferenciacin de la
competencia.
De igual manera permite dar a conocer a la metodologa Extreme

Programming (XP), desarrollada por Kent Beck (1996), como la principal
metodologa gil de desarrollo de software, a las cuales se incorporaron
24
muchas, conformando el universo de las mismas. De este modo, dado el

nfasis de tales metodologas en cuestiones de Peopleware, Dinmica de
Equipos, Psicologa Social y Calidad del Proceso, el tema fue elegido como
base para la construccin de una metodologa que analizara estos aspectos,
basndose en las mejores prcticas de la industria e incorporando aspectos
interdisciplinarios tomados de la Psicologa, la Sociologa, las Relaciones de
Trabajo y la Administracin.
Mrquez, L. (2006), en su Trabajo de Grado para la Facultad de Ciencias

de la Universidad Central de Venezuela, en la ciudad de Caracas, Distrito
Capital, titulada Rediseo y automatizacin de los flujos operacionales del
rea de logstica y coordinacin de transporte de una empresa basado en
Tecnologa Web, el cual se bas en el anlisis del flujo operacional de la
empresa de Distribucin Transporte SV en todas sus etapas, para desarrollar e
implementar un sistema que gestione el flujo operacional que se lleva a cabo
entre el mdulo de Operaciones y Logstica y el mdulo de Coordinacin de
Transporte y Almacn SV, bajo un ambiente integrado en Tecnologa Web;
garantizando el control, la coordinacin y desarrollo ptimo del flujo operacional
y que al mismo tiempo pueda ser lo suficientemente flexible para integrarse a
las etapas del flujo operacional.
El desarrollo de este sistema estuvo alineado con los planes, objetivos,

relaciones y el flujo de operaciones de Transporte SV y de los diferentes
clientes a los que se les presta servicios, tratando de aprovechar al mximo
posible la base instalada de Tecnologa de Informacin, tomando en
consideracin las tendencias en TI y las mejores prcticas en materia de
distribucin y almacenaje. De igual manera, estuvo guiado por la metodologa
de desarrollo denominada Programacin Extrema (XP- Extreme Programming),
la cual se basa en la simplicidad, la comunicacin y el reciclado continuo de
25
cdigo y cuyo principal objetivo es la satisfaccin del cliente y potenciar al

mximo el trabajo en grupo.
El principal aporte de este estudio con la implantacin de este sistema, es

contar con una aplicacin automatizada que permita a cada uno de los usuarios
pertenecientes a cada rea, administrar y controlar bajo un ambiente Windows
la generacin de nuevas requisiciones, la aprobacin y rechazo de las mismas,
tiempos de evaluacin, retrasos en respuestas y la canalizacin de las
solicitudes basadas en el flujo de operaciones de las plantas, garantizando el
cumplimiento de los procesos definidos en cada una de las etapas del flujo
operacional; permitiendo as la ejecucin correcta, ptima e integrada de los
procesos.
Garantn, S. (2008). Sistema para el control y gestin de materiales en el

almacn del Departamento de Mantenimiento y Operacin de telfonos pblicos
de la Cantv del Estado Monagas. Trabajo de Grado de Ingeniera de Sistemas.
Universidad de Oriente Ncleo de Monagas.
Este trabajo se realiz con el fin de automatizar los procesos llevados a

cabo en uno de los departamentos de la organizacin, se plantea como
alternativa el diseo y elaboracin de un sistema computarizado para el control
de almacn e inventario que sea capaz de mejorar y agilizar todos los procesos
referentes a la gestin y el control de los materiales en el almacn o deposito
dentro del departamento de mantenimiento y operacin de telfonos pblicos de
la CANTV Monagas. Contribuyendo as en forma directa con los objetivos
primordiales del departamento en lo que a mantenimiento predictivo y correctivo
de la planta se refiere, incluyendo manejo de personal, entrada y salida de
materiales, entre otros. Sirvi como base fundamental en el estudio de la
metodologa XP en el desarrollo de sistemas de informacin.
26
Rodrguez, P. (2009). Desarrollo de una aplicacin web para el control de

gestin de declaraciones sucesorales que permita optimizar procesos y tiempos
de respuesta al rea de sucesiones del SENIAT Sector Maturn. Trabajo de
Grado de Ingeniera de Sistemas. Universidad de Oriente Ncleo de
Monagas.
La finalidad del proyecto fue desarrollar un sistema de informacin

basado en tecnologa web para el control del proceso principal llevado a cabo
en el rea de sucesiones de la organizacin ya mencionada. El aporte brindado
por el mismo en esta investigacin radica en el uso de la Metodologa XP como
patrn para el desarrollo del sistema, facilitando as la comprensin de sus
tcnicas y herramientas. Adems, es necesario destacar que se llev a cabo en
la misma institucin donde se realiz la presente investigacin, lo cual facilita y
colabora en el estudio del entorno.
Del mismo modo, el aporte que ofrece este estudio se refleja en que
permite dar a conocer a la metodologa Extreme Programming (XP),
desarrollada por Kent Beck (1996), como la principal metodologa gil de
desarrollo de software, a las cuales se incorporaron muchas, conformando el
universo de las mismas. De este modo, dado el nfasis de tales metodologas
en cuestiones de Peopleware, Dinmica de Equipos, Psicologa Social y
Calidad del Proceso, el tema fue elegido como base para la construccin de
una metodologa que analizara estos aspectos, basndose en las mejores
prcticas de la industria e incorporando aspectos interdisciplinarios tomados de
la Psicologa, la Sociologa, las Relaciones de Trabajo y la Administracin.
Los
antecedentes
anteriormente
reseados
no
presentan
en
su
generalidad el tipo de estudio o conclusiones concretas. Sin embargo, los

mismos son considerados como un recurso valioso a efectos del desarrollo de
27
esta investigacin; y por lo tanto, se consideran vlidos para documentar la

misma por parte del autor.
3.2 Bases Tericas
Las Bases Tericas tienen la finalidad de establecer las pautas especficas

hacia donde se dirigir la investigacin a presentar, de forma tal que se puedan
estudiar con mayor precisin las variables que intervienen en el desarrollo del
proyecto planteado.
3.2.1 Visin General de la Ingeniera de Software
3.2.1.1 Ingeniera de Software
Debido al alcance del proyecto, es significativa la importancia que tiene el

concepto Ingeniera del Software ya que este define mtodos que satisfacen
las definiciones formales en el desarrollo de un producto e integra paradigmas
de programacin que dan el soporte a las metodologas agiles para el desarrollo
de software.
3.2.1.2 Caractersticas de Software
Echeverry, L y Delgado, L. (2007) nos mencionan las siguientes

caractersticas del software:
a) Es de carcter lgico en vez de fsico. Es un intangible.
b) Se desarrolla, no se fabrica. Lo cual implica que es susceptible de

modificarse de acuerdo a las necesidades.
c) Se deteriora. Entre otras causas, debido al desgaste del hardware y
28
a la acumulacin de errores a medida que se introducen cambios durante

su vida til.
d) Se desarrolla a medida que la organizacin lo necesite.
3.2.1.3 Definicin de Ingeniera del Software
Es el establecimiento y uso de principios robustos de la ingeniera a fin de

obtener econmicamente software que sea fiable y que funcione eficientemente
sobre mquinas reales. (Anaya y Plaza, 2007, p. 30).
La ingeniera del software proporciona un marco de trabajo, mtodos,

tcnicas y herramientas para construir software de mayor calidad. Trmino que
aparece en 1968.
Segn estas definiciones y paralelo a cualquier metodologa utilizada en el

desarrollo de aplicaciones se sigue a este concepto como la estrategia para
desarrollar software que sea til al cliente, que se pueda transferir de un
entorno de operacin a otro (Portable), que soporte ajustes y adaptaciones con
costos manejables (Mantenible), que presente baja tasa de fallos (Confiable),
que brinde resultados correctos con alto grado de exactitud (Integro), que no
consuma demasiados recursos (Eficiente), que sea accesible al usuario y que
sea fcil de aprender y de utilizar. Es as como la ingeniera del software
proporciona las estrategias y mtodos a utilizar en cada uno de los diferentes
proyectos de software.
Segn la IEEE la Ingeniera del software representa la aplicacin de un
enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y
mantenimiento del software; es decir, la aplicacin de ingeniera al software.
(Letelier, 2002, p. 2).
29
3.2.1.4 Situacin Actual de la Ingeniera de Software
Actualmente al referirse a ingeniera del software se percibe o asimila el

concepto con programacin orientada a objetos, se tiende en primera instancia
a pensar en proceso unificado como metodologa de desarrollo y en gestin(de
alguna manera) de la calidad del software. Pero quiz la respuesta que
realmente abarca la situacin actual de la ingeniera del software es que se ha
establecido UML (Lenguaje Unificado de Modelado) como una notacin
estndar de anlisis y diseo.
Aparecen tambin Mtodos Agiles como Extreme Programming, Scrum,

Crystal, etc.; como necesidad al desarrollo gil y funcional. Algunas
universidades han comenzado a ofrecer el ttulo en ingeniera del software y se
han creado comits como CSAB (Computer Science Accreditation Board) y
ABET (Accreditation Board for Engineering and Technology). El CMM
(Capability Maturity Model) del SEI (Software Engineering Institute) y la familia
de estndares ISO 9000 son usados para valorar la capacidad de una
organizacin de ingeniera del software.
3.2.1.5 Fases de la Ingeniera de Software
El trabajo que se asocia a la ingeniera del software se puede dividir en

tres fases genricas, con independencia del rea de aplicacin, tamao o
complejidad del proyecto:
a) Fase de definicin
Esta fase se centra sobre el qu. Es decir, durante la definicin, el que

desarrolla el software intenta identificar qu informacin ha de ser procesada,
qu funcin y rendimiento se desea, qu comportamiento del sistema, qu
interfaces van a ser establecidas, qu restricciones de diseo existen, y qu
30
criterios de validacin se necesitan para definir un sistema correcto. Por tanto,

han de identificarse los requisitos clave del sistema y del software.
b) Fase de desarrollo
Se centra en el cmo. Es decir, durante el desarrollo un ingeniero del

software intenta definir cmo han de disearse las estructuras de datos, cmo
ha de implementarse la funcin dentro de una arquitectura de software, cmo
han
de
implementarse
los
detalles
procedimentales,
cmo
han
de
caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de

programacin (o lenguaje no procedimental) y cmo ha de realizarse la prueba.
c) Fase de mantenimiento
Se centra en el cambio que va asociado a la correccin de errores, a las

adaptaciones requeridas a medida que evoluciona el entorno del software y a
cambios debidos a las mejoras producidas por los requisitos cambiantes del
cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de
cambios: correccin, adaptacin,
mejora y prevencin. Adems de estas
actividades de mantenimiento, los usuarios de software requieren un

mantenimiento continuo. Los asistentes tcnicos a distancia, telfonos de ayuda
y sitios web de aplicaciones especficas se implementan frecuentemente como
parte de la fase de mantenimiento. (Pressman, 2002, pp. 15-16).
3.2.1.6 Ciclo de vida y Modelo de ciclo de vida

Segn la norma 1074 IEEE se define al ciclo de vida del software como
una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la
explotacin y el mantenimiento del software y la norma ISO 12207 define como
modelo de ciclo de vida al marco de referencia, que contiene los procesos, las
actividades y las tareas involucradas en el desarrollo, la explotacin y el
31
mantenimiento de un producto de software, abarcando la vida del sistema

desde la definicin de requisitos hasta la finalizacin de su uso. Ambas
consideran una actividad como un subconjunto de tareas y una tarea como una
accin que transforma las entradas en salidas (Normas ISO. ISO 9000-3).
3.2.1.7 El proceso de desarrollo de software
Un proceso de desarrollo de software tiene como propsito la produccin

eficaz y eficiente de un producto software que rena los requisitos del cliente.
Dicho proceso, en trminos globales se muestra en la Figura 2 (Jacaboson y
otros, 2000). Este proceso es intensamente intelectual, afectado por la
creatividad y juicio de las personas involucradas (Sommerville, 2002). Aunque
un proyecto de desarrollo de software es equiparable en muchos aspectos a
cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie
de desafos adicionales, relativos esencialmente a la naturaleza del producto
obtenido. En la Figura 3, se muestra el proceso de desarrollo de software.
Fuente: Jacaboson y otros (2000)
Requisitos nuevos
o modificados
Proceso de Desarrollo
de Software
Sistema nuevo
o modificado
Figura 3: Proceso de desarrollo de software
Es importante sealar que el proceso de desarrollo de software no es

nico. No existe un proceso de software universal que sea efectivo para todos
los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil
automatizar todo un proceso de desarrollo de software.
32
A pesar de la variedad de propuestas de proceso de software, existe un

conjunto de actividades fundamentales que se encuentran presentes en todos
ellos (Sommerville, 2002):
a) Especificacin de software: Se debe definir la funcionalidad y

restricciones operacionales que debe cumplir el software.
b) Diseo e Implementacin: Se disea y construye el software de

acuerdo a la especificacin.
c) Validacin: El software debe validarse, para asegurar que cumpla con

lo que quiere el cliente.
d) Evolucin: El software debe evolucionar, para adaptarse a las

necesidades del cliente.
Otra perspectiva utilizada para determinar los elementos del proceso de

desarrollo de software es "establecer las relaciones entre elementos que
permitan responder Quin debe hacer Qu, Cundo y Cmo debe hacerlo
(Letelier, 2003, p. 4).
En la Figura 4 se muestran los elementos de un proceso de desarrollo de

software y sus relaciones:
Fuente: Letelier (2002), p.4
Figura 4: Relacin entre elementos del proceso de software
33
As las interrogantes antes planteadas, se responden partiendo de la

figura anterior de la siguiente forma:
Quin: Las Personas participantes en el proyecto de desarrollo

desempeando uno o ms Roles especficos.
Qu: Un Artefacto es producido por un Rol en una de sus Actividades. Los
Artefactos se especifican utilizando Notaciones especficas. Las Herramientas
apoyan la elaboracin de Artefactos soportando ciertas Notaciones.
Cmo y Cundo: Las Actividades son una serie de pasos que lleva a
cabo un Rol durante el proceso de desarrollo. El avance del proyecto est
controlado mediante hitos que establecen un determinado estado de
terminacin de ciertos Artefactos.
3.2.1.8 Modelos de procesos de software
Los modelos son simplemente una descripcin de un proceso de software

que se presenta desde una perspectiva particular. Es una abstraccin de un
proceso real e incluye actividades (que son parte de los procesos del software),
los productos software, y el papel de las personas interesadas en el desarrollo.
Existe una gran variedad de modelos diferentes genricos o paradigmas de
desarrollo de software, y son los modelos Incremental y Prototipado los que
constituyen la base fundamental para las Metodologas Agiles de desarrollo de
software.
El modelo incremental nace con la idea de evitar repetir el trabajo en las

tareas de desarrollo, y tomar decisiones sobre requisitos cuando exista mayor
experiencia con el sistema; cada secuencia produce un incremento del
software y con cada incremento, se entrega un producto totalmente operacional
(diferente del prototipado evolutivo). En si, el modelo incremental, es una
34
combinacin del Modelo de Cascada y Modelo Evolutivo. La figura 4 muestra el

modelo del desarrollo incremental.
Fuente: Goncalves (2005), p.13
Figura 5: Modelo de desarrollo iterativo incremental
El modelo Prototipo, tal cual indica su nombre, se basa en prototipos que

representan la primera versin de un nuevo tipo de producto en el que se han
incorporado slo algunas caractersticas del sistema final o no se han realizado
completamente. Se basa principalmente en presentar al cliente un prototipo
para su experimentacin, este prototipo ayuda al cliente a establecer
claramente los requisitos y ayuda a los desarrolladores a: validar correcciones
de la especificacin, a aprender sobre problemas que se presentaron durante el
diseo e implementacin del sistema, a mejorar el producto, y a examinar la
viabilidad y la utilidad de la aplicacin.
3.2.2 Mtodos de desarrollo de software
3.2.2.1 Metodologa
Proporciona un modo de abordar el desarrollo del software y un conjunto

de pasos y procedimientos que deben seguirse en su ciclo de vida, manifiesta el
cmo se debe dividir un proyecto en etapas, describe las tareas que se llevan a
35
cabo en cada etapa, las salidas que se producen y cundo se deben producir,
adems, describe las restricciones que se aplican, las herramientas que se
utilizan y la forma como se gestiona y controla un proyecto.
Escalona, define metodologa como un conjunto de filosofas, etapas,
procedimientos, reglas, tcnicas, herramientas, documentacin y aspectos de
formacin para los desarrolladores de sistemas de informacin. (Escalona,
2001, p. 71).
Por lo que fcilmente, se puede llegar a dar una definicin de metodologa

de desarrollo, como ese conjunto de procedimientos, tcnicas, herramientas, y
un soporte documental que ayuda a los desarrolladores a realizar nuevo
software o sistema.
3.2.2.2 Definicin de mtodo de desarrollo de software

Conjunto de procedimientos (fases y sub-fases, actividades y tareas; que
dan lugar a productos), tcnicas (grficas y textuales), herramientas (Rational
Rose, StarUML) y soporte documental que ayuda a los desarrolladores a
producir nuevo software (Schenone, 2004, p. 16).
3.2.2.3 Metodologas estructuradas

Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s
con la Programacin Estructurada, luego a mediados de los 70s aparecieron
tcnicas para el Diseo (por ejemplo: el diagrama de Estructura) primero y
posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos).
Estas metodologas son particularmente apropiadas en proyectos que utilizan
para la implementacin lenguajes de 3ra y 4ta generacin.
36
Ejemplos de metodologas estructuradas de mbito gubernamental:

MERISE (Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de
propuestas de mtodos estructurados en el mbito acadmico: Gane & Sarson,
Ward & Mellor, Yourdon & DeMarco e Information Engineering.
3.2.2.4 Metodologas orientadas a objetos
Su historia va unida a la evolucin de los lenguajes de programacin

orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines
de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en
1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a
consolidarse algunos mtodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la

ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que
posteriormente se reorienta a un objetivo ms modesto, para dar lugar al
Unified Modeling Lenguage (UML) la notacin OO ms popular en la actualidad.
Algunos mtodos OO con notaciones predecesoras de UML son: OOAD

(Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT
(Rumbaugh). Algunas metodologas orientadas a objetos que utilizan la
notacin UML son: Rational Unified Process (RUP), OPEN, MTRICA (que
tambin soporta la notacin estructurada). La descripcin de cada una de ests
metodologas puede consultarse a travs de la web en sus pginas oficiales,
referidas en la bibliografa de este trabajo.
3.2.2.5 Metodologas tradicionales (no giles)

Las metodologas no giles son aquellas que estn guiadas por una fuerte
planificacin durante todo el proceso de desarrollo; llamadas tambin
37
metodologas tradicionales o clsicas, donde se realiza una intensa etapa de

anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse

como metodologas tradicionales. Aunque en el caso particular de RUP, por el
especial nfasis que presenta en cuanto a su adaptacin a las condiciones del
proyecto (mediante su configuracin previa a aplicarse), realizando una
configuracin adecuada, podra considerarse gil.
3.2.2.6 Adaptacin del mtodo

No existe un mtodo universal o ideal a seguir en el proceso de
desarrollo de un producto software, en efecto, cantidad de mtodos diferentes
tienen distintas reas donde son aplicables. sta seleccin de un mtodo para
el desarrollo depende y est condicionado por el tamao, polticas y estructura
de la organizacin desarrolladora, por el tipo y/o complejidad de las
aplicaciones a desarrollar, por la experiencia requerida y por los recursos
disponibles.
Tambin se puede decir que no es razonable pensar que dos

organizaciones o grupo de desarrollo utilicen la misma metodologa sin realizar
cambios sobre ella, lo cual hace que dichos entes adapten a sus metodologas
su propio estilo profesional para el desarrollo de un producto, segn sus propias
herramientas, conocimientos, recursos y necesidades.
3.2.3 Metodologas giles de desarrollo de software

A principios de la dcada del 90, surgi un enfoque que fue bastante
revolucionario para su momento ya que iba en contra de la creencia de que
38
mediante procesos altamente definidos se iba a lograr obtener software en

tiempo, costo y con la requerida calidad.
Surgen cuando las metodologas tradicionales ms especficamente los

procesos en cascada decaen por descredito ya que prevaleca la crisis de
confianza en tantos procesos rgidos de metodologas prescriptivas con anlisis
completo de requerimientos y planificacin detallada.
En ste nuevo tipo de metodologa, se valoran los individuos y la

interaccin por encima de los procesos y herramientas, el software que funciona
mas que la documentacin abarcadora, la colaboracin con el cliente por
encima de la negociacin contractual, la respuesta al cambio por encima de un
seguimiento a un plan, adems sealan que aunque halla valor en los
elementos de la derecha se valoran mas los de la izquierda.
Entre las metodologas giles ms destacadas hasta el momento

podemos nombrar: XP - Extreme Programming, Scrum, Crystal Clear, DSDM Dynamic
Systems
Developmemt
Method,
ASD
Adaptive
Software
Development, FDD - Feature Driven Development, LD - Lean Development,

XBreed, Extreme Modeling.
3.2.3.1 The Agile Alliance - La gil Alianza

En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el
trmino gil, aplicado al desarrollo de software. El objetivo fue esbozar los
valores y principios que deberan permitir a los equipos desarrollar software
rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas.
39
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo
de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil
de software y ayudar a las organizaciones para que adopten dichos conceptos.
El punto de partida fue el Manifiesto gil, un documento que resume la filosofa
gil (Cans, Letelier, y Penads, 2007, p. 2).
3.2.3.2 El Manifiesto gil
El Manifiesto comienza enumerando los principales valores del desarrollo

gil. Segn Echeverry y Delgado (2007, p. 28) en el se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. Es ms importante construir un buen equipo que
construir el entorno, es mejor crear el equipo y que ste configure su propio
entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena

documentacin. La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisin importante
(Manifiesto gil), los dos elementos fundamentales son: el propio cdigo y la
interaccin con el equipo.
La colaboracin con el cliente ms que la negociacin de un contrato. Se

propone que exista una interaccin constante entre el cliente y el equipo de
desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del
proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La

planificacin no debe ser estricta puesto que hay muchas variables en juego,
debe ser flexible para poder adaptarse a los cambios que puedan surgir.
40
3.2.3.2.1 Principios del Manifiesto gil
Los valores anteriores inspiran los doce principios del manifiesto. Estos
principios son las caractersticas que diferencian un proceso gil de uno
tradicional. Los dos primeros son generales y resumen gran parte del espritu
gil. Son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.
Luego existen una serie de principios que tienen que ver con el proceso de
desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo posible entre
entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno
y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo.
VII.
El software que funciona es la medida principal de progreso.
41
VIII. Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de mantener una
paz constante.
Finalmente los ltimos principios estn ms directamente relacionados con

el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la

agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a

ser ms efectivo, y segn esto ajusta su comportamiento.
3.2.3.3 Revisin de las principales metodologas giles
Aunque los creadores e impulsores de las metodologas giles ms

populares han suscrito el manifiesto gil y coinciden con los principios
enunciados anteriormente, cada metodologa tiene caractersticas propias y
hace hincapi en algunos aspectos ms especficos.
A continuacin se resumen dichas metodologas giles, dejando el anlisis

ms detallado de XP para la siguiente seccin, al ser sta la metodologa
seleccionada para el desarrollo del proyecto de pasanta.
3.2.3.3.1 SCRUM
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un
42
marco para la gestin de proyectos, que se ha utilizado con xito durante los
ltimos 10 aos. Est especialmente indicada para proyectos con un rpido
cambio de requisitos. Sus principales caractersticas se pueden resumir en dos:
el desarrollo de software se realiza mediante iteraciones, denominadas sprints,
con una duracin de 30 das y el resultado de cada sprint es un incremento
ejecutable que se muestra al cliente. La segunda caracterstica importante son
las reuniones a lo largo proyecto. stas son las verdaderas protagonistas,
especialmente la reunin diaria de 15 minutos del equipo de desarrollo para
coordinacin e integracin.
Su principal obra es de Schwaber K., Beedle M., Martin R.C. Agile
Software
Development
with
SCRUM.
Prentice
Hall.
(2001);
www.controlchaos.com su pgina oficial.
3.2.3.3.2 Crystal Methodologies
Metodologas caracterizadas por estar centradas en las personas que

componen el equipo (de ellas depende el xito del proyecto) y la reduccin al
mximo del nmero de artefactos producidos. Han sido desarrolladas por
Alistair Cockburn. El desarrollo de software se considera un juego cooperativo
de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de
desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar
sus habilidades y destrezas, as como tener polticas de trabajo en equipo
definidas.
Estas polticas dependern del tamao del equipo, establecindose una

clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal
Orange (25 a 50 miembros).
43
Su principal obra es de Cockbun, A. Agile Software Development.

Addison-Wesley.(2001); su pgina oficial es: www.crystalmethodologies.org.
3.2.3.3.3 Feature-Driven Development (FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones son

cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin
del sistema partiendo de una lista de caractersticas que debe reunir el
software. Sus impulsores son Jeff De Luca y Peter Coad; creadores junto con
Lefebvre E., de Java Modeling In Color With UML: Enterprise Components and
Process.
Prentice
Hall
.(1999).
Su
pgina
Oficial
es:
www.featuredrivendevelopment.com.
3.2.4 Programacin Extrema XP - Extreme Programming
Partiendo de las diversas afirmaciones de Kent Beck en su obra Extreme

Programming Explained. Embrace Change (2004), XP es una metodologa gil
centrada en potenciar las relaciones interpersonales como clave para el xito en
desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.
XP se basa en realimentacin continua entre el cliente y el equipo de

desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define
como especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo tcnico.
3.2.4.1 Los objetivos de XP

Segn Calero (2003, p.2), los objetivos de XP son muy simples; primero
que nada busca la satisfaccin del cliente. Esta metodologa trata de dar al
44
cliente el software que l necesita y cuando lo necesita. Por tanto, debemos

responder muy rpido a las necesidades del cliente, incluso cuando los cambios
sean al final de ciclo de la programacin.
El segundo objetivo es potenciar al mximo el trabajo en grupo. Tanto

los jefes de proyecto, los clientes y desarrolladores, son parte del
equipo y estn involucrados en el desarrollo del software.
3.2.4.2 Las cuatro variables
XP define cuatro variables para proyectos de software: coste, tiempo,

calidad y mbito. De estas cuatro variables, Beck (2004) propone que slo las
tres primeras pueden ser establecidas por las fuerzas externas (jefes de
proyecto y clientes), mientras que el valor de la cuarta variable debe ser
establecido por los programadores en funcin de las otras tres.
XP involucra todas las partes implicadas en el proyecto hasta que el valor

que alcancen las cuatro variables sea el correcto para todas las partes: Si
quieres mas calidad en menos tiempo tendrs que aumentar el equipo e
incrementar el coste. (dem, p. 3)
3.2.4.3 Los cuatro valores
Una de las cosas que los desarrolladores deben tener muy claro es que en
el ciclo de vida del desarrollo de un proyecto software los cambios van a
aparecer, cambiarn los requisitos, las reglas de negocio, el personal, la
tecnologa, todo va a cambiar.
Para Beck (2004, p. 30), como en otra cualquier actividad humana, en XP

se necesitan valores para desarrollar el trabajo y conseguir los planteamientos
45
inciales. Estos cuatro valores son:
a) Comunicacin. Se tienen muchos problemas en el equipo de desarrollo

por falta de comunicacin, por no comentar un cambio crtico en el diseo, por
no preguntar lo que se piensa al cliente. XP ayuda mediante sus prcticas a
fomentar la comunicacin.
b) Sencillez. XP nos ensea a apostar por hacer una cosa sencilla hoy y
pagar un poco ms para maana, si es necesario, que hacer una cosa
complicada hoy y no utilizarla despus. La sencillez y la comunicacin se
complementan, cuanto ms simple es el sistema menos hay que comunicar de
l.
c) Retroalimentacin. Por medio de pruebas funcionales al software, ste

nos mantendr informado del grado de fiabilidad del sistema, esta informacin
realmente no tiene precio. La retroalimentacin acta junto con la sencillez y la
comunicacin, cuanto mayor retroalimentacin ms fcil es la comunicacin.
Cuanto mas simple un sistema mas fcil de probar.
d) Valenta. La valenta junto con la comunicacin y la sencillez se

convierte en extremadamente valiosa. En fin se debe tener la valenta suficiente
para medir honestamente el avance del proyecto y comunicar abiertamente los
errores y los cambios para solucionarlos.
3.2.4.4 Las Actividades Bsicas de XP
Las tareas que se deben llevar a cabo para desarrollar un buen software,
con XP son:
46
a) Codificar. Sin cdigo fuente no hay programa, por tanto, se necesita

codificar y plasmar las ideas a travs del cdigo. En una programacin en XP
en pareja el cdigo expresa la interpretacin del problema, as se puede utilizar
el cdigo para comunicar, para hacer comunes las ideas, y por tanto para
aprender y mejorar.
b) Hacer pruebas. Las caractersticas del software que no pueden ser

demostradas mediante pruebas simplemente no existen. Las pruebas dan la
oportunidad de saber si lo implementado es lo que en realidad se tena en
mente.
c) Escuchar. Hay que escuchar del cliente cuales son los problemas de su
negocio, teniendo una escucha activa explicando lo que es fcil y difcil de
obtener, y la realimentacin entre ambos ayudar a todos a entender los
problemas.
d) Disear. El diseo crea una estructura que organiza la lgica del

sistema, un buen diseo permite que el sistema crezca con cambios en un solo
lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de
desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el
diseo o malos diseos, estos deben de ser corregidos cuanto antes.
En fin, lo ms importante en XP en lo que a actividades se refiere, no es

conocerlas a cada una, es combinarlas de una manera efectiva y
constantemente en todo el proceso de desarrollo, es decir, se debe codificar
porque sin cdigo no hay programas, hay que hacer pruebas por que sin
pruebas no se sabe si se ha acabado de codificar, habr que escuchar, pues de
lo contrario no se sabe que codificar ni probar, y tambin hay que disear para
poder codificar, probar y escuchar indefinidamente.
47
3.2.4.5 Los Principios de XP
Hay
principios
fundamentales
varios
ms
adicionales.
Los
fundamentales son:
a) Realimentacin Rpida: con la idea de maximizar el aprendizaje,

reduciendo el coste del cambio y de los errores.
b) Asumir la sencillez: se parte del supuesto de que para todo problema

complejo hay siempre una solucin sencilla. Se debe trabajar para encontrarla,
empezando por aceptar que existe.
c) Cambio Incremental: nada de realizar grandes cambios, estos no
funcionan. La diferencia se consigue mediante la sucesin de pequeos
cambios que harn la diferencia.
d) Aceptar el cambio: Se optar por las estrategias de desarrollo que

permitan posponer las decisiones al mximo, as el cliente no tendr que optar
ni invertir hasta el ltimo momento, con la mayor informacin posible y el menor
costo.
a) Trabajar con calidad: hacer un trabajo bajo los mejores estndares de

calidad posibles, satisfaciendo al mximo al cliente.
Los principios adicionales son: Ensear a aprender, Pequea inversin

inicial, Jugar a ganar, Experimentos concretos, Comunicacin Abierta y sincera,
Trabajar con los instintos de las personas, Aceptar la responsabilidad,
Adaptacin particular, Ir ligero e equipaje, y realizar medidas honestas.
3.2.4.6 Las Prcticas en XP

La principal suposicin que se realiza en XP es la posibilidad de disminuir
48
la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo
suficiente para que el diseo evolutivo funcione. XP apuesta por un crecimiento
lento del costo del cambio y con un comportamiento asinttico. Esto se
consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de
software y a la aplicacin disciplinada de las prcticas que descritas a
continuacin:
a) El juego de la planificacin. El equipo tcnico (jugador 1) realiza una

estimacin del esfuerzo requerido para la implementacin de las historias de
usuario y los clientes (jugador 2) deciden sobre el mbito y tiempo de las
entregas y de cada iteracin.
b) Entregas pequeas. La idea es producir rpidamente versiones del
sistema que sean operativas, aunque obviamente no cuenten con toda la
funcionalidad pretendida para el sistema pero si que constituyan un resultado
de valor para el negocio.
c) Metfora. El sistema es definido mediante una metfora o
historia
compartida (cliente/desarrollador) que describe cmo debera funcionar el

sistema o el trabajo de desarrollo.
d) Diseo simple. Se debe disear la solucin ms simple que pueda
funcionar y ser implementada en un momento determinado del proyecto. La
complejidad innecesaria y el cdigo extra debe ser removido inmediatamente.
e) Pruebas. La produccin de cdigo est dirigida por las pruebas
unitarias, las pruebas unitarias son establecidas antes de escribir el cdigo y
son ejecutadas constantemente ante cada modificacin del sistema, mientras
que, los clientes escriben las pruebas funcionales para cada historia de usuario
que deba validarse; pudiendo combinarse los dos tipos de pruebas.
f) Refactorizacin (Refactoring). La refactorizacin es una actividad

constante de reestructuracin del cdigo con el objetivo de remover duplicacin
49
de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para

facilitar los posteriores cambios.
g) Programacin en parejas. La mayor parte de la produccin de cdigo

debe realizarse con trabajo en parejas de programadores, logrando que la tasa
de errores del producto final es ms baja, los diseos sean mejores, el tamao
del cdigo menor, entre otras ventajas.
h) Propiedad colectiva del cdigo. Cualquier programador puede cambiar
cualquier parte del cdigo en cualquier momento. Esta prctica motiva a todos a
contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la
vez que algn programador sea imprescindible para realizar cambios en alguna
porcin de cdigo.
i) Integracin Continua. Cada pieza de cdigo es integrada en el sistema

una vez que est lista. As, el sistema puede llegar a ser integrado y construido
varias veces en un mismo da. Todas las pruebas son ejecutadas y tienen que
ser aprobadas para que el nuevo cdigo sea incorporado definitivamente.
j) 40 horas por semana. Se debe trabajar un mximo de 40 horas por

semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre,
probablemente est ocurriendo un problema que debe corregirse.
k) Cliente in-situ. El cliente tiene que estar presente y disponible todo el

tiempo para el equipo. Gran parte del xito del proyecto XP se debe a que es el
cliente quien conduce constantemente el trabajo hacia lo que aportar mayor
valor de negocio y los programadores pueden resolver de manera inmediata
cualquier duda asociada.
l) Estndares de programacin. XP enfatiza la comunicacin de los

programadores a travs del cdigo, con lo cual es indispensable que se sigan
50
ciertos estndares de programacin, manteniendo el cdigo legible para los

miembros del equipo, facilitando los cambios.
3.2.4.7 Combinacin entre prcticas
La mayora de las prcticas ya haban sido propuestas en ingeniera del

software, el gran mrito de XP es integrarlas de una forma efectiva y
complementarlas con otras ideas desde la perspectiva del negocio, los valores
humanos y el trabajo en equipo.
El mayor beneficio de las prcticas se consigue con su aplicacin conjunta

y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 6
(Letelier, 2003), donde una lnea entre dos prcticas significa que las dos
prcticas se refuerzan entre s.
Fuente: Letelier (2003), p.17
Figura 6: Prcticas se refuerzan entre s
51
3.2.4.8 El Proceso de XP Ciclo de Vida
El ciclo de vida de XP se enfatiza en el carcter interactivo e incremental

del desarrollo. Segn Anaya y Plaza (2007, p. 4) una iteracin de desarrollo es
un periodo de tiempo en el que se realiza un conjunto de funcionalidades
determinadas que en el caso de XP corresponden a un conjunto de historias de
usuario.
Las iteraciones son relativamente cortas ya que se piensa que entre ms

rpido se le entreguen desarrollos al cliente, ms retroalimentacin se va a
obtener y esto va a representar una mejor calidad del producto a largo plazo.
Existe una fase de anlisis inicial orientada a programar las iteraciones de
desarrollo y cada iteracin incluye diseo, codificacin y pruebas, fases
superpuestas de tal manera que no se separen en el tiempo. En la figura 7, se
muestran las fases en las que se subdivide el ciclo de vida XP.
Fuente: Anaya y Plaza (2007), p.5
Figura 7: Ciclo de Vida de XP
52
El ciclo de vida ideal de XP consiste de seis fases (Beck, 2004, p. 100):

Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin,
Mantenimiento y Muerte del Proyecto.
a) Fase I: Exploracin. En esta fase, los clientes plantean a grandes

rasgos las historias de usuario que son de inters para la primera entrega del
producto. Al mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se
prueba la tecnologa y se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo.
La fase de exploracin toma de pocas semanas a pocos meses,
dependiendo del tamao y familiaridad que tengan los programadores con la
tecnologa.
b) Fase II: Planificacin de la Entrega. En esta fase el cliente establece la

prioridad
de
cada
historia
de
usuario,
correspondientemente,
los
programadores realizan una estimacin del esfuerzo necesario de cada una de

ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega debera
obtenerse en no ms de tres meses. Esta fase dura unos pocos das.
c) Fase III: Iteraciones. Esta fase incluye varias iteraciones sobre el

sistema antes de ser entregado. El Plan de Entrega est compuesto por
iteraciones de no ms de tres semanas. En la primera iteracin se puede
intentar establecer una arquitectura del sistema que pueda ser utilizada durante
el resto del proyecto. Esto se logra escogiendo las historias que fuercen la
creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que
es el cliente quien decide qu historias se implementarn en cada iteracin
(para maximizar el valor de negocio). Al final de la ltima iteracin el sistema
estar listo para entrar en produccin.
53
Todo el trabajo de la iteracin es expresado en tareas de programacin,

cada una de ellas es asignada a un programador como responsable, pero
llevadas a cabo por parejas de programadores.
d) Fase IV: Produccin. La fase de produccin requiere de pruebas
adicionales y revisiones de rendimiento antes de que el sistema sea trasladado
al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la
inclusin de nuevas caractersticas a la versin actual, debido a cambios
durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una
semana. Las ideas que han sido propuestas y las sugerencias son
documentadas para su posterior implementacin (por ejemplo, durante la fase
de mantenimiento).
e) Fase V: Mantenimiento. Mientras la primera versin se encuentra en

produccin, el proyecto XP debe mantener el sistema en funcionamiento al
mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere
de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo
puede bajar despus de la puesta del sistema en produccin. La fase de
mantenimiento puede requerir nuevo personal dentro del equipo y cambios en
su estructura.
f) Fase VI: Muerte del Proyecto. Es cuando el cliente no tiene ms

historias para ser incluidas en el sistema. Esto requiere que se satisfagan las
necesidades del cliente en otros aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentacin final del sistema y no se realizan ms
cambios en la arquitectura.
La muerte del proyecto tambin ocurre cuando el sistema no genera los
54
beneficios esperados por el cliente o cuando no hay presupuesto para

mantenerlo.
3.2.4.9 Roles en XP
Aunque en otras fuentes de informacin aparecen algunas variaciones y
extensiones de roles XP, en este apartado describiremos los roles de acuerdo
con la propuesta original de Beck (2004, p. 105).
a) Programador: escribe las pruebas unitarias y produce el cdigo del
sistema. Debe existir una comunicacin y coordinacin adecuada entre los
programadores y otros miembros del equipo.
b) Cliente: escribe las historias de usuario y las pruebas funcionales para

validar su implementacin. Adems, asigna la prioridad
a las historias de
usuario y decide cules se implementan en cada iteracin centrndose en

aportar mayor valor al negocio.
c) Encargado de pruebas (Tester): ayuda al cliente a escribir las pruebas

funcionales. Ejecuta las pruebas regularmente, difunde los resultados al equipo
y es responsable de las herramientas de soporte para pruebas.
d) Encargado de seguimiento (Tracker): proporciona realimentacin al

equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto
entre las estimaciones realizadas y el tiempo real dedicado, comunicando los
resultados para mejorar futuras estimaciones. Determina cundo es necesario
realizar algn cambio para lograr los objetivos de cada iteracin.
As mismo, existen otros roles como el del Entrenador (Coach),

responsable del proceso global de desarrollo bajo reglas XP; el Consultor, o
miembro externo del equipo con un conocimiento especfico en algn tema
55
necesario para el proyecto y el Gestor (Big boss), cuya labor esencial es de

coordinacin.
3.2.4.10 Historias de Usuario y dems artefactos XP
a) Historias de Usuario.
Las historias de usuario son la tcnica utilizada en XP para especificar los

requisitos del software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las caractersticas en un lenguaje no tcnico acerca de la
informacin que el sistema debe poseer, sean requisitos funcionales o no
funcionales. Cada historia de usuario es lo suficientemente comprensible y
delimitada para que los programadores puedan implementarla en unas
semanas.
A continuacin se muestra una tabla utilizada como modelo para registrar

una historia de usuario:
Fuente: Anaya, 2007
Historia de Usuario
Nmero:
Nombre Historia de Usuario:
Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre):
Usuario:
Prioridad en Negocio:
(Alta / Media / Baja)
Riesgo en Desarrollo:
(Alto / Medio / Bajo)
Descripcin:
Iteracin Asignada:
Puntos Estimados:
Puntos Reales:
Observaciones:
Tabla 1. Modelo propuesto para una historia de usuario
56
Estas deben proporcionar slo el detalle suficiente como para poder

hacer razonable la estimacin de cunto tiempo requiere la implementacin de
la historia, difiere de los casos de uso porque son escritos por el cliente, no por
los programadores, empleando terminologa del cliente. Las historias de
usuario son ms amigables que los casos de uso formales.
Dependiendo de la complejidad del sistema, debe haber al menos una

historia por cada caracterstica importante, para as realizar una o dos historias
por programador por mes. Si se tienen menos, probablemente sea conveniente
dividir las historias, si se tienen ms lo mejor es disminuir el detalle y
agruparlas.
Las Historias de Usuario tienen tres aspectos:
Tarjeta: en ella se almacena suficiente informacin para identificar y detallar la

historia.
Conversacin: cliente y programadores discuten la historia para ampliar los

detalles (verbalmente cuando sea posible, pero documentada cuando se
requiera confirmacin).
Pruebas de Aceptacin: permiten confirmar que la historia ha sido

implementada correctamente. Las tarjetas o tablas de las pruebas de
aceptacin/unitarias constituyen otro de los artefactos utilizados, en XP,
sealado en la siguiente tabla.

una prueba de aceptacin:
57
Fuente: Anaya, 2007.

Caso de Prueba de Aceptacin
Cdigo:
Historia de Usuario (Nro. y Nombre):
Nombre:
Descripcin:
Condiciones de Ejecucin:
Entrada / Pasos de ejecucin:
Resultado Esperado:
Evaluacin de la Prueba:
Tabla 2. Modelo propuesto para una prueba de aceptacin
b) Tarea de ingeniera
Otro artefacto de XP son las Task Card o Tarea de Ingeniera, en ellas
los desarrolladores junto con el manager del proyecto y previa consulta y
validacin de todas las historias de usuario, proceden a anotar las tareas de
desarrollo de aplicaciones relacionadas a cada historia de usuario. El grupo
programador, dada las practicas metodolgicas se apoyar en ests para la
ejecucin del producto de software; se elaboran con el fin de definir el orden de
desarrollo de cada tarea, fechas de inicio y fin, el programador responsable y su
descripcin.

una tarea de ingeniera:
Tarea de Ingeniera
Nmero Tarea: Historia de Usuario (Nro. y Nombre):
Nombre Tarea:
Tipo de Tarea :
Desarrollo / Correccin / Mejora / Puntos Estimados:
Otra (especificar)
Fecha Inicio:
Fecha Fin:
Programador Responsable:
Descripcin:
Tabla 3. Modelo propuesto para una tarea de ingeniera
58
c) Tarjetas CRC (Clase - Responsabilidad Colaborador)
En la tarjetas de tareas de ingeniera, y siguiendo el formato arriba

descrito (Tabla 3); los desarrolladores junto con el manager del proyecto y
previa consulta y validacin de todas las historias de usuario, proceden a
anotar las tareas de desarrollo de aplicaciones relacionadas a cada historia
de usuario. El grupo programador (par programando); dada las practicas
metodolgicas se apoyar en ests para la ejecucin del producto de
software.
Estas tarjetas se dividen en tres secciones que contienen la informacin

del nombre de la clase, sus responsabilidades y sus colaboradores y pueden
ser utilizadas dependiendo la utilidad y el valor que le aporten al desarrollo.
En la siguiente figura se muestra cmo se distribuye esta informacin.
Estas tarjetas se dividen en tres secciones que contienen la informacin

del nombre de la clase, sus responsabilidades y sus colaboradores. En la
siguiente figura se muestra cmo se distribuye esta informacin.

Nombre de la clase
Responsabilidades
Colaboradores
Tabla 4. Modelo de tarjeta CRC

Una clase es cualquier persona, cosa, evento, concepto, pantalla o
59
reporte. Las responsabilidades de una clase son las cosas que conoce y las
que realizan, sus atributos y mtodos. Los colaboradores de una clase son las
dems clases con las que trabaja en conjunto para llevar a cabo sus
responsabilidades.
En la prctica conviene tener pequeas tarjetas de cartn, que se

llenarn y que son mostradas al cliente, de manera que se pueda llegar a un
acuerdo sobre la validez de las abstracciones propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:
1) Encontrar clases
2) Encontrar responsabilidades
3) Definir colaboradores
4) Disponer las tarjetas
Para encontrar las clases debemos pensar qu cosas interactan con el

sistema (en nuestro caso el usuario), y qu cosas son parte del sistema, as
como las pantallas tiles a la aplicacin (un despliegue de datos, una entrada
de parmetros y una pantalla general, entre otros). Una vez que las clases
principales han sido encontradas se procede a buscar los atributos y las
responsabilidades, para esto se puede formular la pregunta Qu sabe la
clase? y Qu hace la clase? Finalmente se buscan los colaboradores dentro
de la lista de clases que se tenga.
(Anaya, 2007, pp. 5-7).
3.2.5 Elementos Esenciales en el Desarrollo de Sistemas de

Informacin
En pro del exitoso desarrollo de un sistema de informacin se hace

imprescindible, adems de la metodologa con la que se fundamentar todo el
60
proceso, el uso de una serie de factores, tales como el lenguaje para la

programacin, las bases de datos donde se almacenar la informacin
pertinente y un sistema gestor que permita el manejo de la misma.
3.2.5.1 Lenguaje de Programacin
Es un conjunto de smbolos y reglas sintcticas y semnticas que definen

su estructura y el significado de sus elementos y expresiones. Es utilizado para
controlar el comportamiento fsico y lgico de una mquina.
.
Un lenguaje de programacin permite a uno o ms programadores
especificar de manera precisa sobre qu datos debe operar una computadora,
cmo estos datos deben ser almacenados o transmitidos y qu acciones debe
tomar bajo una variada gama de circunstancias. Todo esto, a travs de un
lenguaje que intenta estar relativamente prximo al lenguaje humano o natural,
tal como sucede con el lenguaje lxico. Una caracterstica relevante de los
lenguajes de programacin es precisamente que ms de un programador
puedan tener un conjunto comn de instrucciones que puedan ser
comprendidas entre ellos para realizar la construccin del programa de forma
colaborativa.http://www.mastermagazine.info/termino/6749.php
[Consulta: Septiembre, 2009].
3.2.5.2 Bases de datos
Una base de datos es un conjunto estructurado de datos que representa

entidades y sus interrelaciones. La representacin ser nica e integrada, a
pesar de que debe permitir utilizaciones varias y simultneas.
61
(Camps, Casillas, Costal, Ginest, Escofet y Prez, 2005, p. 8).
Una base de datos tiene las siguientes propiedades implcitas:
a) Una base de datos representa algn aspecto del mundo real, en

ocasiones
llamado
minimundo
universo
de
discurso.
Las
modificaciones del minimundo se reflejan en la base de datos.

b) Una base de datos es un conjunto de datos lgicamente coherente, con
cierto significado inherente. Una coleccin aleatoria de datos no puede
considerarse propiamente una base de datos.
c) Toda base de datos se disea, construye y puebla con datos para un

propsito especfico. Est dirigida a un grupo de usuarios y tiene ciertas
aplicaciones preconcebidas que interesan a dichos usuarios.
En otras palabras, una base de datos tiene una fuente de la cual se
derivan los datos, cierto grado de interaccin con los acontecimientos del
mundo real y un pblico que est activamente interesado en el contenido de la
base de datos.
Las bases de datos pueden ser de cualquier tamao y tener diversos

grados de complejidad. Su generacin y mantenimiento pueden ser manuales o
mecnicos. Las bases de datos computarizadas se pueden crear y mantener
con un grupo de programas de aplicacin escritos especficamente para esa
tarea, o bien mediante un sistema de gestin de bases de datos. (Elmari y
Navathe, 2000, p. 2).
3.2.5.3 Sistema Gestor de Base de Datos (SGBD)
Es un conjunto de programas que permite a los usuarios crear y

mantener una base de datos. Por tanto, el SGBD es un sistema de software de
62
propsito general que facilita el proceso de definir, construir y manipular bases

de datos para diversas aplicaciones.
(Elmasri y Navathe, 2000, p. 3).
Los SGBD que actualmente estn en el mercado pretenden satisfacer un

conjunto de objetivos:
a) Consultas no predefinidas y complejas
Los usuarios podrn hacer consultas de cualquier tipo y complejidad

directamente al SGBD. El SGBD tendr que responder inmediatamente sin que
estas consultas estn preestablecidas; es decir, sin que se tenga que escribir,
compilar y ejecutar un programa especfico para cada consulta.
b) Flexibilidad e independencia
Para conseguir esta independencia, tanto los usuarios no necesitan

saber nada sobre el soporte fsico, de este modo, se pueden hacer cambios de
tecnologa y cambios fsicos para mejorar el rendimiento sin afectar a nadie,
este tipo de independencia recibe el nombre de independencia fsica de los
datos. Sin embargo, con la independencia fsica no es suficiente. Tambin se
desea que los usuarios no tengan que hacer cambios cuando se modifica la
descripcin lgica o el esquema de la BD, a lo que se denomina independencia
lgica.
c) Problemas de la redundancia
El SGBD debe permitir que el diseador defina datos redundantes, pero

entonces tendra que ser el mismo SGBD el que hiciese automticamente la
actualizacin de los datos en todos los lugares donde estuviesen repetidos.
63
d) Integridad de los datos
Cuando el SGBD detecte que un programa quiere hacer una operacin

que va contra las reglas establecidas al definir la BD, no se lo deber permitir, y
le tendr que devolver un estado de error.
e) Concurrencia de usuarios
Un objetivo fundamental de los SGBD es permitir que varios usuarios
puedan acceder concurrentemente a la misma base de datos.
f) Seguridad
Actualmente, en el campo de los SGBD, el trmino seguridad se suele

utilizar para hacer referencia a los temas relativos a la confidencialidad, las
autorizaciones, los derechos de acceso, etc.
(Camps, Casillas, Costal, Ginest, Escofet, y Prez, 2005, pp. 15-21).
3.2.5.4 Sistemas de Control y Gestin

Un Sistema de Control, es un conjunto de acciones, funciones, medios
y responsables que garanticen, mediante su interaccin, conocer la situacin
de un aspecto o funcin de la organizacin en un momento determinado y
tomar decisiones para reaccionar ante ella (Menguzzato y Renau. 1986, p.
245.)
Los sistemas de control deben cumplir con una serie de requisitos para su
funcionamiento eficiente, entre ellos se destaca, ser entendibles, adems,
deben seguir la forma de organizacin, ser rpidos, flexibles y econmico.
64
El Control de gestin, al principio se consideraba como una serie de

tcnicas tales como el control interno, el control de costos y documentos,
auditoras internas y externas, anlisis de ratios, informes de entrega y puntos
de equilibrio, pero el control presupuestario constitua y an para algunos
constituye el elemento fundamental de la gestin. Actualmente se le considera
como un proceso mediante el cual los directivos aseguran la obtencin de
recursos y su utilizacin eficaz y eficiente en el cumplimiento de los objetivos de
la organizacin Gonzlez y Yabor (2007, p. 5)
Basado en lo anterior, un Sistema de Control y Gestin, es aquel que est
destinado a ayudar a los distintos niveles de decisin a coordinar las acciones,
a fin de alcanzar los objetivos de mantenimiento, desempeo y evolucin,
fijados a distintos plazos, especificando que si los datos contables siguen
siendo importantes, est lejos de tener el carcter casi exclusivo que se le
concede en muchos sistemas de control de gestin. (dem, p. 6)
Aplicado al proyecto de pasanta, esto se logra a travs de un conjunto de

mecanismos (como desarrollar un software de gestin) que puede utilizar la
direccin de la organizacin que permiten aumentar la probabilidad de que el
comportamiento
de los
procesos,
actividades (entrega
de
materiales,
generacin de reportes e informes, y dems) y de las personas que forman

parte de ella (trabajadores del departamento), sea coherente con los objetivos
que esta persigue (mantener ndices efectivos en lo que ha mantenimiento
correctivo y preventivo se refiere).
3.2.5.5 Control y Gestin de Requisiciones
Para Serna (2005) existen dos factores importantes que se toman en

cuenta para conocer lo que implica el control de requisiciones, estos son:
65
a) Minimizacin de la inversin: El inventario mnimo es cero, la empresa

podr no tener ninguno y producir sobre pedido, esto no resulta posible para la
gran mayora de las empresas, puesto que deben satisfacer de inmediato las
demandas de los clientes o en caso contrario el pedido pasar a los
competidores que puedan hacerlo, y deben contar con inventarios para
asegurar los programas de produccin. La empresa procura minimizar el
inventario porque su mantenimiento es costoso.
b) Afrontando la demanda: Si la finalidad de la administracin fuera slo

minimizar los gastos, manteniendo la satisfaccin de sus clientes dotndose de
materiales necesarios para la solucin de problemas a corto o largo plazo los
resultados serian excelentes . Sin embargo, resulta extremadamente costoso
tener inventarios estticos paralizando un capital que se podra emplear con
provecho. La empresa debe determinar el nivel apropiado de pedidos
semanales o mensuales para poder evitar de esta manera desgaste de
recursos primas para la produccin y actividad constante de las plantas
evitando paradas que generan prdidas millonarias a la empresa.
El control y gestin es importante, ya que esta partida constituye el

aparato circulatorio de una empresa que tenga un flujo continuo sobre los
elementos de su almacn. Los elementos de un buen control interno sobre los
inventarios, segn Franklin (2004, s/p), incluyen:
a) Conteo fsico de los inventarios por lo menos una vez al ao, no
importando cual sistema se utilice.
b) Mantenimiento eficiente de compras, recepcin y procedimientos de
embarque.
c) Almacenamiento del inventario para protegerlo contra el robo, dao
descomposicin.
d) Permitir el acceso al inventario solamente al personal que no tiene
acceso a los registros contables.
66
e) Mantener registros de inventarios perpetuos para las mercancas de

alto costo unitario.
f) Comprar el inventario en cantidades econmicas.
g) Mantener suficiente inventario disponible para prevenir situaciones de
dficit, lo cual conduce a prdidas en ventas.
h) No mantener un inventario almacenado demasiado tiempo, evitando
con eso el gasto de tener dinero restringido en artculos innecesarios
De este modo, el control y gestin interno se convierte en la base sobre la

cual descansa la confiabilidad de un sistema contable y administrativo, al
consistir en procedimientos, mtodos de valuacin (PEPS y UEPS) y polticas
que: promuevan la exactitud y confiabilidad de los datos contables y operativos;
preserven los recursos de la empresa contra el derroche, el fraude y la
ineficiencia; midan el grado de cumplimiento de la poltica empresarial por parte
de los departamentos operativos; y evalen la eficiencia total de las funciones
operativas.
3.2.5.6 Sistemas para el Control y Gestin de Inventarios

Definir el concepto de sistema para el control y gestin de inventarios
implica considerar el desarrollo del mismo en el mbito administrativo; de este
modo, este tipo de sistema puede considerarse, segn Abad Arango (2006)
como:
un instrumento gerencial integral y estratgico que, apoyado en
indicadores, ndices y cuadros producidos en forma sistemtica,
peridica y objetiva, permitan a la organizacin ser efectiva en el
manejo de sus recursos, productos, elementos y/o herramientas, de
forma eficiente para transformarlos y eficaz para canalizarlos (p. 25)
En el campo administrativo, el desarrollo de actividades para la
elaboracin y ejecucin de sistemas de control y gestin han tenido relacin con
el mbito de concepcin acerca del propio concepto de control, a continuacin
67
se explican las fases generalmente aplicadas en el diseo y desarrollo de este

tipo de sistemas, aplicable sin duda, al mbito de los depsitos y almacenes:
a) Diagnstico institucional: todo proceso de Control de Gestin comienza

con el estudio propio del sistema (de almacn) a controlar. El diagnstico tiene
como objetivo, segn Abad (2006, p.15), identificar posibles obstculos que
puedan interferir en la eficacia del sistema, y del mismo modo, establecer si
estn dadas las condiciones para la ejecucin del sistema propuesto e
identificar los procesos clave para que el sistema opere sobre ellos y sus
variables claves, a fin de garantizar en lo posible el xito organizacional
b) Identificacin de procesos claves: luego de conocer el sistema a

controlar, es necesario identificar los procesos claves para el xito en el sector
empresarial donde se aplica (inventario y almacn en este caso), el sistema se
centra en aquellos procesos lo suficientemente importantes en el desempeo
eficaz del sistema a controlar, van desde la entrega de productos, la recepcin y
almacenaje, el despacho, la generacin de reportes, los medios de transporte y
traslado, entre otros.
c) Diseo del sistema de indicadores: De la definicin de las reas claves,

se originan los indicadores que van a permitir medir atributos de dichos
procesos y tomar las decisiones pertinentes para su correccin.
d) Definir los indicadores para los factores claves de xito: A cada factor
de xito se definirn los respectivos indicadores y determinar para cada
indicador el estado, umbral y rango de gestin.
e) Disear la medicin: Consiste en definir la fuente de informacin, la
frecuencia de la medicin, la presentacin, la tabulacin, anlisis y el
responsable del proceso; que permitan medir, probar y ajustar el sistema de
indicadores.
68
f) Estandarizar y formalizar: Se refiere a la elaboracin del manual de

indicadores y a la divulgacin del mismo
g) Escoger los instrumentos de control: Dentro del control de gestin
existe una variedad de tcnicas e instrumentos generalmente aplicados en la
gestin del proceso, entre estos: manuales operativos y de procedimientos,
intervencin, inspeccin, control interno, auditora interna, auditora externa,
contabilidad analtica, entre otros
Y otros factores como la Validacin del sistema (revisar la calidad,

pertinencia, consistencia y confiabilidad de los datos manejados por el sistema);
la evaluacin del sistema (identificar los desfases y puntos dbiles de la gestin
de los inventarios) y por ltimo la implementacin del sistema (aplicar las fases
anteriormente descritas a fin de adoptar oficialmente el sistema y definir los
mecanismos para su administracin).
3.2.5.7 Visual Basic 6.0
Esta versin combina la sencillez del BASIC con un poderoso lenguaje

de programacin Visual que juntos permiten desarrollar robustos programas
para Windows. El lenguaje Visual Basic ya no es ms "un lenguaje para
principiantes" sino que es una perfecta alternativa para los programadores de
cualquier nivel que deseen desarrollar aplicaciones compatibles con Windows.
La versin 6.0 continua utilizndose masivamente; la cual es la ms adecuada
para el sistema que se desea realizar en el departamento de compras y
logstica o P&M (procura y materiales) de dicha empresa, pudiendo realizar en
algn momento una extensin hacia otros departamentos que requieran de
dicho sistema.
Como lo es en este caso un lenguaje de programacin conocido como

visual Basic 6.0 que se ha diseado para facilitar el desarrollo de aplicaciones
69
en un entorno Como Windows vista, Windows ultimate o superior, cuya versin

6.0 soportan caractersticas propias de los lenguajes orientados a objetos.
Visual Basic es un entorno de desarrollo integrado (IDE, por sus siglas en

ingls) para sistemas operativos Windows. Soporta varios lenguajes de
programacin. Esta suite permite a los desarrolladores crear aplicaciones, sitios
y aplicaciones web, as como servicios web en cualquier entorno que soporte la
plataforma .NET. As se pueden crear aplicaciones que se intercomuniquen
entre estaciones de trabajo, pginas web y dispositivos mviles.
Visual Basic est diseado para aprovechar las ventajas que ofrece el
nuevo sistema operativo "Windows Vista" a travs de sus subsistemas
"Windows Communication Foundation" (WCF) y "Windows Presentation
Foundation" (WPF).El primero tiene como objetivo la construccin de
aplicaciones orientadas a servicios mientras que el ltimo apunta a la creacin
de interfaces de usuario ms dinmicas que las conocidas hasta el momento.
3.3 Bases Legales
En relacin con los proyectos informticos asociados con el desarrollo de

software y sistemas automatizados la empresa exterran decret los principales
artculos 301, 303, 305, 306, 309, 312, que establece los requisitos, directrices,
problemas y descripciones necesarios para el funcionamiento seguro y fiable de
los sistemas de tecnologa de la informacin, servicios y aplicaciones de
software para su uso en actividades de produccin y comercio.
El Artculo 301 del cdigo versin A, se refiere directamente a los sistemas

de tecnologa, que abarcan los recursos empresariales del sistema de
70
produccin en Oracle ("Oracle"), Visual Basic, Access, SQL, y la infraestructura

de red y el medio ambiente. De dicho artculo se extrae:
La poltica define las medidas de control de lnea de base de datos donde
todos los empleados en Exterran deben estar familiarizados para prevenir una
variedad de temas, incluyendo: el fraude y la malversacin de fondos, el
espionaje industrial, sabotaje, errores y problemas legales y falta de
disponibilidad del sistema. De manera detallada la poltica es razonable y
prctica para evitar prdidas innecesarias. Utilizando esta poltica de seguridad
de la informacin es el primer paso en el control de la integridad de los activos
digitales de las actividades comerciales del da a da de la empresa Exterran.
Esta poltica se aplica a los empleados, empresarios, consultores o terceros que
tienen acceso a los sistemas de Tecnologa de Negocios.
El Artculo 303 del cdigo versin A, se refiere directamente a la
privacidad de los sistemas de tecnologa, internet, intranet, de igual manera
su correcto uso y beneficios. De dicho artculo se extrae:
El uso de sistemas informticos, de Intranet, internet tiene la
particularidad de guardar en los servidores internos de Exterran todo los
procesos y gestiones que se realizan en cada uno de los equipos que forman
parte de los bienes de la empresa y los cuales son manejados por empleados,
proveedores o clientes debidamente autorizados los cuales no ofrecen ninguna
garanta de privacidad.
El Artculo 305 del cdigo versin A, se refiere directamente a todos los

cambios que en su momento se realizan a todo los dispositivos de los sistemas
de informacin. De dicho artculo se extrae:
Todos los cambios que afectan a la configuracin de los sistemas de
produccin, las plataformas, dispositivos y la lgica del programa debe ser
controlado y vigilado. Los cambios estn documentados y procesados a travs
de una solicitud formal. Todos los cambios deben ser documentados y
aprobados antes de su aplicacin.
Cada cambio solicitado se evala en funcin del nivel de riesgo que
implica. Bajo y medio riesgo de cambios no requieren de revisin a travs del
Control de Cambios, sino que son revisadas por un Coordinador de prueba y
aprobado por un gerente de Tecnologa de Negocios. Alto riesgo de cambios
71
deben ser procesados a travs del proceso de cambio de Examen, donde se

requiere la aprobacin por el Comit de Control de Cambios a fin de ponerse en
prctica.
El Artculo 306 del cdigo versin A, se refiere directamente a todas las
gestiones de datos que se realizan a todo los dispositivos de los sistemas de
informacin. De dicho artculo se extrae:
Los datos sobre la red de Exterran, se obliga tener una copia de
seguridad en un medio extrable donde pueda transportarse y almacenarse en
un lugar seguro, fuera del sitio y mantenerse durante el perodo determinado
por la poltica 502 "Retencin de registros".
Con el fin de mantener la integridad de los datos, continuidad del negocio
y recuperacin ante desastres, todos los datos y los programas que residen en
la red Exterran estn respaldadas. Estas copias de seguridad son
administrados centralmente y cada copia de seguridad del servidor y
supervisin programada por el Departamento de Tecnologa de Negocios.
Adquisicin y Desarrollo de Sistemas de Aplicacin. De dicho artculo se extrae:
Todas las aplicaciones y software sern adquirido y / o desarrolladas por
el Departamento de Tecnologa IT de acuerdo con una metodologa de
desarrollo de sistemas, a los cuales se les debe realizar todas las pruebas de
aplicacin de software que se deben llevar a cabo en un entorno distinto al de
produccin, y los datos confidenciales deben ser descifrados.
Desarrollo de usuario. Las aplicaciones desarrolladas por los usuarios son
restringidos y se gestionarn de acuerdo con la poltica Exterran 312
"Aplicaciones de usuario".
Aplicaciones de usuario desarrollados de Sistemas informticos. De dicho
artculo se extrae:
Creados por el usuario las aplicaciones, incluyendo hojas de clculo,
bases de datos, herramientas de informes y programas similares, no deben
directa o indirectamente generar informes sobre el impacto financiero sin los
oportunos controles financieros y contables y el cumplimiento de contabilidad
aplicables y las directrices de presentacin de informes. Adems las
72
aplicaciones creadas se deben almacenar en un lugar aprobado y seguro para

garantizar que las aplicaciones y los datos estn debidamente respaldados, de
conformidad con la poltica Exterran 306 "Gestin de Datos".
Aplicaciones Cubiertas. Esta directiva se refiere a hojas de clculo Microsoft
Excel, bases de datos de Microsoft Access, bases de datos SQL y otras
aplicaciones similares creados por el usuario de los datos y que no se han
creado y / o mantenidos por el Departamento de Tecnologa de Negocios.
El Artculo 1 de conformidad con lo dispuesto en los artculos 110 y 226 de
la Constitucin de la Repblica Bolivariana de Venezuela, 12 y 47 de la Ley
Orgnica de la Administracin Pblica y, 2, 19 y 22 del Decreto con Rango y
Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin, de dicho artculo
se extrae:
La Administracin Pblica Nacional emplear prioritariamente Software Libre
desarrollado con Estndares Abiertos, en sus sistemas, proyectos y servicios
informticos. A tales fines, todos los rganos y entes de la Administracin
Pblica Nacional iniciarn los procesos de migracin gradual y progresiva de
stos hacia el Software Libre desarrollado con Estndares Abiertos.
El Artculo 4 de conformidad con lo dispuesto en los artculos 110 y 226 de
la Constitucin de la Repblica Bolivariana de Venezuela, 12 y 47 de la Ley
Orgnica de la Administracin Pblica y, 2, 19 y 22 del Decreto con Rango y
Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin, de dicho artculo
se extrae. A los efectos del presente Decreto se entender por:
El Ministerio de Ciencia y Tecnologa, adelantar los programas de
capacitacin de los funcionarios pblicos, en el uso del Software Libre
desarrollado con Estndares Abiertos, haciendo especial nfasis en los
responsables de las reas de tecnologas de informacin y comunicacin, para
lo cual establecer con los dems rganos y entes de la Administracin Pblica
Nacional los mecanismos que se requieran.
3.4 Definicin de Trminos
Automatizacin: Ejecucin automtica de tareas industriales, administrativas o
cientficas sin intervencin humana intermediaria. (Diccionario Larousse. p 124).
73
Base de Datos: Una base de datos es una coleccin de datos organizados y

estructurados segn un determinado modelo de informacin y que refleja no
solo los datos en s mismos, sino tambin las relaciones que existen entre ellos.
Los datos podrn ser compartidos por distintos usuarios y aplicaciones, pero
deben conservar su integridad y seguridad. La definicin y descripcin de los
datos han de ser nicas para minimizar la redundancia y maximizar la
independencia de su utilizacin. Los datos almacenados pueden ser diversos:
nombres, nmeros telefnicos, direcciones, aos, etc. Todo depende de la
finalidad de la BD. Actualmente, en todos los quehaceres cotidianos se utiliza
una base de datos: cajeros automticos, catlogos de bibliotecas o libreras,
pginas amarillas, listado de medicamentos, e incluso los mismos buscadores
de Internet. Disponible en:
http://www.hipertexto.info/documentos/b_datos.htm [Consulta: Junio, 2009].
Cliente: en la arquitectura cliente/servidor se llama as al proceso que inicia

el dilogo o solicita los recursos, en general, es un ente que requiere de un
servicio o tarea de otro ente. Disponible en: http://www.inei.gob.pe/[Consulta:
Septiembre, 2009].
Control: Actividad de monitorear los resultados de una accin y tomar medidas

para hacer correcciones inmediatas y medidas preventivas para evitar eventos
indeseables en el futuro. Disponible en:
http://www.controlinterno.udea.edu.co/ciup/glosario.htm.[Consulta: Septiembre,
2009].
Cliente/Servidor: La red Cliente/Servidor es aquella red de comunicaciones en
la que todos los clientes estn conectados a un servidor, en el que se
centralizan los diversos recursos y aplicaciones con que se cuenta; y que los
pone a disposicin de los clientes cada vez que estos son. Esto significa que
todas las gestiones que se realizan se concentran en el servidor, de manera
que en l se disponen los requerimientos provenientes de los clientes que
74
tienen prioridad, los archivos que son de uso pblico y los que son de uso
restringido, los archivos que son de slo lectura y los que, por el contrario,
pueden ser modificados, etc. Disponible en:
http://www.mastermagazine.info/termino/6498.php[Consulta: Junio,2009].
Estndares Abiertos: Especificaciones tcnicas, publicadas y controladas por
alguna organizacin que se encarga de su desarrollo, las cuales han sido
aceptadas por la industria, estando a disposicin de cualquier usuario para ser
implementadas en un software libre u otro, promoviendo la competitividad,
interoperatividad o flexibilidad. Disponible en: Publicado en la Gaceta oficial N
38.095 de fecha 28/ 12/ 2004 Decreto N 3.390.
Servidor: En la arquitectura cliente/servidor un servidor es un programa

computacional que provee servicios a otros programas computacionales en la
misma computadora o en otras. Disponible en: http://www.inei.gob.pe/
Software Libre: Programa de computacin cuya licencia garantiza al usuario

acceso al cdigo fuente del programa y lo autoriza a ejecutarlo con cualquier
propsito, modificarlo y redistribuir tanto el programa original como sus
modificaciones en las mismas condiciones de licenciamiento acordadas al
programa original, sin tener que pagar regalas a los desarrolladores previos.
Disponible en: Publicado en la Gaceta oficial N 38.095 de fecha 28/ 12/ 2004
Decreto N 3.390.
Sistemas de Informacin: Un Sistema de Informacin es un conjunto de
elementos que interactan entre s con el fin de apoyar las actividades de una
empresa o negocio. Orientados al tratamiento y administracin de datos de
informacin, organizados y listos para su posterior uso, generados para cubrir
una necesidad u objetivo. Disponible en:
http://www.gestiopolis.com/Canales4/mkt/simparalas.htm[Consulta:
75
Septiembre, 2009].
Software y Hardware: La computadora est constituida por dos tipos de

elementos: el hardware y el software El hardware representa todos los
elementos fsicos que la integran mientras que el software, por el contrario,
tiene que ver con sus componentes lgicos. Bsicamente, hablamos de
software para referirnos a todos aquellos programas y procedimientos que la
computadora es capaz de leer ya que estn escritos en lenguaje mquina y que
por eso permite que sta pueda operar. Para ser ms especficos, podemos
referirnos a una definicin de la IEEE, segn la cual software es la suma total
de los programas de cmputo, procedimientos, reglas documentacin y datos
asociados que forman parte de las operaciones de un sistema de cmputo.
Disponible en:
http://www.mastermagazine.info/termino/6749.php[Consulta: Septiembre,2009].
Status: Entre ms conocimiento se pueda manejar en la negociacin, mejores

oportunidades tendr el comprador en obtener sus objetivos con el proveedor.
Este campo permite conocer cul es el estado en el que se encuentra dicha
requisicin desde el momento en que es creada hasta el momento en que es
entregada completamente. Disponible en:
http://www.gestiopolis.com/canales6/fin/compras-manejo-y
conceptos.htm[Consulta: Septiembre, 2009].
SIC: En la mayora de las ocasiones, ocurre de forma verbal, resultando con
ello, un dilogo entre comprador y jefe del departamento de compras para la
realizacin de una compra-venta del bien o servicio. Se conoce como solicitud
interna de compra y es la que permite una vez est aprobada generar la orden
de compra para su requisicin. Disponible en:
http://www.gestiopolis.com/canales6/fin/compras-manejo-yconceptos.htm[Consulta: Septiembre, 2009].
76
Planta: Este trmino relacionado con el sistema desarrollado se conoce como

los diversos lugares que hacen que las compras adquieran especial importancia
en toda la actividad industrial, comercial y de servicios siendo stas conocidas
como bienes fsicos de una empresa que necesiten del departamento de
compras para la obtencin de utilidades, la fijacin del precio de compra, la
fijacin del precio de venta, la operacin eficiente de la inversin, y, los costos y
sustitucin de materiales al lugar donde estn solicitando dichas partes.
Disponible en:
Prioridad: El generar compras como una profesin dentro de la vida industrial y

comercial de un conglomerado empresarial es el acto de obtener el producto o
servicio de la calidad correcta, al precio correcto, en el tiempo correcto y en el
lugar correcto. En este campo se coloca la prioridad con la que est haciendo
solicitada dicha requisicin. Disponible en:
Partes: Son suministros, piezas o componentes que pueden obtenerse en
fuentes externas a la empresa, o pueden ser producidas en la fbrica y
almacenadas para su uso futuro. Son los que se usan en el funcionamiento de
la planta o en la produccin de la compaa, pero que no llegan a formar parte
integrante de los mismos productos.
A medida que crecen los negocios y se trata de administrar en forma cada vez
ms cientfica, los gerentes encuentran ms complejos y ms grandes sus
problemas, as como una mayor presin en la toma de decisiones. Disponible
en: http://www.gestiopolis.com/canales6/fin/compras-manejo-yconceptos.htm[Consulta: Septiembre, 2009].
77
Partes Despachadas: Son las que se encuentran en el almacn de depsito

para ser entregadas de inmediato y se encuentran amparadas con el certificado
de depsito respectivo. Disponible en:
Partes por Despachar: Son los que se usan para el funcionamiento de la

planta o en la produccin de la compaa, pero que no llegan a formar parte
integrante de los mismos productos y no se encuentran disponibles por lo que
son materiales que no han sido entregados y se encuentran pendientes por
despachar. Disponible en:
PR: Se puede afirmar que es el proceso de localizacin y seleccin de
proveedores, adquisicin de productos (materias primas, componentes o
artculos terminados), luego de negociaciones sobre el precio y condiciones de
pago, as como el acompaamiento de dicho proceso para garantizar su
cumplimiento. Son llamadas de igual manera requisiciones o solicitud de
compras. Disponible en:
Requisiciones: Es el camino para obtener cotizaciones de diversos

proveedores de productos y/o servicios, donde t puedes escoger la mejor para
optimizar tus costos de operacin. nicamente tienes que llenar los datos de la
requisicin, especificar los productos o servicios que requieres y nosotros de
inmediato le informamos a todos los proveedores especializados para que te
enven una respuesta con lo que ofrecen; dichas requisiciones se conocen
tambin como PR. Disponible en:
78
http://www.businesscol.com/productos/glosarios/glosarios.htm[Consulta:
Septiembre, 2009].
OC: Es un documento similar a la solicitud interna de compra, se utiliza para

solicitar mercancas, materiales y materia prima a un determinado proveedor
cuando se encuentran en una misma localidad y el proveedor no enva
vendedores para ofrecer el producto. Es el documento formal que utiliza el
departamento de compras para solicitar los materiales que requiere. Debe ser
concreto, claro y especfico en lo que se solicita. Disponible en:
http://www.hipertexto./info/documenmercant/documenmercant.shtml [Consulta:
Septiembre, 2009].
79
CAPTULO IV
MARCO METODOLGICO
Este captulo contempla los aspectos metodolgicos utilizados para
llevar a cabo la investigacin. Comprende tipo y nivel de investigacin,
poblacin y muestra, tcnicas e instrumentos para la recoleccin de datos y
procedimiento, tcnicas de anlisis de datos y diseo operativo.
4.1 Tipo y Nivel de la Investigacin
En cuanto a su nivel o grado de profundidad, la presente investigacin,

se ubica dentro del tipo de Proyecto Factible, por cuanto estar orientada a
la investigacin, elaboracin y desarrollo de la propuesta de un sistema o
modelo operativo viable para darle solucin al problema de la no
automatizacin de los procesos y tareas relacionadas al control del proceso
de requisiciones en el departamento de compras y logstica de la Empresa
Exterran, formulando a partir de las tareas que dentro del departamento se
realizan, en lo que a transacciones en el proceso del departamento se
refiere. En referencia a esto Pardo, J. L. (2003, s/n) expresa que: Un
proyecto factible estar orientado a proponer la solucin de un problema
prctico, requerimientos o necesidades de una organizacin. Este tipo de
investigacin se refiere a la formulacin de mtodos, modelos, planes,
polticas, programas, procesos, sistemas o tecnologas.
El tipo o diseo de la investigacin tiene como objetivo proporcionar un
modelo de verificacin que permita contrastar hechos con teoras, y su forma
es la de una estrategia o plan general que determina las operaciones
necesarias para hacerlo. (Sabino, 1992, p. 87).
80
Esta investigacin se fundamenta, principalmente, en un diseo de

campo, pues los datos primarios para el desarrollo de un sistema
automatizado que optimice, gestione y controle las requisiciones de la
Empresa Exterran Venezuela en el departamento de compras y logstica, son
recolectados directamente desde el seno de dicho departamento, as mismo
todas las actividades y procesos relacionados a las transacciones que se
buscan automatizar con el sistema propuesto fueron analizadas y sus datos
tomados tal cual y suceden en el mismo lugar donde ocurren los hechos. Al
respecto Sabino (1992) comenta:
En los diseos de campo los datos de inters se recogen en forma

directa de la realidad, mediante el trabajo concreto del investigador
y su equipo. Estos datos, obtenidos directamente de la experiencia
emprica, son llamados primarios, denominacin que alude al
hecho de que son datos de primera mano, originales, producto de
la investigacin en curso sin intermediacin de ninguna
naturaleza.(p. 89)
El nivel de la investigacin se determina especificando los objetivos en
cuanto al tipo de conocimientos que el cientfico espera obtener al finalizar el
trabajo (Sabino, 1992, p. 59). As mismo, depender del estado del
conocimiento en el tema de investigacin que nos revele la revisin de la
literatura y del enfoque que el investigador le pretenda dar a su estudio
(Hernndez R. y otros, 1997, p. 115).
Segn el enfoque, la investigacin es Descriptiva, ya que busca

conocer la estructura fundamental de todos los procesos y transacciones
relacionados con el control y gestin del proceso de requisiciones en el
departamento de compras y logstica de la Empresa Exterran Venezuela,
describiendo la situacin actual de estos procesos, de manera que se
puedan especificar sus caractersticas y propiedades necesarias para la
81
automatizacin de los mismos. Sobre los estudios descriptivos Hernndez, R.

y otros (1997) expresa que:
El propsito del investigador es describir situaciones y eventos.

Esto es, decir cmo es y se manifiesta determinado fenmeno.
Los estudios descriptivos buscan especificar las propiedades
importantes de personas, grupos, -comunidades o cualquier otro
fenmeno que sea sometido a anlisis (Dankhe, 1986). Miden y
evalan diversos aspectos, dimensiones o componentes del
fenmeno o fenmenos a investigar. En un estudio descriptivo se
selecciona una serie de cuestiones y se mide cada una de ellas
independientemente, para as -y valga la redundancia- describir lo
que se investiga. (p. 117)
4.2 Poblacin y Muestra
En este proyecto la poblacin est representada por el personal que

labora dentro del departamento de compras y logstica, y todos aquellos que
de igual manera, interactan directamente con los procesos relacionados al
departamento y al rea de trabajo. La poblacin se constituye entonces por:
a) Un (01) Gerente del Departamento de Compras y logstica, que

gestiona, dirige y orienta las actividades relacionadas con todos los
procesos de requisiciones dirigido a todas las plantas en las que opera
la Empresa Exterran.
b) Un (01) Supervisor del Departamento de Compras y logstica,

se encarga de hacer efectiva todas las actividades relacionadas con el
proceso de requisiciones llevando un orden y seguimiento de las
labores que se realizan en cada una de las plantas operativas de la
Empresa Exterran.
c) Cinco (05) Superintendentes uno en cada planta, que ejecutan
las labores de mantenimiento correctivo y preventivo para lograr de esta
82
manera mantener en operacin y produccin dichas sedes; as mismo

tanto de los equipos y materiales que se necesitan para evitar errores y
fallas a largo o mediano plazo.
d) Tres (03) Analistas de Soporte Administrativo,
son los
encargados de gestionar los reportes de despachos de equipos y

materiales, de llevar los inventarios de materia prima, adems de
gestionar las rdenes de compra, entre otras labores.
El total de personas que integran la poblacin a estudiar es de diez

(10), y debido a que el nmero de unidades que integran la poblacin, es
accesible en su totalidad, es decir, esta es menor a cincuenta (50) personas,
no fue necesario extraer una muestra, por lo que generalmente se acuerda
en estos casos, decir que la poblacin ser igual a la muestra, ya que se
pudo obtener datos de toda esa poblacin, sustentado en lo que expresa
Hurtado (2008): La poblacin, adems de ser conocida es accesible, es
decir, es posible ubicar a todos los miembros. No vale la pena hacer un
muestreo para poblaciones de menos de 100 integrantes (p.140).
4.3 Tcnicas e Instrumentos de Recoleccin de Datos
Durante el desarrollo de un sistema automatizado que optimice,

gestione y controle las requisiciones de la Empresa Exterran Venezuela en el
departamento de compras y logstica, se utilizaron las siguientes tcnicas de
recoleccin de datos.
4.3.1 Observacin directa:

indudablemente el observar en el mismo lugar de trabajo (departamento de
compras y logstica de la Empresa Exterran) cada una de las tareas que ah
se realizaban, sirvi como tcnica principal a la hora, no solo de identificar la
83
situacin problemtica y susceptible a mejorar dentro del departamento (no

automatizacin de las transacciones o tareas relacionadas al manejo del
proceso de requisiciones), sino tambin, para establecer los requerimientos
mnimos necesarios para el sistema propuesto y por consiguiente para la
solucin del problema, constituyendo esta la manera ideal de recolectar
datos primarios (Sabino, 1992, p. 89) para el diseo y desarrollo de dicha
propuesta.
4.3.2 Entrevista no estructurada:

esta se aplico a la poblacin en la cual se baso la investigacin, es decir, el
personal del departamento de compras y logstica de la empresa Exterran
Venezuela y a los Analistas de Soporte Administrativo, con el fin
principalmente de obtener los requerimientos bsicos para el diseo del
sistema, utilizando como herramienta principal las historias de usuario. Para
este tipo d entrevista no se dispone de una gua de preguntas elaboradas
previamente. Sin embargo, se orienta por unos objetivos preestablecidos, lo
que permite definir el tema de la entrevista (Arias, F. 2006, p.74); objetivos
que estn claramente definidos en el modelo del sistema a desarrollar.
(Vase Marco Terico, Tabla 1, p. 62)
4.3.3 Recopilacin documental a travs de la Web:

las revistas tcnicas de pginas web especializadas, los foros de discusin,
los grupos de investigacin y desarrollo, los EBook especializados fueron de
vital importancia a la hora de la recoleccin de informacin y dems tipos de
datos secundarios (Sabino, 1992, p. 89 y p. 144) necesarios para la
elaboracin de este trabajo, sobre todo en lo que se refiere a sistemas de
informacin , mtodos de diseo y desarrollo, sistemas de gestin y control,
administracin de almacn; fuentes fundamentales para realizar el proyecto.
84
En todo proceso de elaboracin de sistemas, software o programas, al

igual que en toda tarea de investigacin y desarrollo, es necesario que toda
observacin realizada pueda ser registrada de alguna manera, para que
luego, a partir de ella se puedan relacionar las variables que en ella
convergen para as proceder con las etapas de diseo y desarrollo
correspondientes.
Durante esta investigacin se utilizaron los siguientes instrumentos

bsicos para la recoleccin de informacin:
4.3.4 Libretas de anotaciones, diario de actividades y ordenadores:

estos constituyeron medios auxiliares valiosos, al permitir registrar toda la
serie de actividades, tareas, procesos y transacciones que dentro del
departamento de trabajo se ejecutaban da a da, de manera que los datos
primarios recopilados (producto de dicha observacin directa) pudieran ser
procesados y organizados en conjunto con los datos secundarios
(provenientes de las recopilaciones documentales) y as lograr, no solo una
ms rpida adaptacin en el ambiente de trabajo, sino que tambin tener la
oportunidad de analizar todas las posibles alternativas a la hora de identificar
alguna situacin problemtica y susceptible a mejora.
4.3.5 Historias de Usuario:

metodolgicamente hablando, las user-stories o fichas de historias de
usuario constituyen el medio principal y ms valioso a la hora de registrar los
requerimientos del usuario (por medio de las entrevistas no estructuradas).
Constituyen la base del desarrollo en Extreme Programming o XP (Kent
Beck, 1996), pues por medio de estas fichas no solo se recopila la
informacin
necesaria
que
permite
definir
la
estructura,
forma
funcionamiento del sistema; sino que tambin se registran las prioridades de

desarrollo para cada modulo del sistema, el riesgo y el esfuerzo asociado a
85
cada una de las tareas de ingeniera que estos producen, as como tambin
son el punto de partida para la ejecucin de las pruebas al sistema
desarrollado en determinadas etapas de la iteracin.
4.4 Tcnicas de Anlisis de Datos:

En el desarrollo de un sistema automatizado que optimice, gestione y
controle las requisiciones de la Empresa Exterran Venezuela en el
departamento de compras y logstica, la informacin o datos recopilados
durante el proceso de observacin directa, entrevistas no estructuradas y
recopilacin bibliogrfica, es en su totalidad del tipo verbal, es decir,
informacin cualitativa que indica las tareas bsicas a seguir para el proceso
de automatizacin (desarrollo del sistema), y no datos numricos con los
cuales construir algn tipo de tabla, grficos o anlisis similar que permita
alcanzar enunciados tericos de alcance ms general.
La informacin recopilada est constituida principalmente por el flujo de

las actividades dentro del rea del trabajo y los requerimientos del usuario
para el sistema a desarrollar, provenientes de la observacin directa de las
actividades que se realizan (para el caso de los flujos de los procesos o
actividades), y de las entrevistas no estructuradas, expresadas en trminos
de historias de usuarios (que permitieron identificar la base de los
requerimientos del usuario).
Dicha informacin cualitativa es de alguna manera cuantificada, es
decir, Extreme Programming o XP (Kent Beck, 1996) propone que sea
analizada, haciendo una revisin detallada de todos los datos obtenidos,
revisando internamente todos los requisitos para el sistema, de manera que
se pueda luego evaluar, todo esto en las user-stories o fichas de historias de
usuario.
86
En las historias de usuario, se valora la envergadura de cada uno de los

requerimientos, identificando sus posibles escenarios de ejecucin como
prioridades para el negocio en cada ficha (alta, media o baja); escenarios que
sirven como base para la elaboracin de las pruebas al sistema.
Igualmente, de acuerdo a los requisitos, se hace una estimacin del

esfuerzo que involucra el desarrollo de cada Historia de Usuario registrndolo
en las fichas. De acuerdo con el grupo desarrollador, se estima que un punto
(01 punto) corresponde una semana ideal de trabajo, sin considerar posibles
incidentes que afecten el trabajo.
Se estableci el riesgo de desarrollo para cada Historia de Usuario,

indicndolos en las fichas (alto, medio o bajo). Tomando en cuenta cualquier
situacin que pueda afectar la estimacin de esfuerzo. Es importante no
sobre-estimar el esfuerzo anticipndose a alguna situacin de riesgo, por lo
que, ambos atributos de la Historia de Usuario son tratados en forma
separada.
4.5 Diseo Operativo
Para la elaboracin del proyecto, se sigui un diseo operativo derivado

del ciclo de vida de la metodologa de desarrollo para sistemas de
informacin llamada Extreme Programming o XP (Kent Beck, 1996), el cul
consta de 6 fases iterativas: Exploracin, Planificacin de la Entrega,
Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto; y cuyas
practicas y actividades bsicas fueron reseadas con anterioridad (Vase
Marco Terico, p. 49-59).
Partiendo de lo anterior, se agruparon las dos primeras fases

metodolgicas de XP en una sola, y as darle paso, a las siguientes cinco
87
(05) fases iterativas (y en parte simultaneas) del proyecto; todas necesarios

para cumplir con los objetivos antes planteados, poniendo en marcha los
valores, principios y prcticas de XP.

En primer lugar se estudi el entorno en el cual se desarroll el
trabajo. Abarcando una etapa de conocimiento y adaptacin al ambiente
adems de la comprensin y familiarizacin con los procesos llevados a cabo
en el mismo. Se realizaron entrevistas que facilitaron el establecimiento de
requisitos, as como la seleccin de un mtodo de evaluacin de personal
acorde y la puntualizacin de criterios claves para ello.
Esta etapa tuvo como objetivo definir las historias de usuario que
estableceran las caractersticas principales de la aplicacin. De esta manera
se explor la posible arquitectura del sistema mediante la construccin de un
prototipo haciendo una revisin documental sobre la metodologa XP, y
estudiando los flujos de los procesos relacionados con el control de
requisiciones en el rea de trabajo. Se plantearn las historias de usuario
agrupndolas por iteraciones, se estableci la prioridad de cada historia de
usuario, se tomaron decisiones acerca del contenido de la primera entrega y
se determin un cronograma en conjunto con el cliente.
Se definir la arquitectura del sistema y las herramientas a utilizar; por

ltimo, se hace un plan de entregas basado en la prioridad para el cliente de
cada requerimiento, en las estimaciones de esfuerzo asociado a la
implementacin de cada historia, y el tiempo de desarrollo involucrado a cada
una de stas. Las prcticas XP fundamentalmente aplicadas en esta fase
fueron el juego de la planificacin, entregas pequeas y el cliente en sitio.
88
4.5.2 Fase II: Produccin y Diseo del proyecto

Llamada fase de iteraciones, se ejecutaron las labores de diseo y
desarrollo de cdigo de los diversos prototipos del sistema de automatizacin
control y gestin, las cuales estn ntimamente ligadas al plan de entrega
antes planteado. Todo el trabajo de la iteracin fue expresado en tareas de
programacin, cada una de ellas es asignada a un programador como
responsable, pero llevadas a cabo, en la medida de lo posible por parejas de
programadores.
Las prcticas XP que resaltaron en sta fase fueron la metfora, diseo

sencillo, entregas pequeas, refactoreo, programacin por parejas, propiedad
colectiva, integracin continua, 40 horas mximo a la semana, cliente en sitio
y estndares definidos de programacin.
El diseo de las pruebas se realiz integrando las pruebas de

aceptacin y unitarias en un solo modelo de tarjeta de prueba de aceptacin,
efectuando de este modo tcnicas manuales de comprobacin de software
por cada iteracin; utilizando guiones de pruebas o pequeas guas de
acciones, que un Tester o probador efectu considerando los resultados que
se van a obtener si el sistema est funcionando correctamente.
En esta fase se realiz un diseo del software en general, incluyendo
la base de datos y los mdulos; pasando luego a la etapa de codificacin
donde se le dio la funcionalidad al sistema, fusionando y conectando los
mdulos entre s y creando los vnculos pertinentes con la base de datos.
Todo lo anterior en iteraciones de acuerdo a las tareas de ingeniera que
fueron establecidas.
Al finalizar esta fase, fue posible comprobar la operatividad del

sistema, en trminos generales, obtenindose una versin final del mismo
para proceder a continuacin con las pruebas respectivas.
89
4.5.3 Fase III: Codificacin y Mantenimiento del proyecto
La Fase III, de mantenimiento; la cual constituye bsicamente el

estado constante en el que se encuentra el proyecto bajo XP. Se ejecuta al
mismo tiempo que la fase II, pues los prototipos que son desarrollados y
probados, son continuamente implementados. Se hicieron actividades de
soporte con el cliente que consisten bsicamente en explicarle las pruebas
realizadas sobre los prototipos y as explicarle el funcionamiento del sistema,
analizando la inclusin de mayor funcionalidad o de nuevos requerimientos.
Para esto se ejecutaron pruebas para detectar errores o fallas que luego
fueron corregidos y depurados. Adems, fue elaborado el manual de usuario,
el cual permitir el adecuado manejo del sistema.
Para la documentacin de esta fase, se consider la muestra de

prototipos de interfaz de usuarios desarrollados por cada tarea de ingeniera
ejecutada y probada, haciendo referencia en cada una de las tarjetas de
tareas de ingenieras mostradas en la fase anterior.
4.6 Cuadro Operativo
En la tabla 5, mostrada a continuacin, se especifica de una forma

ms estructurada la metodologa utilizada
y fases
de la misma que se
utilizaron para alcanzar cada objetivo especfico, as como las actividades

llevadas a cabo para ello.
90
CUADRO OPERATIVO
METODOLOGIA
APLICADA
Extreme
Programming
(XP)
Extreme
Programming
(XP)
Extreme
Programming
(XP)
OBJETIVOS
ESPECFICOS
ACTIVIDADES
Identificar la situacin
problemtica del
Departamento de
compras y logstica y su
entorno.
Determinar cmo fluye la
informacin entre los
distintos departamentos
que forman parte de la
empresa.
1.-Hacer una
observacin general de
las actividades llevadas
a cabo.
2.-Realizar Entrevistas
no estructuradas
3.-Definir Objetivos
4.-Crear Historias de
Usuarios
5.-Realizar un plan de
entrega con las
prioridades del cliente
Elaborar de acuerdo a su
importancia la
construccin del sistema
automatizado
Disear un sistema
automatizado que
controle el proceso de
requisiciones para el
buen funcionamiento del
departamento.
6.-Reuniones con los

usuarios en intervalos
pequeos para
establecer prioridades
7.-Delimitar el alcance
del proyecto, junto con
los objetivos para lograr
el desarrollo del sistema
automatizado
Construir el sistema
automatizado, de manera
ordenada travs de
cdigos que sean
entendibles y fciles de
modificar en un momento
dado evitando
incrementar costos y
gastos innecesarios.
8.-Diseos de Software
Entregas pequeas del
sistema
9.-Codificar e ir
corrigiendo y haciendo
pruebas del sistema
junto con el cliente.
Realizar pruebas
continuamente mediante el
diseo del sistema para la
verificacin de su correcto
desarrollo.
10.-Por ltimo realizar

un manual de usuarios y
correr el programa para
explicarle de manera
detallada al cliente sus
funciones
Tabla 5. Cuadro operativo
91
FASES
1era Fase:
Exploracin y
Planificacin del
Proyecto.
2da fase:
Produccin y
Diseo del
proyecto
3era:
Codificacin y
Mantenimiento
del proyecto
CAPTULO V
RESULTADOS
En este captulo se muestra el proceso de desarrollo del software
basado en la metodologa gil Programacin Extrema (Extreme Programming
o XP), enfocado en el desarrollo del proyecto de pasanta anteriormente
planteado en todos sus pasos y fases a desarrollar.
5.1 El Proyecto
El proyecto consiste en desarrollar un sistema automatizado que

optimice, gestione y controle las requisiciones de la Empresa Exterran
Venezuela en el departamento de compras y logstica.
Partiendo del diseo operativo mostrado anteriormente (Vase Marco

metodolgico, p. 84) en esta investigacin, los resultados productos de la
aplicacin de la metodologa de desarrollo XP, sern mostrados en este
proyecto por medio de tres (03) etapas o fases, Exploracin y Planificacin
del proyecto, Produccin y Diseo del proyecto
y Codificacin y
Mantenimiento del proyecto, incluyendo adems, un anlisis de los beneficios

tangibles e intangibles que trae el sistema enfrentado a su costos de
desarrollo e implementacin.
Esta fase represent oficialmente el comienzo de la ejecucin del

proyecto. Haciendo uso de tcnicas como la observacin directa, entrevistas
no estructuradas y revisin documental, se obtuvo la informacin necesaria
92
para lograr la comprensin y anlisis de la situacin actual en el rea en

estudio.
a. Actividad principal el proceso de requisiciones el cual es respuesta

clave en la situacin econmica y en su buen funcionamiento. Dicho
proceso es el objeto de esta investigacin.
b. Los factores que inciden son diversos, en primer lugar el sistema no

est desarrollado, se lleva a cabo de manera manual, por lo tanto la
seguridad que proporciona es muy baja.
c. Cuya principal caracterstica es el almacenamiento de datos en

carpetas ordenadas por plantas, ofreciendo servicios y procesos a
pocos usuarios.
d. No existe un orden especfico de recibimiento de solicitudes, lo cual es

una de las principales causas de errores y fallas a la hora de ofrecer
reportes y resultados en un tiempo determinado producto del gran
nmero de requisiciones que se realizan.
e. El descontento por parte de la gerencia de la empresa debido a la falta

de control e informacin del proceso actual; trajo como consecuencia
la necesidad de un cambio en el sistema.
f. Por falta de organizacin ocurre retraso, extravo, precisamente por no

llevar un seguimiento completo a dichas requisiciones, lo cual
ocasiona errores en los reportes.
93
g. El cual por ser manual se hace sujeto al acceso de un slo usuario a la

vez,
lo
cual
genera
una
dependencia
y limitacin
para
el
desenvolvimiento del mismo.
h. As mismo dentro del estudio del sistema actual que es utilizado por
los empleados, se observaron los inconvenientes que presenta este
departamento
al
momento
de
realizar
desempeadas con frecuencia de forma
funciones
que
son
manual, que comprende
varios pasos como generar orden de compra, solicitar aprobacin,

generar solicitud interna de compra, contactar a los proveedores
enviando dichas solicitudes por e mail o fax entre otros; lo que implica
un esfuerzo y tiempo muy valioso que puede ser aprovechado en otras
labores.
i. De igual manera el tener que archivar carpetas tras carpetas

organizndolas por planta, es un trabajo engorroso e interminable.
j. Durante el proceso de observacin y familiarizacin con cada una de

las tareas y labores que dentro del rea de trabajo se realizaban; y de
conversar
personas
profundamente (entrevistas no estructuradas) con las

involucradas
en
dichas
actividades
(Gerente
del
Departamento de Compras y logstica, Supervisores, Especialistas del

cumplimiento del proceso de requisiciones, y analistas de soporte); se
logr establecer e identificar el conjunto de tareas que se llevan a
cabo dentro del departamento, sobre todo las relacionadas con el
proceso de requisiciones de dicho departamento.
A continuacin se presentara el diagrama de flujo relacionado con el

proceso de requisiciones que se lleva actualmente:
94
Fuente: Autor 2010.

INICIO
LLENAR
DATOS
PARA OC
GENERAR
OC
SOLICITAR
APROBACION
SI
GENERAR SIC
NO
ENVIAR
DATOS
CREAR
REQUISICIONES
ALMACENAR EN
CARPETAS
MOSTRAR
DATOS
1
FIN
Figura 8. Diagrama de flujo del proceso de requisiciones actual
95
El diagrama de flujo mostrado anteriormente facilit la comprensin de

las actividades realizadas en el departamento, lo que permiti adems la
seleccin de los criterios o factores tomados en cuenta para el desarrollo del
sistema. Debido a que los procesos indicados no sufrieron ningn tipo de
modificacin, ste se mantuvo con validez para el sistema a desarrollar.
5.1.2 Requerimientos del sistema
Luego del breve resumen del sistema actual que se llevaba a cabo en
el departamento de compras y logstica, se logr establecer e identificar el
conjunto de tareas que se llevan a cabo dentro del departamento,
determinando los requisitos necesarios para elaborar el sistema solicitado. La
herramienta que facilit esta actividad de recoleccin fueron las Historias de
Usuario, en las cuales se plasm la informacin obtenida durante las
entrevistas no estructuradas, asignando luego las prioridades y riesgos a
cada una e incluyndolas en la iteracin respectiva.
En esta fase, se empieza la ejecucin del proyecto, estando siempre en

contacto directo con el cliente y con el rea de trabajo, conociendo los
diferentes aspectos involucrados con la ingeniera de software, los
fundamentos de las metodologas giles de desarrollo y los diferentes
aspectos que hay que tener en cuenta para desarrollar un sistema de
automatizacin que optimice gestione y controle las requisiciones del
departamento de compras y logstica. (Vase Marco Referencial, p. 23).
A continuacin se mostrara las presentes tablas de historias de usuario

que utilizaremos en el desarrollo del sistema.
96
5.1.2.1 Requerimientos para la primera iteracin

Para la primera iteracin se mostrara las tablas 6 y 7 con las dos (02)
historias de usuario, las cuales hacen referencia a la informacin almacenada
y vinculada a los empleados del rea.
Fuente: Autor, 2010.
Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
Carga de requirientes
Puntos Estimados:
Administrador
Alta
Iteracin Asignada:
medio
1
Zurilka Bolvar
Descripcin:
Se debe almacenar toda la informacin referente a los requirientes tales como: nombre y
apellido, cdula, cargo, direccin y telfono
Observaciones:
Secuencia lgica de desarrollo: 1.a
Tabla 6. Historia de usuario Nro. 1

Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
carga de usuarios
Puntos Estimados:
Administrador
Alta
Iteracin Asignada:
alto
1
Zurilka Bolvar
Descripcin:
En esta pantalla existe la opcin de poder ingresar a las cuentas de usuarios ver la
informacin de cada uno de ellos crear nuevas cuentas de usuarios, modificarlas, eliminarlas,
cambiar clave desde este enlace.
Observaciones:
Secuencia lgica de desarrollo: 1.b
97
5.1.2.2 Requerimientos para la segunda iteracin
A continuacin se muestran las tablas 8 y 9 de las dos (02) historias

de usuarios que fueron escogidas para la segunda iteracin. Las mismas
abarcan procesos de creacin y edicin de partes y plantas.
Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
Administrador
Carga de plantas
Puntos Estimados:
Media
Iteracin Asignada:
Bajo
2
Zurilka Bolvar
Descripcin:
El administrador puede consultar las plantas, modificarlas, agregar nuevas plantas al
sistema o eliminarlas en caso de que fuese necesario.
Observaciones:

Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
Carga de Partes
Puntos Estimados:
Administrador
Alta
Iteracin Asignada:
Medio
2
Zurilka Bolvar
Descripcin:
El administrador puede consultar, ingresar, modificar y eliminar las partes, ya sea a
travs del sistema o de la base de datos que se encuentra en Access.
Observaciones:
98
5.1.2.3 Requerimientos para la tercera iteracin
En esta iteracin se mostraran las tablas 10 y 11 donde explicaran dos

(02) historias de usuario que conforman el acceso a las creaciones de
Requisiciones, status, prioridades de las mismas luego de estar ingresadas
en el sistema, de igual forma se puede imprimir por las opciones antes
mencionadas.

Historia de Usuario
Nmero:
Usuario:
5
Administrador
Nombre de Historia:
Creacin de Requisiciones
Alta
Alto
Puntos Estimados:
Iteracin Asignada:
4
3
Zurilka Bolvar
Descripcin:
Es en esta parte cuando se procede a utilizar el sistema en su correcta funcionalidad, ya que es
aqu donde se procede a crear todas aquellas requisiciones provenientes de las distintas plantas
de la empresa.
Observaciones:
La informacin que ser ingresada para la creacin de esta requisicin debe estar completamente
correcta ya que de aqu se lleva el seguimiento para los reportes.

Historia de Usuario
Nmero:
Usuario:
6
Administrador
Nombre de Historia:
Modificacin de Requisiciones
Alta
Alto
Puntos Estimados:
Iteracin Asignada:
1
3
Zurilka Bolvar
Descripcin:
Las requisiciones se pueden modificar a travs de este enlace, se puede ver el status de las
mismas, modificarlas y eliminarlas en caso que sea sumamente necesario es por ello que solo el
administrador est autorizado para realizar ese tipo de cambios.
Observaciones:
La requisicin se genera con un cdigo de identificacin nico para poder ser identificada de esta
manera y as se pueda generar reportes de la misma.

99
5.1.2.4 Requerimientos para la cuarta iteracin
Las requisiciones realizadas son el elemento principal en esta

iteracin. Se presenta la tabla 12 y una (01) historias de usuario, donde
se especifican las partes por despachar de las requisiciones creadas.
Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
Cargar partes por despachar
Puntos Estimados:
Administrador
Alta
Iteracin Asignada:
Alto
4
Zurilka Bolvar
Descripcin:
Las partes por despachar de las requisiciones se podrn observar a travs de la opcin
modificar donde se pueda ver dichas partes por el numero de requisiciones, por fechas y de
esta manera si se desea tener un reporte se pueda imprimir.
Observaciones:
Una vez que se encuentren en la pantalla dndole doble clic encima de cada fila de partes por
despachar se puede actualizar su status fcilmente.
5.1.2.5 Requerimientos para la quinta iteracin
En esta etapa se muestra la tabla 13 donde se incluye una (01)

historia de usuario, siguiendo lo anteriormente explicado nos encontramos
con la pantalla de partes despachadas de las requisiciones creadas dicha
historia se presenta a continuacin.
100

Historia de Usuario
Nmero:
Usuario:
Nombre de Historia:
Cargar partes despachadas
Puntos Estimados:
Administrador
Alta
Iteracin Asignada:
Alto
5
Zurilka Bolvar
Descripcin:
Las partes despachadas de las requisiciones se podrn observar a travs de la opcin modificar
donde se pueda ver dichas partes por el numero de requisiciones, por fechas, por orden de
compra y de esta manera si se desea tener un reporte se pueda imprimir.
Observaciones:
Una vez que se encuentren en la pantalla de partes despachadas se ofrece la opcin de poder
imprimir dicha informacin ya sea por nro. de requisicin, por fecha, por orden de compra.

5.2 Herramientas utilizadas para el desarrollo del sistema
Este proceso de manipulacin de requisiciones es una funcin

delicada que deber contar con los mecanismos adecuados, proporcionando
as integridad y seguridad a su contenido.
Del cual se esperar sea el
desarrollo del sistema automatizado de requisiciones; a travs del cual se

lograr crear mejores beneficios para todo el personal que all labora
especialmente al departamento al cual estar asignado dicho sistema;
haciendo uso de algunas herramientas que son necesarias para el buen
desenvolvimiento del programa en el tiempo estipulado.
Por motivos de conocimiento y dominio del cliente se utilizo el lenguaje

de programacin visual Basic 6.0 y Access. A pesar de tener en cuenta que
su respaldo de informacin y almacenamiento de la misma es muy pequea,
por lo que se recomienda guardar informacin cada cierto tiempo para
mantener la base de datos actualizada y de rpida ejecucin.
101
Microsoft Access: Es un programa sistema de gestin de base de datos

relacional creado y modificado por Microsoft para uso personal en pequeas
organizaciones. Es un componente de la suite Microsoft Office, aunque no se
incluye en el paquete "bsico". Una posibilidad adicional es la de crear
ficheros con bases de datos que pueden ser consultados por otros
programas. Dentro de un sistema de informacin, entrara dentro de la
categora de gestin, y no en la de ofimtica, como podra pensarse. Este
programa permite manipular datos en forma de tablas (la cual es la unin de
filas y columnas), realizar clculos complejos con frmulas y funciones,
incluso dibujar distintos tipos de grficas. Access fue utilizado como SGBD
del programa desarrollado.
Visual Basic 6.0: Visual Basic (Visual Studio) constituye un IDE (entorno
de desarrollo integrado o en ingls Integrated Development Enviroment) que
ha sido empaquetado como un programa de aplicacin, es decir, consiste en
un editor de cdigo (programa donde se escribe el cdigo fuente), un
depurador (programa que corrige errores en el cdigo fuente para que pueda
ser bien compilado), un compilador (programa que traduce el cdigo fuente a
lenguaje de mquina), y un constructor de interfaz grfica o GUI (es una
forma de programar en la que no es necesario escribir el cdigo para la parte
grfica del programa, sino que se puede hacer de forma visual).
Se recomend el uso de este lenguaje de programacin por mayor

manipulacin y conocimientos de los usuarios que consiguen en l las
siguientes ventajas.
a. Es un lenguaje.
b. Posee una curva de aprendizaje muy rpida.
c. Integra el diseo e implementacin de formularios de Windows.
102
d. Permite usar con suma facilidad la plataforma de los sistemas

Windows dado que tiene acceso prcticamente total a la API de
Windows incluidas libreras actuales.
e. El cdigo en Visual Basic es fcilmente migrable a otros lenguajes.
f. Es un lenguaje muy extendido por lo que resulta fcil encontrar
informacin, documentacin y fuentes para los proyectos.
5.3 Planes de entregas
Con el objetivo de agilizar las entregas de las versiones del sistema

fue necesaria la elaboracin de una planificacin, tal y como lo sugiere la
Metodologa XP. Para ello se dieron puntajes a las historias de usuario de
acuerdo al tiempo que se estima tardar en desarrollarse, un punto
representa una semana ideal (5 das) de trabajo, sin interrupciones y sin
exceder las ocho horas de trabajo diario.
La metodologa recomienda adems, no tardar ms de tres semanas

para hacer entrega de la primera versin. XP recomienda el desarrollo en
parejas, tal principio no pudo ser cumplido, en adelante se podr demostrar
al observar que los puntos totales son iguales a los de la iteracin, lo cual no
fuese igual si el trabajo se dividiera entre dos personas: el tiempo de
desarrollo sera menor. Sin embargo en algunas ocasiones se considerarn
holguras de tiempo para garantizar la culminacin exitosa de todas y cada
una de las iteraciones.
A continuacin se mostraran las tablas utilizadas en la elaboracin de

los planes de entrega.
5.3.1 Plan de entrega para la primera iteracin
103
Para la entrega de la primera iteracin (ver tabla 14) el plan elaborado

indica que se tard tres semanas en culminar y mostrar al cliente el prototipo,
en este caso el mdulo requirientes que consta de dos historias de usuarios
relacionadas todas entre s.

Historia
Nombre
Usuario
Prioridad Riesgo Puntos
Carga de Requirientes
Administrador
Alta
Medio
Carga de usuarios
Administrador
Alta
Alto
Total
Holgura
Puntos de Trabajo
Tabla 14. Plan de entrega primera iteracin
5.3.2 Plan de entrega para la segunda iteracin
Para la segunda iteracin se estim un aproximado de dos semanas

(ver tabla 15). En esta iteracin se trabajo con las plantas y partes a travs
de dos historias de usuario.
104

Historia
Nombre
3
Carga de plantas
4
Carga de partes
Usuario
Prioridad Riesgo Puntos
Administrador
Media
Bajo
1
Administrador
Alta
Medio
Total
Holgura
Puntos de Trabajo
2
0
2
Tabla 15. Plan de entrega segunda iteracin
5.3.3 Plan de entrega para la tercera iteracin

La entrega de la tercera iteracin consta de dos historias de usuario
que conforman el desarrollo de la creacin de las requisiciones y las
opciones de su modificacin. Esta iteracin es de considerada importancia
para el cliente y representa adems cierto nivel de riesgo al desarrollarla, por
ello y a fin de subsanar o completar tareas faltantes de iteraciones anteriores,
se consider una holgura de un punto, equivalente a una semana,
obteniendo como duracin un total de seis semanas debido al alto riesgo
que representaba una de las historias incluidas (ver tabla 16).
Historia
Nombre
Usuario
Prioridad
Riesgo
Puntos
Creacin de
requisiciones
Modificacin de
Requisiciones
Administrador
Alta
Alto
Administrador
Alta
Alto
Total
Holgura
Puntos de Trabajo
Tabla 16. Plan de entrega tercera iteracin
105
5
1
6
5.3.4 Plan de entrega para la cuarta iteracin

Se estim que la entrega de la cuarta iteracin tardase dos semanas
respecto a la anterior (ver tabla17) a travs de una historia de usuario
obteniendo como producto el mdulo de partes por despachar donde se
permitir la carga de informacin sobre las mismas, consulta y actualizacin.
Historia
Nombre
Usuario
Prioridad
Cargar Partes por

despachar
Administrador
Alta
Riesgo
Puntos
Alto
Total
Holgura
Puntos de Trabajo
2
0
2
Tabla 17. Plan de entrega cuarta iteracin
5.3.5 Plan de entrega para la quinta iteracin

La quinta y ltima iteracin posee una historia de usuario. Esta
iteracin se refiere a las partes despachadas de las requisiciones creadas,
obteniendo como duracin un total de dos semanas (ver tabla 18).

Historia
Nombre
Usuario
Prioridad
Riesgo
Puntos
Cargar Partes
despachadas
Administrador
Alta
Alto
Total
Holgura
Puntos de Trabajo
Tabla 18. Plan de entrega quinta iteracin
106
2
0
2
5.4 Fase II: Produccin y Diseo del proyecto
En esta fase se comenz con el desarrollo del sistema, para ello se utiliz
otra de las herramientas recomendadas por la Metodologa XP: las tareas de
ingeniera, las cuales son obtenidas de las historias de usuario. Se dise
adems, la arquitectura de la base de datos que almacenar la informacin.
Luego, con las tareas de ingeniera y la base de datos ya estructurada fue
posible iniciar con el desarrollo del sistema siguiendo las iteraciones
preestablecidas y realizando modificaciones o mejoras en los casos que sea
necesario.
5.4.1 Tareas de Ingeniera
Para su elaboracin se sigui el plan de entregas propuesto, indicando
por iteracin la manera cmo se desarrollara el sistema. Es preciso acotar
que los puntos estimados de cada tarea provienen de la suma de las
puntuacin
asignada
en
los
planes
de
trabajo
las
historias
correspondientes, lo que establece adems el tiempo de desarrollo;

siguiendo con lo indicado anteriormente, un punto representa una semana de
cinco das con ocho horas diarias cada uno.
Existen tres tipos de tareas posibles: desarrollo, correccin o mejora;

en todas se desarroll y algunas requerirn correcciones y mejoras; para ello
se especifica en negrita el tipo de tarea llevada a cabo.
A continuacin se mostrara las tablas utilizadas para reconocer las
tareas de ingeniera.
5.4.1.1 Tareas de Ingeniera de la primera iteracin

La primera iteracin consta de dos historias de usuario, las cuales se
satisfacieron segn las dos tareas de ingeniera mostradas a continuacin
(ver tabla 19 y 20):
107
Nmero:
Nombre de Tarea:
Tarea de Ingeniera
1 Carga de requirientes
Ingresar Requirientes
Tipo de Tarea:
Desarrollo / Correccin / Mejora
Tiempo de Trabajo:
1 semana
Puntos Estimados:
Autor
Descripcin:
Se cre el formulario donde se ingresarn los datos de los requirientes que laboran en la
empresa. La tabla donde se almacenarn los datos se llam empleados, y consta de los
siguientes campos: nombre (nombre), apellido (apellido), C.I: (cdula de identidad), cargo
(posicin jerrquico que posee en el rea), telfono (nmero telefnico) y direccin (domicilio).
Tabla 19. Tarea de Ingeniera Nro. 1

Tarea de Ingeniera
Nmero:

2 Carga de Usuarios
Nombre de Tarea:
Ingresar usuarios
Tipo de Tarea:
Puntos Estimados:

Tiempo de Trabajo:
2 semana
Autor
Descripcin:
Se cre el formulario donde se ingresarn los datos de los usuarios que laboran en el
departamento de compras y logstica. La tabla donde se almacenarn los datos se
llam clave, consta de los siguientes campos: usuario, clave, Borrar, nuevo, cambiar
clave, ver todos.

5.4.1.2 Tareas de Ingeniera de la segunda iteracin
Fueron elaboradas dos tareas para la iteracin nmero dos, las cuales
fueron desarrolladas paralelas a la anterior de manera exitosa (ver tabla 21)
y (ver tabla 22).
108

Nmero:
Tarea de Ingeniera
3 Carga de plantas
Asignar Plantas
Nombre de Tarea:
Tipo de Tarea:
Tiempo de
1 semana
Trabajo:
Programador Responsable: Autor
Puntos Estimados:
Descripcin:
Los datos se almacenarn en la base de datos a travs de un formulario. La tabla se
llam plantas, y consta de los siguientes campos: nombre, buscar, modificar,
eliminar, guardar, nuevo y actualizar.

Nmero:
Tarea de Ingeniera
4 Carga de partes
Ingresar partes
Nombre de Tarea:
Tipo de Tarea:
Puntos Estimados: 1
Tiempo de Trabajo: 1 semana
Autor
Descripcin:
Los datos se almacenarn en la base de datos a travs de un formulario. La tabla se
llam partes, y consta de los siguientes campos: number part, descripcin, buscar,
nuevo, borrar, editar y actualizar
5.4.1.3 Tareas de Ingeniera de la tercera iteracin
Fueron elaboradas dos tareas para el desarrollo y cumplimiento de los

requerimientos de la tercera iteracin, las cuales obtuvieron un tiempo de
desarrollo de 6 semanas debido a la holgura propuesta en caso de algn
ajuste o mejora, por ser estas historias de usuarios indispensables para el
desarrollo del sistema (ver tabla 23 y 24).
109
Nmero:
Tarea de Ingeniera
5 Creacin de Requisiciones. 6.-codificacion del sistema
a desarrollar. 7.- realizar pruebas al sistema
Desarrollo del sistema de requisiciones
Nombre de Tarea:
Tipo de Tarea:
Puntos Estimados:
4
Tiempo de Trabajo:
4 semana
Autor
Descripcin:
Es en esta tarea donde comienza el desarrollo del sistema como tal, ya que las requisiciones
son la parte esencial del mismo, contiene los siguientes campos: nro. de requisicin, status,
prioridad, ordenado por, fecha, planta, number part, cantidad despachada, cantidad por
despachar, cantidad pendiente ofreciendo la opcin de guardar, imprimir, crear una nueva o
modificarla;
A medida de cada avance que se iba obteniendo con el proyecto se mejoraba y se modificaba
de acuerdo a las prioridades establecidas por el cliente, una vez terminara el desarrollo del
cdigo se proceda a realizar pruebas para minimizar fallas y errores existentes.

Tarea de Ingeniera
Nmero:
Nombre de Tarea:

8 Modificaciones de requisiciones
Modificar requisicin
Tipo de Tarea:
Tiempo de Trabajo:
1 semana
Puntos Estimados:
Autor
Descripcin:
En esta parte se procede a poder modificar dichas requisiciones en caso de ser
necesario.
En este tipo de procesos el acceso a realizar dichos cambios y eliminar lo tiene el
administrador que puede ingresar bajo su clave autorizada de lo contrario ningn tipo de
usuarios no autorizadas al sistema pueden realizar acciones no permitidas.,
110
5.4.1.4 Tareas de Ingeniera de la cuarta iteracin

Para completar la cuarta iteracin se deba tener avanzado en su
totalidad el sistema para poder realizar pruebas acerca de las partes por
despachar de las requisiciones creadas , la cual corresponde a la historia de
usuario nmero 11 (ver tabla 25).

Nmero:
Tarea de Ingeniera
9 Partes por despachar
Partes por despachar
Nombre de Tarea:
Tipo de Tarea:
Puntos Estimados:
2
Tiempo de Trabajo:
2 semana
Autor
Descripcin:
La tabla de partes por despachar est relacionada con cada requisicin creada ya que a
travs de esta tabla se logra tener un reporte de dichas requisiciones por fecha, por nmero,
por orden de compra, entre otras.
5.4.1.5 Tareas de Ingeniera de la quinta iteracin
La quinta y ltima iteracin incluye la historia de usuario que hace

referencia a las partes despachadas y se llevo a cabo de manera
satisfactoria (ver tabla 26).
Nmero:
Tarea de Ingeniera
10 Partes Despachadas
Partes despachadas
Nombre de Tarea:
Tipo de Tarea:
Tiempo de Trabajo:
2 semanas
Autor
Puntos Estimados:
Descripcin:
De igual manera en esta fase se obtiene la pantalla que permite observar las
partes que han sido entregadas en parmetros determinados, pautas y
criterios de acuerdo a su importancia y a su uso.
111
5.5 Diseo de la base de datos
Para la elaboracin de la base de datos se us Microsoft Office

Access 2007. Se crearon seis tablas: empleados, clave, planta, partes,
requisicin, partes por despachar. El contenido de cada una se estableci de
acuerdo a los requerimientos necesitados compuesto por un total de seis
mdulos, incluyendo el principal, a travs de los cuales se accede a otra
serie de sub mdulos y ventanas.
A continuacin se detalla cada mdulo y sus respectivas funciones:
5.5.1 Mdulo Principal

Es la ventana que se apertura para ingresar al sistema, a partir de ste
se puede acceder a los otros cinco mdulos, ingresando el nombre de
usuario correspondiente y la clave.
5.5.2 Mdulo Usuarios

Este mdulo fue dispuesto para acceder a toda la informacin
referente a los empleados del departamento. Al ingresar al mdulo es posible
realizar las siguientes acciones:
a) Agregar: ingresar un nuevo usuario al sistema. Al hacer clic en esta

opcin se abre una ventana nueva, con un formulario a travs del cual se
ingresan los datos del empleado, existe la opcin para mostrar u ocultar los
datos
b) Buscar: hacer una bsqueda especfica a travs de la clave o del
usuario. Esto se realiza a travs de una opcin representada por un botox.
c) Ver todos: se dispone de un botn en el men con estas palabras, a

travs de l se pueden mostrar los usuarios que se encuentran en el sistema
112
del cual se despliega una tabla donde se pueden observar los datos de todos
los usuarios registrados en el sistema.
Luego de hacer una bsqueda o simplemente cliquear en la opcin

Ver todos, se puede ocultar la informacin, borrar, cambiar clave.
5.5.3 Mdulo Requirientes

A travs de este mdulo se tiene acceso a toda la informacin
referente a las personas que estn solicitando dicha requisicin. Se pueden
a) Nuevo: se incluye un botn en el men con esta opcin, a partir de
la cual se visualiza un formulario para ingresar los datos requeridos que son
C.I., Nombre, Cargo, Telfono, Direccin.
b) Buscar: Se procede a buscar por numero de cedula y luego al hacer

clic en el botn de buscar debe aparecer toda la informacin relacionada con
dicha cedula.
c) Ver: mediante esta opcin se abre una tabla donde es posible

observar toda la informacin de los requirientes que se encuentran ya
registrados en el sistema con todos sus datos respectivos.
Adems de las opciones Buscar y Ver se pueden realizar acciones de

eliminar, modificar y actualizar la informacin consultada.
5.5.4 Mdulo Planta

Permite al usuario o administrador consultar las tablas en operacin.
Este mdulo consta de las siguientes opciones:
a) Buscar: esta opcin de bsqueda se realiza a travs del nombre de la

113
planta que se est solicitando.
b) Las plantas pueden ser ingresadas por este modulo como tambin
pueden ser agregadas al sistema por la base de datos en Access.
Al realizar la consulta por cualquiera de los dos mtodos, se permite de
igual manera modificar, actualizar, guardar, y eliminar plantas.
5.5.5 Mdulo Partes

ste maneja toda la informacin que ha sido ingresada acerca de los
materiales o partes que existen para generar las requisiciones. Se pueden
a) Nuevo: se ingresa una nueva parte a la base de datos que se

encuentra respaldada en Access con su respectivo number part y descripcin
el cual se puede acceder desde este mdulo o desde la BD.
b) Buscar: Con solo ingresar el number part le damos clic a buscar y

automticamente aparecer la informacin correspondiente.
Las dems opciones existentes permiten editar, borrar, actualizar y
guardar la informacin.
5.5.6 Mdulo Requisiciones

ste es uno de los mdulos mas grandes ac se encuentran todos los
sub mdulos anteriormente explicados, se maneja toda la informacin que
ha sido ingresada y que forma parte del sistema los cuales son factores o
ndices necesarios para realizar una requisicin. En ella se pueden realizar
las siguientes acciones:
114
a) Nuevo: Se procede a llenar toda la requisicin sin dejar en blanco

ningn tipo de campo, ya que enviara error en el momento de guardar la
informacin.
b) Guardar: Con solo dar clic al botn de guardar automticamente
aparecer un mensaje que anuncia que la requisicin se ha guardado con
xito.
c) Imprimir: En este modulo se pueden imprimir la requisicin que se
desee conociendo siempre los datos y el nmero correcto.
d) Modificar: Esta opcin es de suma utilidad y sirve para cambiar el
status o prioridad a ciertos campos que se encuentren en proceso de
culminacin. A continuacin se presentara el mapa de los mdulos antes
descritos con sus relaciones y respectivas actividades.
Proceso de
requisiciones
Principal
Usuarios
Requirientes
Nuevo
Usuario
Entrar
Salir
Partes
Nueva
Nuevo
Nuevo
Buscar
Clave
Planta
Buscar
Ver todos
Borrar
Cambiar
Clave
Guardar
Ver
Buscar
Requisiciones
Nuevo
Buscar
Guardar
Guardar
Imprimir
Guardar
Modificar
Actualizar
Eliminar
Modificar
Editar
Actualizar
Actualizar
Modificar
Eliminar
Borrar
Salir
Salir
Salir
Salir
Figura 9. Orden de mdulos con sus actividades

115
Para la elaboracin de la base de datos se us Access 7.0. Se crearon

las tablas necesarias, con claves primarias y forneas que permiten
relacionarse entre ellas, lo cual puede observarse en la figura 10 a travs del
modelo relacional de la base de datos
Figura 10. Esquema Relacional de la base de datos
116
5.6 Descripcin de la base de datos
La base de datos del sistema est formada por un conjunto de seis

tablas: empleados, clave, planta, partes, requisicin, partes por despachar.
Cada tabla est compuesta por una serie de campos. Los tipos de datos
almacenados en cada uno de ellos, as como las respectivas claves primarias
y forneas que establecen las relaciones necesarias de cada tabla, son
especificados a continuacin de manera ms precisa. . A continuacin se
presentan las tablas:
Empleados: En esta tabla se almacenan los datos de los empleados del

departamento. Consta de cinco campos, una clave primaria y dos claves
forneas.
Figura 11. Tabla Empleados
117
Fuente: Autor, 2010

Base de Datos: Access 7.0
Nombre BD: Exterran
Nombre de la tabla: Empleados
Propsito: Conocer toda la informacin de los empleados del departamento.
Campo
Tipo
Descripcin
C.i.
Text
Identificador nico del empleado
Nombre
Text
Datos personales del empleado
Cargo
Text
Cargo que posee el empleado en la empresa
Telf
Text
Nmeros telefnicos del empleado
Direccin
Text
Ubicacin personal del empleado
PK
FK
X
X
X
X
X
Clave Primaria
PK_ Empleado:C.i.
Claves Forneas
FK_ Empleados_Clave:
clave fornea con tabla clave usando usuario
FK_Empleados_Requisicin:
clave fornea con tabla Requisicin usando Ordenado
Tabla 27. Descripcin de la tabla empleados
Clave: En esta tabla se almacenan los datos de las personas autorizadas

para ingresar al sistema, deberan ser empleados del departamento o de la
empresa. Consta de dos campos, una clave primaria y posee dos claves
forneas.
Figura 12. Tabla Clave
118
Fuente, Autor, 2010

Nombre BD: Exterran
Nombre de la tabla: Clave
Propsito: Clave necesaria para acceder al sistema de Automatizacin del departamento.
Campo
Tipo
Descripcin
PK
FK
Usuario
Text
Identificador nico del Usuario
X
X
Clave
Text
Clave o password nico y secreto del usuario
X
X
Clave Primaria
PK_Clave: Usuario.
Claves Forneas
FK_Clave_Requisicin:
clave fornea con tabla Requisicin usando Ordenado
FK_Clave_Empleados:
clave fornea con tabla Empleados usando Nombre
Tabla 28. Descripcin de la tabla clave

Planta: En esta tabla se almacenan los datos de las plantas que se
encuentran operando actualmente en la empresa y por ende es de all q se
generan la mayora de las requisiciones. Consta de un campo, una clave
primaria y posee una clave fornea.
Figura 13. Tabla Planta
119
Fuente: Autor, 2010

Nombre BD: Exterran
Nombre de la tabla: Planta
Propsito: Conocer toda las plantas que forman parte de la empresa.
Campo
Tipo
Descripcin
Nombre
Text
Identificador nico de los nombres de cada planta
PK
FK
Clave Primaria
PK_Planta: Nombre
Claves Forneas
FK_Planta_Requisicin:
clave fornea con tabla Requisicin usando Planta
Tabla 29. Descripcin de la tabla planta

Partes: En esta tabla se almacenan todos los datos de las partes o
materiales que se encuentran en stock o en almacn y que son solicitadas
como parte del equipo de repuestos y herramientas para solventar problemas
e inconvenientes en la empresa y en la parte productiva de la misma. Consta
de tres campos, una clave primaria y posee dos claves forneas.
Fuente: Autor, 2010
Figura 14. Tabla Partes
120
Fuente: Autor, 2010

Nombre BD: Exterran
Nombre de la tabla: Partes
Propsito: Conocer toda la informacin de las partes o materiales que se solicitan en las
requisiciones.
Campo
Tipo
Descripcin
PK FK
Numero
Text
Identificador nico de las partes o materiales
X
FabricanteM
Descripcin
Text
Text
Tipo de marca o fabricante de las partes o materiales

La explicacin especifica de las partes o materiales
X
X
Clave Primaria
PK_Partes: Nmero
Claves Forneas
FK_Partes_Requisicin:
clave fornea con tabla Requisicin usando NumeroDRequisicin
FK_Partes_PartesxDespachar:
clave fornea con tabla PartesxDespachar usando NumeroDRequisicin
Tabla 30. Descripcin de la tabla partes
Requisicin: En esta tabla se almacenan todos los datos que deben

contener una planilla de solicitud de requisiciones, todos aquellos datos que
son necesarios para la informacin de la empresa y para su buen
funcionamiento. Consta de siete campos, una clave primaria y posee cinco
claves forneas.
Fuente: Autor, 2010
Figura 15. Tabla Requisicin
121
Fuente: Autor, 2010

Nombre BD: Exterran
Nombre de la tabla: Requisicin
Propsito: Llenar todos los campos que posee la planilla de requisicin ya que son de suma
importancia para un buen resultado.
Campo
Tipo
Descripcin
PK
NumeroDRequisicion
Text
Identificador nico e irrepetible de las
X
requisiciones que se van creando
FechaSolicitada
Text
Es la fecha en que est siendo creada dicha
requisicin
Ordenado
Text
Es la persona que est requiriendo dicha solicitud
FechaRequerida
Text
Es la fecha en la que se estima necesiten los
materiales y que se espera estn disponibles
Planta
Text
Es el lugar o la base de trabajo para donde van a
ir los materiales que estn solicitando
Prioridad
Text
Es la urgencia o importancia con la que estn
necesitando los materiales o partes
Status
Text
Es el estado en el que se encuentra dicha
solicitud desde el momento de su creacin hasta
su culminacin
Clave Primaria
PK_Requisicin: NmeroDRequisicin
Claves Forneas
FK_Requisicin_Clave:
clave fornea con tabla Clave usando Usuario
FK_Requisicin_Planta:
clave fornea con tabla Planta usando Nombre
FK_Requisicin_Empleados:
clave fornea con tabla Empleados usando Nombre
FK_Requisicin_Partes:
clave fornea con tabla Partes usando Numero
FK_Requisicin_PartesxDespachar:
clave fornea con tabla PartesxDespachar usando NumeroDRequisicin
Tabla 31. Descripcin de la tabla requisicin
PartesxDespachar: En esta tabla se almacenan todos los datos de los

materiales o repuestos que no se han despachado identificndose
conjuntamente con el numero de requisiciones, OC, SIC que deben contener
la planilla de solicitud de requisiciones. Consta de diez campos, una clave
primaria y posee dos claves forneas.
122
FK
X
X
X
X
X
X
Fuente: Autor, 2010
Figura 16. Tabla Partesxdespachar

Fuente: Autor, 2010

Nombre BD: Exterran
Nombre de la tabla: PartesxDespachar
Propsito: Conocer toda la informacin de las partes o materiales que no se han despachado en
cada requisicin correspondiente.
Campo
Tipo
Descripcin
PK
FK
NumeroDRequisicion
Text
Identificador nico de las requisiciones
X
Numero
Text
Es el numero de las partes o materiales
X
FechaSolicitada
Text
Es la fecha en la que est siendo creada la
X
requisicin
FechaRequerida
Text
Es la fecha en la que se espera tener a
X
disponibilidad los materiales o partes
FechaSalida
Text
Es la fecha en la que despachan los materiales
X
pendientes
CantidadSolicitada
Text
Es la cantidad total de cierto material
X
CantidadDespachada
Nm
Es la cantidad real que ha sido despachada
X
CantidadPendiente
Text
Es la cantidad pendiente que no se ha
X
despachado
OC
Text
Es la orden que se genera cuando hay
X
materiales pendientes por despachar
SIC
Text
Es la solicitud que se realiza para comprar los
X
materiales faltantes
Clave Primaria
PK_PartesxDespachar: NmeroDRequisicin
Claves Forneas
FK_PartesxDespachar_Requisicin:
clave fornea con tabla Requisicin usando NumeroDRequisicin
FK_PartesxDespachar_Partes:
clave fornea con tabla Partes usando Numero
Tabla 32. Descripcin de la tabla partesxdespachar
123
5.7 Modelo de Casos de Uso del Sistema
Para obtener el resultado deseado por el usuario, el sistema lleva a

cabo una serie de acciones, las cuales pueden ser o no ser dependientes
unas de otras. Para conocer dichas acciones se desarroll un modelo
general de 11 casos de uso (CU) del sistema, y su posterior desglose en
casos de usos ms simples facilit la comprensin de los procesos que se
ejecutan con cada solicitud o clic efectuado por el usuario. A continuacin se
muestra el diagrama general de caso de uso del sistema (ver figura 17).
Fuente: Autor, 2010
Crear usuarios
Crear requirientes
Guardar
<<Include>>
Crear planta
Usuarios del
sistema
(requirientes)
Imprimir
<<Include>>
Validar
usuario
<<Include>>
Crear
prioridad
Nueva
100
<<Include>
>
80
<<Include>>
60
Crear status
40
Administrador
20
del sistema
Este
Oeste
Norte
Modificar
0
1er
trim.
2do
trim.
3er
trim.
4to
trim.
Crear
requisicion
ews
Figura 17. Diagrama de CU general del sistema de requisiciones

124
Fuente: Autor, 2010

Crear nuevo
requirientes
Crear
usuarios
Administrador
usuarios o
requirientes
<<Include>>
Administrador
Cambiar
clave de
usuarios
Borrar
Guardar
Ver todos
<<Include>>
Buscar
<<Include>>
<<Include>>
Validar
usuario
<<Include>>
Ver
Modificar
Validar
usuario
<<Include>>
Guardar
<<Include>>
Eliminar
Buscar
Figura 18. Diagrama de CU del sistema Ingresar usuarios y/o requirientes
Fuente: Autor, 2010

Caso de uso
Actores
Ingresar Usuario y/o Requirientes

Usuario (Administrador del Sistema,
Requirientes y/o pasantes del Sistema.)
Descripcin:
El caso de uso inicia cuando el usuario ingresa al sistema a llenar requisiciones del mdulo
principal, usuarios y requirientes.
Referencias
Precondiciones
El administrador, pasantes ingresa al
mdulo usuario y/o requirientes
Hace clic en las opciones deseadas y
permitidas para su uso.
Curso Bsico
Respuesta del Sistema
Accin del Actor
El sistema enva una notificacin de carga
El usuario ingresa los datos deseados en
satisfactoria.
cualquiera de las dos pantallas
En caso contrario
Cursos Alternos
Si existe algn problema en la carga de los
datos el sistema enva una notificacin
Tabla 33. DCU Ingresar usuarios y/o requirientes
125
Fuente: Autor, 2010

Administrador
usuarios o
requirientes
Administrador
usuarios o
requirientes
Crear nueva
planta
Buscar
Crear nuevas
partes
<<Include>>
Include
Buscar
<<Include>>
Validar
usuario
Actualizar
Actualizar
Guardar
<<Include>>
Guardar
ar
Editar
<<Include>>
<<Include
>>
Eliminar
Eliminar
Figura 19. Diagrama de CU del sistema Ingresar planta y/o partes
Fuente: Autor, 2010

Caso de uso
Actores
Ingresar Planta y/o Partes

Supervisor, Requirientes del Sist.)
Descripcin:
El caso de uso inicia cuando el usuario ingresa al sistema a ingresar plantas y partes a
las requisiciones del mdulo planta y partes.
Referencias
Precondiciones
El administrador ingresa al mdulo planta
y/o partes.
Hace clic en las opciones deseadas para
su uso.
Curso Bsico
Accin del Actor
El usuario ingresa los datos deseados en El sistema enva una notificacin de carga
satisfactoria.
En caso contrario
Cursos Alternos
Tabla 34. DCU Ingresar planta y/o partes
126
Fuente: Autor, 2010

Crear Nueva
Requisicin
Guardar
Include
Administrador
usuarios o
requirientes
Requisicin
por Nro. de
requisicin
Modificar
Requisicin
por partes x
despachar
Validar
usuario
Include
Imprimir
Include
Requisicin
por
prioridad
Requisicin
por partes
despachadas
Requisicin
por fecha
Requisicin
por Status
Figura 20. Diagrama de CU del sistema Ingresar requisiciones
Fuente: Autor, 2010

Caso de uso
Actores
Ingresar Requisiciones
Supervisor, Requirientes del Sist.)
Descripcin:
El caso de uso inicia cuando el usuario ingresa al sistema a ingresar y actualizar los datos
de las requisiciones del mdulo requisiciones.
Referencias
Precondiciones
El administrador y/o pasantes ingresa al
mdulo requisiciones; pero solo el
administrador puede eliminar y modificar
PR o requisiciones.
Hace clic en las opciones deseadas y
permitidas para su uso.
Curso Bsico
Accin del Actor
El usuario ingresa los datos deseados en El sistema enva una notificacin de carga
satisfactoria.
En caso contrario
Cursos Alternos
Tabla 35. DCU Ingresar requisiciones
127
5.8 Diseo y codificacin de interfaces
5.8.1 Interfaces de la primera iteracin

En la primera iteracin se dise y codific el mdulo de requirientes,
as como los formularios y ventanas que lo conforman. A partir de la ventana
principal del mdulo se pueden agregar nuevos requirientes, eliminar de ser
necesario, modificar, Actualizar y ver todos los requirientes existentes en el
sistema, La bsqueda puede realizarse con una consulta personalizada a
travs de la cdula, a partir de la cual se despliega un formulario con los
datos de la consulta.
Figura 21. Interfaz 1. Agregar nuevos Requirientes
128
Es en esta parte donde tenemos la opcin de ver todos los

requirientes que se encuentran ingresados en el sistema con toda la
informacin deseada.
Figura 22. Interfaz 2. Agregar nuevos Requirientes

De igual forma se cre la carga de usuarios a travs de la cual se
pueden buscar los usuarios ingresados al sistema, permite crear nuevos
usuarios, borrar datos existentes cambiar clave y ver todos los usuarios
ingresados mediante un botox que se desplega al hacer clic.
Esta es la opcin que cumple con ciertas restricciones ya que la nica

persona autorizada para crear o eliminar cuentas de usuario debe ser el
administrador del sistema o en su defecto deber autorizar para dicho
cambio o modificaciones.
129
Figura 23. Interfaz 3. Agregar nuevos Usuarios

En esta parte se puede observar mediante un clic que se hace al modulo
operando como podemos ver todos los usuarios creados en el sistema.
Figura 24. Interfaz 4. Agregar nuevos Usuarios

A travs de esta pantalla se procede acceder al sistema introduciendo
130
el nombre de usuario y la clave.

Figura 25. Interfaz 5. Acceder al sistema

5.8.2 Interfaces de la segunda iteracin
A continuacin se muestran las interfaces de la segunda iteracin. Las
mismas abarcan procesos de creacin y edicin de partes y plantas. Las
cuales se presentan a continuacin. Los campos nombre, buscar, guardar,
eliminar, modificar, actualizar y crear nuevas plantas.
Figura 26. Interfaz 6. Carga de Plantas

Se realiza tambin el acceso al modulo de la base de datos de las
partes del sistema, mediante los campos number part, descripcin, buscar,
guardar, borrar, editar, actualizar y crear nuevas partes para poder lograr de
131
esta manera la BD actualizada y respaldada la cual se presenta en la

siguiente pantalla.
Figura 27. Interfaz 7. Carga de Partes

5.8.3 Interfaces de la tercera iteracin
Fueron elaboradas dos tareas para el desarrollo y cumplimiento de los

requerimientos de la tercera iteracin, por ser estas historias de usuarios
indispensables para el desarrollo del sistema. Como primera tarea
establecida anteriormente tenemos la creacin de requisiciones:
Nro. De Requisicin: En este campo se coloca el nmero de requisicin que
132
se va a crear, el cual debe ser nico e irrepetible, para poder identificar a

travs de l las partes de dicha requisicin.
Planta: En este campo se coloca la planta que est solicitando dicha
requisicin.
Prioridad: En este campo se coloca la prioridad con la cual estn solicitando
las partes de dicha requisicin.
Status: En este campo se coloca el status en el que se encuentran las
requisiciones desde el momento en que se crean en el sistema hasta el
momento en que se despachan completamente.
Ordenado por: En este campo se coloca el nombre de la persona que est
solicitando la requisicin.
Fecha Requerida: En este campo de fechas se coloca la fecha en la que el
requiriente estima tener a disposicin los materiales o partes.
Number part: En este campo se busca las partes a solicitar de la requisicin
a travs de la base de datos.
Descripcin: En esta parte se especifica de manera detalla las partes que
se estn solicitando con sus respectivos cdigos, esta informacin se
encuentra en la base de datos.
Cantidad Solicitada: En esta casilla se coloca la cantidad de las partes que
se estn solicitando.
Cantidad Despachada: En esta casilla se coloca la cantidad que se est
despachando, la cual est relacionada con la cantidad solicitada y por ende
no debe ser mayor que la cantidad que se est necesitando.
Cantidad pendiente: Este campo se llena automticamente despus de
pasar por cantidad solicitada y cantidad despachada al darle enter el sistema
automticamente colocara la cantidad correspondiente para ese campo.
Guardar: Este Botn se cre con la finalidad de poder guardar de manera
fcil y rpida todas las requisiciones que se vayan cargando al sistema.
Imprimir: Este Botn se cre con la funcin de poder imprimir directamente
la requisicin una vez que este guardada.
133
Nueva: Este campo tiene la funcin de poder crear nuevas requisiciones sin
mucho esfuerzo.
Modificar: En este campo nos encontramos con el Botox opcionario de
poder modificar muchas partes de las requisiciones entre las que se
encuentran partes despachadas, partes por despachar, status, prioridad
entre muchas otras las cuales sern explicadas en la prxima pantalla.
Figura 28. Interfaz 8. Creacin de Requisiciones
Como segunda tarea establecida en la tercera iteracin, tenemos la

tabla de eliminar PR o Requisicin, son cambios que deben hacerse lo
menos posible para evitar perdida de informacin, donde solo est
134
autorizado el Administrador del sistema, como tambin se puede cambiar

el status de la misma.
Figura 29. Interfaz 9. Modificacin de PR o Requisiciones
5.8.4 Interfaces de la Cuarta iteracin
En esta cuarta fase de iteracin definimos una tarea llamada partes

por despachar la cual se encuentra muy relacionada con las requisiciones;
podemos decir que vienen de la mano a continuacin detallaremos sus
campos y funciones.
Cuando realizamos la prueba vamos entendiendo de manera ms fcil
los mdulos desarrollados y la utilizacin de los mismos nos encontramos en
este caso con la pantalla del Botox modificar que podemos ver en la pantalla
anterior explicada en la parte inferior derecha de la requisicin donde se dar
135
a conocer detalladamente todos y cada uno de los pasos a seguir para

realizar las modificaciones y eliminaciones permitidas.
A continuacin se presentan las siguientes pantallas
las cuales se
encuentran relacionadas entre s:
Buscar: En este campo existen tres opciones para poder buscar de manera
generalizada las cuales son: Requisiciones, Partes por despachar y partes
despachadas; donde cada una de ellas tiene su funcin y utilidad.
Por: Este campo sirve para buscar detalladamente las opciones generales.
Ej. En esta parte se puede buscar: Requisiciones por: Nro de Requisicin,
Fechas, Status, Prioridad y Plantas deben elegir la opcin deseada.
Vacio: En este campo se va a colocar los datos de acuerdo a las opciones

elegidas anteriormente.
Buscar: Como campo indispensable en todo sistema tenemos la opcin

buscar la cual nos ayudara con tan solo darle enter o clic a localizar y
mostrarnos en pantalla los datos solicitados.
Imprimir: Este campo es opcional ac se puede imprimir todos y cada uno

de los datos que sean solicitados en las casillas anteriores con tan solo darle
clic encima de l.
A travs de la pantalla que viene a continuacin se explica

detalladamente las diferentes opciones en este caso buscamos las
requisiciones por nro. De requisiciones y de inmediato se obtiene los
resultados.
136
Figura 30. Interfaz 10. Partes por Despachar

Tambin se puede realizar requisiciones por nro. De requisiciones, por
status, por prioridad, por modificaciones, cambiar status y eliminar PR o
requisiciones con tan solo darle doble clic encima de cada fila de la pantalla;
as mismo se pueden obtener informes y reportes impresos si se necesitar.

A travs de la pantalla que viene a continuacin se explica
detalladamente las diferentes opciones en este caso buscamos las
requisiciones por fechas dependiendo de los parmetros necesitados por el
137
usuario
y de inmediato se obtiene los resultados y su reporte impreso
tambin es vlido en este caso.

A continuacin presentamos la pantalla de Requisiciones por status,

se aplica lo mismo que en las anteriores.
Ac tenemos la pantalla de requisiciones por prioridades
138

De igual forma el sistema est capacitado para imprimir dichos
resultados en caso de ser necesario.
139
En la cuarta iteracin se trato las partes por despachar a continuacin

observaran la pantalla de partes por despachar por nro. De requisiciones.

En la pantalla de Partes por despachar por el nmero de requisicin y
por fechas hacindole doble clic encima de la fila se puede actualizar y
modificar las partes que estn pendientes por entregar y as mantener de
manera ordenado
el sistema para luego al final proceder a guardar los
cambios.
140

Esta pantalla hacer referencia a las partes por despachar por fechas:
141
5.8.5 Interfaces de la Quinta iteracin

En esta ltima iteracin se realizo la tarea de las partes despachadas
las cuales se convierten en una de las ltimas pantallas del sistema. Se
observa las partes despachadas con su O/C cantidades entre otros datos.
Figura 39. Interfaz 19. Partes Despachadas

La presente pantalla hacer referencia a las partes despachadas por
fechas se recuerda que esto si se desea puede ser impreso.
142
Por ltimo podemos obtener las partes despachadas por rdenes de

compra si se desea un seguimiento mas especifico de igual forma estos
resultados pueden imprimirse.
Una vez realizado todo el ingreso o trabajo en dicho sistema se procede

a salir del mismo.
Figura 42. Interfaz 22. Salir del Sistema
143
5.9 Fase III: Codificacin y Mantenimiento del proyecto

En esta fase se desarrollaron las diferentes pruebas realizadas sobre
las versiones desarrolladas en cada iteracin. XP establece dos tipos de
pruebas: las unitarias y las de aceptacin, las primeras son practicadas por el
usuario o cliente a fin de constatar la funcionalidad y cumplimiento de los
requerimientos establecidos en primera instancia; las segundas son
elaboradas por el desarrollador y permiten la deteccin de errores o fallas. A
pesar de esto y gracias a la flexibilidad que brinda la metodologa, se decidi
integrar estos dos tipos de pruebas en una.
6.1 Pruebas de aceptacin
Todas las pruebas fueron documentadas en tarjetas, tal como las
historias de usuario y tareas de ingeniera; se identifican las tareas
involucradas, la descripcin de la accin a ejecutar y el resultado esperado.
A continuacin se muestran las pruebas de aceptacin por iteraciones.
6.1.1 Pruebas de aceptacin de la primera iteracin

Fuente: Autor, 2010
Tarea de Ingeniera:
Cdigo: 1
1 Carga de Requirientes
Nombre: Ingreso, modificacin, eliminacin de requirientes al sistema.
Descripcin: mediante un formulario, el usuario introduce los datos del requiriente, los cuales sern
almacenados en la tabla empleados en los siguientes campos (nombre, apellido C.I, cargo, telfono,
direccin.)
Condiciones de Ejecucin
Todos los campos son obligatorios.
Pasos de ejecucin:
Se ingresa al men principal y luego al mdulo de requirientes.
Se hace clic en la opcin nuevo o si desea puede proceder a llenar directamente todos los campos son
obligatorios.
Los datos como campo identificador es la cedula de identidad, el sistema rechazar datos iguales o
repetidos.
Resultado Esperado:
Se crea exitosamente el registro en la base de datos.
Puede visualizarse el registro al hacer clic en la opcin Ver todo del men.
Evaluacin de la Prueba: Completada 100%
Tabla 36. Caso de Prueba de Aceptacin Nro. 1

144
Fuente: Autor, 2010

Tarea de Ingeniera:
Cdigo: 2
2 Carga de Usuarios
Nombre: Ingreso, modificacin, eliminacin y creacin de nuevas cuentas de usuarios al
sistema.
Descripcin: mediante un formulario, el administrador puede crear nuevas cuentas de
usuarios, modificar, editar, actualizar cambiar clave, eliminar ya que l es el nico
autorizado para hacerlo, los cuales sern almacenados en la tabla clave.
Pasos de ejecucin:
Se ingresa al men principal y luego al mdulo de usuarios
Se hace clic en la opcin nuevo o si desea puede proceder a llenar directamente todos los
campos son obligatorios.
Los datos como campo identificador son el nombre de usuario y el password.
Resultado Esperado:

6.1.2 Pruebas de aceptacin de la segunda iteracin
Fuente: Autor, 2010

Tarea de Ingeniera:
Cdigo: 3
3 Carga de plantas
Nombre: Ingreso, modificacin, eliminacin de plantas al sistema.
Descripcin: mediante un formulario, se procede a realizar los cambios respectivos a las
plantas de la empresa dependiendo del problema se pueden ingresar nuevas plantas,
borrar, editar o actualizar, los cuales sern almacenados en la tabla planta.
Pasos de ejecucin:
Se ingresa al men principal y luego al mdulo de plantas.
Se hace clic en la opcin nuevo o si desea puede proceder a llenar directamente todos
los campos son obligatorios, como es de conocimiento las plantas no se repiten.
Resultado Esperado:

145
Fuente: Autor, 2010

Tarea de Ingeniera:
Cdigo: 4
4 Carga de partes
Nombre: Ingreso, modificacin, eliminacin de partes de materiales a la base de datos
del sistema.
Descripcin: mediante un formulario, se procede a realizar los cambios respectivos a las
partes o materiales se pueden ingresar nuevas partes, borrar, editar o actualizar, los
cuales sern almacenados en la tabla partes.
Pasos de ejecucin:
Se ingresa al men principal y luego al mdulo de partes.
Se hace clic en la opcin nuevo o si desea buscar algn material puede proceder a llenar
directamente todos los campos son obligatorios, como es de conocimiento puede darse
el caso de que existan iguales productos de diferentes marcas o proveedores.
Resultado Esperado:

6.1.3 Pruebas de aceptacin de la tercera iteracin
Fuente: Autor, 2010
Tarea de Ingeniera:
5 Creacin de requisiciones
Cdigo: 5
6.- Codificacin del sistema a desarrollar.
7.- Realizar pruebas al sistema
Nombre: Ingreso, modificacin, eliminacin y desarrollo de requisiciones.
Descripcin: mediante un formulario, se procede a crear la requisicin, con los cambios
respectivos a las diferentes formas de obtener informacin, los cuales sern almacenados
en la tabla requisicin
Pasos de ejecucin:
Se ingresa al men principal y luego al formulario de requisicin.
Se procede a llenar dicha requisicin ordenadamente ya que es de suma importancia y
obligatoria colocar correctamente los datos completos, el numero de requisicin es nico e
irrepetible para evitar de esta manera errores a la hora de los resultados.
Resultado Esperado:
146
Fuente: Autor, 2010

Tarea de Ingeniera:
Cdigo: 6
8. Modificacin de requisiciones
Nombre: Ingreso, modificacin, eliminacin y desarrollo de requisiciones.
Descripcin: mediante un formulario, se procede a crear la requisicin, con los
cambios respectivos a las diferentes formas de obtener informacin, los cuales sern
almacenados en la tabla requisicin
Pasos de ejecucin:
Se ingresa al men principal y luego al formulario de requisicin.
Se procede a llenar dicha requisicin ordenadamente ya que es de suma importancia
y obligatoria colocar correctamente los datos completos, el numero de requisicin es
nico e irrepetible para evitar de esta manera errores a la hora de los resultados.
Resultado Esperado:

6.1.4 Pruebas de aceptacin de la cuarta iteracin
Fuente: Autor, 2010
Tarea de Ingeniera:
Cdigo: 7
9. cargar partes por despachar
Nombre: Ingreso, modificacin, eliminacin y desarrollo de partes por despachar.
Descripcin: mediante la opcin de modificar se puede realizar cambios a las
partes por despachar actualizando su estado a travs de las diferentes maneras con
los cambios respectivos a las diferentes formas de obtener informacin, los cuales
sern almacenados en la tabla partes por despachar
Pasos de ejecucin:
Se ingresa al men de la opcin de modificar y a partir de all se permite buscar
informacin para su buen desarrollo y control del sistema
Resultado Esperado:
147
6.1.5 Pruebas de aceptacin de la Quinta iteracin

Fuente: Autor, 2010
Tarea de Ingeniera:
Cdigo: 8
10. cargar partes despachadas
Nombre: Buscar partes despachadas por numero de requisicin, por fecha y por orden de
comprar.
Descripcin: mediante la opcin de ver los resultados de las partes que se han ido
despachando ya sea buscando a travs de parmetros establecidos con anterioridad dichos
resultados se pueden imprimir.
Pasos de ejecucin:
Se ingresa al men de la opcin de modificar y a partir de all se permite buscar informacin
para su buen desarrollo y control del sistema
Resultado Esperado:
6.2 Requisitos mnimos para instalacin y uso del sistema

A continuacin se muestra una tabla donde se especifican los
caractersticas mnimas que deber tener el computador donde se vaya a
instalar y usar la aplicacin.
Fuente: Autor, 2010
Caracterstica
Requisitos mnimos
Procesador
Pentium IV o superior
Disco Duro
120 GB
Memoria RAM
512MB
Sistema operativo
Windows XP
Software aplicacin
Visual Basic 6.0
Software base de datos
Access 7.0
Tabla 44. Requisitos mnimos para instalacin y uso del sistema
148
6.3 Anlisis Costo Beneficio

El factor econmico es de alta importancia en la realizacin de un
proyecto, independientemente del tipo de investigacin que se realice, por lo
cual se hace necesario un estudio donde se tomen en cuenta costos que
permitan determinar la rentabilidad monetaria de dicho estudio. Partiendo de
esto surge el anlisis costo beneficio, una tcnica a partir de la cual se
identifican los costos necesarios para el desarrollo del proyecto, y aquellos
en los que se incurrir al implementarlo en comparacin con el sistema que
se lleva actualmente para el desarrollo de las mismas actividades (sistema
manual).
6.3.1 Costos de desarrollo
Personal Empleado
El
personal
involucrado
con
el
desarrollo
del
sistema
est
representado por el Jefe del departamento de Compras y Logstica, cuyo

salario es pagado por la empresa, y el autor quien no constituye ningn tipo
de gasto excesivo por representar un cargo de pasante. Debido a que el
empleado es parte del personal contratado de la empresa, ste no recibir
remuneracin adicional por la colaboracin en el desarrollo del sistema, por
lo cual se consider que el costo que representaba sera igual a cero. Estos
costos son detallados en la siguiente tabla.
Fuente: Autor, 2010
Rol
Analista
Asesor
Cargo
Pasante
Admn.
Sistema
Salario
(Bs.)
0,00
9,17
Tiempo
6 meses
180 horas
Total
Costo
(Bs.)
0,00
1.650,60
1.650,60
Tabla 45. Costos del personal
149
Recursos de Hardware y Software
En ninguno de los casos fue necesario incurrir en algn tipo de

equipos o herramientas adicionales a las disponibles en el rea de trabajo.
En cuanto a hardware se cont con computador e impresora. El software
utilizado para el desarrollo de interfaz grfica y codificacin fue Visual Basic
6.0, del cual la empresa posee conocimiento y licencia y el Microsoft office
Access como versin gratuita y manejadora de base de datos.
Materiales y suministros
Estn representados por todos aquellos suministros necesarios para el

desarrollo del proyecto de investigacin. Ac se incluyen las resmas de papel
utilizadas para la impresin de pruebas de reportes, manuales y
documentacin en general; los cartuchos de tinta utilizados, libretas y lpices
para anotaciones, encuadernado de instructivos y discos compactos (ver
tabla 46).

Descripcin
Resmas de papel
Cartuchos de tinta
Libretas
Lpices/Bolgrafos
Encuadernacin
Discos compactos
Cantidad
(unidades)
3
2
4
5
2
4
P. Unit.
(BsF.)
40,00
100,00
4,00
2,00
7,00
3,00
Total
Tabla 46. Costos de materiales y suministros
150
Total
(Bs.F)
120,00
200,00
16,00
10,00
14,00
12,00
372,00
En la tabla 47 se muestra un resumen de los costos generados por el

desarrollo del proyecto.
Concepto
Costos de personal
Costos de hardware y software
Costos de materiales y suministros
Total
Costo
1650,60
0,00
372,00
2022,60
Tabla 47. Costo total de desarrollo
6.3.2 Costos por depreciacin de equipos

La depreciacin es la reduccin anual del valor de una propiedad,
planta o equipo; exceptuando los terrenos, todos los activos fijos sufren de
esta desvalorizacin. Para el uso del sistema ser necesaria la instalacin en
un computador (asignado al Supervisor del departamento de compras y
logstica), adquirido por un monto de Bs. 3.500,00 en el ao 2009. Estimando
una vida til para el mismo de 5 aos y haciendo uso del mtodo de
depreciacin en lnea recta, obtuvo lo siguiente:
En la tabla 48 se muestran los costos por concepto de depreciacin de

activos fijos. Para el ao 2015 se considera depreciacin cero dado que se
consider una vida til de cinco aos para el equipo y el mismo fue adquirido
en el ao 2009.
Fuente: Autor, 2010
Concepto
2010
Depreciacin 700,00
2011
700,00
2012
700,00
2013
700,00
2014
700,00
Tabla 48. Costos por depreciacin de equipos
151
2015
0,00
6.3.3 Costos de operacin
Estos se refieren a aquellos en los que se incurre, tanto al utilizar el

nuevo sistema, como para la ejecucin de las actividades bajo el sistema que
actualmente
se
utiliza.
Mediante
esta
comparacin,
fundamentada
bsicamente en la comparacin de tiempos requeridos para el cumplimiento

de las actividades, fue posible observar cul de los dos sistemas resultaba
ms rentable econmicamente. Las tablas 49 y 50 muestran con
especificidad estos costos.

Costos
Costos de mano de obra mensual para la operacin del sistema
Usuario: Coordinador del Departamento de Compras y Logstica
Sueldo base mensual del usuario
Sueldo diario por hora (8 horas de trabajo)
Tiempo de ejecucin para las transacciones (minutos)
Tiempo de ejecucin para las transacciones (horas)
Das hbiles laborables de trabajo mensuales

25
BsF.
2.500,00
12,5
30
min
156,25
BsF
h
Das
Total de costos de mano de obra mensual de operacin del sistema

(sueldo diario * tiempo de ejecucin en horas * das hbiles laborables)
Costo mensual de papelera
Precio unitario de una resma de papel (500 hojas)
Precio unitario por hoja de papel
Cantidad de unidades de papel utilizadas al mes (aprox.)
Total de costos mensuales de papelera
(precio unitario por hojas * cantidad de hojas usadas al mes)
TOTAL COSTO MENSUAL DE OPERACIN DEL NUEVO SISTEMA
Tabla 49. Costos de operacin del nuevo sistema
152
40,00
0,08
250
20,00
BsF
176,25
BsF
Costos
BsF.
Costos de mano de obra mensual para la operacin del sistema actual

Usuario: Coordinador del departamento de Compras y Logstica
Sueldo base mensual del usuario
Sueldo diario por hora (8 horas de trabajo)
Tiempo de ejecucin para las transacciones (minutos)
120
min
Tiempo de ejecucin para las transacciones (horas)
3
h
Das hbiles laborables de trabajo mensuales
25
Das
Total de costos de mano de obra mensual de operacin del sistema
(sueldo diario * tiempo de ejecucin en horas * das hbiles
laborables)
2.500,00
12,5
937,50
BsF
Costo mensual de papelera

Precio unitario de una resma de papel (500 hojas)
Precio unitario por hoja de papel
Cantidad de unidades de papel utilizadas al mes (aprox.)
40,00
0,08
500
Total de costos mensuales de papelera

(precio unitario por hojas * cantidad de hojas usadas al mes)
40,00
BsF
TOTAL COSTO MENSUAL DE OPERACIN DEL SISTEMA ACTUAL
977,5
BsF
Tabla 50. Costos de operacin del sistema actual

La tabla 51 muestra la comparacin de los costos operacionales de
ambos sistemas, pudiendo observar la diferencia monetaria existente entre
ellos, comprobando as la rentabilidad econmica de la implantacin del
nuevo sistema. Sin embargo, Blank y Tarquin (2004) recomiendan que, una
vez calculados los costos del proyecto y sus beneficios, sea calculado el
ndice B/C (beneficio/costo), mediante el cual se establece si el proyecto es
factible o no.
153

Costos
Mano de obra
Papelera
Total
Sistema actual
937,50
40,00
977,50
Nuevo sistema
156,25
20,00
176,25
Diferencia (beneficios)
781,25
20,00
801,25
Tabla 51. Comparacin de costos de operacin Sistema Actual vs. Nuevo

Sistema
Ya obtenidos los costos, se procedi al clculo del ndice B/C a travs
de la siguiente frmula:
Donde:
Beneficios: Costos de Op. Del Sistema Actual Costos de Op. Del Nuevo
Sistema
Costos: Costo de Desarrollo del Nuevo Sistema
De acuerdo a esto, Blank, L. y Tarquin, A. (2004) establecen que si el

resultado de la relacin es mayor o igual a uno, se considera entonces que el
proyecto es econmicamente factible.
Aplicando la frmula, se obtiene:
Beneficios = 977,50 176,25 = 801,25 = 2,15
% Costos
372,00
372,00
Dado que el resultado obtenido es mayor a 1, es posible decir que el

proyecto posee factibilidad econmica.
6.3.4 Beneficios
Los beneficios que representan el desarrollo y posterior implantacin
del nuevo sistema se pueden calificar como tangibles e intangibles, los
154
primeros hacen mencin a aquellos que pueden ser cuantificables y

demostrados, los segundos no presentan la misma caracterstica, sin
embargo con una observacin y anlisis objetivo pueden ser confirmados.
Dichos
beneficios
tangibles
fueron
cuantificados
anteriormente.
continuacin en la tabla 52 se muestran los mencionados factores.

Beneficios tangibles
Beneficios intangibles
Ahorro de gastos por concepto de

materiales de oficina y transporte,
reduciendo de esta manera gastos
operacionales.
Mayor tiempo de dedicacin a labores
productivas por parte de los usuarios,
al no tener que dedicar tiempo para
las entregas de los informes.
Menores costos de operacin.
Generacin de reportes
automticos.
Garanta de confidencialidad y
seguridad.
Elaboracin de procesos en menor
tiempo.
Disminucin de los tiempos de
respuesta relacionados con las
consultas y envos de informacin.
Mayor satisfaccin del usuario.
Agilizacin y
actividades.
simplicidad
de
Garanta de objetividad en la
automatizacin del sistema.
Disponibilidad inmediata de la
informacin.
El uso correcto del sistema a travs
de los usuarios.
Sistema automatizado de procesos
Mayor conocimiento por parte de los
empleados
Tabla 52. Beneficios tangibles e intangibles
155
CONCLUSIONES
1. A travs del levantamiento de informacin directo que se obtuvo en el
departamento de compras se conoci a profundidad la gran cantidad
de inconvenientes que presentaba el proceso actual de requisiciones,
ya sea por mala manipulacin de informacin, perdida o extravi de
documentos, de rdenes de compra y solicitud de rdenes, surgi
entonces la necesidad de desarrollar un sistema automatizado, que
optimizara, gestionara y controlar el proceso de requisiciones
logrando un orden y seguimiento a cada uno de los procesos
realizados.
2. Con relacin a la informacin entre los distintos departamentos existe

la suficiente comunicacin entre ellos para conocer los procesos a
detalle y sus respectivas evoluciones o inconvenientes que se
suscitaban a la hora de presentar informes o cuentas de las solicitudes
realizadas en un periodo determinado.
3. A travs de las historias de usuario, herramienta brindada por la
metodologa XP, se facilit la recoleccin de la informacin necesaria
para definir los requisitos del sistema, mediante el contacto y
comunicacin
directa
con
el
cliente,
permitiendo
adems
retroalimentacin en la misma. Herramientas desarrolladas para

obtener los puntos importantes del desarrollo del sistema dependiendo
de las necesidades de la empresa.
4. Luego de un estudio de los mtodos existentes se obtuvo como escala
de investigacin la importancia que brindar la automatizacin de este
proceso el mayor control y garantizar la presencia de objetividad en
las evaluaciones sin omitir factores de relevancia, para lo cual adems
156
de seleccionar un mtodo acorde, se debieron elegir los factores

claves que seran tomados en cuenta para ello.
5. El adecuado diseo de la base de datos result fundamental en el

desarrollo del software, ya que el mismo sirvi de base para constituir
la arquitectura del sistema, evitando incrementar costos y gastos
innecesarios. Una aplicacin que adems de abarcar y controlar todo
lo necesitado por el usuario y/o cliente, representa un sistema
bastante completo que adems otorga informacin real y exacta para
ser usada como sustento en la toma de decisiones.
6. El desarrollo de la aplicacin sigui los lineamientos de la metodologa

eXtremme Programming, mejor conocida como XP, la cual fue
modificada a fin de adaptarla a las necesidades del cliente y del
desarrollador, aplicndose hasta su tercera fase (mantenimiento); el
lenguaje de programacin conocido como visual Basic 6.0 que se ha
diseado para facilitar el desarrollo de aplicaciones en un entorno
Como Windows cuya versin 6.0 soportan caractersticas propias de
los lenguajes orientados a objetos, adems de realizar las pruebas
pertinentes para verificar su buen desarrollo.
157
RECOMENDACIONES
1. Se recomienda a la empresa, en primer lugar, implantar el sistema
desarrollado, con el cual se mejoraran de sobremanera las actividades
que se llevan a cabo en el departamento y permitira adems la
agilizacin de actividades ajenas al mismo.
2. Seguidos de un entrenamiento necesario para los usuarios que harn uso

de la aplicacin, suministrndoles los manuales de usuario y hacindoles
saber los beneficios que brinda y la facilidad con la que podrn acceder a
l, todo esto intentado no caer en la resistencia al cambio.
3. Luego de la implantacin se exhorta a ingresar en el sistema la

informacin sobre las requisiciones de cada una de las plantas, a medida
que se registren los datos necesarios como nombres, fechas, nmeros de
requisiciones, los nombres de las plantas. el sistema permitir Mantener
actualizados los datos que es de vital importancia, esto garantizar la
confiabilidad en los reportes emitidos y las evaluaciones realizadas. Es
importante la realizacin de backups o respaldo de informacin peridicos
como medidas preventivas para evitar la prdida de informacin ante
cualquier tipo de accidente.
4.
Por ser un desarrollo automatizado muy completo se puede proponer

ms adelante una extensin del mismo aplicndoles ciertos detalles y
ajustes para cualquier departamento de la misma empresa, incluyendo
mejoras del sistema realizado.
158
BIBLIOGRAFA
Anaya, A. (2007). A propsito de programacin extrema XP. Documento en
lnea disponible en: www.monografias.com/trabajos51/programacionextrema/ programacion-extrema.shtml. [Consulta: Marzo, 2009].
Arias, F. (2002). El Proyecto de Investigacin. (Quinta Edicin). Caracas,

Venezuela: Editorial Episteme.
Arias, F. (1999). El proyecto de Investigacin. (Tercera Edicin). Caracas,

Venezuela: Editorial Episteme.
Barrios, M. (2006). Manual de trabajos de grado de especializacin y

Maestra y tesis Doctorales. (Cuarta Edicin). Editorial FEDUPEL.
Beck, K. (2004). Extreme Programming Explained. Embrace Change.

(Segunda Edicin). Editorial Addison Wesley.
Blank, L. y Tarquin, A. (2000). Ingeniera econmica. (Cuarta Edicin).

Bogot, Colombia: Editorial McGrawHill.
Calero, M. (2003). Una explicacin de la Programacin Extrema (XP).

Documento en lnea disponible en: http://www.avemundi.com/archivos/
XP.doc. [Consulta: Marzo, 2009].
Camps, R.; Casillas, L.; Costal, D.; Ginest, M.; Escofet, C. y Prez, O.
(2005). Bases de Datos. Documento en lnea disponible en:
159
http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-dedatos/bases-de-datos/XP06_M2109_02146.pdf. [Consulta: Mayo, 2009].
Cans, J.; Letelier, P. y Penads, M. (2007). Metodologas giles en el

Desarrollo
de
Software.
Documento
en
lnea
disponible
en:
http://www.willydev.net/descargas/prev/TodoAgil.pdf. [Consulta: Marzo,

2009]
Copias de seguridad Microsoft visual Basic 6.0 (Documento en lnea)

disponible: http://www.desarrolloweb.com/articulos/1180.php. [consulta: 24 de
Abril de 2009].
Chiavenato, I. (2000). Administracin de Recursos Humanos. (Quinta

Edicin). Bogot, Colombia: Editorial McGrawHill.
Echeverry, L. y Delgado, L. (2007). Caso prctico de la metodologa gil XP

al desarrollo de software. Documento en lnea disponible en: http://
biblioteca.utp.edu.co/ tesisdigitales/resumentesis148.html. [Consulta:
Abril, 2009]
Elmasri, R. y Navathe, S. (2000). Sistemas de Bases de Datos. Conceptos

Fundamentales. (Segunda Edicin). Mxico, D.F.: Editorial Addison
Wesley Iberoamericana.
Ferguson, J.; Patterson, B. y Beres, J. (2003). La biblia de C#. Madrid,

Espaa: Editorial Anaya.
Freites, R. (2007). Sistema de Evaluacin del Desempeo para el personal

administrativo del Instituto Pedaggico de Miranda Jos Manuel Siso
Martnez. Trabajo de Grado de Licenciatura en Administracin de
160
Empresas de Servicios Administrativos. Tecana American University

Miami, Florida.
Galaz, S. (s.f.) Ingeniera de Software. Documento en lnea disponible en:

http://www.monografias.com/trabajos5/inso/inso.shtml.
[Consulta:
Mayo, 2009].
Garantn, S. (2008). Sistema para el control y gestin de materiales en el

almacn del Departamento de Mantenimiento y Operacin de
telfonos pblicos de la Cantv del Estado Monagas. Trabajo de Grado
de Ingeniera de Sistemas. Universidad de Oriente Ncleo de
Monagas.
Hernndez, R.; Fernndez, C. y Baptista, P. (2006). Metodologa de la

Investigacin. Mxico, D.F.: Editorial McGrawHill.
Hurtado, J. (2001). El Proyecto de Investigacin Holstica. Caracas,

Venezuela: Editorial Magisterio.
Hurtado, J. (2008). Metodologa de la Investigacin, una comprensin

holstica. Caracas, Venezuela: Ediciones Quirn - Sypal.
Impacto de tecnologas informticas (Documento en lnea). Disponible:

http://www.deltaasesores.com. [visitado 22/Febrero/2009].
Kendall, K. y Kendall, J. (2005). Anlisis y Diseo de Sistemas. (Sexta

Edicin). Mxico, D.F.: Editorial Pearson.
Laudon, K. y Laudon, J. (1996). Administracin de los Sistemas de

Informacin. (Tercera Edicin). Mxico, D.F.: Editorial Pearson.
161
Letelier, P. y Penads, M. (2007). Mtodologas giles para el desarrollo de

software: eXtreme Programming (XP). Documento en lnea disponible
en: http://www.willydev.net/descargas/masyxp.pdf. [Consulta: Marzo,
2009].
Los sistemas de informacin y su importancia para las organizaciones y

empresas.
(documento
en
lnea).
Disponible:
http://www.gestiopolis.com/canales4/mkt/simparalas.htm.[visitado
22/Agosto/2008].
Metodologas giles de desarrollo de software. (s.f.). Documento en lnea

disponible en: (http://www.qualitrain.com.mx/Metodologias-Agiles-deDesarrollo-de-Software -Primera-Parte.html). [Consulta: Marzo, 2009].
Pressman, R. (2002). Ingeniera del software, un enfoque prctico. (Quinta

Edicin). Madrid, Espaa: Editorial McGrawHill.
Rasheed, F. (2006). C# School. Programmers Heaven. (Primera Edicin).
Fuengirola, Espaa: Synchron Data, S.L.
Rodrguez, P. (2009). Desarrollo de una aplicacin web para el control de

gestin de declaraciones sucesorales que permita optimizar procesos
y tiempos de respuesta al rea de sucesiones del SENIAT Sector
Maturn. Trabajo de Grado de Ingeniera de Sistemas. Universidad de
Oriente Ncleo de Monagas.
Sabino, C. (1992). El proceso de Investigacin. Caracas, Venezuela: Editorial

Panapo.
162
Senn, J. (1992). Anlisis y Diseo de Sistemas de Informacin. (Segunda

Edicin). Madrid, Espaa: Editorial McGrawHill.
Sommerville, I. (2005). Ingeniera del Software. (Sptima Edicin). Madrid,

Espaa: Editorial Pearson.
Sosa, M. (2006). Recursos humanos. Documento en lnea disponible en:

http://www.wikilearning.com/curso_gratis/recursos_humanos/15225.
Zabala, R. (2000). Diseo de un Sistema de Informacin Geogrfica sobre

Internet. Tesis de Maestra en Ciencias de la Computacin.
Universidad Autnoma Metropolitana Azcapotzalco. Mxico, D.F.
Documento
en
lnea
disponible
en:
http://www.angelfire.com/
scifi/jzavalar/apuntes/IngSoftware.html. [Consulta: Agosto, 2009].
163

Tes Is Zuri LK A Bolivar

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tes Is Zuri LK A Bolivar

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD DE ORIENTE

DESARROLLO DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE,

Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de

Br: Zurilka A. Bolvar. C.I: 17.420.916

Maturn, Agosto de 2010.

A mis padres Zurilma y Carlos, quienes con su ayuda y apoyo

Junto a ustedes siempre batallando y luchando para que nunca nos

As mismo, dedico este trabajo de manera muy especial a mi hermana,

A mi hermano Marvel Bolvar que a pesar de su corta edad se que le ha

A mi familia por todo el apoyo y por creer en m, este sueo cumplido

A mi cuado Wilmer Gonzlez que me ha ayudado mucho, en los

De igual forma dedico este trabajo de grado a la familia Marn Alfaro

A la Virgen de la Candelaria siempre estas cuidndonos gracias por

A toda mi familia, a mis abuelitas Sobella y Leonides las quiero

A una Familia muy especial que llego a mi vida en el momento donde

A la Universidad de Oriente, por haberme dado la oportunidad de

A todos mis profesores quienes tuvieron la labor de impartirme sus

A todos mis compaeros de la UDO y amigos(as) con quienes compart

A mis asesores la Ing. Nelsy Vvenes, Ing. Desiree Andrico y el Ing.

3.2 Bases Tericas

3.2.5.6 Sistemas para el Control y Gestin de Inventarios

5.5 Diseo de la base de datos

1. Organigrama gerencial de la empresa exterran Maturn EdoMonagas..

3. Proceso de desarrollo de software..

4. Relacin entre elementos del proceso de software.

5. Modelo de desarrollo iterativo incremental....

6. Practicas se refuerzan entre s....

7. Ciclo de vida XP.

8. Diagrama de flujo del proceso de requisiciones actual...

9. Orden de mdulos con sus actividades.

10. Esquema relacional de la base de datos.

11. Tabla empleados.

12. Tabla clave

13. Tabla planta..

14. Tabla partes..

15. Tabla requisiciones.. 121

17. Diagrama de CU general del sistema de requisiciones. 124

20. Diagrama de CU del sistema ingresar requisiciones.

21. Interfaz 1. Agregar nuevos requirientes...

22. Interfaz 2. Agregar nuevos requirientes...

23. Interfaz 3. Agregar nuevos usuarios.

24. Interfaz 4. Agregar nuevos usuarios.

25. Interfaz 5. Acceder al sistema...

26. Interfaz 6. Carga de plantas..

27. Interfaz 7. Carga de partes....

28. Interfaz 8. Creacin de requisiciones...

29. Interfaz 9. Modificacin de PR O requisiciones.....

30. Interfaz 10. Partes por despachar.

31. Interfaz 11. Partes por despachar.

32. Interfaz 12. Partes por despachar.

33. Interfaz 13. Partes por despachar.

34. Interfaz 14. Partes por despachar.

35. Interfaz 15. Partes por despachar.

36. Interfaz 16. Partes por despachar.

37. Interfaz 17. Partes por despachar.

38. Interfaz 18. Partes por despachar.

39. Interfaz 19. Partes despachadas..

40. Interfaz 20. Partes despachadas..

41. Interfaz 21. Partes despachadas..

42. Interfaz 22. Salir del sistema.....

1. Modelo propuesto para una historia de usuario..

2. Modelo propuesto para una prueba de aceptacin

3. Modelo propuesto para una tarea de ingeniera.....