IV. CHANGE REQUEST SYSTEM

  

4.1. Descripción del sistema 

 

Debido a la naturaleza del proceso de desarrollo, y al acuerdo de                       

confidencialidad firmado con la compañía, sólo pueden ser compartidos ciertos                   

datos relacionados con el desarrollo de esta aplicación, y debido a ello, sólo se                           

mostrarán algunas metodologías, pantallas y funciones consideradas como de                 

dominio público, y que no afectan de forma directa con los procesos internos de                           

la empresa ni la información correspondiente a las actividades que aquí se                       

realizan. 

 

4.2. Modelo de prototipos 

 

El modelo de prototipos permite que todo el sistema, o algunos de sus                         

partes, se construyan rápidamente para comprender con facilidad y aclarar                   

ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el                         

cliente estén de acuerdo en lo que se necesita así como también la solución que                             

se propone para dicha necesidad y de esta forma minimizar el riesgo y la                           

incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños                       

para que estos sean analizados y prescindir de ellos a medida que se adhieran                           

nuevas especificaciones, es ideal para medir el alcance del producto, pero no se                         

asegura su uso real.  

 

Este modelo principalmente se lo aplica cuando un cliente define un                     

conjunto de objetivos generales para el software a desarrollarse sin delimitar                     

detalladamente los requisitos de entrada procesamiento y salida, es decir cuando                     

el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad                           

38 

 

del sistema o de la forma en que interactúa el hombre y la máquina. Este modelo                               

se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a                         

entender de mejor manera cuál será el resultado de la construcción cuando los                         

requisitos estén satisfechos.  

 

El paradigma de construcción de prototipos tiene tres pasos:  

 

● Escuchar al cliente. Recolección de requisitos. Se encuentran y definen                   

los objetivos globales, se identifican los requisitos conocidos y las áreas                     

donde es obligatorio más definición.  

● Construir y revisar la maqueta (prototipo).  

● El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los                       

requisitos del software.  

 

Este modelo es útil cuando:  

 

● El cliente no identifica los requisitos detallados.  

● El responsable del desarrollo no está seguro de la eficiencia de un                       

algoritmo, sistema operativo o de la interface hombre­máquina.  

 

 

 

 

 

 

 

 

 

 

39 

 

4.2.1. Etapas para la elaboración del modelo de prototipo 

 

 

 

 Figura 4.2.1.A. Etapas del Modelo de prototipo 

 

  

4.2.2. Ciclo de vida de un sistema basado en prototipo  

 

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación,                       

su cara externa, pero dicha interfaz está fija, estática, no procesa datos. El                         

prototipo no tiene desarrollada una lógica interna, sólo muestra las pantallas por                       

las que irá pasando la futura aplicación. 

 

40 

 

Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento                   

que satisface los requisitos y necesidades que se han entendido claramente.                     

Realiza, por tanto, un un proceso real de datos, para contrastarlo con el usuario.                           

Se va modificando y desarrollando sobre la marcha, según las apreciaciones del                       

cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto                       

que el software está constantemente variando, pero, a la larga, genera un                       

producto más seguro, en cuanto a la satisfacción de las necesidades del cliente. 

 

Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor                       

las necesidades del cliente y después no se va a aprovechar ni total ni                           

parcialmente en la implementación del sistema final se habla de un prototipo                       

desechable. Para que la construcción de prototipos sea posible se debe contar                       

con la participación activa del cliente. 

 

   

Figura 4.2.2.A. Ciclo de vida del prototipo 

41 

 

4.2.3. Ventajas del modelo de prototipo 

 

Este modelo es útil cuando el cliente conoce los objetivos generales para                       

el software, pero no identifica los requisitos detallados de entrada, procesamiento                     

o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo                       

del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de                           

un sistema operativo o de la forma que debería tomar la interacción                       

humano­máquina.  

 

4.2.4. Desventajas del modelo de prototipo 

  

Su principal desventaja es que una vez que el cliente ha dado su                         

aprobación final al prototipo y cree que está a punto de recibir el proyecto final,                             

se encuentra con que es necesario reescribir buena parte del prototipo para                       

hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho                       

compromisos de implementación para hacer que el prototipo funcione                 

rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy                         

amigable en su uso, o incluso, que esté escrito en un lenguaje de programación                           

poco adecuado. 

 

El cliente ve funcionando lo que para él es la primera versión del prototipo                           

que ha sido construido con "plastilina y alambres", y puede desilusionarse al                       

decirle que el sistema aún no ha sido construido. El desarrollador puede ampliar                         

el prototipo para construir el sistema final sin tener en cuenta los compromisos de                           

calidad y de mantenimiento que tiene con el cliente[8]. 

 

 

 

 

42 

 

4.3. Herramientas CASE 

 

Se puede definir a las Herramientas CASE como un conjunto de                     

programas y ayudas que dan asistencia a los analistas, ingenieros de software y                         

desarrolladores, durante todos los pasos del ciclo de vida de desarrollo de un                         

Software. 

 

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida: 

 

● Análisis de datos y procesos integrados mediante un repositorio. 

● Generación de interfaces entre el análisis y el diseño. 

● Generación del código a partir del diseño. 

● Control de mantenimiento. 

 

 

Entre los beneficios más significativos de las herramientas CASE se enumeran                     

los siguientes: 

 

Facilidad para la revisión de aplicaciones 

 

La experiencia muestra que una vez que las aplicaciones se implementan,                     

se emplean por mucho tiempo. Las herramientas CASE proporcionan un                   

beneficio substancial para las organizaciones al facilitar la revisión de las                     

aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que                         

éste proporciona bases para las definiciones y estándares para los datos. Las                       

capacidades de generación interna, si se encuentran presentes, contribuyen a                   

modificar el sistema por medio de las especificaciones más que por los ajustes al                           

código fuente. 

 

43 

 

Soporte para el desarrollo de prototipos de sistemas 

 

En general, el desarrollo de prototipos de aplicaciones toma varias formas.                     

En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de                         

mostrar la organización y composición de los datos, encabezados y mensajes.                     

Los ajustes necesarios al diseño se hacen con rapidez para alterar la                       

presentación y las características de la interface. Sin embargo, no se prepara el                         

código fuente, de naturaleza orientada hacia procedimientos, como una parte del                     

prototipo. 

Como disyuntiva, el desarrollo de prototipos puede producir un sistema                   

que funcione. Las características de entrada y salida son desarrolladas junto con                       

el código orientado hacia los procedimientos y archivos de datos. 

 

Generación de código 

 

La ventaja más visible de esta característica es la disminución del tiempo                       

necesario para preparar un programa. Sin embargo, la generación del código                     

también asegura una estructura estándar y consistente para el programa (lo que                       

tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios                       

tipos de errores, mejorando de esta manera la calidad. Las características de la                         

generación del código permiten volver a utilizar el software y las estructuras                       

estándares para generar dicho código, así como el cambio de una especificación                       

modular, lo que significa volver a generar el código y los enlaces con otros                           

módulos. 

 

 

 

 

 

44 

 

Mejora en la habilidad para satisfacer los requerimientos del usuario 

 

Es bien conocida la importancia de satisfacer los requerimientos del                   

usuario, ya que esto guarda relación con el éxito del sistema. De manera similar,                           

tener los requerimientos correctos mejora la calidad de las prácticas de                     

desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo, una                   

característica que es importante para los usuarios. Las herramientas afectan la                     

naturaleza y cantidad de interacción entre los encargados del desarrollo y el                       

usuario. Las descripciones gráficas y los diagramas, así como los prototipos de                       

reportes y la composición de las pantallas, contribuyen a un intercambio de ideas                         

más efectivo. 

 

Soporte interactivo para el proceso de desarrollo 

 

La experiencia ha demostrado que el desarrollo de sistemas es un                     

proceso interactivo. Las herramientas CASE soportan pasos interactivos al                 

eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar.                     

Como resultado de esto, se anticipa que los analistas revisarán los detalles del                         

sistema con mayor frecuencia y en forma más consistente. 

 

4.3.1. Ejemplos de Herramientas CASE 

 

● Microsoft Project 

● Rational Rose 

● JDeveloper 

● MagicDraw 

● Visual Paradigm 

● Microsoft Visio 

● Enterprise Architect 

45 

 

4.4. Funcionalidades del sistema 

 

Las funcionalidades básicas del sistema, corresponden a los siguientes                 

módulos:  

 

● Registro de usuarios: Incluye el alta, modificación y asignación de                   

permisos de acceso a los diversos empleados de la compañía. 

 

● Levantamiento de Change Request: En esta sección se harán las                   

peticiones por parte de los usuarios para la realización de cambios en el                         

sistema o la instalación de nuevo software. 

 

● Listado de software: Es un catálogo que contiene todo el software                     

disponible para instalar en las estaciones de trabajo, las arquitecturas                   

correspondientes, los períodos que comprenden las licencias de cada uno                   

de estos mismos softwares y los sistemas operativos a los que                     

corresponden. 

 

● Inventario: Este catálogo almacena la información de las estaciones de                   

trabajo y establece la relación que tienen con los empleados de la                       

compañía. 

 

● Aprobaciones: Aquí se almacenan y gestionan los niveles de aprobación                   

y el estado en el que se encuentran los change requests asignados a las                           

diversas estaciones de trabajo y los softwares que se hayan solicitado. 

 

● Historial de cambios: Es un catálogo en forma de registro de todos los                         

movimientos, peticiones y aprobaciones que se han hecho a lo largo del                       

46 

 

tiempo dentro de todos los departamentos correspondientes y sus                 

diversas estaciones de trabajo. 

 

4.5. Interfaz gráfica 

 

 

Figura 4.5.A. Inicio de sesión de usuarios 

 

 

 

Figura 4.5.B. Formato básico de catálogo 

 

 

47 

 

 

 

Figura 4.5.C. Apariencia básica de tabla 

 

 

Figura 4.5.D. Formato de creación y búsqueda de usuarios 

 

48 

 

V. CONCLUSIONES

  

5.1. Resultados 

 

Dado a que el proyecto concluyó en una versión de prueba para usuarios                         

finales, aún está propenso a recibir retroalimentación y reportes de fallas o                       

errores por parte de los mismos usuarios. Sin embargo, al contar ahora con un                           

método por el cual los empleados puedan realizar solicitudes de cambios de                       

forma más directa y contando con un seguimiento apropiado, se aceleraron                     

procesos relativos al cumplimiento de objetivos de las actividades designadas                   

para cada sector, lo que promueve un mejor desarrollo de los proyecto, y un                           

aumento significativo en la calidad de cada módulo. 

 

5.2. Dificultades 

 

Las principales dificultades con las cuáles el equipo de trabajo se enfrentó                       

durante la realización del proyecto y las actividades subsecuentes de ello fueron,                       

en primera instancia, la falta de conocimientos técnicos en áreas muy específicas                       

de algunos módulos. Esto llevó como consecuencia a un pequeño retraso en el                         

desarrollo de las actividades necesarias para la conclusión del sistema. Para ello,                       

fue necesaria asesoría e instrucción relativa a esas tecnologías de las que el                         

equipo carecía y se pudieron sobrellevar situaciones que no llevaron a mayores. 

 

 

 

 

 

 

49 

 

5.3. Futuros lanzamientos 

 

Para futuros lanzamientos y mejoras del sistema, se pretende realizar una                     

mejor interfaz gráfica, mucho más adaptable a dispositivos móviles y portátiles                     

para facilitar el uso del sistema en cualquier entorno de trabajo, y agilizar así aún                             

más el proceso de peticiones. 

 

5.4. Conclusión 

 

Actualmente son necesarias las implementaciones de sistemas que               

faciliten y automaticen los procesos que se requiere llevar a cabo por parte de las                             

personas que integran una corporación, sobre todo cuando se trata de                     

multinacionales en las que no pueden permitirse detener procesos de                   

producción, y en los que es necesario llevar a cabo ajustes y cambios de manera                             

rápida y efectiva. 

 

El acercamiento que utilizamos para poder resolver el problema que la                     

empresa estaba enfrentando fue el apropiado, y el enfoque logró alcanzar en su                         

totalidad el objetivo, ya que se cumplieron los requerimientos solicitados para la                       

realización de este proyecto, sin excepción. 

 

 

 

 

 

 

 

 

 

50