viernes, 18 de julio de 2008

Gestión de la configuración del software.



El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.

La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.

El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.

A medida que progresa el proceso del software, el número de elementos de configuración del software
(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:

Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;
Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;
Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;
Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.

La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.

La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.

Estrategias de prueba de software.



Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.
Las características generales son:
La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
La prueba y la depuración son actividades diferentes.
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
· Planificación de las pruebas.
· Diseño de las pruebas.
· Implementación de las pruebas.
· Ejecución de las pruebas.
· Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
· Plan de Pruebas.
· Casos de Prueba.
· Informe de evaluación de Pruebas.
· Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:
· Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.
· Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.
Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de Elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.
Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:
· La eliminación de casos de prueba obsoletos.
· El refinamiento de algunos casos de prueba en casos de prueba de regresión.
· La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.
La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.
Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.
“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.

Técnicas de prueba de software.



Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.

Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.


Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Principios de las pruebas.

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.
Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.
El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.
Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.
No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.
Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.

Facilidad de prueba.
En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.

Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.

Operatividad. «Cuanto mejor funcione, más eficientemente se puede probar.»
El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
Ningún error bloquea la ejecución de las pruebas.
El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).
Observabilidad. «Lo que ves es lo que pruebas.».
Se genera una salida distinta para cada entrada.
Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
Todos los factores que afectan a los resultados están visibles.
Un resultado incorrecto se identifica fácilmente.
Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
Se informa automáticamente de los errores internos.
El código fuente es accesible.

Controlabilidad. «Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»

Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.
Todo el código es ejecutable a través de alguna combinación de entrada.
El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.
Los formatos de las entradas y los resultados son consistentes y estructurados.
Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

Capacidad de descomposición. «Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »

El sistema software está construido con módulos independientes.
Los módulos del software se pueden probar independientemente

Simplicidad. «Cuanto menos haya que probar, más rápidamente podremos probarlo.»

Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).
Estabilidad. «Cuanto menos cambios, menos interrupciones a las pruebas.»
Los cambios del software son infrecuentes.
Los cambios del software están controlados.
Los cambios del software no invalidan las pruebas existentes.
El software se recupera bien de los fallos.

Facilidad de comprensión. «Cuanta más información tengamos, más inteligentes serán las pruebas.»

El diseño se ha entendido perfectamente.
Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente.
Se han comunicado los cambias del diseño.
La documentación técnica es instantáneamente accesible.
La documentación técnica está bien organizada.
La documentación técnica es específica y detallada.La documentación técnica es exacta.

Garantía de la calidad del software.


Hasta el desarrollador de software más agobiado estará de acuerdo con que el software de alta calidad es una meta importante. Pero, ¿cómo definimos la calidad? Un bromista dijo una vez: «Cualquier programa hace algo bien, lo que puede pasar es que no sea lo que nosotros queremos que haga».

En los libros se han propuesto muchas definiciones, &calidad del software. Por lo que a nosotros respecta, Ib calidad del software se define como: Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición formal de calidad del software. Para los propósitos de este libro, la anterior definición sirve para hacer hincapié en tres puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

El nuevo proceso de Ingeniería de Software.



Es razonable caracterizar las dos primeras décadas de la práctica de ingeniería del software como la era del «pensamiento lineal». Impulsado por el modelo de ciclo vital clásico, la ingeniería del software se ha enfocado como una actividad en la cual se podían aplicar una serie de pasos secuenciales en un esfuerzo por resolver problemas complejos. Sin embargo, los enfoques lineales del desarrollo del software van en contra de la forma en que se construyen realmente la mayoría de los sistemas. En realidad, los sistemas complejos evolucionan de forma iterativa, e incluso incremental. Por esta razón, un gran segmento de la comunidad de la ingeniería del software se está desplazando hacia modelos evolutivos para el desarrollo del software. Los modelos de proceso evolutivos reconocen que la incertidumbre domina la mayoría de los proyectos; que las líneas temporales suelen ser imposibles y cortas; y que la iteración proporciona la habilidad de dar una solución parcial, aunque un producto completo no es posible dentro del marco de tiempo asignado. Los modelos evolutivos hacen hincapié en la necesidad de productos de trabajo incrementales, análisis de riesgos, planificación y revisión de planes, y realimentación que provenga del cliente.

A lo largo de la década pasada, el Modelo de madurez de capacidad desarrollado por el Software Engineering Institute (SEI) ha tenido un impacto apreciable sobre los esfuerzos por mejorar las prácticas de ingeniería del software y sin embargo proporciona una buena indicación de los una buena ingeniería del software.

Las tecnologías de objetos, junto con la ingeniería del software son un brote de la tendencia hacia los modelos de proceso evolutivos. Ambos tendrán un impacto profundo sobre la productividad de desarrollo del software y sobre la calidad del producto. La reutilización de componentes proporciona beneficios inmediatos y convincentes. Cuando la reutilización se une a las herramientas CASE para los prototipos de una aplicación, los incrementos del programa se pueden construir mucho más rápidamente que mediante la utilización de enfoques convencionales. La construcción de prototipos arrastra al cliente al proceso. Por tanto es probable que clientes y usuarios se impliquen más en el desarrollo del software. Esto, a su vez, puede llevar a una satisfacción mayor del usuario final y a una calidad mejor del software global.

El crecimiento rápido de las aplicaciones basadas en Web (WebApps) está cambiando tanto en el proceso de la ingeniería del software como en sus participantes. De nuevo, nos encontramos con un paradigma incremental y evolutivo. Pero en el caso de las WebApps, la inmediatez, seguridad y estética se están convirtiendo en las preocupaciones dominantes. Un equipo de ingeniería de Web mezcla técnicos con especialistas de contenido para construir una fuente de información para una comunidad de usuarios grande e impredecible. El software que ha surgido del trabajo de la ingeniería de Web ya ha dado como resultado un cambio radical tanto económico como cultural.

Inteligencia Artificial.

Se denomina inteligencia artificial a la rama de la informática que desarrolla procesos que imitan a la inteligencia de los seres vivos. La principal aplicación de esta ciencia es la creación de máquinas para la automatización de tareas que requieran un comportamiento inteligente.

Algunos ejemplos se encuentran en el área de
control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.

TECNOLOGÍA DE LA INFORMACIÓN Y PRODUCTIVIDAD



RESUMEN

La Paradoja de la Productividad.

Las organizaciones se constituyen para generar y distribuir un producto o servicio y con ello conseguir un beneficio, ya sea económico o social. Las organizaciones intentan funcionar de la manera más efectiva y eficiente posible. Se considera que una buena medida de la eficiencia de las organizaciones consiste en evaluar su productividad, definida como la relación entre el valor de los productos o servicios que genera y los costes de los recursos consumidos para la generación o prestación de los mismos.

La productividad de una organización es, pues, el cociente entre el output y el input en la misma. En los mismos términos se puede definir la productividad de un sector industrial, así como la productividad a nivel nacional o internacional. En todos los casos, la principal utilidad de las medidas de productividad surge cuando se comparan los datos de distintas empresas, sectores o naciones, más que cuando se analizan los datos de una sola entidad.

Uno de los objetivos permanente de toda organización, sector o nación consiste en aumentar su productividad. Y ello porque la mejora de la productividad es “el único medio válido para poder pagar niveles de vida creciente”.

Tradicionalmente, los medios utilizados para aumentar la productividad han consistido, por un lado, en cambiar los métodos de trabajo, ya sea mediante su reorganización metódica o la incorporación de tecnología, a fin de aumentar el outpu de cada unidad operativa, y, por otro lado, reducir coste, a fin de disminuir el input necesario para la elaboración de los productos o la prestación de los servicios.

El factor realmente indicativo del desarrollo de las organizaciones no es su productividad en sí, sino la tasa anual de crecimiento de la productividad. Y aquí es donde aparece lo que se ha venido en llamar “paradoja de la productividad”: la tasa de crecimiento de la productividad en el conjunto de los países occidentales se ha desacelerado durante las dos últimas décadas, y no ha conseguido igualar las cifras de crecimiento conseguidas tras la Segunda Guerra Mundial, y ello a pesar de que los avances tecnológicos son ahora mayores y más rápidos que nunca.

Lo más sorprendente de la paradoja es que la desaceleración en el crecimiento de la productividad se produce justo cuando la tecnología parece avanzar más, y cuando las inversiones en tecnología por parte de las organizaciones suman cantidades muy relevantes.

En concreto, en lo que se refiere a las tecnologías de la información, durante las tres últimas décadas, y en especial durante los ochenta, se han producido avances en capacidad y prestaciones impresionantes, avances que pueden ser medidos, por ejemplo, en términos de la relación potencia/coste de los equipos informáticos, que no ha dejado de crecer, así, por ejemplo, la unidad de potencia de proceso de un ordenador personal pasó de costar tres mil dólares 1987 a costar menos de setecientos cincuenta 1991, y menos de quinientos en 1992.

Por otra parte, las inversiones en TI ha ido paralela al avance técnico. Así, desde 1982, el 52 % del crecimiento acumulado de bienes de capital en el conjunto de los sectores económicos de los Estados Unidos ha correspondido a inversiones en TI (Ordenadores, Telecomunicaciones, reprografía, instrumentos científicos, equipo ofimático en general.



Razones de la paradoja de la productividad.
Distintos autores y estudios han propuesto un conjunto de posibles razones de la “paradoja de la productividad”, es decir, de la desaceleración del crecimiento de la productividad experimentada en los países occidentales justo en las décadas que el avance tecnológico ha sido más evidente. No existe aún unanimidad en el diagnóstico de las causas de la paradoja, aunque hay un cierto acuerdo en que quizás sea algo pronto para encontrarlas, ya que las TI no se han implantado de una manera suficientemente amplia como para desarrollar todo su potencial de aceleración de la productividad.

La desaceleración de la productividad puede ser, en cierta medida, resultado de un espejismo estadístico, es decir, no se trata de un hecho real sino que se deriva de las dificultades surgidas en la medida estadística de la productividad.

No es que se haya producido una desaceleración de la productividad en los setenta y ochenta, sino que la aceleración fue extraordinariamente alta en los cincuenta y sesenta, a causa de la conjunción de un aserie de factores, como, por ejemplo, la necesidad de reconstrucción de la mayoría de bienes de capital en Europa y Japón tras la Segunda Guerra Mundial.

La razón fundamental de la paradoja de la productividad, en lo que se refiere a las TI, consiste quizá en que su aplicación implica un verdadero cambio de paradigma, el paso de un sistema basado en el uso intensivo de energía aun sistema intensivo en información, y que, como en todo cambio de paradigma, se requiere en un cierto tiempo para que las potencialidades del nuevo paradigma puedan manifestarse.

El nuevo paradigma traído por las TI posibilitara nuevo avances en productividad, pero sólo si las TI se difunden adecuadamente por todo el sistema económico, lo que exige muchos cambios sociales e institucionales… así como un gran aumento de nuevas habilidades de las personas y transformaciones de los bienes existentes.

Las empresas pretenden aumentar su productividad automatizando labores manuales para conseguir actividad ininterrumpida las veinticuatro hora de los sietes días de cada semana del año, pero el ahorro en personal y en duplicación de maquinaria (que contribuye a aumentar la productividad) es superado por los nuevos costes de la automatización, es decir, por el hardware, el software y su correspondiente mantenimiento. Advierte que son otras las verdaderas ventajas de la automatización, como, por ejemplo, la posibilidad de aumentar la calidad disminuyendo al máximo los errores, o de disminuir el tiempo des respuesta tras la recepción de un pedido. La importancia de las TI son pues más de orden estratégico que de orden táctico; la competitividad del producto o servicio prima más que la mera productividad.

El estudio del MIT (Massachusset Institute of Technology) con el objeto de estudiar el impacto de las tecnologías de la información (TI). En este estudio se proponen diversas razones por las que el avance de las TI no se ha traducido en mejoras de las variables tradicionales con las que con las que se mide el éxito de una empresa (Productividad y rentabilidad). Entre las distintas razones propuestas, cabe destacar las siguientes:

· Los beneficios aportados por las tecnologías de la información no son inmediatamente visibles.
· Los beneficios aportados por las tecnologías de la información no son capturables por la empresa.
· El entorno de la empresa se vuelve cada vez más exigente.
· El impacto de las tecnologías de la información es escaso si su aplicación no viene acompañada de cambios en la organización de la empresa.
· La implantación de las tecnologías de la información no ha respondido a las necesidades fundamentales de la empresa.

El estudio MIT señala también cuáles son las características comunes de las empresas que han sabido aprovechar satisfactoriamente el potencial de las tecnologías de la información. Entre ellas, cabe destacar las siguientes:

- Tenían un objetivo empresarial concreto, y una visión clara de lo que debía ser la organización.
- Habían alienado su estrategia de tecnología de la información con la estrategia general de la empresa y con las dimensiones de la organización.
- Tenía una estructura de tecnología de la información capaz y robusta.
- Habían invertido en recursos humanos, a fin de sacar el máximo partido de las tecnologías.
Esta última característica se considera fundamental, hasta el punto de que se concluye que una causa fundamental de la falta de impacto de las tecnologías de la información en la mejora del comportamiento económico de las organizaciones es de la poca disposición de ésta a invertir fuertemente, y suficientemente pronto, en los recursos humanos.

El Futuro de la TI la Productividad.
El panorama descrito hasta el momento en este capítulo puede parecer algo sorprendente y sombrío. Se ha empezado indicando que la productividad se ha desacelerado justo en la época en que el avance de las tecnologías es mayor. Se ha dicho también que esta paradoja es más evidente en el sector servicios, y que la importancia creciente de éste en el conjunto de la economía hace del aumento de la productividad en servicios uno de los mayores condicionantes de la mejora del nivel de vida en las sociedades desarrolladas.
La verdad es que no se dispone aún de un arsenal de datos comparables al existente para la década de los ochenta. Sin embargo, algunos autores anticipan que se están produciendo cambios relevantes en lo que respecta a la justificación de las inversiones en TI. Por un lado, las organizaciones están adaptando sus estructuras con el fin de sacar mayor provecho de su principal activo, las personas.

Ello conlleva en muchos casos una definición del trabajo, de las jerarquías, del estilo de dirección, con una eliminación de procesos y procedimientos innecesarios y con la distribución de información allí donde es necesaria, y no sólo en el nivel directivo como antes.

Por otro lado, se está produciendo un cambio importante en las metodologías de análisis y diseño de sistemas de información. Así, la denominada reingeniería pone en cuestión todos los procedimientos y procesos en los que se han aplicado TI en una empresa y no duda en empezar desde el principio si es necesario. El enfoque está en aplicar las TI para aumentar la efectividad, más que para aplicar la eficiencia necesaria no hace más que aminorar la productividad de la empresa.

Finalmente, las TI empiezan a ofrecer productos con verdadero impacto en la productividad. Y a diferencia de lo que ocurría hasta ahora, el avance se produce en los interfaces gráficos de usuarios, los softwares para la interconexiones en red, que finalmente facilitan el trabajo en grupo, las bases de datos relacionales, que pueden ser compartidas por distintas personas y departamentos de una empresa, o las técnicas de imágenes a través de las redes. Todo ello se caracterizan por su gran facilidad de aprendizaje y de utilización.

De alguna forma, se ha tenido que esperar a que el software avanzara suficientemente para que pueda entreverse un impacto positivo de las TI en la productividad de las empresas.
La realización de cambios en la estructura organizativa de las empresas, la aplicación de nuevas metodologías de desarrollo de sistemas de información, y la incorporación de software más potentes, pueden traducirse en los próximos años en el esperado aumento de la productividad, especialmente en el sector servicios, pueden conllevar la superación de la paradoja de la productividad. Pero para ello será necesario que se produzcan un cambio sustancial en la filosofía de las organizaciones, por el que se pase a concebir las TI como instrumento para manejar mejor el activo información de la empresa en lugar de considerarlas como meros instrumentos de automatización de tareas más o menos rutinarias.