1. ESCUELA MILITAR DE INGENIERIA
MCAL. ANTONIO JOSE DE SUCRE
BOLIVIA
SISTEMA DE CONTROL, DEL MANTENIMIENTO DE ARMAMENTO DE
ARTILLERÍA
1. INTRODUCCIÓN.
La tecnología se encuentra actualmente en continua evolución y crece a una
velocidad impresionante, el incremento de la demanda para tener acceso a
sistemas computacionales y a los servicios de Internet, promueve la adaptación
desde el punto de vista técnico de los implementadores, de sistemas de información
adecuados y actualizados con tecnologías de conectividad.
En este sentido las Fuerzas Armadas como viene encarando proyectos de
automatización de la información que contribuyen en el cumplimiento de sus
labores específicas, debe desarrollarse acorde a los avances de la tecnología, sin
escatimar esfuerzos, debe propender a que todas sus unidades se encuentren
actualizados con sistemas para un mejor y buen control de nuestro material en este
caso de algo que es tan delicado que es el armamento.
La necesidad de adecuarse a este avance tecnológico es inminente para las FF.
AA., ya que la institución debe responder eficientemente a exigencias generadas
por el acelerado progreso tecnológico, la administración eficiente de los datos que
generarán información vital para la toma de decisiones de tipo administrativo en el
mantenimiento de armamento. El Análisis de Sistemas juega un rol muy importante
porque en sus manos está el desarrollo de la aplicación que pretende solucionar las
deficiencias en el ámbito de la informática, en este caso del mantenimiento control
y seguimiento del armamento ya que es nuestro material de trabajo en todos los
cuarteles de nuestra Bolivia.
En este sentido el presente proyecto, se elabora con la finalidad de contar con un
SISTEMA DE CONTROL Y SEGUIMIENTO DEL MANTENIMIENTO DE
ARMAMENTO DE ARTILLERÍA, que tiene a su cargo la Sección Material Bélico del
Departamento IV Logístico. Permitiendo que la misma sea proporcionada en un
tiempo oportuno otorgándole seguridad en su almacenamiento en los diferentes
aspectos que se detallan adelante.
2. ANTECEDENTES.
Desde la creación de las Fuerzas Armadas en todas las unidades militares siempre
se contó con armamento ya que es el material primordial para brindar seguridad
interna y externamente para el control de nuestro territorio; El armamento es un
material muy delicado ya que para su reposición en caso de pérdida o mal uso no
se lo puede encontrar o comprar en cualquier lugar por lo cual necesita de un mejor
control y un adecuado seguimiento del mismo cuando se tiene armamento en
multitud como es el caso de nuestras grandes unidades militares en este caso del
1

2. centro de mantenimiento de Artillería. Ante los accidentes ocurridos a lo largo de la
historia, en especial en el nuestro, en las unidades de artillería donde se emplea
este tipo de armamento de calibres mayores, dotados para el entrenamiento del
personal de tropa e instructores de las unidades militares especializadas en el
manejo de este material. Así mismo debido a la antigüedad que tienen, la falta de
mantenimiento adecuado y el seguimiento inadecuado del control del ciclo de vida
que tiene este armamento ocurren lamentables accidentes con numerosas pérdidas
de vidas humanas.
3. DESCRIPCIÓN DEL PROBLEMA.
Las Unidad de Centro de Mantenimiento de Artillería por falta de recursos
económicos que no son asignados, no cuenta con un sistema de control y
seguimiento del mantenimiento que se realiza al armamento sistematizado, así
como ciclo de vida con que cuenta el armamento, ya que dicho control se lo realiza
en forma manual almacenando la información en documentos que se puede perder
la información. Factores que ocasionan accidentes en las unidades.
3.1. Problema principal.
El deficiente control y seguimiento del mantenimiento del armamento de
artillería que existe con el sistema manual con que cuenta el centro de
mantenimiento de artillería.
3.2. Problemas secundarios.
• Requiere mucho tiempo en la recolección de información de de
requerimientos por la ubicación de la Centro de Mantenimiento de Artillería
(Viacha), lo cual dificulta el proceso de elaboración del proceso de
desarrollo del sistema.
• Dificultad en la actualización de datos en forma continua por el cambio de
personal que se presenta en cada repartición militar por gestión.
• Demora en la generación de datos en el sistema actual conque cuenta el
centro de mantenimiento de artillería.
4. OBJETIVOS.
4.1 Objetivo General.
Nuestro objetivo general es:
Desarrollar un prototipo de un sistema de control y seguimiento del
mantenimiento del armamento de artillería en el Centro de Mantenimiento de
Artillería.
4.2 Objetivos Específicos.
Los objetivos específicos de este proyecto son los siguientes:
2

3. • Planificación del proyecto, Análisis del problema determinando los
requerimientos y necesidades para un sistema de control y seguimiento de
armamento de artillería.
• Recolección de información.
• Especificación de requisitos.
• Diseño, Arquitectura del sistema.
• Desarrollo del software o codificación.
• Pruebas del sistema
5. JUSTIFICACIÓN.
Con la finalidad de contribuir a la solución del problema planteado, se establecen las
siguientes justificaciones:
5.1 Justificación Técnica.
El desarrollo del presente Proyecto se justifica técnicamente considerando el
manejo de la información al que se refiere; las computadores están en
capacidad de convertirse en una ventaja estratégica para las organizaciones
más diversas, estas pueden almacenar y procesar con bastante rapidez los
datos generados y mediante reportes extraer información mediante la
automatización de los procesos de información para el registro y control de
matriculación de armamento, mejorar el flujo de información y la transparencia
del movimientos de este material bélico que actualmente se realizan mediante
procesos manuales, actualmente la sección material bélico de la sección IV
Logística , cuenta con equipos de computación necesarios y adecuados tanto
para el desarrollo como para la implementación del presente proyecto
propuesto. Para el desarrollo de este proyecto se hará la utilización de Análisis
y Diseño de sistemas, Bases de Datos apropiado y compatible con la
plataforma de aplicación, Lenguaje de Programación, estas son asignaturas
que justifican el trabajo.
5.2 Justificación Social.
El Sistema de justifica socialmente porque mejorará la calidad de manejo de
este material que es tan delicado existentes en todas las unidades militares
con información, precisa y reportes oportunos, de esta manera se podrá
ofrecer un mejor servicio al personal militar, administrativo, armadores o
propietarios que contaran con un sistema informático de control.
5.3 Justificación Económica.
El presente trabajo que se realiza se justifica económicamente por que la
Sección “Material Bélico” del Departamento IV Logístico dispondrá de un
nuevo sistema de informático que permitirá aminorar gastos en cuanto al
material de escritorio y tiempo en el trabajo actual del personal y de esta
manera reducirá los costos de registro y control del pañol de armamento.
3

4. También se incrementa la confianza del propietario o armador porque sus
datos del armamento estarán registrados y administrados de manera
transparente en una Base de Datos.
5.4. Justificación Institucional.
El proyecto se justifica desde el punto de vista Institucional porque: la calidad
de servicio que brindara el sistema desarrollado, beneficiara a las Fuerzas
Armadas, a través del Departamento IV Logístico, teniendo un seguimiento de
la codificación del armamento, evaluar armamento nuevo, cambio de unidad
y tipo de armamento.
6. METODOLOGIAS (MATERIALES Y METODOS).
La metodología que se emplea en este proyecto de desarrollo de sistemas se llama
METODOLOGÍA XP.
La programación extrema o XP es una metodología de desarrollo que se englobaría
dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a
la obtención de resultados y reduce la burocracia que se produce al utilizar otras
‘metodologías pesadas’.
Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio
cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo
cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el
cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio
cuando éste tiene lugar.
6.1. Valores de la Programación Extrema.
Para garantizar el éxito de un proyecto, los autores de XP han considerado
como fundamentales cuatro valores:
6.1.1. Comunicación.
Muy importante. La XP ayuda mediante sus prácticas a la comunicación
entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y
desarrolladores.
6.1.2. Sencillez.
Los programas deben ser los más sencillos posibles y tener la
funcionalidad necesaria que se indican en los requisitos. No hay que
añadir algo que no se necesite hoy. Si se necesita añadir más
funcionalidad mañana pues ya se hará entonces.
6.1.3. Retroalimentación.
4

5. Las pruebas que se le realizan al software nos mantiene informados del
grado de fiabilidad del sistema.
6.1.4. Valentía.
Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar
mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias
no existe el riesgo de ‘meter la pata’.
Algunas veces, añaden además un quinto valor: la humildad. Con la
compartición de código, la refactorización y el trabajo de equipo tan
estrecho una buena dosis de humildad siempre es de agradecer.
6.2. Las prácticas de la XP son 12.
El juego de la planificación (the planning game). Es un permanente diálogo
entre las partes empresarial (deseable) y técnica (posible).
1) Pequeñas entregas (small releases). Cada versión debe de ser tan
pequeña como fuera posible, conteniendo los requisitos de negocios más
importantes, las versiones tiene que tener sentido como un todo, me
explico no puedes implementar media característica y lanzar la versión.
Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año,
las compañías que entregan software muy voluminoso no son capaces de
hacerlo con mucha frecuencia.
2) Metáfora (metaphor). Una metáfora es una historia que todo el mundo
puede contar a cerca de cómo funciona el sistema. Algunas veces
podremos encontrar metáforas sencillas “Programa de gestión de
compras, ventas, con gestión de cartera y almacén”. Las metáforas
ayudan a cualquier persona a entender el objeto del programa.
3) Diseño sencillo (simple design). Cuando implementamos nuevas
características en nuestros programas nos planteamos la manera de
hacerlo lo mas simple posible, después de implementar esta
característica, nos preguntamos como hacer el programa mas simple sin
perder funcionalidad, este proceso se le denomina recodificar o
refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas
trabajo del necesario, pero a la vez estaremos preparando nuestro sistema
para que en un futuro acepte nuevos cambios y pueda albergar nuevas
características. No debemos de recodificar ante especulaciones si no solo
cuando el sistema te lo pida.
4) Pruebas (testing). No debe existir ninguna característica en el programa
que no haya sido probada, los programadores escriben pruebas para
chequear el correcto funcionamiento del programa, los clientes realizan
pruebas funcionales. El resultado un programa mas seguro que conforme
pasa el tiempo es capaz de aceptar nuevos cambios.
5

6. 5) Refactorización (refactoring). Cuando implementamos nuevas
características en nuestros programas nos planteamos la manera de
hacerlo lo mas simple posible, después de implementar esta
característica, nos preguntamos como hacer el programa mas simple sin
perder funcionalidad, este proceso se le denomina recodificar o
refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas
trabajo del necesario, pero a la vez estaremos preparando nuestro sistema
para que en un futuro acepte nuevos cambios y pueda albergar nuevas
características. No debemos de recodificar ante especulaciones si no solo
cuando el sistema te lo pida.
6) Programación por parejas (pair programming). Todo el código de
producción lo escriben dos personas frente al ordenador, con un sólo ratón
y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica
en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas
estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no
funcione?, ¿Hay forma de simplificar el sistema global para que el
problema desaparezca?
El emparejamiento es dinámico, puedo estar emparejado por la mañana
con una persona y por la tarde con otra, si tienes un trabajo sobre un área
que no conoces muy bien puedes emparejarte con otra persona que si
conozca ese área. Cualquier miembro del equipo se puede emparejar con
cualquiera.
7) Propiedad colectiva (collective ownership). Cualquiera que crea que puede
aportar valor al código en cualquier parcela puede hacerlo, ningún
miembro del equipo es propietario del código. Si alguien quiere hacer
cambios en el código puede hacerlo. Si hacemos el código propietario, y
necesitamos de su autor para que lo cambie entonces estaremos
alejándonos cada vez mas de la comprensión del problema, si
necesitamos un cambio sobre una parte del código lo hacemos y punto.
XP propone un propiedad colectiva sobre el código nadie conoce cada
parte igual de bien pero todos conoce algo sobre cada parte, esto nos
preparará para la sustitución no traumática de cada miembro del equipo.
8) Integración continua (continuos integration). El código se debe integrar
como mínimo una vez al día, y realizar las pruebas sobre la totalidad del
sistema. Una pareja de programadores se encargara de integrar todo el
código en una maquina y realizar todas las pruebas hasta que estas
funcionen al 100%.
9) 40 horas semanales (40-hour week). Si queremos estar frescos y
motivados cada mañana y cansado y satisfecho cada noche. El viernes
quiero estar cansado y satisfecho para sentir que tengo dos días para
pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto
requiere que trabajemos 40 horas a la semana, mucha gente no puede
estar más de 35 horas concentrada a la semana, otros pueden llegar
6

7. hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y
aun seguir fresco, creativo y confiado. Las horas extras son síntoma de
serios problemas en el proyecto, la regla de XP dice nunca 2 semanas
seguidas realizando horas extras.
10) Cliente en casa (on-site costumer). Un cliente real debe sentarse con el
equipo de programadores, estar disponible para responder a sus
preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el
cliente nos ceda una persona que conozca el negocio para que se integre
en el equipo normalmente estos elementos son muy valiosos, pero
debemos de hacerles ver que será mejor para su negocio tener un
software pronto en funcionamiento, y esto no implica que el cliente no
pueda realizar cualquier otro trabajo.
11) Estándares de codificación (coding standards). Si los programadores van
a estar tocando partes distintas del sistema, intercambiando compañeros,
haciendo refactoring, debemos de establecer un estándar de codificación
aceptado e implantado por todo el equipo.
12) Algunas de estas prácticas reciben muchas críticas, sobre todo la
programación por parejas. Muchos jefes de proyecto no aceptan que dos
desarrolladores tengan un único ordenador, ya que creen que esto
minimizará la productividad, sin saber que de este modo puede producirse
el mismo código que dos personas trabajando en solitario pero con un
código de mayor calidad.
6.3. Fases de la Metodología XP.
1ª Fase: Planificación del proyecto.
• Historias de usuario.
• Release planning.
• Iteraciones
• Velocidad del proyecto.
• Programación en pareja.
• Reuniones diarias.
2ª Fase: Diseño.
• Diseños simples.
• Glosarios de términos.
• Riesgos.
• Funcionalidad extra.
• Tarjetas C.R.C.
3ª Fase: Codificación.
7

8. 4ª Fase: Pruebas.
• El uso de los test en X.P es el siguiente.
• Test de aceptación.
6.3.1. Fase: Planificación del Proyecto.
Historias de usuario: El primer paso de cualquier proyecto que siga la
metodología X.P es definir las historias de usuario con el cliente. Las
historias de usuario tienen la misma finalidad que los casos de uso pero
con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente
en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no
se debe hablar ni de posibles algoritmos para su implementación ni de
diseños de base de datos adecuados, etc. Son usadas para estimar
tiempos de desarrollo de la parte de la aplicación que describen.
También se utilizan en la fase de pruebas, para verificar si el programa
cumple con lo que especifica la historia de usuario. Cuando llega la
hora de implementar una historia de usuario, el cliente y los
desarrolladores se reúnen para concretar y detallar lo que tiene que
hacer dicha historia. El tiempo de desarrollo ideal para una historia de
usuario es entre 1 y 3 semanas.
Release planning: .Después de tener ya definidas las historias de
usuario es necesario crear un plan de publicaciones, en inglés "Release
plan", donde se indiquen las historias de usuario que se crearán para
cada versión del programa y las fechas en las que se publicarán estas
versiones. Un "Release plan" es una planificación donde los
desarrolladores y clientes establecen los tiempos de implementación
ideales de las historias de usuario, la prioridad con la que serán
implementadas y las historias que serán implementadas en cada
versión del programa. Después de un "Release plan" tienen que estar
claros estos cuatro factores: los objetivos que se deben cumplir (que
son principalmente las historias que se deben desarrollar en cada
versión), el tiempo que tardarán en desarrollarse y publicarse las
versiones del programa, el número de personas que trabajarán en el
desarrollo y cómo se evaluará la calidad del trabajo realizado. (*Release
plan: Planificación de publicaciones).
Iteraciones Todo proyecto que siga la metodología X.P. se ha de dividir
en iteraciones de aproximadamente 3 semanas de duración. Al
comienzo de cada iteración los clientes deben seleccionar las historias
de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no
pasaron el test de aceptación que se realizó al terminar la iteración
anterior. Estas historias de usuario son divididas en tareas de entre 1 y
3 días de duración que se asignarán a los programadores.
Velocidad del proyecto: La velocidad del proyecto es una medida que
representa la rapidez con la que se desarrolla el proyecto; estimarla es
muy sencillo, basta con contar el número de historias de usuario que se
pueden implementar en una iteración; de esta forma, se sabrá el cupo
8

9. de historias que se pueden desarrollar en las distintas iteraciones.
Usando la velocidad del proyecto controlaremos que todas las tareas se
puedan desarrollar en el tiempo del que dispone la iteración. Es
conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se
aprecia que no es adecuada hay que negociar con el cliente un nuevo
"Release Plan".
Programación en pareja: La metodología X.P. aconseja la
programación en parejas pues incrementa la productividad y la calidad
del software desarrollado. El trabajo en pareja involucra a dos
programadores trabajando en el mismo equipo; mientras uno codifica
haciendo hincapié en la calidad de la función o método que está
implementando, el otro analiza si ese método o función es adecuado y
está bien diseñado. De esta forma se consigue un código y diseño con
gran calidad.
Reuniones diarias. Es necesario que los desarrolladores se reúnan
diariamente y expongan sus problemas, soluciones e ideas de forma
conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene
que tener voz y voto.
6.3.2. Fase: Diseño.
Diseños simples: La metodología X.P sugiere que hay que conseguir
diseños simples y sencillos. Hay que procurar hacerlo todo lo menos
complicado posible para conseguir un diseño fácilmente entendible e
impleméntable que a la larga costará menos tiempo y esfuerzo
desarrollar.
Glosarios de términos: Usar glosarios de términos y un correcta
especificación de los nombres de métodos y clases ayudará a
comprender el diseño y facilitará sus posteriores ampliaciones y la
reutilización del código.
Riesgos: Si surgen problemas potenciales durante el diseño, X.P
sugiere utilizar una pareja de desarrolladores para que investiguen y
reduzcan al máximo el riesgo que supone ese problema.
Funcionalidad extra: Nunca se debe añadir funcionalidad extra al
programa aunque se piense que en un futuro será utilizada. Sólo el 10%
de la misma es utilizada, lo que implica que el desarrollo de
funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar. Refactorizar es mejorar y modificar la estructura y
codificación de códigos ya creados sin alterar su funcionalidad.
Refactorizar supone revisar de nuevo estos códigos para procurar
optimizar su funcionamiento. Es muy común rehusar códigos ya
creados que contienen funcionalidades que no serán usadas y diseños
obsoletos. Esto es un error porque puede generar código
completamente inestable y muy mal diseñado; por este motivo, es
necesario refactorizar cuando se va a utilizar código ya creado.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities
and Collaboration) permiten al programador centrarse y apreciar el
9

10. desarrollo orientado a objetos olvidándose de los malos hábitos de la
programación procedural clásica.
Las tarjetas C.R.C representan objetos; la clase a la que pertenece el
objeto se puede escribir en la parte de arriba de la tarjeta, en una
columna a la izquierda se pueden escribir las responsabilidades u
objetivos que debe cumplir el objeto y a la derecha, las clases que
colaboran con cada responsabilidad.
6.3.3. Fase: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del
equipo de desarrollo; su presencia es indispensable en las distintas
fases de X.P. A la hora de codificar una historia de usuario su presencia
es aún más necesaria. No olvidemos que los clientes son los que crean
las historias de usuario y negocian los tiempos en los que serán
implementadas. Antes del desarrollo de cada historia de usuario el
cliente debe especificar detalladamente lo que ésta hará y también
tendrá que estar presente cuando se realicen los test que verifiquen que
la historia implementada cumple la funcionalidad especificada.
La codificación debe hacerse ateniendo a estándares de codificación ya
creados. Programar bajo estándares mantiene el código consistente y
facilita su comprensión y escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos
implementados nos ayudará a desarrollar dicho código. Crear estos test
antes nos ayuda a saber qué es exactamente lo que tiene que hacer el
código a implementar y sabremos que una vez implementado pasará
dichos test sin problemas ya que dicho código ha sido diseñado para
ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a
programar en pequeñas unidades, de esta forma se crearán primero los
test para cada unidad y a continuación se desarrollará dicha unidad, así
poco a poco conseguiremos un desarrollo que cumpla todos los
requisitos especificados.
Como ya se comentó anteriormente, X.P opta por la programación en
pareja ya que permite un código más eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de código dónde
las parejas de programadores publican cada pocas horas sus códigos
implementados y corregidos junto a los test que deben pasar. De esta
forma el resto de programadores que necesiten códigos ajenos
trabajarán siempre con las últimas versiones. Para mantener un código
consistente, publicar un código en un repositorio es una acción
exclusiva para cada pareja de programadores.
X.P también propone un modelo de desarrollo colectivo en el que todos
los programadores están implicados en todas las tareas; cualquiera
puede modificar o ampliar una clase o método de otro programador si
es necesario y subirla al repositorio de código. El permitir al resto de los
programadores modificar códigos que no son suyos no supone ningún
riesgo ya que para que un código pueda ser publicado en el repositorio
tiene que pasar los test de funcionamiento definidos para el mismo.
10

11. La optimización del código siempre se debe dejar para el final. Hay que
hacer que funcione y que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo
extra que el planificado para ser finalizados no podrán ser terminados a
tiempo se haga lo que se haga, aunque se añadan más desarrolladores
y se incrementen los recursos. La solución que plantea X.P es realizar
un nuevo "Release plan" para concretar los nuevos tiempos de
publicación y de velocidad del proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear
test de funcionamiento con entornos de desarrollo antes de programar.
Nuestros test los obtendremos de la especificación de requisitos ya que
en ella se especifican las pruebas que deben pasar las distintas
funcionalidades del programa, procurando codificar pensando en las
pruebas que debe pasar cada funcionalidad.
6.3.4. Fase: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para
comprobar el funcionamiento de los códigos que vayamos
implementando.
El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno
de desarrollo específico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los
métodos más triviales.
Se deben crear los test que pasarán los códigos antes de
implementarlos; en el apartado anterior se explicó la importancia de
crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia
del código que en un futuro evaluará. Hay que crear los test
abstrayéndose del futuro código, de esta forma aseguraremos la
independencia del test respecto al código que evalúa.
Como se comentó anteriormente los distintos test se deben subir al
repositorio de código acompañados del código que verifican. Ningún
código puede ser publicado en el repositorio sin que haya pasado su
test de funcionamiento, de esta forma, aseguramos el uso colectivo del
código (explicado en el apartado anterior).
El uso de los test es adecuado para observar la refactorización. Los test
permiten verificar que un cambio en la estructura de un código no tiene
porqué cambiar su funcionamiento.
Test de aceptación. Los test mencionados anteriormente sirven para
evaluar las distintas tareas en las que ha sido dividida una historia de
usuario. Para asegurar el funcionamiento final de una determinada
historia de usuario se deben crear "Test de aceptación"; estos test son
creados y usados por los clientes para comprobar que las distintas
historias de usuario cumplen su cometido.
Al ser las distintas funcionalidades de nuestra aplicación no demasiado
extensas, no se harán test que analicen partes de las mismas, sino que
11

12. las pruebas se realizarán para las funcionalidades generales que debe
cumplir el programa especificado en la descripción de requisitos.
6.4. Ciclo de Vida.
El ciclo de vida de Xp se enfatiza en el carácter interactivo e incremental del
desarrollo, Según [1] una iteración de desarrollo es un período de tiempo en el
que se realiza un conjunto de funcionalidades determinadas que en el caso de
Xp corresponden a un conjunto de historias de usuarios.
Las iteraciones son relativamente cortas ya que se piensa que entre más
rápido se le entreguen desarrollos al cliente, más retroalimentación se va a
obtener y esto va a representar una mejor calidad del producto a largo plazo.
Existe una fase de análisis inicial orientada a programar las iteraciones de
desarrollo y cada iteración incluye diseño, codificación y pruebas, fases
superpuestas de tal manera que no se separen en el tiempo.
7. DESCRIPCION GENERAL DEL PROYECTO.
El SISTEMA DE CONTROL, SEGUIMIENTO Y MANTENIMIENTO DE
ARMAMENTO DE ARTILLERÍA se desarrollara de acuerdo a los siguientes
parámetros:
- Realizar un registro del Armamento de Artillería en el Centro de Mantenimiento
Viacha por el Administrador o Usuario.
- Realizar un registro de accesorios y repuestos por el usuario para el control
respectivo de todo el estock de repuestos.
- Realizar un control del Mantenimiento del Armamento antes, durante y despues
del mantenimiento.
- Registrar al usuario y administrador que realiza el respectivo regoistro.
- Emitir reportes del estado del armamento.
- Emitir reportes del estado de los accesorios para su respectivo control.
- Emitir un detalle del armamento actual existente en el Centro de Mantenimiento.
- Emitir un detalle de los accesorios, estado actual en el Centro de Mantenimiento.
- Emitir un reporte del mantenimiento del armamento que ingresa.
8. ANALISIS PRELIMINAR.
Este análisis se realiza de acuerdo al planteamiento del problema y los
requerimientos del usuario.
Detallándolo a continuación en la parte inicial del desarrollo del Proyecto.
12

13. 9. DESARROLLO DEL PROYECTO.
9.1. Planificación del Proyecto.-
9.1.1. Planificación
FECHAS
ACTIVIDADES DOCUMENTOS
COMIENZO FIN
1ra FASE PLANIFICACION 18/09/2012 28/09/2012 PLANIFICACION
Descripción del proyecto 18/09/2012 18/09/2012 Introducción, objetivos
Planificación de tiempos
19/09/2012 19/09/2012 Diagrama de GANTT
descripción
Desc. Unidad 20/09/2012 20/09/2012 G
Recolección de información 21/09/2012 21/09/2012 Entrevistas, cuestionarios
Especificación de requisitos 24/09/2012 25/09/2012 Tabla de requisitos
Factibilidad 25/09/2012 26/09/2012 Estudio de factibilidad
Identificación de actores y
27/09/2012 27/09/2012 Tabla de actores, tabla de procesos
procesos
Descripción de Casos de uso de alto nivel, casos de uso
28/09/2012 28/09/2012
requerimientos expandidos, historias de usuario
2da FASE DISEÑO 01/10/2012 12/10/2012 DISEÑO
Análisis proyecto 01/10/2012 02/10/2012 Diagrama secuencial
Diseño procedimientos 03/10/2012 04/10/2012 Diagrama de estados
Diagrama entidad - relación, diagrama de
Diseño de la base de datos 05/10/2012 08/10/2012
clases
Diseño de pantallas muertas 09/10/2012 10/10/2012 Distribución de pantallas muertas
Estructura arquitectura 11/10/2012 12/10/2012 Diagrama de despliegue UML
3ra FASE CODIFICACION 15/10/2012 09/11/2012 CODIFICACION
Generación del sitio web de la
15/10/2012 23/10/2012 Sitio web de la unidad
unidad
Codificación pantallas
24/10/2012 31/10/2012 Pantallas muertas del sistema
muertas
Codificación de la base de
01/11/2012 09/11/2012 Codificación de la base de datos
datos
4ta FASE PRUEBAS 12/11/2012 30/11/2012 PRUEBAS
Pruebas unitarias 12/11/2012 15/11/2012 Pruebas por procesos
Prueba de la base de datos 16/11/2012 20/11/2012 Prueba de la base de datos
Prueba de conexión 21/11/2012 26/11/2012 Interfaces y bases de datos
Prueba de funcionalidad 27/11/2012 30/11/2012 Prueba de todo el sistema
9.2. Recolección de Información.-
9.2.1. Técnicas Utilizadas.
Para la recopilación de información se empleó el método de la
entrevista a los usuarios administrativos.
9.2.2. Resultados Obtenidos.
13

14. De acuerdo al Anexo (A)
9.2.3. Resultados Obtenidos.
Se obtuvo los siguientes resultados (Anexo B):
- Todo el personal que participo en la entrevista está de a cuerdo
con la implementación del nuevo sistema.
- Se determinó las falencias del sistema actual.
- Se identificó las vulnerabilidades en aspectos de seguridad de
información.
9.3. Planificación por tiempo (GANTT).-
sep 2012 oct 2012
Id. Nombre de tarea Comienzo Fin Duración
18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 1ra FASE PLANIFICACION 18/09/2012 28/09/2012 9d
2 DESCRIPCIÓN DEL PROYECTO 18/09/2012 18/09/2012 1d
PLANIFICACION DE TIEMPOS
3 19/09/2012 19/09/2012 1d
DESCRIPCION
4 DESC. UNIDAD 20/09/2012 20/09/2012 1d
RECOLECCIÓN DE
5 21/09/2012 21/09/2012 1d
INFORMACION
ESPECIFICACIÓN DE
6 24/09/2012 24/09/2012 1d
REQUISITOS
7 FACTIBILIDAD 25/09/2012 26/09/2012 2d
IDENTIFICACIÓN DE ACTORES
8 27/09/2012 27/09/2012 1d
Y PROCESOS
DESCRIPCIÓN DE
9 28/09/2012 28/09/2012 1d
REQUERIMIENTOS
10 2da FASE DISEÑO 01/10/2012 12/10/2012 10d
11 ANÁLISIS PROC 01/10/2012 02/10/2012 2d
12 DISEÑO PROCEDIMIENTOS 03/10/2012 04/10/2012 2d
13 DISEÑO DE LA BASE DE DATOS 05/10/2012 08/10/2012 2d
DISEÑO DE PANTALLAS
14 09/10/2012 10/10/2012 2d
MUERTAS
15 ESTRUCTURA ARQUITECTURA 11/10/2012 12/10/2012 2d
16 3ra FASE CODIFICACION 15/10/2012 09/11/2012 20d
GENERACIÓN DEL SITIO WEB
17 15/10/2012 23/10/2012 7d
DE LA UNIDAD
CODIFICACIÓN DE PANTALLAS
18 24/10/2012 31/10/2012 6d
MUERTAS DEL SISTEMA
CODIFICACIÓN DE LA BASE DE
19 01/11/2012 09/11/2012 7d
DATOS
20 4ta FASE PRUEBAS 12/11/2012 30/11/2012 15d
21 PRUEBAS UNITARIAS 12/11/2012 15/11/2012 4d
PRUEBA DE LA BASE DE
22 16/11/2012 20/11/2012 3d
DATOS
23 PRUEBA DE CONEXIÓN 21/11/2012 26/11/2012 4d
24 PRUEBA DE FUNCIONALIDAD 27/11/2012 30/11/2012 4d
9.4. Historia del Usuario.-
No. ACTORES DESCRIPCION
Jefe de Centro Es responsable del centro de mantenimiento,
realiza el seguimiento y control al personal
administrativo y el personal de técnicos
armeros que Realizan el Mantenimiento del
armamento.
Administrador Realiza el Registro de ingreso y salida de todo
armamento, así como repuestos que ingresa al
14

15. centro de mantenimiento. Así mismo realiza el
registro de los detalles de mantenimiento del
armamento.
Es responsable de la elaboración de los
distintos partes e informes para su respectivo
control.
Técnico Armero Son encargados de realizar el mantenimiento
del armamento que ingresa al centro, así
mismo en coordinación con el administrador
realizan el registro del detalle de
mantenimiento realizado.
9.5. Diseño del Sistema.
Pagina de Ingreso al Sistema
LOGO IMAGEN
CENTRO DE MANTENIMIENTO LOGO
UNIDAD DPTO IV
TITULO DEL SISTEMA
USUARIO
CONTRASEÑA
INGRESA CANCELAR
R
IMAGENES
15

16. PANTALLA PRINCIPAL
Pagina Principal del Sistema
MENSAJE DE BIENVENIDA
LOGO DE LA LOGO DEL
UNIDAD TITULO DEL SISTEMA DPTO. IV
MENU OPCIONES
MISION IMAGEN
VISION
HISTORIA TEXTO
REGISTRO DE ARMAMENTO
MANTENIMIENTO
REPORTES IMAGEN
ATRAS PAGINA INICIO
10. IMPACTO.
La deficiencia existente en cuanto al control, registro de armamento en las
unidades de mantenimiento del mismo en todo el Ejercito de Bolivia es sumamente
precaria, es por esta razón que se esta desarrollando este proyecto basado en la
innovación de la tecnología para subsanar estas deficiencias.
16

17. Al respecto se espera por parte del personal que dirige y administra el Centro de
Mantenimiento un impacto positivo en el aspecto de la Tecnología de Sistemas
informáticos, que de lugar a la innovación o cambio del Sistema anterior, que no se
adecua a la tecnología actual, la predisposición por parte de los usuarios en adquirir
un nuevo Sistema de Control, Seguimiento y Mantenimiento de Armamento es muy
favorable al respecto.
11. BIBLIOGRAFIA.
12. ANEXOS.
17