Automatización de Aseguramiento de
Calidad, de Encapsulación de Software.
Quality Assurance Automation for Software Packaging.
José Gabriel Chacón
Licenciado en
Tecnologías de Información para la Gestión de los Negocios
Universidad Latina
de Costa Rica
Recibido 11/set/2018
Aprobado 20/dic/2018
Resumen- Este trabajo
nació de la necesidad de un cambio en el proceso de QA de IBM Costa Rica. La
investigación demostró sobre los diferentes marcos de automatización de pruebas
para así verificar cual podría servir más para la implementación de una
herramienta que evite los problemas existentes. Se recopilo información de los
diferentes involucrados en el proceso para que la herramienta se hiciera en
base a la opinión de todo utilizando la herramienta de encuestas como uno de
los medios primordiales. El proceso de QA en IBM es un proceso que no registra
ningún dato sobre sus resultados por lo que el cliente no está seguro de si el
trabajo que se realizó realmente está bueno. Se descubrió que algunas personas
se saltan partes del proceso de QA y a la hora de dárselo al cliente, este nos
devuelve el trabajo y las métricas bajan. Se pretendió buscar la forma de
automatizar este proceso para que no se siguieran entregando trabajos
incompletos o mal hechos. Con los resultados educaron sobre el impacto actual y
la necesidad de automatizar las pruebas de aseguramiento de calidad.
Palabras Claves: Buenas
Practicas, QA, Aseguramiento de la Calidad, Proyectos, Automatización de
Pruebas, Encapsulación de Software, Automatización.
Abstract— This work was born from the
need for a change in the IBM Costa Rica QA process. The investigation showed about the different
frameworks of automation of tests
to verify which could be more useful for the
implementation of a tool that avoids
existing problems. Information was gathered from the
different people involved in the process so that the tool was
made based on the opinion
of all. The
QA process in IBM is a process that does not record any data about its results
so the client is not sure if the work that was actually done is good. It was
discovered that some people skip parts of the QA process and at the time of
giving it to the client, this gives us back the work and the metrics go down.
It was intended to find a way to automate this process so that they do not
continue to deliver incomplete or badly done work. With the results they
educated about the current impact and the need to automate the quality
assurance tests.
Keywords: Best Practices, QA, Quality
Assurance, Projects, Test Automation, Software Packaging, Automation.
I.
INTRODUCCIÓN
En IBM se prestan muchos servicios relacionados con
tecnologías que requieren de ser estudiadas y entendido acorde a las
necesidades del cliente. Uno de sus servicios a nivel mundial es “Software Packaging” también conocido en español como “Encapsulación
de Software”, el cual trata de generar paquetes de instaladores para sus
diferentes clientes a nivel mundial y así poder distribuir estos paquetes a las
diferentes máquinas y servidores que nuestros clientes tienen. Cada “Paquete”
1.
Pre-Packaging Validation
Verificar
dependencias
Validación
del software a instalar y su comportamiento
2.
Packaging
Instalar el
software
Aplicar los
estándares dependiendo de la cuenta[1]
Probar el
paquete (Instalar, desinstalar, instalar)
Copiar los
archivos del paquete al repositorio compartido
Crear
documentación y lista de complejidad
Enviar correo
de confirmación
3.
Aseguramiento de Calidad
Revisar la
documentación del paquete (Formulario de Solicitud y Lista de complejidad)
Revisar que
la ubicación del paquete sea correcta.
Revisar que
el nombre del paquete cumpla con el estándar del cliente.
Enviar un correo
de confirmación.
4.
Aseguramiento de Calidad 2
Revisar que
el nombre del paquete cumpla con el estándar del cliente.
Revisar que
la ubicación del paquete sea correcta.
Aplicar las
instrucciones de prueba.
Verificar los
registros de errores
Enviar un correo
de confirmación.
El Software Packager
Los procesos de QA[2]
han sido un problema a la hora de realizarlos ya que los colaboradores realizan
la tarea de QA de distintas formas y aunque dos personas revisen el “Paquete”,
puede haber ciertos pasos o errores que se omiten y el Paquete se entrega al
cliente sin los aspectos deseados. Parte del proceso de “Packaging”
es incluir archivos de texto Reporte de errores con información importante
respecto a la instalación y su proceso al momento de que se corre. Los QA’s no incluyen ningún tipo de Reporte de errores por lo
que el cliente verdaderamente no sabe si el paquete una vez creado fue probado.
Dado que los clientes han presentado molestia se ha considerado tratar de
implementar un sistema con el cual se sigan los pasos sin importar quien haga
el QA y que estos resultados queden documentados, en caso de no tener
resultados positivos, volver a hacer el Paquete hasta que estos cumplan con las
métricas deseadas de acuerdo a los requerimientos del cliente.
II.
ANTECEDENTES DEL PROBLEMA DE
ESTUDIO
IBM es una empresa que tiene 10 años de estar en
Costa Rica y desde entonces el proceso de Software Packaging
siempre ha existido, por lo que el proceso de QA también. Se ha logrado mejorar
conforme surgen los años y van mejorando las tecnologías y la educación. Las
empresas cada vez quieren estar más seguros de que los encargados de hacer esta
labor sea de la mejor manera ya que en ciertas situaciones, si el trabajo está
mal hecho puede afectar tanto al cliente como a IBM. A través de los años se
han perdido métricas y escalado casos en los cuales de haber habido un proceso
de QA eficiente, estos se hubieran evitado. Hoy en día sigue siendo recurrente
el entregar un trabajo que ya paso por los procesos de QA correspondientes y a
la hora de hacer el sistema funcionar, este no funciona por lo que el cliente
experimenta una mala situación. Los clientes se han manifestado y nos
recomiendan acudir a otro tipo de metodología para hacer un cambio que
beneficie a ambos lados.
III.
PLANTEAMIENTO DEL PROBLEMA
La situación actual se encontró que los clientes
están molestos por la inconsistencia en los procesos de QA como resultado
ineficiencia o falta de capacitación para el proceso de QA. Además de ambientes
inadecuados para probar los paquetes por parte del cliente con falta de
entregables (Documentación) como parte del servicio.
IV.
JUSTIFICACIÓN
Los clientes exigieron un
cambio y las organizaciones con las que IBM trabaja se pudieron ver afectados
por descuidos al no seguir correctamente sus estándares (buenas practicas)
sobre el manejo de programas en sus computadoras. Los colaboradores saben que
esto es necesario para la agilidad y calidad sobre el trabajo entregado, mejorar
métricas y así los clientes pueden ver cambios positivos en nuestro trabajo.
i. ¿Es posible llevar a cabo esta investigación?
La iniciativa se vio de buena
manera a nivel de gerencia, están anuentes de que esto es un proceso que hay
que mejorar. IBM es una empresa que le
gusta el cambio y le gusta que sus colaboradores innoven para su beneficio.
ii. ¿Cuánto tiempo requirió?
Se tuvo planeado un tiempo aproximado de 2 a 4 meses donde se les
consulto a los diferentes colaboradores de IBM que trabajan en Software Packaging
sobre sus procesos de QA. Muchos de los procesos son parecidos, sin embargo, la
idea es automatizar la mayoría de esos procesos de forma que los colaboradores
tengan un mejor resultado sobre el QA.
V.
OBJETIVO GENERAL:
Proponer un sistema con las características necesarias
para que todos los Colaboradores de “IBM Software Packaging
Costa Rica” utilicen y que nuestros clientes tengan mejores resultados.
VI.
Objetivos específicos:
a. Diferenciar las necesidades de
los clientes (estándares[3]) para incluir todos los
aspectos a revisar dentro del sistema.
b. Organizar el resultado de los QA’s de forma que sea legible y fácil de interpretar con
los resultados de las instalaciones.
c. Explicar las razones del por
qué el cliente nos está presionando para obtener servicios adecuados a sus
normas y calidades.
d. Comparar las diferentes formas
en las cuales se trabaja a nivel de cuentas sobre la aplicación de “QA” y ver
si son aplicables para incluir al sistema.
e. Entender la respuesta al
cambio en caso de implementar una herramienta.
f. Distinguir los diferentes
aspectos que se requieren para generar el sistema a proponer. (Sistema de programación
a usar, herramientas, etc.)
VII.
DELIMITACIÓN, ALCANCE O
COBERTURA
La investigación posee un alcance descriptivo ya
que esta consiste en describir fenómenos, situaciones, contextos y eventos;
esto es, detallar cómo son y cómo se manifiestan. Se pretendió medir o recoger
información de manera independiente o conjunta sobre las variables a las que se
refieren. Con lo que se procuró:
·
Generar una propuesta para IBM Costa Rica sobre la
automatización del proceso de QA que se realiza a los trabajos de los Software Packagers que genere mejoras a su calidad y tiempo en el
trabajo.
·
Realizar un estudio sobre los aspectos a considerar
para la elaboración o características de la herramienta.
·
Brindar la capacitación y documentación necesaria para
el manejo de la herramienta.
·
Facilitarle el soporte necesario a la herramienta en
caso de haber cambios
VIII. RESTRICCIONES Y/O LIMITACIONES
Lo que respecta a limitaciones del proyecto, se
pueden encontrar varios aspectos que podrían influir en los datos y en los
resultados. Una de las limitaciones más presentes que se tiene la investigación
es que cada cuenta, cuenta con diferentes tipos de QA por lo que hay que
adecuar el sistema a todas estas cuentas. Sin embargo, esto es más una
limitación por el tiempo y no por la dificultad técnica por lo que se pueden
esperar atrasos.
IX.
MARCO SITUACIONAL
¿Qué es Software
Packaging en IBM?
En IBM la labor de ser un Software Packaging Specialist [4]genera
archivos .msi, que son igual que un instalador, un
requerimiento básico para realizar el trabajo es hacer estas instalaciones
silenciosas. ¿A que nos referimos con esto? Significa que el usuario que vaya a
instalar el paquete no tiene por qué ver algún proceso de instalación. Los
archivos .msi no son silenciosos por si solos, por
los que hay que ejecutarlos de alguna otra forma.
Los entregables del paquete final incluyen
ciertas carpetas que complementan el paquete. Estos son:
Complete[5]
Doc[6]
Prj[7]
Src[8]
En la carpeta de Complete se puede encontrar en la mayoría de los
paquetes una herramienta propia de IBM llamada ISPI que se conforma de un
“Setup.exe”, un archivo que contiene un código para correr secuencias de
instalación para correr los archivos necesarios dentro del paquete que se llama
“Install.ini” y por último, se encuentra una carpeta llamada “Install Files[9]” que
contiene los archivos a instalar. La carpeta Doc
incluye una carpeta con los registros de instalación del paquete con resultados
positivo. El formulario con el que se solicitó el paquete, un archivo
“Readme.txt[10]”
que contiene instrucciones e información del paquete y por ultimo un archivo de
Excel con una lista de chequeo de complejidad del paquete para así poder medir
el trabajo.
En la carpeta Prj
X.DEFINICIONES
Para este proyecto necesitamos definir qué tipo
de marcos de automatización de pruebas se pueden usar para realizar este proyecto pero primero hay que definir que es un marco. Un
marco se refiere a un conjunto de reglas o buenas prácticas que se siguen para
conseguir los resultados deseados. ¿Qué es Automatización de Pruebas? Es un
conjunto de procesos o acciones que se ejecutan uno tras otro con el fin de
analizar un trabajo en específico.
Para este proyecto se estarán utilizando
diferentes tipos de recolección de datos para así poder recopilar la
información necesaria. Estas herramientas serian:
Entrevistas
“Tener una conversación con una o varias personas para un fin determinado.”
(RAE[15])
Encuestas
“Serie de preguntas dirigidas a una muestra de un grupo de personas para
recopilar la opinión y como se ven afectados.” (RAE)
Revisión de Documentos
La propuesta sugiere la creación de una
aplicación o una herramienta por lo que hay que saber cuáles son nuestras
opciones para el trabajo que se quiere realizar. Podemos hablar sobre
diferentes lenguajes de programación pero ¿Qué es un
lenguaje de programación? Es un sistema diseñado para interactuar con la
computadora y el usuario para cumplir diferentes funciones. Existen muchos
tipos de lenguajes de programación por lo que se consideraran 3 opciones de
lenguajes de programación:
Neatbeans (Java)[16]
Lenguaje de programación basado en Java [17]que
es un motor para correr aplicaciones del tipo Java. Este tipo de programación
puede ser sumamente amigable con el usuario final; crear código es sencillo,
aunque si se ocupa conocimiento técnico. No tiene mucha interacción con los
componentes básicos de Windows pero si permite la
interacción con diferentes objetos. Significa gran espacio en la memoria de la
computadora
VBScript
Lenguaje de programación nativo de Windows.
Utiliza el WSH (Windows Script Host) para así poder interactuar con datos variables.
No es muy amigable con el usuario final. En caso de ocupar introducir datos a
la aplicación tiene que ser por medio de la Línea de comandos de Windows
utilizando wscript.exe o cscript.exe al correr el código. Se requiere de nivel
técnico para realizar este código pero la interacción
con el sistema de Windows es directa por lo que es más fácil el manejo y
comunicación de los componentes de la computadora.
C++[18]
Lenguaje de programación basado en el lenguaje “C”. Este lenguaje
permite la interacción de objetos por lo que se vuelve un lenguaje hibrido. La
interacción con el usuario final es buena. Se requiere constante mantenimiento
de código. Es un lenguaje de programación con licencia, es decir, hay que pagar
para obtener todas sus funciones.
¿Qué es un ejecutable de tipo exe[19] y
msi[20]?
Exe es una extensión de un archivo que es capaz de ser ejecutado al
igual que un msi. La diferencia entre un .exe y un .msi es que el msi es capaz de ser
modificado por medio de herramientas.
¿Qué es una observación?
Según “La Real Academia Española” una observación
es “La acción y efecto de observar”.
XI.
MARCO
METODOLÓGICO
Esta investigación será del tipo transversal ya
que se busca recolectar datos en un momento en específico, en un tiempo único.
El propósito es describir
variables y analizar su incidencia e interrelación en un momento
dado. Además la investigación obtuvo un diseño
descriptivo ya que tiene como objetivo describir el proceso correcto para
realizar la tarea que se espera de nosotros hacia los clientes. Se presentó de
plantear una base para realizar el trabajo por lo que esta debió de especificar
bien cada paso y cada proceso a realizar dentro de la tarea de realizar un
paquete y sus diferentes pasos.
Se analizaron y compararon los tiempos para
completar los QA’s y la calidad de estos
acorde a los estándares. Hubo interacción con personas especializadas y
certificadas en ISTQB (International Software Testing
XII.
SISTEMATIZACIÓN
DE HALLAZGOS
Se solicitó información oficial que tenga paso a
paso detallado con comentarios de cuáles son los aspectos a considerar para esa
cuenta respecto a los estándares y obligaciones que tiene cada Software Packager al presentar su trabajo al cliente. Estos
elementos se estudiaron y se analizaron para así realizar un sistema en el que
todas las cuentas que realicen labores de Software Packaging
puedan usar y que nuestros clientes puedan recibir el mejor servicio.
Resultados de la Encuesta realizada a los
integrantes de Software Packaging en IBM, en base al
cuestionario (demostrado siguientemente). Se verifico que el proceso no se está
tratando con las mejores prácticas o de la mejor manera pero demuestran interés
en mejorar.
Análisis del resultado de la pregunta 1: Se concluye que el proceso de
QA a pesar de que se ha descuidado tanto por la parte gerencial como por los
colaboradores es bastante importante para ambos interesados en el proceso.
Análisis del resultado de la pregunta 2: Se
define que es necesaria la creación de un reporte de errores para el proceso de
QA ya que en este momento no existe.
Análisis del resultado de la pregunta 3: Se definen los aspectos
importantes a evaluar los cuales vienen siendo cada uno de los aspectos del
proceso de QA.
Análisis del resultado de la pregunta 4: Para la mejora del proceso de QA
se determinó que es necesario mejores ambientes de prueba de parte del
cliente
Análisis del resultado de la pregunta 5: Se logra determinar que el
proceso de QA no se realiza por igual dependiendo de cada persona sin importar
el cliente por lo que se evidencia la necesidad de una herramienta que
evite el error humano.
Análisis del resultado de la pregunta
6: La gran mayoría de los colaboradores piensan que una herramienta que realice
las labores de un QA es necesaria para mejorar nuestra calidad con el cliente.
Análisis del resultado de la pregunta
7: Los mismos colaboradores creen posible la opción de automatizar el proceso de
QA.
Análisis del resultado de la pregunta 8: Se
define que hay buen nivel técnico de programación y que el lenguaje más
conocido por la mayoría de los colaboradores es VBScript por lo que se tomara
en cuenta para la realización del trabajo.
Análisis del resultado de la pregunta 9: Ninguno
de los colaboradores ha interactuado con los marcos de automatización de
pruebas.
Análisis del resultado de la pregunta 10: Los
colaboradores están dispuestos a recibir cambios
a. Análisis y Resultados de la Entrevista
En total se lograron realizar 2 entrevistas a dos managers, en base al
cuestionario (resultado de entrevista abajo). Se verifico en la entrevista
la intención de la importancia sobre la utilización de mejores prácticas.
Pregunta 1: ¿Que
considera usted que sea importante mejorar en los procesos de QA?
Respuestas de la entrevista:
·
QA es un proceso muy crítico y la intervención humana
puede afectar resultados, lo mejor para el proceso es que sea totalmente
automatizado para prevenir errores.
·
Automatización de tareas repetitivas y mejorar los
controles de Asignación.
·
Sería importante crear una herramienta que ayude en
parte a automatizar las pruebas y de paso sirve para estandarizar más dicho
proceso
·
Considero que se podrían establecer estándares para
que el proceso de QA sea el mismo para todas las cuentas, crear casos de
pruebas o listas de comprobación de requerimientos.
·
Sería importante dividir los QAs,
que en el primero se revisen solo cosas de estándares de la fábrica, y en el
segundo se revisen funcionamientos y códigos, de esta manera podríamos hacerlo
más rápido y por otro lado enfocarnos más en lo que se está realizando.
·
Que se pueda estandarizar y automatizar en la medida de lo posible,
reduciendo el margen de error humano.
·
Análisis del resultado de la entrevista:
- Automatizar el proceso de QA
para prevenir errores humanos
- Mejores controles de
asignación de trabajo
- Estandarización del proceso y
casos de prueba
- Separación de
los proceso del QA
XIII.
PLANTEAMIENTO
DE LA HERRAMIENTA
La herramienta consiste en entregar confianza al
cliente por medio de la documentación necesario sobre el resultado del
aseguramiento de la calidad y ayudar a que los colaboradores puedan agilizar
los procesos. Tras la encuesta y las entrevistas que se realizaron, se logró
determinar que el lenguaje de programación más factible para realizar la
herramienta es el lenguaje VBScript que al menos un 65% de los integrantes
tienen conocimiento y preferencia por este lenguaje. Además, este tipo de
lenguaje tiene mejor interacción con los componentes de Windows[22]
que se ocupan para poder realizar el trabajo de la herramienta. Este además es
sencillo de modificar y de interpretar.
La herramienta está dividida en diferentes
secciones para que esta pueda ser interpretada de mejor manera por el
colaborador y así poder ir logrando los diferentes procesos del aseguramiento
de la calidad.
La herramienta se divide así:
Primero es necesario abrir una consola CMD e
introducir una línea de comando para poder ejecutar la herramienta la cual sería:
Una vez que se corre esta línea la herramienta se ejecutara y Preguntara
cual es: el nombre del paquete que por estándar de todas las cuentas seria:
<Sección><Vendedor><Aplicación><Versión><Lanzamiento(R#)>
Imagen 12. Inicio de
la herramienta. Autoría propia.
Imagen 13, Nombre del
Paquete. Autoría propia.
Enseguida se solicita al usuario ingresar el tipo
de paquete o de ejecutable desea correr. Se dan tres opciones la cuales
incluyen realizar instalaciones de Ejecutables tipo .EXE y numerosos tipos de
scripts, también se permite ejecutar un instalador tipo MSI y si es necesario
también está la opción para ejecutar un MST
Una vez ingresado el tipo de instalador que desea correr, la herramienta
preguntara donde se encuentra este ejecutable.
Una vez ingresada la ruta para el ejecutable En caso de que sea un .EXE
(opción 1), la herramienta ejecutara el instalador
pero no revisara los estándares ya que son ejecutables no estandarizados, es
decir, no es posible aplicarle estándares. En caso de que sea la Opcion 2 o 3, estos si revisaran estándares a diferencia d ela opción 1. Despues de analizar
los estándares se procederá a realizar la instalación. Despues
de la instalación se verificara si se han creado atajos en el Escritorio o en
el Menú de Inicio.
Imagen 16, Propiedades
e instalacion del ejecutable. Autoría
propia.
Una vez analizadas las propiedades, el resultado de la instalación y los
atajos al escritorio y al menú de Inicio, le herramienta verificara con el
usuario si se requiere de algún registro en específico.
Imagen 17,
Verificación de Registros. Autoría propia.
En caso de ser necesario de revisar un registro,
nada más ingresarlo y el sistema verificara si existe o no.
Después de revisar si el registro existe, la
herramienta le preguntara al usuario si hay algún archivo para revisar. Aquí
mismo se le pide al usuario incluir que verifique la existencia de la
documentación.
Si el trabajo necesita revisar un archivo
importante para el funcionamiento del paquete, la herramienta pedirla la ruta
del archivo y verificara su existencia.
XIV.
CONCLUSIÓN
La investigación que se ha realizado para la
implementación de la automatización del aseguramiento de la calidad para el
puesto de Software Packaging de la empresa IBM Costa
Rica ha sido de mucha ayuda ya que se logró obtener información muy valiosa que
sin duda dio una perspectiva bastante amplia de lo que se tiene que cambiar.
Una de las cosas que cambio es la confianza del cliente por lo que se debió
crear la documentación necesaria para validar los procesos de aseguramiento de
calidad. Esta documentación no solo entrego confianza al cliente, sino que mejoro
tiempos del trabajo por hacer y facilito el trabajo de los colaboradores.
Se logró determinar que en IBM Costa Rica ya
existían marcos de automatización de pruebas, sin embargo, se dejaron al lado y
no siguieron implementándolo. Gracias a la investigación se determinó que para
este tipo de automatización se va a requerir de otro tipo de marco que se
adapte más al equipo de Software Packaging y así
poder tener resultados más centralizados. Gracias a la encuesta y entrevista realizada
a los colaboradores se logró determinar que la respuesta ante un cambio al
proceso de aseguramiento de la calidad se vio bien visto por la gerencia al
realizar una herramienta que sea beneficiosa, será utilizada por los colaboradores.
Los estándares de los diferentes clientes que
reciben el servicio de Software Packaging se
recopilaron por medio de correos y documentos internos para así poder incluir
todos estos estándares que los clientes buscan. Estos fueron incluidos a la
herramienta y es posible modificar estos estándares en caso de que se necesite
agregar o eliminar uno.
“La gestión de la calidad
se centra en proporcionar confianza en que se cumplirán los requisitos de
calidad"
Adamson, C. (2006). Mastering Data
Warehouse Aggregates Solutions for Star Schema Performance. . Indiana, EEUU:
Wiley Publishing.
Anderson, D. &. (2001). Beyond Change
Management. San Francisco,CA, EEEUU: Jossey-Bass/Pfeiffer. .
APM Group, L. (2012, May 08). Retrieved
from http://www.itil-officialsite.com/AboutITIL/WhatisITIL.aspx
Chemuturi, M. &. (2010). Mastering
Software Project Management: Best Practices, Tools and Techniques. Florida, EEUU.: J. Ross
Publishing. .
Project Management Institute,
I. (2008). Guía de los fundamentos de la dirección de Proyectos (PMBOK®
López J.C. (2014). La taxonomía de Bloom y sus actualizaciones. Setiembre 29,
2015, de Eduteka. Retrieved from Guía de los fundamentos de la dirección
de Proyectos: http://www.eduteka.org/TaxonomiaBloomCuadro.php
Rajkumar, S. (2018). Types of Test
Automation Frameworks | Software Testing Material. Retrieved from https://www.softwaretestingmaterial.com/types-test-automation-frameworks/
Russel, J. (2012). ASQ. Retrieved
from ASQ: http://asq.org/learn-about-quality/quality-assurance-quality-control/overview/overview.html
Naveen, V. (2015, 04). 6 Popular Test
Automation Frameworks for UFT (QTP). EvokeTechnologies. Obtenido 05, 2018, de
https://www.evoketechnologies.com/blog/popular-test-automation-frameworks-uft/
InstallShield. (n.d.). Retrieved 14/3/18,
from
LLC, F. S. (2016). AdminStudio. Retrieved
14/3/18, from Installshield,
http://www.flexerasoftware.com/enterprise/products/application-packaging/adminstudio/
[3] Estándares:
Se refiere a la aplicacion de acuerdos ya establecidos por parte del cliente,
esto puede incluir no dejar un atajo en el escritorio, crear llaves de registro
o configuraciones internas del paquete.
[4] Software Packaging Specialist: Puesto laboral en IBM
[5] Complete: Folder utilizado como estándar de IBM (Completo)
[6] Doc: Folder utilizado como estándar de IBM (Documentación)
[7] Prj: Folder utilizado como estándar de IBM (Proyecto)
[8] Src: Folder utilizado como estándar de IBM (Fuente)
[9] Install Files: Folder utilizado como estándar de IBM (archivos a
instalar)
[10] ReadMe.txt: Archivo que indica como correr el instalador.
[11] Binarios: Archivos que provee el cliente
[12] Legacy: aplicación de escritorio
[13] Citrix: aplicaciones remotas
[14] App-V: aplicaciones virtuales.
[15] RAE: Real Academia Española
[16] NetBeans: Lenguaje de programación basado en Java
[17] Java: Es un motor para correr archivos tipo java en una computadora.
[18] C++: Lenguaje de programación basado en Visual basic
[19] Exe: Tipo de ejecutable que no es modificable
[20] MSI: Tipo de ejecutable que es modificable.
[21] ITSQB: Es una certificación internacional con intensión en la mejora de
los proceso de aseguramiento de la calidad.
[22] Windows: Sistema Operativo de una computadora.
