viernes, 25 de julio de 2008

DISEÑO ORIENTADO A LAS ESTRUCTURAS DE DATOS


RESUMEN

Capítulo 8



La íntima relación entre el software y datos puede ser rastreada hasta los orígenes de la computación. La estructura de la información, llamada estructura de datos, se ha demostrado que tiene un importante impacto en la complejidad y eficiencia de los algoritmos diseñados para procesar la información.

Los datos de entrada, internamente información almacenada (es decir, una base de datos), y los datos de salida, pueden tener cada uno una estructura única. El diseño orientado a la estructura de datos hace uso de estas estructuras como base para el desarrollo del software.

Diseño y estructura de los datos.

La estructura de los datos afecta al diseño, tanto en el aspecto estructural, como procedimental del software. Los datos repetitivos se procesan siempre con software que tiene facilidades de control para la repetición; los datos alternativos (es decir, información que puede o no puede estar presente) requieren software con elementos condicionales de procesamiento; una organización jerárquica de los datos frecuentemente tiene una extraordinaria semejanza con la estructura del programa que utiliza los datos.

El diseño orientado a la estructura de datos transforma una representación de la estructura de datos en una representación del software.

La metodología de desarrollo del sistema de Jackson parte de que la “paralelización de la estructura de datos de entrada y salida (informe) asegurará un diseño de calidad”.

La construcción lógica de programas (CLP), desarrollada por J. D. Warnier, da un método riguroso para el diseño del software. Sobre el esquema de relación entre estructura de datos y estructura procedimental, Warnier desarrolla un conjunto de técnicas que realizan una transformación de la estructura de datos de entrada/salida en una representación procedimental detallada del software.

El Desarrollo de Sistemas Estructurada de Datos (DSED), también llamado metodología de Warnier-Orr, es una extensión de CLP y potencia el análisis, así como las capacidades de diseño. El método DSED proporciona una notación y procedimiento para derivar la estructura de datos, estructura del programa y diseño procedimental detallado de los componentes del programa (Módulos). Además, DSED da una notación que facilita al diseñador de examinar el flujo de datos entre las fuentes y sumideros de información y de los procesos que transforman la información.

Una técnica llamada construcción lógica del software es una síntesis representativa de los métodos de diseño orientados a flujo de datos y a la estructuras de datos. Los creadores del método sostienen que “el diseño lógico puede describirse explícitamente si se ve el software con un sistema de conjuntos de datos y transformaciones de datos”.

Áreas de aplicación.

El diseño orientado a la estructura de datos puede aplicarse con éxito a aplicaciones que tengan una estructura jerárquica, bien definida, de la información.

· Aplicaciones en sistemas de información comerciales. La entrada y salida tiene distinta estructura (por ejemplo, archivos de entrada, informes de salida); el uso de una base de datos jerárquico es frecuente.
· Aplicaciones de sistema. La estructura de datos para los sistemas operativos comprenden muchas tablas, archivos y listas que tienen una estructura bien definida.

El diseño orientado a la estructura de datos puede ser adecuado para aplicaciones del dominio de la ingeniería y de la ciencia, enseñanza asistida por computadora, resolución de problemas combinatorios y muchas otras áreas.
En general, el diseño orientado a la estructura de datos es más difícil de aprender y más complicado de aplicar que las técnicas orientadas al flujo de datos. Sin embargo, la escuela de diseño orientado a la estructura de datos ofrece un enfoque más rico y, potencialmente, más poderoso para el diseño de software.

Técnicas de estructuras de datos frente a las de flujo de datos.

El diseño orientado a la estructura de datos no hace un uso explícito de un diagrama de flujo de datos. Por tanto, las clasificaciones de flujo de transformación y de transacción tienen poca relevancia en el método de diseño orientado a la estructura de datos. Lo más importante es que el objetivo último de los métodos orientados a la estructura de datos es producir una descripción procedimental del software. El concepto de estructura modular de programa no se considera explícitamente. Los módulos se consideran un subproducto del procedimiento y a la idea de independencia de módulos se le da poca importancia.

El diseño orientado a la estructura de datos hace uso de un diagrama jerárquico para representar la estructura de la información. Por lo tanto, durante el análisis de requerimiento del software, el énfasis debe colocarse en estos modos de representación.

Consideraciones sobre el proceso de diseño.

Cada método de diseño da un conjunto de “reglas” que facilitan al diseñador la transformación de la estructura de datos en una representación del software.

Cada método orientado a la estructura de datos tiene su propio conjunto de reglas. Sin embargo, deben realizarse siempre las siguientes tareas de diseño:



  1. Evaluar las características de la estructura de datos.


  2. Representar los datos en términos de formas elementales, tales como secuencia, selección y repetición.


  3. Transformar la representación de la estructura de datos en una jerarquía de control para el software.


  4. Refinar la jerarquía de software usando los criterios definidos como parte de un método.


  5. Desarrollar finalmente una descripción procedimental del software.


En los métodos orientados a la estructura de datos no está clara la división entre los pasos de diseño arquitectural y procedimental (se ha descrito como parte del proceso del diseño de software). Warnier y Orr van rápidamente hacia la representación procedimental.

DESARROLLO DEL SISTEMA DE JACKSON

Como la mayoría de las metodologías de diseño de software, el Desarrollo de Sistemas de Jackson (DSJ) es realmente una continuación de los pasos técnicos que soportan el análisis y diseño de software.

Para realizar el Desarrollo de Sistema de Jackson (DSJ) el analista y diseñador han de dar los siguientes pasos:

Paso de las acciones y entidades. Se identifican las entidades (agentes, objetos u organizaciones que un sistema necesita para producir o usar la información) y acciones (los sucesos que ocurren en el mundo real que afectan a las entidades).
Pasos de estructuración de las entidades. Las acciones que afectan a cada entidad se ordenan en el tiempo y se representan mediante los diagramas de Jackson.
Paso de modelación inicial. Las entidades y acciones se representan como un modelo del proceso; se definen las conexiones entre el modelo y el mundo real.
Paso funci0nal. Se especifican las funciones que corresponden a las acciones definidas.
Paso de temporización del sistema. Se establecen y especifican las características de planificación del proceso.
Pacto de implementación. Se especifica el hardware y software como un diseño.

CONSTRUCCIÓN LÓGICA DE PROGRAMAS Y SISTEMAS

La construcción Lógica de Programas y más recientemente la Construcción Lógica de Sistema (referidos colectivamente como CLP) se desarrollaron para definir un conjunto de “reglas” y “leyes” que gobiernen la estructura de la información y la organización resultante del software obtenido.

La Construcción Lógica de Programa (CLP) presenta procedimientos para el análisis y diseño. Comenzando con la representación formal de las estructuras de datos, el método conduce a la derivación de procedimientos y culmina con métodos sistemáticos para la generación de pseudocódigo, verificación y optimización.

El diagrama de Warnier.

La notación para la estructura de datos, usados en la Construcción Lógica de Programa (CLP), es el diagrama de Warnier. Como el diagrama de Jackson, la representación de Warnier de los datos describe jerarquías, así como repetición explicita e información condicional.

Una “regla” establecida por Warnier indica que “cualquier conjunto de información debe subdividirse en subconjuntos. El diagrama Warnier realiza esta subdivisión con la especificación adicional del número de ocurrencia de los elementos de datos.

El método de diseño Construcción Lógica de Programa (CLP).

El método de diseño CLP comienza con la especificación de las estructuras de datos de entrada y salida usando los diagramas de Warnier. Como otros métodos de diseño, una minuciosa evaluación de los requerimientos del software es la precursora de la derivación de una representación del software. Warnier toma la visión clásica de que los “programas, como los datos (entrada) y resultados, son archivos de información.


Organización detallada.

La construcción lógica de programas intenta extender la metodología de diseño a un dominio que los otros métodos evitan. Warnier ha desarrollado una técnica, llamada organización detallada, en la que un conjunto de instrucciones detalladas puede desarrollarse sistemáticamente a partir de la organización lógica del programa. Otros métodos establecen una base para la especificación de instrucciones detalladas, pero Warnier ha propuesto un procedimiento paso a paso para derivar tales instrucciones.

Warnier define los siguientes tipos de instrucciones:

Entrada y preparación de a entrada.
Bifurcación y bifurcación preliminares.
Cálculos.
Llamadas a subprogramas (módulos).
Estructuras complejas.

Conforme la organización lógica de un programa se vuelve más compleja, se requieren técnicas de diseño adicional para representar y finalmente simplificar las condiciones y el correspondiente procesamiento. La construcción lógica de programas (CLP) recomienda el uso del álgebra boolena (en informática y matemática, es una estructura algebraica que vigorizan las operaciones lógicas Y, O y NO, así como el conjunto de operaciones unión, intersección y complemento) y/o diagramas de Karanaugh (sirven principalmente para minimizar expresiones del tipo suma de productos o productos de sumas, obteniendo otra suma d productos o producto de sumas) para ayudar a reducir la complejidad lógica, ayudando así al diseñador en la especificación de la organización detallada.

DESARROLLO DE SISTEMAS ESTRUCTURADOS DE DATOS

El Desarrollo de Sistemas Estructurados de Datos (DSED), extiende los conceptos básicos desarrollados por Warnier a una metodología más comprensiva para el análisis y diseño de sistemas basados en computadoras.

Los diagramas y datos contenidos en estas representaciones, se utilizan como la base de diseño lógico procedimental del software. El diseño físico surge el diseño lógico y se enfoca sobre el “empaquetado” del software, para adquirir mejor el rendimiento deseado, mantenimiento y otras ligaduras de diseño impuestas por el entorno del sistema.

Un método de diseño simplificado.

El proceso de diseño lógico puede dividirse en dos actividades: la derivación de la estructura lógica de la salida (ELS) y la definición resultante de la estructura lógica del proceso Estructura Lógica del Proceso.

En este método los elementos de datos, que son parte de dominio de la información de un problema, se organiza jerárquicamente, de la misma forma que en los métodos de diseño de Jackson y Warnier. Se aplica un proceso de cuatro pasos para derivar la estructura lógica de la salida (ELS):

Se evalúa la declaración del problema o información relativa a los requerimientos, y se listan todos los elementos de datos distintos (llamados átomos), que no pueden ser subdivididos más.
Se especifica la frecuencia de ocurrencia de cada átomo.
Se evalúan los elementos de datos que pueden ser subdivididos (llamados universales).
Se desarrolla una representación diagramática de ELS.

Derivación de la estructura lógica de la salida.

La estructura lógica de salida (ELS) es una representación jerárquica de los elementos de datos que componen la salida de un sistema basado en computadora. El primer paso en la derivación del ELS es aislar todos los átomos (elementos de datos que no pueden ser subdivididos).

Una vez que todos los átomos y su frecuencia han sido definidos, el diseñador comienza un examen de los universales. Los universales son elementos o categorías de datos que están compuestos de otros universales y átomos.

Derivación de la estructura lógica del proceso.



La estructura lógica del proceso (ELP) es una representación procedimental del software requerido para procesar el correspondiente ELS. El método DSED para la derivación de ELP es similar, en muchos aspectos, a la derivación de Warnier de una organización detallada en CLP. Cada elemento de dato universal se convierte en una construcción repetitiva, a la que se añaden las instrucciones de procesamiento. Se siguen los siguientes pasos para derivar el ELP:

Se quitan todos los átomos del diagrama de Warnier-Orr para el ELS.
Se añaden los delimitadores BEGIN y END a todos los universales (repeticiones).
Se definen todas las instrucciones o procesos de inicialización y terminación.
Se especifican todos los cálculos o procesamientos no numéricos.
Se especifican todas las instrucciones y procesor de salida.
Se especifican todas las instrucciones y procesos de entrada.

Se han presentado tres métodos importantes de diseño –Desarrollo de Sistema de Jackson, Construcción Lógica de Programas y Desarrollo de Sistema Estructurado de Datos. Todos son significativamente similares en muchos aspectos, pero cada uno enfoca el proceso de diseño del software desde un punto de vista algo diferente.

Cada uno de los tres métodos de diseño orientado a estructura de datos presentados introduce importantes ideas sobre la naturaleza del buen diseño y especifica métodos para lograrlo. Conforme estos métodos han madurado, su singular enfoque sobre la estructuras de datos se ha ido ensanchando, conforme evolucionó nuestra compresión de lo que “un buen sistema debe parecer”.

viernes, 18 de julio de 2008

Resumen Libro Ingeniería de Softwawre Capítulo 6

LA PRODUCTIVIDAD Y LA EVOLUCIÓN
Uno de los objetivos principales de información de ingeniería es mejorar la productividad en la construcción de aplicaciones de ordenador. Puede ayudar a mejorar la productividad de varias maneras. Dos de los más importantes son el uso de herramientas automatizadas y de su identificación común de datos y procesos a fin de que estos deben ser diseñados por una sola vez en lugar de por separado para múltiples aplicaciones.

Al principio puede haber una preocupación de que IE se ralentiza el desarrollo del sistema, ya que aboga por que detallado modelado de datos y modelado de procesos se realizan antes de diseño comienza.

IE se basa en un marco diseñado por separado que los sistemas de ajuste. Este marco tiene en algún momento de construir, pero una vez que exista, los sistemas se pueden construir rápidamente en el marco.

En la ingeniería de software un problema en relación con el análisis estructurado y el diseño es que requiere un trabajo importante por hacer antes de que comience la codificación. Algunos ejecutores se sienten incómodos acerca de retrasar el código. Tienen una gran necesidad de construir algo, incluso si aún no está diseñado adecuadamente. Es sólo una leve exageración decir que muchos de esos sistema están diseñados de pruebas. Tan poco se sabe sobre los requisitos de sistema que está a menudo después de que se construya que sale a luz la verdad. Abogado del análisis estructurado y del diseño que hace más trabajo en las partes frontales del ciclo vital y menos trabajo en el extremo trasero, especialmente si se utilizan las idiomas de cuarta generación o los generadores de código.
El IE requiere aún más el trabajo antes de la codificación porque el sistema debe caber en las infraestructuras de otros sistemas. Sin embargo, uno los modelos de datos y los modelos de proceso existe en una enciclopedia del IE, diseño individual del systtem y la construcción puede proceder rápidamente si se utilizan las herramientas convenientemente automatizadas.

I.S. Productividad. Muchos estudios se han hecho de los efects de las herramientas de la productividad de I.S., y éstos demuestran mejoras importantes en algunas organizaciones pero mejoras bajas en otra usando las mismas herramientas. Para alcanzar alta productividad, es necesario no sólo seleccionar las mejores herramientas pero también adaptar la organización y métodos de I.S. para aprovechar completo de estas herramientas.
Los procesadores de textos de los abogados dan lugar a menudo a lejos más texto que es creado; el diagramming filetea a menudo resultado en lejos más diagramas que son creados.

Un efecto más valuoso de instrumentos de Caso buenos es el retiro de errores e inconsistencies en la etapa de diseño. Los diseños son de calidad más alta, conduciendo a menos problemas y menos tiempo tomado en el retiro de errores del código.
Los generadores de código permiten a ejecutores producir un programa de trabajo rápidamente. Sin embargo, si el generador no se liga a un diccionario, a un modelo de datos, o a herramientas de diseño, los programas generados pueden ser fragmentos incompatibles, enfermedad diseñada y que no liga juntos. Para alcanzar alta productividad, las herramientas para el diseño necesitan ser juntadas firmemente al generador de código. Las herramientas de diseño deben emplear un modelo de datos y deben permitir al diseño ser representado en un de gran alcance, visual, fácil-a-modifique la forma de las cuales cifran se genera adentro directamente. Los programas deben ser rápidamente ejecutables de modo que el diseñador pueda observar lo que él hace, ajusta o agrega al diseño, vuelve a efectuar los programas, realza el diseño, y así sucesivamente, hasta que se cree un sistema comprensivo. El principio qué usted ve es lo que usted consigue debe aplicarse a la combinación de herramienta de diseño y de generador de código visuales. La necesidad de la codificación manual se debe quitar al máximo.
El generador primero produce el código estructurado que se relaciona con las pantallas del diseño. Este código se puede utilizar para la creación de un prototipo y el depuración. El código estructurado no da perfomance óptimo de la máquina, así pues, para los usos resistentes, el código se puede alimentar en un optimizador que cree código con funcionamiento óptimo de la máquina. Este código nunca será tocado por los programadores de mantenimiento.

La herramienta del generador del diseñador debe facilitar los prototipos que son construidos y modificados rápidamente. Debe generar datos de prueba y proporcionar las herramientas de prueba. Debe generar código de la base de datos y código de control de trabajo, para poder ejecutar rápidamente el programa cuando se realizan los cambios de diseño. Con creación de un prototipo de gran alcance filetea un ciclo vital iterativo del desarrollo se utiliza. El ejecutor diseña algo en la pantalla de una herramienta del I-caso, genera código, ejecuta el código y lo prueba, después se modifica o agrega al diseño, regenera código, y así sucesivamente. Cuanto más rápido es el ciclo de la diseñar-generar-prueba puede ser, más productivo el ejecutor es probable ser. Las herramientas de diseño de gran alcance con los generadores interpretativos son necesarias que hacen este ciclo tan rápido como sea posible.

EL EFECT DE EQUIPOS GRANDES
La productividad del desarrollo de sistema es afectada fuertemente por el número de gente en el equipo de desarrollo de sistema. Los equipos grandes tienden a dar productividad baja del desarrollo. La razón es que el número de interacciones entre los miembros de equipo aumenta rápidamente mientras que el tamaño del equipo aumenta. Si hay gente de N en el equipo, obrando recíprocamente todo, el número de interacciones personales es N (N-1) /2. Cuando obra recíprocamente la gente, hay miscommunication. La tentativa de disminuir el miscommunication documentando las interacciones es desperdiciadora de tiempo y no trabaja a menudo bien. Los efectos de productividad-reducción son aproximadamente proporcionales al cuadrado del número de miembros de equipo que obran recíprocamente.
Estadísticas para la demostración programada convencional mucha una gran cantidad de líneas de código por persona para el equipo muy pequeño que para los equipos grandes. Los proyectos del desarrollo de aplicaciones con muy una gran cantidad de gente son a menudo desastrosos. Los proyectos de una persona exhiben la productividad más alta.
Cuadro 6.2 estadísticas de las demostraciones para la programación de COBOL. El número medio de línea de código por personas-año varía a partir el 800 a 15.000, dependiendo del tamaño del programa. Esto refleja en gran parte el efecto de equipos grandes: 500 la línea programa es escrita por una persona; 500.000 la línea programas es escrita por los equipos grandes.


Diseño y código reutilizables.Los programadores de hoy reinventan constantemente la rueda. Luchan para crear algo que se ha creado las épocas sin fin antes. Los aumentos de la productividad del alcalde resultarán de emplear diseños, modelos de datos, o código reutilizables. Los componentes reutilizables se deben catalogar en una enciclopedia del caso para poderlos ser seleccionados cuando son necesarios y modificarse como sea necesario. Una empresa grande debe emplear el mismo juego de herramientas del Yo-caso en todas las localizaciones en donde se construyen los sistemas para poder utilizar modelos de datos, diseños, y componets comunes del programa por localizaciones múltiples. Las telecomunicaciones tienen acceso a las enciclopedias de la unidad central facilitan la distribución de usos, diseño de documento, procedimientos de contabilidad, y así sucesivamente.
Un objetivo del IE es identificar concordancia en datos y procesos y por lo tanto reducir al mínimo el trabajo de desarrollo redundante de sistema. El modelado de datos hace claro que los mismos tipos de entidad son aplicaciones en usos numerosos.
Dondequiera que se utilicen puede haber ciertas rutinas que serán invocadas, por ejemplo la computación de cualidades derivadas, aplicando cheques de la integridad, o crear datos sumarios. Una corporación puede tener muchas fábricas que al grado grande tengan los mismos tipos de entidad.
Muchos de los procedimientos de proceso de datos pueden ser iguales a partir de una fábrica a otra. Algunos serán enteramente diferentes. La gerencia puede hacer comparaciones. Cuando se hace la descomposición de proceso y los procesos se trazan contra tipos de entidad, la concordancia entre procesos puede ser descubierta.

Westpac, uno del banco más grande del hemisferio meridional, basado en Sydney, utilizó la ingeniería de información a través del banco entero, con la ayuda de su gerencia superior, que reconoció que un mejor uso de la informática era crítico para el crecimiento y el éxito del banco.
Westpac, uno del banco más grande del hemisferio meridional, basado en Sydney, utilizó la ingeniería de información a través del banco entero, con la ayuda de su gerencia superior, que reconoció que un mejor uso de la informática era crítico para el crecimiento y el éxito del banco.
Esta reducción del 22:1 en el código generado ahorró mucha hora de desarrollo y es probable reducir el esfuerzo del mantenimiento grandemente. También ayudó a proporcionar la consistencia de la información y de la información, que es valiosa a la gerencia y buena para los clientes. Pongo en contraste esto con el banco que utilizo, que me dice que es imposible computar la vuelta en activos neta porque las computadoras no pueden manejarla. El diseño y el código reutilizables deben ser un objetivo importante del desarrollo de proceso de datos porque pueden reducir dramáticamente esfuerzo del desarrollo y del mantenimiento.
Cuando un generador de código puede generar código directamente forme una representación del diseño que el foco de la reutilidad es la etapa de diseño. Los módulos del diseño pueden ser almacenados en la enciclopedia y ser utilizados cuando están necesitados. El banco de trabajo del diseño hace diseños fáciles modificarse.
El poder hacer ajustes a los diseños, y agregar a ellos según lo necesitado, amplía grandemente el sentido práctico del diseño reutilizable.
Los estándares para el diseño del uso también amplían el sentido práctico del diseño reutilizable. Éstos incluyen los estándares establecidos en la organización de I.S. para el acceso a las redes, acceso a las bases de datos, formatos de documento estándar, diálogos estándar del usuario, IMB' s SAA (arquitectura del uso de sistemas), y así sucesivamente. De uso común de tal estándar a través de una organización de I.S compara a los aumentos en productividad de I.S.
La cuadro 6.1 resume las medidas para maximizar productividad.
- Utilice las herramientas de diseño de gran alcance automatizadas.
- utilice las herramientas de diseño que cogen todos los errores posibles y cogen todas las inconsistencias en el diseño.
- utilice el generador de código integrado con el diseño (las herramientas de un I-caso).
- utilice las herramientas que hacen el ciclo de diseño, generan, prueban, modifican, generan, prueban tan rapid como sea posible.
- Utilice las herramientas de diseño en línea a una enciclopedia comprensiva del IE.
- Diseño dentro de un marco preexistente del plan del IE, de los modelos de datos, y de los modelos de proceso.
- Utilice los modelos de datos correctamente normalizados.
- Genere tanto del diseño de los modelos comerciales y de la regla de negocio como posible.
- Utilice la creación de un prototipo de alta velocidad dentro del marco del IE.
- Genere el documetation automáticamente.

Crecimiento evolutivo de sistemas.
El más impresionantes de sistemas complejos no se crean con un solos diseño y puesta en práctica. Se desarrollan, siendo mejorado en muchos pasos en las diversas horas y lugares.
Un diseñador de sistema mira los trabajos de la naturaleza con temor. Un guepardo que mira para la presa en el amanecer suddnely compite con friega a través en 70 kilómetros por hora con tolerancia asombrosa para matar un antílope del salto. Un colibrí, que dirigen probado una vez era una imposibilidad aerodinámica, revolotea de la flor a la flor y emigra a Suramérica.
El cerebro humano, por completo o los esquemas diabólicos y la poesía maravillosa, ha probado mucho más alla de nuestras técnicas más ambiciosas de la inteligencia artificial. Éstos no son el sistema para el cual Dios escribió especificaciones; son el sistema que se desarrolló sobre millones de años.
El futuro traerá software impresionante y sistemas informáticos corporativos, y éstos también serán crecidos durante muchos años con mucha gente y organizaciones que agregan a ellas. Es difícil o imposible crecer el software que es un lío.
Para alcanzar la evolución de largo plazo del software, necesitamos modelos estructurados de los modelos de los datos y de estructura de procesos. Los diseños demasiados complejos para que una persona sepa todo el detalle se deben representar en una manera ordenada en una enciclopedia de modo que mucha gente en muchos lugares pueda agregar al diseño.El diseño necesita estándares y los componentes y la arquitectura reutilizables que facilita la adición incremental de nuevas funciones. De modo que los ejecutivos puedan controlar el comportamiento de las computadoras que ponen automáticamente órdenes, seleccionan a surtidores, hacen comercios, y así sucesivamente, el comportamiento debe ser expresable en las reglas y los diagramas que los ejecutivos entienden.

ISO 9003

ISO 9003: Sistemas de Calidad - Modelos para Aseguramiento de la Calidad en la Inspección Final y Pruebas. Este es el modelo contractual para los sistemas de calidad que no incluye diseño o producción. ISO 9003 contiene cerca de la mitad de requerimientos de ISO 9001 y modifica algunos requerimientos para adecuarse a la inspección y la aplicación de prueba final. ISO 9003 requiere el desarrollo de un manual de calidad y procedimientos documentados que definan la organización y operación del sistema de calidad. Es responsabilidad de una compañía crear y mantener estos documentos, de modo tal que sean relevantes y apropiados a la operación específica del negocio.

Fundamento de análisis de requisitos.



La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas.

El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.

Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente; (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.

Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables?

Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.

Ingeniería de sistema de computadora.


HACE casi 500 años, Maquiavelo dijo: “no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas”. Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad. La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información. El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.

La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como:

1. un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico; 2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. Un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...

Se proporcionan cinco definiciones más en el diccionario, pero no se sugiere un sinónimo preciso. Sistema es una palabra especial. Tomando prestada la definición del diccionario Webster, definimos un sistema basado en computadora como:

Un conjunto o disposición de elementos que están organizados para realizar un objetivo preteñido procesando información. El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:

Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.

Personas. Usuarios y operadores del hardware y software.

Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.

Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.
Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica. Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas. Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema aún más grande. El macroelemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio. Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.

Análisis de requisitos del sistema del software.



El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.

La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.

Inicio del proceso
La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes): los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito.
Técnicas para facilitar las especificaciones de una aplicación.
Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo.

Diseño de interfaz del Usuario.



El plano de una casa (su diseño arquitectónico) no está completo sin la representación de puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. Puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora.

Diseño de interfaz del usuario.



El diseño de interfaz de usuario o ingeniería de la interfaz es el diseño de
computadoras, aplicaciones, máquinas, dispositivos de comunicación móvil, aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la interacción.
Normalmente es una actividad multidisciplinar que involucra a varias ramas del diseño y el conocimiento como el
diseño gráfico, industrial, web, de software y la ergonomía; y está implicado en un amplio rango de proyectos, desde sistemas para computadoras, vehículos hasta aviones comerciales.

Su objetivo es que las aplicaciones o los objetos sean más atractivos y además, hacer que la interacción con el usuario sea lo más intuitiva posible, conocido como el diseño centrado en el usuario. En este sentido las disciplinas del diseño industrial y gráfico se encargan de que la actividad a desarrollar se comunique y aprenda lo más rápidamente, a través de recursos como la gráfica, los pictogramas, los estereotipos y la simbología, todo sin afectar el funcionamiento técnico eficiente.

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.

Bloques que componen un CASE



La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o tan compleja como todo un entorno que abarque «herramientas», una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros mil componentes más. Cada bloque de construcción forma el fundamento del siguiente, estando las herramientas situadas en la parte superior del montón. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos para la ingeniería del software se construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un software de sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería del software.

Las arquitecturas del entorno, que constan de una plataforma hardware y de un soporte de sistema operativo (incluyendo software de red, gestión de la base de datos y servicios de gestión de objetos), establece los cimientos para un entorno CASE. Pero el entorno CASE en sí requiere otros bloques de construcción. Existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE, su marco de integración y la arquitectura del entorno. El marco de integración es un grupo de programas especializados que permiten a cada una de las herramientas comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo significativo.

Los bloques de representan un fundamento completo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construidas empleando todos los bloques de construcción anteriormente descritos. De hecho, algunas herramientas siguen siendo las «soluciones puntuales». Esto es, una herramienta se utiliza para prestar apoyo en una actividad de ingeniería del software concreta (por ejemplo, modelado de análisis), pero esta herramienta no se comunica directamente con otras, no está unida a una base de datos del proyecto, y no forma parte de un entorno integrado CASE (1-CASE). Aunque esta situación no es la ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque se trate de una solicitud puntual.

Ingeniería del software asistida por computadora.



Ingeniería asistida por computadora o por ordenador (CAE, del inglés Computer Aided Engineering) es el conjunto de programas informáticos que permiten analizar y simular los diseños de ingeniería realizados con el ordenador, o creados de otro modo e introducidos en el ordenador, para valorar sus características, propiedades, viabilidad y rentabilidad. Su finalidad es optimizar su desarrollo y consecuentes costos de fabricación y reducir al máximo las pruebas para la obtención del producto deseado.


La mayoría de ellas se presentan como módulos o extensiones de aplicaciones CAD, que incorporan:

  • Análisis cinemático.
  • Análisis por el método de elementos finitos (FEM, Finite Elements Method).
  • Maquinado por control numérico CNC (Computered Numeric Control).
  • De exportación de ficheros "Stl" (Estereolitografía) para máquinas de prototipado rápido.

RESUMEN DE LECTURA: LA QUINTA DISCIPLINA

Capitulo 13

APERTURA

¿Cómo superar el Politiqueo interno que predomina en las Organizaciones tradicionales?
El politiqueo es una perversión de la verdad y la honestidad, tan profunda que la mayoría de las organizaciones apestan con su hedor. Pero la mayoría de nosotros la damos tan por sentada que ni si quiera reparamos en ella.

Un “ámbito político” es aquel donde el “quién” es más importante que el “qué”. Si el jefe propone una idea, la idea se toma en serio. Si otra persona propone una idea, se la ignora. Siempre hay “ganadores” y “perdedores”. Gente que acumula poder y gente que pierde poder.
Una persona puede determinar el destino de otra, y no hay apelación posible. El manejo del poder arbitrario sobre los demás es la esencia del autoritarismo, y en este sentido un ámbito político es un ámbito autoritario, aunque quienes posean el poder no ocupen las posiciones oficiales de autoridad.

La construcción de una visión compartida es el primer paso para desafiar las maniobras de política interna. Pero podemos comenzar a construir un clima dominado por el “mérito” y no por el politiqueo, donde hacer lo correcto predomine sobre quién quiere hacerlo, pero un clima no político también exige “apertura”, que es la norma de hablar sin rodeos sobre cuestiones de importancia, también es la aptitud para cuestionar continuamente el propio pensamiento. La primera se puede denominar apertura participativa, y la segunda apertura reflexiva. Sin apertura es imposible desbaratar el politiqueo de la mayoría de las organizaciones. La visión y apertura constituyen los antídotos contra las maniobras políticas internas.

VISIÓN COMPARTIDA: CÓMO CONSTRUIR UN ÁMBITO DONDE NO PREDOMINE EL INTERÉS PERSONAL.

Cuando la organización alienta las visiones compartidas, sacan a la luz este compromiso trascendente. La construcción de una visión compartida induce a la gente a reconocer sus sueños ajenos. Cuando se maneja con sensibilidad y perseverancia, la construcción de visión compartida comienza por establecer una confianza que se genera naturalmente cuando revelamos y compartimos nuestras aspiraciones más profundas. El comienzo consiste simplemente en sentar a las personas en círculos pequeños para pedirles que hablen de lo que realmente les importa.
Cuando la gente comienza a describir y a escuchar visiones, el cimiento del politiqueo comienza a derrumbarse, junto con la creencia de que sólo nos mueven intereses egoístas las organizaciones que no alientan visones genuinamente compartida, o imponen visiones unilaterales y fingen que son compartidas no logran explotar este compromiso. Aunque declamen contra la politiquería interna, no hacen nada para crear un ámbito neutral.

Podemos creer que las maniobras políticas desaparecen una vez que una visión compartida cobra arraigo, divididas por el compromiso que genera la visión.
La organización no cambia de inmediato porque algunas personas comiencen a construir una visión compartida. Si una visión se introduce en un ámbito muy politizado, degenera fácilmente en objetivo político: “¿Quién concibió esta visión, a fin de cuentas?” Esta pregunta cobra mayor relevancia que el mérito intrínseco de una visión. Se necesita apertura para desaprender los hábitos de la politiquería interna.
Pero la apertura es un concepto complejo y sutil que se puede entender sólo a la luz de las disciplinas del trabajo con modelos mentales y el aprendizaje en equipo.

Apertura Participativa Y Apertura Reflexiva.
La apertura participativa, la libertad de expresar nuestra opinión es el aspecto más aceptado de la apertura. Ello se debe a que la filosofía del “management” participativo, que permite mayor participación en las dediciones, goza de amplia difusión.
En algunas organizaciones es casi una religión: se transforma en compañías de “management” participativo. Yo expreso mi opinión. Tú expresas tu opinión. Aparentemente todos contribuimos al aprendizaje colaborativo, Y sin embargo hay poco aprendizaje.
La apertura participativa puede inducir mayor “adhesión” ante ciertas decisiones, pero rara vez conduce a mejores decisiones porque no influye sobre el pensamiento de la gente. En términos de dominio personal se concentra en los “medios” o procesos de interacción, no en los “resultados” de esa interacción. Por ejemplo, la gente dice: “Fue una magnifica reunión. Todos pudieron expresar su punto de vista”. Pero nadie juzga la calidad de las decisiones y acciones efectuadas a lo largo del tiempo. Por eso muchos managers recelan del management participativo.
“La apertura participativa” induce a la gente a hablar, “la apertura reflexiva” induce a la gente a examinarse. La apertura reflexiva comienza con la voluntad de cuestionar nuestro propio pensamiento, de reconocer que toda certidumbre es a lo sumo una hipótesis acerca del mundo. Por muy convincente que sea, por muco afecto que le profesemos, “nuestra idea” siempre está sometida a la verificación y el perfeccionamiento. La apertura reflexiva vive en la actitud: “quizá yo esté equivocado y la otra persona esté en lo cierto”. No se trata sólo de analizar nuestras ideas, sino de un examen mutuo de nuestro pensamiento.
Las organizaciones que toman la apertura en serio procuran que sus integrantes desarrollen estas aptitudes para el aprendizaje. Pero se requiere tiempo y perseverancia para desarrollarlas, y la mayoría de los managers no han oído hablar de ellas. La apertura reflexiva: indaga, reflexiona, dialoga. Se basa en aptitudes y no sólo en buenas intenciones.

Apertura y Complejidad.
La certidumbre es el mayor obstáculo para la apertura. Una vez que creemos tener “la respuesta”, perdemos toda motivación para cuestionar nuestro pensamiento. Pero la “disciplina de pensamiento sistémico muestra que no hay “respuesta correcta” cunado se aborda la complejidad. Por esta razón, la apertura y el pensamiento están estrechamente relacionados.
Podemos afirmar nuestra capacidad racional para resolver problemas, y usar esa capacidad del mejor modo posible, aun reconocimiento que nunca será suficiente. Luego la curiosidad, antes sepultada bajo la creencia de que “conocemos las respuesta” es libre de aflorar. Se disuelve el temor a “Yo no sé, pero quizás otra persona sí” o “No sé pero debería saber”. No nos molesta saber que no sabemos. Como dijo Einstein “Lo más bello que podemos experimentar es lo misterioso. Es la fuente de todo arte y ciencia verdaderos”.

El espíritu de apertura.
La apertura es algo más que un conjunto de aptitudes. La apertura trasciende la calida personal. Es una relación que se tiene con los demás. Es un cambio de espíritu, así como un conjunto de práctica y aptitudes.

Conviene pensar en la apertura como una característica de las relaciones, no de los individuos. En cierto nivel, no tiene sentido decir: “Soy una persona abierta”. La misma persona experimenta genuina apertura con algunas personas y no con las otras.
La apertura emerge cuando dos o más individuos están dispuestos a suspender la certidumbre en presencia de otro. Están dispuestos a compartir los pensamientos y a dejarse influir por el otro.

El impulso hacia la apertura es “el espíritu del amor”, no se refiere al amor romántico. El tipo de amor que subyace a la apertura lo que los griegos llaman ágape tiene poco que ver con las emociones. En cambo, tiene mucho que ver con las intensiones: el compromiso del servicio mutuo, la voluntad de ser vulnerable en el contexto de ese servicio.
La mejor definición del amor relacionado con la apertura es el compromiso pleno e incondicional con la realización de otro, para que ese otro pueda ser todo lo que puede y desea ser.

La Libertad.
Cuando decimos “Soy libre de hacer lo que quiero”, queremos decir: “Tengo libertad de acción. Nadie me dice qué hacer: nadie me impide actuar a mi antojo.
Pero la “libertad”, en el sentido de estar libre de restricciones externas, puede ser un trofeo hueco.

La gente cree que es libe en ausencia de controles externos, pero sin embargo es prisionera de una forma de dominación más profunda e insidiosa, tiene una sola manera de mirar el mundo.
La “libertad para” (en contraste con la libertad respecto de”) es la libertad para crear los resultados que de veras deseamos. Es la libertad que buscan las personas que procuran el dominio personal. Es el corazón de la organización inteligente, porque el impulso hacia el aprendizaje generativo es el deseo de crear algo nuevo, algo que tenga valor y significado para la gente.

Capítulo 14

LOCALISMO
¿Cómo se controla sin controlar?
El localismo significa en este contexto, que las decisiones descienden por l jerarquía el diseño de unidades donde, en mayor medida posible, los directivos locales afrontan los problemas y dilemas propios del crecimiento y sostén de una empresa. Localismo significa liberar el compromiso, dando a la gente libertad de actuar, poner a prueba sus propias ideas y ser responsable de los resultados.
En la organización jerárquica tradicional, la cima piensa y el directivo local actúa. En una organización inteligente, hay que fusionar el pensamiento y la acción en cada individuo.

La ilusión de ejercer el control.
Al pasar de la organización tradicional, autoritaria y jerárquica a una organización manejada localmente, el mayor problema es el control. Más allá del dinero y de la fama, el principal impulso de la mayoría de los ejecutivos tradicionales es el poder, el deseo de ejercer el control. La mayoría desistirá de cualquier cosa menos del control.
Cuando los negocios andan bien, las decisiones se localizan cada vez más. Cuando los negocios flaquean, el instinto aconseja devolver el control a la administración central.
La comprensión de que es casi imposible controlar una organización compleja desde arriba puede ayudar a los directivos a desistir de la necesidad de ejercer el control.

Control sin control.
El hecho de que nadie ejerza el control no significa que no haya control. Todos los organismos saludables tienen procesos de control. Sin embargo, son procesos distribuido, no concentrados en una cabeza autoritaria.

Tolerancia.
Para ser efectivo, el localismo debe alentar a los managers locales a correr riesgos. Pero ello implica tolerancia, capacidad para perdonar. El perdón auténtico incluye el perdón y el olvido.
Si usted comete errores, eso significa que toma decisiones y corre riesgos. Y no creceremos a menos que usted corra riesgos.
Las organizaciones inteligentes practica el perdón porque “cometer el error ya es suficiente castigo”.