Continuando con el último post referente a la reutilización de software hablare sobre algunas desventajas que suelen ocurrir cuando se busca la reutilización de software. Estas desventajas deberían ser consideradas antes de crear y]/o utilizar un componente o servicio reutilizable.

Eficiencia o Rendimiento

La creación de componentes o servicios de uso general puede afectar algún día la eficiencia (rendimiento, utilización de recursos, etc.). Por ejemplo, si consideramos una clase Tiempo de de uso general que es utilizada para convertir fechas. Está claro que una Clase Conversión es una clase mucho más eficiente para este tipo de operaciones. Sin embargo, la clase Conversión no puede ser reutilizada para ningún otro objetivo, como por ejemplo que sea utilizada para el almacenamiento de Fechas a una Base de Datos. En algunos casos, este problema puede ser solucionado usando la especialización, lo que significa crear tanto el componente general como los componentes separados para casos excepcionales. En el ejemplo anterior, esto significa la creación de una clase Tiempo para el almacenamiento de Fechas y una Clase de propósito general de Conversiones. En algunos casos las características generales provocan inconvenientes o limitantes en el buen rendimiento o desempeño. Por ejemplo podemos estar utilizando una herramienta que optimice enormemente los recursos para un sistema operativo (Windows Vista y SQL Server 2005 por ejemplo) y el hecho de hacer un componente lo más genérico posible (soporte para Access, SQL 2000, Windows 98 y Windows 2000) podríamos estar desperdiciando características importantes que nos de una versión reciente de un producto o sistema operativo. Cuando la eficiencia drástica es necesaria (p.ej. tiempo real, procesos de altos volúmenes y tiempo de respuesta cortos), habría que considerar con cuidado si el crear o usar un componente de propósito general podría ser perjudicial para los requerimientos de eficiencia y rendimiento.

Tamaño del código

En algunas aplicaciones (Por ejemplo aplicaciones de tiempo real o aplicaciones móviles) el tamaño de código es significativo. En estos casos usando un componente reutilizable de uso general que es normalmente más grande que una simple tarea del componente podría ser problemático. Las restricciones de tamaño de código pueden forzar la creación de componentes específicos y no reutilizables. Por lo tanto, soluciones donde el tamaño de código es importante se debe considerar con cuidado la utilización de elementos reutilizables antes de comenzar un proyecto.

Generalidad innecesaria

Los componentes o servicios que deben implementar grandes conjuntos de requerimientos por lo general contienen grandes conjuntos de funciones y una interfaz grande. Algunos nuevos usuarios pueden necesitar sólo una pequeña fracción del conjunto de la funcionalidad del componente o servicio a utilizar. Existe una carga de trabajo elevada relacionada a la utilización, implementación, configuración y desarrollo de un componente o servicio reutilizable, que es necesario a fin de usar el componente o servicio correctamente. En estos casos, habría que pensar poner en práctica solo la funcionalidad necesaria y no usar el componente o servicio. Los componentes que no son cohesivos pueden tener partes innecesarias para cualquier usuario y ser inservibles.

Adicionar generalización

En la fase de requerimientos más personas están siendo entrevistadas y trabajo extra es añadido para incluir todos los requerimientos. En la fase de diseño un esfuerzo es hecho para hacer el componente independiente al ambiente y diseñar un componente de propósito general.

Documentación adicional

En cada fase del proceso de desarrollo una documentación detallada debe ser escrita. Los Requerimientos y los documentos de diseño deben cumplir con estándares altos, el código debe ser bien documentado, el manual de usuario y la guía de Desarrollo deben ser creados. Existe más documentación que la creada en un proceso de desarrollo regular.

Pruebas adicionales

Un mayor esfuerzo debe ser invertido en la fase de pruebas. Algunos componentes o servicios pueden ser candidatos a pruebas de exactitud el cual es un proceso caro; otros componentes deben ser probados para muchos posibles usos y escenarios. Existen más pruebas que deben ser aplicadas a un componente o servicio reutilizable que las generadas en un proceso de desarrollo regular.

Soporte y Mantenimiento de las librerías

Cuando el componente o servicio está listo debería ser insertado dentro de un Repositorio para el control de versiones. Esta tarea puede incluir la preparación de documentos especiales, llenando de formas, definir el nombre del componente y más. Cuando el componente está ya en el Repositorio los creadores deben esperar contestar preguntas, reparar defectos, obtener peticiones de cambios, añadir requerimientos y más.

Adicional a estas observaciones hay que evaluar si el componente o servicio reutilizable cumplirá con las siguientes características:

• El costo de crear el componente reutilizable.
• El número de veces que el componente o servicio será usado.
• El costo de crear componentes o servicios no reutilizables con la funcionalidad necesaria en cada proyecto donde el componente o servicio reutilizable pudo ser usado.
• El número esperado de veces que el componente será reutilizado en el futuro

VS

Como vemos el proceso de reutilización de software no es una actividad trivial, ya que involucran esfuerzos y costos que deben ser tomados en cuenta, pero que sabiéndolos utilizar en el proceso y proyecto adecuados son una parte importante para la reducción de costos y tiempos en procesos de desarrollo de software.