Embed Size (px)
Citation preview
Proyecto: Estrategias docentes de UML y MDA Documento: UML_HojaDeRuta Historial: 14/05/2004 11:28 – 18.08.2004 Situación: Abierta Proceso: UML COACHING Responsable Josep Vilalta - [email protected]
La “Hoja de Ruta” UML Manif iesto 2004
Posiblemente, uno de los errores más frecuentes en el dominio del desarrollo del software, es abordar
directamente “la solución” sin haber dedicado previamente el esfuerzo suficiente para definir cuál es “el
problema”. El resultado es que la mayoría de las soluciones planteadas para dar valor a los “Actores” de
un sistema en discusión, permanecen enterradas en el interior de complejas herramientas de software y
los problemas siguen donde siempre, ahí fuera. Desde que en noviembre de 1997 el Object
Management Group (OMG) acreditó la versión 1.1 del Unified Modeling Language (UML) como
estándar para modelar y visualizar la especificación del análisis y el diseño de componentes de software,
el uso de dicha notación ha tenido un crecimiento constante. Según datos del Gartner Group publicados
en 2002, la notación UML es usada por un 98 % de las herramientas CASE y por un 60 % de las
herramientas de ingeniería de procesos. Ambos enfoques, se espera que lleguen a una cuota del 99 % en
los próximos dos años. La evolución de UML ha hecho converger en una misma notación la
especificación de componentes de software (desde su análisis hasta su implementación), y el modelado de
procesos de negocio de una organización (Process Mapping - Workflows). Esta unificación tiene un gran
impacto en los entornos corporativos donde se utilizan ambas ingenierías, procesos y desarrollo de
software. La ausencia de un vocabulario común y, la incompatibilidad de los modelos de especificación,
había impedido hasta ahora establecer un espacio de colaboración, en el cual, todos los agentes
involucrados puedan definir y resolver de una manera eficiente los problemas de información y
comunicación de los usuarios finales. Es gracias a la notación UML, que podemos comunicar y compartir
el conocimiento de una arquitectura (conceptual, de diseño, y de implementación), donde se entrelazan
los procesos de negocio de la organización y las aplicaciones informáticas, mediante la combinación
simultánea y sinérgica de las siguientes tareas:
1. Definir conceptos a través de sus atributos distintivos y trazar sus límites.
o de unos elementos.
ción.
reutilizables.
2. Formalizar unas reglas de relación y actuación.
3. Hacer visible la granularidad y el entrelazamient
4. Mantener la trazabilidad entre la concepción de un problema y su solu
5. Tomar decisiones y evaluar su impacto dentro de una arquitectura definida.
6. Organizar la experiencia de los usuarios en patrones de conocimiento.
7. Comprobar la coherencia, completitud y usabilidad de los entregables.
8. Alinear la solución tecnológica con la cadena de valor de los Actores.
9. Usar un vocabulario controlado dentro de un espacio de colaboración.
10. Realizar un plan de producción en base a una factoría de componentes
Dir.: D:\__sincroMentor\__TRAD CD Borrador\_TRAD COACHING Hoja de Ruta\UML_HojaDeRuta_00.doc Equipo: vico.org
Fecha actualización:
18/08/2004 12:45
Revisión:
24 Página:
1 de 3
Proyecto: Estrategias docentes de UML y MDA Documento: UML_HojaDeRuta Historial: 14/05/2004 11:28 – 18.08.2004 Situación: Abierta Proceso: UML COACHING Responsable Josep Vilalta - [email protected] Pero dis
1. Definición del problema al.- Aplicación de patrones de Clases de análisis para definir el
b. trones de Actividad para delimitar los
c. ara acotar un “Censo
2. Solución de diseño e diseño.- Aplicación de patrones de diseño abstracto orientados a
a en
b. onentes.- Aplicación de patrones orientados a desacoplar los
c. tos ajustado a la “granularidad” de las clases
3. Esquema de implementación Utilización de patrones de Clases de implementación
e
b. componentes.- Ajuste escalable de los distintos componentes en los
c. datos optimizado para extraer el máximo
rendimiento de un motor concreto de base de datos relacional (SQLServer, DB2,
Oracle, etc.).
poner de un lenguaje unificado de modelado (UML) no es suficiente. El Analista de Negocio y
el Programador, por mencionar un par de roles clave en los procesos de desarrollo de software, también
necesitan establecer un esquema de cooperación orientado a un plan de producción y a la certificación
de entregables de un proyecto (Software Factory). Lo que impide que este esquema se desarrolle de una
manera eficiente no es la falta de motivación, a mi entender es una falta de visibilidad. Es necesario
construir una “maqueta visual” del proyecto en cuestión que ayude a los distintos roles participantes a
visualizar (comprender visualmente) una “Hoja de Ruta” con múltiples itinerarios posibles:
a. Arquitectura conceptu
“Modelo de Negocio” del sistema en discusión.
Esquema de flujo de trabajo.- Aplicación de pa
procesos esenciales en un modelo: “Proceso de Negocio Global”.
Red de funcionalidad.- Aplicación de patrones de Casos de Uso p
de Escenarios de Usabilidad” que organice la experiencia de los Actores del sistema en
discusión de acuerdo con su cadena de valor.
a. Arquitectura d
definir las reglas de creación, estructura y comportamiento de los objetos del sistem
discusión con independencia de la plataforma final de implementación (Model Driven
Architecture – MDA).
Arquitectura de comp
componentes que integran las estructuras de información y comunicación de la empresa
dentro y fuera de su ámbito de actuación.
Modelo Lógico de Datos.- Esquema de da
de diseño que define la persistencia y la semántica de los objetos de negocio.
a. Arquitectura de ejecución.-
(Java, C#, C++), configurados a partir de un entorno de desarrollo: “Framework” d
aplicaciones.
Despliegue de
nodos de una red con múltiples capas.
Modelo Físico de Datos.- Esquema de
Dir.: D:\__sincroMentor\__TRAD CD Borrador\_TRAD COACHING Hoja de Ruta\UML_HojaDeRuta_00.doc Equipo: vico.org
Fecha actualización:
18/08/2004 12:45
Revisión:
24 Página:
2 de 3
Proyecto: Estrategias docentes de UML y MDA Documento: UML_HojaDeRuta Historial: 14/05/2004 11:28 – 18.08.2004 Situación: Abierta Proceso: UML COACHING Responsable Josep Vilalta - [email protected] El Programador yecto
a través de la “Ho ),
desde la concepción del problema hasta el código y viceversa. En cada itinerario, unos hitos de referencia
pueden señalar cuando es recomendable o necesario el abordar la certificación de entregables de
modelado o de código, dentro de un esquema de cooperación y de responsabilidad compartida.
La utilización de esta “maqueta visual” también tiene un extraordinario valor docente. Puede evitar la
elaboración de arduas explicaciones teóricas para pasar directamente a “mostrar el proceso” de cómo
resolvemos los “Escenarios de Usabilidad” desde un entorno de desarrollo a un entorno de ejecución.
También, nos puede mostrar cómo desde dicho entorno de ejecución disponemos de la trazabilidad
necesaria para poder enlazar con la arquitectura conceptual que nos define la concepción del negocio,
desde su estructura a sus procesos (visión estática y dinámica). Tengo la convicción de que si podemos
mostrar este viaje en ambos sentidos y podemos explicar las razones de la “granularidad” de los
distintos elementos (Clases, Procesos, Casos de Uso), será mucho más facil que el Analista de Negocio y
el Programador comprendan la importancia de construir un buen modelo, como la única referencia
formal del enunciado del problema a resolver.
La realización de los distintos itinerarios por la “Hoja de Ruta”, permitirá que ambos roles cooperen en
la presentación de una solución tecnológica bien alineada con la cadena de valor de los Actores más
relevantes del sistema en discusión. Dicha cooperación, también facilitará la traducción del modelo de
referencia en unos componentes de software bien desacoplados, y proporcionará una mayor visibilidad
de los procesos de proyecto involucrados para obtener dicha solución. Finalmente, al Analista de
Negocio y el Programador podrán entender mejor sobre el terreno (hands-on), las ventajas clave de la
orientación a objetos (dentro de los ámbitos interdependientes del análisis, el diseño y la programación),
que les ayudarán a revelar la profunda unidad que subyace a la diversidad superficial de los procesos de
negocio de una organización. Quizá la elaboración de esta “Hoja de Ruta” sea ambiciosa, pero no es
imposible, y considero que vale la pena el esfuerzo para llegar a sus múltiples destinos.
vico.org umlearning.com
y el Analista de Negocio tienen que poder viajar por la “maqueta visual” del pro
ja de Ruta” con distintos itinerarios posibles de ida y vuelta (procesos de proyecto
Josep Vilalta Marzo CV Resumen: http://www.vico.org/aRecursosPrivats/JosepVilaltaMarzo_Res.pdf Manifiesto 2004: http://www.vico.org/aRecursosPrivats/UML_HojaDeRuta.pdf
Dir.: D:\__sincroMentor\__TRAD CD Borrador\_TRAD COACHING Hoja de Ruta\UML_HojaDeRuta_00.doc Equipo: vico.org
Fecha actualización:
18/08/2004 12:45
Revisión:
24 Página:
3 de 3
Hoja de Ruta de la plantilla TRAD-3PAEntregables a realizar y/o seleccionar por los Roles participantes en los
procesos indicados de cada fase de un proyecto: escala A
Autorizar proyecto Arquitectura estable Producto implantable Explotación Cierre proyecto
Estudio Preliminar Formalización Construcción Transición Evaluación Requerimientos y Análisis
¬ Glosario de conceptos
¬ Actas normalizadas
¬ Modelo de Negocio básico
¬ Proceso de Negocio global
¬ Censo Casos de Uso candidatos
¬ Diccionario de Clases A. (S)
¬ Censo de Casos de Uso (S)
¬ Modelo de Casos de Uso (S)
¬ Fichas de Casos de Uso princip.
¬ Prototipos de interfaces GUI
¬ Censo escenarios usabilidad (O)
¬ Censo de Casos de Uso (S)
¬ Modelo de Casos de Uso (S)
¬ Fichas de Casos de Uso
¬ Censo escenarios usabilidad (O)
¬ Censo escenarios usabilidad (O)
Diseño ¬ Diccionario de Clases D. (S)
¬ Modelo de Arquitectura (S)
¬ Esce. Interacción de objetos (O)
¬ Modelo de datos (S)
¬ Diccionario de Clases D. (S)
¬ Diseño de interfaces GUI
¬ Dic. de Componentes (S)
¬ Esce. Interacción de objetos (O)
¬ Modelo de datos (S)
¬ Modelo de datos (S)
¬ Dic. de Componentes (S)
Implementación ¬ Modelo de Implementación
¬ Versión código fuente
¬ Versión inicial de Build
¬ Scripts SQL (DDL)
¬ Censo de subsistemas
¬ Plan de Integración
¬ Versión código fuente
¬ Versión de Build
¬ Scripts SQL (DDL)
¬ Versión código fuente
¬ Versión de Build
Test ¬ Plan de Testing
¬ Informe de Testing ¬ Informe de Testing ¬ Informe de Evaluación
Implantación ¬ Plan de Despliegue
¬ Plan de documentación
¬ Plan de Despliegue
¬ Manual de Usuario
¬ Manual de Admin y explotación
¬ Diagrama de Despliegue
¬ Conf. Entorno de ejecución
¬ Manual de Usuario
¬ Manual de Admin y explotación
¬ Informe de aceptación
Configuración y cambios
¬ Plan de Configuración básico ¬ Cartera de peticiones
¬ Cartera de versiones
¬ Cartera de peticiones
¬ Cartera de versiones
¬ Cartera de peticiones
¬ Cartera de versiones
Infraestructura
¬ Censo recursos de soporte
¬ Censo de herramientas
¬ Conf. Entorno de desarrollo
Dirección de proyecto ¬ Matrícula de Proyecto
¬ Ficha Técnica básica
¬ Ficha Técnica básica
¬ Orden de Trabajo
¬ Ficha Técnica básica
¬ Orden de Trabajo
¬ Ficha Técnica básica
¬ Orden de Trabajo
¬ Ficha Técnica básica
¬ Informe de Cierre
vico
.org
- jv
ilalta
@vi
co.o
rg -
Rev
.- 3.
1 - 2
003
