6. CONCLUSIONES

Douglas (2006) lleva a cabo un análisis de diversos problemas relacionados con la ingeniería de software, de cuyas soluciones pueden obtenerse conclusiones aplicables al área del diseño instruccional. Entre dichos problemas menciona la falta de confianza que ciertos desarrolladores muestran a la hora de reutilizar componentes que no han sido desarrollados por ellos mismos, y la percepción de que en muchas ocasiones el esfuerzo asociado a la adaptación de componentes a un nuevo contexto pueden resultar mayores que la construcción de uno nuevo desde cero. Esta situación es en gran medida extrapolable al área de la ingeniería instruccional.

De igual forma que en el mundo de software el concepto de patrón está ganando popularidad como método para reutilizar no un componente ya construido sino el  conocimiento de diseño requerido para su construcción, la reutilización del conocimiento relacionado con el diseño instruccional puede ser alcanzada mediante el uso de patrones. Disponer de un catálogo de patrones abstractos, que pueden ser aplicados en una amplia gama de dominios, y que han sido construidos a partir de las experiencias comunes de la comunidad de educadores, puede resultar un recurso inestimable a la hora de construir nuevos diseños, más aún si dichos patrones además de describir pares de problemas-solución incluyen referencias a estudios empíricos que respalden la solución propuesta. En este sentido, en este documento se aboga por la utilización de patrones de distintos dominios de diseño, en tanto en cuanto nuestros sistemas de e-learning son también sistemas multiperspectiva.

No obstante, la decisión de utilizar o no un patrón no es tan inmediata ni sencilla como podría parecer a primera vista, especialmente si se empiezan a mezclar patrones de diversos dominios de diseño. Es muy probable que la aplicación de un patrón tenga un coste en esfuerzo y que, además, afecte negativamente en la consecución de otros objetivos de diseño. Es cierto que al realizar un sistema de e-learning son muchos los objetivos a alcanzar, pero no es menos cierto que cualquier proyecto tiene unas limitaciones presupuestarias y temporales y que, en la mayoría de los casos, hay que sacrificar algunos objetivos en aras de conseguir un producto final de la forma más efectiva posible. Sin embargo, cuando se utilizan los patrones tal y como aquí los hemos visto, el diseñador no es consciente del avance que está haciendo en las metas del sistema, no sabe qué metas se están cumpliendo y cuáles se están dejando atrás, por lo que se corre el riesgo de construir un sistema reutilizando conocimiento pero no cumpliendo con las expectativas iniciales que se tenían sobre el mismo. Por ello, la adopción de patrones debe pasar por un proceso integrado, en el que los patrones estén ligados a conseguir unas metas y a sus prioridades, y en el que sea posible estimar el coste de aplicar los patrones así como el avance en el proyecto, ya que de este modo se corre el riesgo de profundizar en exceso en funcionalidades que tal vez no sean las que van a definir la “cualidad sin nombre” de nuestro sistema de e-learning.