el blog de ​​perseguido

Cada proyecto necesita una fase de inicialización en la que planificar los recursos necesarios, seleccionar las tecnologías y metodologías, etc,. Entre estas opciones también juega un papel secundario, el modelo de desarrollo que se adopten.

La experiencia personal y lecturas (el resultado de la experiencia de otros) pueden ayudar a configurar correctamente este aspecto crucial de cada proyecto.

Hace unos tres años, con otros dos amigos, hemos creado un estilo de proyecto web 2.0: un agregador semántico de los flujos de información (RSS y más) con un sistema de clasificación basado esencialmente en el etiquetado de los contenidos.

Entre las noches, los sábados y domingos pasaban escribir código, la interminable lluvia de ideas entre la pizza y la cerveza, los Scazzi y momentos de euforia, esa experiencia se ha caracterizado por una extraordinaria intensidad profesional y humano que ha ido más allá de los límites del proyecto .

La arquitectura del sistema consta de tres componentes diferentes inter-operar. A nivel tecnológico, era fácil de identificar como la solución óptima para desacoplar los componentes realizados por cada uno, la definición de las interfaces de comunicación entre los tres subsistemas, mientras que una de las principales dificultades que enfrentan consistió en compartir un modelo de desarrollo y la organización de ciclo de vida del proyecto.

La necesidad de la experimentación en el alto nivel de innovación característico del proyecto sugiere un enfoque flexible que permita un control continuo de las decisiones tomadas, por otro lado, la inevitable-sincronía con la que se adelanta la evolución requiere la definición de un diseño que fue común (aunque sujetos a cambios frecuentes y radicales) que era una guía para la aplicación de cada parte y se garantizaría la unidad de propósito. Como en la mejor tradición de la filosofía oriental, el caos creativo y la producción de orden seguido enfrentándose entre sí y (s) para equilibrar el conjunto del proyecto.

La pregunta, que ha sobrevivido a este proyecto, si estas demandas son inherentemente irreconciliables o si hay herramientas y modelos de producción capaces de garantizar la velocidad de ejecución y la reprogramación frecuente de un diseño de proyecto definido.

No creo que hay una respuesta universal a esta pregunta, sin embargo, es posible identificar algunos tipos de solución.

Las respuestas "clásico" de la ingeniería de software se denominan modelo / prototipo y desarrollo basado en componentes iterativo. Estos enfoques, sin embargo, se prestan muy bien para resolver casos específicos de los problemas ya conocidos con soluciones que son en gran medida preenvasados ​​(tanto en los componentes de la interfaz en la que los algoritmos aprobados). En cuanto a la velocidad, la artesanía, esto depende mucho de la disponibilidad y calidad de los componentes reutilizables, mientras que en lo que respecta a la flexibilidad en la reestructuración del diseño del proyecto, esto depende en gran medida de las tecnologías elegidas (de su uso correcto) y el IDE utilizado para ensamblar componentes. El resultado de este modelo de producción termina pareciéndose mucho a la creación de un prototipo (que será definitivo en su segunda o tercera versión, aunque no necesariamente exhaustiva en sus requisitos iniciales) se centró en los componentes de que era posible reunir.

Un enfoque alternativo que proporciona más flexibilidad es la de Ingeniería Dirigida por Modelos (o sus variantes, tales como el Model Driven Architecture de la OMG) en la que se coloca el foco del proceso de aplicación en el diseño del proyecto (modelo) del sistema definido de acuerdo con el requerimiento del negocio expresada . El sistema se realiza a través de la adopción de una serie de opciones de implementación aplicados a los diferentes componentes del modelo dibujado: proceso de esta forma de realización puede ser diseñado como una cadena de transformaciones del modelo inicial que integran y refinar el requisito de negocio para implementar el software del sistema (Business Driven Development). La velocidad ejecutivo consiste en la generación de aplicación automática o semi-automática del modelo, mientras que la flexibilidad está dada por la facilidad de manipulación del modelo del sistema con respecto a su aplicación (que se ajusta en un sistema automático o semi-automático) con el fin de satisfacer fácilmente los remodulations requisitos.

Una de las técnicas más simples para aplicar dicho proceso de transformación consiste en el uso de plantillas de código se aplican a los metadatos que describen formalmente el modelo del sistema. Muchos hogares UML (ex. StarUML , Enterprise Architect , etc.) estas plantillas le permiten definir el producto, así como para ampliar su metamodelo para integrar la información necesaria para la generación automática de código.

La automatización del proceso de transformación de modelos, además de reducir drásticamente el tiempo de codificación dejando más espacio para el modelado de sistemas y la identificación de las soluciones más adecuadas implementative, garantiza las aplicaciones de arranque de la línea de las mismas soluciones en todo el implementative el proyecto. En la misma funcionalidad implementada la carga de trabajo (así como el profesionalismo requiere) mueve superior en las primeras etapas del ciclo de desarrollo (análisis y diseño), la pista de desarrollo se descarga tareas de codificación más repetitivos (aplicación Patttern estereotipada) a para el estudio de soluciones tecnológicas y la aplicación de algoritmos y componentes para los que no es posible o conveniente para proporcionar para una generación automática de código.

La aplicación de este modelo de producción es muy útil también en el contexto de la realización, en poco tiempo, los prototipos de trabajo, cuando ya tiene plantillas y herramientas para el análisis y diseño probado. Con un entorno de demostración preconfigurado y las herramientas adecuadas se pueden realizar en pocos días (u horas) toda una iteración del diseño de la formulación de un simple requisito para la realización de un sistema que implementa la funcionalidad principal. Las actividades de demostración de este tipo también se pueden llevar a cabo por una sola figura profesional capaz de modelar un requisito y seguir las etapas del sistema de auto-generación que lo implementa.