Ingeniería de software: Un enfoque práctico.

1. El software se desarrolla, no se fabrica en un sentido clásico.

El software no se «estropea»pero se deteriora.

Las siguientes áreas del software indican la amplitud de las aplicaciones potenciales:

Software de sistemas. El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (por ejemplo: compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo: ciertos componentes del sistema operativo, utilidades de manejo de periféricos, procesadores de telecomunicaciones) procesan datos en gran medida indeterminados. En cualquier caso, el área del software de sistemas se caracteriza por una fuerte interacción con el hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una compartición de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejas y múltiples interfaces externas.

Software de tiempo real. El software que coordina/ analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de controVsalida que responda al entorno externo, y un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la repuesta en tiempo real (típicamente en el rango de un milisegundo a un segundo).

Software de gestión. El proceso de la información comercial constituye la mayor de las áreas de aplicación del software. Los «sistemas» discretos (por ejemplo: nóminas, cuentas de haberes-débi.tos, inventarios, etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG) que accede a una o más bases de datos que contienen información comercial.

Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamientos de datos, las aplicaciones de software de gestión también realizan cálculo interactivo (por ejemplo: el procesamiento de transacciones en puntos de ventas).

Software de ingeniería y científíco. El software de ingeniería y científico está caracterizado por los algoritmos de «manejo de números». Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de ingeniería/ ciencia se han alejado de los algoritmos convencionales numéricos. El diseño asistido por computadora (del inglés CAD), la simulación de sistemas y otras aplicaciones interactivas, han comenzado a coger características del software de tiempo real e incluso del software de sistemas.

Software empotrado. Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un horno de microondas) o suministrar una función significativa y con capacidad de control (por ejemplo: funciones digitales en un automóvil, tales como control de la gasolina, indicadores en el salpicadero, sistemas de frenado, etc.).

Software de computadoras personales. El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

Software basado en Web. Las páginas Web buscadas por un explorador son software que incorpora instrucciones ejecutables (por ejemplo, CGI, HTML, Perl, o Java), y datos (por ejemplo, hipertexto y una variedad de formatos de audio y visuales). En esencia, la red viene a ser una gran computadora que proporciona un recurso software casi ilimitado que puede ser accedido por cualquiera con un modem.

Software de inteligencia artificial. El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes neuronales artificiales, prueba de teoremas, y los juegos son representativos de las aplicaciones de esta categoría.

[La ingeniería del software] es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

El fundamento de la ingeniería del software es la capa de proceso. El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de Úreas clave de proceso (ACPs) [PAU93] que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software. Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto. Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente.

Lafase de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto.

La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero («arialista») del software debe comprender el dominio de información del software,así como la función requerida, comportamiento, rendimiento e interconexión.

Diseño. El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseño traduce requisitos en una representación del software donde se pueda evaluar su calidad antes de que comience la codificación.

Generación de código. El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.

Pruebas. Una vez que se ha generado el código, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos.

Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al cliente (una excepción posible es el software empotrado). Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado en la ingeniería del software.

El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

El modelo DRA es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.

Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional » dentro de períodos cortos de tiempo (por ejemplo: de 60 a 90 días) [MAR91]. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases [KER94]:

Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?

Modelado de datos. El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para

implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.

Generación de aplicaciones. El DRA asume la utilización de técnicas de cuarta generación.

En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construcción del software.

El modelo incremental entrega el software en partes pequeños, pero utilizables, llamadas ((incrementos). En general, cado incremento se construye sobre aquél que ya ha sido entregado.

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto.

Pero no todos los equipos cuajan. De hecho, muchos equipos sufren lo que Jackman llama «toxicidad de equipo » [JAC98] define cinco factores que «fomentan un entorno de equipo tóxico potencial»:

Una atmósfera de trabajo frenética en la que los miembros del equipo gastan energía y se descentran de los objetivos del trabajo a desarrollar; alta frustración causada por factores tecnológicos, del negocio, o personales que provocan fricción entre los miembros del equipo; «procedimientos coordinados pobremente o fragmentados » o una definición pobre o impropiamente elegida del modelo de procesos que se convierte en un obstáculo a saltar; definición confusa de los papeles a desempeñar produciendo una falta de responsabilidad y la acusación correspondiente, y «continua y repetida exposición al fallo» que conduce a una pérdida de confianza y a una caída de la moral.

El elemento fundamental en todos los proyectos de software es el personal. Los ingenieros del software pueden organizarse en diferentes organigramas de equipo que van desde las jerarquías de control tradicionales a los equipos de «paradigma abierto». Se pueden aplicar varias técnicas de coordinación y comunicación para apoyar el trabajo del equipo. En general, las revisiones formales y las comunicaciones informales persona a persona son las más valiosas para los profesionales.

La actividad de gestión del proyecto comprende medición y métricas, estimación, análisis de riesgos, planificación del programa, seguimiento y control.

La medición del software permite que gestores y desarrolladores mejoren el proceso del software, ayuden en la planificación, seguimiento y control de un proyecto de software, y evalúen la calidad del producto (software) que se produce. Las medidas de los atributos específicos del proceso, del proyecto y del producto se utilizan para calcular las métricas del software.Estas métricas se pueden analizar para proporcionar indicadores que guían acciones de gestión y técnicas.Las métricas del proceso permiten que una organización tome una visión estratégica proporcionando mayor profundidad de la efectividad de un proceso de software. Las métricas del proyecto son tácticas.Estas permiten que un gestor de proyectos adapte el enfoque a flujos de trabajo del proyecto y a proyectos técnicos en tiempo real.Las métricas orientadas tanto al tamaño como a la función se utilizan en toda la industria. Las métricas orientadas al tamaño hacen uso de la línea de código como factor de normalización para otras medidas, como persona-mes o defectos. El punto de función proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.

Las métricas de la calidad del software, como métricas de productividad, se centran en el proceso, en el proyecto y en el producto. Desarrollando y analizando una línea base de métricas de calidad, una organización puede actuar con objeto de corregir esas áreas de proceso del software que son la causa de los defectos del software.Las métricas tienen significado solo si han sido examinadas para una validez estadística. El gráfico de control es un método sencillo para realizar esto y al mismo tiempo examinar la variación y la localización de los resultados de las métricas.La medición produce cambios culturales. La recopilación de datos, el cálculo de métricas y la evaluación de métricas son los tres pasos que deben implementarse al comenzar un programa de métricas. En general, un enfoque orientado a los objetivos ayuda a una organización a centrarse en las métricas adecuadas para su negocio. Los ingenieros del software y sus gestores pueden obtener una visión más profunda del trabajo que realizan y del producto que elaboran creando una línea base de métricas -una base de datos que contenga mediciones del proceso y del producto.

El planificador del proyecto de software tiene que estimar tres cosas antes de que comience el proyecto: cuánto durará, cuánto esfuerzo requerirá y cuánta gente estará implicada. Además, el planificador debe predecir los recursos (de hardware y de software) que va a requerir,y el riesgo implicado.El enunciado del ámbito ayuda a desarrollar estimaciones mediante una o varias de las técnicas siguientes: descomposición, modelos empíricos y herramientas automáticas. Las técnicas de descomposición requieren un esbozo de las principales funciones del software, seguido de estimaciones (1) del número de LDC's, (2) de los valores seleccionados dentro del dominio de la información, (3) del número de personas-mes requeridas para implementar cada función, o (4) del

número de personas-mes requeridas para cada actividad de ingeniería del software. Las técnicas empíricas usan expresiones empíricamente obtenidas para el esfuerzo y para el tiempo, con las que se predicen esas magnitudes del proyecto. Las herramientas automáticas implementan un determinado modelo empírico.Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y de técnicas sistemáticas puedan mejorar la precisión de la estimación.

Cuando se pone mucho en juego en un proyecto de software el sentido común nos aconseja realizar un análisis de riesgo. Y sin embargo, la mayoría de los jefes de proyecto lo hacen informal y superficialmente, si es que lo hacen. El tiempo invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones: menos trastornos durante el proyecto, una mayor habilidadde seguir y controlar el proyecto y la confianza que da planificar los problemas antes de que ocurran.El análisis de riesgos puede absorber una cantidad significativa del esfuerzo de planificación del proyecto.Pero el esfuerzo merece la pena. Por citar a Sun Tzu, un general chino que vivió hace 2.500 años, G Si conoces al enemigo y te conoces a ti mismo, no tendrás que temer el resultado de cien batallas». Para el jefe de proyectos de software, el enemigo es el riesgo.

La garantía de calidad del software es una «actividad de protección» que se aplica a cada paso del proceso del software. La SQA comprende procedimientos para la aplicación efectiva de métodos y herramientas, revisiones técnicas formales, técnicas y estrategias de prueba, dispositivos poku-yoke, procedimientos de control de cambios, procedimientos de garantía de ajuste a los estándares y mecanismos de medida e información.La SQA es complicada por la compleja naturaleza de la calidad del software -un atributo de los programas de computadora que se define como «concordancia con los requisitos definidos explícita e implícitamente»-.Cuando se considera de forma más general, la calidad del software engloba muchos factores de proceso y de producto diferentes con sus métricas asociadas.

Las revisiones del software son una de las actividades más importantes de la SQA. Las revisiones sirven como filtros durante todas las actividades de ingeniería del software, eliminando defectos mientras que no son relativamente costosos de encontrar y corregir. La revisión técnica formal es una revisión específica que se ha mostrado extremadamente efectiva en el descubrimiento de errores.

Para llevar a cabo adecuadamente una garantía de calidad del software, se deben recopilar, evaluar y distribuir todos los datos relacionados con el proceso de ingeniería del software. La SQA estadística ayuda a mejorar la calidad del producto y la del proceso de software.Los modelos de fiabilidad del software amplían las medidas, permitiendo extrapolar los datos recogidos sobre los defectos, a predicciones de tasas de fallo y de fiabilidad.

Resumiendo, recordemos las palabras de Dunn y U11-man [DUN82]: «La garantía de calidad del software es la guía de los preceptos de gestión y de las disciplinas de diseño de la garantía de calidad para el espacio tecnológico y la aplicación de la ingeniería del software.))

La capacidad para garantizar la calidad es la medida de madurez de la disciplina de ingeniería. Cuando se sigue de forma adecuada esa guía anteriormente mencionada, lo que se obtiene es la madurez de la ingeniería del software.

La gestión de configuración del software es una actividad de protección que se aplica a lo largo de todo el proceso del software. La GCS identifica, controla, audita e informa de las modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido distribuido a los clientes. Cualquier información producida como parte de la ingeniería del software se convierte en parte de una configuración del software. La configuración se organiza de tal forma que sea posible un control organizado de los cambios.La configuración del software está compuesta por un conjunto de objetos interrelacionados, también denominados elementos de configuración del software, que se producen como resultado de alguna actividad de ingeniería del software. Además de los documentos, los programas y los datos, también se puede poner bajo control de configuración el entorno de desarrollo utilizado para crear el software.Una vez que se ha desarrollado y revisado un objeto de configuración, se convierte en una línea base. Los cambios sobre un objeto de línea base conducen a la creación de una nueva versión del objeto. La evolución de un programa se puede seguir examinando el historial de las revisiones de todos los objetos de su configuración.Los objetos básicos y los compuestos forman un asociación de objetos que refleja las variantes y las versiones creadas. El control de versiones es un conjunto de procedimientos y herramientas que se usan para gestionar el uso de los objetos.El control de cambios es una actividad procedimental que asegura la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuración.

El proceso de control de cambios comienza con una petición de cambio, lleva a una decisión de proseguir o no con el cambio y culmina con una actualización controlada del ECS que se ha de cambiar.La auditoría de configuración es una actividad de SQA que ayuda a asegurar que se mantiene la calidad durante la realización de los cambios. Los informes de estado proporcionan información sobre cada cambio a aquellos que tienen que estar informados.

Un sistema de alta tecnología comprende varios componentes: hardware, software, personas, bases de datos, documentación y procedimientos. La ingeniería de sistemas ayuda a traducir las necesidades del cliente en un modelo de sistema que utiliza uno o más de estos componentes.La ingeniería de sistemas comienza tomando una «visión global». Se analiza el dominio de negocio o producto para establecer todos los requisitos básicos.El enfoque se estrecha entonces a una «visión de dominio», donde cada uno de los elementos del sistema se analiza individualmente. Cada elemento es asignado a uno o más componentes de ingeniería que son estudiados por la disciplina de ingeniería correspondiente.La ingeniería de procesos de negocio es un enfoque de la ingeniería de sistemas que se usa para definir arquitecturas que permitan a un negocio utilizar la información eficazmente. La intención de la ingeniería de procesos de negocio es crear minuciosas arquitecturas de datos, una arquitectura de aplicación y una infraestructura tecnológica que satisfaga las necesidades de la estrategia de negocio y los objetivos de cada área de negocio. La ingeniería de procesos de negocio comprende una planificación de la estrategia de la información (PEI), un análisis del área de negocio (AAN) y un análisis específico de aplicación que de hecho forman parte de la ingeniería del software.La ingeniería de productos es un enfoque de la ingeniería de sistemas que empieza con el análisis del sistema.El ingeniero de sistemas identifica las necesidades del cliente, determina la viabilidad económica y técnica, y asigna funciones y rendimientos al software, hardware, personas y bases de datos; los componente claves de la ingeniería.La ingeniería del sistema demanda una intensa comunicación entre el cliente y el ingeniero del sistema.Esto se realiza a través de un conjunto de actividades bajo la denominación de ingeniería de requisitos -identificación, análisis y negociación, especificación, modelización, validación y gestión-.Una vez que los requisitos hayan sido aislados, el modelado del sistema puede ser realizado, y las representaciones de los subsistemas principales pueden ser desarrolladas. La tarea de la ingeniería del sistema finaliza con la elaboración de una Especificación del Sistema -un documento que sirve de base para las tareas de ingeniería que se realizarán posteriormente.

El análisis de requisitos es la primera fase técnica del proceso de ingeniería del software. En este punto se refina la declaración general del ámbito del software en una especificación concreta que se convierte en el fundamento de todas las actividades siguientes de la ingeniería del software.

El análisis debe enfocarse en los dominios de la información, funcional y de comportamiento del problema.Para entender mejor lo que se requiere, se crean modelos, los problemas sufren una partición y se desarrollan representaciones que muestran la esencia de los requisitos y posteriormente los detalles de la implementación.En muchos casos, no es posible especificar completamente un problema en una etapa tan temprana. La creación de prototipos ofrece un enfoque alternativo que produce un modelo ejecutable del software en el que se pueden refinar los requisitos. Se necesitan herramientas especiales para poder realizar adecuadamente la creación de prototipos.Como resultado del análisis, se desarrolla la Especificación de requisitos del software. La revisión es esencial para asegurarse que el cliente y el desarrollador tienen el mismo concepto del sistema. Desgraciadamente, incluso con los mejores métodos, la cuestión es que el problema sigue cambiando.

El análisis estructurado es el método más usado para el modelado de requisitos, utiliza el modelo de datos y el modelo de flujos para crear la base de un adecuado modelo de análisis. Utilizando el diagrama entidad-relación, el ingeniero del software crea una representación de todos los objetos de datos que son importantes para el sistema. Los sistemas de datos y flujo de control son la base de representación de la transformación de datos y control. Al mismo tiempo, estos métodos son usados para crear un modelo funcional del software y proveerse de un mecanismo para dividir funciones. Después, un modelo de comportamiento usando el diagrama de transición de estados y un modelo de contenido de los datos con un diccionario de datos. Las especificaciones de los procesos y del control proporcionan una blaboración adicional de los detalles.La notación original para el análisis estructurado fue desarrollada para aplicaciones de procesamiento de datos convencionales, pero ahora hay ampliaciones que permiten aplicar el método a los sistemas de tiempo real.El análisis estructurado está soportado por una larga lista de herramientas CASE que ayudan en la creación de cada elemento del modelo y también en el mantenimiento de la consistencia y de la corrección.

El diseño es el núcleo técnico de la ingeniería del software.Durante el diseño se desarrollan, revisan y documentan los refinamientos progresivos de la estructura de datos, arquitectura, interfaces y datos procedimentales de los componentes del software. El diseño da como resultado representaciones del software para evaluar la calidad.Durante las cuatro últimas décadas se han propuesto diferentes principios y conceptos fundamentales del diseño del software. Los principios del diseño sirven de guía al ingeniero del software a medida que avanza el proceso de diseño. Los conceptos de diseño proporcionan los criterios básicos para la calidad del diseño.La modularidad (tanto en el programa como en los datos) y el concepto de abstracción permiten que el diseñador simplifique y reutilice los componentes del software.El refinamiento proporciona un mecanismo para representar sucesivas capas de datos funcionales. El programa y la estructura de datos contribuyen a tener una

visión global de la arquitectura del software, mientras que el procedimiento proporciona el detalle necesario para la implementación de los algoritmos. La ocultación de información y la independencia funcional proporcionan la heurística para conseguir una modularidad efectiva.

La arquitectura del software nos proporciona una visión global del sistema a construir. Describe la estructura y la organización de los componentes del software, sus propiedades y las conexiones entre ellos. Los componentes del software incluyen módulos de programas y varias representaciones de datos que son manipulados por el programa. Además, el diseño de datos es una parte integral para la derivación de la arquitectura del software.La arquitectura marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. El diseño de datos traduce los objetos de datos definidos en el modelo de análisis, en estructuras de datos que residen dentro del software. Los atributos que describe el objeto, las relaciones entre los objetos de datos y su uso dentro del programa influyen en la elección de la estructura de datos. A mayor nivel de abstracción, el diseño de datos conducirá a lo que se define como una arquitectura para una base de datos o un almacén de datos.El ingeniero del software cuenta con diferentes estilos y patrones arquitectónicos. Cada estilo describe una categoría de sistema que abarca un conjunto de componentes que realizan una función requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la coordinación y cooperación entre los componentes, las restricciones que definen cómo se integran los componentes para conformar el sistema, y los modelos semánticos que facilitan al diseñador el entendimiento de todas las partes del sistema.Han sido propuestos uno o varios estilos arquitectónicos por sistema, y el método de análisis de compromisos para la arquitectura podría utilizarse para evaluar la eficacia de cada arquitectura propuesta. Esto se consigue determinando la sensibilidad de los atributos de calidad seleccionados (también llamados dimensiones del diseño) con diferentes mecanismos de realización que reflejan las propiedades de la arquitectura.El método de diseño arquitectónico presentado en este capítulo utiliza las características del flujo de datos descritas en el modelo de análisis que derivan de un estilo arquitectónico utilizado comúnmente. El diagrama de flujo de datos se descompone dentro de la estructura del sistema a través de dos enfoques de análisis -e1 análisis de las transformaciones y/o el análisis de las transacciones-. Se aplica el análisis de las transformaciones a un flujo de información que presenta diferentes límites entre los datos de entrada y de salida. El DFD se organiza en una estructura que asigna los controles de entrada, procesamiento y salida a través de tres jerarquías separadas de módulos de descomposición en factores. El análisis de las transformaciones se aplica cuando un Único ítem de información bifurca su flujo a través de diferentes caminos. El DFD se organiza en una estructura que asigna el control a una subestructura que adquiere y evalúa la transacción. Otra subestructura controla todas las acciones potenciales de procesamiento basadas en la transacción. Una vez que la arquitectura ha sido perfilada se elabora y se analiza contrastándola con los criterios de calidad.

El diseño arquitectónico agrupa un grupo inicial de actividades de diseño que conducen a un modelo completo del diseño del software.

Se puede argumentar que la interfaz de usuario es el elemento más importante de un sistema o producto basado en computadora. Si la interfaz tiene un diseño pobre, la capacidad que tiene el usuario de aprovecharse de la potencia de proceso de una aplicación se puede dificultar gravemente. En efecto, una interfaz débil puede llevar al fracaso de una aplicación con una implementación sólida y un buen diseño.Existen tres principios importantes que dirigen el diseño de interfaces de usuario eficaces: (1) poner el control en manos del usuario; (2) reducir la carga de la memoria del usuario; (3) construir una interfaz consecuente. Para lograr que una interfaz se atenga a estos principios, se deberá desarrollar un proceso de diseño organizado.El diseño de la interfaz de usuario comienza con la identificación de los requisitos del usuario, de las tareas y del entorno. El análisis de tareas es una actividad de diseño que define las tareas y acciones del usuario empleando un enfoque elaborativo u orientado a objetos.Una vez que se han definido las tareas, los escenarios del usuario se crean y analizan para definir un conjunto de objetos y acciones de la interfaz. Esto es lo que proporciona la base para la creación del formato de la pantalla, el cual representa el diseño gráfico y la colocación de iconos, la definición de un texto descriptivo en pantalla, la especificación y titulación de ventanas y la especificación de los elementos importantes y secundarios del menú. Cuando se va a refinar un modelo de diseño para el sistema se tienen en consideración temas de diseño tales como tiempo de respuesta, estructura de Órdenes y acciones, manipulación de errores y funciones de ayuda. Para construir un prototipo que el usuario pueda evaluar se utilizan diversas herramientas de implementación.La interfaz de usuario es la ventana del software. En muchos casos, la interfaz modela la percepción que tiene un usuario de la calidad del sistema. Si la ventana se difumina, se ondula o se quiebra, el usuario puede rechazar un sistema potente basado en computadora.

El proceso de diseño acompaña a una secuencia de actividades que reducen lentamente el nivel de abstracción con el que se representa el software. El diseño a nivel de componentes representa el software a un nivel de abstracción muy cercano al código fuente.A un nivel de componentes, el ingeniero del software debe representar estructuras de datos, interfaces y algoritmos con suficiente detalle como para servir de guía en la generación de códigos fuente de lenguajes de programación. Para conseguirlo, el ingeniero utiliza una de las notaciones de diseño que representa los detalles a nivel de componentes o bien en formatos gráficos, tabulares o basados en texto.La programación estructurada es una filosofía de diseño procedimental que restringe el número y tipo de construcciones lógicas que se utilizan para representar el dato algorítmico. El objetivo de la programación estructurada es

ayudar a que el diseñador defina algoritmos menos complejos y por tanto más fáciles de leer, comprobar y mantener.

El principal objetivo del diseño de casos de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software. Para llevar a cabo este objetivo, se usan dos categorías diferentes de técnicas de diseño de casos de prueba: prueba de caja blanca y prueba de caja negra.Las pruebas de caja blanca se centran en la estructura de control del programa. Se obtienen casos de prueba que aseguren que durante la prueba se han ejecutado, por lo menos una vez, todas las sentencias del programa y que se ejercitan todas las condiciones lógicas. La prueba del camino básico, una técnica de caja blanca, hace uso de grafos de programa (o matrices de grafos) para obtener el conjunto de pruebas linealmente independientes que aseguren la total cobertura. La prueba de condiciones y del flujo de datos ejercita más aún la lógica del programa y la prueba de los bucles complementa a otras técnicas de caja blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados de complejidad.Heztel [HET84] describe la prueba de caja blanca como «prueba a pequeña escala». Esto se debe a que las pruebas de caja blanca que hemos considerado en este capítulo son típicamente aplicadas a pequeños componentes de programas (PO ejemplo; módulos o pequeños grupos de módulos). Por otro lado, la prueba de caja negra amplía el enfoque y se puede denominar «prueba a gran escala».

Las pruebas de caja negra son diseñadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa. Las técnicas de prueba de caja negra se centran en el ámbito de información de un programa, de forma que se proporcione una cobertura completa de prueba. Los métodos de prueba basados en grafos exploran las relaciones entre los objetos del programa y su comportamiento. La partición equivalente divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software. El análisis de valores límite prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables. La prueba de la tabla ortogonal suministra un método sistemático y eficiente para probar sistemas con un número reducido de parámetros de entrada.Los métodos de prueba especializados comprenden una amplia gama de capacidades del software y áreas de aplicación.Las interfaces gráficas de usuario, las arquitecturas cliente/servidor, la documentación y facilidades de ayuda, y los sistemas de tiempo real requieren directrices y técnicas especializadas para la prueba del software.A menudo, los desarrolladores de software experimentados dicen que «la prueba nunca termina, simplemente se transfiere de usted (el ingeniero del software) al cliente: Cada vez que el cliente usa el programa, lleva a cabo una prueba.» Aplicando el diseño de casos de prueba, el ingeniero del software puede conseguir una prueba más completa y descubrir y corregir así el mayor número de errores antes de que comiencen las «pruebas del cliente».

La prueba del software contabiliza el mayor porcentaje del esfuerzo técnico del proceso de desarrollo de software.Todavía estamos comenzando a comprender las sutilezas de la planificación sistemática de la prueba, de su ejecución y de su control. El objetivo de la prueba de software es descubrir errores. Para conseguir este objetivo, se planifica y se ejecutan una serie de pasos; pruebas de unidad, de integración, de validación y del sistema. Las pruebas de unidad y de integración se centran en la verificación funcional de cada módulo y en la incorporación de los módulos en una estructura de programa. La prueba de validación demuestra el seguimiento de los requisitos del software y la prueba del sistema valida el software una vez que se ha incorporado en un sistema superior.Cada paso de prueba se lleva a cabo mediante una serie de técnicas sistemáticas de prueba que ayudan en el diseño de casos de prueba. Con cada paso de prueba se amplía el nivel de abstracción con el que se considera el software.A diferencia de la prueba (una actividad sistemática y planificada), la depuración se puede considerar un arte.A partir de una indicación sintomática de un problema, la actividad de la depuración debe rastrear la causa del error. De entre los recursos disponibles durante la depuración, el más valioso puede ser el apoyo de otros ingenieros de software.

Las métricas del software proporcionan una manera cuantitativa de valorar la calidad de los atributos internos del producto, permitiendo por tanto al ingeniero valorar la calidad antes de construir el producto. Las métricas proporcionan la visión interna necesaria para crear modelos efectivos de análisis y diseño, un código sólido y pruebas minuciosas.Para que sea útil en el contexto del mundo real, una métrica del software debe ser simple y calculable, persuasiva, consistente y objetiva. Debería ser independiente del lenguaje de programación y proporcionar una realimentación eficaz para el desarrollador de software.Las métricas del modelo de análisis se concentran en la función, los datos y el comportamiento (los tres componentes del modelo de análisis). El punto de función y la métrica bang proporcionan medidas cuantitativas para evaluar el modelo de análisis. Las métricas del diseño consideran aspectos de alto nivel, del nivel de componentes y de diseño de interfaz. Las métricas de diseño de alto nivel consideran los aspectos arquitectónicos y estructurales del modelo de diseño. Las métricas de diseño de nivel de componentes proporcionan una indicación de la calidad del módulo estableciendo medidas indirectas de la cohesión, acoplamiento y complejidad. Las métricas de diseño de interfaz proporcionan una indicación de la conveniencia de la representación de una IGU.La ciencia del software proporciona un intrigante conjunto de métricas a nivel de código fuente. Usando el número de operadores y operandos presentes en el código, la ciencia del software proporciona una variedad de métricas que pueden usarse para valorar la calidad del programa.Se han propuesto pocas métricas técnicas para un empleo directo en las pruebas y mantenimiento del software.

Sin embargo, se pueden emplear muchas otras métricas técnicas para guiar el proceso de las pruebas y como mecanismo para valorar la facilidad de mantenimiento de un programa de computadora.

Las tecnologías de objetos reflejan una visión natural del mundo. Los objetos se clasifican en clases y las clases se organizan en jerarquías. Cada clase contiene un conjunto de atributos que la describen y un conjunto de operaciones que define su comportamiento.Los objetos modelan casi todos los aspectos identificables del dominio del problema: entidades externas, cosas, ocurrencias, roles, unidades organizacionales, lugares y estructuras pueden ser representados como objetos. Es importante destacar que los objetos (y las clases de las que se derivan) encapsulan datos y procesos. Las operaciones de procesamiento son parte del objeto y se inician al pasarle un mensaje al objeto. Una definición de clase, una vez definida, constituye la base para la reutilización en los niveles de modelado, diseño e implementación.Los objetos nuevos pueden ser instanciados a partir de una clase.

Tres conceptos importantes diferencian el enfoque O0 de la ingeniería del software convencional. El encapsulamiento empaqueta datos y las operaciones que manejan esos datos. La herencia permite que los atributos y operaciones de una clase puedan ser heredados por todas las clases y objetos que se instancian de ella. El polimorfismo permite que una cantidad de operaciones diferentes posean el mismo nombre, reduciendo la cantidad de líneas de código necesarias para implementar un sistema y facilita los cambios en caso de que se produzcan.Los productos y sistemas orientados a objetos se producen usando un modelo evolutivo, a veces llamado recursivo/paralelo. El software orientado a objetos evoluciona iterativamente y debe dirigirse teniendo en cuenta que el producto final se desarrollará a partir de una serie de incrementos.

Los métodos de A00 permiten a un ingeniero del software modelar un problema representando las características tanto dinámicas como estáticas de las clases y sus relaciones como componentes principales del modelado.Como los métodos precedentes, el lenguaje unificado de modelado UML construye un modelo de análisis con las siguientes características: (1) representación de las clases y jerarquías de clases, (2) creación de modelos objeto-relación, y (3) obtención de modelos objetocomportamiento.El análisis de sistemas orientados a objetos se realiza a muchos niveles diferentes de abstracción. En los niveles de empresa o de negocio las técnicas asociadas con el análisis se pueden conjugar con el enfoque de ingeniería del proceso de negocio. A estas técnicas a menudo se las llama de análisis del dominio. En el nivel de implementación el modelo de objetos se centra en los requisitos especificados por el cliente tal y como éstos afectan a la aplicación a construir.El proceso de A00 comienza con la definición de casos de uso (escenarios que describen cómo se va a utilizar el sistema). La técnica de modelado de clases responsabilidades- colaboraciones (CRC) se aplica para documentar las clases y sus atributos y operaciones.

También proporciona una vista inicial de las colaboraciones que ocurren entre los objetos. El siguiente paso en el A00 es la clasificación de objetos y la creación de una jerarquía de clases. Los sistemas (paquetes) se pueden utilizar para encapsular objetos relacionados.El modelo objeto-relación proporciona información sobre las conexiones entre las clases, mientras que el modelo objeto-comportamiento representa el comportamiento de los objetos individualmente y el global de todo el sistema.

El diseño orientado a objetos traduce el modelo de A00 del mundo real, a un modelo de implementación específica, que puede realizarse en software. El proceso de DO0 puede describirse como una pirámide compuesta por cuatro capas. La capa fundamental se centra en el diseño de subsistemas, que implementan funciones principales de sistema. La capa de clases especifica la arquitectura de objetos global, y la jerarquía de clases requerida para implementar un sistema.La capa de mensajes indica cómo debe ser realizada la colaboración entre objetos, y la capa de responsabilidades identifica las operaciones y atributos que caracterizan cada clase.Al igual que el AOO, existen diferentes métodos de DOO. UML es un intento de proporcionar una aproximación simple al DOO, que se aplica en los dominios de aplicaciones. UML y otros métodos, aproximan el proceso de diseño mediante dos niveles de abstracción -diseño de subsistemas (arquitectura) y diseño de objetos individuales-.Durante el diseño del sistema, la arquitectura del sistema orientado a objetos se desarrolla. Además del desarrollo de sistemas, de sus interacciones y de su colocación dentro de las capas arquitectónicas, el diseño de sistemas considera la componente de interacción con el usuario, una componente de administración de tareas y una componente de manejo de datos. Estas componentes de subsistemas proporcionan la infraestructura de diseño, que permite a la aplicación operar efectivamente. El proceso de diseño de objetos se centra en la descripción de estructuras de datos, que usan los atributos de clase, los algoritmos que usan las operaciones y los mensajes que permiten colaboraciones entre objetos relacionados.Los patrones de diseño permiten al diseñador crear la arquitectura de diseño integrando componentes reusables.La programación O0 extiende el modelo de diseño a un dominio de ejecución. Un lenguaje de programación O0 se usa para traducir las clases, atributos, operaciones y mensajes, de manera que puedan ejecutarse por la máquina.

El objetivo global de la verificación orientada a objetos-encontrar el máximo número de errores con un mínimo de esfuerzo-, es idéntico al objetivo de prueba del software convencional. Pero la estrategia y tácticas para la prueba O0 difieren de modo significativo. La visión de verificación se amplía, para incluir la revisión de ambos modelos de diseño y de análisis.En resumen, el enfoque de prueba se aleja del componente procedimental (el módulo) hacia la clase. Ya que los modelos de análisis y diseño O0 y el código fuente resultante se acoplan semánticamente, la prueba (a manera de revisiones

técnicas formales) comienza en estas actividades de ingeniería. Por esta razón, la revisión de los métodos CRC, objeto-relación y objeto-comportamiento, pueden verse como una primera etapa de prueba.Una vez que la PO0 ha sido concluida, las pruebas de unidad se aplican a cada clase. El diseño de pruebas para una clase utiliza una variedad de métodos: pruebas basadas en errores, las pruebas al azar y las pruebas por partición. Cada uno de estos métodos ejercita las operaciones encapsuladas por la clase.Las secuencias de pruebas se diseñan para asegurarse de que las operaciones relevantes se ejerciten.El estado de la clase representada por los valores de sus atributos se examina, para determinar si persisten errores.La prueba de integración puede llevarse a cabo utilizando una estrategia basada en hilos o basada en el uso.La estrategia basada en hilos integra el conjunto de clases, que colaboran para responder a una entrada o suceso.Las pruebas basadas en el uso construyen el sistema en capas, comenzando con aquellas clases que no usan clases servidoras. Los métodos de diseño de integración de casos de prueba pueden usar pruebas al azar y por partición.En suma, las pruebas basadas en el escenario y las pruebas derivadas de los modelos de comportamiento pueden usarse para verificar una clase y sus colaboraciones.Una secuencia de pruebas registra el flujo de operaciones, a través de las colaboraciones de clases.La prueba de validación de sistemas O0 está orientada a caja negra y puede completarse aplicando los mismos métodos de prueba de caja de negra discutidos para el software convencional. Sin embargo, las pruebas basadas en el escenario dominan la validación de sistemas 00, haciendo que el caso de uso sea el conductor primario para las pruebas de validación.

El software orientado a objetos es fundamentalmente diferente al software desarrollado con el uso de métodos convencionales.Es por esto que las métricas para sistemas O0 se enfocan en la ponderación que puede aplicarse a las clases y a las características del diseño -1ocalización, encapsulación, ocultamiento de información, herencia y técnicas de abstracción de objetos-, que definen a la clase como única.La colección de métricas CK define seis métricas de software orientadas a la clase que se centran en la clase y en la jerarquía de clases. La colección de métricas también incorpora métricas para evaluar las colaboraciones entre clases y la cohesión de métodos que residen dentro de la clase. Al nivel orientado a clases, la colección CK puede complementarse con las métricas propuestas por Lorenz y Kidd y la colección de métricas MDOO. Estas incluyen ponderaciones de «tamaño» de clase, y otras métricas que proporcionan una visión acerca del grado de especialización de las subclases.Las métricas orientadas a operaciones se centran en el tamaño y complejidad de las operaciones individuales.Sin embargo, es importante hacer notar que la primera para las métricas de diseño O0 es a nivel de clases.

Se ha propuesto una amplia variedad de métricas O0 para evaluar la comprobabilidad de un sistema OO. Estas métricas se centran en la encapsulación, herencia, complejidad de las clases y polimorfismo. Muchas de estas métricas han sido adaptadas de la colección CK y de las métricas propuestas por Lorenz y Kidd. Otras han sido propuestas por Binder.Las características ponderables del modelo de análisis y diseño pueden ayudar al jefe de proyecto de un sistema O0 en la planificación y registro de las actividades.El número de escenarios (casos de uso), clases clave y subsistemas proporcionan información acerca del nivel de esfuerzo requerido para implementar el sistema.

Los métodos formales ofrecen un fundamento para entornos de especificación que dan lugar a modelos de análisis más completos, consistentes y carentes de ambigüedad, que aquellos que se producen empleando métodos convencionales u orientados a objetos. Las capacidades descriptivas de la teoría de conjuntos y de la notación lógica capacitan al ingeniero del software para crear un enunciado claro de los hechos (requisitos).Los conceptos subyacentes que gobiernan los métodos formales son: (1) los invariantes de datos condiciones que son ciertas a lo largo de la ejecución del sistema que contiene una colección de datos-; (2) el estado -los datos almacenados a los que accede el sistema y que son alterados por él-; (3) la operación una acción que tiene lugar en un sistema y que lee o escribe datos en un estado-. Una operación queda asociada con dos condiciones: una precondición y una postcondición.La matemática discreta -la notación y práctica asociada a los conjuntos y a la especificación constructiva, a los operadores de conjuntos, a los operadores lógicos y a las sucesiones- constituyen la base de los métodos formales. Estas matemáticas están implementadas en el contexto de un lenguaje de especificación formal, tal como Z.Z, al igual que todos los lenguajes de especificación formal, posee tanto un dominio semántico como un dominio sintáctico. El dominio sintáctico utiliza una simbología que sigue estrechamente a la notación de conjuntos y al cálculo de predicados. El dominio semántico capacita al lenguaje para expresar requisitos de forma concisa. La estructura Z contiene esquemas, estructuras en forma de cuadro que presentan las variables y que especifican las relaciones entre estas variables.La decisión de utilizar métodos formales debe considerar los costes de arranque, así como los cambios puntuales asociados a una tecnología radicalmente distinta.En la mayoría de los casos, los métodos formales ofrecen los mayores beneficios para los sistemas de seguridad y para los sistemas críticos para los negocios.

La ingeniería del software de sala limpia es un enfoque formal para el desarrollo del software, que puede dar lugar a un software que posea una calidad notablemente alta. Emplea la especificación de estructura de cajas (o métodos formales) para el modelado de análisis y diseño, y hace hincapié en la verificación de la corrección, más que en las pruebas, como mecanismo fundamental para hallar y eliminar errores. Se aplica una prueba estadística de utilización para

desarrollar la información de tasa de fallos necesaria para certificar la fiabilidad del software proporcionado.El enfoque de sala limpia comienza por unos modelos de análisis y diseño que hacen uso de una representación de estructura de cajas. Una «caja» encapsula el sistema (o algún aspecto del sistema) en un determinado nivel de abstracción. Se utilizan cajas negras para representar el comportamiento observable externamente de ese sistema.Las cajas de estado encapsulan los datos y operaciones de ese estado. Se utiliza una caja limpia para modelar el diseño de procedimientos que está implicado por los datos y operaciones de la caja de estados.Se aplica la verificación de corrección una vez que está completo el diseño de estructura de cajas. El diseño de procedimientos para un componente de software se desglosará en una serie de subfunciones. Para demostrar la corrección de cada una de estas subfunciones, se definen condiciones de salida para cada una de las subfunciones y se aplica un conjunto de subpruebas. Si se satisfacen todas y cada una de las condiciones de salida, entonces el diseño debe ser correcto.Una vez finalizada la verificación de corrección, comienza la prueba estadística de utilización. A diferencia de la comprobación condicional, la ingeniería del software de sala limpia no hace hincapié en la prueba unitaria o de integración. En su lugar, el software se comprueba mediante la definición de un conjunto de escenarios, mediante la determinación de las probabilidades de utilización de cada uno de esos escenarios y mediante la aplicación posterior de pruebas aleatorias que satisfagan estas probabilidades. Los registros de error resultantes se combinan con modelos de muestreo, de componentes y de certificación para hacer posible el cálculo matemático de la fiabilidad estimada de ese componente de software.La filosofía de sala limpia es un enfoque riguroso de la ingeniería del software. Se trata de un modelo de proceso del software que hace hincapié en la verificación matemática de la corrección y en la certificación de la fiabilidad del software. El resultado final son unas tasas de fallo extremadamente bajas, que sería difícil o imposible de conseguir empleando unos métodos menos formales.

La ingeniería del software basada en componentes proporciona unos beneficios inherentes en lo tocante a calidad del software, productividad del desarrollador y coste general del sistema. Sin embargo, es preciso vencer muchas dificultades antes de que el modelo de proceso ISBC se utilice ampliamente en la industria.Además de los componentes del software, un ingeniero del software puede adquirir toda una gama de elementos reutilizables. Entre estos se cuentan las representaciones técnicas del software (por ejemplo, especificación, modelos de arquitectura, diseños y códigos), documentos, datos de prueba e incluso tareas relacionadas con los procesos (por ejemplo, técnicas de inspección).El proceso ISBC acompaña a dos subprocesos concurrentes -ingeniería del dominio y desarrollo basado en componentes-. El objetivo de la ingeniería del dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software en un determinado dominio de aplicación. A continuación, el desarrollo basado en componentes cualifica, adapta e integra estos componentes para su reutilización en un sistema nuevo. Además, el

desarrollo basado en componentes diseña componentes nuevos que se basan en los requisitos personalizados de un sistema nuevo.Las técnicas de análisis y diseño de componentes reutilizables se basan en los mismos principios y conceptos que forman parte de las buenas prácticas de ingeniería del software. Los componentes reutilizables deberían de diseñarse en el seno de un entorno que establezca unas estructuras de datos estándar, unos protocolos de interfaz y unas arquitecturas de programa para todos los dominios de aplicación.La ingeniería del software basada en componentes hace uso de un modelo de intercambio de datos; herramientas, almacenamiento estructurado y un modelo objeto subyacente para construir aplicaciones. EL modelo de objetos suele ajustarse a uno o más estándares de componentes (por ejemplo, OMGKORBA) que definen la forma en que una aplicación puede acceder a los objetos reutilizables. Los esquemas de clasificación capacitan al desarrollador para hallar y recuperar componentes reutilizables y se ajustan a un modelo que identifica conceptos, contenidos y contextos. La clasificación enumerada, la clasificación de facetas, y la clasificación de valores de atributos son representativas de muchos esquemas de clasificación de componentes.La economía de reutilización del software se abarca con una Única pregunta: ¿Es rentable construir menos y reutilizar más? En general, la respuesta es «sí», pero un planificador de proyectos de software debe considerar los costes no triviales asociados a la adaptación e integración de los componentes reutilizables.

Aun cuando los sistemas cliente/servidor pueden adoptar uno o más de los modelos de procesos de software y muchos de los métodos de análisis, diseño y comprobación descritos anteriormente en este libro, las características de arquitecturas especiales de C/S requieren una personalización del software de ingeniería del software. En general, el modelo de proceso del software que se aplica a los sistemas C/S tiene una naturaleza evolutiva, y los métodos técnicos suelen tender a enfoques orientados a objetos. El desarrollador debe describir aquellos objetos que se produzcan en la implementación de los componentes de interacción hepresentación con el usuario, de base de datos y de aplicación. Los objetos definidos para estos componentes deberían asignarse bien a la máquina, o bien a la máquina servidor, y se pueden vincular a través de un distribuidor de solicitudes de objetos.Las arquitecturas de agente de solicitud de objetos sirven de apoyo para los diseños C/S en los cuales los objetos cliente envían mensajes a los objetos servidor.El estándar CORBA hace uso de un lenguaje de definición de interfaz, y los repositorios de interfaz gestionan las solicitudes de objetos independientemente de su ubicación dentro de la red.El análisis y el diseño de sistemas cliente servidor hacen uso de diagramas de flujo de datos y de entidades y relaciones, diagramas de estructura modificados, y otras notaciones que se encuentran en el desarrollo de aplicaciones convencionales. Es preciso modificar las estrategias de comprobación para adecuarlas a las comprobaciones que examinan la comunicación a través de la

red y el juego entre el software que reside en el cliente y aquel que reside en el servidor.

Se puede argumentar que el impacto de los sistemas y aplicaciones basados en Web es el acontecimiento más significativo en la historia de la informática. A medida que las WebApps crecen en importancia, el enfoque de ingeniería de Web disciplinado ha empezado a evolucionar -basado en principios, conceptos, procesos y métodos que se han desarrollado para la ingeniería del software.Las WebApps son diferentes de otras categorías de software informático. Son intensivas de red, están gobernadas por el contenido y están en continua evolución. La inmediatez que conduce a su desarrollo, la necesidad primordial de seguridad al funcionar, y la demanda de estética y la entrega del contenido funcional son otros factores diferenciadores. Durante el desarrollo de la WebApp hay tres tecnologías que se integran con otras de ingeniería del software convencional; desarrollo basado en componentes, seguridad y lenguajes de notas estándar.El proceso de ingeniería de Web comienza con la formulación una actividad que identifica las metas y los objetivos de la WebApp-. La planificación estima el coste global del proyecto, evalúa los riesgos asociados con el esfuerzo del desarrollo y define una programación temporal del desarrollo. El análisis establece requisitos técnicos e identifica los objetos del contenido que se incorporarán en la WebApp. La actividad de ingeniería incorpora dos tareas paralelas: diseño del contenido y diseño técnico. La generación de páginas es una actividad de construcción que hace un uso extenso de herramientas automatizadas para la creación de WebApps, y la comprobación ejercita la navegación de la WebApp, intentando descubrir errores en la función y el contenido, y asegurando mientras tanto que la WebApp funcione correctamente en diferentes entomos. La ingeniería de Web hace uso de un modelo de proceso iterativo e incremental porque la línea temporal del desarrollo para la WebApp es muy corta. Las actividades protectoras aplicadas durante el trabajo de la ingeniería del software -SQA, GCS, gestión de proyectos- se aplican a todos los proyectos de ingeniería de Web.

La ingeniería se produce en dos niveles distintos de abstracción. En el nivel de negocios, la reingeniería se concentra en el proceso de negocios con la intención de efectuar cambios que mejoren la competitividad en algún aspecto de los negocios. En el nivel del software, la reingeniería examina los sistemas y aplicaciones de información con la intención de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad.La reingeniería de procesos de negocio (RPN) define los objetivos de negocios, identifica y evalúa los procesos de negocios ya existentes (en el contexto de los objetivos definidos), especifica y diseña los procesos revisados, y construye prototipos, refina e instancia esos procesos en el seno de un negocio. La RPN tiene un objetivo que va más allá del software. Su resultado suele ser la definición de formas en que las tecnologías de la información puedan prestar un mejor apoyo a los negocios.La reingeniería del software abarca una serie de actividades entre las que se incluye el análisis de inventario, la reestructuración de documentos, la ingeniería

inversa, la reestructuración de programas y datos, y la ingeniería directa. El objetivo de esas actividades consiste en crear versiones de los programas existentes que muestren una mayor calidad, y una mejor mantenibilidad-se trata de programas que sean viables hasta bien entrado el siglo veintiuno-.El análisis de inventarios permite que una organización estime todas y cada una de las aplicaciones sistemáticamente, con el fin de determinar cuáles son las candidatas para una reingeniería. La reestructuración de documentos crea un marco de trabajo de documentos necesario para el apoyo de una cierta aplicación a largo plazo. La ingeniería inversa es el proceso de analizar un programa en un esfuerzo por extraer información acerca de los datos, de su arquitectura y del diseño de procedimientos. Por Último, la ingeniería directa reconstruye el programa empleando prácticas de ingeniería moderna del software y la información obtenida durante la ingeniería inversa.Los costes y beneficios de la reingeniería se pueden determinar de forma cuantitativa. El coste del status quo, esto es, los costes asociados al mantenimiento y soporte que conlleva una aplicación existente se puede comparar con los costes estimados de la reingeniería, y con la reducción resultante de los costes de mantenimiento. En casi todos los casos en que un programa tiene una vida larga y muestra en la actualidad un mantenimiento dificultoso, la reingeniería representa una estrategia de negocios eficiente en relación con los costes.

Las herramientas de ingeniería del software asistida por computadora abarcan todas las actividades del proceso del software y también aquellas actividades generales que se aplican a lo largo de todo el proceso. CASE combina un conjunto de bloques de construcción que comienzan en el nivel del hardware y del software de sistema operativo y finalizan en las herramientas individuales.En este capítulo se ha tenido en consideración una taxonomía de herramientas CASE. Las categorías abarcan tanto las actividades de gestión como las técnicas, e incluyen la mayor parte de las áreas de aplicación del software. Todas las categorías de herramientas se han considerado «soluciones puntuales».El entorno 1-CASE combina mecanismos de integración para datos, herramientas e interacción hombre-computadora.La integración de datos se puede conseguir mediante el intercambio directo de información, mediante estructuras de archivos comunes, mediante datos compartidos o interoperabilidad, o a través de la utilización de un repositorio 1-CASE completo. La integración de herramientas se puede diseñar de forma personalizada por parte de fabricantes que trabajan a la vez, o bien se puede lograr mediante un software de gestión que se proporcione como parte del repositorio.La integración entre hombre y computadora se logra mediante estándares de interfaz que se están volviendo cada vez más comunes a lo largo y ancho de toda la industria. Para facilitar la integración de los usuarios con las herramientas, de las herramientas entre sí, de las herramientas con los datos y de los datos con otros datos se diseña una arquitectura de integración.Se ha aludido al repositorio CASE con el nombre de «bus de software». La información pasa por él, y va circulando de herramienta en herramienta a medida que progresa el proceso de software. Pero el repositorio es mucho más que un

«bus». También se trata de un lugar de almacenamiento que combina sofisticados mecanismos para integrar herramientas CASE mejorando consiguientemente el proceso mediante el cual se desarrolla el software. El repositorio es una base de datos relacional u orientada a objetos que es «el centro de acumulación y almacenamiento» de la información de ingeniería del software.