IMPLEMENTACIÓN,

PRUEBAS, USO Y
MANTENIMIENTO
Son 5 las Fases que se utilizan en la implantación de
Software de Aplicación.
Ofrecer Capacitación a los Usuarios,
Administradores y Técnicos
Realizar la Conversión de Datos y el Cambio de
Sistema
Efectuar una Evaluación luego de la Instalación del
Sistema
 IMPLEMENTACION
 Una vez que sabemos qué funciones debe desempeñar nuestro sistema de información (análisis)
y hemos decidido cómo vamos a organizar sus distintos componentes (diseño), es el momento
de pasar a la etapa de implementación, pero nunca antes. Antes de escribir una sola línea de
código (o de crear una tabla en nuestra base de datos) es fundamental haber comprendido bien el
problema que se pretende resolver y haber aplicado principios básicos de diseño que nos
permitan construir un sistema de información de calidad.
 Para la fase de implementación hemos de seleccionar las herramientas adecuadas, un entorno de
desarrollo que facilite nuestro trabajo y un lenguaje de programación apropiado para el tipo de
sistema que vayamos a construir. La elección de estas herramientas dependerá en gran parte de
las decisiones de diseño que hayamos tomado hasta el momento y del entorno en el que nuestro
sistema deberá funcionar. A la hora de programar, deberemos procurar que nuestro código no
resulte indescifrable. Para que nuestro código sea legible, hemos de evitar estructuras de control
no estructuradas, elegir cuidadosamente los identificadores de nuestras variables, seleccionar
algoritmos y estructuras de datos adecuadas para nuestro problema, mantener la lógica de
nuestra aplicación lo más sencilla posible, comentar adecuadamente el texto de nuestros
programas y, por último, facilitar la interpretación visual de nuestro código mediante el uso de
sangrías y líneas en blanco que separen distintos bloques de código.
 Además de las tareas de programación asociadas a los distintos componentes de nuestro sistema,
en la fase de implementación también hemos de encargarnos de la adquisición de todos los
recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso del sistema
gestor de bases de datos que vayamos a utilizar). Usualmente, también desarrollaremos algunos
casos de prueba que nos permitan ir comprobando el funcionamiento de nuestro sistema
PRUEBAS
 Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que
se hayan podido cometer en las etapas anteriores del proyecto (y, eventualmente,
corregirlos). Lo suyo, además, es hacerlo antes de que el usuario final del sistema
los tenga que sufrir. De hecho, una prueba es un éxito cuando se detecta un error (y
no al revés, como nos gustaría pensar). La búsqueda de errores que se realiza en la
etapa de pruebas puede adaptar distintas formas, en función del contexto y de la
fase del proyecto en la que nos encontremos: - Las pruebas de unidad sirven para
comprobar el correcto funcionamiento de un componente concreto de nuestro
sistema. Es este tipo de pruebas, el "probador" debe buscar situaciones límite que
expongan las limitaciones de la implementación del componente, ya sea tratando
éste como una caja negra ("pruebas de caja negra") o fijándonos en su estructura
interna ("pruebas de caja blanca"). Resulta recomendable que, conforme vamos
añadiéndole nueva funcionalidad a nuestras aplicaciones, vayamos creando nuevos
tests con los medir nuestro progreso y también repitamos los antiguos para
comprobar que lo que antes funcionaba sigue funcionando (test de regresión).
 Pruebas 2
 Las pruebas de integración son las que se realizan cuando vamos juntando los componentes que
conforman nuestro sistema y sirven para detectar errores en sus interfaces. En algunas empresas,
como Microsoft, se hace una compilación diaria utilizando los componentes del sistema tal como
estén en ese momento (daily build) y se somete al sistema a una serie de pruebas básicas (la prueba
de humo, smoke test) que garanticen que el proyecto podrá seguir avanzando al día siguiente. El
causante de que la compilación diaria falle suele tener que quedarse a hacer horas extra para que sus
compañeros puedan seguir trabajando al día siguiente...
 - Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organización encargada del
desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista de un usuario final, pueden
ayudar a pulir aspectos de la interfaz de usuario del sistema
 - Cuando el sistema no es un producto a medida, sino que se venderá como un producto en el
mercado, también se suelen realizar pruebas beta. Estas pruebas las hacen usuarios finales del
sistema ajenos al equipo de desarrollo y pueden resultar vitales para que un producto tenga éxito en
el mercado.
 - En sistemas a medida, se suele realizar un test de aceptación que, si se supera con éxito, marcará
oficialmente el final del proceso de desarrollo y el comienzo de la etapa de mantenimiento.
 - Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer revisiones de todos los
productos generados a lo largo del proyecto, desde el documento de especificación de
requerimientos hasta el código de los distintos módulos de una aplicación. Estas revisiones, de
carácter más o menos formal, ayuden a verificar la corrección del producto revisado y también a
validarlo (comprobar que se ajusta a los requerimientos reales del sistema).
Pruebas
 Aunque es imposible garantizar la ausencia de errores
en el software, una adecuada combinación de distintas
técnicas de prueba puede ayudar más del 90% de los
errores que se encontrarán a lo largo de toda la vida del
sistema. Aunque podamos ser reacios a admitirlo, lo
normal es que el 40% de nuestro tiempo lo "perdamos"
eliminando errores, mientras que sólo empleamos un
20% en la etapa de análisis, otro 20% en el diseño y el
20% restante en la implementación del sistema (Robert
Glass, Building quality software, 1992).
 INSTALACION Y DESPLIEGUE
 Una vez concluidas las etapas de desarrollo de un sistema de información (análisis, diseño,
implementación y pruebas), llega el instante de que poner el sistema en funcionamiento, su
instalación o despliegue.
 De cara a su instalación, hemos de planificar el entorno en el que el sistema debe funcionar,
tanto hardware como software: equipos necesarios y su configuración física, redes de
interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos
(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados
por terceras partes, etcétera. Para asegurar el correcto funcionamiento del sistema, resulta
esencial que tengamos en cuenta las dependencias que pueden existir entre los distintos
componentes del sistema y sus versiones. Una aplicación puede que sólo funcione con una
versión concreta de una biblioteca auxiliar. Un disco duro puede que sólo rinda al nivel
deseado si instalamos un controlador concreto. Componentes que por separado funcionarían
correctamente, combinados causan problemas, por lo que deberemos utilizar sólo
combinaciones conocidas que no presenten problemas de compatibilidad. Si nuestro sistema
reemplaza a un sistema anterior o se despliega paulatinamente en distintas fases, también
hemos de planificar cuidadosamente la transición del sistema antiguo al nuevo de forma que
sus usuarios no sufran una disrupción en el funcionamiento del sistema. En ocasiones, el
sistema se instala físicamente en un entorno duplicado y la transición se hace de forma
instantánea una vez que la nueva configuración funciona correctamente. Cuando el
presupuesto no da para tanto, tal vez haya que buscar un momento de baja utilización del
sistema para realizar la actualización (por la noches o en fin de semana, por ejemplo).
USO Y MANTENIMIENTO
 La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los recursos de
una empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la
etapa más importante del ciclo de vida del software. Dada la naturaleza del software, que ni se
rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes:
 - Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo), lo
primero que a uno se le viene a la cabeza cuando piensa en el mantenimiento de cualquier
cosa.
 - Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de
funcionar sobre una nueva versión del sistema operativo o en un entorno hardware diferente,
por ejemplo.
 - Añadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen
características deseables que supondrían una mejora del sistema ya existente. De las distintas
facetas del mantenimiento, la eliminación de defectos sólo supone el 17% del coste de
mantenimiento de un sistema, mientras que el diseño e implementación de mejoras es
responsable del 60% del coste de mantenimiento. Es decir, más de un tercio del coste total del
software se emplea en añadirle características a software ya existente (el 60% del 60%). La
corrección de errores supone, en contraste, "sólo" en torno al 10% del coste total del software.
Aún menos cuanto mejores sean las técnicas usadas en su desarrollo.