Documents - MX - Desarrollo de Un Sistema para El Control y Gestion de Materiales en El Almacen

UNIVERSIDAD DE ORIENTE
NCLEO DE MONAGAS
PROGRAMA DE INGENIERA DE SISTEMAS
COMISIN DE TRABAJO DE GRADO
MATURN / MONAGAS / VENEZUELA
DESARROLLO DE UN SISTEMA PARA EL CONTROL Y GESTIN DE

MATERIALES EN EL ALMACN DEL DEPARTAMENTO DE
MANTENIMIENTO Y OPERACIN DE TELFONOS PBLICOS DE LA
COMPAA ANNIMA NACIONAL TELFONOS DE VENEZUELA DEL
ESTADO MONAGAS BASADO EN LA METODOLOGA GIL EXTREME
PROGRAMMING XP.
Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de

Grado, como requisito para optar al titulo de Ingeniero de Sistemas.
Br. Simn Garantn C.I: 17.722.691
Asesor Acadmico:
Ing. Jess Chaparro C.I: 4.526.369
Asesor Industrial:
Lic. Alejandro Guerra C.I: 8.350.623
Maturn, Mayo de 2008

ndice General
ndice de Cuadros
ndice de Tablas
ndice de Figuras
ACTA DE EVALUACIN
APROBACIN
RESUMEN
INTRODUCCIN
CAPTULO I
CONTEXTO ORGANIZACIONAL
1.1 Historia de CANTV
1.2 Somos CANTV
1.3 Misin
1.4 Visin
1.5 Objetivos de la organizacin
1.6 Estructura Gerencial Red Zona Monagas
CAPTULO II
EL PROBLEMA Y SUS GENERALIDADES
2.1 Planteamiento del Problema
2.2 Objetivos de la Investigacin
2.2.1 Objetivo General
2.2.2 Objetivos Especficos
2.3 Justificacin de la Investigacin
2.4 Alcance del Problema
2.5 Delimitacin del proyecto
CAPTULO III
ii
MARCO REFERENCIAL
3.1 Antecedentes de la Investigacin
3.2 Bases Tericas
3.2.1 Visin General de la Ingeniera del Software
3.2.2 Mtodos de desarrollo de software
3.2.3 Metodologas giles de desarrollo de software
3.2.4 Programacin Extrema - eXtreme Programming
3.2.5 Control de gestin de Materiales y Almacenes
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.4 Tcnicas de Anlisis de Datos
4.5 Diseo Operativo
CAPTULO V
RESULTADOS
5.1 El Proyecto
5.1.1 Exploracin y Planeamiento
5.1.2 Iteraciones
5.1.3 Productizacin
5.1.4 Mantenimiento
5.1.5 Muerte
5.2 Anlisis Costo Beneficio
CONCLUSIONES
RECOMENDACIONES
BIBLIOGRAFA
3
3
ANEXOS
Anexo 1 - Cdigo del esquema de la base de datos
Anexo 2 - Pantallas y artculos del desarrollo
Anexo 3 Formato hoja de despacho
Anexo 4 Formato Salida de Materiales
Anexo 5 Formato Traslado Especiales
Anexo 6 - Cdigo fuente del sistema (versin digital del proyecto)
ndice de Cuadros
Cuadro n 1: Cuadro operativo metodolgico

Cuadro n 2: Plan de entrega primera iteracin
Cuadro n 3: Plan de entrega segunda iteracin
Cuadro n 4: Plan de entrega tercera iteracin
Cuadro n 5: Plan de entrega cuarta iteracin
Cuadro n 6: Costos de desarrollo e implementacin
Cuadro n 7: Costo mensual de operacin del sistema propuesto
Cuadro n 8: Costo mensual mano de obra del sistema heredado
Cuadro n 9: Costo mensual de operacin del sistema heredado
Cuadro n 10: Comparacin de costos
Cuadro n 11: Resumen beneficios tangibles e intangibles
Cuadro n 12: Beneficios obtenidos por mano de obra mensual
Cuadro n 13: Recuperacin de la Inversin
Cuadro n 14: Relacin de beneficios por uso del sistema
5
5
ndice de Tablas
Tabla 1: Modelo de Historia de Usuario a utilizar

Tabla 2: Modelo propuesto para una prueba de aceptacin
Tabla 3 Modelo propuesto para una tarea de ingeniera
Tabla 4: Historia de Usuario 11
Tabla 17: Historia de Usuario 2 (no incluida)
Tabla 18: Tarea de Ingeniera 1
Tabla 28: Prueba Cdigo 1
Tabla 29: Prueba Cdigo 1.1
vii
ndice de Figuras
Figura 1: Plan Operativo Cantv Gerencia Red Monagas Nov. 2007

Figura 2: Proceso de desarrollo de software
Figura 3: Relacin entre elementos del proceso del software
Figura 4: Modelo de desarrollo iterativo incremental
Figura 5: Prcticas se refuerzan entre s
Figura 6: Ciclo de Vida de XP
Figura 7: Customer story and task card
Figura 8: Modelo de tarjeta CRC
Figura 9: Bosquejo interfaz historia de usuario 11
Figura 14: Arquitectura del Sistema
Figura 15: Esquema de la base de datos
Figura 16: Prototipo de interfaz tarea 1
Figura 17: Prototipos de interfaz tarea 2
8
88
ACTA DE EVALUACIN
En mi carcter de asesor acadmico del trabajo presentado por el

Bachiller Simn P. Garantn L., portador de la cdula de identidad nmero:
17.722.691, para optar al grado acadmico de Ingeniero de Sistemas.
Titulado: DESARROLLO DE UN SISTEMA PARA EL CONTROL Y GESTIN
DE MATERIALES EN EL ALMACN DEL DEPARTAMENTO DE
PROGRAMMING XP, considero que dicho trabajo rene los requerimientos y
mritos suficientes para ser sometido a la evaluacin por parte del jurado
examinador.
En la ciudad de Maturn a los cinco das del mes de marzo de dos mil ocho
Ing. Jess Chaparro

C.I. 4.526.369
9
9
APROBACIN
Quienes suscriben, Miembros del jurado evaluador designados por la

comisin de Trabajos de Grado de la Escuela de Ingeniera de Sistemas de la
Universidad de Oriente Ncleo Monagas, para examinar el Trabajo de Grado
modalidad pasanta presentado por el Bachiller: Simn P. Garantn L.,
portador de la cdula de identidad nmero: 17.722.691. Titulado:
PROGRAMMING XP, el cual es presentado para optar al grado acadmico de
Ingeniero de Sistemas, consideramos que dicho trabajo cumple con los
requisitos exigidos para tal efecto y por tanto lo declaramos:
En la ciudad de Maturn a los _ das del mes de de dos

mil ocho
Miembro Principal
Miembro Principal Miembro Principal
1
01
PROGRAMMING XP.
Autor: Simn P. Garantn L.

C. I: 17.722.691
Asesor Acadmico: Ing. Jess Chaparro
C. I: 4.526.369
RESUMEN
El desarrollo de esta investigacin se realiz en la Compaa Annima
Nacional Telfonos de Venezuela sede Monagas, en el edificio TELECOM
ubicado en la calle Rojas con Avenida Bolvar, de Maturn, con la finalidad de
automatizar los procesos de entrada y salida de materiales en el almacn del
departamento de telefona pblica, la generacin de reportes y rdenes de
compras relacionados a estas tareas y mejorar el almacenamiento y consulta de
dichos reportes. Para ello se elaboraron prototipos de un sistema de software
siguiendo las pautas metodolgicas dictadas por la metodologa gil de
desarrollo llamada XP o eXtreme Programming (Kent Beck, 1996). En el
proyecto, se aplic un diseo de campo, del tipo factible con un nivel
descriptivo. La poblacin estuvo constituida por el personal involucrado
directamente con las tareas de gestin y control de materiales dentro de la
empresa y que interactan directamente con el sistema propuesto, sta al ser
escaza en cantidad se considera como la muestra. Para la recoleccin de datos
se utiliz entrevistas, observacin directa, y la recopilacin documental a travs
de la web. Todos los datos o requerimientos acumulados fueron analizados
utilizando las historias de usuarios, para en base a ellas establecer las tareas
de ingeniera que a su vez dieron paso a las pruebas de los prototipos
desarrollados. De acuerdo a los resultados obtenidos, se pudo verificar que el
sistema propuesto bajo plataforma cliente/servidor, utilizando PHP, MySQL y
Apache, e Internet como estructura bsica, optimiza el tiempo de ejecucin de
las transacciones, aportando mayor operatividad en el control y gestin de los
materiales en el departamento mantenimiento y operacin de telfonos
pblicos, reduciendo los costos, aportando mayor facilidad para la generacin,
almacenamiento y consulta de reportes, dando integridad, eficacia y eficiencia a
las labores de mantenimiento correctivo y preventivo en el rea de trabajo.
Descriptores: Ingeniera de software, metodologas giles, XP, eXtreme

Programming, control y gestin de inventarios, almacn, prototipos, historias de
usuario, tareas de ingeniera, pruebas, materiales
INTRODUCCIN
En un mundo cada vez ms automatizado, en el que surgen continuas

mejoras en lo que a capacidad de procesamiento, consulta y almacenamiento
de datos se refiere; el control de los procesos y la gestin de los mismos a
travs de sistemas de informacin 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 el que continuamente se exigen mejores ndices de
desempeo.
En la actualidad son muchas las empresas e instituciones que acuden a

aplicaciones, o sistemas automatizados para la ejecucin de aquellas tareas
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 dichas actividades. Son las labores y
procesos relacionados con el control del almacn e inventario, las que con
mayor frecuencia necesitan de este tipo de sistemas, dada la importancia a
nivel operativo y de costos que directamente estn relacionadas a ellas, y que
aportan ventajas significativas en lo que a eficiencia, integridad y seguridad se
refiere, si se compara con labores de control no sistematizadas.
Esto trae como consecuencia que continuamente se estn desarrollando

sistemas, que le permitan 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
1
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 operacin y mantenimiento de

telfonos pblicos de la CANTV, surge la necesidad de automatizar los
procesos relacionados con el control y la gestin de los materiales del almacn,
utilizando la ingeniera del software como base fundacional para el desarrollo
del proyecto.
Dicho proyecto est dividido en cinco (05) captulos los cuales 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 los objetivos generales y
especficos del estudio, la justificacin del mismo y su alcance.
Captulo III (Marco Referencial), en esta seccin se exponen los

antecedentes de los trabajos titulados, Metodologas giles en el desarrollo de
software, Desarrollo de un nuevo modelo de estimacin basado en metodologa
gil de desarrollo y generadores de aplicaciones, Diseo de una metodologa
gil de desarrollo de software, Caso prctico de la metodologa gil XP al
desarrollo de software, Diseo de una metodologa gil de desarrollo de
software, entre otros; los cuales presentaban relacin directa con el tema de
trabajo. En este captulo tambin se desarrollan las bases tericas, las bases
legales y la definicin de trminos.
Captulo IV (Marco Metodolgico), en este se desarrolla 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 Capitulo V (Resultados), es donde se muestran los resultados y

conclusiones obtenidas de la investigacin, as como su anlisis costo
beneficio.
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 red zona Monagas.
1.1 Historia de CANTV
La Compaa Annima Nacional Telfonos de Venezuela, conocida como

CANTV, fue fundada en 1930, y hoy en da es el proveedor lder de servicios de
telefona fija, mvil, Internet y servicios de informacin del pas.
La Corporacin CANTV dispone de las tecnologas ms avanzadas, lo

cual, aunado al desarrollo de mejores prcticas gerenciales, ha permitido llevar
adelante una importante transformacin en cobertura y calidad de servicios.
Actualmente, luego de 15 aos de administracin privada, CANTV asume

una nueva etapa que representar importantes retos en sus 77 aos de servicio
a los venezolanos.
No es algo nuevo. A travs de los siglos XX y XXI, CANTV ha pasado por

diferentes facetas que comienzan en 1930 con una concesin otorgada al
venezolano Flix A. Guerrero, pasando por ser empresa pblica entre 1953 y
1991, para luego volver a manos privadas por un lapso de 15 aos, entre 1992
y 2007, ao en que pasa, de nuevo, al control del Estado venezolano.
1930-1952: El inicio de la era del cobre
Esta etapa marca el nacimiento de la CANTV. En los ltimos aos del

gobierno del General Juan Vicente Gmez, el entonces Ministro de Fomento,
Gumersindo Torres, otorga una concesin para construir y explotar una red
telefnica en el Distrito Federal y los llamados Estados de la Unin.
El beneficiario de esta concesin es el comerciante Flix A. Guerrero,

quien luego de haber suscrito la concesin el 4 de abril de 1930, se asocia con
el comerciante Manuel Prez Abascal y el abogado Alfredo Damirn y
constituyen la Compaa Annima Nacional Telfonos de Venezuela (CANTV)
con capital suscrito de Bs. 500.000, de los cuales Guerrero tena 200 acciones y
Damirn y Prez Abascal 150 acciones cada uno.
CANTV fue inscrita formalmente en el Registro de Comercio el 20 de junio

de 1930 y, momento a partir del cual empieza su proceso de crecimiento
adquiriendo las compaas existentes, comprando la Compaa de Telfonos
de Maracaibo, adquiere la Venezuelan Telephone and Electrical Appliances
Company Limited (provea servicios de telfonos desde Caracas hasta las
poblaciones de Puerto Cabello, San Juan de Los Morros, Ocumare del Tuy y
Macuto) y adquiere tambin las instalaciones telefnicas que funcionaban en
Ciudad Bolvar.
Se inicia igualmente la comunicaciones internacionales declarando abierto

el servicio Radiotelefnico Internacional con la cual se establece comunicacin
directa entre Maracay, ciudad de residencia del General Gmez, Miami, en
Estados Unidos, y Europa; y se hace necesario nacionalizar a la empresa para
mantener un nivel operativo a la par del crecimiento del pas.
1953-1991: La Primera Nacionalizacin
En 1953, la nacin adquiere la totalidad de las acciones ordinarias de

CANTV (20.000 en total) por Bs. 29.900.911. El objetivo era crear una nueva
red telefnica independiente y solamente utilizar las partes aprovechables de la
anterior empresa. En este proceso, la compaa Telephone Properties LTD
mantuvo 4.895 acciones que fueron posteriormente adquiridas por el Estado en
1968.
Para 1962, el Ejecutivo Nacional le asigna a CANTV la operacin,

administracin y desarrollo de los servicios de telefona local, larga distancia,
tlex, radio, facsmil, telfonos, transmisin de datos y otras facilidades para la
transmisin de radiodifusin y televisin.
En 1962, el Gobierno Nacional solicita al Fondo Especial de las Naciones

Unidas una ayuda para la creacin del Centro de Estudios para Tcnicos de
Telecomunicaciones (CETT). Ms adelante, las actividades del CETT
comenzaron con la formacin de 400 tcnicos preparados para mantener los
equipos instalados.
El 12 de junio de 1964, CANTV suscribe un contrato con la American

Telephone and Telegraph, (AT&T) y la Transoceanic Communications
Incorporated para la construccin de un cable submarino, que enlazara a
Venezuela con las Islas Vrgenes para establecer comunicaciones confiables y
de calidad con Estados Unidos. Se introduce tambin el Discado Directo
Nacional y la instalacin de las primeras centrales tlex.
En octubre de 1975, se constituye la filial C.A. Venezolana de Guas

(Caveguas). En esta empresa CANTV participa con 40% de las acciones para
ese momento. Ya para 1979, CANTV arriba al primer milln de lneas fijas
instaladas.
Mientras tanto, a nivel internacional, hay un desarrollo intensivo de

innovacin en microelectrnica e informtica que invade el mercado mundial de
suministros. Este hecho afecta la adquisicin de insumos para CANTV, cuya
red se va quedando obsoleta frente a estos cambios tecnolgicos.
En esta etapa, los grandes y ambiciosos proyectos de la empresa no

pueden concretarse por no haberse previsto la infraestructura necesaria. Sin
embargo, se instalan 300.000 nuevas lneas.
En 1990 se vence el Contrato de Concesin que CANTV tiene con el

Estado por 25 aos. En esos tiempos, el Estado atraviesa por una
comprometida situacin financiera para afrontar los requerimientos de los
servicios de telecomunicaciones. El Estado se pronuncia a favor de la
privatizacin de la empresa, otorgando derechos para instalar, desarrollar,
mantener y comercializar el servicio de telecomunicaciones del pas.
El 15 de diciembre de 1991, en acto pblico, se abren los sobres de las

ofertas y resulta ganador el Consorcio VenWorld Telecom, C.A. al ofrecer US$
1.885 millones (US$ 1.085 millones por encima del precio base) por 40% de las
acciones de la empresa.
1991-2007: De Compaa de Telfonos a Corporacin de

Telecomunicaciones
Desde diciembre de 1991 hasta 2007, la Corporacin CANTV ha

transitado por tres lustros de crecimiento, aprendizaje colectivo y desarrollo
continuo que ha definido sus fortalezas actuales. Para comprender la
transformacin protagonizada por la empresa en este lapso, debemos subdividir
este perodo en cuatro grandes etapas:
1992-1997: Expansin y Modernizacin de las Redes
Durante los primeros seis aos como empresa privatizada, se emprende la

expansin y modernizacin de las redes de voz y datos, fijas y mviles; gracias
a la mayor inversin de capital que una empresa privada haya realizado en el
pas: ms de 3.000 millones de dlares.
Se digitaliza ms del 50% de las redes y se lleva a cabo un agresivo plan

de actualizacin y expansin de la planta de telfonos pblicos. Este perodo se
cierra con ms de 70.000 aparatos instalados en toda la nacin.
En el plano del trfico desde y hacia Venezuela con el mundo, ste es el

perodo de mayor impulso a travs de la conexin a los distintos cables de fibra
ptica submarinos y las adecuaciones tecnolgicas a la estacin terrena
"Camatagua", lo cual garantiza a CANTV la comunicacin simultnea digital de
voz, datos y video entre Venezuela y Norteamrica, el Caribe, Suramrica y
Europa.
Otro de los hitos de este perodo es la constitucin de Movilnet el 19 de

mayo de 1992, que en su primer ao alcanz 21.000 clientes, y pronto se
convertira en la primera operadora celular del pas en digitalizar su red y en
1993 se produce el relanzamiento de Caveguas, mediante un cambio
accionario que eleva el control de CANTV a 80%, con un socio estratgico,
Grabados Nacionales del Grupo Capriles.
En noviembre de 1995 nace CANTV Servicios -posteriormente convertida
en Cantv.net, con el propsito de proveer a los clientes servicios de valor
agregado. A la postre ser la insignia de modernizacin de la Corporacin al
impulsar masivamente el servicio de Internet en Venezuela, liderazgo que sigue
consolidando a travs de los aos.
En este perodo se fortalece la privatizacin, luego de que el 22 de

noviembre de 1996 la Repblica de Venezuela colocara en oferta pblica 34,8%
del capital accionario, con lo cual CANTV, como VNT, cotiza sus acciones en la
Bolsa de Nueva York, y como TDV.D en la Bolsa de Valores de Caracas.
1998/2000: Transformacin y Orientacin Comercial
Esta etapa caracteriza la evolucin de la empresa hacia el mercado ante

la inminente apertura total del sector. Se concreta la transformacin de la
estructura organizacional de CANTV y se crean las unidades de negocio con un
nuevo enfoque estratgico: el cliente.
Durante esta etapa, CANTV consolida el proceso de transformacin

anunciado en 1997, a raz de la formulacin de un nuevo plan estratgico. Se
inicia as una nueva ruta, luego de la etapa de evolucin tecnolgica, orientada
hacia el cliente como razn de ser de la empresa, con lo cual la cultura
corporativa da un giro donde el mercado pasa a dominar la dinmica de la
gestin de la organizacin; aprendizaje que se vena gestando con el mpetu
competitivo que ya protagonizaba Movilnet, compaa que siempre estuvo en
competencia.
Dentro del proceso de expansin comercial, se remozan las Oficinas de

Atencin al Cliente, se introducen los Centros de Comunicaciones y las
Taquillas de Paso, entes que adems de recaudar comienzan a ofrecer tambin
productos y servicios de la empresa.
De igual manera, se produce la explosin del segmento prepago en el

mercado celular venezolano, hecho que capitaliza Movilnet para incrementar su
cartera de clientes. En este perodo, se inicia tambin el avance de Internet a
travs de Cantv.net. De la mano de esta filial, nace el producto Acceso a Banda
Ancha (ABA).
2001/2003: Integracin en Competencia
Luego de la aprobacin de la Ley Orgnica de Telecomunicaciones y el

comienzo de la apertura total del mercado de las telecomunicaciones, CANTV,
como Corporacin, evoluciona hacia la integracin de las empresas del grupo.
Este proceso permite ofrecer, en un mercado totalmente en competencia,

productos y servicios integrales, unificar los medios de prepago y fortalecer la
cartera de clientes a travs de una fuerza de ventas comn.
A partir de 2001, CANTV presenta una identidad de marca corporativa

uniforme, smbolo de la comunicacin abierta a travs de un amplio abanico de
productos y servicios, trabajando en conjunto para satisfacer, de forma integral,
las necesidades de los clientes: servicios de voz va la red fija o celular,
transmisin de datos, Internet, ventas para publicaciones y directorios.
2004/2006: Crecimiento Para Abrir Horizontes
Tambin se inici un proceso de integracin de las redes fijas y mviles, lo

que ha permitido ofrecer, por ejemplo, servicios de telefona fija inalmbrica,
10
10
mercado de la banda ancha, de los contenidos y de las transacciones
electrnicas a travs de las redes fijas y mviles. De esta forma, se abre un
nuevo camino para convertir a CANTV en una Corporacin sobresaliente.
Por medio de la instalacin de puertos ABA en la mayora de las centrales

fijas y la capacidad de transmisin de datos a travs de la nueva tecnologa
EvDO, CANTV y Movilnet consolidan un liderazgo absoluto en el mercado de
banda ancha e Internet.
Se inicia adems el Programa Super@ulas, con ms de 90 unidades

instaladas hasta la fecha, que permiten reducir la brecha digital en poblaciones
remotas y ofrecer servicios de Internet a sus alumnos.
CANTV Hoy - 2007
La CANTV del siglo XXI es la insignia de las telecomunicaciones en

Venezuela. CANTV es mucho ms que equipos, redes y sistemas; es una
Corporacin que aglutina diferentes pblicos de inters y que gravita en torno a
una actividad en constante expansin y renovacin tecnolgica.
CANTV sirve a Venezuela con las tecnologas ms avanzadas y dispone

de una red de fibra ptica interurbana de 7.800 kilmetros de longitud a travs
de siete gigantescos anillos que proporcionan redundancia, garantizando, por
tanto, confianza y seguridad en el servicio.
Hoy, CANTV es la empresa preferida de los venezolanos porque a travs

de sus redes fijas, mviles y satelitales, ofrece a los venezolanos la posibilidad
de estar comunicados, en cualquier momento y en cualquier lugar, con servicios
de voz, datos y video de alta confiabilidad y velocidad de respuesta.
La Compaa Annima Nacional Telfonos de Venezuela (CANTV) es la
proveedora lder de servicios integrados de telecomunicaciones en Venezuela.
Para 31 de Mazo de 2007, CANTV contaba con cerca de 3,6 millones de lneas
de acceso fijas en servicio, cerca de 8,2 millones de suscriptores de telefona
mvil y 528 mil suscriptores de banda ancha.
1.2 Somos CANTV
El 22 de mayo de 2007, luego de un proceso de compra de acciones, el

Estado venezolano concret la nacionalizacin de la Compaa Annima
Nacional Telfonos de Venezuela, CANTV.
De esta manera, el gobierno revolucionario ratific su compromiso con el

logro de la Plena Soberana y autodeterminacin, al rescatar una de las
empresas de mayor valor estratgico para el desarrollo del pas y colocarla al
servicio de todos los venezolanos y todas las venezolanas.
La Nueva CANTV declara como principio irrenunciable, que el acceso a

las telecomunicaciones es un derecho humano fundamental. Por ese motivo
llevar los servicios de telecomunicaciones a todos los rincones del territorio
nacional.
La Nueva CANTV ofrecer servicios de telefona bsica a todo centro

poblado con ms de 500 personas, pondr a disposicin de los clientes de
menores recursos una tarifa social a comienzos del ao 2008 y reinvertir el
60% de las ganancias de la empresa en funcin de las necesidades de
telecomunicaciones del pueblo venezolano.
Como empresa del Estado, CANTV impulsar tambin la construccin de
una nueva estructura social en Venezuela en la que priven valores de igualdad,
solidaridad, participacin y corresponsabilidad.
1.3 Misin
Mejoramos la calidad de vida de la gente en Venezuela al proveer

soluciones de comunicaciones que exceden las expectativas de nuestros
clientes.
1.4 Visin
Ser el proveedor preferido de servicios integrales de telecomunicaciones

de Venezuela, y satisfacer plenamente las necesidades especficas de nuestros
clientes, siempre bajo exigentes patrones de tica y rentabilidad.
1.5 Objetivos de la organizacin
1. Democratizar el servicio con justicia social, ampliando la cobertura geogrfica,

incluyendo a todos los segmentos de la poblacin, ofreciendo tarifas justas y
solidarias para promover una competencia ms equitativa.
2. Potenciar la participacin y el Poder Popular, promoviendo la participacin

protagnica de las comunidades organizadas y potenciando la labor de los
Consejos Comunales.
3. Avanzar hacia la soberana tecnolgica apoyando la implantacin del software

libre, impulsando la apropiacin tecnolgica por parte de los ciudadanos y
ciudadanas, respaldando la formacin de talentos nacionales y promoviendo la
sustitucin de importaciones.
4. Apoyar la integracin Nacional e Internacional, expandiendo las fronteras

tecnolgicas de la nacin, bajo el lineamiento del acuerdo ALBA, el proyecto
satelital VENESAT-1, brindando apoyo a los programas sociales y del Estado y
as facilitar la transferencia tecnolgica.
5. Apoyar la seguridad y la defensa integral del Estado proveyendo una red de

comunicaciones segura y de alcance nacional.
6. Crear la concepcin socialista del servicio de telecomunicaciones, abrir

espacios reales para la participacin de las comunidades, colocar las
innovaciones tecnolgicas al servicio del pueblo, convertirse en un motor de
integracin para los pueblos de la regin.
7. Enaltecer los valores de la organizacin, a travs de la unin de los 5 anillos

funcionales principales: el compromiso con la organizacin y su misin, la
orientacin al negocio, al servicio y al cliente; tener una alta responsabilidad por
resultados, poseer adems alto nivel de profesionalismo y contribuir al
desarrollo por medio de una poltica de responsabilidad social comprometida.
Tomado de: http://www.cantv.com.ve/seccion.asp?pid=1&sid=1243
1.6 Estructura Gerencial Red Zona Monagas
Se seala a continuacin el organigrama que muestra la estructura bsica

organizacional de la CANTV Gerencia de Operaciones de Red, Zona Monagas.
Figura 1: Plan Operativo CANTV Gerencia Red Monagas (Astor, 2007)
15
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.
El mayor aporte de los sistemas de informacin es que han cambiado la

forma en que operan las organizaciones actuales en todo el mundo, 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
16
16
mencionar algunos de los que son generalmente aceptados en diversas
clasificaciones.
Pero cuando se habla 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.
La Compaa Annima Nacional Telfonos de Venezuela (CANTV), que

es la principal empresa en servicios de telecomunicaciones del pas, abarcando
reas como la telefona fija, inalmbrica y celular, redes de datos y voz, internet,
pginas amarillas, entre otros servicios; considera con mucho cuidado las
capacidades de sus sistemas de informacin, sobre todo cuando deciden
actualizar sus operaciones con el fin de apoyar sus actividades diarias para
mejorar su funcionamiento y eficacia, agilizando los modos de operacin y
reduciendo los tiempos de respuesta, por lo que continuamente se apoyan en
sistemas automatizados, y en su nivel ms bajo de operaciones, en sistemas de
procesamiento de operaciones o tambin llamados sistemas de informacin
transaccionales para el manejo de los datos.
En el Departamento de Mantenimiento y operacin de Telfonos Pblicos

(en adelante Telfonos Pblicos) de la CANTV Monagas, es el encargado del
mantenimiento preventivo y correctivo de la planta de telefona pblica del
estado, por medio principalmente del despacho de averas, la atencin directa
del equipo, la cancelacin de la avera, el enrutamiento de las fallas, la
gestiones de marcas y eventualidades; pese a los adelantos tecnolgicos que
posee a nivel de operaciones en lo que a programas y sistemas de computacin
se refiere; existen algunos procesos y actividades relacionadas con la gestin y
el control del almacn o deposito que pueden ser tcnicamente fciles de
automatizar y an as se continan realizando en forma manual.
Tal es el caso de la entrada de materiales al almacn, las salidas y

asignacin de recursos a los diferentes tcnicos y rutas, el manejo y control de
inventario, los pedidos de nuevos materiales, la generacin de rdenes de
compra, y los manejos de formatos especiales para el traslado de material y
entrega de equipos los cuales se realizan en forma manual, cuando son
procesos fcilmente automatizables, en un ambiente en el que se cuenta con
todas las herramientas para hacerlo.
El proceso de asignacin diaria de materiales por parte del Supervisor de

Mantenimiento y Operacin de Telefona Pblica o del Tcnico Especialista,
que salen del almacn y que son utilizados por alguno de los 5 tcnicos de ruta
para la ejecucin de las rutinas de mantenimiento preventivo y correctivo de la
planta, no solo es en extremo lento, sino tambin, susceptible a fallos por parte
de la persona encargada de hacer las entregas y llevar los reportes de entrega
o despacho de materiales (Anexo 3), debido a la gran cantidad de informacin
que maneja y el corto tiempo que posee para realizar las entregas.
Igualmente la generacin de las rdenes de compra, la verificacin del

estatus de un producto en el almacn, la presentacin de inventarios, la
elaboracin de ordenes de salida, y autorizaciones de traslado que siguen
formatos especiales (Anexos 4 y 5 respectivamente) y sobre todo el
almacenamiento y consulta de los continuos reportes e informes que generan
todas estas transacciones, son procesos lentos y a los cuales hay que hacer un
seguimiento detallado (por ser realizados en forma manual) para evitar que la
gestin del departamento, sobre todo en lo que aspectos administrativos
(asignacin de recursos por parte de la Gerencia de Operaciones) y desempeo
general (resolucin de averas en los tiempos limites estipulados) se trata, se
vean afectados.
Dichos sntomas son causados directamente por el hecho de ser procesos

en los que se maneja una gran cantidad de informacin en forma no
automatizada, y en los que se trabaja con una elevada cantidad de materiales
(con sus cdigos y descripciones respectivas), con una considerable cantidad
de reportes e informes en los que se almacena toda la informacin
correspondiente a la gestin del almacn (traducido esto en cinco (05) reportes
bsicos, de los cuales cuatro (04) siguen un formato preestablecido, tres (03) de
los cuales son elaborados en el departamento, y sobre los 100 materiales o
insumos). Informacin que debe ser procesada con la mayor rapidez y eficacia
posible durante todos los das en el departamento de trabajo.
El hecho que la gestin y el control del almacn se realice en forma

manual produce toda una serie de inconvenientes que terminan por afectar de
una u otra manera la labor dentro del departamento de telefona pblica, esto se
ve reflejado en el hecho de que continuamente la informacin que es enviada a
la Analista de Soporte Administrativo (quien se encarga entre otra cosas de
tramitar las compras, manejando lo relacionado a los almacenes de la
organizacin a nivel estadal); generada desde la base de las operaciones de
entrada y salida de material del almacn que se realizan rutinariamente,
contiene errores de forma y contenido, por ejemplo, cdigos errados,
descripciones no acorde con el material usado, fechas incorrectas, entre otros.
De la misma manera, a veces la informacin no es enviada a tiempo para

que sea procesada por el analista en cuestin, ya sea porque no se encuentra
correctamente estructurada (en formatos establecidos), porque los reportes no
fueron realizados en el momento de la transaccin, por la prdida de algn
registro dada la gran cantidad que se acumula, y muchas veces por el mismo
descuido del personal del departamento encargado de hacer llegar la
informacin, lo que repercute en el hecho de no poder realizar
reabastecimientos preventivos en almacn de algunos de los productos o
materiales, por lo que muchos de ellos solo son solicitados en ordenes de
compra cuando son necesarios o peor aun cuando ya no existen en el almacn
(ordenes de compra tardas).
Otra de las consecuencias directas de la no automatizacin de los

procesos relacionados con el control y gestin de los materiales, es la dificultad
para el almacenar y consultar los reportes e informes que son generados
diariamente producto del continuo flujo de materiales para las labores de
mantenimiento correctivo y preventivo que el departamento realiza a la planta
de Telfonos Pblicos, estos son almacenados en carpetas y archivados segn
el momento en que son generados, pero an as, lo continuo de la transaccin
hace que se eventualmente se desorganice toda la informacin, lo que
evidentemente hace mas tedioso el proceso de consulta.
Igualmente, en ocasiones por ahorrar tiempo valioso y haciendo la tarea lo

ms rpido posible, los materiales son entregados sin elaborar reportes de
salida, o son recibidos directamente sin llevar anotaciones de la cantidad
asignada segn la orden de compra, por lo que la existencia real en almacn de
materiales, equipos y/o herramientas varia en relacin a los inventarios que son
llevados en el departamento, y los reportes que son entregados al rea de
Anlisis y Soporte Administrativo no reflejan el estatus real de los materiales en
el rea de trabajo.
20
20
Adems los reportes especiales, las autorizaciones para la salida de
material, las rdenes de compra, los traslados especiales de equipos, son
generados, procesados, y pocas veces almacenados en forma correcta, por lo
que las consultas se ven restringidas a la memoria de quien elabor el reporte o
informe en cuestin.
Debido a todos los aspectos antes descritos, 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.
2.2 Objetivos de la Investigacin
2.2.1 Objetivo General
Desarrollar un sistema de informacin transaccional para el control y

gestin de los materiales en el almacn del departamento de mantenimiento y
operacin de telfonos pblicos de la Compaa Annima Nacional Telfonos
de Venezuela (CANTV) del estado Monagas.
2.2.2 Objetivos Especficos
1. Estudiar la situacin actual del entorno y lo relacionado con las metodologas

giles de desarrollo y la gestin de materiales en el almacn del departamento
de operacin y manteniendo de telefona pblica de la CANTV Monagas.
2. Analizar los requerimientos necesarios del sistema propuesto para el control
y gestin de los materiales segn las prioridades del departamento de
operacin y manteniendo de telefona pblica de la CANTV Monagas.
3. Disear los prototipos del sistema basado en tareas de ingeniera iterativas

orientadas a obtener versiones funcionales de la aplicacin que puedan ser
implementadas y evaluadas.
4. Ejecutar pruebas y revisiones de rendimiento a las versiones desarrolladas

para obtener un sistema organizado, manejable y adaptado los requerimientos
antes establecidos en el rea de trabajo.
5. Implementar las diferentes versiones de prototipos del sistema desarrollados

con el fin de incluir nuevos requerimientos o establecer nuevas ideas en lo que
a funcionalidad se refiere.
6. Elaborar la estructura de documentos para el soporte del software

desarrollado para que ste sea fcilmente manejable y ms eficiente dentro del
rea de trabajo.
2.3 Justificacin de la Investigacin
La alternativa de disear y elaborar un sistema computarizado para el

control de almacn e inventario 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 de telfonos pblicos de la CANTV.
Su diseo, 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 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 materiales se evitar que los tiempos de respuesta (en lo que a
disponibilidad de materiales se refiere) afecten la gestin del grupo, pues los
mantenimientos tanto preventivos como correctivos de la planta, 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 las telecomunicaciones pblicas (reparaciones en menos de 8 horas y
mantenimiento preventivo a la totalidad de la planta) y de esta manera
mejorando significativamente los ndices de desempeo del estado Monagas,
en relacin al mantenimiento y operacin de los telfonos pblicos en
comparacin a otros entes operativos.
Indudablemente, lo anterior se traduce, en una serie de beneficios

intangibles, pero muy significativos, pues el sistema propuesto aportar mayor
facilidad a la hora de ejecutar las tareas del departamento relacionadas al
despacho de materiales, 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.5 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 mantenimiento y operacin de telfonos
pblicos de la CANTV Monagas), si no tambin, sobre el flujo de los procesos y
las actividades que se realizan para la gestin y el control de los materiales del
almacn en dicha rea 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 la
administracin de almacenes.
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 transaccional para el control y gestin
de los materiales del almacn que funciona bajo una plataforma de
cliente/servidor (Apache), compilado en lenguaje libre PHP y JavaScript
(middleware), con MySQL como sistema de gestin de la base de datos
relacional, accediendo a el mismo por medio de un Navegador Web (Mozilla
Firefox); todas stas estructuras libres de desarrollo.
A travs de esta investigacin, se logr implementar prototipos de un

sistema para el control y gestin de los materiales del almacn del
Monagas, que cumple en forma eficiente y efectiva con los requerimientos
existentes dentro del rea de trabajo, contribuyendo en trminos generales al
las labores de mantenimiento correctivo y preventivo que en el rea de trabajo
se realizan, labores stas, que constituyen los objetivos primordiales del
departamento.
2.6 Delimitacin del proyecto
El estudio se desarroll en el seno del Departamento de Mantenimiento y

Operacin de Telfonos Pblicos de la CANTV Monagas, ubicado en la calle
Rojas cruce con Avenida Bolvar de Maturn, Edificio Telecom, Piso 1, mientras
se realizan las labores de Tcnico Especialista de Telfonos Pblicos, 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 quince (15) de
Junio de 2007 hasta el quince (15) de Febrero de 2008. (15/06/2007
15/02/2008)
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 conocimientos, a partir de la cual
se derivan los planteamientos del investigador para el diseo de un sistema
para el control y gestin de materiales en el departamento de mantenimiento y
operacin de telfonos pblicos de la CANTV en el estado 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.
Inicialmente, en el mbito internacional se recopil la investigacin

realizada por Cans, J., Letelier, P y Penads M (2007), para la Universidad
Politcnica de Valencia, en la regin de la Comunidad Valenciana, Espaa,
titulada Metodologas giles en el desarrollo de software, donde los autores
expresaron que el desarrollo de software no es una tarea fcil; y prueba de ello
es que existen numerosas propuestas metodolgicas que inciden en distintas
dimensiones del proceso de desarrollo.
Por una parte, se tienen aquellas propuestas ms tradicionales que se
centran especialmente en el control del proceso, estableciendo rigurosamente
las actividades involucradas, los artefactos que se deben producir, as como las
herramientas y notaciones que se usarn. Pero para cierto tipo de proyectos,
dichas propuestas hacen que el proceso de desarrollo sea ms complejo,
limitando la propia habilidad del equipo para llevar a cabo el proyecto.
Otra aproximacin sugerida por los autores, es centrarse en otras

dimensiones, como por ejemplo el factor humano o el producto software. 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
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.
El aporte de este trabajo se presenta resumidamente en la evaluacin del

contexto en el que surgen las metodologas giles, sus valores, principios y
comparacin con las diferentes metodologas tradicionales; donde adems se
describen brevemente las principales propuestas de desarrollo de software,
especialmente enmarcadas en la Programacin Extrema (eXtreme
Programming o XP), la metodologa gil ms popular en la actualidad.
Siguiendo en el mbito mundial, se compil el estudio desarrollado por

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. El proceso inici en una revisin bibliogrfica de la metodologa y
otros aspectos relacionados a sta. A continuacin se contact con un posible
cliente al cual se le hizo una presentacin de los objetivos inciales del proyecto.
Una vez acorados todos los detalles se procedi a su ejecucin, al final de la
cual se redact el informe definitivo documentando la experiencia.
El aporte de esta investigacin se encuentra en la parte central del

documento, correspondiente a cada una de las fases de desarrollo en XP:
planeacin, diseo, codificacin y pruebas. En cada uno de estos captulos se
discute como se aplicaron los aspectos de la correspondiente etapa al proyecto,
as como el resultado obtenido.
De la misma manera, se identific el estudio realizado por Goncalves, M.

(2005), en su Trabajo de Diploma para la Universidad de Morn, en la ciudad de
Buenos Aires, Argentina, titulado Desarrollo de un nuevo modelo de
estimacin basado en metodologa gil de desarrollo y generadores de
aplicaciones, donde luego de un previo anlisis de los mtodos giles ms
reconocidos del mercado, se detect la carencia de herramientas de estimacin
de esfuerzo de desarrollo y de estimacin de recursos necesarios que se
encuentren ligadas a stos; es decir, existe en el mercado una importante
cantidad de modelos y herramientas para estimar esfuerzo de desarrollo, pero
no se para modelos basados en metodologas giles y en herramientas case.
Por ello, este trabajo abord la definicin de un modelo que permitiera

estimar esfuerzos y recursos para desarrollo de software construido con
herramientas case de ltima generacin, que se encuentren enmarcados bajo el
modelo gil definido por la tesis mencionada. 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 permite verificar que

actualmente es un desafo constante para las empresas de desarrollo de
software convertirse en un entidad seria que logre la confianza de sus clientes,
donde para ellos el objetivo de cumplir con los plazos establecidos, comprender
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.
En este mismo contexto, se recopil la investigacin desarrollada por

Schenone, M. (2004), en su Tesis de Grado en Ingeniera en Informtica para la
Facultad de Ingeniera de la Universidad de Buenos Aires, en la ciudad de
Buenos Aires, Argentina, titulada Diseo de una metodologa gil de
desarrollo de software, quien seal que esta tesis tuvo como propsito la
construccin de una metodologa gil de desarrollo de software, la cual utiliza
UML como notacin; que si bien podr ser empleada en proyectos de distinto
tamao y complejidad, su aplicacin tendr como objetivo proyectos de
pequea escala y riesgo limitado. Tambin ser independiente del lenguaje o la
arquitectura utilizada, as como del tipo de software que se est construyendo.
Para desarrollar esta metodologa se comenz por un relevamiento de las

metodologas y notaciones actualmente empleadas (Rational Unified Process,
UML, SCRUM, OPEN, Extreme Programming, entre otras), con un posterior
refinamiento de las mismas y el desarrollo paulatino de un proceso que
incorpore las mejores y ms avanzadas prcticas existentes en cada etapa del
desarrollo. Finalmente, se describi la realizacin de dos casos prcticos
resueltos con la metodologa propuesta. El primer caso prctico estuvo basado
en un sistema de integracin de servicios para ONGs; mientras que el
segundo, en un sistema de administracin de recursos de hardware y software.
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.
En el contexto nacional se verific la preparacin de la investigacin

desarrollada por 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 cada una de 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 basado en Tecnologa Web; siendo sus caractersticas principales
30
30
que garantice el control, la coordinacin y desarrollo ptimo de esta etapa del
flujo operacional y que al mismo tiempo pueda ser lo suficientemente flexible y
modular para que pueda integrarse a las siguientes 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
cdigo y cuyo principal objetivo es la satisfaccin del cliente y potenciar al
mximo el trabajo en grupo.
El principal aporte de este estudio se manifiesta en que con la

implantacin de este sistema, es posible contar con una aplicacin
automatizada que permita a cada uno de los usuarios pertenecientes a cada
rea, administrar y controlar bajo un ambiente Web la generacin de nuevas
solicitudes de servicios, 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 la empresa, garantizando el cumplimiento de los
procesos definidos en cada una de las etapas del su flujo operacional;
permitiendo as la ejecucin correcta, ptima e integrada de los procesos.
Finalmente, en el mbito regional no fue posible recopilar datos de

estudios basados en la metodologa eXtreme Programming (XP) o en otra de
las diferentes metodologas de desarrollo gil de software, que hayan sido
realizados en las universidades presentes en el oriente venezolano. Del mismo
modo, los antecedentes anteriormente reseados no presentan en su
generalidad el tipo de estudio, metodologa empleada o conclusiones concretas.
Sin embargo, los mismos son considerados como un recurso valioso a efectos
del desarrollo de 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 de
proyecto planteado.
3.2.1 Visin General de la Ingeniera del Software
3.2.1.1 Ingeniera del 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 del 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 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).
3.2.1.4 Situacin Actual de la Ingeniera del 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 OO.
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 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
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.6 El proceso de desarrollo del 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 2, se muestra el proceso de desarrollo de software
Requisitos nuevos Sistema nuevo

o modificados Proceso de Desarrollo o modificado
de Software
Figura 2: proceso de desarrollo de software. (Jacaboson y otros, 2000).
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. 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 3 se muestran los elementos de un proceso de desarrollo de

software y sus relaciones:
No se puede mostrar la imagen. Puede que su equ po
i no tenga suf ci ente
i memor ai para abr ri al magen
i o que sta est daada. Re ni ci ei e equ
l po
i y , a cont ni uac n,
i abra e arc
l h vi o de nu ev o. S si gue
i aparec endo
i al x ro a,j puede que tenga que bor rar a ma
l i gen e nsertar
i a lde nuev o.
Figura 3: Relacin entre elementos del proceso del software (Letelier, 2002)
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.7 Modelos de procesos del 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
combinacin del Modelo de Cascada y Modelo Evolutivo. La figura 4 muestra el
modelo del desarrollo incremental.
No se puede mostrar la imagen. Puede que su equ po

i no tenga suf ci ente
i memor ai para abr ri al magen
i o que sta est daada. Re ni ci ei e equ
l po
i y , a cont nuac
i n,
i abra e arc
l h vi o de nu ev o. S si gue
i aparec endo
i al x ro a,
j puede que tenga que bor rar a lmagen
i e nsertar
i a lde nuev o.
Figura 4: Modelo de desarrollo iterativo incremental. (Goncalves, 2005)

El modelo Prototipado, 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
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.
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
40
40
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.4 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
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.9 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 esta 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
mediante procesos altamente definidos se iba a lograr obtener software en
tiempo, costo y con la requerida calidad.
Surgen cuando las metodologas tradicionales mas 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.
Eme 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.
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.
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.

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

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); y
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).
Su principal obra es de Cockbun, A. Agile Software Development.
Addison-Wesley. (2001); y su pgina oficial es: www.crystalmethodologies.org.
3.2.3.3.5 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 web official 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
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
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 mas simple es el sistema menos hay que comunicar de
el.
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.
50
50
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:
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.
3.2.4.5 Los Principios de XP
Hay 5 principios fundamentales y 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.
e) 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

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
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
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 5
(Letelier, 2003), donde una lnea entre dos prcticas significa que las dos
prcticas se refuerzan entre s.
Figura 5: Prcticas se refuerzan entre s (Letelier, 2003)
3.2.4.8 El Proceso de XP Ciclo de Vida
El ciclo de vida de XP se enfatiza en el carcter inte activo e incremental

del desarrollo. Segn Anaya y Plaza (2007, p. 4) una iteracin de desarrollo es
de funcionalidades
un periodo de tiempo en el que se realiza un conjunto
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

iteracin incluye diseo, codificacin y pruebas, fases
desarrollo y cada
superpuestas de tal manera que no se separen en el tiempo.

La figura 8 muestra las fases en las que se subdivide el ciclo de vida XP.
Figura 8: Ciclo de Vida de XP (Anaya y Plaza, 2007)
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, y 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.
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 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
necesario para el proyecto y el Gestor (Big boss), cuya labor esencial es de
coordinacin.
3.2.4.11 Historias de Usuario y dems artefactos XP
Empezar con lo que considero la herramienta bsica para la aplicacin

de XP, las Historias de Usuario.
60
60
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 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.
Respecto de la informacin contenida en la historia de usuario, existen

varias plantillas sugeridas pero no existe un consenso al respecto. En muchos
casos slo se propone utilizar un nombre y una descripcin o slo una
descripcin, ms quizs una estimacin de esfuerzo en das. Beck (2004, p. 73)
presenta un ejemplo de ficha (customer story and task card figura 9)
Figura 7: Customer story and task card (historia de usuario) (Beck, 2000)
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. Jeffries (2001)
No hay que preocuparse si en un principio no se identifican todas las

historias de usuario. Al comienzo de cada iteracin estarn registrados los
cambios en las historias de usuario y segn eso se planificar la siguiente
iteracin. Las historias de usuario son descompuestas en tareas de
programacin y asignadas a los programadores para ser implementadas
durante una iteracin. El modelo de historia de usuario a utilizar es el propuesto
por Letelier (2003), el cual se muestra en la Tabla 1, a continuacin:
Historia de Usuario
Nmero:
Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre):
Usuario:
Prioridad en Negocio:
(Alta / Media / Baja)
Riesgo en Desarrollo:
(Alto / Medio / Bajo)
Descripcin:
Observaciones:
Tabla 1: Modelo de Historia de Usuario a utilizar (Letelier y otros, 2003)
Las 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.
Caso de Prueba de Aceptacin
Cdigo:
Nombre:
Descripcin:
Condiciones de Ejecucin:
Entrada / Pasos de ejecucin:
Resultado Esperado:
Evaluacin de la Prueba:
Tabla2: Modelo propuesto para una prueba de aceptacin. (Letelier y otros,
2003)
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. Dichas tareas siguen el formato presentado en la Tabla 3.
Tarea de Ingeniera
Nmero Tarea:
Nombre Tarea:
Tipo de Tarea :
Desarrollo / Correccin / Mejora / Otra
(especificar)
Fecha Inicio:
Programador Responsable:
Descripcin:
Tabla 3 Modelo propuesto para una tarea de ingeniera (Letelier y otros,
2003).
En la tarjetas de tareas de ingeniera, y siguiendo el formato arriba
los desarrolladores junto con el manager del proyecto y
descrito (Tabla 3);
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.
Por ultimo, se suele utilizar opcionalmente las Tarjetas CRC (Clase -

Responsabilidad Colaborador) como artefacto dentro de XP. 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.
Figura 10 Modelo de tarjeta CRC (Anaya y Plaza, 2007)
Una clase es cualquier persona, cosa, evento, concepto, pantalla o

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
llevar a cabo sus
dems clases con las que trabaja en conjunto para
responsabilidades.
3.2.5 Control de gestin de materiales y almacenes
3.2.5.1 Administracin de los Almacenes e Inventarios
Un almacn es el lugar o espacio fsico en que se depositan las materias

primas, el producto semiterminado, o el producto terminado a la espera de ser
transferido. Sirve como centro regulador del flujo de mercancas entre la
disponibilidad y la necesidad de fabricantes, comerciantes y consumidores.
(http://es.wikipedia.org/wiki/Almac%C3%A9n)
Los Inventarios en cambio, son bienes tangibles que se tienen para la

venta en el curso ordinario del negocio o para ser consumidos en la produccin
de bienes o servicios para su posterior comercializacin Amat Salas (2001, p.
17). As, los inventarios comprenden, adems de las materias primas, productos
en proceso y/o terminados, mercancas, materiales, repuestos, herramientas y
accesorios para ser consumidos en la produccin de bienes fabricados para la
venta o en la prestacin de servicios y actividades. La administracin de
inventario de un almacn, implica entonces, la determinacin de la cantidad de
inventario que deber mantenerse, la fechas y entidades a quienes debern
colocarse los pedidos y las cantidades de unidades a ordenar y asignar.
3.2.5.2 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.
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.3 Control y Gestin de Inventarios
Para Serna (2005) existen dos factores importantes que se toman en

cuenta para conocer lo que implica el control de inventarios, estos son:
a) Minimizacin de la inversin en inventarios: 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 del

inventario fuera slo minimizar las ventas satisfaciendo instantneamente la
demanda, la empresa almacenara cantidades excesivamente grandes del
producto y as no incurrira en los costos asociados con una alta insatisfaccin
ni la perdida de un cliente. 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 inventarios en
trminos de la opcin entre los beneficios que se esperan, no incurriendo en
faltantes y el costo de mantenimiento del inventario que se requiere.
El control y gestin interna sobre los inventarios 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.
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.4 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
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.
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).
70
70
3.3 Bases Legales
En relacin con los proyectos informticos asociados con el desarrollo de

software y sistemas de cualquier organizacin, sobre todo en las que
pertenecen al estado (como la Compaa Annima Nacional Telfonos de
Venezuela), aparece publicado en la Gaceta oficial N 38.095 de fecha 28/ 12/
2004, el Decreto N 3.390 con fecha del 23 de dicie mbre de 2004.
Dicho decreto se basa principalmente 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 2 2 del Decreto con Rango
y Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin; en el que se
considera que la adopcin del Software Libre desarrollado con Estndares
Abiertos en la Administracin Pblica y en los servicios pblicos, facilitar la
interoperabilidad de los sistemas de informacin del Estado.
(http://www.cenit.gob.ve/cenitcms/servlet/com.mvdcomm.cms.andocasociado?5
,64)
El Artculo 1 del Decreto N 3.390, se refiere dire ctamente a la norma o

reglamento que impulsa la nacin, con el fin de que todos los sistemas o
programas que se desarrollen para el Estado o sus entes relacionados sea bajo
la plataforma libre; de dicho articulo 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 Abierto. (dem)
Queda ms que claro, que el todo tipo de aplicaciones que tengan como
mbito de funcionamiento, los entes u organizaciones dependientes del Estado
Venezolano, deben ser desarrollados bajo estndares libres.
Es por ello que para el desarrollo de un sistema de gestin y control de

materiales en el almacn del departamento de mantenimiento y operacin de
telfonos pblicos de la CANTV en el estado Monagas se trabajar
enteramente en un entorno abierto, siempre y cuando se den las caractersticas
para ello.
3.4 Definicin de Trminos
Arquitectura: En las tecnologas de la informacin (TI), especialmente en lo

que refiere a computadores y ms recientemente en lo que se refiere a redes,
arquitectura es un trmino que se aplica al proceso y resultado de pensar y
especificar la estructura, componentes lgicos, e interrelaciones lgicas de un
computador, sistema operativo, red u otro concepto.
(www.microsoft.com/spanish/msdn/articulos/archivo/130902/voices/eaarchover.
asp)
Arquitectura Cliente/Servidor: Es un modelo para el desarrollo de sistemas de

informacin, en el que las transacciones se dividen en procesos independientes
que cooperan entre s para intercambiar informacin, servicios o recursos.
(http://www.inei.gob.pe/)
Artefacto: es una pieza de informacin que es producida, modificada o usada

por el proceso; define un rea de responsabilidad para un rol y est sujeta a
control de versiones. Un artefacto puede ser un modelo, un elemento de modelo
o un documento. (Letelier, 2002, p. 6)
Bases de datos: es un conjunto de datos pertenecientes al un mismo contexto
y almacenados sistemticamente para su posterior uso.
(http://es.wikipedia.org/wiki/Base_de_datos)
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. (http://www.inei.gob.pe/)
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. (controlinterno.udea.edu.co/ciup/glosario.htm)
Entorno de desarrollo integrado o IDE: es un programa compuesto por un

conjunto de herramientas para un programador. Puede dedicarse en exclusiva a
un slo lenguaje de programacin o bien, poder utilizarse para varios.
(http://es.wikipedia.org/wiki/Entorno_de_desarrollo_integrado)
Mantenimiento Correctivo: Mantenimiento que se realiza tras detectarse la

falla. (www.construir.com/Econsult/construr/Nro61/document/gestion2.htm)
Mantenimiento Preventivo: accin de carcter peridica y permanente que

tiene la particularidad de prever anticipadamente el deterioro, producto del uso y
agotamiento de la vida til de componentes, partes, piezas, materiales y en
general, elementos que constituyen la infraestructura o la planta fsica,
permitiendo.(www.mineduc.cl/usuarios/jec/doc/200702021532330.CONCEPTO
SBASICOSYDEFINICIONES.doc)
PEPS: La valuacin del inventario conforme el supuesto que los primeros
artculos recibidos fueron los primeros artculos vendidos. (Pacheco, Ramiro y
Otros, 2002, s/p)
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. (http://www.inei.gob.pe/)
UML: o Unified Modeling Language, es un lenguaje grfico para visualizar,

especificar, construir y documentar un sistema de software. UML ofrece un
estndar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocios y funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin,
esquemas de bases de datos y componentes de software reutilizables.
(http://es.wikipedia.org/wiki/Uml)
UEPS: La valuacin de los inventarios conforme al supuesto que los ltimos

artculos recibidos fueron los primeros artculos recibidos. (Pacheco, Ramiro y
Otros, 2002, s/p)
CAPTULO IV
MARCO METODOLGICO
Este captulo contempla los aspectos metodolgicos utilizados para llevar

a cabo la investigacin. Comprende tipo y nivel de investigacin, oblacin 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 y gestin de materiales en el
Monagas, formulando a partir de las descripcin de las tareas que dentro del
departamento se realizan, en lo que a transacciones en el almacn del
departamento se refiere. En referencia a esto Pardo, J. L. (2003, s/n) expresa
que: Un proyecto factible estar orientada 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).
Esta investigacin se fundamenta, principalmente, en un diseo de
campo, pues los datos primarios para el diseo y desarrollo del sistema de
control y gestin de materiales en el departamento de mantenimiento y
operacin de telfonos pblicos de la CANTV Monagas, 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 de materiales en el departamento de mantenimiento y
operacin de telfonos pblicos de la CANTV Monagas, describiendo la
situacin actual de estos procesos, de manera que se puedan especificar sus
caractersticas y propiedades necesarias para la 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 esta representada por el personal que

labora dentro del departamento de mantenimiento y operacin de telfonos
pblicos de la CANTV Monagas, y todos aquellos que al igual que stos,
interactan directamente con los procesos relacionados al control y gestin de
los materiales del almacn del rea de trabajo. La poblacin se constituye
entonces por:
a) Un (01) Supervisor de Mantenimiento y Operacin de Telfonos

Pblicos, que gestiona, dirige y orienta las actividades relacionadas con el
mantenimiento preventivo y correctivo de la planta fsica de telefona pblica.
b) Un (01) Tcnico Especialista de Telfonos Pblicos, que se encarga

principalmente de hacer seguimiento a las labores de mantenimiento realizadas
por los dems tcnicos de ruta, mientras est a cargo de los sistemas de
gestin de actividades, coordinando lo relacionado al manejo y control de las
herramientas y elementos de trabajo.
c) Cinco (05) Tcnicos de Ruta (tres (03) fijos y dos (02) contratistas o
outsourcing), que ejecutan las labores de mantenimiento correctivo y preventivo
a la planta pblica de telfonos.
d) Un (01) Analista de Soporte Administrativo, que a pesar de no

pertenecer directamente al departamento, se encarga de gestionar los reportes
de despachos de materiales, de llevar los inventarios de materia prima, adems
de gestionar la ordenes de compra, entre otras labores.
El total de personas que integran la poblacin a estudiar es de ocho (08), y

debido a que el nmero de unidades que integran la poblacin, es accesible en
su totalidad, es decir, esta es menor a cuarenta (40) 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.
4.3 Tcnicas e Instrumentos de Recoleccin de Datos
Durante el diseo y desarrollo del sistema de control y gestin de

materiales en el del departamento de mantenimiento y operacin de telfonos
pblicos de la CANTV Monagas, se utilizaron las siguientes tcnicas de
recoleccin de datos.
Observacin directa: indudablemente el observar en el mismo lugar de

trabajo (departamento de operacin y mantenimiento de telfonos pblicos de la
CANTV Monagas) cada una de las tareas que ah se realizaban, sirvi como
tcnica principal a la hora, no solo de identificar la situacin problemtica y
susceptible a mejorar dentro del departamento (no automatizacin de las
transacciones o tareas relacionadas al manejo del almacn), sino tambin,
para establecer los requerimiento 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.
Entrevista no estructurada: esta se aplico a la poblacin en la cual se baso

la investigacin, es decir, el personal del departamento de mantenimiento y
operacin de telfonos pblicos de la CANTV Monagas y a la Analista 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 de la tarjeta a
utilizar. (Vase Marco Terico, Tabla 1, p. 62)
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 informacin sobre aplicaciones web, mtodos de diseo y
desarrollo, sistemas de gestin y control, administracin de almacn; fuentes
fundamentales para realizar el proyecto.
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:
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 Gy susceptible
a mejora.
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 y funcionamiento
del sistema; sino que tambin se registran las prioridades de desarrollo para
cada modulo del sistema, el riesgo y el esfuerzo asociado a 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.
80
80
4.4 Tcnicas de Anlisis de Datos
En el desarrollo sistema para el control y gestin de materiales en el

Monagas, 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.
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 (05)
fases iterativas (y en parte simultaneas) del proyecto; todas necesarios para
cumplir con los objetivos antes plantados, poniendo en marcha los valores,
principios y practicas de XP.
Fase I o de exploracin y planificacin, en la que se procedi a estudiar el

entorno del departamento en el cual se desarrolla el proyecto, haciendo una
revisin documental sobre la metodologa XP, y estudiando los flujos de los
procesos relacionados con el control y gestin del almacn en el rea de
trabajo. Se plantearn las historias de usuario agrupndolas por iteraciones. 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.
Fase II, llamada iteraciones, se ejecutaron las labores de diseo y

desarrollo de cdigo de los diversos prototipos del sistema de 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.
Fase III o productizacin (produccin), se realizaron pruebas adicionales y

revisiones de rendimiento a los prototipos desarrollados. Se toman decisiones
sobre la inclusin de nuevas caractersticas a la versin en funcionamiento del
sistema, basado principalmente en cambios de requerimientos, expuestos por el
cliente o por los desarrolladores. 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.
La Fase IV o de manteniendo, constituye bsicamente el estado constante

en el que se encuentra el proyecto bajo XP. Se ejecuta al mismo tiempo que las
fases III y III, 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 realizas sobre los
prototipos y as explicarle el funcionamiento del sistema, analizando la inclusin
de mayor funcionalidad o de nuevos requerimientos. 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.
Por ltimo la Fase V o muerte del proyecto, se origin cuando para el

cliente no hay ms historias para ser incluidas en el sistema. Se satisfacen las
necesidades del cliente en aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentacin final del sistema, constituida
principalmente por el cdigo del sistema, el diseo de la base datos (reseadas
en el anexo del trabajo) y las historias de usuarios, con sus respectivas tareas
de desarrollo y pruebas ejecutadas, que est sealadas en el contenido de
fases anteriores. No se considera realizar un manual de funcionamiento del
sistema, pues al estar desarrollado de la mano con el cliente, este no lo
considera necesario, y se pospone para futuros proyectos.
Para finalizar, se podr determinar un anlisis de costo beneficio,

mediante el cual se pudo establecer si el proyecto es factible y favorable para la
empresa en el cual se desarrollo el trabajo de investigacin, aplicando el clculo
del valor presente neto de la inversin y el ndice de costo beneficio o IRt.
Dicha actividad fue incluida dentro de la fase V del proyecto, en el

siguiente cuadro operativo metodolgico:
Objetivo Especfico
Estudiar la situacin actual del entorno y lo relacionado con las metodologas giles de desarrollo y la ges
Analizar los requerimientos

para el control y gestin de los materiales segn las prioridades del
Disear los prototipos del sistema basado en tareas de ingeniera iterativas orientadas
Ejecutar pruebas y revisiones de rendimiento a las versiones desarrolladas pa
establecido
t
Implementar las diferentes versiones de prototipos del sistema desarrollados con el fin d
Elaborar la estructura de documentos para el soporte del

y ms eficiente de
Cuadro n 1: Cuadro operativo metodolgico
86
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.
5.1 El Proyecto
El proyecto consiste en desarrollar un sistema de informacin

transaccional para el control y gestin de los materiales en el almacn del
departamento de mantenimiento y operacin de telfonos pblicos de la
Compaa Annima Nacional Telfonos de Venezuela (CANTV) del estado
Monagas.
Partiendo del diseo operativo mostrado anteriormente (Vase Marco

metodolgico, p. 82) en esta investigacin, los resultados productos de la
aplicacin de la metodologa de desarrollo XP, sern mostrados en este seis
(06) etapas o fases, exploracin y planeamiento, iteraciones, productizacin,
mantenimiento, y muerte, incluyendo adems, un anlisis de los beneficios
tangibles e intangibles que trae el sistema enfrentado a su costos de desarrollo
e implementacin.
5.1.1 Fase I: Exploracin y Planeamiento
Una vez estudiado el anteproyecto y su plan operativo, empieza la

ejecucin del proyecto, estando en contacto directo con el cliente y con el rea
de trabajo. En esta etapa, se realiz una revisin documental intensiva, sobre
los diferentes aspectos involucrados con la ingeniera de software, los
87
87
fundamentos de las metodologas giles de desarrollo, los diferentes aspectos
involucrados con la metodologa plantada por Kent Beck (1996) conocida como
XP o Extreme Programming, y los diferentes aspectos que hay que tener en
cuenta para desarrollar un sistema de control y gestin para la administracin
de un almacn y su inventario. (Vase Marco Referencial, p. 26).
Luego de un largo proceso de observacin y familiarizacin con cada una

de las tareas y labores que dentro del rea de trabajo se realizaban; y de
conversar profundamente (entrevistas no estructuradas) con las personas
involucradas en dichas actividades (supervisor, tcnicos fijos, tcnicos
contratados, 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 la gestin y control de los materiales en el almacn.
El flujo que siguen las actividades, en lo que a gestin y control de

almacn se refiere, es muy simple, pues basan su trabajo en seis procesos
bsicos plenamente identificados: seleccin, adquisicin, recepcin,
almacenamiento, distribucin y control. Cada uno descrito a continuacin:
a) Seleccin: para este proceso se cuenta con un catlogo de productos,

herramientas, repuestos y/o insumos de constante uso en las labores de
mantenimiento correctivo y preventivo de la planta pblica. Se manejan una
amplia lista de artculos, organizados segn su marca, descripcin, cdigo y
dems caractersticas intrnsecas de cada material. La programacin de compra
de dichos materiales se realiza de manera semanal, por lo que la seleccin de
insumos a solicitar debe estar guiada por dicha regla.
b) Adquisicin: se pudo identificar que la compra de insumos se realiza

una vez por semana, de acuerdo claro est, con las necesidades existentes
para atender la demanda (por lo que en casos extremos, solo se podr hacer
una orden de compra a la semana). Este proceso se rige por un nivel de
atribucin o mnimo permitido para cada material en particular, es decir, cada
uno tiene tope de existencia a partir del cual puede hacerse la peticin. Para la
adquisicin se maneja un proveedor fijo representado por el Almacn Central de
Oriente de CANTV ubicado en Puerto la Cruz (Edo. Anzotegui), al cual se
hacen las peticiones y se envan los materiales para ser reparados o
desechados, segn sea su disponibilidad al momento de crear la orden.
Dichas peticiones de compra, a pesar de ser generadas desde el seno del

departamento de telfonos pblicos, son tramitadas por la analista de soporte
administrativo (previa autorizacin de la Gerencia Operativa), quien es la
encargada de servir de puente, entre el proveedor y el rea de trabajo; guiados
en todo momento por el plan operativo de compras asignados a la gestin del
departamento.
c) Recepcin: la recepcin de insumos y materiales, se realiza

directamente en el rea de trabajo, en este proceso se realiza una especie de
legalizacin de todos los insumos que van a formar parte del inventario de
productos, pues se firma y sella un documento al proveedor o transportista, por
medio de esto, se comprueba que la carga ha sido recibida, y est conforme
con la orden de compra solicitada. Se hace adems una revisin, por medio de
una inspeccin fsica de cada uno de los insumos entregados por el proveedor;
mediante un muestreo aleatorio y representativo por lote, verificando las
condiciones generales del insumo recibido.
d) Almacenamiento: este se hace de manera tal que se conserven las

especificaciones tcnicas de los materiales en los depsitos o almacenes
dispuestos para tal fin. Se tienen dos depsitos, uno ubicado en el stano del
edificio TELECOM (sede del departamento) destinado para los materiales,
insumos y herramientas de gran tamao (pedestales, cabinas, equipos
telefnicos, entre otros) y otro depsito ubicado en el primer piso (Piso 1) del
mismo edificio, para materiales de menor tamao y de ms fcil manipulacin
(tarjetas, auriculares, visualizadores, teclados, entre muchos otros). El
almacenaje se hace organizando los materiales por sus nombres, asignado un
lugar fijo para cada uno en estanteras, gabinetes, y hasta archiveros.
Es importante sealar, que los materiales se organizan de manera tal que

se garantice una rotacin adecuada, es decir, que se cumpla con la regla de
validacin de inventario PEPS (Primero que Entra, Primero que Sale), en la cual
los primeros productos en entrar son los primeros en salir.
e) Distribucin: la entrega de materiales a los tcnicos de ruta para la

ejecucin de sus rutinas de mantenimiento, se realiza a diario, a primera hora
de la maana, de acuerdo a los reportes de averas que a estos sean
asignados. Se verifica primero que nada la existencia del material en el almacn
y luego se elabora un registro en el reporte de despacho de materiales para el
tcnico solicitante (siguiendo la regla PEPS). Dependiendo el tipo de material a
asignar se podr elaborar una permiso de salida especial o una autorizacin de
traslado.
f) Control: representado principalmente por los reportes de despachos de

materiales asignados a cada tcnico en un periodo de tiempo determinada (por
lo general una semana) y que es enviado al rea de soporte administrativo para
su anlisis. Igualmente se controla el almacn por medio de infrmenos de
inventario, los cuales se deben realizare continuamente.
90
90
Una vez identificado el flujo de los procesos involucrados con el manejo de
materiales, se procedi a analizar los requisitos necesarios para el desarrollo de
un sistema que permita automatizar dichos procesos. La recoleccin de
informacin se realiz a travs de entrevistas no estructuradas y observacin
directa, utilizando las tarjetas de historias de usuarios, para luego junto con el
equipo de desarrollo asignarle a cada una su prioridad dentro del negocio,
indicar el riesgo que conlleva su desarrollo, estimar el tiempo de ejecucin de
cada una segn los puntos o semanas ideales, planificando al mismo tiempo la
iteracin asignada a cada una. Dependiendo de la historia, se incluy en
algunas un esbozo de la interfaz que sirva como base para el desarrollo de los
prototipos.
En esta planificacin inicial las historias de usuario pueden ser cambiadas

o excluidas a lo largo del proyecto, a medida que cambien los requisitos del
cliente o se tenga una concepcin ms clara del sistema.
A continuacin, se muestran los requerimientos obtenidos para el sistema,

reflejados historias de usuario agrupadas segn la planificacin hecha por
iteraciones y su orden lgico de desarrollo (esta ltima tcnica propuesta para
identificar las relaciones existentes entre las clases y los objetos a desarrollar
para cada historia, evitando as en lo el uso de tarjetas CRC como otro
artefactos)
Requerimientos primera iteracin
Las cuatro (04) historias de usuario, correspondientes a la primera

iteracin se sealan a continuacin en las siguientes tarjetas:
Historia de Usuario
Nmero: 11
Nombre historia: Gestin de materiales
Prioridad en negocio: Alta
Puntos estimados: 1
Programador responsable: Equipo Almagister
Descripcin: se llevara igualmente la creacin, edicin, eliminacin de los datos relacionados con los materia
Observaciones: la gestin lista est directamente relacionada con la H8 en la que se consulta a la base de dat
Secuencia lgica de desarrollo -> 1.a

Historia de Usuario
Nmero: 10
Nombre historia: Gestin de tcnicos
Puntos estimados: 1
Descripcin: se llevara la creacin, edicin, eliminacin, y lista de los datos relacionados con los tcnicos d
Observaciones: Secuencia lgica de desarrollo -> 1.b

Historia de Usuario
Nmero: 7
Nombre historia: Asignacin de cantidad mnima permitida en almacn
Prioridad en negocio: Media
Puntos estimados: 0.5
Descripcin: el usuario podr definir para cada uno de los materiales existentes en el almacn (listados
Observaciones: para la peticin de materiales existe un formato establecido el cual pudiera se llenado autom
Secuencia lgica de desarrollo -> 1.c
94
Historia de Usuario
Nmero: 8
Nombre historia: Generacin de informe de inventario o existencia en almacn.
Descripcin: el usuario podr pedirle al sistema un informe detallado del stock en el almacn en el momento q
Observaciones: Secuencia lgica de desarrollo -> 1.d

95
95
Requerimientos segunda iteracin
Las siguientes cuatro (04) historias de usuario correspondientes a la

segunda iteracin, son sealadas a continuacin en las siguientes tarjetas:
Historia de Usuario
Nmero: 1
Nombre historia: Introduccin y carga de tcnico para despacho
Descripcin: se introduce en cuadro de texto el cdigo del carnet o nombre de tcnico quien solicita el o los ma
Observaciones: se evaluara con equipo de desarrollo la posibilidad de que el proceso de seleccin del tcn

Historia de Usuario
Nmero: 3
Nombre historia: Carga del pedido a procesar (peticin del tcnico disponibilidad total)
Puntos estimados: 1
Descripcin: se introducen los cdigos de los materiales solicitados por el tcnico, estos se cargan de la base d
Observaciones: c/u de los tcnicos tendr un reporte de pedidos realizados para un periodo de tiempo determi
Se plantea al cliente la posibilidad de la no disponibilidad de algn material con lo que se
genera historia de usuario siguiente.
Sobre el tiempo de generacin de los reportes, este ser no limitativo, es decir, se genera el reporte
Secuencia lgica de desarrollo -> 2.b
97
Historia de Usuario
Nmero: 4
Nombre historia: Verificacin de pedido en stock o inventario
Puntos estimados: 1
Descripcin: durante el ingreso de la cantidad del pedido (H3), el sistema verifica que la cantidad solicitada se
Observaciones: se evala la posibilidad que durante el proceso de la H3 y H4 el sistema muestre automti

Lo referente a la cola de la peticin de materiales se tratara con detenimiento en historias
posteriores.
Secuencia lgica de desarrollo -> 2.c
98
Historia de Usuario
Nmero: 9
Nombre historia: Generacin de peticin de materiales (orden de compra)
Puntos estimados: 1
Descripcin: se generara un registro para el informe de la orden de compra si el usuario as lo desea ingresa
Observaciones: tener en cuenta que exista la posibilidad de que un material no se encuentre en almac
Secuencia lgica de desarrollo -> 2.d
99
Requerimientos tercera iteracin
Las dos (02) historias de usuario, correspondientes a la tercera iteracin

se sealan a continuacin en las siguientes tarjetas:
Historia de Usuario
Nmero: 5
Nombre historia: Gestin del reporte de pedidos
Puntos estimados: 1
Descripcin: Cada uno de los reportes de pedidos (generado en H1 a H4) acumulados para cada tcnico podr
El sistema permitir bien sea por un cuadro de texto u otro medio de carga, definir la direccin de corre
Observaciones: los reportes de pedidos sern almacenados en forma de texto plano (por ejemplo en extensin
100
Historia de Usuario
Nmero: 6
Nombre historia: Generacin de pedidos especiales
Puntos estimados: 1
Descripcin: para cierto tipo de materiales (de caractersticas especiales) no solo se generara un
Observaciones: recopilar formato de traslado especial de materiales. Se evalan la posibilidad para
101
Requerimientos cuarta iteracin
Las siguientes dos (02) historias de usuario correspondientes a la cuarta

iteracin, son sealadas a continuacin en las siguientes tarjetas:
Historia de Usuario
Nmero: 12
Nombre historia: Control de acceso de usuario
Prioridad en negocio: Media
Puntos estimados: 1
Descripcin: antes de iniciar la aplicacin se solicitara el nombre o login del usuario y la clave respectiva d
El control de acceso estar enlazado al men principal del sistema, que presentar acceso simple en pantalla a
Observaciones: Secuencia lgica de desarrollo -> 4.a

102
Historia de Usuario
Nmero: 13
Nombre historia: Generar traslado especial
Prioridad en negocio: Baja
Descripcin: se podr crear por medio de cuadros de textos los datos requeridos para realizar un tipo d
Observaciones: recopilar este y todos los formatos preestablecidos para el manejo de materiales que estn inv
103
La siguiente, forma parte de las historias de usuario no tomadas en cuenta
para el diseo de las tareas de ingeniera.
Historia de Usuario
Nmero: 2
Nombre historia: Preparacin del pedido
Prioridad en negocio:
Puntos estimados:
Descripcin: A la vez que aparecen en pantalla los datos del tcnico solicitante (ver H1), se muestra cuadro de
El usuario podr contar con un botn para cerrar el pedido al haber cargado toda la solicitud.
Observaciones: considerar que un mismo tcnico puede pedir diferentes materiales para un solo despacho, po
No se toma en cuenta dentro de la planificacin inicial, al considerar que est duplicada en la H
Tabla 17: Historia de Usuario 2 (no incluida)
104
1041
Arquitectura para el sistema y Herramientas de Desarrollo
Tras evaluar diferentes alternativas de lenguajes de programacin y

plataformas de desarrollo, la aplicacin se desarroll bajo un marco
cliente/servidor, utilizando la potencia ofrecida por el lenguaje de programacin
PHP junto al JavaSript, con un sistema de gestin de base de datos en MySQL;
esto dado principalmente a la sencillez que provee este motor para el trabajo y
la gestin de bases de datos, que constituye el ncleo central de la aplicacin.
La arquitectura completa para el desarrollo y de implantacin seguir el modelo
presentado en la siguiente figura:
Base de Datos
Relacional (MySQL)
Servidor Web (Apache - Middleware

desarrollo) (IIS -
implantacin) (PHP, Java Script)
INTERNET
Web Browser - Explorador
(Internet Explorer, Firefox)
Figura 14: Arquitectura del Sistema.

Las herramientas de desarrollo, utilizadas para el desarrollo del sistema,
se describen a continuacin:
Adobe Fireworks 8 (Diseo Grafico): es una aplicacin en forma de

estudio (Basada por supuesto en la forma de estudio de Adobe Flash) pero
con ms parecido a un taller destinado para la edicin y optimizacin para web
de grficos en mapa de bits o vectoriales.
Adobe Dreamweaver 8 (Diseo web): Es una aplicacin en forma de

estudio (Basada por supuesto en la forma de estudio de Adobe Flash) pero
con ms parecido a un taller destinado para la edicin WYSIWYG de pginas
web, creado inicialmente por Macromedia (actualmente es propiedad de Adobe
Systems). Es el programa de este tipo ms utilizado en el sector del diseo y la
programacin web, por sus funcionalidades, su integracin con otras
herramientas como Adobe Flash y, recientemente, por su soporte de los
estndares del World Wide Web Consortium.
DBDesigner es un sistema totalmente visual de diseo de bases de

datos, que combina caractersticas y funciones profesionales con un diseo
simple, muy claro y fcil de usar, a fin de ofrecerte un mtodo efectivo para
gestionar tus bases de datos. Te permite administrar la base de datos, disear
tablas, hacer peticiones SQL manuales y mucho ms, como ingeniera inversa
en MySQL, Oracle, MSSQL y otras bases de datos ODBC, modelos XML y
soporte para la funcin drag-and-drop.
MySQL-Front (administrador de BD Escritorio): es una sencilla pero til

aplicacin diseada especialmente para desarrolladores que trabajan con
MySQL. Con MySQL-Front se pueden realizar acciones bsicas como aadir,
borrar o modificar tablas, campos, registros, entre otras.
PHP es un lenguaje de programacin interpretado usado normalmente
para la creacin de pginas web dinmicas. PHP es un acrnimo recursivo que
significa "PHP Hypertext Pre-processor" (inicialmente PHP Tools, o, Personal
Home Page Tools). Igualmente se utiliza un poco de Java Script, que es un
lenguaje de programacin interpretado, es decir, que no requiere compilacin,
utilizado principalmente en pginas web, con una sintaxis semejante a la del
lenguaje Java y el lenguaje C.
PhpMyAdmin (Administrador BD WEB): es una herramienta escrita en

PHP con la intencin de manejar la administracin de MySQL a travs de
pginas webs, utilizando Internet. Actualmente puede crear y eliminar Bases de
Datos, crear, eliminar y alterar tablas, borrar, editar y aadir campos, ejecutar
cualquier sentencia SQL, administrar claves en campos, administrar privilegios,
exportar datos en varios formatos y est disponible en 50 idiomas. Se encuentra
disponible bajo la licencia GPL.
WYSIWYG: es el acrnimo de What You See Is What You Get (en ingls,
"lo que ves es lo que obtienes"). Se aplica a los procesadores de texto y otros
editores de texto con formato (como los editores de HTML) que permiten
escribir un documento viendo directamente el resultado final, frecuentemente el
resultado impreso.
XAMPP (Apache Mysql PHP y PERL): es un paquete que te permite

instalar varios tipos de servidores en tu sistema con unos pocos clicks de tu
ratn en apenas 5 minutos. XAMPP incluye el servidor web Apache, los
servidores de bases de datos MySQL y SQLite, sus respectivos gestores
phpMyAdmin y phpSQLiteAdmin, el intrprete del lenguaje homnimo PHP con
los extras incluidos en PEAR, el intrprete del lenguaje Perl, entre otros.
Plan de Entregas
Se muestra a continuacin, el plan de entregas acordado con el cliente,

para la muestra de los prototipos del sistema.
Segn el cuadro 7, para la primera entrega sern necesarias 3 semanas

ideales de programacin, segn las estimaciones hechas en base a las
afirmaciones de los mismos desarrolladores.
Historia Nombre
11 Gestin de materiales
10 Gestin de tcnicos
Asignacin de cantidad mnima permitida en almacn
7
Generacin de informe de inventario o existencia
8 en almacn Superusuario Alta Bajo 0,5
Total 3
Puntos de Trabajo 3
Cuadro n 2: Plan de entrega primera iteracin.
Es bueno recordar que un punto representa una semana ideal de trabajo,

sin interrupciones y sin pasar de las 8 horas de trabajo. Al ser solo una pareja
de programadores el ndice total de 3 puntos se mantiene igual al los puntos de
trabajo.
De esta manera se mantiene la regla de no exceder de las 3 semanas

para la primera entrega al cliente, desde el momento en que se inicien las
labores de desarrollo.
Para la segunda entrega se estima un aproximado de un mes de trabajo,
teniendo en cuenta que el promedio de puntos por actividades ronda la semana
de trabajo (4 historias = 4 semanas de trabajo = 1 mes). Esto se confirma,
mediante el siguiente cuadro (n 3), correspondiente al plan de la segunda
entrega:
Histor ia Nombre Usuario

Introduccin y carga de tcnico para
1 despacho
3 Carga del pedido a procesar
4 Verificacin de pedido en stock o inventario
Generacin de informe de inventario o existencia
9 en almacn Superusuario Alta Bajo 1
Total 4,5
Puntos de Trabajo 4,5
Cuadro n 3: Plan de entrega segunda iteracin.
Se consider disolver la prctica de la programacin en pareja, pues los

riesgos de desarrollo son en promedio altos, lo que trae complicaciones sobre
todo a la hora de realizar las pruebas y dejar operativos al 100% los mdulos
del sistema, sobre todo los correspondientes a sta iteracin.
Para la tercera iteracin (tercera entrega) se estiman solo 2 semanas de

trabajo, pero considerando una holgura que puede ser utilizada para completar
iteraciones pendientes de la tareas de la iteracin anterior, se planifica entonces
un tiempo de entrega de 3 semanas para esta tercera fase del proyecto.
Se debe tener cuidado en no subestimar el esfuerzo y el riesgo que
implica esta entrega, pues, aunque son solo dos historias las que se buscan
desarrollar, implican niveles altos tanto de riesgo como de importancia para el
proyecto, esto reafirma la idea de tomar una semana ms de las que arrojan los
datos, en el cuadro n 4
Historia Nombre Usuario Prioridad Riesgo Puntos

5 Gestin del reporte de pedidos Super
6 Generacin de pedidos especiales Supe
Total 2
Puntos de Trabajo 3
Cuadro n 4: Plan de entrega tercera iteracin.
Se estima que para la ltima entrega (cuarta iteracin), se haga entre 2 y

tres semanas luego de la entrega anterior, tal cual lo muestra el siguiente
cuadro.
Historia Nombre Usuario Prioridad Riesgo Puntos
12 Control de acceso de usuario Superusuario
13 Generar traslado especial Superusuario
Total 1,5
Puntos de Trabajo 2-3
Cuadro n 5: Plan de entrega cuarta iteracin.
110
1101
sta representa la entrega definitiva del proyecto y aunque las historias
son de fcil desarrollo, se toma en cuenta toda la cantidad de trabajo que se
puede haber venido acumulando de entrega a entrega, igualmente al ser la
ultima entrega, se busca probar exhaustivamente el producto de manera que
cumpla con los requerimientos del usuario de la mejor manera posible.
En definitiva, se planea una duracin de 12 semanas ideales de trabajo,

es decir, un aproximado de 2 meses de trabajo a 2 meses y medio,
considerando que una semana ideal de trabajo sera de 6 das, un da libre a la
semana en vez de dos pero muchsimo menos que 8 horas diarias de trabajo
esos 6 das.
Como se podr intuir, si los programadores o grupos de desarrolladores,

se conocen bien a si mismos, entre ellos, y pueden estimar el tiempo que les
lleva realizar tareas de desarrollo con cierto grado de acertividad, entonces es
muy fcil estimar la duracin de un proyecto bajo XP.
Claro est que las medidas de desempeo no solo se ven sujetas a la

intuicin de cada desarrollador y lo que ste o estos crean que pueden lograr;
pues dependiendo de los cambios que aparezcan durante el desarrollo, (bien
sea por problemas de desarrollo o por nuevos requerimientos que aparecen,
entre otros), los valores y estimaciones de duracin entre una entrega y otra
pueden cambiar, y seguramente lo harn; es por ello que en los proyectos
planificados bajo XP (sobre todo los que son de mayor envergadura) en los que
los cambios son ms que seguros, las estimaciones se hacen en base a
promediar logros obtenidos en iteraciones pasadas ms un poco de inferencia
hecho por el planificador (Manager en XP) en base a lo que los desarrolladores
le comenten creen pueden lograr.
5.1.2 Fase II: Iteraciones
Se sealan a continuacin, las tareas de ingeniera derivadas de las

historias de usuario (requerimientos del sistema), y que son convertidas en
cdigo del sistema por parte de los desarrolladores. Dichas tareas son
agrupadas, siguiendo el plan de entregas antes expuesto, por lo que sern
mostradas por iteracin.
Tareas de Ingeniera - Primera Iteracin
La metfora compartida por el equipo de desarrollo en esta etapa inicial,

est relacionada directamente con este hecho, es decir, con el hecho de que es
la primera vez que se utiliza un enfoque definido para afrontar el desarrollo de
proyecto de ingeniera de software. La metfora utilizada es Trabajando bajo
XP, a utilizar las prcticas fundamentales
Es de destacar que con el fin de afianzar las prcticas XP aplicadas en

esta etapa; las tareas de ingeniera son continuamente integradas dentro de la
aplicacin y subidas al servidor WEB dispuesto par tener acceso a ellas desde
distintos puntos, que junto a los distintos formas y medios de comunicacin
(chat, video-chat, telefona, SMS, reuniones continuas), le aportaban mayor
calidad al trabajo.
Las tareas bsicas de ingeniera se muestran a continuacin, en las

siguientes cuatro (04) tarjetas:
Tarea de Ingeniera
Nmero Tarea: 1
Nombre Tarea: Crear modulo inventario (tabla inventario)

Tipo de Tarea :
(especificar)
Tiempo de trabajo: semana y media de trabajo aproximadamente 7 das.
Programador Responsable: Pedro Rodrguez Antonio Estaba.
Descripcin:
Es el tiempo de empezar, con el desarrollo del mdulo de inventario, esto se refiere a realizar un formu
Con el desarrollo de la historia 11, se ejecuta en gran parte las tareas de desarrollo que implican la ejecucin de
A nivel del cdigo de sistema estn tareas se ven reflejadas en el moduloinventario/nuevoarticulo y modulo
Los prototipos de interfaz del usuario para estas tareas son mostrados en la Fase IV: Mantenimiento (fig
113
Tarea de Ingeniera
Nmero Tarea: 2
Nombre Tarea: Desarrollar las tarea administrativas del modulo inventario.
Tipo de Tarea :
(especificar)
Tiempo de trabajo: media semana de trabajo 3 das.
Programador Responsable: Pedro Rodrguez Antonio Estaba.
Descripcin:
Bsicamente se crean las acciones de consulta, edicin, eliminacin y dems de cada uno de los registros d
Se conforma el modulo adm/editar, la cual realiza accin de edicin del registro seleccionado en
Se incluye el script de confirmacin de cdigo (adm/buscarcodigoarticulo y buscarmateriales), que arroja un
Considerando la visin del cliente, desde el mdulo administracin de materiales se lista todo el inventario
114
Tarea de Ingeniera
Nmero Tarea: 3
Nombre Tarea: Crear modulo tcnico (tabla tcnicos)
Tipo de Tarea :
(especificar)
Tiempo de trabajo: 3 das aproximadamente.
Programador Responsable: Pedro Rodrguez
Descripcin:
Las tareas de desarrollo para este modulo son muy similares a las ejecutadas para la tarea de ingeniera 1 co
Estn tareas se ven reflejadas en el desarrollo del modulotecnicos. Ah se desarrolla el cdigo para modu
Se encuentra en ese mismo modulo llamado modulotecnicos /buscarcedulatecnicos. Su funcin es ir confirm
Los prototipos de interfaz del usuario para estas tareas son mostrados en la Fase IV: Mantenimiento (fig
115
Tarea de Ingeniera
Nmero Tarea: 4
Nombre Tarea: Desarrollar las tarea administrativas del modulo de tcnicos
Tipo de Tarea :
(especificar)
Tiempo de trabajo: 2 das aproximadamente.
Programador Responsable: Pedro Rodrguez Simn Garantn
Descripcin:
Se desarrolla dentro del modulo de tcnicos, el cdigo para adm/listartecnicos desde donde se administran
mediante el cual se hace un enlace hacia la actualizacin o edicin del tcnico seleccionado en la tabla de
Se incluye el script de confirmacin de cdigo (adm/buscarcedulatecnicos), agregndole seguridad y mayor fu
Considerando la visin del cliente, desde el mdulo administracin de los tcnicos se lista todos los tcnicos regi
116
Tareas de Ingeniera - Segunda Iteracin
La metfora compartida en esta segunda iteracin, mantiene el enfoque

filosfico de la metodologa XP. La metfora es: Ms comunicacin, mejor
trabajo. Las tareas elaboradas para esta etapa se muestran a continuacin, en
las siguientes dos (02) tarjetas:
Tarea de Ingeniera
Nmero Tarea: 5
Nombre Tarea: Desarrollar la relacin entre tcnicos y materiales para crear el despacho. (tabla control)
Tipo de Tarea :
(especificar)
Tiempo de trabajo: entre 15 y 20 das.
Programador Responsable: Pedro Rodrguez.
Descripcin:
Se acuerda trabajar el despacho de los materiales bajo una misma pantalla, desde la cual se pueda seleccionar
Se crea entonces una especie de nueva historia, en la que el desarrollo de su aplicacin se ejecute desde un mi
Primero que nada se desarrollar una consulta cruzada entre las tablas inventario y tcnicos
en la base de datos que se ejecute en un modulodespacho, se desarrolla un formulario de
117
1171
insercin de datos que irn a un registro de la tabla control, se ejecutara desde
despachar/nuevo, ubicado dentro de modulodespacho.
Igualmente se desarrolla el cdigo donde se realiza el registro de lo que se introdujo en el

archivo nuevo, despachar/crear, y se integra a este modulo el script despachar/buscar que
buscar el articulo para que sea cargado junto con el tcnico para el despacho nuevo.
El cliente contar con la interfaz que permita realizar la asignacin del pedido al tcnico
correspondiente, con su respectiva cantidad verificada. El prototipo de dicha interfaz en la
Fase IV: Mantenimiento (figura 20 - prototipos de interfaz tarea 5)
Tarea de Ingeniera
Nmero Tarea: 6
Nombre Tarea: Elaborar los cierres de los periodos de entrega modulo despacho
Tipo de Tarea :
(especificar)
Tiempo de trabajo: 10 das aproximadamente
Programador Responsable: Antonio Estaba
Descripcin:
Se desarrollara el script cierre/cierreperiodo en el modulodespacho, el cual es necesario para pedir una auto
Igualmente es necesario desarrollar el modulo que pueda realizar la actualizacin de la tabla control en la base
El cierreperiodo ser archivo ejecutable, contacto con la interfaz de usuario, y le permitir al mismo decidir si c

En esta iteracin, se observa la aparicin de una especie de nueva historia
de usuario. sta no se refleja como tal (en el apartado de la planificacin), pues
no se basa en un requerimiento diferente ni en un cambio en la funcionalidad
del sistema; sta surge de la reorganizacin o ms bien de la integracin de
varias historias planificadas inicialmente para ser desarrolladas en la misma
iteracin.
Tareas de Ingeniera - Tercera Iteracin
La metfora compartida en esta iteracin es: Fase mantenimiento, que el

sistema contine su mejoramiento. La tarjeta de tarea de ingeniera elaborada
para esta tercera entrega es:
Tarea de Ingeniera
Nmero Tarea: 7
Nombre Tarea: Elaborar modulo de reportes
Tipo de Tarea :
(especificar)
Tiempo de trabajo: 7 das
Descripcin:
Se desarrolla el modulo de reportes en el cual se gestionaran todos los reportes que genera el sistema.
En el se desarrolla un apartado de reportes/tcnicos que gestiona los reportes pedidos por cada uno de los t
con los mdulos tcnicos/detallestecnico y tcnicos/buscardatostecnico, el primero
arrojar los detalles de un tcnico elegido (en trminos de los despachos por periodo que
este ha generado) y el segundo busca si el tcnico existe o no para poder ser desplegado en
la lista de consulta.
Los reportes de despacho son generados en forma de texto plano, fcilmente pueden ser
enviado va mail por medio de las utilidades del explorador utilizado utilizando la cuenta de
correo predeterminada en el Outlook (gestor de correos utilizado en el departamento de
telefona publica de CANTV Monagas).
El prototipo de la interfaz de usuario para la consulta del reporte de los tcnicos se sealar
en la Fase IV: Mantenimiento (figura 22 - prototipo de interfaz tarea 7)
Tareas de Ingeniera - Cuarta Iteracin
La metfora compartida en esta cuarta iteracin es: Utilidades finales,

ltimos retoques, 100% de pruebas efectivas. Las tareas de ingeniera
elaboradas para esta cuarta, se presentan en las siguientes tres (03) tarjetas:
Tarea de Ingeniera
Nmero Tarea: 8
Nombre Tarea: Incluir reporte especial
Tipo de Tarea :
(especificar)
Tiempo de trabajo: 10 das aproximadamente
Descripcin:
Se incluye en la consulta de los reportes de los tcnicos, los reportes especiales los cuales sealan si para un pe
Con el formato en mano, y previamente adaptado a formato HTML que permita su inclusin en el sistema, se
120
1201
artculo despechado en el periodo de cierre necesita autorizacin de salida, creando un
registro para dicho formato.
El prototipo de la interfaz de usuario para la consulta del reporte de los tcnicos (incluyendo
los reportes especiales) se sealar en la Fase IV: Mantenimiento (figura 22 y 23 - prototipos
de interfaz tarea 7 y 8)
Tarea de Ingeniera
Nmero Tarea: 9
Nombre Tarea: Crear tabla para el usuario

Tipo de Tarea :
(especificar)
Descripcin:
Se desarrollan las tareas tpicas para el acceso de control de usuarios. Se crea la tabla usuarios en la ba
El acceso al usuario seguir el bosquejo inicial desarrollado durante la tarea de ingeniera 12 (tabla 14), tpico

Tarea de Ingeniera
Nmero Tarea: 10
Nombre Tarea: Crear formulario de traslado especial
Tipo de Tarea :
(especificar)
Descripcin:
Para la elaboracin de esta tarea, es indispensable contar con el formato usado por la empresa para est
Se crea entonces una pantalla de usuario donde se visualicen los datos a ingresar en cuadros de texto,
Al ser un simple formulario, este no tiene conexin con la base de datos, ni de los materiales sin de los tcnico
122
Esquema de la base de datos
Tal y como se ha sealado en las tareas de ingeniera, el sistema

propuesto funciona sobre la plataforma que ofrece una simple base de datos
gestionada bajo MySQL. Dicha base de datos, se separa en tres regiones, la
regin de los accesos del usuario que es independiente y proporciona acceso al
sistema, la regin del despacho donde se encuentran los registros del inventario
y los tcnicos que se asignan a un despacho; y la regin de los despachos,
donde se une y se gestiona (registra) los despachos de materiales asignados a
un tcnico determinado en un periodo de cierre determinado. El esquema de la
base de datos se seala a continuacin en la siguiente figura:
Figura 15: Esquema de la base de datos
123
1231
5.1.3 Fase III: Productizacin
En esta seccin se indican las distintas pruebas funcionales realizadas

sobre los prototipos desarrollados segn las iteraciones propuestas en base a
las historias de usuario aprobadas. Esta parte corresponde en su totalidad al
Tester o Probador XP.
Existen en XP dos tipos de pruebas, las de aceptacin y las unitarias. Para

el desarrollo de este proyecto se integran ambos tipos de pruebas dada la
naturaleza de las personas que ejecutan los roles, es decir, las pruebas de
aceptacin son simplemente aquellas en las que el usuario certifica que las
funcionalidades y requerimientos por el creados se ven cumplidos en cada
iteracin, mientras que, las pruebas unitarias son las que realiza el equipo de
desarrollo XP para evaluar la funcionalidad del sistema.
Al ser el Manager XP, parte del conjunto de clientes, y contar este con
total libertad de decidir los cambios en cuanto a funcionalidad e interfaz del
sistema, se acuerda integrar ambas pruebas en una. Al ser el mismo usuario el
que desarrolla su propio sistema, naturalmente no existe esa distincin entre
pruebas de aceptacin y pruebas unitarias, aunque es importante sealar que
para proyectos de otra naturaleza, si es necesario apartar este tipo de pruebas.
Cada prueba tendr su documentacin respectiva en las tarjetas de los

casos de pruebas. En ellas se especifica el modo de utilizacin de la aplicacin
y los posibles estados de error que pueden darse, as como los mensajes de
aviso/error/confirmacin que debe emitir la aplicacin en estos casos.
Los casos de prueba por iteracin se presentan por iteraciones, en las

siguientes tarjetas.
Pruebas primera iteracin
Para los primeros prototipos desarrollados durante sta iteracin, se

ejecutaron las siguientes pruebas, reunidas en los siguientes once (11) casos:
Cdigo: 1
Nombre: Gestionar el ingreso de los datos de los tcnicos fijos CANTV
Descripcin: Se ingresaran en el formulario del ingreso de los datos del tcnico los campos ah requeridos. Se
- Se deben contar con todos los datos del tcnico que aparecen en la descripcin.
- En caso de ser tcnico fijo CANTV se debe tener el dato del carnet SAP.
- De ser tcnico contratado, no permitir el ingreso de datos en el campo Id SAP.
-Se comprueba adems que a la hora de definir el tipo de tcnico se desplegu lista en la que se visualice s
-Si se elije tipo de tcnico CANTV, se activa la casilla para el ingreso del carnet Id SAP; de lo
contrario (tcnico contratista) no se activara el cuadro de texto imposibilitando el acceso de datos.

- En la pantalla principal se selecciona el botn para ingresar al men de tcnicos.
- Se ingresa en la seccin de Ingreso de datos de tcnicos (para gestionar un nuevo tcnico).
- Se ingresa cada uno de los campos antes mencionados:
Nombre: Evelio Apellido: Lepage Cdula: 8546606
Carnet: 813245
Tipo de Tcnico: Cantv (seleccionado de men desplegable) Id SAP: 108725.
- Al tener los datos completos, cliquear sobre el botn enva en la parte inferior para crear el registro en la bas
Resultado Esperado:
- Se crea exitosamente el registro en la base de datos, el cual puede ser confirmado en la
seccin de listar tcnicos del sistema.
- Al ingresar los datos correspondientes a la cdula, aparece smbolo de verificacin, que
indica que el tcnico en cuestin no ha sido registrado antes en la base de datos.
- Al cliquear sobre enviar, el sistema enva un mensaje de confirmacin indicando que los
datos han sido ingresado exitosamente, y ofrece la opcin de volver hacia la pantalla de
ingreso.
Evaluacin de la Prueba: Completada 100%
Cdigo: 1.1
Nombre: Gestionar el ingreso de los datos de los tcnicos contratista
Descripcin: Se ingresaran en el formulario del ingreso de los datos del tcnico pero en este caso contrati
Condiciones de Ejecucin: Mismas condiciones prueba cdigo 1

- Se ingresa cada uno de los campos antes mencionados: Nombre: Alberto
Apellido: Dorca
Cdula: 6.371.223
Carnet: W4OW05
Tipo de Tcnico: Contratista (seleccionado de men desplegable)
- Al tener los datos completos, cliquear sobre el botn enva en la parte inferior para crear el registro en la base
Resultado Esperado:
- Se crea exitosamente el registro en la base de datos, el cual puede ser confirmado en la seccin de listar t
- Al ingresar los datos correspondientes a la cdula, aparece smbolo de verificacin, que indica que el tcn
-Se comprueba si permite el ingreso de datos de cedula con separacin de puntos (muchos
usuarios as lo prefieren)
- Se comprueba que al seleccionar el tipo de tcnico contratista en la lista desplegable, no se
puedan ingresar datos en el campo carnet Id SAP.
- Se verifica que el campo carnet soporte el tipo de datos alfanumrico.
ingreso.
Cdigo: 1.2
Nombre: Gestionar el ingreso de los datos de los tcnicos con alguno de los datos faltante.
Descripcin: Se ingresaran los datos del tcnico, pero incompletos faltando primero el nombre, luego el
- Se ingresan los datos de manera que siempre quede uno de los campos del formulario vacio.
- Pueden quedar vacios ms de un campo a la vez.
- Se probara dejando vacio uno a uno en el mismo orden en que aparecen en el formulario
(tal y como se han ingresado en pruebas pasadas)

- Se ingresa los datos mostrados a continuacin, exceptuando siempre uno de ellos: Nombre: Juan
Apellido: Pereza
Cdula: 2642682
Carnet: 123456
Tipo de Tcnico: Cantv (seleccionado de men desplegable) Id SAP: 108726.
- Al tener los datos completos, cliquear sobre el botn enva en la parte inferior para crear el registro en la base
Resultado Esperado:
- En caso de faltar el nombre del tcnico, el sistema responder dando una alarma que
solicite el ingreso del nombre.
- En caso de faltar el apellido del tcnico, el sistema responder dando una alarma que
solicite el ingreso del dato en cuestin.
- En caso de faltar la cdula del tcnico, el sistema responder dando una alarma que
- En caso de faltar el carnet del tcnico, el sistema responder dando una alarma que solicite
el ingreso del dato en cuestin.
- En caso de no indicar el tipo de tcnico, el sistema responder dando una alarma que
- En caso de faltar el carnet SAP del tcnico (si es este del tipo CANTV), el sistema
responder dando una alarma que solicite el ingreso del dato en cuestin.
- En caso de faltar ms de un dato, el sistema indicar con una alarma el ingreso del primer
dato que falte en el orden en que aparece en pantalla.
Cdigo: 1.3
Nombre: Gestionar el ingreso de los datos de los tcnicos con la cdula repetida.
Descripcin: Se ingresaran los datos de un nuevo tcnico, pero repitiendo la misma cdula que de un tcnico
- Debe existir un tcnico pre cargado al sistema con el mismo dato de la cedula del nuevo que se intenta ing

- Se ingresa los datos mostrados a continuacin, exceptuando siempre uno de ellos:
Nombre: Juan
Apellido: Pereza
Cdula: 8546606 (existente en el sistema para tcnico Evelio Lepage) Carnet: 123456
Tipo de Tcnico: Cantv (seleccionado de men desplegable)
Id SAP: 1087244.
- Al tener los datos completos, cliquear sobre el botn enva en la parte inferior para crear el
registro en la base de datos.
Resultado Esperado:
- El sistema automticamente al ingresar la cedula repetida, indicara con una X, junto al
campo de la cdula, que esta no es permitida.
- Todos los datos pueden repetirse (cuestin bastante poco probable en la realidad) menos
el dato de la cdula (campo clave).
- De no tomar en cuenta la alarma y forzar al sistema a crear el registro, este no lo permitir,
y arroja una seal de que el cdigo ya existe en la base de datos. Forzando a la correccin.
Cdigo: 1.4
Nombre: Administrar los datos de los tcnicos ingresados a la base de datos
Descripcin: Administrar los datos de la tabla correspondiente, significa, verificarlos, editarlos, y elimin
- Debe existir uno o ms tcnicos pre cargado al sistema.

- Se ingresa en la seccin de administrar datos de tcnicos.
- Se visualiza en pantalla ventana de administracin de tcnicos.
- Se observa cuadro de bsqueda con filtro desplegable segn cdula, nombre, apellido y carnet.
- Al montarse sobre el cuadro de texto se despliega en pantalla lista con los tcnicos listados en la bas
- Se filtran datos segn los campos antes descritos, comprobando que los datos se organicen segn
- Se busca un tcnico segn cada uno de los datos ya mencionados, comprobando que el sistema no tome en c
- A cada uno de los registros de los tcnicos se podr mediante acceso directo visualizar por separado (cuadro
- Se visualiza en pantalla conexin para ingresar a la pantalla de nuevos tcnicos.
Resultado Esperado:
- El sistema muestra en ventana administrativa lista con tcnicos ingresados a la base de
datos indicando su nombre, apellido, cedula y carnet; adems de contar con los enlaces Ver,
editar y eliminar (para cada registro).
- Al filtrar la bsqueda bien sea por cdula, nombre, apellido o carnet; los datos de la pantalla
se organizan de mayor a menor orden segn el criterio seleccionado.
- Al realizar la bsqueda, esta ser de modo despiste, es decir, mostrar en pantalla solo
los resultados que cumplan con los datos ingresados segn el criterio de la bsqueda
seleccionado en el filtro.
- Al ingresar en la seccin ver, se podrn visualizar aparte en pantalla los detalles del tcnico
seleccionado. Se regresa a la pantalla anterior por medio del explorador.
- Al ingresar en la seccin editar, se enlaza directamente con la pantalla de actualizacin de
tcnicos, con los datos del registro seleccionado pre cargados, de manera que puedan ser
corregidos y/o modificados y enviados de regreso a la base de datos.
- Al seleccionar la opcin Eliminar, el sistema preguntar si est seguro de eliminar el
registro seleccionado y de ser afirmativa la seleccin, elimina el registro de la base de datos,
en caso contrario la mantiene tal cual aparece en el detalle.
- Al seleccionar Agregar nuevo tcnico, se hace un enlace directo con el formulario para el
ingreso de un nuevo tcnico.
Evaluacin de la Prueba: Completada 89% - Detalle en el filtrado, al filtrar, bien sea por
nombre, apellido, o carnet; el sistema no muestra en pantalla el dato del carnet, este dato
regresa, al filtrar por cdula. Este detalle no afecta para nada la funcionalidad del sistema, se
considera un error esttico de pantalla. En vas de solucin.
Cdigo: 2
Nombre: Gestionar el ingreso de los datos de los materiales al sistema
Descripcin: Se ingresaran en el formulario del ingreso de los datos del nuevo material los campos ah requer
- Se contar con todos los datos requeridos en el formulario.
- La cantidad mnima permitida ser un valor cualquiera, no interesa para los efectos de sta prueba.

- En la pantalla principal se selecciona el botn para ingresar al men de los materiales.
130
1301
- Se ingresa en la seccin de Ingreso de nuevo artculo.
- Se ingresa los datos mostrados a continuacin.
Cdigo: 381853
Marca: RSTL
Descripcin: Tarjeta de terminacin de lnea s617/1/14
Cantidad (stock): 100
Cantidad Mnima (permitida): 10
Producto necesita autorizacin: NO
- Se enva el registro a la base de datos por medio de botn Enviar.
Resultado Esperado:
- Se crea exitosamente el registro en la base de datos, el cual puede ser confirmado en la
seccin de listar materiales del sistema.
- Al ingresar los datos del cdigo del material, aparece casilla de verificacin indicando que
el cdigo que se va ingresando no existe en la base de datos.
- Para indicar que el producto no necesita una autorizacin se contara con un botn de
seleccin (solo existen 2 opciones; SI o NO).
ingreso.
Cdigo: 2.1
Nombre: Gestionar el ingreso de los datos de los materiales con alguno de los datos faltante.
Descripcin: Se ingresaran los datos de un material, pero incompletos faltando sucesivamente algu
- Se ingresan los datos de manera que siempre quede uno de los campos del formulario vacio.
- Pueden quedar vacios ms de un campo a la vez.
- Se probara dejando vacio uno a uno en el mismo orden en que aparecen en el formulario
(Ingreso Nuevo Articulo)
- Que el producto necesite o no autorizacin no importa para este caso de prueba al igual que la cantidad m
-Al corregir los datos faltantes se crea un nuevo registro con todos los datos arriba sealados
en la base de datos de los materiales.

- Se ingresa los datos mostrados a continuacin. Cdigo: 381873
Marca: RSTE
Descripcin: Teclado Matriz SIEMENS 617/7/07458/000
Cantidad (stock): cualquier valor
Cantidad Mnima (permitida): cualquier valor
Producto necesita autorizacin: indistinto
Resultado Esperado:
- En caso de faltar el cdigo de artculo o material, el sistema responder dando una alarma que solicite introd
- En caso de faltar la marca del material, el sistema responder dando una alarma que solicite el ingreso
- En caso de faltar la descripcin, el sistema responder dando una alarma que solicite el ingreso del dato e
- En caso de faltar la cantidad de material a ingresar, el sistema responder dando una alarma solicitando
- En caso de no la cantidad mnima permitida para algn material, el sistema responder
dando una alarma que solicite el ingreso del dato en cuestin.
- En caso de faltar el carnet SAP del tcnico (si es este del tipo CANTV), el sistema responder dando
- En caso de faltar ms de un dato, el sistema indicar con una alarma el ingreso del primer
dato que falte en el orden en que aparece en pantalla.
- Por defecto aparecer seleccionada la opcin de que no necesita autorizacin, pudiendo el usuario cambiarla
Cdigo: 2.2
Nombre: Gestionar el ingreso de los datos de un nuevo material con un cdigo repetido. (cdigo errado)
Descripcin: Se ingresaran los datos de un nuevo material, pero repitiendo el cdigo de un
132
material antes ingresado.
- Debe existir un material pre cargado al sistema con el mismo dato de cdigo del nuevo que se intenta ingresa
- Que el producto necesite o no autorizacin no importa para este caso de prueba al igual
que la cantidad mnima permitida.

- Se ingresa los datos mostrados a continuacin, exceptuando siempre uno de ellos: Cdigo: 381873 (cdigo de
Marca: RSMP
Descripcin: Micro interruptor de puerta SIEMENS Cantidad (stock): indistinta
Cantidad Mnima (permitida): indistinta
Producto necesita autorizacin: indistinto
Resultado Esperado:
- El sistema automticamente al ingresar el cdigo, indicara con una X, junto al campo de la cdula, que est
- Todos los datos de dos materiales distintos pudieran repetirse (cuestin improbable en la
realidad) menos el dato del cdigo (campo clave).
- De no tomar en cuenta la alarma y forzar al sistema a crear el registro, este no lo permitir, y arroja una seal
Cdigo: 2.3
Nombre: Administrar los datos de los materiales o artculos ingresados a la base de datos
Descripcin: Administrar los datos de la tabla correspondiente, significa, verificarlos, editarlos, eliminar
- Debe existir uno o ms materiales pre cargado al sistema.
133
- Se considera la posibilidad de que ingresen nuevos artculos (producto de una nueva compra) con lo q

- Se ingresa en la seccin de administracin de materiales.
- Se visualiza en pantalla ventana de administracin de los materiales.
- Se observa cuadro de bsqueda con filtro desplegable segn descripcin y cdigo.
- Al montarse sobre el cuadro de texto se despliega en pantalla lista con los materiales listados en la base de d
- Se filtran datos segn los campos antes descritos, comprobando que los datos se organicen segn est
- Se busca uno de los materiales antes ingresados, ingresando las inciales de su descripcin o cdigo,
- A cada uno de los registros de los tcnicos se podr mediante acceso directo visualizar por separado, Editar,
- Se visualiza en pantalla conexin para ingresar al sistema un nuevo artculo.
Resultado Esperado:
- El sistema muestra en ventana administrativa una lista con los materiales ingresados a la base de datos in
- Al filtrar la bsqueda bien sea por cdigo o descripcin; los datos de la pantalla se
organizan de mayor a menor orden segn el criterio seleccionado.
- Al realizar la bsqueda, esta ser de modo despiste, es decir, mostrar en pantalla solo los resultados qu
- Al ingresar en la seccin ver, se podrn ver aparte en pantalla los detalles del material seleccionado. Se regres
- Al ingresar en la seccin editar, se enlaza directamente con la pantalla de ingreso de nuevo artculo, con los da
- Al seleccionar la opcin Eliminar, el sistema preguntar si est seguro de eliminar el registro seleccion
- Al seleccionar la opcin de agregar stock, se hace un enlace con la pantalla de
actualizacin del stock (Bosquejo interfaz agregar stock en anexo) en la que se podr aumentar o dismin
- Al seleccionar Agregar nuevo artculo, se hace un enlace directo con el formulario para el
ingreso de un nuevo artculo.
134
Cdigo: 2.4
Nombre: Confirmacin de modificacin de datos en el stock desde el men de administracin de
Descripcin: Al ingresar nuevos materiales al departamento, provenientes de una peticin de compra; la can
- Debe existir dos materiales especficos pre cargado al sistema.
- Se anotaran las cantidades existentes de dos materiales distintitos, para as confirmar que se aumenta y dism

- Se visualiza en pantalla ventana de administracin de los materiales o artculos.
- Al montarse sobre el cuadro de texto se despliega en pantalla lista con los materiales listados en la base
- Se verifica la cantidad de dos de ellos.
Tarjeta de terminacin de lnea s617/1/14 = 100 unidades
Teclado Matriz SIEMENS 617/7/07458/000 = 100 unidades
- Al cada uno de los registros antes mencionados, se cliquea sobre la opcin Agregar stock. (procesos separad
- Se enlaza hacia la pantalla de Actualizacin del stock.
- Al primero se aumenta la cantidad en 10 unidades, ingresando la cantidad en cuadro de texto y procesand
- Se procesa la actualizacin mediante botn en pantalla.
Resultado Esperado:
- El sistema muestra en ventana administrativa una lista con los materiales ingresados a la base de datos in
- Al filtrar la bsqueda bien sea por cdigo o descripcin; los datos de la pantalla se organizan de may
- Al realizar la bsqueda para ambos materiales se confirma nuevamente que esta se realice en modo despiste
135
- Al seleccionar la opcin de agregar stock, se hace un enlace con la pantalla de
actualizacin del stock (Bosquejo interfaz agregar stock en anexo) en la que se podr
aumentar o disminuir cantidad de un material seleccionado previamente.
- Se selecciona esta opcin para el primer material, al mismo se le aumentan 10 unidades en
cuadro de texto, se seala la opcin de aumentar, y se procesa el cambio.
- Aparece ventana de confirmacin de datos actualizados y opcin para regresar a la
pantalla de administracin.
- Se repite el los 2 pasos anteriores, pero disminuyendo la cantidad del segundo material en
15 unidades.
- Se confirman los cambios en el stock o cantidad de cada material en la ventana
administrativa, quedando como sigue:
Tarjeta de terminacin de lnea s617/1/14 = 110 unidades
Teclado Matriz SIEMENS 617/7/07458/000 = 85 unidades
- Se comprueba que esta misma operacin puede ser realizada desde el botn de
actualizacin utilizando la pantalla o formulario de ingreso de datos de nuevos materiales.
Cdigo: 2.5
Nombre: Generar un informe de la situacin actual de los materiales en el almacn. Presentar un info
Descripcin: Se podr imprimir una o ms hojas que muestren la situacin actual de los materiale
- Debe existir materiales pre cargado al sistema.

- Se visualiza en pantalla ventana de administracin de los materiales o artculos.
- Al montarse sobre el cuadro de texto se despliega en pantalla lista con todos los materiales listado
- Se verifica la cantidad de dos de ellos.
136
1361
- Por medio del explorador, se verifica vista preliminar del informe.
- Se podr mandar a imprimir desde la vista previa o desde la opcin de impresin
del explorador web que se use (por ejemplo usando la clave CTRL+P o
Archivo/Imprimir del explorador Mozilla Firefox)
Resultado Esperado:
- El sistema muestra en ventana administrativa una lista con los materiales
ingresados a la base de datos indicando su cdigo, descripcin y cantidad; adems
de contar con los enlaces Ver, editar, eliminar y agregar stock (para cada registro).
- Al filtrar la bsqueda bien sea por cdigo o descripcin; los datos de la pantalla se
organizan de mayor a menor orden segn el criterio seleccionado.
- Se observa vista previa de las hojas contentivas del informe de inventario.
- Se imprime informe segn modelo mostrado en pantalla.
Pruebas segunda iteracin
Para los prototipos desarrollados durante sta segunda iteracin, se

ejecutaron las siguientes pruebas, reunidas en los siguientes tres (03) casos:
Cdigo: 3
Nombre: Seleccionar o introducir nombre del tcnico para preparar un despacho
Descripcin: Se ingresa o selecciona el nombre de un tcnico (con su respectivo carnet de identificacin) y se p
- Debe existir al menos un tcnico cargado a la base de datos. (Evelio Lepage - 813245)

- Desde el men principal se ingresa a la seccin de despacho.
- Se visualiza pantalla de preparacin de despacho (Registro de nuevo despacho).
- Aparece cuadro de texto mostrando la fecha actual (al momento de realizar el despacho)
- En ventana o cuadro de texto desplegable aparecen el o los tcnicos cargados a la base
de datos.
- Se selecciona el tcnico de la descripcin (pudiendo seleccionar a cualquiera de ellos),
bien sea cliqueando sobre el nombre de la lista desplegada o presionando la tecla de la
inicial de su nombre (bsqueda por descarte)
-Se tendr al tcnico preparado para asignarle el material y la cantidad correspondiente.
Resultado Esperado:
- Se visualizar pantalla para el registro de un nuevo despacho.
- Aparecern los tcnicos cargados a la base de datos en lista desplegable.
- Se podr seleccionar tcnico de la condicin, buscndolo por las inciales de su nombre o
seleccionndolo directamente de la lista.
- El tcnico seleccionado se carga con su correspondiente nmero de carnet.
- Se mantendr las opciones para seleccionar los materiales a despacharle y su cantidad
correspondiente
Cdigo: 4
Nombre: Asignar material y cantidad del mismo que van a ser despachados al tcnico previamente carg
Descripcin: Se ingresarn el nombre del material desde un cuadro de texto o lista desplegable y se cargara
- Debe existir un tcnico cargado desde la base de datos en la ventana correspondiente.
- Debe existir al menos un material cargado a la base de datos con disponibilidad. (Tarjeta de terminacin de
- Se intentar en primera instancia intentar asignar una cantidad superior a la existente en
almacn para el material seleccionado.
- Por ultimo se realizar un despacho por una cantidad menor a la existente.

- Con los datos del tcnico ya pre cargados, se trabajar desde la misma pantalla de la
prueba anterior.
- En cuadro correspondiente a los materiales, se selecciona el de la condicin para el
despacho.
- Se verifica su cantidad en el almacn en cuadro de estado informativo.
- Se intenta despachar una cantidad superior a la indicada en cuadro de estado. (125
unidades)
- Se ingresa valor inferior de despacho. (10 unidades)
- Se presiona botn para confirmar el despacho.
- Aparece ventana de confirmacin para el despacho realizado.
- Se confirma el despacho, buscando el detalle del inventario segn prueba cdigo 2.4 para
le material.
Resultado Esperado:
- Se visualizar pantalla para el registro de un nuevo despacho con tcnico pre cargado
(Evelio Lepage 813245)
- Aparecern los materiales cargados a la base de datos en lista desplegable.
- Se podr seleccionar el material de la condicin, buscando por las inciales de su
descripcin o seleccionndolo directamente de la lista.
- El material seleccionado se carga al sistema indicando su cantidad actual en el inventario.
(110 unidades)
- Se intentar realizar un despacho por la cantidad de 125 unidades de dicho material
(usando botn de registro), a lo que el sistema responder que no existen suficientes
unidades en el inventario, pues solo existen 110.
- Luego realiza correcto despacho por la cantidad de 10 unidades.
- El sistema avisa que el despacho se ha realizado exitosamente, permitiendo regresar al
inicio para otro despacho.
- Segn prueba 2.4, se confirma que el estatus del material de la prueba es de 100 unidades
luego de realizado el registro del despacho.
Evaluacin de la Prueba: Completa 100%
Cdigo: 4.1
Nombre: Generacin de registro de material faltante.
Descripcin: Con un tcnico previamente cargado para el despacho, se ingresar el nombre del materia
lmite permitido.
- Debe existir un tcnico cargado desde la base de datos en la ventana correspondiente.
- Debe existir al menos un material cargado a la base de datos con disponibilidad. (Tarjeta de terminacin de
- Su cantidad mnima permitida es 10 unidades.
- Se realizar un despacho por la cantidad de 91 unidades.

- Con los datos del tcnico ya pre cargados, se trabajar la pantalla para un nuevo despacho.
- En cuadro correspondiente a los materiales, se selecciona el de la condicin para el despacho.
- Se verifica su cantidad en el almacn en cuadro de estado informativo.
- Se despacha la cantidad de la condicin. (91 unidades)
- Se presiona botn para confirmar el despacho.
- Aparece ventana de confirmacin para el despacho realizado.
Resultado Esperado:
- Se visualizar pantalla para el registro de un nuevo despacho con tcnico pre cargado
(Evelio Lepage 813245)
- Aparecern los materiales cargados a la base de datos en lista desplegable.
- Se podr seleccionar el material de la condicin, buscando por las inciales de su descripcin o selecc
- El material seleccionado se carga al sistema indicando su cantidad actual en el inventario.
(100 unidades)
- Se realiza el despacho por la cantidad de 91 unidades de dicho material (usando botn de registro).
- El sistema avisa que el despacho se ha realizado exitosamente, permitiendo regresar al inicio para otro de
- Al sobrepasar el lmite permitido, pues solo existen 9 unidades (de 10 mnimas permitidas); el sistema crear
- El material podr seguir siendo despachado, hasta llegar a cero (0 unidades) su existencia; aunque continuar
Evaluacin de la Prueba: Completa 100%
140
Pruebas tercera iteracin
Para prototipos desarrollados durante sta iteracin, se ejecutaron las

siguientes pruebas, reunidas en los siguientes cuatro (04) casos:
Cdigo: 5
Nombre: Cierre de periodo de reportes.
Descripcin: El usuario del sistema podr en un periodo de tiempo que considere prudente o necesario, cerr
- Se deben de haber realizado un mnimo de un despacho de materiales para cada tcnico listado en la base

- El usuario podr cerrar el periodo de despachos desde el men principal del sistema, presionando botn
- El sistema le preguntara al usuario, si est seguro de querer cerrar el periodo de operaciones y com
- El usuario confirma el cierre, a lo que el sistema arroja mensaje de confirmacin para el
periodo cerrado y vuelve al men principal.
- Se creara entonces un registro de cada transaccin o despacho realizado desde el ltimo cierre para cada u
- Dicho registro no podr ser modificado de ninguna forma posible, y se guardar en el
sistema para su posterior consulta.
Resultado Esperado:
- Creacin efectiva de los periodos de despacho, presionando botn de cierre de despacho.
- Cada operacin o transaccin realizada en dicho periodo, se guarda segn formato establecido junto con el cli
- Confirmacin de los mensajes descritos segn pasos de ejecucin.
141
Cdigo: 5.1
Nombre: Consulta de periodos de reportes previamente cerrados
Descripcin: El usuario del sistema podr en cuando as lo considere prudente o necesario, consultar los repor
- Se deben de haber realizado un mnimo de un despacho de materiales para cada tcnico listado en la base
- Al tcnico Evelio Lepage, se le despachara previamente 30 unidades de Tarjeta de
terminacin de lnea s617/1/14 (10 en da y 20 en otro)
- Se deben haber cerrado los periodos de despacho para cada uno de los tcnicos.

- El usuario deber haber cerrado el periodo de despachos en curso, desde el men principal del sistema, pres
- El usuario desde el men principal, ingresar a la seccin de reportes o consulta de reportes de tcnic
- En el cuadro de texto desplegable, aparecern el o los tcnicos cargados en la base de datos y que adem
- Se selecciona el tcnico de la descripcin (pudiendo seleccionar a cualquiera de los que en la lista aparecen),
- Se presiona el botn de consulta de la ventana de reportes de tcnicos.
- Se muestra en pantalla el enlace al reporte o los reportes acumulados por el tcnico seleccionado en lo
- Al seleccionar el o los enlaces correspondientes (cada uno por separado), el sistema muestra formato p
Resultado Esperado:
- Se visualiza en pantalla ventana de consulta para los reportes de los tcnicos.
- Del cuadro de bsqueda/consulta desplegable, se elije al tcnico de la descripcin el cual se carga a la pant
- Al presionar en consulta, aparecen los reportes por periodo de cierre para el tcnico en cuestin.
- Se verifica que posee un reporte con dos despachos realizados en das distintos de un mismo material d
142
- El informe incluir un detalle indicando fe de recibo para el tcnico en cuestin, su carnet y
espacio para su firma.
- El informe adems presenta fe de entrega con espacios en blanco, para que sean
rellenados luego de ser impreso el reporte (en caso de ser necesario).
- El reporte se podr ver en vista previa o preliminar segn las utilidades del explorador y
podr ser impreso cuando as sea requerido.
- Las consultas de los reportes de periodos pueden hacerse aun mientras estos periodos
estn activos, el cierre de consultas solo impone un salto entre un periodo de revisin y otro,
sin limitar las consultas. El periodo sin cerrar siempre aparecer sealado como periodo sin
cerrar o periodo abierto.
Cdigo: 5.2
Nombre: Creacin de reportes de pedidos especiales.
Descripcin: Se crearn reportes especiales de salida para cada tcnico por separado (que incluirn los datos
- Se deben de haber realizado un mnimo de un despacho de materiales que necesite autorizacin para
Evelio Lepage 813245.
- Se ingresar un nuevo material a la base de datos que necesite dicho tipo de autorizacin. Telfono interno am

- Para la ejecucin de esta prueba se siguen los mismos pasos de la prueba cdigo 2 para el ingreso de un mat
- Para el despacho del material en cuestin, se siguen los pasos de la prueba cdigo 4. Se
despacha el material que requiere autorizacin al tcnico de la condicin.
- Se confirma que el despacho ha sido realizado con xito.
- Al realizar el despacho exitosamente, se crea automticamente el registro que va hacia el formato especial p
- Dicho informe o formato de autorizacin para la salida de materiales y equipos puede ser consultada
143
1431
Resultado Esperado:
- Se crea un registro de despacho que va al reporte del periodo corriente.
- Dicho registro adems, se inserta en formato preparado para autorizacin de materiales
especiales, el cual puede ser consultado junto al formato para los reportes de periodos.
- De no realizarse ningn despacho de material especial (que necesite autorizacin de
salida) alguno, el formato de autorizacin quedara en blanco.
Cdigo: 5.3
Nombre: Consulta de reportes especiales.
Descripcin: El usuario del sistema deber cada vez que realice un despacho de un material que requ
- Se deben de haber realizado un mnimo de un despacho de materiales que necesite autorizacin para
Evelio Lepage 813245.
- El material despachado ser una unidad de Telfono interno amper TPAS.

- Previamente, al tcnico sealado en la condicin se le realiza un despacho 1 material que necesite autorizaci
- El usuario desde el men principal, ingresar a la seccin de reportes o consulta de reportes de tcnic
- En el cuadro de texto desplegable, aparecern el o los tcnicos cargados en la base de datos y que adem
- Se selecciona el tcnico de la descripcin (pudiendo seleccionar a cualquiera de los que en la lista aparecen),
- Se presiona el botn de consulta de la ventana de reportes de tcnicos.
- Se muestra en pantalla el enlace al reporte de materiales especiales (junto al reporte del periodo en curso).
- Al seleccionar el enlace correspondiente, el sistema muestra formato de autorizacin de
salida de materiales y equipos con los registros del despacho del material que necesita de
autorizacin.
- Dicho reporte puede ser visualizado en vista previa, impreso desde las opciones del
explorador, enviado va mail para su gestin.
Resultado Esperado:
- Se visualiza en pantalla ventana de consulta para los reportes de los tcnicos.
- Del cuadro de bsqueda/consulta desplegable, se elije al tcnico de la descripcin el cual
se carga a la pantalla.
- Al presionar en consulta, aparecen los reportes por periodo de cierre para el tcnico en
cuestin, adems de aparecer el reporte para los materiales especiales.
- Se verifica que dicho reporte, siga el formato de la autorizacin para salida de materiales y
equipos; y que contenga en el lugar correspondiente el registro del material despachado en
la condicin que requiere de dicha autorizacin.
- El reporte se podr ver en vista previa o preliminar segn las utilidades del explorador y
podr ser impreso o enviado va mail para su gestin.
- Las consultas de los reportes de periodos pueden hacerse aun luego de que los periodos
se han cerrad.

Pruebas cuarta iteracin
Para los ltimos prototipos desarrollados durante sta cuarta iteracin, se

ejecutaron las siguientes pruebas, reunidas en los siguientes dos (02) casos:
Cdigo: 6
Nombre: Acceso al sistema
Descripcin: Desde el explorador predeterminado (Microsoft Explorer), se ingresa el link o URL del sistema de ge
- Se acuerda con el usuario mantener el link del sistema dentro de la carpeta de favoritos
(Internet Explorer) para facilitar su acceso.
- Se habr definido previamente en la tabla se usuarios en la base de datos, el usuario:
smnpdr86 y la clave: 21tesis.
- Se ingresara un usuario distinto al predeterminado y la clave correcta.
- Se ingresa el usuario correcto y una clave distinta.
- Se ingresa el usuario y la clave distinta.
- Se ingresa el usuario y la clave correcta.
- Se contara con botn de acceso, luego del ingreso de los datos.

- El usuario ingresa la direccin web o url del sistema de gestin en su explorador predeterminado
- Aparece la ventana para el acceso de usuario o login del sistema.
- Habr un cuadro de texto para el usuario y otro para el ingreso de la clave.
- Se ingresara en cuadro de usuario smnpdr y la clave 21tesis, presionando botn de acceso.
- Se verifica que el sistema no permita el acceso.
- Se ingresa en cuadro de usuario smnpdr86 y la clave 21tesi, presionando botn de acceso.
- Se ingresa en cuadro de usuario smnpdr8 y la clave 21tesi, presionando botn de acceso.
- Se ingresa en cuadro de usuario smnpdr86 y la clave 21tesis, presionando botn de acceso.
- Se verifica que el sistema permita el acceso.
Resultado Esperado:
- Se confirma que el link del sistema dirija al explorador web hacia la aplicacin desarrollada.
- Se confirma la ventana de login o acceso al sistema.
- Al ingresar usuario correcto y clave incorrecta el login arroja mensaje similar al de clave o usuario incorrec
- Al ingresar usuario incorrecto y clave correcta el login arroja mensaje similar al de clave o
usuario incorrecto, verifique los datos e intente de nuevo.
- Al ingresar usuario y clave incorrecta el login arroja mensaje similar al de clave o usuario incorrecto, verifi
- Al ingresar usuario correcto y clave correcta el login arroja mensaje de bienvenida dirigiendo al usuario al men
- En men principal se confirma los mens accesos a los usuarios y su administracin, a los materiales y su adm
146
Cdigo: 7
Nombre: Crear un traslado especial.
Descripcin: El usuario podr generar una orden de traslado especial para cualquier material, artculo,
- Contar con todos los datos necesarios para llenar formulario de translados especiales.

- El usuario desde le men principal accede al men de reportes o informes.
- El usuario ingresa a la seccin de reporte o traslados especiales.
- Se muestra en pantalla formulario para ingreso de datos en cuadros de texto, segn formato de traslad
- Se selecciona el tipo de solicitud.
- Se ingresan los datos del destinatario en cuadros de texto
- Se ingresan la descripcin, la cantidad y el valor de los materiales, artculos o tems, igualmente en cua
- Con todos los datos ingresados se genera la vista previa del reporte utilizando para ello
botn en pantalla.
- Se podr imprimir el reporte, enviar por correo, o editar nuevamente, segn el requerimiento del
Resultado Esperado:
- Acceso correcto al men de los reportes.
- Acceso efectivo al formulario de Traslado de Materiales y Equipos.
- Verificar que siga los campos predeterminados en el formato.
- Comprobar la seleccin del tipo de traslado utilizando botones de seleccin.
- Ingresar los datos correspondientes en cuadros de texto de manera efectiva.
- Generar vista previa del reporte utilizando botn de envo en pantalla.
- Imprimir el reporte utilizando utilidad del explorador.
147
5.1.4 Fase IV: Mantenimiento
sta fase constituye el estado normal del proyecto de desarrollo, es decir,

es durante esta etapa, cuando se implementaron los prototipos del sistema
desarrollado en las tareas de la fase II y que fueron probados segn los casos
de la fase III. Durante esta fase adems, se incluyeron una serie de propuestas
y sugerencias relacionadas sobre todo a las interfaces de usuario.
Las interfaces de usuario implementadas, y que tienen una relacin directa

con las tareas de ingeniera elaboradas (Vase Resultados, p. 112) y cuyo
funcionamiento fue probado siguiendo los casos antes expuestos (dem, p. 124)
se muestran a continuacin organizadas por iteraciones.
Interfaces Primera Iteracin
Las interfaces, relacionas con las tareas de ingeniera de la primera

iteracin, se muestran a continuacin en las siguientes figuras:
148
1481

Interfaces Segunda Iteracin
Las interfaces, relacionas con las tareas de ingeniera de la segunda

150
1501
Interfaz de registros en reportes de artculos escasos (ingreso desde men principal)

Interfaces Tercera Iteracin
Las interfaces, relacionas con las tareas de ingeniera de sta iteracin, se

muestran a continuacin en las siguientes figuras:
Consulta de Reporte de Periodo N0 (producto de pantalla anterior)

Interfaces Cuarta Iteracin
Las interfaces, relacionas con las tareas de ingeniera de sta ltima

Consulta de informe de Materiales Especiales N0 pantalla anexo anterior

Prototipo Men principal

155
5.1.5 Fase V: Muerte
En esta etapa del proyecto, se ha comprobado el correcto funcionamiento

de cada uno de los mdulos del sistema en el propio campo de trabajo. Cada
uno de los prototipos funciona correctamente y en forma conjunta, de modo tal
proveen al departamento de mantenimiento y operaciones de telefona pblica
de un sistema prototipo capaz de controlar en forma automatizada entre otras
cosas, la entrada y salida de materiales, la generacin de reportes de
despacho, los informes de inventario, las autorizaciones de salida de materiales
y autorizaciones de traslado, adems de generar ordenes de compra en forma
automtica, basado en el reabastecimiento predictivo de insumos,
contribuyendo con eso ala ejecucin de las labores de mantenimiento a la
planta de telefona pblica del Estado Monagas, perteneciente a la CANTV.
La documentacin necesaria para darle no solo soporte al sistema, sino

tambin, para expandir sus funcionalidades (considerando el hecho, de que aun
puede ser ampliado en cuanto a funcionalidad y capacidad de procesamiento se
refiere) y mejorar las ya existentes, se resumen en el contenido de este
proyecto de investigacin.
Los requerimientos anotados en las tarjetas historias de usuario, que

dieron paso luego a la elaboracin de tareas de ingeniera para producir el
cdigo funcional del sistema, incluyendo las diferentes pruebas realizadas
adems de los prototipos de sistema implementados y mostrados como
interfaces de usuario, estn documentados en detalle en el contenido del
proyecto. (Vase Resultados, p. 87)
Los cdigos del sistema, elaborados en un entorno libre y que constituyen

la documentacin principal y base de todo proyecto desarrollado bajo XP, se
156
1561
encuentra sealada en la versin digital del proyecto (incluyendo los scripts del
sistema y de la base de datos, en la seccin de los anexos.
Para finalizar, y considerando que el sistema fue desarrollado

ntegramente de la mano del usuario, ste no requiri la elaboracin de un
manual de usuario, por lo que siguiendo el principio fundamental de XP, que es
trabajar con la mayor sencillez y practicidad posible, no se elabor manual
alguno.
5.2 Anlisis Costo - Beneficio
El anlisis costo beneficio se define como la relacin entre el beneficio

percibido por los usuarios del sistema para el control y gestin de los materiales
en el almacn del departamento de mantenimiento y operacin de telfonos
pblicos de la Compaa Annima Nacional Telfonos de Venezuela (CANTV)
del estado Monagas, o Proyecto XP y el costo en que incurre la CANTV para
realizar el trabajo de investigacin; con la finalidad de justificar en trminos
monetarios, o lo que es igual, en cantidades financieras su desarrollo.
Para calcular el costo del Proyecto XP, es necesario, es necesario, definir

y separar tanto los costos de desarrollo e implementacin como el costo de
operacin del sistema. Dentro de los primeros se incluyen los costos de las
herramientas (hardware y software), de la mano de obra (anlisis de
requerimientos del sistema y desarrollo de la aplicacin), y de implementar el
sistema en el lugar de trabajo con su correspondiente etapa de adiestramiento.
Los costos de operacin vendrn dados por el costo en que se incurren al

utilizar el sistema propuesto, utilizando como variable o medida bsica para el
clculo monetario o financiero, el tiempo de uso de la aplicacin automatizada,
al ser este (tiempo) el aspecto fundamental que resalta y estimula la creacin
del proyecto, si se compara con el tiempo que lleva realizar las mismas
operaciones y transacciones en forma manual (no automatizada).
Igualmente para el anlisis de los beneficios del proyecto, se evaluaron los

beneficios tangibles, duros o financieros; basado en el consumo de tiempo
estimado que lleva realizar las tareas de manera manual vs realizarlas en forma
automtica a travs del sistema propuesto. Dicha evaluacin se realizar
considerando cantidades descontadas, utilizando para ellos el mtodo el tiempo
de recobro de la inversin, el del valor presente neto y el ndice costo beneficio
o IRt.
En este tipo de proyecto, el mayor peso para la decidir en un anlisis de

costo - beneficio, lo llevar el anlisis de los beneficios intangibles, los cuales
no son tomados en cuenta, ni en el clculo del TRI ni en otros mtodos de
anlisis de costos como el del VPN o Valor Presente Neto. (12Manage
Management Communities). Por lo tanto en el anlisis de los beneficios del
sistema propuesto, se tomar en cuenta tanto los beneficios intangibles
cuantitativos como los beneficios intangibles cualitativos.
5.2.1 Costos de Desarrollo e Implementacin
A continuacin se describen los costos pertenecientes a este punto:
Costo de hardware y software: se incluye el costo relacionado con la

adquisicin de estas herramientas. En este caso del diseo y desarrollo del
Proyecto XP, no se adquiri ningn tipo hardware adicional, pues se dispona
de el, los anlisis (requerimientos y tiempos de ejecucin del trabajo) fueron
realizados de manera manual, y la gran mayora de la plataforma de software
utilizado, pertenece al entorno libre, y las que no, se contaba previamente con
ellos. En trminos del departamento de telefona pblica donde se
implementar el proyecto, ste ya posee los equipos de computacin
necesarios para la puesta en marcha del sistema propuesto, en consecuencia el
desembolso por la adquisicin del mismo es nulo.
Costos en mano de obra: es el costo representado por el analista del

sistema y el usuario que intervienen en el proyecto. Es importante destacar que
durante la etapa de desarrollo, en analista de sistema (Gerente del proyecto
XP), desempaar las mismas funciones de usuario principal del sistema, por
los costos de desarrollo e implantacin estarn reflejados en el pago asignado a
quien realiza dichas tareas, es decir, el pasante del departamento de
mantenimiento y operacin de telfonos pblicos de la CANTV Monagas.
Costos de Adiestramiento: es el costo en que se incurrira para

ensearles a los usuarios como utilizar el sistema propuesto. Al respecto es
importante sealar que gracias a las caractersticas que ofrece el desarrollo de
aplicaciones bajo la metodologa de XP, en las que el usuario final (forme o no
parte del equipo de desarrollo) se encuentra muy cercano al desarrollo de la
aplicacin, no es necesario incurrir en costos de adiestramiento; pues el
sistema funcionar tal cual el usuario lo ha venido verificando durante las
iteraciones y avances del proyecto.
Las propiedades de la aplicacin son ampliamente conocidas por el

usuario final, sobre todo en la fase final del proyecto; inclusive las
caractersticas simples de la aplicacin implican un uso intuitivo de la misma, en
el que cualquier otro usuario pueda ejecutar con facilidad las utilidades de la
aplicacin.
En cuadro n 6, se detallan cada uno de los costos generados por el
desarrollo del proyecto, en este se desglosa el costo por mano de obra y
personal, dejando de lado los costos de papelera y de electricidad (al
considerarlos no significativos):
Costos de Desarrollo e Implantacin
Costos Bs.F.
Costos de Hardware y Software
Hardware + 0,00
Software 0,00
Total costos de Hardware y Software 0 Bs.F.
Costo Mano de Obra (sueldo * tiempo)

Gerente Proyecto XP (tesista)
Pago mensual personal (1
Tiempo de
desarrollo 6
Total costos Mano de Obra 2400,00 Bs.F.
Costos de Adiestramiento
(no necesario) 0,00
Total costos Adiestramiento 0,00
TOTAL COSTOS DESARROLLO E

IMPLEMENTACION 2400,00 Bs.F.
Cuadro n 6: Costos de desarrollo e implementacin.
160
1601
5.2.2 Costo de Operacin
Entre los costos de operacin se incluye lo siguiente:
Costo de operacin: este se calcul en base al tiempo que lleva utiliza el

sistema automatizado propuesto por medio del desarrollo del proyecto y el valor
en dinero que eso significa. Es decir, representar el valor que paga o con le
cual remunera la empresa CANTV al usuario del sistema para que este ejecute
la tarea correspondiente utilizando el sistema.
Los costos estarn basados en una escala mensual de operacin,

utilizando estimados en lo que a tiempo de uso del sistema se refiere, derivado
principalmente de la experiencia acumulada.
Se incluir adems los costos en materiales utilizados por el sistema

(papelera principalmente) y los costos de depreciacin del equipo utilizado
siguiendo el mtodo de depreciacin en lnea recta, considerando una vida til
de aproximadamente 4 aos para el equipo de computacin.
Se presentar igualmente una comparacin, entre los costos de operacin

del sistema propuesto vs el costo de operacin del sistema de trabajo utilizado
antes de la automatizacin de las tareas de despacho de materiales del
almacn de telfonos pblicos en la CANTV Monagas.
Los costos de operacin para el sistema propuesto, se detallan en el

cuadro n 7, a continuacin:
Costos de operacin sistema propuesto
Costos Bs.F.
Costos de mano de obra mensual para la operacin delTsistema
Usuario: Tcnico Especialista en Telefona Pblica

Sueldo mensual del usuario
Sueldo diario por hora (8 horas de trabajo)
Tiempo de ejecucin de las transacciones
Tiempo de ejecucin de las transacciones en horas =
Das hbiles laborables de trabajo mensuales
Total costos mensuales de operacin del sistema (Bs.F.)

(sueldo diario * tiempo de ejecucin * das hbiles laborables)
Costo mensual de papelera
Precio unitario resma papel (500 hojas)

Precio unitario por hoja de papel
Cantidad unidades de papel utilizado al mes
Total costos mensuales de papelera (Bs.F.)

(precio unitario por hoja * cantidad de hojas usadas al mes)
Costos de depreciacin mensual del equipo (mtodo en lnea recta)
Vida til del equipo (entre 3 y 5 aos) Costo de adquisicin del bien
Valor de recupero del bien

Valor a depreciar
Costo de Depreciacin (valor a depreciar/vida til)
Total costo mensual depreciacin (mtodo lnea recta)

(costo de depreciacin / 12 meses)
TOTAL COSTO MENSUAL DE OPERACIN SISTEMA PROPUESTO
Cuadro n 7: Costo mensual de operacin del sistema propuesto

Dichos costos, pueden y deben ser comparados con los costos de
operacin del sistema anterior. Este sistema heredado, no es ms que el
desarrollo o ms bien la ejecucin de las distintas tareas relacionadas con el
despacho de materiales del almacn, realizadas en forma manual, tareas que el
Proyecto XP busca automatizar.
Cabe destacar que a pesar de no utilizar de la misma manera el equipo de

cmputo o hardware con el sistema manual, igualmente este se deprecia, pues
est en el departamento y es sub-utilizado, sin ser aprovechado al mximo en lo
que a tareas de gestin y control de almacn se refiere. Los costos del dicho
sistema se muestran a continuacin, en los cuadros n 8 y n 9.
Costos de Operacin (sistema manual)
Costos Bs.F.
Costos de mano de obra mensual para la operacin del sistema
Usuario: Tcnico Especialista en Telefona Pblica

Sueldo mensual usuario
Sueldo diario por hora (8 horas de trabajo)
Tiempo de ejecucin de las transacciones
Tiempo de ejecucin de las transacciones en horas =
Das hbiles laborables de trabajo mensuales
Total costos mensuales de operacin del sistema (Bs.F.) 156.25 Bs.F.

(sueldo diario * tiempo de ejecucin * das hbiles laborables)
Cuadro n 8: Costo mensual mano de obra del sistema heredado

Costos de Operacin (sistema manual) Costo mensual de papelera
Precio unitario resma papel (500 hojas) 12.50

Precio unitario por hoja de papel 0.03
Cantidad unidades de papel utilizado al mes 350
Total costos mensuales de papelera (Bs.F.) 8.75 (precio unitario por ho
Costos de depreciacin mensual del equipo (mtodo en lnea recta)
Vida til del equipo (entre 3 y 5 aos) 5 aos

Costo de adquisicin del bien 1500.00
Valor de recupero del bien 700.00
Valor a depreciar 800.00
Costo de Depreciacin (valor a depreciar/vida til) 160.00
Total costo mensual depreciacin (mtodo lnea recta) 13.33 (costo de depreciacin
TOTAL COSTO MENSUAL DE OPERACIN SISTEMA HEREDADO

(operacin + papelera + depreciacin)
Cuadro n 9: Costo mensual de operacin del sistema heredado
A pesar de no tratar montos de dinero que sean significativos, sobre todo

cuando se trata de una compaa con el potencial econmico de la CANTV;
tampoco es menos cierto, que no utilizar al mximo las capacidades de los
sistemas de informacin disponibles, sobre todo cuando estos reduzcan aun
ms los costos, est dentro de los planes de operaciones en este tipo de
organizacin, donde cualquier ahorro de tiempo, horas hombre de trabajo,
costos, en fin, cualquier ahorro es valioso.
Siguiendo la misma lnea, se confirma por medio de un simple anlisis de
los cuadros anteriores; que tan importante como el ahorro en trminos de costo,
se puede observar un gran ahorro en trminos de tiempo de ejecucin de las
tareas, aspecto en extremo valioso, que a la larga puede ser dirigido al
desarrollo de otras tareas ms productivas y de mayor alcance dentro del
departamento.
En el cuadro n 10, se expondr un anlisis de los costos de operacin del

sistema manual y del sistema automatizado para el control y la gestin de los
materiales en el departamento de mantenimiento y operacin de telfonos
pblicos de la CANTV Monagas.
Dichos costos, sern proyectados a futuro, y a travs de ellos se pudo

confirmar una gran reduccin de los costos, traducida en un ahorro de poco
ms del 70%. Es importante destacar, que los costos de depreciacin no son un
factor importante de comparacin, pues este fenmeno ocurre, este o no el
nuevo sistema instalado (el equipo de computo igualmente se deprecia).
Comparacin de los costos - sistema manual vs sistema automtico
Operacin
Costos (Bs.F.)
Sistema Manual Sistema Automtco Diferencias
En un ao de operacin continua (* 12 meses)

Sistema Manual Sistema Automtco Diferencias
% de ahorro = 72.35 %
Cuadro n 10: Comparacin de costos (sistemas manual vs. automatizado)

A continuacin, se presenta el anlisis de los beneficios, diferenciando los
beneficios intangibles de los tangibles.
5.2.3 Anlisis de los Beneficios
Dado que los principales beneficios que se buscan con la implantacin del
sistema, se refleja en trminos de optimizacin del tiempo de ejecucin de las
operaciones, y mayor operatividad en el control y gestin de los materiales del
almacn de telfonos pblicos de la CANTV Monagas; y no tanto en cuanto a
obtencin de menores costos operativos, es necesario separar los beneficios
suaves e intangibles de los beneficios duros o tangibles.
5.2.3.1 Beneficios Intangibles (cuantitativos y cualitativos)
Entre los beneficios intangibles, se pueden mencionar:
Mayor facilidad para los usuarios para la ejecucin de las tareas

relacionadas con el despacho de materiales, dado que la ubicacin de los datos
de los tcnicos y de los diversos materiales se realiza de forma bastante fcil e
intuitiva, lo cual contribuye una mejor realizacin del trabajo.
Reduccin al mximo de los errores en las labores de despacho y

creacin de reportes correspondientes; pues sus causas ms comunes (gran
cantidad de cdigos, descripciones de materiales difciles de manejar, manejo y
gestin de los distintos reportes de despachos) son atacados directamente
dentro del sistema, el cual cuenta con cdigos y materiales pre cargados,
mdulos de despacho de fcil manejo, creacin automtica de reportes de
periodos de despacho y autorizaciones de salida, y mdulos con formularios
para la creacin automtica de informes de translados especiales, todas
utilidades que evitan la duplicacin de datos y los errores de vaciado, forma y
cantidad en los materiales despachados a tcnicos especficos.
Los periodos de cierre de despacho y las rdenes de compra, podrn ser

fcilmente consultados y gestionados, stos podrn ser enviados va correo
electrnico al ente que se encargado de procesarlos (Analista de Soporte
Administrativo), o impresos en fsico para su gestin correspondiente (tareas de
consulta de gestin, clculos de transacciones, anlisis de material
despachado, etc.)
El sistema aportar integridad en los diversos inventarios que se llevan

dentro de la organizacin CANTV Monagas, tanto en el Departamento de
operacin y mantenimiento de telfonos pblicos como en el rea de Anlisis de
soporte administrativo; pues el sistema funcionara como un sistema de
informacin transaccional, que aporte los datos bsicos en lo que a manejo de
materiales se refiere, de manera que ambos entes lleven cuentas y relaciones
de stock de materiales y ordenes de compra, basados en la informacin
generada por el sistema.
Las tareas de mantenimiento de la planta telefnica, se ver afectada lo

menor posible, en lo que se refiere a abastecimiento de materiales para el
mantenimiento correctivo y sobre todo predictivo; pues el sistema se encargar
de gestionar las compras automticamente antes de que los materiales entren
en una etapa critica de escases. Evidentemente, el sistema estar expuesto a
que los almacenes centrales con cuenten el material pedido, por lo que no
podr controlar al 100% el abastecimiento, pero si, las gestiones de ordenes de
compra las cuales sern totalmente predictivas.
Optimizacin en cuanto a la generacin, consulta, eliminacin y sobre todo
almacenamiento de reportes de traslado de materiales, despacho a los
tcnicos, autorizacin de salidas de materiales, envo y gestin de reportes y
dems tareas relacionadas con el almacn de telefona pblica, lo cual permitir
a los usuarios, la ejecucin ms rpida de dichas tareas y contar con mayor
tiempo disponible para la ejecucin de tareas productivas o de descanso.
5.2.3.2 Beneficios Tangibles
En cuanto a los beneficios tangibles, nos referiremos a las ventajas

econmicas que puedan ser cuantificables en base a la principal ventaja que
aporta el sistema; la reduccin considerable en el tiempo para la ejecucin de
las tareas, procedimientos o transacciones relacionadas con el control y gestin
de los materiales en el rea de desarrollo y aplicacin del proyecto. Al respecto
se pueden mencionar:
Un incremento considerable en la velocidad de realizacin de las tareas de

despacho de materiales, sobre todo en lo referente a la creacin, eliminacin y
consulta de las mismas.
Ms rpido procesamiento, control, consulta y gestin de los documentos

generados en la ejecucin de las transacciones de manejo del almacn, es
decir, generacin automtica de reportes, consultas de rpida bsqueda y
procesamiento, envos automticos de reportes de pedidos, generacin
inmediata de reportes de autorizaciones de salida, y creacin en corto tiempo
de traslados especiales por medio de formularios webs.
Todo esto se traduce en una reduccin considerable en el tiempo utilizado

por el empleado asignado al despacho y control de materiales y gestin de
reportes relacionados, considerando que la tarea se realiza en las horas pico
de trabajo, momento en el cual, el tiempo es el elemento ms escaso y de
mayor importancia para realizar labores de estudio de estado de gestin
departamental y muestra de resultados al equipo de trabajo, despacho de
averas diarias, creacin del plan de trabajo para el da o periodo corriente,
anlisis, control y evaluacin del trabajo realizado en da o periodos posteriores,
asignacin de trabajos especiales y dems tareas realizadas junto con el
despacho de materiales y gestin de reportes a primeras horas de trabajo por el
tcnico especialista (o pasante) de telefona pblica.
En el cuadro n 11, se comparan los beneficios tangibles e intangibles que

trae consigo la automatizacin de los procesos de control y gestin de almacn.
Beneficios
Mejoramiento en los ndices generales de desempeo en las labores de mantenimiento
Generacin automt
Cuadro n 11: Resumen beneficios tangibles e intangibles

Las ventajas econmicas que puedan ser cuantificables, se calculan en
base al tiempo de uso del sistema en trminos de las horas hombre o de mano
de obra empleada con la implantacin del prototipo del sistema Proyecto XP,
comparado con el tiempo utilizado en la realizacin de estas mismas tareas sin
el sistema automatizado. Dejando aparte la reduccin en costo por papelera
por papelera, al considerarlo poco significativo (<6%)
Basados en los datos estimados en los cuadros n 7, 8 y 9 y analizados

en cuadro n10, se puede elaborar un anlisis de los beneficios segn horas de
trabajo, presentada en el siguiente cuadro.
Consumo mensual de mano de obra
Sistema manual (heredado) Tiempo (Bs.F.)
Ejecucin de las transacciones al da 45 minutos

Ejecucin mensual de las transacciones 1125 minutos
1125 minutos son 18.75 horas
Sueldo tcnico especialista (mensual) 2000.00
Sueldo diario por hora (8 horas) 8.33
Total costos mensuales de 156.25 Bs.F.
operacin
Sistema automtico (Proyecto XP)
Ejecucin de las transacciones al da 10 minutos

Ejecucin mensual de las transacciones 250 minutos
250 minutos son 4.17 horas
Sueldo Tcnico Especialista (mensual) 2000.00
Sueldo diario por hora (8 horas) 8.33
Total costos mensuales de 34.72 Bs.F.
operacin
Relacin costos - horas mano de obra % (Bs.F.)
% de reduccin en horas trabajadas 77.78

% de reduccin en costos 77.78
Beneficio neto obtenido al mes 121.53 Bs.F.
Cuadro n 12: Beneficios obtenidos por mano de obra mensual
170
1701
En el cuadro anterior, se verifica que la reduccin solo en trminos de
horas de trabajo y de costo de mano de obra, es de ms del 70%, lo que sin
dudas representa un gran porcentaje de beneficio a favor del sistema propuesto
o Proyecto XP en contra del sistema heredado no automatizado.
Sin tomar en cuenta el ahorro por papelera de 7,50 Bs.F. y otros costos
menores, los beneficios netos generados por la utilizacin del nuevo sistema
propuesto son de 121, 53 Bs.F. mensuales. Haciendo un anlisis conjunto, los
beneficios mensuales con la implantacin en trminos de operacin son de
129,03 Bs.F.
Ahora, si se quiere tomar en cuenta el costo inicial de desarrollo del

sistema de 2400,00 Bs.F., para analizar la factibilidad econmica; entonces es
necesario agrupar estos datos y realizar un clculo del tiempo de recobro para
el sistema o periodo de recuperacin de la inversin (Graterol, 2003); y el
calculo del valor presente neto, para decidir si aceptar o no el proyecto en base
a un periodo establecido y una tasa de inters o de descuento (Neira, 2002) que
se establece en este caso particular en base a la tasa pasiva ofrecida por los
bancos Venezolanos a los ahorristas; establecida por el Banco Central de
Venezuela en 13%. Los clculos se presentan a continuacin.
5.2.3.2.1 Periodo de recuperacin de la inversin
Para el clculo del periodo para el cual se estima se vea recuperada la

inversin realizada presentado en el siguiente cuadro, se usar los datos del
cuadro n 10, en el cual se hace una comparacin de costos del sistemas
manual contra el automatizado, basado solo en los costos de operacin. Esto
se refleja en el cuadro n 13.
Periodo de recuperacin de la inversin
Flujo de caja negativo o desembolso 2400.00 Bs.F.
(costo de desarrollo e implantacin)
Periodos de flujo de ingresos 5 periodos

(5 periodos de 4 meses cada uno) 4 meses/periodo
Flujo de ingreso mensual 129.03 Bs.F.
(diferencias costo de operacin)
Diagrama de Flujos
Bs.F.
516.11 516.11 516.11 516.11 516.11
1 2 3 4 5
periodos
2400.00
Al finalizar el 4 periodo, se ha recuperado Bs.F. = 2064.44 Bs.F.
Al finalizar el periodo 4 falta por recuperar Bs.F. = 335.56 Bs.F.
Del periodo 4 al 5 se recupera (ingreso en 4 meses) 516.11 Bs.F.
Proporcin en meses para generar 335,56 Bs.F. = 2.60 meses

((cantidad a recuperar/recuperacin)*4meses))
Recuperacin de la Inversin se da en 18.60 meses
Cuadro n 13: Recuperacin de la Inversin
Claramente, se puede ver, que la recuperacin de la inversin en base a

los costos de operacin es de algo ms de 18 meses. Incluso si se considera el
hecho que le sistema podra y puede ser utilizado por el supervisor del
departamento, el periodo de recuperacin de la inversin podra se incluso
menor.
5.2.3.2.2 Clculo del valor presente neto y relacin costo beneficio.
El Valor presente neto o valor actual neto (VPN), se define como el valor
presente de una inversin a partir de una tasa de descuento, una inversin
inicial y una serie de pagos futuros (Graterol, 2003, p.6).
La idea del VPN es actualizar todos los flujos futuros al perodo inicial
(cero), compararlos para verificar si los beneficios son mayores que los costos.
Para este clculo, se usarn periodos de tiempo de 6 meses, teniendo en

cuenta que, tal y como se observo en el anlisis, la inversin se recupera en el
peor de los casos (solo un tipo de usuario, el que menos ingreso obtiene por
mano de obra) en poco ms de 18 meses.
Igualmente y como se menciona anteriormente, se us como tasa de

descuento la establecida por el BCV (Banco Central de Venezuela), utilizada
por los bancos del pas como tasa de inters pasiva para sus ahorristas.
Basado entonces, en los datos anteriormente manejados; que reflejan un

ahorro mensual de 129,03 Bs.F.; se puede establecer una serie de flujos de
dinero en el tiempo como la del cuadro n 14, a continuacin:
Beneficios del uso del sistema por periodos
Beneficio neto al mes = 129,03 Bs.F.
Periodo
Cuadro n 14: Relacin de beneficios por uso del sistema.
Con los datos completos, se procede al clculo del VPN y posterior

anlisis del ndice de la relacin costo beneficio.
Neira (2002), explica que si se designa como VFn al flujo neto de un

perodo n, (positivo o negativo), y se representa a la tasa de actualizacin o
tasa de descuento por i (inters), entonces el Valor Actual Neto (al ao cero)
del perodo n es igual a:
VPN: Sumatoria De Ingresos A Valor Presente (VAN) Inversin Inicial,

donde:
1
Por lo que, para 3 periodos (n=3), con una tasa de inters del 13%
(i=0,13), unos flujos por periodo segn el cuadro 17, y una inversin inicial de
2400,00 Bs.F., el VPN queda como sigue:
774,17 1548,33 2322,50

2400,00 . .
1 0,13 1 0,13 1 0,13
774,17 1548,33 2322,50
2400,00 . .
1,13 1,28 1,44
685,11 1209,63 1612,85 2400,00 . .

3507,59 2400,00 .
1107,59 . .
Con dicha tasa de inters y para un periodo de tiempo de 18 meses, la

opcin de utilizar el sistema en base al VPN, da como resultado un balance
positivo; por lo que es aconsejable la implementacin del sistema.
Para confirmar sta afirmacin, se puede calcular el ndice de costo

beneficio o IRt; basado en el resultado de este ndice se procede a decidir de la
siguiente manera: si el ndice es mayor que cero se acepta el proyecto, en caso
contrario se rechaza (Graterol, 2003). El IRt se calcula en base al VAN y a los
desembolsos de caja o inversiones del proyecto, segn la formula:
%&' 567,58 9,.: .

"#$ 1,46 (se acepta)
( )*+,-. /*0 1+.2*34. ;66,66 9,.:
.
CONCLUSIONES
Durante el desarrollo de un sistema para el control y gestin de los

materiales en el almacn del departamento de mantenimiento y operacin de
telfonos pblicos de la CANTV estado Monagas utilizando una metodologa
gil e iterativa de desarrollo conocida como XP o Extreme Programming, se
obtuvieron una serie de conclusiones, enmarcadas en la utilidad del proyecto,
las herramientas utilizadas, y las practicas metodolgicas; y que son
presentadas a continuacin.
En lo que al funcionamiento del sistema, al comparar las horas hombres

empleadas en el desarrollo de las actividades bsicas del sistema propuesto
contra las de la forma tradicional o no automatizada de ejecucin de las
transacciones, se confirma que con la implementacin del nuevo sistema
automatizado, se logran reducir significativamente el tiempo de ejecucin de las
tareas, es decir, la ejecucin de las tareas relacionadas con el manejo de
materiales en el departamento se reducen en casi el 80%. (77,8%). Este de por
si representa un beneficio determinante a la hora de seleccionar la alternativa
de implantar el nuevo sistema.
Siguiendo la misma idea, en cuanto a los beneficios obtenidos por la mano

de obra mensual (cuadro n 15) para el sistema propuesto al Departamento de
mantenimiento y operacin de telfonos pblicos, se pudo observar que este
ofrece una gran reduccin en cuanto al costo de horas hombres empleadas
para llevar a cabo las actividades esenciales de gestin y control del almacn,
con un ndice de reduccin del 77,8%, lo que representa un gran beneficio para
la organizacin. ndice de ahorro que se mantiene si se incluyen los ahorros en
papelera, y otros menos significativos.
Es importante destacar que en trminos monetarios, los costos tangibles
duros, o financieros que implican el desarrollo e implantacin del sistema
propuesto, no son de gran significancia considerando las enormes ventajas que
trae consigo su uso, sobre todo cuando se habla de beneficios intangibles
(cualitativamente y cuantitativamente hablando) que aporta el sistema Proyecto
XP.
Sin duda, los beneficios que trae consigo la implantacin de un sistema

para el control y gestin de los materiales en el almacn del departamento de
mantenimiento y operacin de telfonos pblicos de la CANTV, son mucho
mayores que los costos que este pueda suponer, por lo que se considera como
acertada la decisin de desarrollar este proyecto. La implantacin del mismo
proporciona un valor aadido tanto al departamento de telefona pblica como a
toda la organizacin CANTV ya que contribuye a la ejecucin ms rpida de las
transacciones relacionadas con el control del inventario y el almacn, optimiza
la gestin de reportes de salida, mejora enormemente la consulta y el
almacenaje de los registros, hace ms cmodo el trabajo en el departamento,
favorece enormemente la gestin de grupo, y por sobre todo contribuye a la de
gran manera la consecucin de mejores ndices de mantenimiento correctivo y
preventivo de la planta de telfonos pblicos del estado Mongas, objetivos estos
primordiales dentro del departamento.
De acuerdo a la situacin problemtica identificada en la ejecucin de las

tareas correspondientes al despacho de materiales en el almacn del
departamento de telefona pblica de la CANTV, se propuso la alternativa de
automatizar todos los procesos correspondientes a dichas tareas, para lo que
fue necesario aplicar el diseo y desarrollo de un sistema de gestin y control
que funcionar bajo una plataforma confiable, moderna y de fcil alcance para
la organizacin. El desarrollo de la alternativa se enmarco dentro de las
prcticas y fases metodolgicas pertenecientes a la metodologa gil e iterativa
de desarrollo de sistemas de informacin creada por Kent Beck en 1996
llamada Extreme Programming o XP.
Un beneficio alterno que trajo consigo la ejecucin del proyecto, es

precisamente la nombrada en el apartado anterior, conocer XP y el mundo gil
de desarrollo de sistemas de informacin. La metodologa XP, se presenta ms
que todo como una filosofa de desarrollo, basada en valores y principios bien
definidos, agrupando las mejores practicas conocidas para la elaboracin de
sistemas de informacin, innovando en muchos aspectos del desarrollo y del
trabajo en grupo, usando como bandera principal una fuerte comunicacin y
una bsqueda constante de la satisfaccin del cliente elaborando sistemas de
alta calidad, adaptados lo ms posibles a los requerimientos del usuario.
Las clave principales distintivas de XP sobre otras metodologas de

desarrollo es su fcil adaptacin a proyectos pequeos, en los que se busca
estar alejado de las especificaciones precisas de requisitos y modelado
(mtodos pesados de desarrollo), sin tener tanto nfasis en la planificacin y
control del mismo; y que por el contrario que est ms orientado a la filosofa
gil de desarrollo de sistemas de informacin, con la generacin de cdigo en
ciclos muy cortos de desarrollo y entrega, con un equipo de desarrollo pequeo,
haciendo especial hincapi en aspectos humanos asociados al trabajo en
equipo e involucrando activamente y de gran manera al cliente en el proceso.
Los principales beneficios que se destacan de usar dicha metodologa

esta la obtencin inmediata de la satisfaccin del cliente, las facilidad que
aporta para el cumplimiento de plazos, al menos para proyectos pequeos
como el presentado, y la comprobada calidad del trabajo realizado por un unido
grupo de desarrollo. Indudablemente tambin presenta prcticas difciles de
ejecutar, como la programacin en pareja; practicas poco funcionales, como las
metforas y practicas no tomadas en cuenta dentro de la metodologa, como el
clculo de presupuestos o de anlisis de factibilidades en lo que ha trminos
monetarios se refiere y forma de documentacin pobre o poco definida.
Sobre la estructura, se desarrolla bajo PHP principalmente por ser el

lenguaje para aplicaciones de mayor auge actualmente, la gran mayora (ASP,
Perl, etc.) interacta con el manejador de base de datos, con paquetes de
archivos, con servidores web, pero PHP demuestra cada vez ms hacerlo con
mayor rapidez, adems de ser el que posee una mayor facilidad de aprendizaje.
Entre otras ventajas destaca que es gratis, est en constante desarrollo, existen
grandes comunidades de apoyo, y sin importar la aplicacin web que se
desarrolle PHP puede ser utilizado.
Sobre el manejador de base de datos, se elije MySQL por ser la

herramienta libre (gratis) ms potente y de mayor funcionalidad en el mercado.
Es fcil de manejar, adems de ser muy robusta cuando se une junto a PHP
para el desarrollo de aplicaciones. Al ser parte de la comunidad libre, es
continuamente mejorada.
RECOMENDACIONES
1. Es importante que dentro del departamento de mantenimiento y

operacin de telfonos pblicos de la CANTV en el estad Monagas, sin importar
el puesto que desempee, bien sea supervisor, tcnico especialista, o tcnico
de ruta fijo o contratado, logren responder efectivamente al sistema implantado,
tratando de vencer la resistencia al cambio, para as poder gozar de los
beneficios que trae consigo la implantacin del sistema.
2. Se recomienda a la organizacin CANTV, en primera instancia a la sede

de operaciones del estado Monagas, promueva el uso del sistema propuesto y
del todo el Proyecto XP en general, extendindolo a otras zonas operativas,
impulsndolo de manera que logre ser convertido en un sistema estndar para
toda la organizacin a nivel nacional. El mismo, podra ser extendido a otras
reas funcionales de la organizacin que realicen despachos rutinarios de
materiales para el cumplimiento de sus actividades diarias, como por ejemplo el
departamento de Planta Externa, de esta manera los beneficios del sistema
prototipo seran ms extensivos, sus costo sera mucho menor y la gestin de
todo el ente se vera beneficiada con respuestas ms rpidas y transacciones
ms efectivas, en lo que a manejo de material se refiere.
3. Tener en cuenta que el producto entregado, sigue siendo un prototipo

expandible y con gran potencial, ofrecindole a la organizacin CANTV un
punto de partida para el desarrollo de un posible sistema de gestin empresarial
desarrollado bajo plataforma libre, tal cual lo decreta el estado para los entes
pblicos; y que puede ser asumido con bajos costos de desarrollo a travs de
nuevos proyectos que sigan la misma modalidad del presente, hechos en base
a proyectos de pasantas.
180
1801
4. Mantener continuamente las bases de datos actualizados, no solo en lo
que a materiales se refiere, sino tambin en cuanto a tcnicos que ejecuten
labores dentro del departamento y los reportes generados producto de los
despachos y solicitudes de materiales procesados, esto permitir mantener al
mximo el rendimiento del sistema, un mayor control del almacn y una mejor
gestin dentro del departamento. As mismo, se recomienda realizar un
respaldo constante de la data, an est o no el sistema funcionando en forma
local.
5. Igualmente se le recomienda al departamento continuar recopilando

informacin valiosa, en cuanto a requerimientos del sistema se refiere, seguir
evaluando su funcionalidad, estudiar la posibilidad de incluir nuevos cambios en
el sistema, tanto en trminos de funcionalidad como en trminos de interfaz de
usuario; puesto el sistema es ampliamente modificable puede ser desarrollado
con nuevos proyectos debidamente planteados.
6. Metodolgicamente hablando, se recomienda enormemente el uso de la

metodologa de desarrollo XP. Esta ofrece una gran libertad para definir que es
lo que se quiere realizar y la forma ms indicada para hacerlo, adems no
requiere de amplios conocimientos de artefactos y mtodos de modelado
pesados (como UML), adems de generar trabajos de calidad y en corto
tiempo.
7. Los objetivos principales de XP, que son satisfacer al cliente y trabajar

en equipo son fcilmente realizables siguiendo las prcticas propuestas,
afrontndolas en base a los valores, los principios, y las actividades propuestas.
Tener sobre todo valenta a la hora de afrontar le reto de desarrollar o cambiar
un sistema, trabajar con mucha sencillez cumpliendo los con los requisitos
bsicos, potenciar lo mximo posible la comunicacin para con el cliente o
usuario y con el equipo de desarrollo, adems de probar continuamente todo lo
desarrollado e integrarlo al sistema son los fundamentos que se deben seguir
para trabajar bajo XP.
BIBLIOGRAFA
Abad Arango, Daro (2006). Control de Gestin. Interconed Editores. Bogot,

Colombia.
Aguilar, Alejandro (2002). Programacin Extrema y Software Libre. rea de

Software Libre de la UNAM. Consultado en:
http://www.seguridad.unam.mx/eventos/datos/ev11/semi18/mat.7.pon19.
semi18.pdf
Amat Salas, Oriol (2001). Contabilidad y Finanzas para no financieros.

Coleccin Gerencia Empresarial. Editora El Nacional. Caracas,
Venezuela.
Anaya, Villegas y Plaza M, Edison (2007). Estndares de calidad en

metodologas agiles para el desarrollo de software aplicados
como ejemplo en el desarrollo de un modulo del sistema de
tesorera para la industria licorera del Cauca, usando Extreme
Programming [Trabajo de tesis de grado] Popayan Colombia.
Arias, F (2002). El Proyecto de Investigacin. (Quinta Edicin). Editorial

Episteme. Caracas Venezuela.
Beck, K. Extreme Programming Explained. Embrace Change (2004).

Addison Wesley. Segunda Edicin. EBook.
Clculos de la depreciacin. Mtodo de depreciacin en lnea recta.

http://www.economicas-online.com/bienesde5.htm
Calero, Manuel (2003). Una explicacin de la programacin extrema (XP). V

Encuentro usuarios xBase 2003 Madrid. Disponible en:
http://www.willydev.net/descargas/prev/ExplicaXP.pdf
Cans, Jos; Letelier Patricio y Mara Carmen Penads (2007). Metodologas
giles en el desarrollo de software. Investigacin para la Universidad
Politcnica de Valencia. Valencia, Espaa. Disponible en:
http://www.willydev.net/descargas/prev/TodoAgil.Pdf
Comisin de Trabajo Especial de Grado. (2007). Normas para el Desarrollo de

un Trabajo Especial de Grado - Modalidad Pasantas. Universidad de
Oriente. Ncleo Monagas - Maturn.
Echeverry Tobn, Luis Miguel y Luz Elena Delgado Carmona (2007). Caso
prctico de la metodologa gil XP al desarrollo de software.
Investigacin para la Universidad Tecnolgica de Pereira. Disponible en:
http://biblioteca.utp.edu.co/tesisdigitales/resumentesis148.html
Escalona, Mara Jos (2001). Metodologa para el desarrollo de sistemas de

Informacin Global: Anlisis comparativo y propuesta. Departamento
de Lenguajes y Sistemas Informticos. Escuela Tcnica Superior de
Ingeniera Informtica. Universidad de Sevilla. Sevilla. Disponible en:
http://www.lsi.us.es/docs/informes/EstadoActual.pdf
Goncalves, Matas (2005). Desarrollo de un nuevo modelo de estimacin

basado en metodologa gil de desarrollo y generadores de
aplicaciones. Trabajo de Diploma para la Universidad de Morn. Buenos
Aires, Argentina. Material en lnea. Disponible en: http://www.i-
sol.com.ar/plan_de_tesis_final.pdf
Gonzlez, Oliek y Yabor Jorge (200. Los Sistemas de Control y de Gestin

Estratgica para las organizaciones. Disponible en:
http://www.monografias.com/trabajos15/sistemas-control/sistemas-
control.shtml#control
Graterol, Mara Luisa. (2003) Proyecto de Inversin. Instituto Universitario de
Tecnologa de Administracin Industrial. Matemtica Financieras.
Maracay, Venezuela. Disponible en:
http://www.monografias.com/trabajos16/proyecto-inversion/proyecto-
inversion.shtml
Hernandez, Roberto, Carlos Fernndez y Pilar Batista. (1997) Metodologa de

la Investigacin. Mc GRAW-HILL INTERAMERICANA EDITORES,
S.A de C.V. Mxico, D.F. EBook. Disponible en:
http://rapidshare.com/files/76200867/Roberto_Sampieri_Metodologia_de
_la_Investigacion.rar
Informacin general sobre arquitectura de software. Disponible en:

www.microsoft.com/spanish/msdn/articulos/archivo/130902/voices/eaarc
hover.asp
Jacaboson, I., Booch, G., Rumbaugh J., (2000) El Proceso Unificado de

Desarrollo de Software, Addison Wesley
Jeffries, Ron, y otros. Extreme Programming Installed (2001). The XP Series

EBook. Addison Wesley.
Letelier, P. Proceso de Desarrollo de Software (2002). Departamento de

Sistemas Informticos y Computacin. Universidad Politcnica de
Valencia. EBook. Aportado va mail. Mail: letelier@dsic.upv.es.
Letelier, P. y su grupo del DSIC. Seminario de Metodologas giles, incluye

Introduccin al desarrollo de software, Tratado sobre Metodologas
giles, XP Casos de Uso, Programacin Extrema Extreme
Programming (XP), entre otros (2003). Departamento Sistemas
Informticos y Computacin (DSIC). Universidad Politcnica de Valencia
(UPV) - Espaa. Aporte va email. Mail: letelier@dsic.upv.es.
Mrquez Vera, Luis Enrique (2006). Rediseo y automatizacin de los flujos
operacionales del rea de logstica y coordinacin de transporte de
una empresa basado en Tecnologa Web. Trabajo de Grado para la
Facultad de Ciencias de la Universidad Central de Venezuela. Caracas,
Venezuela. Documento en lnea. Disponible en:
http://www.postgrado.ucv.ve/biblioteca/tesis.asp?id=TCi947&fecha=3
Menguzzato, Martina y J.J. Ranau. La Direccin Estratgica. Un enfoque

innovador del Managment. Valencia. Ed. Euroed, 1993.
Neira, Daniel (2002). Trabajo del Valor Presente Neto (VPN) y otras tcnicas
financieras para el estudio de futuros proyectos. Universidad
Metropolitana. Ciencias administrativas. Caracas, Venezuela. Documento
en lnea. Disponible en:
http://www.monografias.com/trabajos11/vepeme/vepeme.shtml
Normas ISO. ISO 9000-3. Laboratorio de Sistemas de Informacin. Facultad de

Informtica - Universidad Politcnica de Valencia. Disponible
en:http://www.dsic.upv.es/asignaturas/facultad/lsi/trabajos/102000.dochtt
p://www.histaintl.com/soluciones/configuracion/configuracion.php
Normas para el Desarrollo de un Trabajo Especial de Grado - Modalidad

Pasantas. Comisin de Trabajo Especial de Grado. Universidad de
Oriente. Ncleo Monagas - Maturn.
Pacheco, Ramiro y Otros (2002). Estrategias para el Control de los

Inventarios. Disponible en la direccin http://www.monografias.com
Pardo, J. L. (2003). Gua prctica para tesistas. Caracas: Ediciones

train4you. Publicacin digital CD. P&A, Caracas.
Robles, Gregorio y Jorge Ferrer. Programacin eXtrema y Software Libre
(2001). Universidad Politcnica de Madrid. Disponible en:
http://es.tldp.org/Presentaciones/200211hispalinux/gregorio2/progm-ext-
soft-libre-html/
Sabino, Carlos. (1992) El Proceso de Investigacin. Editorial Panapo de

Venezuela, C.A. Caracas-Venezuela. EBook. Disponible en:
http://paginas.ufm.edu/Sabino/PI.htm
Schenone, Marcelo Hernn (2004). Diseo de una metodologa gil de

desarrollo de software. Investigacin para la Universidad de Buenos
Aires. Buenos Aires, Argentina. Documento en lnea. Disponible en:
http://www.fi.uba.ar/materias/7500/schenone-
tesisdegradoingenieriainformatica.pdf
Serna, Humberto (2005). Gerencia Estratgica. Ediciones Global S.A., Caracas,

Venezuela.
Sobre Arquitectura Cliente/ Servidor. Pgina Web del INEI Per (2008).
http://www.inei.gob.pe/
Sommerville, I. (2002). Ingeniera de Software, Pearson Educacin.
Torres L., Araceli. Metodologas Modernas de Desarrollo de Sistemas de

Informacin. (2002). Consultado en:
http://www.monografias.com/trabajos12/docmento/docmento.shtml
Valera Aranguren, Ramn Antonio (2005). Desarrollo de una herramienta

para la gestin de documentos y contenidos en el proceso de
enseanza-aprendizaje dentro del Decanato de Ciencias y
Tecnologa de la UCLA. Tesis de Grado de Magster Scientarum en
Ciencias de la Computacin para la Universidad Centroccidental
Lisandro Alvarado. Barquisimeto, Venezuela. Disponible en:
http://bibcyt.ucla.edu.ve/cgi- win/be_alex.exe?
Descriptor=SOFTWARE+DE+GESTION&Nombrebd=bc iucla&&
Vega, Edgar. Los sistemas de informacin y su importancia para las

organizaciones y empresas. (2003). Disponible en:
http://www.monografias.com/trabajos24/tics-empresas/tics-
empresas.shtml
William C. Wake. Extreme Programming Explored (2002). The XP Series

EBook. Addison Wesley
Zavala R. Diseo de un Sistema de Informacin Geogrfica sobre internet

(2000). Tesis de Maestra en Ciencias de la Computacin. Universidad
Autnoma Metropolitana Azcapotzalco, Mxico, D.F. Disponible en:
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html
Otros links consultados:
Alianza gil. http://www.agilealliance.com
Biblioteca Virtual CANTV http://cired.cantv.com.ve/
Departamento Sistemas Informticos y Computacin (DSIC). Universidad

Politcnica de Valencia (UPV) http://www.dsic.upv.es/indexC.pl
Gaceta Oficial Software libre. Disponible en:

http://www.cenit.gob.ve/cenitcms/servlet/com.mvdcomm.cms.andocasoci
ado?5,64
LAASD - Latin America Agile Software Development. Informacin general
sobre Modelado gil y Metodologas de desarrollo en Comunidad gil de
Grupos Yahoo. Yahoo Tech Groups. Consultado en:
http://groups.yahoo.com/ y/o http://tech.groups.yahoo.com/group/laasd/
Manifiesto gil. http://agilemanifesto.org/ y http://www.agile-

spain.com/agilev2/manifiesto_agil
Metodologa Extreme Programming. Web Oficial

http://www.extremeprogramming.org/, Web Oficial en Espaol
http://www.programacionextrema.org/, Web de Ron Jeffries y
http://www.xprogramming.com/; Wiki: http://c2.com/cgi/wiki?
ExtremeProgramming
MSN Groups _ metodologas giles. Informacin sobre tesis y proyectos

desarrollados usando Extreme Programming u otra metodologa
gil. Disponible en:
http://groups.msn.com/TESISMETODOLOGIASAGILES/
Resea Histrica completa de CANTV. Disponible en:

http://www.cantv.com.ve/seccion.asp?pid=1&sid=1243
Pagina Oficial UML. http://www.uml.org/
Wikipedia. Enciclopedia libre plurilinge basada en la tecnologa wiki.

http://es.wikipedia.org/wiki/W ikipedia
12Manage. Management Communities. Anlisis de Costo Beneficio.

Disponible en http://12manage.com/methods_cost-
benefit_analysis_es.html
ANEXOS
Anexo 1 - Cdigo del esquema de la base de datos
Esquema tomado desde el manejador de base de datos, algunos campos contienen datos
-- phpMyAdmin SQL Dump

-- version 2.10.3
-- http://www.phpmyadmin.net
--
-- Servidor: localhost
-- Tiempo de generacin: 24-02-2008 a las 22:47:15
-- Versin del servidor: 5.0.45
-- Versin de PHP: 5.2.3
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
--
-- Base de datos: `control_simon`
--
-- --------------------------------------------------------
--
-- Estructura de tabla para la tabla `control`
--
CREATE TABLE `control` (

ìd` int(11) NOT NULL auto_increment,
`fecha` varchar(50) collate latn1_general_ci NOT NULL,
àrtculo` int(11) NOT NULL,
`tecnico` int(11) NOT NULL,
`cantidad` int(11) NOT NULL,
`cierre` int(11) NOT NULL,
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latn1 COLLATE=latin1_general_ci
AUTO_INCREMENT=10 ;
--
-- Volcar la base de datos para la tabla `control`
--
190
1901
INSERT INTO `control` (ìd`, `fecha`, àrticulo`, `tecnico`, `cantdad`, `cierre`) VALUES
(1, '14/01/2008', 1, 1, 5, 2),
(2, '14/01/2008', 1, 1, 15, 2),
(3, '14/01/2008', 2, 1, 1332, 1),
(4, '14/01/2008', 1, 1, 12, 1),
(5, '14/01/2008', 1, 1, 112, 1),
(6, '14/01/2008', 1, 2, 1, 1),
(7, '14/01/2008', 1, 2, 21, 1),
(8, '17/02/2008', 1, 1, 12, 0),
(9, '17/02/2008', 2, 2, 12, 0);
-- --------------------------------------------------------
--
-- Estructura de tabla para la tabla ìnventario`
--
CREATE TABLE ìnventario` (

`codigo` varchar(50) collate latn1_general_ci NOT NULL,
`marca` varchar(50) collate latin1_general_ci NOT NULL,
`descripcion` varchar(100) collate latn1_general_ci NOT NULL,
`cantidad` int(11) NOT NULL,
`tipo` varchar(50) collate latin1_general_ci NOT NULL,
`cantidadmin` int(11) NOT NULL,
PRIMARY KEY (ìd`),
UNIQUE KEY `codigo` (`codigo`)
AUTO_INCREMENT=3 ;
--
-- Volcar la base de datos para la tabla ìnventario`
--
INSERT INTO ìnventario` (ìd`, `codigo`, `marca`, `descripcion`, `cantdad`, `tpo`,

`cantdadmin`) VALUES
(1, '00021', 'Panduit', 'Conector RJ-45 con Botas', 74, 'SI', 3),
(2, '000345', 'Siemens', 'Telefono Publico Tarjetero Modelo 34xl', 3, 'SI', 18);
-- --------------------------------------------------------
--
-- Estructura de tabla para la tabla `tecnicos`
--
CREATE TABLE `tecnicos` (
`nombres` varchar(50) collate latin1_general_ci NOT NULL,
àpellidos` varchar(50) collate latin1_general_ci NOT NULL,
`cedula` varchar(50) collate latn1_general_ci NOT NULL,
`carnet` varchar(50) collate latn1_general_ci NOT NULL,
ìdsap` varchar(50) collate latn1_general_ci NOT NULL,
PRIMARY KEY (ìd`),
UNIQUE KEY `cedula` (`cedula`)
AUTO_INCREMENT=3 ;
--
-- Volcar la base de datos para la tabla `tecnicos`
--
INSERT INTO `tecnicos` (ìd`, `nombres`, àpellidos`, `cedula`, `carnet`, ìdsap`) VALUES
(1, 'Pedro Emilio', 'Rodriguez Larez', '18463795', '00033432110', '3421'),
(2, 'Simon Pedro', 'Garanton', '17722641', '0003454', '123');
-- --------------------------------------------------------
--
-- Estructura de tabla para la tabla ùsuarios`
--
CREATE TABLE ùsuarios` (

ùsuario` varchar(50) collate latn1_general_ci NOT NULL,
`clave` varchar(50) collate latin1_general_ci NOT NULL,
`nombres` varchar(50) collate latin1_general_ci NOT NULL,
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci
AUTO_INCREMENT=1 ;
--
-- Volcar la base de datos para la tabla ùsuarios`
--
Anexo 2 Pantallas y artculos del desarrollo
Borrador Historia de Usuario nmero 3

Historia de usuario original
194
DBDesigner
Diseando las pantallas del modulo de cierre
195
1951
Relacionando el cdigo para el nuevo articulo con pantalla del sistema
Elaborando la autorizacin de salida segn formato

Anexo 3 Formato hoja de despacho
197
Anexo 4 Formato Salida de Materiales
198
Anexo 5 Formato Traslado Especiales
199
Anexo 6 - Cdigo fuente del sistema
Incluidos en la versin digital (por no requerir evaluacin)
Mtricas:
5 mdulos generales
10 sub mdulos o carpetas
39 secuencias de desarrollo
3500 lneas de cdigo aproximadamente
70 hojas de documentacin extra
200

Documents - MX - Desarrollo de Un Sistema para El Control y Gestion de Materiales en El Almacen

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Documents - MX - Desarrollo de Un Sistema para El Control y Gestion de Materiales en El Almacen

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD DE ORIENTE

DESARROLLO DE UN SISTEMA PARA EL CONTROL Y GESTIN DE

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

Br. Simn Garantn C.I: 17.722.691

Maturn, Mayo de 2008

Cuadro n 1: Cuadro operativo metodolgico

Tabla 1: Modelo de Historia de Usuario a utilizar

Figura 1: Plan Operativo Cantv Gerencia Red Monagas Nov. 2007

En mi carcter de asesor acadmico del trabajo presentado por el

Ing. Jess Chaparro

Quienes suscriben, Miembros del jurado evaluador designados por la

En la ciudad de Maturn a los _ das del mes de de dos

Miembro Principal Miembro Principal

Autor: Simn P. Garantn L.

Descriptores: Ingeniera de software, metodologas giles, XP, eXtreme

En un mundo cada vez ms automatizado, en el que surgen continuas

En la actualidad son muchas las empresas e instituciones que acuden a

Esto trae como consecuencia que continuamente se estn desarrollando

Aparece entonces la ingeniera del software como rama primordial en la

Por todo esto, dentro del departamento de operacin y mantenimiento de

Captulo I (Contexto Organizacional), en el cual se hace referencia al

Captulo II (Planteamiento del Problema), en el que se realiza el

Captulo III (Marco Referencial), en esta seccin se exponen los

Captulo IV (Marco Metodolgico), en este se desarrolla el tipo y nivel de

El Capitulo V (Resultados), es donde se muestran los resultados y

El referido captulo describe todos aquellos aspectos relacionados con la

1.1 Historia de CANTV

La Compaa Annima Nacional Telfonos de Venezuela, conocida como

La Corporacin CANTV dispone de las tecnologas ms avanzadas, lo

Actualmente, luego de 15 aos de administracin privada, CANTV asume

No es algo nuevo. A travs de los siglos XX y XXI, CANTV ha pasado por

Esta etapa marca el nacimiento de la CANTV. En los ltimos aos del

El beneficiario de esta concesin es el comerciante Flix A. Guerrero,

CANTV fue inscrita formalmente en el Registro de Comercio el 20 de junio

Se inicia igualmente la comunicaciones internacionales declarando abierto

En 1953, la nacin adquiere la totalidad de las acciones ordinarias de

Para 1962, el Ejecutivo Nacional le asigna a CANTV la operacin,

En 1962, el Gobierno Nacional solicita al Fondo Especial de las Naciones

El 12 de junio de 1964, CANTV suscribe un contrato con la American

En octubre de 1975, se constituye la filial C.A. Venezolana de Guas

Mientras tanto, a nivel internacional, hay un desarrollo intensivo de

En esta etapa, los grandes y ambiciosos proyectos de la empresa no

En 1990 se vence el Contrato de Concesin que CANTV tiene con el

El 15 de diciembre de 1991, en acto pblico, se abren los sobres de las

1991-2007: De Compaa de Telfonos a Corporacin de

Desde diciembre de 1991 hasta 2007, la Corporacin CANTV ha

1992-1997: Expansin y Modernizacin de las Redes

Durante los primeros seis aos como empresa privatizada, se emprende la

Se digitaliza ms del 50% de las redes y se lleva a cabo un agresivo plan

En el plano del trfico desde y hacia Venezuela con el mundo, ste es el

Otro de los hitos de este perodo es la constitucin de Movilnet el 19 de

En este perodo se fortalece la privatizacin, luego de que el 22 de

1998/2000: Transformacin y Orientacin Comercial

Esta etapa caracteriza la evolucin de la empresa hacia el mercado ante

Durante esta etapa, CANTV consolida el proceso de transformacin

Dentro del proceso de expansin comercial, se remozan las Oficinas de

De igual manera, se produce la explosin del segmento prepago en el

2001/2003: Integracin en Competencia

Luego de la aprobacin de la Ley Orgnica de Telecomunicaciones y el

Este proceso permite ofrecer, en un mercado totalmente en competencia,

A partir de 2001, CANTV presenta una identidad de marca corporativa

2004/2006: Crecimiento Para Abrir Horizontes

Tambin se inici un proceso de integracin de las redes fijas y mviles, lo