ANEXO 2
Software:
metodologías de adquisición
y evaluación
Es en el mercado del software, donde se compran y venden pensamientos
Sumario
1. Determinación de la necesidad 2. Levantado de requerimientos 3. Adquisición
4. Proceso de evaluación de alternativas 5. Factores adicionales
Universidad de Costa Rica
Programas de Educación Continua
Orientación par.a el estudiante
El software es la otra gran parte de los sistemas informáticos. Es la lógica que da cuerpo al proceso de la información y de-be ser el mejor para lograr aprovechar al máximo el hardwa-re adquirido. El softwahardwa-re es m u y difícil de medir, pero debe ser la respuesta directa a las necesidades y requerimientos que se presentan en un proyecto de automatización o actua-lización. Este hecho es el que hace que eí software sea un po-co m á s sencillo de analizar, dado que los objetivos o necesi-dades que se persiguen son directamente solucionados por él. A d e m á s , el software tiene un carácter específico, contra el carácter general del hardware.
O B J E T I V O S
Al finalizar el estudio del presente tema, el estudiante-será capaz de:
Identificar las necesidades que puedan ser solucionadas con productos de software.
Identificar las formas de deter-minación y presentación de los requerimientos de software pa-ra la adquisición.
Explicar las formas de evalua-ción de software.
Explicar las formas en la pre-sentación de las distintas figu-ras de adquisición de software disponibles.
Esbozar los pasos y característi-cas de una presentación de pro-puesta para la adquisición de software.
Universidad de Costa Rica Programas de Educación Continua
introducción
1. DETERMINACIÓN DE LA NECESIDAD
En este apartado se hablará sobre la forma de determinar la necesidad de un producto de software. En la actualidad, las necesidades son fáciles de encontrar dado que, en todo trabajo, la automatización ha alcanzado un lugar importante y el manejo de la información está tomando poco a po-co su lugar dentro de las altas esferas de trabajo de la empresa.
1.1 Oportunidad de encontrar una necesidad
Las oportunidades de encontrar una necesidad que se pueda resolver por software son muchas, sea que la compañía esté empezando, introducien-do una nueva línea o lleva ya varios años sin actualizarse. Estos esque-mas se analizan a continuación:
• C o m i e n z o de trabajo: en el inicio, una compañía debe pensaren su sistema de información. Dependiendo de su línea de trabajo, debe-rá pensar en las alternativas existentes en el mercado o en fabricar su propio sistema. Muchas veces se comienzan negocios que ya tie-nen representantes en el mercado. Si es un negocio altamente gene-ral, y por ende con muchas empresas en él, es muy probable que exista software ya hecho que se pueda comprar. Si el negocio es nuevo, o acaba de comenzar, hay que investigar quién y cómo se de-sarrolla el software que usan los que ya comenzaron o cómo y quién puede fabricarlo para nosotros por primera vez. El análisis de lo que se necesita es muy delicado, ya que al estar adquiriendo tecno-logía por primera vez, se tiene que prever e! futuro, el crecimiento, las expectativas de trabajo, etcétera, de forma que lo que se adquie-ra pueda ser una buena base paadquie-ra el avance del negocio.
• Proyectos nuevos: al igual que cuando se comienza un nuevo ne-gocio, el lanzamiento al mercado de una nueva línea, un producto nuevo, o arrancar un nuevo departamento que ofrezca productos que ya están en el mercado, las necesidades de nuevo software, un nuevo sistema, saltan a la vista. En este punto es importante
Universidad de Costa Rica D
car que, a diferencia de arrancar una compañía nueva, el análisis de-be enfocarse en cómo acoplar el nuevo software o sistema con el existente, o si es necesaria una reorganización total.
• Actualización: muchas veces, la compañía ya tiene software fun-cionando que fue en su momento evaluado y ha dado ya sus frutos. Con el tiempo, la vida útil de todo sistema va terminando, sea por-que los repor-querimientos han cambiado, o sea porpor-que ya existen me-jores formas de enfrentar dichos requerimientos. En este caso, es el momento de una actualización. Las actualizaciones funcionan con base en el software que ya está corriendo. Muchas veces, la actua-lización se reduce a la instalación de una nueva versión del softwa-re que ya se tenía. En otros casos, es necesaria una softwa-reestructuración de los sistemas para poder instalar otros tipos de software, dejando el que ya se tenía de lado. Sin embargo, siempre hay que realizar una reevaluación de los requerimientos para determinar la mejor opción para la actualización.
1.2 Fuentes que pueden sugerir cambios
Las sugerencias de cambio, respaldadas usualmente por una necesidad encontrada, provienen de varias fuentes, entre las que se pueden citar: • Publicidad: muchos nuevos productos o avances son presentados
a los profesionales por medio de la publicidad. Las revistas son la fuente más actualizada de tecnología que se puede encontrar. Des-de artículos especializados hasta las páginas publicitarias, todo es fuente de ideas que permiten evaluar el estado de los sistemas que se ejecutan en la compañía, y que permiten determinar si es tiempo de cambio o no. Muchas veces, los profesionales conocen un nuevo producto o la mejora de uno ya conocido, que puede solucionar un problema que se tiene con el software actualmente instalado. • Usuarios: los usuarios son los reyes en la exigencia de la calidad y
la comodidad. Muchos de ellos pasan su tiempo proponiendo cam-bios que ayudarían a mejorar el sistema y su forma de trabajo. Otros pasan su tiempo criticando la forma de desempeño de ciertas aplicaciones. De esas opiniones, pueden identificarse faltas que el sistema tiene y que necesitan ser saldadas. La opción de reimpri-mir, el cálculo automático de saldos, nuevas consultas, todos son ejemplos de características o funciones que el sistema actual puede no tener y que serían útiles para los usuarios. Las necesidades que pueden identificarse de estas fuentes, y las obtenidas por la
dad, son muy difíciles de vender a las altas esferas, ya que no nacen de una falla o falta de algún requerimiento (el sistema funciona "perfectamente"), sino que simplemente vendrían a mejorar el sis-tema. Hay que presentar un buen estudio de beneficios por alcan-zar con las mejoras, para que las altas esferas opinen que sería bue-no incurrir en las modificaciones.
• Auditorías: las auditorías generan recomendaciones que no nece-sariamente son tomadas en cuenta. Sin embargo, a diferencia de las fuentes anteriores, las necesidades encontradas en una auditoría tie-nen suficiente fuerza como para ser tomadas en serio. El auditor debe estar al tanto de todo lo que ocurre, y no debe convertirse en un busca-fallas. Muchas veces, el mismo auditor conoce que los avances actuales pueden mejorar en mucho las aplicaciones y reco-miendan el cambio, respaldándose muy bien con documentación y - números estadísticos, necesarios para vender la idea a las altas
esfe-ras.
• Proyectos: es obvio que cualquier nuevo proyecto genera gran can-tidad de necesidades, sea éste un nuevo negocio o compañía, el reestructurar un departamento o el sacar a mercado un nuevo pro-ducto. En todos los casos, se debe realizar la evaluación para deter-minar si todas las necesidades encontradas son dignas de tomarse en cuenta.
• Necesidad obvia: esta es una necesidad que salta a la vista por sí sola. Una necesidad se hace obvia cuando se requiere realizar algu-na función y no se puede porque el sistema no lo permite, y todo el mundo se da cuenta que algo falta o faltó por definirse. El proble-ma es que puede ya ser muy tarde para poder agregar lo necesario para que todo funcione bien. Por ejemplo, pudo no haberse pensa-do en la necesidad de reimprimir cheques, y justo cuanpensa-do el cliente está afuera esperando, la impresora echa a perder el cheque que se estaba imprimiendo y el sistema no permite tirar otro. En una com-pañía bien administrada, la frecuencia de esos hechos debería ser mínima.
• Revisiones: esta es la fuente de necesidades que es la cura contra la que se acaba de estudiar. Las revisiones se encargan de encontrar posibles problemas latentes, y desarrollar una estrategia para que nunca ocurran, o que para q u e cuando lo hagan, su impacto sea mí-nimo. Muchas veces, las únicas revisiones que se efectúan son las de la auditoría. El profesional informático o el departamento
Universidad de Costa Rica
Programas de Educación Continua
mático como tal, deben programar revisiones periódicas de los sis-temas, adicionales a las auditorías, para que las necesidades puedan encontrarse antes de que sean obvias. Estas revisiones deben incluir el análisis de las solicitudes de los usuarios para la corrección de al-gún error (por si esos errores puedan deberse a una necesidad no contemplada), de los programas y salidas, la revisión de los proce-dimientos, la simulación de fallas de todos los tipos y la prueba de la recuperación, etcétera.
1.3 Presentación de la necesidad
Encontrada una necesidad, esta se debe presentar y justificar. La presen-tación hará que las altas esferas conozcan sobre una necesidad que ha si-do encontrada y la justificación le dará la seriedad e importancia del ca-so. Hay que tener en cuenta que no toda necesidad es importante. A los gerentes no les interesa ser molestados porque a la cajera no le aparece en negrita el nombre de la compañía en las facturas, .pero sí es importante para ellos que el sistema no permite la integración de un nuevo módulo adquirido para manejar la información sobre un nuevo producto que quieren lanzar al mercado. Los siguientes son algunos de los puntos que se deben tomar en cuenta al presentar la necesidad al gerente de cómpu-to, o a quien corresponda.
• No es necesaria una presentación espectacular. No todas las nece-sidades son tan importantes como para sacar todo un día de traba-jo para explicarlas. La presentación no es preparada con tanto es-mero como en las de las propuestas, pero sí necesita un poco de re-copilación de datos. Muchas veces esa presentación es coloquial, en la oficina del gerente de cómputo, y sin más ayuda que un papel y un lápiz. La idea es hacer de conocimiento del gerente que existe una necesidad.
• Lleve un documento breve que explique la necesidad. No preten-da que el gerente se acuerde de todo lo que usted, le va a decir. Puede que usted tampoco se acuerde. Por eso, prepare un docu-mento que explique brevemente el problema, enumerando causas y efectos, y si puede, su solución general a grandes rasgos. Dicho do-cumento no puede pasar de 3 ó 4 páginas. Trate de llevar al menos dos copias, una par? usted, y otra para el gerente. Lleve copias adi-cionales para cada uno de los presentes (algunas veces se presenta el gerente o usuario del área donde se encontró la necesidad). • Lleve un estimado de lo que necesita para atacar la necesidad.
Tenga pensado quiénes pueden ayudarlo a realizar la evaluación, con cuáles personas ha de reunirse, cuánto tiempo le llevará, qué equipo ha de necesitar. Lleve todo apuntado y listo para analizarlo junto con el gerente.
Luego de la presentación de la necesidad, es probable que se llegue al acuerdo de que dicha necesidad amerita un cambio en los sistemas. Si es así, se comienza una serie de etapas para poder suplir la necesidad. En el apartado siguiente se revisarán las metodologías para el levantado de requerimientos específicos que se ocupan para la satisfacción de la nece-sidad.
A continuación aparece un ejemplo de un documento que presenta una necesidad.
El siguiente es un informe que presenta un analista al gerente de sistemas, para explicar el problema que se encontró en la consolidación de la empresa:
Hace poco se realizaron las consolidaciones. Se ha descubierto que los montos de los informes sumarios, los cuales se imprimen y revisan cada año, no estaban cuadrando con las sumas manuales de los informes de so-porte, que contienen el detalle de ¡as transacciones. Esto obligó a repetir el procedimiento de suma, lo que es muy tedioso, debido a que se debe te-ner mucho cuidado al sumar tantas páginas (un año de transacciones). Se descubrió entonces que, en efecto, los montos totales no cuadran, por lo que se ha creado una inconsistencia que hace que los informes no sean úti-les. Ahora no se sabe cuáles son los que fallan, si los sumarios o los de de-talle, y se ha comenzado a revisar transacción por transacción para cotejar con los recibos y determinar si faltan o sobran algunos.
Revisando el código de los programas, se ha determinado que el proceso está bien. Sumando los totales por medio de la herramienta de consulta se llega a la conclusión de que los datos correctos son los de los de deta-lle. Investigando más, descubrí que el problema es la antigüedad de los informes. Estos fueron planeados para imprimir totales de 13 dígitos, y las sumas actuales ya alcanzan los 14 dígitos, por lo que la variable
Universidad de Costa Rica
Programas de Educación Continua
de se lleva el conteo se desborda, recortando los miles de millones. Lo an-terior presenta dos problemas, el primero obvio y el segundo un poco su-til:
1. Las variables de suma de totales de los informes deben incrementarse a 14 dígitos (o más) para soportar el crecimiento de los montos actua-les. Estos informes son muy viejos, por lo que darles mantenimiento es difícil; adicionalmente son muchos y, para algunos, la herramienta que los compila se ha desactualizado y puede estar incompleta. 2. La forma en la que se tienen que cuadrar estos informes me lleva a
pensar que debe existir una manera de darles un poco más de infor-mación a los usuarios, de forma que no tengan que sumar manual-mente todo el detalle, esto es, darles cosas como subtotales por pági-na para que tengan que sumar sólo las págipági-nas y no ítem por ítem.
Análisis: Me parece que el problema se da por tener esos informes tan vie-jos en una herramienta desactualízada. Los dos problemas anteriores re-quieren de cambios en dichos informes, por lo que se dan dos posibles so-luciones:
1. Utilizar la herramienta actual y "remendar" los informes para que funcionen en el primer problema, y el segundo dejarlo para una etapa posterior (continuando entonces el procedimiento actual).
2. Adquirir una nueva herramienta para generación de informes que permita rehacerlos dependiendo de las necesidades actuales, con nue-vo diseño y mejor apariencia.
De las soluciones anteriores, sería bueno utilizar la primera, si se requirie-ra la solución inmediata. La segunda se escogería en el caso contrequirie-rario, si no se necesita el cambio de inmediato. En nuestro caso, el descubrimien-to del error les ha permitido cuadrar los dadescubrimien-tos (rellenados con los miles de millones; el resto del monto de los sumarios parece coincidir). Esto elimi-na la necesidad de uelimi-na solución inmediata. Sin embargo, me parece que se debe evaluar la compra del generador de informes con cuidado, ya que la base de datos también es vieja y puede que no todo generador de infor-mes la soporte. Sugiero, finalmente, tomamos el tiempo para decidir si se compra un generador y cuál de ellos se compra, mientras tanto, tratar de realizar las correcciones con la herramienta actual y así ganar tiempo pa-ra realizar las evaluaciones.
El siguiente minicaso ejemplifica la creación de necesidades de cambio en la oficina de correos en vías de modernización.
Minicaso 1
La Oficina de Correos
ciona muy bien, lo que parece no justificar la aplicación de esfuerzos en el cam-bio. Muchos directivos no están de acuerdo con el cambio por el cambio, por lo que intentan respaldar sus planteamientos en la reducción del costo. El problema real es que no pueden encontrar necesidades con suficiente peso, que ameriten la disposición de recursos. Se llegó a la determinación de atacar el problema por varias vías:
• Se contrató una empresa auditora externa para que realizara una revisión com-pleta de procesos y controles.
• Se realizaron entrevistas y encuestas a los usuarios para determinar tos proble mas que ellos pudieran descubrir y las inquietudes que, obviamente, las geren d a s no conocían.
• Se realizaron estudios comparativos con otras oficinas de correos o que ofre-cieran servicios similares.
• Se adquirieron subscripciones a publicaciones del área que hablaran sobre los nuevos enfoques.
Estos estudios arrojaron necesidades de varios tipos, algunas serias y escondidas y otras como grandes oportunidades de realizar proyectos nuevos:
• Se determinó que el manejo de los timbres postales con control manual escri-to dejaba puertas para robos y fraudes, además de que hacía muy difícil d cua-dre financiero.
• Se encontró imposible el poder obtener información estadística de fuentes y destinos, con el fin de dar un servicio de expansión de oficinas y de control de trasiego de correo.
• Los controles financieros generales estaban llenos de portillos y parches. Era necesario automatizarlos y asegurarlos.
• La manipulación de la correspondencia creaba peligro de pérdida, destrucción o daño.
• Muchos empleados se quejaban de trabajo tedioso, innumerables cuentas, re-visiones repetitivas, etcétera.
• Los servicios ofrecidos, aunque tradicionales, se habían convertido en tan sólo un porcentaje de los servicios que otras empresas brindabaa Algunas habían incurrido en el mercado de los mensajes por radio, mensajería por Interne!, te-!ex y fax remotos, bloqueos de correo basura, etcétera.
La compañía comenzó por sanear sus procesos. Una vez hecho esto, comenzó la verdadera modernización, con la conexión a las telecomunicaciones.
2. LEVANTADO DE REQUERIMIENTOS
El levantado de requerimientos para las necesidades de software es simi-lar al del hardware. Sin embargo, los requerimientos en sí son distintos. Mientras en el hardware éstos se basan en las características necesarias para hacer correr un software que se acople al tipo de trabajo de la com-pañía, su volumen y su utilización, en el software dichos requerimientos se basan en las funciones y eficiencia con la que se trabaja. Básicamente,
Universidad de Costa Rica
Programas de Educación Continua
el software tiene pocas preguntas que responder: ¿Puede realizar el tra-bajo? ¿Lo hace bien? ¿Puede hacerlo trabajando junto con lo que ya se tiene? Estas tres preguntas se responden por medio de pruebas y evalua-ción, pero antes de poder comenzar con dichas pruebas hay que determi-nar muy bien cuál es ese trabajo en que se basan las preguntas. Eso es só-lo una parte de só-los requerimientos, las otras definen só-lo que se puede en-tender por hacer bien (requerimientos que definen de cuan buena calidad es el trabajo) y con quiénes debe el software trabajar.
2.1 Determinación de los requerimientos
Los primeros requerimientos son los que determinan qué trabajo es el que el software debe realizar. Éstos se basan, al igual que en el estudio de los requerimientos del hardware, en encuestas, reuniones con usua-rios, análisis de la necesidad, etcétera. Los siguientes son algunos de los puntos que se deben considerar para la definición de este tipo de reque-rimientos:
• Determinarlas funciones que se necesitan: la necesidad puede ser sólo el problema, por lo que se debe buscar también su solución, y ésta es el determinar cuáles funciones son necesarias para poder ali-viar la necesidad que genera todo el proyecto. Esto es muy impor-tante, ya que se tienen que definir muy claramente las funciones principales. Muchas veces nos limitamos a decir: "El problema es tal y necesitamos que no se dé". Esto no ayuda mucho, es mejor si se hace un documento que indique: el problema es tal, y para solu-cionarlo se necesita una función que haga esto y esto, y otra que procese esto otro, y una tercera que cumpla con esto y esto. Eso es un comienzo. Este documento debe ser pasado a los usuarios para que ellos determinen si con esas herramientas pueden terminar con el problema descrito, o si tienen otras ideas o funciones que pueden ser aplicadas- No importa la informalidad con que se escriba, ya que estos documentos iniciales servirán para el análisis posterior, donde se generará de ellos especificaciones para los carteles o la misma revisión de lo que se tiene.
usuarios serán afectados. Luego de saber cuáles son los usuarios in-volucrados con el problema, hay que determinar los inin-volucrados con la solución (aquéllos que serán estudiados o que estudiarán el problema). Por último, aunque no sea una lista definitiva, se levan-tan los nombres de los usuarios que posiblemente sean afectados si se lleva a cabo algún cambio. Estas listas servirán en la fase de aná-lisis, porque a todos estos usuarios hay que notificarles del proble-ma, explicar la metodología por seguir y pedirles ayuda.
• Determinar duplicación de funciones: lo primero que se hace des-pués de obtener las listas, es presentar a estos usuarios la lista de funciones obtenida en el primer paso, con el fin de que ellos deter-minen si existe alguna duplicación. Esto es, determinar si alguna de las funciones que se están solicitando se puede realizar de alguna otra forma con el software actual, si ya hay alguien haciendo lo q u e se pide, o si esa función ya existe en el sistema y ios que la apunta-ron no lo sabían (esto pasa muchas veces). Todas las respuestas de-ben anotarse, no para eliminar las funciones, sino para estudiarlas. Muchas funciones ya se pueden hacer, pero ¿a qué costo?, ¿se hacen bien?, ¿quién conoce el procedimiento?, etcétera. Si se encuentran inconsistencias, hay que revisar porque algo se está haciendo mal y debe corregirse. Hasta podría salir otra necesidad distinta que no se había tomado en cuenta. Cualquier información que ayude a me-jorar el sistema es buena y hay que encontrarla.
• Determinar el proceso de las funciones encontradas: ya que se tie-nen identificadas y depuradas las funciones que se deben realizar, se procede a especificar lo que cada una de ellas realiza. Esto es, definir el proceso que cada una debe realizar para cumplir con su o b -jetivo. Puede ser en prosa común, no tiene que ser en seudocódigo, pero debe ser legible y entendible, para que pueda servir a la hora de realizar los carteles.
2.2 Criterios relacionados con la función que se necesita
Los requerimientos sobre la calidad del trabajo que el software debe rea-lizar, son determinados con base en los criterios relacionados con el tipo de trabajo que la función realiza y en la comodidad de su realización. Es-tos criterios se lisian a continuación (compárense con los tipos de proce-so de la sección 1.1 del tema iv):
• Trabajos interactivos o por lotes: la división por excelencia de los trabajos es la que determina si un trabajo es interactivo o por lotes.
Universidad de Costa Rica Programas de Educación Continua
El trabajo interactivo es aquel que interactúa con un usuario. En es-te caso, el trabajo pasa la mayoría del tiempo en un estado de ocio, ya que el proceso que ei usuario solicita es usualmente rápido y es-pecífico. Eí sistema ha terminado mucho antes que el usuario reali-ce una nueva solicitud. Para este tipo de trabajo se requiere deter-minar cosas como la interfaz, la velocidad de trabajo, el uso adecua-do de recursos, etcétera. Este es un trabajo que no necesita mucho recurso para proceso, pero sí para presentación.
El otro tipo, por lotes, se dedica a procesar lotes de transacciones. Este tipo de trabajo requiere muchos procesamientos y muy poca o ninguna interacción con el usuario. Usualmente se utilizan para realizar cálculos en masa, actualizaciones, impresiones, etcétera. Lo q u e se requiere determinar es la cantidad de recurso que utiliza, el control que se pueda tener de ellos (muchas veces, el detener un tra-bajo por lotes es sumamente difícil, y si se está comiendo alguna in-formación, la solución debe ser apagar el equipo, algo no muy reco-mendable).
• Uso interno o uso externo: este es otro criterio para determinar la calidad del trabajo que se debe realizar. El proceso de uso externo es de cara al cliente. Este es muy importante, ya que los datos con-fiables deben darse con muy buena velocidad y presentación. Aquí se debe tener cara gráfica, impresoras de alta resolución (impreso-ras láser o de inyección de tinta), y hasta es posible pensar en mul-timedia.
El proceso de uso interno es todo lo contrario (casi). Aquí el proce-so es de trabajo interno entre los departamentos de la misma com-pañía. La cara puede ser carácter (a menos que sea para los geren-tes, y este no por marginar al resto de usuarios: las caras gráficas cansan mucho y requieren mucho recurso, las de carácter son más flexibles para el trabajo operativo intenso). En el proceso interno se requieren impresoras rápidas y baratas para tirar listados largos, usualmente de impresoras de líneas o en su defecto, impresoras de baja calidad. Muchos procesos pueden tener menos prioridad (es más importante dar el recibo al cliente apurado que compile la prueba del programador de turno).
ar-chivos hechos con otras aplicaciones, etcétera. Este tipo de aplica-ción o funaplica-ción debe ser muy general, ppr lo que a veces no se com-porta con el mejor rendimiento. Se debe buscar esta opción si el ren-dimiento no es de mucha importancia.
• El software rígido es el q u e tiene una forma de trabajo y no se puede cambian muchas veces este tipo de software obliga a una forma de trabajo ya que ha sido optimizado para que funcione así. Se debe poder realizar el proceso requerido con las restricciones da-das. Si no es así, el software no se toma en cuenta. Si se puede, el software debe ser evaluado para compararlo con su contraparte fle-xible.
• Integrado o independiente: el software puede ser integrado o in-dependiente. El software de trabajo integrado permite que se aco-plen las funciones realizadas con las que el sistema ya realiza, sea de una forma automática, o bajo un proceso adicional sencillo. El soft-ware independiente es aquel que trabaja solo, sin tomar ni dar in-formación del sistema actual. Muchas veces el trabajo no requiere integración y puede ser utilizado en forma independiente, lo que evita los procesos de conversión.
Por último, los requerimientos que tienen que ver con el acoplamiento o compatibilidad de los productos adquiridos y el hardware son mucho más sencillos de identificar; sólo han de seguirse los lincamientos que a continuación se listan:
ü Determinar hardware con el que se trabaja: primero se debe tener determinado el hardware con el que se está trabajando, sus necesi-dades y recurso libres, sus características, etcétera.
• Determinar software con el que se trabaja: luego de la determina-ción del hardware, se realiza la del software. La idea es recolectar toda la información sobre el software que está coniendo actualmen-te. Esto es importante para determinar con quién debe convivir la posible solución a la necesidad.
• Determinar grado de compatibilidad: teniendo ambos datos (este y el anterior), se procede a realizar un análisis de compatibilidad. Esto es, revisar si existen características en el hardware o software que presenten problemas o no permitan el trabajo con otro tipo de software. Hay que determinar los posibles problemas de
Universidad de Costa Rica
bilidad en forma general para cualquier software, y documentarlo. Esto sirve para poder exponer en la solicitud las características que el software debe tener para que pueda correr en el sistema actual. El siguiente minicaso expone el proceso realizado para la incorporación al mercado de arrendamientos de un banco.
Minicaso 2
Incursión al mercado de arrendamientos
El mercado de arrendamientos es un tipo de servicio bancario que permite que el cliente adquiera una prenda, propiedad, etcétera, de una forma conjunta con el banco. El banco es el que pone el dinero y realiza la compra, por lo que lo com prado es propiedad de! banco. El cliente arrienda al banco lo comprado y lo uti-liza para su beneficio. Cada pago cancela el alquiler del bien y, adicionalmente. paga un poco de su costo. Al final, el bien es comprado por completo por el dien-te, en una especie de pago a cuotas. Si el cliente no paga, el banco puede dispo-ner del bien y venderlo o arrendarlo a otro cliente, luego de determinar el valor después de la depreciación del bien.
Actualmente, dicho banco maneja este tipo de transacciones como si fueran prés-tamos, en donde lo comprado funge como garantía. El sistema no esta prepara-do para enfrentar la depreciación, los cambios de dueño, la renegociación, etcétera, ya que no son comunes en un sistema de préstamos. L o s clientes que se tiene son muy pocos, muy allegados al banco. Pero el negocio parece ser bue-no y el banco quiere incursionar fuerte en ese mercado. El departamento de in-formática es puesto al tanto y se realiza la investigación y el levantado de requeri-mientos.
• Se realizaron reuniones con los promotores del proyecto para determinar su envergadura. Se entrevistó a los usuarios y se estudió lo ofrecido por otras en-tidades bancarios y los tramites envueltos.
• Se levantaron listas de funciones que se necesitan realizar para llevar a cabo las transacricnes de arrendamiento. Se tipificó la captación de clientes, la forma-lización. la gestión de cobro y la recolocación de los bienes no pagados por los clientes.
• Se determinó quiénes son los usuarios que actualmente manejan las transac-ciones. Como son transacciones muy familiares y escasas, un grupo de tres empleados se encargaba de realizar todas las tareas. Una reunión de altos
je-fes de la sección de crédito determinó que el volumen esperado ameritaba la inclusión de otras diez personas y la creación de un subdepartamento. Las ires
personas iban a ser transferidas para aprovechar su experiencia.
lidad de los bienes (algunos se deprecian tan rápido que no vale la pena arren-dados) son completamente nuevas y deben ser desarrolladas desde cero e in-tegradas con lo que se tiene hasta el momento.
• Con los datos del estudio de los tramites en otros bancos y e! proceso efectua-do manualmente por los tres usuarios que lo manejan actualmente, se detalla ron los procedimientos y se revisaron la documentación requerida, los tramites legales, los tiempos y estudios que se deben realizar. Todo quedó impreso en una propuesta de manual de procedimientos que sera evaluada y estudiada por analistas de sistemas para determinar su automatización.
• Debido a que parte de lo requerido es ofrecido por el sistema actual, el softwa re que se piense adquirir deberá ser flexible para que se acople a los procedí mientos actuales de otorgamiento del crédito, e integrado para que comparta la información con el sistema actual. Adicionalmente, el proceso es de tipo in temo, dado que son los usuarios del banco quienes van a utilizar dicho softwa re (se había pensado que los clientes tuvieran acceso a la información de sus cuotas, lo que impondría características externas al software, pero esto se pue-de cubrir con lo que se tiene actualmente).
• Por último, se levanta una lista de las características particulares del software de crédito que puedan dar problemas con el software que se necesite adquirir, y se determina el equipo en el que el nuevo software correrá.
3. ADQUISICIÓN
En este apartado se tratará sobre los aspectos que se deben considerar en una adquisición. Primero se determinarán los tipos de software que pue-den adquirirse, luego se hablará de la forma en la que el mercado los ofrece. Seguidamente, se detallarán los pasos para la adquisición de un producto de software. Por último, se estudiarán las alternativas para la adquisición del software y los criterios que deben tomarse en cuenta pa-ra decidirse por alguna.
3.1 Tipos de software
Antes de pensar en la adquisición como proceso, se deben aclarar los ti-pos de software que el mercado ofrece, titi-pos de software o aplicaciones que se han definido con el tiempo según su uso y mecánica de trabajo. Existen muchas agrupaciones del software; la siguiente es una que lo cla-sifica según su uso y según la forma con que trabaja.
• Herramientas: las herramientas son todas aquellas aplicaciones o paquetes que ayudan al usuario a realizar un trabajo. Usualmente
Universidad de Costa Rica Programas de Educación Continua
son de bajo nivel, es decir, las utilizan personas con poco conoci-miento de computación. Este tipo de software se subdivide, según su uso, en:
• Diagnóstico: las herramientas de diagnóstico son las que per-miten realizar pruebas para determinar qué es lo que falla en un sistema. Usualmente son aplicadas al hardware, pero exis-ten algunas para diagnosticar fallas en el software. Lo que ha-cen es simular la operación del aparato o software y recolectan el resultado. Algunas sólo imprimen lo recolectado, otras más completas lo interpretan, determinan las posibles causas del fallo y presentan los pasos que hay que seguir para asegurar-se de que esas causas asegurar-sean las correctas o, incluso, hasta arre-glan el problema.
• Desarrollo: estas son herramientas que permiten la fabrica-ción de aplicaciones o paquetes. Estas herramientas incluyen desde los compiladores, hasta los generadores de código. Es-tas henamienEs-tas son de uso de la gente de cómputo.
• Mantenimiento: estas otras herramientas permiten tener bien sintonizado el equipo o el software. Se utilizan para mantener en óptimas condiciones el trabajo. Se encuentran muchas he-rramientas de este tipo en el mercado. Entre las utilidades que ofrecen están las de mantenimiento de discos, de memoria, de carga de trabajo, entre otras.
• Oficina: el software de oficina es relativamente nuevo. Esto es, que permite realizar labores en el ámbito personal, de negocios y de tra-bajo en grupo. La informática aplicada a las labores de oficina se le conoce como ofimática. Entre los paquetes incluidos se encuentran: procesadores de palabras integrados, hojas electrónicas, planifica-dores, agendas, correos electrónicos, etcétera.
Sombrilla: el software sombrilla es el que in-tenta cubrir todos los aspectos por sí sólo. Existen muchos paque-tes c o n la filosofía de sombrilla. La mayoría no permiten que otra marca de software tra-baje con ellos, hacien-do m u y difícil la inte-gración. Existen, sin embargo, ciertos pa-quetes sombrilla que
abren sus especifica- figura J. Subtipos de software industrial
A LA MEDIDA
SOMBRILLA HETEROGÉNEO
NÚCLEO
ciones y se presentan en módulos adquiribles p o r separado, io que permite que se trabaje con otra marca de software si así se quiere, escogiendo el mejor módulo de cada marca. Las mar-cas q u e fabrican software sombrilla son usualmente grandes nombres de la computación, que pueden intentar cubrir todos los módulos de un sistema por sí solos. Las aplicaciones com-pletas (un sistema bancarío completo, por ejemplo) pueden to-marse como aplicaciones sombrilla muy específicas, que usualmente no tienen problema de integración, ya que la espe-cificidad hace difícil imaginar el mezclar distintos módulos. Los problemas vienen cuando se adquiere un software sombri-lla que no posee un módulo desarrosombri-llado, o que los módulos que presenta no tienen la función requerida. En este caso, en-contrar un módulo de otra marca independiente que rellene la necesidad puede ser difícil, y aun si se encuentra, ponerlos a trabajar conjuntamente puede resultar complicado también. Heterogéneo: es el software que se compone de módulos, co-mo el mencionado anteriormente, en donde cada módulo pue-de adquirirse por separado y no necesariamente pue-de la misma marca. El problema con este tipo de software es la compatibi-lidad. Los módulos siempre tratan de ser independientes y tratan de poder comunicarse con los diferentes módulos de la competencia. Peno aun así, se presentan características o fun-ciones que pueden realizarse sólo con los módulos de la ma marca, como un intento de obligar a comprar todo a la mis-ma casa. Además, el intento de hacerlo lo más general posible significa que no tendrá solución para las necesidades
Universidad de Costa Rica Programas de Educación Continua
cas de la empresa. Esto es, cuando la empresa realiza una fun-ción de alguna forma especial o particular, o que se tenga una filosofía de trabajo que exige ciertos controles especiales, el software puede no tenerlas porque son propios de la empresa y no se usan en otras.
Específico: es el famoso software hecho a la medida. Este software no se encuentra en la calle, es construido a partir de especificaciones detalladas que se proponen en la empresa. El software puede ser desarrollado por personal de la empresa o personal contratado temporalmente. Si la necesidad puede cubrirse con un software común, que ya ha sido hecho y se vende comercialmente, es mejor comprarlo que ponerse a construirlo de la nada. Pero ciertas necesidades requieren de un software completamente nuevo, no existente en el merca-do, que deberá ser construido desde el principio. Vale decir que este tipo de desarrolló presenta un sinnúmero de proble-mas, la mayoría relacionados con la mala planeación y la ma-la especificación. Además de ser uno de los más caros, es de los más lentos, pero si se monta bien todo, puede ser el softwa-re que le llene las necesidades de la empsoftwa-resa mejor que cual-quiera.
3.2 Dónde obtener software
Las formas de obtener software del mercado son muy variadas. Los ti-pos de comercio en donde se consiguen software varían su forma de tra-bajo, su precio, lo que ofrecen y su garantía. Entre los tipos de comercio que se utilizan para la compra de software se encuentran:
• Casas de software: muchas compañías que fabrican software, lo venden directamente. Estas son algunas veces compañías pequeñas que no tiene distribuidores, o firmas grandes que tienen puestos de venta en las calles. Este software es software de paquete, desarro-llado para la venta masiva, no es hecho a la medida.
• Intermediarios: los intermediarios aparecen para ofrecer software de casas pequeñas. Estos intermediarios compran a un precio bajo cantidades de software a compañías pequeñas que no tienen forma de promocionarlo, y lo distribuyen y le dan publicidad. El costo de la publicidad, el mercadeo y la comisión es el que se paga de más a los intermediarios. Sin embargo, mucho de este software prueba ser muy bueno y salva la necesidad perfectamente, por lo que el costo disminuye ante el beneficio. Pero los intermediarios no sólo traba-jan con compañías pequeñas; el software de las casas grandes que no quieren gastar esfuerzo en venderlo a gran escala es recogido por estos intermediarios también. Es decir, los intermediarios usual-mente tienen el software que se requiere, sea famoso o desconocido, siempre y cuando se requiera software general y no hecho a la me-dida.
• Fabricantes de computadores: esta es otra forma de adquisición, ya muriendo para el mercado de microcomputadores. pero aún flotan-te en el mercado de máquinas grandes. Los fabricanflotan-tes de un com-putador fabrican además el software que pueda correr en la máqui-na, montando un paquete lo más completo posible. Algunas veces se paga a otra compañía de software para que realice los paquetes. Así, se vende una solución completa en lugar de una máquina sola. Esto se hace para poder vender la máquina, dado que un equipo nuevo que no tenga software desarrollado no tiene mucho futuro, ya que no se puede utilizar. Lo mismo pasa con el sofrware, especí-ficamente con los sistemas operativos: deben tener software que co-rra con ellos, sino, no se venden. Es por eso que las nuevas máqui-nas se fabrican con la capacidad de emular (correr como si fueran otras) el software de otras máquinas con más éxito, al igual que los sistemas operativos.
Universidad de Costa Rica
Programas de Educación Continua
• Internet: es la mayor de las fuentes de software que existe en el mundo. En ella se encuentran casas, intermediarios y, adicional-mente, pequeñas empresas que ofrecen sus productos. Además, se encuentran muchos foros de desarrollo y discusión, en los que au-tores individuales presentan sus trabajos para q u e sean evaluados bajo la técnica de mercado llamada shareware. El shareware es una forma de adquisición del tipo "pruebe antes de comprar". Los pro-gramas sharcivare son propro-gramas completos que tiene alguna dis-función (alguna dis-función no trabaja, o trabaja sólo por cierto tiempo) y que permiten al comprador probar el funcionamiento. Si el pro-ducto es bueno, el comprador contacta al programador, casa o inter-mediario y le propone una compra de la versión comercial del pro-ducto. Muchas veces es una forma muy buena de adquirir algo con la certeza de que funciona.
• • Desarrollo propio: la otra forma de adquirir software es desarro-llándolo personalmente. Esto se justifica si el software es muy es-pecífico y se requiere que se haga de la nada. Para este desarrollo se tienen tres tipos de forma de trabajo:
• Desarrollo en casa: aquí, quienes realizan el desarrollo, son los empleados actuales de informática. Esta alternativa se de-be considerar si el desarrollo es pequeño y se requiere de for-ma inmediata. Se convierte en un problefor-ma cuando se utiliza el personal de la empresa porque se dejan de realizar otros tra-bajos. Sin embargo, si el personal fue contratado para ese tipo de trabajo, se estaría utilizando como se debe y no habría pro-blema.
• Contratación de personal: esto sucede cuando no se tiene per-sonal disponible para programar una aplicación y se contrata temporalmente una o más personas para que se integren al equipo de programación y ayuden a crear la aplicación. Una vez terminada, sus servicios dejan de ser requeridos.
ga un precio parecido al de la adquisición directa. Además, el ma-nejo del paquete puede no ser el adecuado por parte del correo y puede echarse a perder y, también, dichas compañías no se respon-sabilizan por el software enviado y no ofrecen garantía.
• Tiendas: por último, están las tiendas. Éstas, como los intermedia-rios, compran directamente de las casas, pero exponen sus produc-tos en anaqueles para que el cliente los pueda ver y comprar como en un supermercado. Estas tiendas de software ofrecen garantías y - son de fácil ubicación (es decir, no se pueden esconder como las
compañías por correo o los intermediarios sin ubicación física).
3.3 Pasos que se deben seguir para adquirir un software
Conocidos ya los tipos de software y los lugares o formas de adquirirlos, se presentan a continuación una serie de pasos que se han de seguir en el caso de decidir !a adquisición de algún software.
1. Determinar los Requerimientos: esta primera etapa ya ha sido ex-plicada. Se trata de determinar lo que se requiere que el software cumpla para que llene las expectativas y se pueda adquirir.
2. Obtener información del mercado: este paso es esencial. En el ca-so de que el ca-software sea puesto en licitación, sea para compra o pa-ra desarrollo, las ofertas dan la muestpa-ra del mercado que se necesi-ta. Pero si se va a realizar una compra directa, es necesario obtener la lista del software que se ofrece, con sus características y costos. Para esto se debe realizar un sondeo, sea en revistas, catálogos, In-ternet, proveedores e incluso en otras empresas. La idea es tener la mayor cantidad de información sobre los productos ofrecidos en el mercado para realizar la mejor decisión.
3. Escoger alternativas para evaluar: luego de recopilar toda la infor-mación, se escogen las alternativas que serán evaluadas. Esto se ha-ce comparando lo que se ofreha-ce contra ia lista de requerimientos. Si se cumplen los requerimientos, y el factor costo se adecúa a lo esti-mado para gastar en el software, entonces esa alternativa se con-vierte en un buen candidato y se separa para realizar una evalua-ción más profunda.
Módulo 3: Auditoría de Adquisiciones
Universidad de Costa Rica
Programas de Educación Continua
4. Evaluación: en este paso se ponen en práctica las metodologías es-tudiadas en el tema III. De las alternativas escogidas se consigue la información necesaria, hasta la copia del producto, para poder rea-lizar mediciones y pruebas. Primero se debe evaluar si la alternati-va se merece tomar en cuenta para una medición profunda. Algu-nas consideraciones o preguntas que deben contestarse para la al-ternativa se encuentran en el apartado de evaluación más adelante. Luego de determinar que la alternativa es fuerte, se procede a nego-ciar con el proveedor para que facilite una copia para realizar prue-bas. Esto debe hacerse con cuidado. Las consideraciones legales para correr pruebas se discuten en el apartado de factores adiciona-les, más adelante en este tema.
5. Realizar pruebas: esta es la etapa de la prueba. Aquí, con el soft-ware instalado, o una copia de evaluación de éste, se procede a uti-lizarlo en vivo y a medir su calidad y rendimiento con los datos rea-les. Esto debe ser muy bien planeado, de forma que nada quede por fuera. Además, las pruebas deben realizarse con cuidado, tener to-do respaldato-do, y para realizarlas no se debe desarmar nada que pueda poner en peligro el funcionamiento de la empresa en caso de que el producto probado cause problemas o no sea capaz de mane-jar lo que se le impuso.
6. Escoger alternativa: luego de las pruebas y evaluaciones, se debe tomar la decisión. Ésta se debe reforzar con los resultados de las pruebas y las evaluaciones económicas y de factiblidad. Al escoger y dar la autorización para la adquisición, se debe comunicar con el proveedor escogido y solicitar negociar un contrato.
7. Instalan luego de firmado el contrato y adquirido el producto, se procede a la instalación y puesta en marcha. Esta etapa también tie-ne que ser platie-neada con cuidado, pues se tietie-ne que llevar con cal-ma y paulatinamente. Se deben definir procedimientos de contin-gencia, cuidando un mal funcionamiento.
rápido y con ofertas. Toda esta inforrnación es necesaria para que quede como historia de la compra y pueda ser utilizada en adquisi-ciones posteriores.
3.4 Consideraciones que se deben tomar en cuenta para decidir la adquisición
Como último punto de este apartado sobre adquisición, nos referiremos a las consideraciones que se han de tomar en cuenta para decidir si se realiza la compra, la contratación temporal o el desarrollo extemo. Estas consideraciones deben ir acompañadas de evaluaciones de distintos de-partamentos, tales como los encargados de los recursos humanos y de los aspectos económicos.
• Tamaño: la primera consideración es la del tamaño. Si se requiere un programa que una persona sola puede realizar en una semana, no es lógico contratar a una empresa, y una empresa no aceptaría un contrato por algo tan pequeño. Si lo que se necesita, por el contra-rio, es algo demasiado grande, los costos se multiplican si se pone a trabajar a un empleado sólo. Si se necesita realizar un trabajo pe-queño, se puede utilizar a un empleado actual para que lo haga. Si se requiere un trabajo un poco más grande, puede considerarse la posibilidad de contratar a un empleado adicional q u e trabajaría ba-jo contrato temporal. Si el sistema es muy grande, es meba-jor contra-tar a una empresa de nombre y con experiencia, que tenga un gru-po de profesionales capacitados para realizar el trabajo.
• Costo: otra consideración es el costo. En los proyectos de tamaño medio, puede escogerse entre la contratación temporal y una em-presa. Aquí se evalúa el costo en el que se incurre en cada alterna-tiva: algunas veces, la contratación de una empresa es más barata que contratar a casi todo un equipo de informáticos; pero si el siste-ma no requiere tanta siste-mano de obra, la empresa, con sus valores agregados, puede llegar a ser más cara. Para decidir hay que pedir la oferta con el costo a la empresa, estimar el tiempo hombre reque-rido y el costo que tendría si se realiza la contratación temporal. • Disponibilidad de personal: otra consideración importante se
ha-ce evidente cuando lo que se neha-cesita son arreglos pequeños, pero varios. En estos casos se evalúa si los actuales empleados pueden suplir las necesidades. De no ser así, o si los empleados son muy valiosos para ponerlos a íeaüzar tareas para las cuales están
Universidad de Costa Rica
Programas de Educación Continua
calificados (por ejemplo, un administrador de base de datos insta-lando el Windows en las PC), se debe considerar la contratación tem-poral. Es difícil que se deba contratar una empresa, á menos que sea del tipo de empresa que alquila el servicio de programación o man-tenimiento. A estas empresas se les paga un alquiler y ellas mandan a una persona que se encarga de programar o dar el mantenimien-to, como si se hubiera contralado directamente al empleado. La ventaja de estas empresas es que ellas garantizan que el trabajo que la persona que envían realiza es de buena calidad.
• Confidencialidad: no todo el software puede ser desarrollado por personas de afuera. A veces, parte del software trata con informa-ción que es confidencial o muy delicada y que no puede ser mane-jada por cualquiera. En este caso, ni la contratación temporal ni el desarrollo externo pueden darse y, ante esto, se debe trabajar con lo que se tiene, o en su defecto, contratar de forma permanente a más empleados.
• Experiencia: la experiencia es otra consideración importante. Los empleados actuales pueden tener experiencia en la forma de traba-jo y los datos y aplicaciones que se tienen, por lo que son una bue-na alterbue-nativa si el software debe ser parecido a lo que ellos realizan día con día. Si el software es nuevo por completo, y se necesita tra-bajar con herramientas que nunca se han usado en la empresa, o si el proceso no es muy conocido por los empleados, entonces es me-jor contratar una empresa que haya hecho trabajos similares con an-terioridad. O en su defecto, contratar temporalmente a personal ca-pacitado o que ya haya trabajado en cosas similares.
A continuación se presenta una lista de casos en los que se aconseja la contratación de personal temporal:
da en esa época). George Jenkins en su libro Manual de procedimien-tos y políticas de los sistemas de información aconseja pensar en outsour-cing para los siguientes casos:
Operaciones en las que es más difícil manejar y conformar el personal.
Suplir recursos o talentos no disponibles en la organización. - Reducir los costos internos de operación. Liberar recursos
pa-ra otros proyectos.
Para traer mejoras y beneficios inmediatos (eliminando el pro-ceso de entrenamiento).
El siguiente minicaso continúa con el proyecto de arrendamientos del mi-nicaso 2, después de decidirse que la adquisición no es una solución via-ble.
Minicaso 3
Desarrollo del proyecto de arrendamientos
El departamento de sistemas ha evaluado las necesidades planteadas para el pro-yecto de incursión en el mercado de arrendamientos. Se realizaron las siguientes pesquisas.
• Se contactó con los proveedores del software actual de crédito, pero éstos no ofrecieron solución inmediata. Propusieron que ellos desarrollarían las modifi-caciones del producto. Se estimaron d o s meses de negociaciones y unos cua-tro de trabajo.
• No había mucho donde escoger, ni en Internet, ni con intermediarios. Ningu-no de los productos de software revisados cumplían los requerimientos bási-cos (esencialmente las consideraciones de flexibilidad e integración). Se con-tactó el fabricante del equipo y este remitió de nuevo a los proveedores del punto anterior.
• Se estimó que los requerimientos eran menores y que la mejor opción era el desarrollo casero.
• El proceso de desarrollo de productos nuevos estaba requiriendo de la totali-dad de los recursos del departamento de sistemas, por lo que no se consideró la opción de destinar personal para ese desarrollo en particular.
• El tamaño de los cambios se consideró mediano. Se estima que un grupo de dos personas puede llevar a cabo los cambios, por lo que la contratación de una empresa completa es un gasto innecesario. Por esto la opción de los pro-veedores del software de crédito fue rechazada.
• Se contrata a dos personas por un período de tres meses para que realicen los cambios y generen la documentación necesaria.
Universidad de Costa Rica Programas de Educación Continua
En esta sección se trató sobre los tipos de software, fuentes y pasos de ad-quisición. Lo anterior conlleva a evaluar las" alternativas ofrecidas. El si-guiente apartado detalla con profundidad dicho proceso de evaluación.
4. PROCESO DE EVALUACIÓN DE ALTERNATIVAS
Habiendo ya determinado el tipo de adquisición, el tipo de software, y teniendo ya las alternativas seleccionadas para evaluación, se procede a realizar la evaluación misma. En esta etapa se analizan ciertos puntos que pueden dar valor a la alternativa en estudio. Si esta evaluación se ba-sa en un software anterior, se debe contactar al proveedor para obtener las facilidades para realizar pruebas sobre el paquete.
Muchas veces, en paquetes pequeños o conseguidos como shareware, el software se ofrece con limitaciones para las pruebas necesarias. En este caso, el software es instalado y probado por el tiempo que el mismo soft-ware determine, o que las pruebas ameriten. Si no es este el caso, o sea, si el proveedor no ofrece el software para pruebas, se debe negociar la so-licitud de dicho software, eso si es necesario, claro está, realizar pruebas. En este apartado se verán algunos puntos necesarios que se han de cote-jar para valorar la alternativa. Luego de esto, se analizará la posibilidad de pruebas con más calma, y las implicaciones legales que estas pruebas conllevan.
Las alternativas seleccionadas para evaluación han de ser medidas y va-loradas. En este punto se sabe que la alternativa está dentro del presu-puesto y que dice cumplir todos los requerimientos que se solicitaron. Esta fue una selección superficial.
Ahora se revisarán una serie de puntos que se deben contestar para se-leccionar las mejores alternativas. Éstas son las que se han de probar. Los puntos que se deben revisar son los siguientes (este es un conjunto de puntos importantes, pero se pueden incluir miles de puntos adiciona-les si es requerido):
equipo determinado y en algún lugar del archivo de léame se dice que corre en dicho equipo, pero con cie'rtos problemas o restriccio-nes. Si el equipo que la empresa tiene presenta algún problema con el nuevo software, es mejor descartar por el momento dicha alterna-tiva.
2. Verificar si las características detalladas del software cumplen con lo requerido: muchas veces se dice que el software puede usar una determinada función, pero en la documentación se dice que esa fun-ción no está disponible aún, o se da con la versión x (que cuesta el doble de lo que costaba la alternativa ofrecida), no se dice la verdad completa. Es importante verificar con cuidado lo que se ofrece. Si un software ofrece mucho, hay que revisar a qué costo lo ofrece, o bajo qué condiciones.
3. Verificar el estado actual del software: se puede recopilar informa-ción como: autor del software, compañía, cantidad de instalaciones hechas, evolución del software, problemas encontrados con otras versiones, etcétera. A esto se le puede agregar una revisión por en-trevistas, llamando a empresas o personas que conozcan el softwa-re y que puedan darnos una opinión sobsoftwa-re él.
4. Determinar con detalle el costo del software: esto es, no sólo el costo de adquisición, sino también el costo de instaLción, manteni-miento, aditamentos al equipo, costo de personalización (en caso de que tenga que personalizarse a las necesidades de la empresa). Mu-chas veces, un software barato en sí, incurre en mucho más costo en sólo la instalación.
5. Los ofrecimientos del proveedor: es importante notar las facilida-des que el proveedor ofrece, tales come tratos financieros o tratos de mantenimiento. Pero además, hay que tomar en cuenta las implica-ciones de las licencias. Muchas veces, el software se vende con li-cencias por usuario, lo que significa que si se compra, el software lo puede usar sólo una persona a la vez. Algunos tienen restricciones para copiar el software en la red. Otros ofrecen licencias corporati-vas, para múltiples usuarios, etcétera. Todo esto ha de tomarse en cuenta al decidir tratar con determinado proveedor.
6. Verificar los derechos que se adquieren: entre estos derechos es-tán el de hacer copias, el de utilizar el software para pruebas, el de
Universidad de Costa Rica Programas de Educación Continua
modificar el código, el de integrarlo a otros sistemas, etcétera. Se debe tomar en cuenta sí alguno de estos derechos-es importante, y el software lo niega.
7. Determinar el esfuerzo que implica realizar el cambio: muchas veces, un software es "maravilloso", pero no puede ser instalado sin sacrificar mucho tiempo o la configuración que se tenía de ciertos equipos. Otras veces, el software requiere otro producto adicional que no se tiene en la empresa, o no se tienen las licencias del caso. Es importante determinar el impacto de la implantación, traducién-dolo a
costos.-8. Revisar el tipo de documentación: se debe solicitar una lista de la documentación ofrecida con el software. Además, se debe determi-nar el medio en el que se presenta la documentación, sea magnéti-co o en papel.
9. Revisar el tipo de soporte que el proveedor ofrece: esto es muy importante: se debe tener la certeza de que el software tiene un equipo de mantenimiento capacitado. Muchos intermediarios sólo conocen del software como para venderlo, pero no ofrecen soporte alguno. Si se ofrece un teléfono, se debe llamar y corroborar que el servicio de soporte existe y si se puede hacer uso de é!.
10. Revisar ofrecimientos especiales: muchos paquetes ofrecen ciertos regalos por la compra inmediata del producto. Se ha de revisar si esos ofrecimientos valen la pena o no tienen importancia. Entre ellos están los descuentos, las funciones adicionales, herramientas nuevas, etcétera. Se debe tener cuidado, ya que algunos ofrecimien-tos son en realidad la forma de desviar la atención a cosas adiciona-les cuando las funciones principaadiciona-les no son adecuadas.
Revisados estos puntos, y otros que el estudiante crea necesarios para el caso específico de software que lo ocupa, se procede a la eliminación de alternativas que prometían, pero que no dieron la talla ante ia evaluación. A las alternativas que quedan, se debe decidir si se les corren pruebas. Para correr pruebas sobre un software, este debe ser instalado en algún equipo. La instalación es el primer problema. Que se pueda instalar con el permiso del proveedor es el otro. Revisemos las implicaciones que tie-ne el querer probar un software.
• Instalación: el primer problema es la instalación en sí. Si se quiere instalar un software pequeño, fácil de instalar y sin problemas de compatibilidad, esta instalación puede hacerse en una cantidad ma-yor de máquinas, dando oportunidad de que varios usuarios lo puedan probar a la vez. Si el software es más grande, requiere de equipo de medio rango o más; entonces habrá que analizar si se puede realizar la instalación sin que afecte lo que ya está corriendo. También, se debe analizar lo que se necesita para la instalación: además del software, hardware adicional, configurar el hardware actual, montar algún otro software que sea necesario para correr el que se va a probar, etcétera.
• Obtención de! software de prueba: el otro problema es el obtener el software de prueba. Muchos vendedores ofrecen el software ins-talado por un período de evaluación que va desde una semana has-ta 30 días. Otros se mostrarán reacios a inshas-talar el software para evaluación. Usualmente, estos últimos son los que venden softwa-re bastante comercial, con una base instalada en el mundo de millo-nes de copias, que dan por asentado que todo el mundo lo ha pro-bado y compropro-bado, y que no tiene sentido que la empresa le apli-que más pruebas. En cierto sentido tienen razón: no se debe des-perdiciar tiempo en probar software que ya muchos han probado, se les puede llamar y preguntar. Sin embargo, se debería sobcitar aunque sea un demo (un simple vídeo), para ver la operación y fun-ciones que ofrece con detalle.
Al instalar un software para prueba, es importante dejar en claro al proveedor que es para prueba. Muchas veces el proveedor asume que la instalación implica la compra misma del software. Muchas otras veces, el proveedor quiere cobrar por el tiempo que el softwa-re está instalado. En estos casos, hay que firmar un pequeño con-trato de pruebas (cosa poco común, ya que si un proveedor presen-ta este tipo de problemas se oppresen-ta por no tomar su alternativa en cuenta), en donde se especifique que la copia que se realizará es por
Universidad de Costa Rica Programas de Educación Continua
concepto de pruebas, y se detalle tiempo, lugar de las pruebas y ti-po de pruebas (hasta quién las realiza y si personal del proveedor estará presente). El consejo es siempre consultar con el proveedor. • Forma de presentación del software: se puede pedir el software
para pruebas, pero se tiene que tener mucho cuidado con lo que el proveedor entrega debido a que no siempre es lo adecuado para evaluar. Los proveedores suelen entregar:
• Demos: los demos son programas que presentan lo que el software puede hacer. Los demos no sirven para pruebas; con ellos sólo se puede evaluar si se ofrecen las características ne-cesarias, y ver la cara del producto. Esto porque no es el pro-grama en sí, sino una simulación que muchas veces corre ma-ravillosamente en comparación con el software real. Esto se usa mucho en software de equipó grande donde, para realizar una presentación, se lleva un demo que puede correr parecido al producto, pero en una microcomputadora portátil.
• Shareware: los shareiuare también son una forma e presenta-ción para evaluapresenta-ción. Usualmente se da una copia operativa del software para evaluación, pero esta copia tiene limitantes que evitan su uso prolongado o efectivo. Por ejemplo, puede llevar la cuenta de los días que se ha utilizado, permitiendo un máximo de 30. O puede permitir realizar todo el trabajo que se quiera, pero con ciertas opciones deshabilitadas, como el poder salvar el trabajo o poder imprimir. Se han de tomar con precaución dichas restricciones, ya que la evaluación no pue-de hacerse completa porque el software dice tener una función pero no se puede probar si es así. Además, sin las opciones restringidas, el software puede presentar mayor rendimiento que cuando se tienen.
5. FACTORES ADICIONALES
Por último, se tratará un factor adicional a la adquisición de software: e! aspecto legal. Usualmente, cuando se compra un software de cualquier tamaño, se está incurriendo en un contrato legal entre el que vende y el que compra. Aunque no se firme nada, cada software que se utilice tie-ne una licencia con una serie de restricciotie-nes que deben ser leídas con cuidado. Es usual que nadie las lea, aparecen casi siempre al inicio de la instalación de un producto. Estas licencias tienen información importan-te sobre lo que se ha adquirido y el permiso que se tiene de usarlo. Al-gunos de los puntos que se determinan ahí son:
• Validez de la licencia: Algunas dicen que con sólo abrir el paque-te ya se aceptan los términos de la licencia, otras que a la hora de instalar.
• Permisos: se detallan los permisos que se tienen del uso del softwa-re. Por ejemplo, se puede indicar ahí que no se puede utilizar el software en una red, o que no se puede instalar en cierta clase de equipo.
• Responsabilidad limitada: muchos recurren a la frase as it is, que significa tal y como es. Esto indica que el software se entrega a ries-go del cliente. En este caso, ai el software destruye información y daña algún equipo, la compañía fabricante del software no se hace responsable.
• Se detalla el significado de copia: esto es lo más delicado. Una co-pia puede definirse como coco-pia en disco, o simplemente como du-plicación del producto. En el segundo caso, el ejecutar el producto produce una copia de éste en la memoria del computador. Si se es-tablece que una copia puede hacerse sólo en un computador espe-cífico, se pueden encontrar problemas si el software es ejecutado en otro equipo. Por ejemplo, si usted compró una herramienta de diagnóstico, y se va por el edificio revisando máquinas, puede estar incurriendo en falta. Esto porque la licencia puede decir que se per-mite una copia en su computador, no en el de los demás. En este ca-so, se exigiría que se compre una copia por cada computador que se desee revisar.
Leer estas licencias es leer la letra pequeña. Es importante que se revise junto con un abogado para que éste le ayude a encontrar los peros lega-les que son peligrosos para quienes compran el software. Además de la
Universidad de Costa Rica
Programas de Educación Continua
licencia, en la mayoría de los casos se debe crear un contrato. Un aboga-do puede ayudarle, pero trate de que conozca sobre ieyes en lo que a computación se refiere. Muchos abogados incluyen cláusulas de protec-ción en los contratos, como si se fuera a comprar una casa o algo así. Las cláusulas deben estar de acuerdo con lo que se merca, en este caso soft-ware. Ciertas consideraciones que se deben tomar a la hora de escribir el contrato son:
1. Que el contrato permita la devolución del producto si este es encon-trado no aceptable, antes de cierto período de tiempo, sin cargo al-guno.
2. Que el contrato especifique un trato preferencial en el caso de ser una de las primeras empresas en utilizar el producto.
3. Que se deje en claro el tipo de mantenimiento que se ofrece, o si es-te es negociado con un contrato por apares-te.
4. Se debe especificar fechas de entrega y fechas de término de mejo-ras o personalización. Si el software debe ser personalizado, se de-be detallar qué es lo que se personaliza y el tiempo q u e se lleva rea-Uzarlo.
5. Revisar con claridad las restricciones de uso y modificación sobre el software. Es importante dejar en claro ciertas cosas, cerno la liber-tad de uso y el no perder la opción de mantenimiento, en caso de que se realicen cambios en el software por parte de la empresa. Tal vez se pueda aceptar una eliminación de responsabilidad por erro-res si se ha modificado algo, pero no la eliminación de la opción de mantenimiento por completo.
6. Especificar penas por atraso, en ambos bandos.
7. Sería bueno incluir las características y ofrecimientos hechos en co-tizaciones o brochures, para que lo ofrecido quede estipulado en el contrato y no pueda negarse.
8. Se debe especificar qué es lo que se entrega y las fechas en las que se hará dicha entrega.
9. Se debe dejar claro el período de garantía y lo que ésta cubre. 10. Se debe especificar con detalle todo ofrecimiento: qué se entiende
por mantenimiento, capacitación, entrega de materiales, etcétera.
Resumen
El software es la otra gran parte de los sistemas informáticos. Es la lógica que da cuerpo al pro-ceso de la información y debe ser el óptimo para lograr aprovechar al máximo el hardware ad-quirido. El software es muy difícil de medir, pero es h respuesta directa a tas necesidades y re-querimientos que se presentan en un proyecto de automatización o actualización. Este hecho es el que hace que el software sea un poco más sencillo de analizar, dado que los objetivos que se persiguen son directamente solucionados por el software. El software tiene un carácter es-pecífico, contra el carácter general del hardware.
En la actualidad, las necesidades saltan a la vista por sí solas dado que, en todo trabajo, la au-tomatización ha alcanzado un lugar importante dentro de las altas esferas de la empresa. Las oportunidades de encontrar una necesidad que se pueda resolver por software son muchas, sea que la compañía esté empezando, introduciendo una nueva línea o lleva ya varios años sin actualizarse. Las fuentes para buscar necesidades son: el comienzo de trabajo, los proyectos nuevos y la actualización de sistemas.
Las sugerencias de cambio, respaldadas usualmente por una necesidad encontrada, provienen de varias fuentes, entre que las que se pueden citar la publicidad, los usuarios, los resultados de auditorías, los nuevos proyectos, cuando la necesidad es obvia o cuando hay revisiones. Encontrada una necesidad, ésta se debe presentar y justificar. La presentación hará conocer a las altas esferas que una necesidad ha sido encontrada y la justificación le dará la seriedad e importancia del caso. Hay que tener en cuenta que no toda necesidad es importante. Los si-guientes son algunos de los puntos que se deben tomar en cuenta al presentar la necesidad al gerente de cómputo, o a quien corresponda.
• No es necesaria una presentación espectacular. No todas las necesidades son tan impor-tantes como para sacar todo un día de trabajo para explicarlas.
• Se deben llevar pensadas soluciones en forma general. No hay que ser parte del proble-ma, sino de la solución.
• Lleve un documento breve que explique la necesidad. No pretenda que el gerente se acuerde de todo lo que usted le va a decir. Puede que usted tampoco se acuerde. • Lleve un estimado de lo que necesita para atacar la necesidad. Tenga pensado quiénes
pueden ayudarlo a realizar la evaluación, con cuáles personas ha de reunirse, cuánto tiempo le llevará, qué equipo ha de necesitar. Lleve todo apuntado y listo para analizar-lo junto con el gerente.
Luego de la presentación de la necesidad, es probable que se llegue al acuerdo de que dicha necesidad amerita un cambio en los sistemas. Si es así, se comienza una serie de etapas para poder suplir la necesidad.
El levantado de requerimientos para las necesidades de software es similar al del hardware. Sin embargo, los requerimientos en sí son distintos. Básicamente, el software tiene pocas pre-guntas que responder: ¿Puede realizar el trabajo? ¿Lo hace bien?- ¿Puede hacerlo trabajan-do junto con lo que ya se tiene? Estas tres preguntas se responden por medio de pruebas y eva-luación.