La ingeniería
De software basada en la reutilización es una estrategia en la que se engrana//el
Proceso de desarrollo para reutilizar el software existente. Aunque la
Reutilización se//propuso como una estrategia de desarrollo hace más de 40 años
(McIlroy, 1968), es sólo a//partir de 2000 cuando el “desarrollo con
Reutilización” se convirtió en la norma de los nuevos//sistemas empresariales.
El movimiento hacia el desarrollo basado en la reutilización//fue en respuesta
A las demandas para reducir los costos de producción y mantenimiento//del
Software, entregar los sistemas con mayor rapidez y aumentar la calidad del
Software.//Cada vez más compañías consideran su software como un activo
Valioso. Así, promueven//su reutilización para incrementar el rendimiento en
Las inversiones de software.//La disponibilidad de software reutilizable
Aumentó drásticamente. El movimiento de//fuente abierta significó que se
Dispone de una enorme base de código de reutilización a//bajo costo. Esto puede
Ser en la forma de librerías de programa o aplicaciones completas.//Existen
Muchos sistemas de aplicación de dominio específico disponibles que pueden//ajustarse
Y adaptarse a las necesidades de una compañía específica. Algunas grandes
Compañías//ofrecen varios componentes de reutilización para sus clientes. Los
Estándares, como//los estándares de servicios Web, han facilitado el desarrollo
De servicios generales y su//reutilización a través de varias aplicaciones.//La
Ingeniería de software basada en la reutilización es un enfoque al desarrollo
Que//trata de maximizar la reutilización del software existente. Las unidades
De software que se//reutilizan pueden ser de tamaños sustancialmente
Diferentes. Por ejemplo://
1.
Reutilización del sistema de
Aplicación Todo un
Sistema de aplicación puede reutilizarse//al incorporarlo sin cambios en otros
Sistemas o al configurar la aplicación para//diferentes clientes. De manera
Alternativa, pueden desarrollarse familias de aplicación//que, aunque tengan
Una arquitectura común, se ajustan a clientes específicos.//Más adelante, en
Este capítulo, se hablará de la reutilización de componentes.//
2. Reutilización de componentes Los componentes de una
Aplicación, que varían en//tamaño desde subsistemas hasta objetos individuales,
Pueden reutilizarse. Por ejemplo,//un sistema de identificación de patrones
Desarrollado como parte de un sistema//de procesamiento de texto puede
Reutilizarse en un sistema de administración de//base de datos. La
Reutilización de componentes se desarrolla en los capítulos 17 y 19.//
3. Reutilización de objetos y
Funciones Pueden
Reutilizarse los componentes de software//que implementan una sola función, tal
Como una función matemática, o una//clase de objeto. Esta forma de
Reutilización en torno a librerías estándar ha sido//común durante los últimos
40 años. Muchas librerías de funciones y clases están disponibles//de manera
Gratuita. Las clases y funciones en dichas librerías se reutilizan//al
Vincularlas con un código de aplicación de desarrollo reciente. Este enfoque es//particularmente
Efectivo en áreas como algoritmos matemáticos y gráficas, donde se//necesita
Experiencia especializada para desarrollar objetos y funciones eficientes.//Los
Sistemas y componentes de software son entidades potencialmente reutilizables,//pero
Su naturaleza específica significa que en ocasiones es costoso modificarlos
Para una//nueva situación. Una forma complementaria de reutilización es la “reutilización
De concepto”//en la que, en vez de reutilizar un componente de software, se
Reutiliza una idea,//una vía, un funcionamiento o un algoritmo. El concepto que
Se reutiliza se representa//en una notación abstracta (por ejemplo, un modelo
De sistema), que no incluye detalles//de implementación. Por lo tanto, puede
Configurarse y adaptarse para varias situaciones.//El concepto de reutilización
Puede incorporarse como en el diseño de patrones de diseño//(que se estudiaron
En el capítulo 7), productos de sistema configurables y generadores de//Capítulo 16 ■
Reutilización de
Software 427//programa.
Cuando se reutilizan conceptos, el proceso de reutilización incluye una
Actividad//donde los conceptos abstractos se ejemplifican para crear
Componentes ejecutables//de reutilización.//Una ventaja evidente de la
Reutilización de software es que deberían reducirse los//costos totales de
Desarrollo. Habrá que especificar, diseñar, implementar y validar menos//componentes
De software. Sin embargo, la reducción del costo es sólo una ventaja de//la
Reutilización. En la figura 16.1 se mencionan otras ventajas de la
Reutilización de los//activos de software.//No obstante, existen costos y
Problemas asociados con la reutilización (figura 16.2).//Hay un costo
Significativo asociado con entender si un componente es adecuado o no//para su
Reutilización en una situación particular, y probar dicho componente para
Garantizar//su confiabilidad. Tales costos adicionales significan que las
Reducciones en los costos//totales del desarrollo mediante la reutilización
Pueden ser menores que lo previsto.//Como se estudió en el capítulo 2, los
Procesos de desarrollo de software deben adaptarse//para tomar en cuenta la
Reutilización. En particular, debe haber una etapa de corrección//de
Requerimientos en la que se modifiquen los requerimientos del sistema para//reflejar
El software de reutilización disponible. Las etapas de diseño e implementación//del
Sistema pueden incluir también actividades explícitas para buscar y evaluar
Componentes//candidatos para su reutilización.//La reutilización de software es
Más efectiva cuando se planea como parte de un programa//de reutilización de
Toda la organización. Un programa de reutilización implica la//creación de
Activos reutilizables y la adaptación de procesos de desarrollo para incorporar//dichos
Activos en el software nuevo. La importancia de la planeación de reutilización
Se//reconoce desde hace varios años en Japón (Matsumoto, 1984), donde la
Reutilización era//parte integral del enfoque “fabril” Japónés al desarrollo de
Software (Cusamano, 1989).//Beneficio Explicación//
Confiabilidad creciente El software de
Reutilización, que se experimentó y ensayó en sistemas//operativos, debe ser
Más confiable que el software nuevo. Sus fallas de diseño//e implementación
Debieron descubrirse y corregirse.//Reducción de riesgo//de proceso//Se conoce
Ya el costo del software existente, mientras que el de desarrollo//siempre es
Una cuestión de juicio. Éste es un factor importante para la gestión//del
Proyecto, ya que reduce el margen de error en la estimación de costos del//proyecto.
Esto es particularmente cierto cuando se reutilizan componentes de//software
Relativamente grandes, como los subsistemas.//Uso efectivo de especialistas En
Lugar de hacer el mismo trabajo una y otra vez, los especialistas de aplicación//pueden
Desarrollar software de reutilización que encapsule su conocimiento.//Cumplimiento
De estándares Algunos estándares, como los de la interfaz de usuario, pueden
Implementarse//como un conjunto de componentes de reutilización. Por ejemplo,
Si los menús//en una interfaz de usuario se implementan con componentes
Reutilizables,//todas las aplicaciones presentan a los usuarios los mismos
Formatos de menú.//El uso de interfaces de usuario estándar mejora la
Confiabilidad, porque los//usuarios cometen menos errores cuando se les
Presenta una interfaz familiar.//Desarrollo acelerado Llevar un sistema al
Mercado tan rápido como sea posible con frecuencia es//más importante que los
Costos totales de desarrollo. La reutilización de software//puede acelerar la
Producción del sistema, ya que pueden reducirse los tiempos//de desarrollo y
Validación.//Figura 16.1//
Beneficios de la//reutilización//de software//428
Capítulo 16 ■
Reutilización de
Software//Compañías
Tales como Hewlett-Packard han tenido también mucho éxito en sus programas//de
Reutilización (Griss y Wosser, 1995), y su experiencia se documentó en un libro//de
Jacobson et al. (1997).//16.1 Panorama de la
Reutilización//
Durante
Los últimos 20 años, se han desarrollado muchas técnicas para apoyar la
Reutilización//de software. Dichas técnicas aprovechan el hecho de que los
Sistemas en el mismo//dominio de aplicación son similares y tienen potencial de
Reutilización (esa reutilización//es posible a diferentes niveles desde simples
Funciones hasta completas aplicaciones), y//el hecho de que estándares para
Componentes reutilizables facilitan la reutilización. La//figura 16.3 establece
Algunas formas posibles de implementar la reutilización de software,//y en la
Figura 16.4 se describe brevemente cada una de ellas.//Teniendo en cuenta este
Arreglo de técnicas para la reutilización, la pregunta clave//es: ¿Cuál es la
Técnica más adecuada para usar en una situación particular? Desde luego,//esto
Depende de los requerimientos del sistema a desarrollar, la tecnología y los
Activos//reutilizables disponibles, y la experiencia del equipo de desarrollo.
Los factores clave//que deben considerarse al planear la reutilización son://
1. El calendario de desarrollo para
El software Si
El software debe desarrollarse//rápidamente, usted debe tratar de reutilizar
Sistemas comerciales en vez de//Problema Explicación//
Costos crecientes//de
Mantenimiento//Si no está disponible el código fuente de un sistema o
Componente de software//de reutilización, entonces los costos de mantenimiento
Podrían ser superiores,//porque los elementos reutilizados del sistema pueden
Volverse cada vez más//incompatibles con los cambios del sistema.//Falta de
Apoyo//de herramientas//Algunas herramientas de software no apoyan el
Desarrollo con reutilización. Tal vez//sea difícil o imposible integrar dichas
Herramientas con un sistema de librería de//componentes. El proceso de software
Supuesto por dichas herramientas quizá no//tome en cuenta la reutilización.
Esto es particularmente cierto para herramientas//que dan apoyo a la ingeniería
De sistemas embebidos, aunque menos cierto para//herramientas de desarrollo
Orientadas a objetos.//Síndrome “no se inventó//aquí”//Algunos ingenieros de
Software prefieren rescribir los componentes, porque//consideran que pueden
Mejorarlos. Esto en parte tiene que ver con la confianza//y en parte con el
Hecho de que escribir software original se observa como más//desafiante que
Reutilizar el software de alguien más.//Creación, mantenimiento//y uso de una
Librería de//componentes//Suele ser costoso dotar a una librería de componentes
De reutilización y garantizar//que los desarrolladores de software puedan
Utilizar esta librería. Hay que adaptar//procesos de desarrollo para asegurar
Que se use la librería.//Descubrimiento,//comprensión y adaptación//de
Componentes de//reutilización//Deben descubrirse componentes de software en una
Librería, entenderse y, en//ocasiones, adaptarse para trabajar en un nuevo
Entorno. Los ingenieros deben estar//ampliamente seguros de encontrar un
Componente en la librería antes de incluir//una búsqueda de componentes como
Parte de su proceso de desarrollo normal.//Figura 16.2//
Problemas con//la reutilización//16.1 ■
Panorama de la
Reutilización 429//componentes
Individuales. Éstos son activos reutilizables de grano grueso. Aunque//el
Ajuste con los requerimientos tal vez sea imperfecto, este enfoque minimiza la//cantidad
De desarrollo requerido.//
2.
La vida esperada del software Si usted desarrolla un sistema de
Prolongada duración,//debe enfocarse en la capacidad de mantenimiento del
Sistema. No sólo debe//considerar los beneficios inmediatos de la
Reutilización, sino también las implicaciones//a largo plazo.//Durante su vida
útil, podrá adaptar el sistema a nuevos requerimientos, lo que significará//hacer
Cambios a partes del sistema. Si no tiene acceso al código fuente, es//preferible
Evitar los componentes COTS (véase la sección 16.4) y los sistemas de//proveedores
Externos, pues éstos tal vez no sean capaces de continuar con el servicio//de
Apoyo para el software de reutilización.//
3. Los antecedentes, las habilidades y la experiencia del equipo de
Desarrollo Todas//las
Tecnologías de reutilización son bastante complejas, y es necesario mucho//tiempo
Para entenderlas y usarlas de manera efectiva. Por consiguiente, si el equipo//de
Desarrollo tiene habilidades en un área particular, probablemente es ahí donde//deban
Enfocarse.//
4. La criticidad del software y sus
Requerimientos no funcionales Para un sistema//crítico que deba certificarse mediante un
Regulador externo, quizá deba crear un//caso de confiabilidad para el sistema
(como se estudió en el capítulo 15). Esto es//difícil si no tiene acceso al
Código fuente del software. Si su software cuenta con//requerimientos rigurosos
De rendimiento, tal vez sea imposible usar estrategias tales//como la
Reutilización basada en generador, donde el código se forma a partir de una//representación
De reutilización específica de dominio de un sistema. Estos sistemas//a menudo
Crean un código relativamente ineficiente.//
5. El dominio de aplicación En algunos dominios de aplicación, tales como los sistemas//de
Fabricación e información médica, existen muchos productos genéricos//que
Pueden reutilizarse al configurarlos para una situación local. Si trabaja en
Tal//dominio, siempre debe considerarlo como una opción.//Patrones//de diseño//Ingeniería
De software//basada en componentes//Frameworks//de aplicación//Sistemas
Orientados//al servicio//Integración//COTS//Líneas de producto//de software//Encadenamiento//de
Sistemas heredados//Librerías//de programa//Generadores//de programa//Desarrollo
De software//orientado a aspectos//Aplicaciones verticales//configurables//Patrones//arquitectónicos//Sistemas//ERP//Ingeniería
Dirigida//por modelo//Figura 16.3
Panorama//de reutilización//430
Capítulo 16 ■ Reutilización de software//
6. La plataforma en la que operará
El sistema Algunos
Modelos de componentes,//como .NET, se especifican para plataformas Microsoft.
De igual modo, sistemas//genéricos de aplicación pueden ser específicos de
Plataforma y sólo podrá reutilizarlos//si su sistema está diseñado para la
Misma plataforma.//Enfoque Descripción//
Patrones arquitectónicos Se usan arquitecturas de
Software estándar que apoyan tipos comunes//de sistemas de aplicación, tales
Como la base de las aplicaciones.//Se describen en los capítulos 6, 13 y 20.//Patrones
De diseño Las abstracciones genéricas que ocurren a través de las aplicaciones//se
Representan como patrones de diseño que muestran objetos e//interacciones
Abstractas y concretas. Se detallan en el capítulo 7.//Desarrollo basado//en
Componentes//Se desarrollan sistemas al integrar componentes (colecciones de//objetos)
Que se conforman a estándares de modelo de componentes.//Se estudian en el
Capítulo 17.//Frameworks de aplicación Colecciones de clases abstractas y
Concretas adaptadas y extendidas para//crear sistemas de aplicación.//Encadenamiento
De sistemas//heredados//Los sistemas heredados (véase el capítulo 9) se “enlazan”
Al definir un//conjunto de interfaces y proporcionar acceso a estos sistemas
Heredados//a través de dichas interfaces.//Sistemas orientados a servicios Se
Desarrollan sistemas mediante la vinculación de servicios compartidos,//que
Pueden proporcionarse externamente. Se tratan en el capítulo 19.//Líneas de
Producto de software Un tipo de aplicación se generaliza en torno a una
Arquitectura común,//de forma que pueda adaptarse para diferentes clientes.//Reutilización
De productos COTS Los sistemas se desarrollan al configurar e integrar sistemas
De aplicación//existentes.//Sistemas ERP Los sistemas a gran escala que
Encapsulan funcionalidad empresarial//genérica y reglas se configuran para una
Organización.//Aplicaciones verticales//configurables//Se diseñan sistemas
Genéricos de manera que puedan configurarse a las//necesidades específicas de
Clientes del sistema.//Librerías de programa Librerías de clase y función que
Implementan abstracciones de uso//común están disponibles para reutilización.//Ingeniería
Dirigida por modelo El software se representa como modelos de dominio y modelos//independientes
De implementación, y se genera un código a partir//de dichos modelos. Se
Refiere en el capítulo 5.//Generadores de programa Un sistema generador
Incrusta conocimiento de un tipo de aplicación//y se usa para generar sistemas
En dicho dominio a partir de un modelo//de sistema suministrado por el usuario.//Desarrollo
De software orientado//a aspectos//Cuando se compila el programa, los
Componentes compartidos se//hilvanan dentro de una aplicación en lugares
Diferentes. Se expone en//el capítulo 21.//Figura 16.4//
Enfoques que//apoyan la reutilización//de software//16.2 ■
Frameworks de aplicación
431//
La gama de técnicas disponibles
De reutilización es tal que, en la mayoría de las situaciones,//existe la
Posibilidad de cierta reutilización de software. Ya sea que se logre o//no la
Reutilización, con frecuencia es un conflicto administrativo más que técnico.
Los//administradores pueden estar ansiosos de comprometer sus requerimientos
Para permitir//el uso de componentes de reutilización. Es posible que no
Comprendan los riesgos//asociados con la reutilización, tanto como entienden
Los riesgos del desarrollo original.//Aunque los riesgos del desarrollo de
Nuevo software pueden ser elevados, algunos administradores//prefieren los
Riesgos conocidos a los desconocidos.//16.2 Frameworks de aplicación//
Los primeros entusiastas del
Desarrollo orientado a objetos sugerían que uno de los beneficios//clave de
Usar un enfoque orientado a objetos era que éstos pudieran reutilizarse en//diferentes
Sistemas. Sin embargo, la experiencia demostró que los objetos normalmente//son
Muy pequeños y están especializados para una aplicación particular. Entender y//adaptar
El objeto tarda más tiempo que volver a implementarlo. Ahora se ha vuelto claro
Que//la reutilización orientada a objetos tiene mejor apoyo en un proceso de desarrollo
Orientado a//objetos a través de abstracciones de grano más grueso, llamadas
Frameworks (estructuras).//Como sugiere el nombre, un framework es una
Estructura genérica que se extiende//para crear una aplicación o un subsistema
Más específico. Schmidt y sus colaboradores//(2004) definen un framework como://. . . Un conjunto integrado de
Artefactos de software (tales como clases, objetos y//componentes), que
Colaboran en la facilitación de una arquitectura de reutilización//para una
Familia de aplicaciones relacionadas.//Los frameworks brindan soporte para carácterísticas genéricas que
Es probable que//sean utilizadas en todas las aplicaciones de un tipo similar.
Por ejemplo, un framework//de interfaz de usuario ofrecerá soporte para manejo
De evento de interfaz, e incluirá un conjunto//de artilugios que pueden usarse
Para construir despliegues. Entonces se permite al//desarrollador especializar
éstos al agregar funcionalidad específica para una aplicación particular.//Por
Ejemplo, en un framework de interfaz de usuario, el desarrollador define
Plantillas//de despliegue adecuadas para la aplicación a implementar.//Los
Frameworks apoyan la reutilización de diseño en la que ofrecen una arquitectura//que
Sirve de esqueleto para la aplicación, así como la reutilización de clases
Específicas//Reutilización basada en generador//
La reutilización basada en
Generador consiste en incorporar conceptos y conocimiento reutilizables en//herramientas
Automatizadas, y ofrecer una forma sencilla de que los usuarios de la
Herramienta integren un//código específico con este conocimiento genérico. Por
Lo general, este enfoque es más efectivo en aplicaciones//específicas de
Dominio. Soluciones conocidas a los problemas en dicho dominio se incrustan en
El sistema//generador y el usuario las selecciona para crear un nuevo sistema.//http://www.SoftwareEngineering-9.Com/Web/Reuse/Generator.Html//432
Capítulo 16 ■
Reutilización de
Software//en el
Sistema. La arquitectura se define por las clases de objetos y sus
Interacciones. Las//clases se reutilizan directamente y pueden extenderse
Utilizando carácterísticas como la//herencia.//Los frameworks se implementan
Como una colección de clases de objetos concretos//y abstractos en un lenguaje
De programación orientado a objetos. Por lo tanto, los frameworks//son
Específicos del lenguaje. Existen frameworks disponibles en todos los lenguajes//de
Programación orientados a objetos de uso común (por ejemplo, Java, C#, C++,//así
Como lenguajes dinámicos como Ruby y Python). De hecho, un framework puede//incorporar
Muchos otros frameworks, cada uno de los cuales se diseña para soportar//el
Desarrollo de parte de la aplicación. Es posible usar un framework para crear
Una//aplicación completa o implementar parte de una aplicación, como la
Interfaz de usuario//gráfica.//Fayad y Schmidt (1997) analizan tres clases de
Frameworks://
1. Frameworks de infraestructura de
Sistema Dichos
Frameworks apoyan el desarrollo//de infraestructuras de sistema como
Comunicaciones, interfaces de usuario y//compiladores (Schmidt, 1997).//
2. Frameworks de integración de
Middleware Consisten en
Un conjunto de estándares//y clases de objetos asociados que soportan
Comunicación de componentes e//intercambio de información. Los ejemplos de este
Tipo de framework incluyen .NET//de Microsoft y Enterprise Java Beans (EJB).
Dichos frameworks brindan soporte//para modelos estandarizados de componentes,
Como se estudia en el capítulo 17.//
3. Frameworks
De aplicación empresarial Se ocupan de dominios de aplicación//específicos, tales como los
Sistemas de telecomunicaciones o financieros (Baumer//et al., 1997). El conocimiento del
Dominio de la aplicación integra y apoya el desarrollo//de aplicaciones de usuario
Final.//Los frameworks de aplicación Web (WAF) son un tipo de framework más
Reciente e//importante. Ahora los WAF, que apoyan la construcción de sitios Web
Dinámicos, están//ampliamente disponibles. La arquitectura de un WAF se basa
Por lo general en el patrón//compuesto Modelo-Vista-Controlador (MVC) (Gamma et al., 1995), que se muestra//en la
Figura 16.5.//El patrón MVC se propuso originalmente en la década de 1980, como
Un enfoque//al diseño GUI que permitía múltiples presentaciones de un objeto y
Separaba estilos//de interacción con cada una de estas presentaciones. Permite
La separación del estado de//Métodos del controlador Métodos de la vista//Entradas//de usuario//Ver
Mensajes//de modificación//Edición//del modelo//Consultas//y actualizaciones//del
Modelo//Estado del controlador Estado de la vista//Métodos del modelo//Estado
Del modelo//Figura
16.5
Patrón//Modelo-Vista-//Controlador//16.2 ■
Frameworks de aplicación
433//aplicación de la interfaz de
Usuario de la aplicación. Un framework MVC permite la presentación//de datos en
Diferentes formas y admite la interacción con cada una de dichas//presentaciones.
Cuando los datos se modifican a través de una de las presentaciones, se//modifica
El modelo del sistema y los controladores asociados con cada punto de vista//actualizan
Su presentación.//A menudo, los frameworks son implementaciones de patrones de
Diseño, como se estudió//en el capítulo 7. Por ejemplo, un framework MVC incluye
El patrón Observer, el//patrón Strategy, el patrón Composite y algunos otros
Que analizan Gamma y sus colaboradores//(1995). La naturaleza general de los
Patrones y su uso de clases abstractas y concretas//permite la extensibilidad.
Es casi seguro que, sin patrones, los frameworks serían poco//prácticos.//Los
Frameworks de aplicación Web incorporan regularmente uno o más frameworks//especializados
Que apoyen las carácterísticas específicas de aplicación. Aunque cada framework//incluye
Funcionalidad sutilmente diferente, la mayoría de los frameworks de//aplicación
Web soportan las siguientes carácterísticas://
1. Seguridad Los WAF pueden incluir clases para ayudar a implementar
Autenticación//de usuario (login) y el control de acceso para garantizar que
Los usuarios sólo//puedan tener acceso a la funcionalidad que permite el
Sistema.//
2. Páginas Web dinámicas Se ofrecen clases para ayudar a
Definir las plantillas de la//página Web y dotar dinámicamente a éstas con
Datos específicos de la base de datos//del sistema.//
3. Soporte de base de datos Los frameworks usualmente no
Incluyen una base de//datos, sino suponen que se usará una base de datos
Separada, como MySQL. El framework//puede proporcionar clases que ofrezcan una
Interfaz abstracta a diferentes//bases de datos.//
4. Gestión de sesíón Clases para crear y administrar
Sesiones (algunas interacciones//con el sistema por parte de un usuario) por lo
General son parte de un WAF.//
5. Interacción
De usuarios La
Mayoría de los frameworks Web brindan ahora soporte//AJAX (Holdener, 2008), que
Permite la creación de páginas Web más interactivas.//Para extender un
Framework no es necesario cambiar el código de éste. En vez de ello,//usted agrega
Clases concretas que heredan operaciones de clases abstractas en el framework.//Además,
Quizá deba definir callbacks (comunicaciones de regreso). Los callbacks//son
Métodos que se solicitan en respuesta a eventos reconocidos por el framework.//Schmidt
Y sus colaboradores (2004) llaman a esto “inversión de control”. Los objetos//framework,
Y no los objetos específicos de aplicación, son los responsables del control en//el
Sistema. En respuesta a eventos de la interfaz del usuario, base de datos,
Etcétera, dichos//objetos framework recurren a “métodos gancho” que entonces se
Vinculan a la funcionalidad//que proporciona el usuario. La funcionalidad
Específica de la aplicación responde//de una forma adecuada al evento (figura
16.6). Por ejemplo, un framework tendrá un//método que manipule un clic del
Ratón desde el entorno. Este método llama a un método//gancho, que usted debe
Configurar con la finalidad de llamar a los métodos de aplicación//adecuados
Para manejar el clic del ratón.//Las aplicaciones que se construyen utilizando
Frameworks pueden ser la base para una//posterior reutilización a través del
Concepto de líneas de producto de software o familias//434
Capítulo 16 ■
Reutilización de
Software//de
Aplicación. Puesto que dichas aplicaciones se construyen mediante un framework,
La//modificación de los miembros de la familia para crear instancias del
Sistema con frecuencia//es un proceso directo. Implica rescribir clases y
Métodos concretos que deberán//adicionarse al framework.//Sin embargo, los
Frameworks usualmente son más generales que las líneas de producto//de
Software, enfocadas en una familia específica de sistemas de aplicación. Por//ejemplo,
Es posible usar un framework basado en Web para construir diversos tipos de//aplicaciones
Basadas en Web. Uno de éstos podría ser una línea de productos de software//que
Soporte escritorios de ayuda basados en Web. Entonces esta “línea de productos//de
Escritorio de ayuda” puede especializarse aún más para ofrecer tipos
Particulares de//soporte de escritorio de ayuda.//Los frameworks son un enfoque
Efectivo a la reutilización, aunque costosos para introducirse//en procesos de
Desarrollo de software. Se consideran inherentemente complejos,//y aprender a
Usarlos es una actividad que tal vez dure muchos meses. También es posible//que
Sea difícil y costoso evaluar frameworks disponibles para elegir los más
Adecuados.//Depurar las aplicaciones basadas en frameworks resulta complicado,
Porque tal vez no se//comprenda cómo interactúan los métodos framework. Éste es
Un problema general con el//software de reutilización. Las herramientas de
Depuración pueden brindar datos sobre los//componentes del sistema de
Reutilización que un desarrollador no entiende.//16.3 Líneas de productos de
Software//
Uno de los
Enfoques más efectivos para la reutilización es la creación de líneas de
Productos//de software o familias de aplicación. Una línea de productos de
Software es un//conjunto de aplicaciones con una arquitectura común y
Componentes compartidos, con//cada aplicación especializada para reflejar
Diferentes requerimientos. El sistema central//se diseña para configurarse y
Adaptarse a las necesidades de los diferentes clientes del//sistema. Esto puede
Implicar la configuración de algunos componentes, implementar//componentes
Adicionales y modificar varios de los componentes de acuerdo con nuevos//requerimientos.//Clases específicas de
Aplicación//Base de datos Ciclo de//evento//Callbacks Callbacks//Callbacks//Plataforma
Ciclo de//evento//GUI Ciclo de//evento//Figura 16.6
Inversión//de control en//frameworks//16.3 ■
Líneas de productos de
Software 435//
Desarrollar
Aplicaciones mediante la adaptación de una versión genérica de la aplicación//significa
Que se reutiliza una alta proporción del código de aplicación. Además,//la
Experiencia de la aplicación muchas veces es transferible de un sistema a otro.
En//consecuencia, cuando los ingenieros de software se reúnen en un equipo de
Desarrollo, se//acorta su proceso de aprendizaje. Las pruebas se simplifican
Porque éstas también pueden//reutilizarse para gran parte de la aplicación, lo
Que en consecuencia reduce el tiempo//total del desarrollo de la aplicación.//Las
Líneas de producto de software surgen por lo general de aplicaciones
Existentes.//Esto es, una organización desarrolla una aplicación y, luego,
Cuando se requiere un sistema//similar, el código de ésta se reutiliza de
Manera informal en la nueva aplicación. El mismo//proceso se usa conforme se
Desarrollan otras aplicaciones similares. Sin embargo, el cambio//tiende a
Corromper la estructura de la aplicación, así que, a medida que se desarrollan//más
Instancias nuevas, se vuelve cada vez más difícil crear una nueva versión. Por
Consiguiente,//puede tomarse entonces una decisión para diseñar una línea de
Productos genéricos.//Esto implica identificar la funcionalidad común en instancias
De producto e incluirla//en una aplicación base, que después se usa para un
Desarrollo futuro. Esta aplicación base//se estructura deliberadamente para
Simplificar la reutilización y la reconfiguración.//Desde luego, los frameworks
De aplicación y las líneas de productos de software//tienen mucho en común.
Ambos soportan una arquitectura y componentes comunes, y//requieren un nuevo
Desarrollo para crear una versión específica de un sistema. Las principales//diferencias
Entre dichos enfoques son las siguientes://
1. Los frameworks de aplicación se apoyan en carácterísticas
Orientadas a objetos,//como herencia y polimorfismo, para implementar
Extensiones al framework. Por//lo general, el código framework no se modifica y
Las posibles modificaciones están//limitadas a lo que permite el framework. Las
Líneas de producto de software no//necesariamente se crean mediante un enfoque
Orientado a objetos. Los componentes//de aplicación cambian, se borran o
Rescriben. No hay límites, al menos en principio,//para que puedan realizarse
Cambios.//
2. Los frameworks de aplicación se
Enfocan principalmente en brindar apoyo técnico//antes que dominio específico.
Por ejemplo, existen frameworks de aplicación para//crear aplicaciones basadas
En Web. Una línea de productos de software por lo general//incrusta información
Detallada de dominio y de plataforma. Por ejemplo, podría//haber una línea de
Productos de software que se ocupe de aplicaciones basadas en//Web para la
Administración de registros de salud.//
3. Las
Líneas de producto de software generalmente son aplicaciones de control para//equipo.
Por ejemplo, puede haber una línea de productos de software para una familia//de
Impresoras. Esto significa que la línea de productos debe dar soporte para//interfaz
De hardware. Los frameworks de aplicación con frecuencia están orientados//al
Software, y pocas veces ofrecen soporte para interfaz de hardware.//
4. Las líneas de productos de
Hardware constituyen una familia de aplicaciones relacionadas,//propiedad de la
Misma organización. Cuando usted crea una nueva aplicación, su//punto de
Partida es habitualmente el miembro más cercano de la familia de aplicación,//no
La aplicación central genérica.//Si desarrolla una línea de productos de
Software usando un lenguaje de programación//orientado a objetos, en ese
Momento puede usar un framework de aplicación como base del//436
Capítulo 16 ■
Reutilización de
Software//sistema.
Usted crea el núcleo de la línea de productos al extender el framework con
Componentes//específicos de dominio, a través de sus mecanismos internos.
Entonces hay una//segunda fase de desarrollo, donde se crean versiones del
Sistema para diferentes clientes.//Pueden desarrollarse varios tipos de
Especialización de una línea de productos de//software://
1. Especialización de plataforma Se elaboran versiones de la
Aplicación para diferentes//plataformas. Por ejemplo, pueden existir versiones
De aplicación para plataformas//Windows, Mac OS y Linux. En este caso, la
Funcionalidad de la aplicación//por lo regular no cambia; sólo se modifican
Aquellos componentes que hacen interfaz//con el hardware y el sistema
Operativo.//
2. Especialización de entorno Se crean versiones de aplicación
Para manejar entornos//operacionales particulares y dispositivos periféricos.
Por ejemplo, un sistema para//los servicios de emergencia puede existir en
Diferentes versiones, dependiendo del//sistema de comunicaciones en los
Vehículos. En este caso, los componentes del sistema//cambian para reflejar la
Funcionalidad del equipo de comunicación utilizado.//
3. Especialización funcional Se crean versiones de aplicación
Para clientes específicos//que tengan diferentes requerimientos. Por ejemplo,
Un sistema de automatización//bibliotecario se podrá modificar en función de si
Se utiliza en una biblioteca//pública, una biblioteca de consulta o una
Biblioteca universitaria. En tal caso, es//posible variar los componentes que
Implementan la funcionalidad y agregar al sistema//nuevos componentes.//
4. Especialización de proceso El sistema se adapta para hacer
Frente a los procesos//empresariales específicos. Por ejemplo, un sistema de
Pedidos puede adaptarse para//enfrentarse con un proceso de pedidos
Centralizado en una compañía y con un proceso//distribuido en otra.//La
Arquitectura de una línea de productos de software con frecuencia refleja un
Estilo//o patrón arquitectónico general, específico para una aplicación. Por
Ejemplo, considere//un sistema de línea de productos que se diseñe con la
Finalidad de manejar salidas de//vehículos para servicios de emergencia. Los
Operadores de este sistema reciben las llamadas//de los incidentes, localizan
El vehículo adecuado para responder a la emergencia//y envían el vehículo al
Sitio del incidente. Los desarrolladores de tal sistema pueden//comercializar
Versiones de éste para los servicios de policía, bomberos y ambulancias.//Este
Sistema de envío de vehículos es un ejemplo de una arquitectura de gestión de//recursos
(figura 16.7). En la figura 16.8 se ejemplifica dicha estructura de cuatro
Capas, y//se muestran los módulos que es posible incluir en una línea de
Productos de sistemas de//envío de vehículos. Los componentes en cada nivel en
El sistema de línea de productos//son los siguientes://
1. A nivel de interacción, existen
Componentes que ofrecen una interfaz de pantalla de//operador y una interfaz
Con los sistemas de comunicaciones usados.//
2. A nivel de la gestión I/O (nivel 2), hay componentes que manejan
Autenticación//del operador, generan reportes de incidentes y vehículos
Enviados, permiten salida de//mapas y planeación de rutas, y ofrecen un
Mecanismo para que los operadores consulten//las bases de datos del sistema.//16.3 ■
Líneas de productos de
Software 437//3.
A nivel de gestión de recursos
(nivel 3) existen componentes que permiten la localización//y el envío de
Vehículos, componentes para actualizar el estatus de los vehículos//y el
Equipo, y un componente para registrar detalles de incidentes.//
4. A nivel de base de datos, además
Del apoyo de gestión de transacción usual, existen//bases de datos separadas de
Vehículos, equipo y mapas.//Interfaz de usuario//Rastreo//de recursos//Política de//control de
Recursos//Asignación//de recursos//Autenticación//de usuarios//Gestión//de
Consulta//Entrega//de recursos//Gestión de transacción//Base de datos de
Recursos//Interacción//Gestión I/O//Gestión de recursos//Gestión de base de
Datos//Figura
16.7//
Arquitectura
De un//sistema de asignación//de recursos//Autenticación//de operadores//Gestor
De estatus//de vehículos//Bitácora//de incidentes//Despachador//de vehículos//Gestor//de
Equipo//Localizador//de vehículos//Planeador de//mapas y rutas//Gestor//de
Consulta//Generador//de reportes//Interfaz del operador Interfaz de sistemas//de
Comunicaciones//Base de datos//de equipo//Base de datos de vehículos Base de
Datos de mapas//Figura 16.8
Gestión de transacción Bitácora de incidentes//Arquitectura de
Línea//de productos de un//sistema de envío//de vehículos//438
Capítulo 16 ■
Reutilización de
Software//Para crear
Una versión específica de este sistema, habrá que modificar los componentes//individuales.
Por ejemplo, la policía tiene un mayor número de vehículos, pero menor//número
De tipos de vehículos, mientras que los bomberos cuentan con muchos tipos de//vehículos
Especializados. En consecuencia, tal vez sea necesario definir una estructura//diferente
De base de datos de vehículos cuando se implemente un sistema para esos
Distintos//servicios.//La figura 16.9 muestra los pasos considerados en la
Extensión de una línea de productos//de software para crear una nueva
Aplicación. Tales pasos en este proceso general son los//siguientes://
1. Adquirir requerimientos de las
Partes interesadas Puede
Comenzar con un proceso//de ingeniería de requerimientos normal. Sin embargo,
Puesto que ya existe un sistema,//éste deberá comprobarse para luego hacer que
Los interesados lo experimenten//y expresen sus requerimientos como
Modificaciones a las funciones ofrecidas.//
2. Seleccionar el sistema existente que se ajuste más a los
Requerimientos Cuando
Se//crea un nuevo miembro de una línea de productos, puede comenzar con la
Instancia//más cercana al producto. Se analizan los requerimientos y se elige
Modificar al//miembro de la familia más cercano.//
3. Renegociar los requerimientos Conforme surgen más detalles de
Cambios requeridos//y el proyecto se planea, puede haber alguna renegociación
De requerimientos//para minimizar los cambios necesarios.//
4. Adaptar el sistema existente Se desarrollan nuevos módulos
Para el sistema existente,//y los módulos de sistema existentes se adaptan para
Cumplir con los nuevos//requerimientos.//
5. Entregar
Al nuevo miembro de la familia Se entrega al cliente la nueva instancia//de la línea de producto.
En esta etapa, usted debería documentar las carácterísticas//clave, de manera
Que pueda usarse en el futuro como base para otros desarrollos de//sistema.//Cuando
Usted crea un nuevo miembro de una línea de productos, es probable que//encuentre
Un compromiso entre reutilizar la mayor cantidad de aplicación genérica//posible
Y satisfacer los requerimientos detallados de las partes interesadas. Cuanto
Más//detallados sean los requerimientos del sistema, menos probabilidad tendrá
De que los//componentes existentes cumplan tales requerimientos. Sin embargo,
Si las partes interesadas//desean ser flexibles y limitar las modificaciones
Que requiera el sistema, por lo//general se podrá entregar el sistema más
Rápido y a menor costo.//Las líneas de productos de software se diseñan para
Reconfigurarse, y esta reconfiguración//puede implicar el agregar o eliminar
Componentes del sistema, definir parámetros y//Adquirir//requerimientos de//las partes
Interesadas//Elegir instancia//de sistema//más cercana//Entregar nueva//instancia
De sistema//Renegociar//requerimientos//Adaptar sistema//existente//Figura 16.9//
Desarrollo//de instancias//de
Producto//16.3 ■ Líneas de productos de software 439//restricciones para componentes del sistema, e incluir conocimiento
De procesos empresariales.//Esta configuración puede ocurrir en diferentes
Etapas en el proceso de desarrollo://
1. Configuración
A tiempo de diseño La
Organización que desarrolla el software//modifica una línea común de productos
Básicos mediante el desarrollo, la selección//o la adaptación de componentes
Para crear un nuevo sistema para el cliente.//
2. Configuración a tiempo de implementación Se diseña un sistema genérico
Para la//configuración por parte de un cliente o de algún consultor que trabaje
Con el cliente.//El conocimiento de los requerimientos específicos del cliente
Y el entorno operacional//del sistema se incrustan en un conjunto de archivos
De configuración que usa el//sistema genérico.//Cuando un sistema se configura
A tiempo de diseño, el proveedor comienza ya sea con//un sistema genérico o con
Una instancia de producto existente. Al modificar y extender//los módulos en
Este sistema se crea un sistema específico que entrega la funcionalidad//requerida
Por el cliente. Esto implica, por lo general, cambiar y extender el código
Fuente//del sistema, de manera que es posible mayor flexibilidad que con la
Configuración a//tiempo de implementación.//La configuración a tiempo de
Implementación supone usar una herramienta para crear//una configuración
Específica del sistema que se registre en una base de datos o como un//conjunto
De archivos de configuración (figura 16.10). El sistema en ejecución consulta//esta
Base de datos cuando se ejecuta, así que su funcionalidad puede especializarse
Para//su contexto de ejecución.//Existen muchos niveles de configuración en
Tiempo de implementación que un sistema//puede proveer://
1. Selección de componentes, donde
Se seleccionan los módulos en un sistema que//ofrecen la funcionalidad
Requerida. Por ejemplo, en un sistema de información de//pacientes, es posible
Seleccionar un componente de gestión de imagen que permita//vincular imágenes
Médicas (rayos X, tomografías, etcétera) con el registro médico//del paciente.//
2. Definición de flujo de trabajo y
Reglas, donde se definen los flujos de trabajo (cómo//se procesa la
Información, etapa por etapa) y reglas de validación que deben aplicarse//a la
Información que los usuarios ingresen o que genere el sistema.//Configuración de//la base de
Datos//Sistema de base de datos//Sistema genérico//Configuración de la//herramienta
De planeación//Figura 16.10//
Configuración//a tiempo de diseño//440
Capítulo 16 ■
Reutilización de
Software//
3. Definición de parámetros, donde
Se detallan los valores de parámetros específicos//del sistema, que reflejan la
Instancia de la aplicación que se crea. Por ejemplo, puede//especificarse la
Longitud máxima de los campos para la entrada de datos por parte de//un usuario
O las carácterísticas del hardware unido al sistema.//La configuración de la
Implementación a través de despliegue en pantalla puede ser//muy compleja, y la
Labor de configurar el sistema para un cliente tal vez tarde muchos//meses. Los
Grandes sistemas configurables pueden apoyar el proceso de configuración//al
Ofrecer herramientas de software, tales como herramientas de planeación de
Configuración,//para apoyar el proceso de configuración. En la sección 16.4.1
Se estudia con más//detalle la configuración de la implementación a través de
Despliegue en pantalla. Esto//cubre la reutilización de sistemas COTS que deben
Configurarse para trabajar en diferentes//entornos potenciales.//La
Configuración a tiempo de diseño se usa cuando es imposible utilizar las
Instalaciones//existentes de la configuración de implementación a través de
Despliegue en pantalla//en un sistema para desarrollar una nueva versión del
Sistema. Sin embargo, con el tiempo,//cuando se crean varios miembros de la familia
Con funcionalidad comparable, se puede//decidir si se refactoriza la línea
Central de productos para incluir funcionalidad que se haya//implementado en
Varios miembros de la familia de aplicación. Entonces se hace configurable//esta
Nueva funcionalidad cuando se implementa el sistema.//16.4 Reutilización de productos
COTS//
Un producto
COTS (por las siglas de Comercial-Off-The-Shelf ) es un sistema de software//que puede adaptarse a las necesidades
De diferentes clientes sin cambiar el código//fuente del sistema. Prácticamente
Todo el software de escritorio y una gran variedad de//productos del servidor
Son software COTS. Puesto que este software se diseña para uso//general,
Incluye regularmente muchas carácterísticas y funciones. Por consiguiente,
Tiene//el potencial de reutilización en diferentes entornos como parte de
Diversas aplicaciones.//Torchiano y Morisio (2004) descubrieron que los
Productos de código abierto se usaron a//menudo como productos COTS. Esto es,
Los sistemas abiertos se empleaban sin cambiar//ni observar el código fuente.//Los
Productos COTS se adaptan al usar mecanismos de configuración internos que//permiten
Que la funcionalidad del sistema se adecue a necesidades específicas del
Cliente.//Por ejemplo, en un sistema de registro de pacientes en un hospital,
Pueden definirse formatos//de entrada y reportes de salida separados para
Diferentes tipos de pacientes. Otras//carácterísticas de configuración permiten
Al sistema aceptar plug-ins que extiendan la//funcionalidad o comprueben las
Entradas del usuario para garantizar que son válidas.//Este enfoque para la
Reutilización del software se adoptó ampliamente en grandes//compañías durante
Los últimos 15 años, puesto que ofrece beneficios significativos sobre//el
Desarrollo de software personalizado://
1. Al
Igual que sucede con otros tipos de reutilización, es posible la implementación//más
Rápida de un sistema fiable.//16.4 ■ Reutilización de productos COTS 441//2.
Es
Posible ver qué funcionalidad ofrece la aplicación, de manera que es más fácil//juzgar
Si es probable que sea adecuada o no. Quizás otras compañías ya usen las//aplicaciones,
De manera que existen antecedentes de experiencia con el sistema.//
3. Se evitan algunos riesgos de
Desarrollo al usar software existente. Sin embargo, este//enfoque tiene sus
Propios riesgos, como se verá más adelante.//
4. Las empresas pueden enfocarse en su actividad central sin tener
Que dedicar muchos//recursos al desarrollo de sistemas TI.//
5. Conforme evolucionan las
Plataformas operativas, las actualizaciones de tecnología//se pueden
Simplificar, pues éstas son responsabilidad del proveedor del producto//COTS y
No del cliente.//Desde luego, este enfoque a la ingeniería de software entraña
Ciertos problemas://
1. Tienen que adaptarse los
Requerimientos para reflejar la funcionalidad y el modo de//operación del
Producto COTS. Esto puede conducir a cambios bruscos en los procesos//empresariales
Existentes.//
2. El producto COTS puede basarse en
Suposiciones que sean casi imposibles de//cambiar. Por lo tanto, el cliente
Debe adaptar su empresa para reflejar dichas suposiciones.//
3. Elegir el sistema COTS correcto
Para una empresa puede ser un proceso difícil,//en especial porque muchos
Productos COTS no están debidamente documentados.//Tomar la decisión equivocada
Podría ser desastroso, ya que tal vez sea imposible//hacer funcionar el nuevo
Sistema como se requiere.//
4.
Quizá no haya experiencia local
Para apoyar el desarrollo de los sistemas. En consecuencia,//el cliente deberá
Apoyarse en el proveedor y en consultores externos para//obtener consejos de
Desarrollo. Estos consejos podrían estar sesgados y dirigidos a//vender
Productos y servicios, y no a satisfacer las necesidades reales del cliente.//
5. Los proveedores de productos COTS
Controlan el soporte y la evolución del sistema.//Pueden salir del negocio,
Perder el control o incluso hacer cambios que ocasionen//dificultades a los
Clientes.//La reutilización de software basado en COTS cada vez se ha vuelto
Más común. La//vasta mayoría de los nuevos sistemas de procesamiento de
Información empresarial se//construyen ahora utilizando COTS, en vez de emplear
Un enfoque orientado a objetos.//Aunque con frecuencia hay problemas con este
Enfoque para el desarrollo de sistemas//(Tracz, 2001), las historias de éxito
(Baker, 2002; Balk y Kedia, 2000; Brownsword y//Morris, 2003; Pfarr y Reis,
2002) indican que la reutilización basada en COTS reduce el//esfuerzo y el
Tiempo para implementar el sistema.//Existen dos tipos de reutilización de
Productos COTS, a saber: sistemas de solución//COTS y sistemas integrados COTS.
Los primeros consisten en una aplicación genérica//de un solo proveedor que se
Configura de acuerdo con los requerimientos del cliente. Los//sistemas
Integrados COTS implican la integración de dos o más sistemas COTS (quizá//442
Capítulo 16 ■
Reutilización de
Software//de diferentes
Proveedores) para crear un sistema de aplicación. La figura 16.11 resume//las
Diferencias entre estos diferentes enfoques.//16.4.1 Sistemas de solución COTS//Los sistemas de solución COTS son
Sistemas de aplicación genéricos que pueden diseñarse//para dar apoyo a un tipo
De empresa particular, actividad empresarial o, en ocasiones,//a toda la
Empresa. Por ejemplo, es posible generar un sistema de solución COTS//para los
Dentistas que se encargue de registrar citas, llevar expedientes, programar
Llamadas//a pacientes, etcétera. A mayor escala, un sistema de Planeación de
Recursos//Empresariales (ERP, por las siglas de Enterprise Resource Planning) puede apoyar//todas las
Actividades de fabricación, pedidos y servicio de atención a clientes en una//compañía
Grande.//Los sistemas de solución COTS específicos de dominio, como los
Sistemas que brindan//apoyo a una función empresarial (por ejemplo, manejo de
Documentos), ofrecen la//funcionalidad que requieren algunos usuarios
Potenciales. Sin embargo, tales sistemas//incorporan también suposiciones
Internas acerca de cómo trabajan los usuarios, y esto//puede causar problemas
En situaciones específicas. Por ejemplo, un sistema que apoye en//la tarea de
Registrar a estudiantes en las universidades puede suponer que los estudiantes//se
Registrarán para obtener un grado determinado en una universidad. Sin embargo,
Si//varias universidades colaboran para ofrecer grados conjuntos, entonces será
Casi imposible//representar esto en el sistema.//Los sistemas ERP, como los
Producidos por SAP y BEA, son sistemas integrados a//gran escala, diseñados
Para dar apoyo a prácticas empresariales, tales como pedidos y//facturación,
Manejo de inventarios y fechas de producción (O’Leary, 2000). El proceso//de
Configuración para estos sistemas incluye la recopilación de información
Detallada//acerca de la empresa y los procesos empresariales del cliente, e
Incrustan esto en una//base de datos de configuración. Con frecuencia, ello
Requiere conocimiento detallado de//anotaciones y herramientas de
Configuración, y por lo general lo realizan consultores que//trabajan junto con
Los clientes del sistema.//Sistemas de solución COTS Sistemas COTS integrados//
Un solo producto que ofrece
La funcionalidad//requerida por un cliente.//Muchos productos heterogéneos de
Sistema se//integran para ofrecer funcionalidad personalizada.//Basados en una
Solución genérica y procesos//estandarizados.//Pueden desarrollarse soluciones
Flexibles para//procesos del cliente.//El desarrollo se enfoca en la configuración//del
Sistema.//El desarrollo se enfoca en la integración del sistema.//El proveedor
Del sistema es responsable//del mantenimiento.//El dueño del sistema es
Responsable del//mantenimiento.//El proveedor del sistema ofrece la plataforma//para
El sistema.//El dueño del sistema ofrece la plataforma para el//sistema.//Figura 16.11//
Sistemas de//solución COTS//y
COTS integrados//16.4 ■ Reutilización de productos COTS 443//
Un sistema ERP genérico contiene algunos módulos que pueden
Componerse en//diferentes formas con la finalidad de crear un sistema para un
Cliente. El proceso de//configuración implica elegir cuáles módulos deben
Incluirse, configurar dichos módulos//individuales, definir los procesos y las
Reglas empresariales, y definir la estructura//y organización de la base de
Datos del sistema. En la figura 16.12 se presenta un//modelo de la arquitectura
Global de un sistema ERP que apoya algunas funciones//empresariales.//Las
Carácterísticas clave de esta arquitectura son://
1. Algunos módulos para dar apoyo a
Diferentes funciones empresariales. Estos módulos//de grano grueso pueden
Apoyar a departamentos o divisiones enteros de la//empresa. En el ejemplo que
Se señala en la figura 16.12, los módulos seleccionados//para su inclusión en
El sistema son: un módulo que apoya las compras, un módulo//que apoya la
Gestión de la cadena de abastecimiento, un módulo logístico que apoya//la
Entrega de bienes, y un módulo de gestión de atención al cliente (CRM, por las//siglas
De Customer Relationship Management) para mantener información sobre
La//clientela.//
2. Un conjunto definido de procesos
Empresariales, asociados con cada módulo, que se//relaciona con actividades en
Dicho módulo. Por ejemplo, puede haber una definición//del proceso de pedidos
Que especifique cómo crear y aprobar los pedidos. Esto precisará//los roles y
Las actividades implicados en el levantamiento de pedidos.//
3. Una base de datos común que
Mantiene información acerca de todas las funciones//empresariales relacionadas.
Esto significa que no debe ser necesario duplicar la//información, como los
Detalles de un cliente, en diferentes partes de la empresa.//
4. Un conjunto de reglas
Empresariales que se aplican a todos los datos en la base de//datos. Por lo
Tanto, cuando se ingresan datos desde una función, dichas reglas deben//garantizar
Que esto es consistente con los datos requeridos por otras funciones.//Por
Ejemplo, tal vez exista una regla empresarial que establece que alguien de
Mayor//jerarquía que la persona que hace la solicitud debe aprobar todas las
Solicitudes de//gastos.//Los sistemas ERP se usan casi en todas las grandes
Compañías para apoyar algunas//o todas sus funciones. Por consiguiente, se
Trata de una forma de reutilización de//Base de datos del sistema//Reglas empresariales//Compras//Procesos//Cadena
De//abastecimiento//Procesos//Logística//Procesos//CRM//Procesos//Figura 16.12//
Arquitectura de//un sistema
ERP//444
Capítulo 16 ■
Reutilización de
Software//software
Ampliamente difundida. No obstante, la limitación evidente de este enfoque a//la
Reutilización es que la funcionalidad del sistema se restringe a la
Funcionalidad del//núcleo genérico. Más aún, los procesos y las operaciones de
Una compañía tienen que//expresarse en el lenguaje de configuración del
Sistema, y puede haber desajuste de concordancia//entre los conceptos en la
Empresa y los conceptos incluidos en el lenguaje de//configuración.//Por
Ejemplo, en un sistema ERP que se vendíó a una universidad, debía definirse el//concepto
De cliente. Esto causó grandes dificultades cuando se configuró el sistema. Sin//embargo,
Las universidades tienen múltiples tipos de clientes, como estudiantes,
Agencias//que patrocinan investigaciones, instituciones que proveen fondos
Educativos, etcétera,//cada uno de los cuales posee diferentes carácterísticas.
Ninguno de ellos es realmente//comparable a la noción de un cliente comercial
(esto es, una persona o empresa que//adquiere productos o servicios). Una
Discordancia seria entre el modelo empresarial//usado por el sistema y el del
Comprador del sistema hace altamente probable que el sistema//ERP no cumpla con
Las necesidades reales del comprador (Scott, 1999).//Tanto los productos de
Dominio específico COTS como los sistemas ERP por lo general//requieren de una
Extensa configuración para adaptarlos a los requerimientos de cada//organización
Donde se instalan. Esta configuración puede implicar://
1. Seleccionar la funcionalidad
Requerida del sistema (por ejemplo, al decidir qué//módulos deben incluirse).//
2. Establecer un modelo de datos que
Defina cómo se estructurarán los datos de la organización//en la base de datos
Del sistema.//
3. Definir las reglas empresariales
Que se aplican a dichos datos.//
4. Definir
Las interacciones esperadas con sistemas externos.//
5. Diseñar los formatos de entrada y
Los reportes de salida generados por el sistema.//
6. Diseñar nuevos procesos
Empresariales que se conformen al modelo de proceso subyacente//apoyado por el
Sistema.//
7. Establecer parámetros que definan
Cómo se implementará el sistema en su plataforma//subyacente.//Una vez
Completados los escenarios de configuración, el sistema de solución COTS//está
Listo para las pruebas. Las pruebas son un gran problema cuando los sistemas se
Configuran//en vez de programarse con un lenguaje convencional. Puesto que
Dichos sistemas//se construyen mediante una plataforma fiable, las fallas y
Caídas evidentes del sistema//son relativamente excepcionales. Más bien, los
Problemas con frecuencia son sutiles y se//relacionan con las interacciones
Entre los procesos operacionales y la configuración del//sistema. Esto sólo
Puede ser detectable por parte de los usuarios finales y, por lo tanto,//tal vez
Pase inadvertido durante el proceso de pruebas del sistema. Además, no pueden//usarse
Las pruebas automatizadas de unidad, apoyadas por los frameworks de pruebas//como
JUnit. Es improbable que el sistema subyacente soporte algún tipo de
Automatización//de pruebas, y es posible que no haya especificación completa
Del sistema que pueda//usarse para derivar pruebas del sistema.//16.4 ■
Reutilización de
Productos COTS 445//
16.4.2 Sistemas COTS integrados//Los sistemas COTS integrados son aplicaciones que
Incluyen dos o más productos COTS//o, en ocasiones, sistemas de aplicación
Heredados. Usted podrá usar este enfoque cuando no//existan sistemas COTS
Individuales que cumplan todas sus necesidades, o cuando quiera//integrar un
Nuevo producto COTS con los sistemas que ya utiliza. Los productos COTS//pueden
Interactuar a lo largo de sus interfaces de programación de aplicación (API,
Por//las siglas de Application
Programming Interfaces)
O interfaces de servicio si están definidas.//Alternativamente, pueden
Componerse al conectar la salida de un sistema a la entrada//de otro o al
Actualizar las bases de datos usadas por las aplicaciones COTS.//Para
Desarrollar sistemas usando productos COTS, debe hacer algunas elecciones de//diseño://
1. ¿Cuáles productos COTS ofrecen
Funcionalidad más adecuada? Por lo general,//habrá varios productos COTS disponibles, que
Pueden combinarse en diferentes//formas. Si aún no tiene experiencia con un
Producto COTS, tal vez le resulte difícil//decidir cuál producto es el más
Adecuado.//
2. ¿Cómo se intercambiarán los
Datos? Por lo
General, diferentes productos usan//estructuras y formatos de datos únicos.
Usted tendrá que escribir adaptadores que//conviertan de una representación a
Otra. Dichos adaptadores son sistemas a tiempo//de ejecución que operan junto
Con los productos COTS.//
3.
¿Qué carácterísticas de un
Producto se usarán realmente? Los productos COTS//tal vez incluyan más funcionalidad de la
Necesaria, y la funcionalidad puede duplicarse//a través de diferentes
Productos. Usted tendrá que decidir cuáles carácterísticas//y en cuál producto
Son las más adecuadas para sus requerimientos. Si es posible, también//debe
Negar acceso a la funcionalidad no utilizada, porque esto podría interferir//con
La operación normal del sistema. La falla del primer vuelo del cohete Ariane 5//(Nuseibeh,
1997) fue consecuencia de un problema en un sistema de navegación inercial//del
Sistema Ariane 4 que se reutilizó. Sin embargo, la funcionalidad que falló no//se
Requería en realidad en el Ariane 5.//Considere el siguiente escenario como una
Ilustración de la integración COTS. Una//gran organización pretende desarrollar
Un sistema de compras que permita al personal//realizar pedidos desde su
Escritorio. Al introducir este sistema en la organización,//la compañía estima
Que puede ahorrar cinco millones de dólares al año. Al centralizar las//compras,
El nuevo sistema de adquisición puede garantizar que los pedidos siempre se//realicen
Desde proveedores que ofrecen los mejores precios, y que se reduzcan los costos//de
Papeleo asociados con los pedidos. Como sucede con los sistemas manuales, el
Sistema//implica elegir los bienes disponibles de un proveedor, planear un
Pedido, aprobarlo,//enviar la solicitud a un proveedor, recibir los bienes y
Confirmar el pago.//La compañía tiene un sistema de pedidos heredado que se
Utiliza en una oficina//central de compras. Este software de procesamiento de
Pedidos está integrado con un//sistema existente de facturación y entrega. Para
Crear el nuevo sistema de pedidos,//el sistema heredado se integra con una
Plataforma de comercio electrónico basada en//Web y un sistema de correo
Electrónico que maneje las comunicaciones con los usuarios.//446
Capítulo 16 ■
Reutilización de
Software//En la figura
16.13 se muestra la estructura final del sistema de compras, construida usando//COTS.//Este
Sistema de compras se basa en cliente-servidor y, en el lado del cliente, se
Usa//navegación Web y software de correo electrónico estándar. En el servidor,
La plataforma//de comercio electrónico debe integrarse con el sistema de
Pedidos existente a través de//un adaptador. El sistema de comercio electrónico
Tiene su propio formato para los pedidos,//confirmaciones de entrega, etcétera,
Y éstos se convierten en el formato que usa//el sistema de pedidos. El sistema
De comercio electrónico utiliza el sistema de correo electrónico//para enviar
Notificaciones a los usuarios, pero el sistema de pedidos nunca se diseñó//para
Ello. Por lo tanto, debe escribirse otro adaptador para convertir las
Notificaciones del//sistema de pedidos en mensajes de correo electrónico.//Es
Posible ahorrar meses, a veces años, de esfuerzo de implementación, y el tiempo//de
Desarrollo e implementación de un sistema puede reducirse drásticamente usando
Un//enfoque COTS integrado. El sistema de compras descrito anteriormente se
Implementó//y desplegó en una compañía muy grande en nueve meses, en vez de los
Tres años que se//requerirían, de acuerdo con las estimaciones, para
Desarrollar el sistema en Java.//La integración COTS puede simplificarse al
Usar un enfoque orientado a servicios. En//esencia, un enfoque orientado a
Servicios significa permitir el acceso a la funcionalidad//del sistema de
Aplicación mediante una interfaz de servicio estándar, con un servicio//para
Cada unidad discreta de funcionalidad. Algunas aplicaciones pueden ofrecer una//interfaz
De servicio, pero, en ocasiones, ésta debe implementarse mediante el integrador//de
Sistema. En esencia, debe programarse una capa (wrapper) que oculte la aplicación//y
Ofrezca servicios claros en el exterior (figura 16.14). Este enfoque es valioso
En particular//para los sistemas heredados que deben integrarse con sistemas de
Aplicación más//recientes.//En principio, la integración de los productos COTS
Es igual que la integración de cualquier//otro componente. Deben entenderse las
Interfaces del sistema y usarlas de forma//exclusiva para comunicarse con el
Software; habrá que negociar requerimientos específicos//contra desarrollo
Rápido y de reutilización, y diseñar una arquitectura de sistema que//permita a
Los sistemas COTS operar en conjunto.//Sin embargo, el hecho de que tales
Productos por lo regular sean sistemas grandes por//derecho propio, y que se
Vendan con frecuencia como sistemas independientes, entraña//Cliente//
Navegador Web Sistema de
Correo electrónico//Servidor//
Sistema de//comercio electrónico//Sistema de//Adaptador pedido y
Facturación//Figura 16.13
Sistema Sistema de correo electrónico Adaptador//de procuración
COTS//integrado//16.4 ■ Reutilización de productos COTS 447//problemas adicionales. Boehm y Abts (1999) examinan cuatro
Problemas importantes de//la integración de sistemas COTS://
1. Falta de control sobre la
Funcionalidad y el rendimiento Aunque la interfaz publicada//de un producto indique que ofrece
Las facilidades requeridas, éstas tal vez//no se implementen de manera adecuada
O se desempeñen mínimamente. El producto//podría tener operaciones ocultas que
Interfieran con su uso en una situación//específica. Corregir dichos problemas
Puede ser una prioridad para el integrador//de productos COTS, pero tal vez no
Sea una preocupación real para el proveedor del//producto. Es posible que los
Usuarios simplemente tengan que encontrar una solución//a los problemas si
Quieren reutilizar el producto COTS.//
2. Problemas
Con la interoperabilidad del sistema COTS A veces es difícil hacer//que los productos COTS
Funcionen en conjunto, porque cada producto establece sus//propias suposiciones
Sobre cómo se utilizará. Garlan y sus colaboradores (1995), al//reportar su
Experiencia para tratar de integrar cuatro productos COTS, descubrieron//que
Tres de estos productos se basaban en eventos, pero cada uno usaba un modelo//diferente
De eventos. Cada sistema supuso que tenía acceso exclusivo a la cola de//eventos.
En consecuencia, la integración fue muy difícil. El proyecto requirió cinco//veces
Más de esfuerzo que el que se pronosticó originalmente. La fecha de entrega//se
Extendíó a dos años en lugar de los seis meses previstos. En un análisis
Retrospectivo//de su trabajo 10 años después, Garlan y sus colaboradores (2009)
Concluyeron//que no se habían resuelto los problemas de integración
Descubiertos. Torchiano y//Morisio (2004) encontraron que la falta de
Cumplimiento con los estándares en algunos//productos COTS significaba que la
Integración era más difícil que lo esperado.//
3. Ningún control sobre la evolución del sistema En respuesta a presiones del
Mercado,//los proveedores de productos COTS toman sus propias decisiones acerca
De//cambios al sistema. En particular para productos PC, se generan a menudo
Nuevas//versiones, aunque tal vez no sean compatibles con todas las versiones
Anteriores.//Las nuevas versiones pueden tener funcionalidad adicional no
Deseada, y las versiones//anteriores podrían quedar fuera de disposición y no
Recibir servicios de apoyo.//
4.
Soporte de los proveedores COTS El nivel de soporte disponible de
Los proveedores//COTS varía ampliamente. El servicio de soporte del proveedor
Es específicamente//importante cuando surgen problemas, pues los
Desarrolladores no tienen//acceso al código fuente ni a la documentación
Detallada del sistema. Aunque quizá//Sistema//de aplicación//Capa de servicio//Servicios
Servicios//Figura
16.14
Capas//de
La aplicación//448
Capítulo 16 ■ Reutilización de software//los proveedores se comprometan a brindar servicios de asesoría,
Tanto el mercado//cambiante como las circunstancias económicas podrían
Dificultar el cumplimiento//de este compromiso. Por ejemplo, un proveedor de
Sistemas COTS tal vez decida discontinuar//un producto debido a una demanda
Limitada, o quizás otra firma tome el control//de la compañía proveedora y no
Quiera dar servicios de apoyo a los clientes que//adquirieron ciertos
Productos.//Boehm y Abts suponen que, en muchos casos, el costo de
Mantenimiento y evolución//del sistema es mayor para los sistemas COTS
Integrados. Todas las dificultades anteriores//son problemas del ciclo de vida
Que no sólo afectan el desarrollo inicial del sistema.//Cuanto mayor sea el
Número de personas implicadas en el mantenimiento del sistema que//se distancie
De los desarrolladores originales del sistema, más probable será que surjan//dificultades
Reales con los productos COTS integrados//
