Proyecto feria grupo 4

ESCUELA MILITAR DE INGENIERIAMCAL. ANTONIO JOSE DE SUCRE BOLIVIA

SISTEMA DE CONTROL Y SEGUIMIENTO 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

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

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. También se incrementa la confianza del propietario o armador porque sus

3

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.

Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.

4

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) Refactorización (refactoring). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de

5

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 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

6

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. Planificación. 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.

4ª Fase: Pruebas.

El uso de los test en X.P es el siguiente.

7

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. Planificación: .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 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

8

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 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

9

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. 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

10

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 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.

11

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.

9. DESARROLLO DEL PROYECTO.

9.1. Planificación del Proyecto.-12

http://www.monografias.com/trabajos5/teorsist/teorsist.shtml#retrp

http://www.monografias.com/trabajos34/el-caracter/el-caracter.shtml

http://www.monografias.com/trabajos16/proyecto-inversion/proyecto-inversion.shtml#CICLO

9.1.1. Planificación

ACTIVIDADESFECHAS

DOCUMENTOSCOMIENZO FIN

1ra FASE PLANIFICACION 18/09/2012 28/09/2012 PLANIFICACIONDescripción del proyecto 18/09/2012 18/09/2012 Introducción, objetivosPlanificación de tiempos descripción 19/09/2012 19/09/2012 Diagrama de GANTT

Desc. Unidad 20/09/2012 20/09/2012 GRecolección de información 21/09/2012 21/09/2012 Entrevistas, cuestionariosEspecificación de requisitos 24/09/2012 25/09/2012 Tabla de requisitosFactibilidad 25/09/2012 26/09/2012 Estudio de factibilidadIdentificación de actores y procesos 27/09/2012 27/09/2012 Tabla de actores, tabla de procesos

Descripción de requerimientos 28/09/2012 28/09/2012 Casos de uso de alto nivel, casos de uso

expandidos, historias de usuario2da FASE DISEÑO 01/10/2012 12/10/2012 DISEÑOAnálisis proyecto 01/10/2012 02/10/2012 Diagrama secuencialDiseño procedimientos 03/10/2012 04/10/2012 Diagrama de estados

Diseño de la base de datos 05/10/2012 08/10/2012 Diagrama entidad - relación, diagrama de clases

Diseño de pantallas muertas 09/10/2012 10/10/2012 Distribución de pantallas muertasEstructura arquitectura 11/10/2012 12/10/2012 Diagrama de despliegue UML3ra FASE CODIFICACION 15/10/2012 09/11/2012 CODIFICACIONGeneración del sitio web de la unidad 15/10/2012 23/10/2012 Sitio web de la unidad

Codificación pantallas muertas 24/10/2012 31/10/2012 Pantallas muertas del sistema

Codificación de la base de datos 01/11/2012 09/11/2012 Codificación de la base de datos

4ta FASE PRUEBAS 12/11/2012 30/11/2012 PRUEBASPruebas unitarias 12/11/2012 15/11/2012 Pruebas por procesosPrueba de la base de datos 16/11/2012 20/11/2012 Prueba de la base de datosPrueba de conexión 21/11/2012 26/11/2012 Interfaces y bases de datosPrueba 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.

De acuerdo al Anexo (A)9.2.3. Resultados Obtenidos.

Se obtuvo los siguientes resultados (Anexo B):13

- 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).-

9.4. Historia del Usuario.-

No. ACTORES DESCRIPCION

1 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.

2 Administrador Realiza el Registro de ingreso y salida de todo armamento, así como repuestos que ingresa al 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

14

control.

3 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

PANTALLA PRINCIPAL

Pagina Principal del Sistema

15

TITULO DEL SISTEMA

LOGOUNIDAD

IMAGENCENTRO DE MANTENIMIENTO LOGO

DPTO IV

USUARIO

CONTRASEÑA

INGRESAR

CANCELAR

IMAGENES

Ama

9.6 Diagramas Entidad Relación

16

TITULO DEL SISTEMALOGO DE LA

UNIDADLOGO DEL

DPTO. IV

ATRAS PAGINA INICIO

REPORTES

TEXTO

IMAGEN

IMAGEN

MENU OPCIONES

MISION

VISION

HISTORIA

REGISTRO DE ARMAMENTO

MANTENIMIENTO

MENSAJE DE BIENVENIDA

9.7 Tablas del Sistemas

AdministrativoCod. Per

Grado Cargo Nombre Apellido P Apellido M C. M

MantenimientoCod_Per Numero Serie Cod_Rep Fecha

IngresoFecha Salida

Descripción

ArmamentoCodArm

Numero de Serie

Tipo Armamento

Marca Modelo Calibre Procedencia Unidad

RepuestoCod_Rep Nombre Tipo Armamento Procedencia Marca Serie Cantidad

EncargadoCod_Enc Grado Nombre Apellido P Apellido M C.M. Unidad

17

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.

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.

Análisis y Diseño de Sistemas – Kenneth E. KendallAnálisis Estructurado Moderno - E. Yourdon -Ingeniería del Software un enfoque practico - S. PressmanUML en 24 hrs. Joseph Schmuller

12. ANEXOS.

A. Resultados de las encuestas.B. Diagramas de casos de uso.

ANEXO A (RESULTADOS DE LA ENCUESTAS)

GRAFICO 1

18

Word 10,00%Excel 90,00%Access 0,00%

GRAFICO 2Si 0%No 100%

GRAFICO 31 Año 0,00%2 Años 80,00%3 años 20,00%

GRAFICO 4Computarizado 100%

Manual 0%

19

GRAFICO 5Unidad 80%Cantidad 20%


GRAFICO 7Bueno 0%Regular 20%Deficiente 80%

20




21


GRAFICO 12Trabajan 10 100%Otras Cantidades 0%

GRAFICO 13Dpto. IV 100%Comanejto 0%

22

GRAFICO 14Sencillo y Facil 80%Otros 20%

GRAFICO 15Experto 30%Novato 70%Ninguno 0%

23

ANEXO B (DIAGRAMAS DE CASOS DE USO)

TABLAS DE CASO DE USO DE ALTO NIVEL SISTEMA DE CONTROL DE MANTENIMIENTO Y SEGUIMIENTO DEL ARMAMENTO.

CASO DE USO Sistema de Control de Mantenimiento y Seguimiento del Armamento

ActoresAdministrador, Unidad, Técnico Armero, jefe de Centro y Jefe de Mat

Bel (Dpto.IV)

Tipo Primario

DescripciónEl Diagrama muestra el sistema de control y seguimiento de

mantenimiento de Armamento en el Centro de Mantenimiento de

Artillería, con sus respectivos actores y procesos.

24

DIAGRAMA CASO DE USO EXPANDIDO GESTOR DE USUARIO

Caso de Uso Gestor de UsuarioActores Administrador y técnico ArmeroPropósito Autenticación de ID y contraseña para ingresar al sistema.Tipo PrimarioReferencia Cruzada

R2, R16, R18.

ACCION DE LOS ACTORES RESPUESTA DEL SISTEMAS1.- El usuario ingresa a la aplicación del usuario2.- El usuario solicita acceder al sistema.

3.- El sistema muestra el formulario de acceso de seguridad

4.- El usuario ingresa el ID y contraseña.

4.- El sistema valida el ID y la contraseña

5.- Por No: vuelve a ingresar el ID y la contraseña (paso 4)8.- Por Si: el usuario ingresa al sistema de control y seguimiento de mantenimiento de armamento

9.- El usuario solicita detalles del sistema

10.- El sistema muestra detalles del sistema.

25

26

CASO DE USO EXPANDIDO REGISTRO DE DATOS DEL PERSONAL

Caso de Uso Registro de Datos del personal

Actores Administrador y Técnico armero

Propósito Registrar los datos del personal que tiene acceso al sistema.

Tipo Primario

Referencia Cruzada

R2, R3, R7, R10, R12, R13, R14, R15

ACCION DE LOS ACTORES RESPUESTA DEL SISTEMAS

1.- El administrador solicita datos del

personal que tiene acceso al sistema.

2.- El Administrador recibe datos del

personal que tiene acceso al sistema.

3.- El administrador solicita formulario

de registro al sistema.

4.- El sistema muestra el formulario

5.- El administrador registra los datos

del personal que tiene acceso al

sistema.

6.- El sistema valida el formulario de registro

del personal.

7.- Por No: vuelve a llenar el formulario(paso

5)

8.- Por Si: Almacena la información en la

base de datos del sistema(paso 9)

9.- Muestra mensaje guardado correcto

10.- El administrador solicita imprimir el

formulario de registro de personal.

11.- Muestra el detalle de los datos e

imprime el formulario de registro del

personal.

27

28

TABLA DE CASO DE USO EXPANDIDO REGISTRO DE DATOS DEL ARMAMENTO

Caso de Uso Registro de Datos del armamento

Actores Encargado de la Unidad, Administrador

Propósito Recabar información del armamento y registrar.

Tipo Primario

Referencia Cruzada

R1, R3, R4, R8, R9, R10, R15


1.- El encargado de la Unidad entrega

datos del armamento.

2.- El Administrador recibe datos del

armamento e ingresa al sistema.





del armamento en el formulario.


de armamento.


5)


base de datos del sistema



formulario de registro de armamento.


imprime el formulario de registro de

armamento.

29

30

TABLAS DE CASO DE USO EXPANDIDO REGISTRO DE DATOS DE LOS REPUESTOS DEL ARMAMENTO Caso de Uso Registro de Datos de los repuestos del armamento

Actores Administrador, Encargado Mat. Bel. Dpto. IV.

PropósitoRecabar información de los repuestos del armamento y luego

registrar en la Base de Datos.

Tipo Primario

Referencia Cruzada

R3, R10, R11, R12, R15, R17, R18.


1.- El encargado de Mat. Bel. del Dpto.

IV entrega datos de los repuestos del

armamento.

2.- El Administrador recibe datos de los

repuestos del armamento e ingresa al

sistema.





de los repuestos del armamento en el

formulario.


de los repuestos del armamento.


5)


base de datos del sistema



formulario de registro de los repuestos

del armamento.


imprime el formulario de registro de

armamento.

31

DIAGRAMA CASO DE USO EXPANDIDO CONTROL Y SEGUIMIENTO DEL ARMAMENTO

Caso de Uso Control y Seguimiento del ArmamentoActores Administrador y técnico Armero

Propósito Realizar el control y seguimiento minucioso del armamento al detalle.

Tipo PrimarioReferencia Cruzada

R4, R5, R7, R9, R10, R12, R14, R15, R18.

ACCION DE LOS ACTORES RESPUESTA DEL SISTEMAS1.- El administrador solicita los registros y formularios de mantenimiento del armamento

2.- El sistema muestra los registros y formularios del mantenimiento del armamento

3.- El usuario solicita imprimir los registros y formularios para el control y seguimiento del armamento.

4.- Muestra el detalle de los datos e imprime el formulario y los registros del mantenimiento.

32

CASO DE USO EXPANDIDO REPORTES E INFORMES DE MANTENIMIENTO

Caso de Uso Reportes e informes de mantenimientoActores AdministradorPropósito Actualizar los reportes e informes de mantenimientoTipo PrimarioReferencia Cruzada

R3, R5, R6, R7, R8, R15.

ACCION DE LOS ACTORES RESPUESTA DEL SISTEMAS1.- El administrador solicita los registros y formularios de mantenimiento

2.- El sistema muestra los registros y formularios del mantenimiento

3.- El usuario solicita imprimir los registros y formularios de mantenimiento.

4.- Muestra el detalle de los datos e imprime el formulario y los registros del mantenimiento.

33

Documents

Proyecto feria grupo 4