Marco de modelado P

El marco de modelado P es un conjunto de directrices, métodos, herramientas y plantillas para la mejora del proceso de desarrollo . Este marco se puede integrar en cualquier otro ciclo de vida de desarrollo de software (SDLC) , como MSF Agile , MSF CMMI , RUP , etc.

Historia

Los orígenes del marco de trabajo P-Modeling provienen del "Experimento Babel", diseñado por Vladimir L. Pavlov en 2001 como un programa de capacitación para estudiantes de ingeniería de software , cuyo objetivo era que los estudiantes experimentaran una versión "condensada" de los problemas de comunicación típicos del desarrollo de software y adquirieran experiencia en la aplicación de UML para superar estos problemas.

Este experimento se llevó a cabo de la siguiente manera: un equipo de estudiantes recibió la tarea de diseñar un sistema de software con la siguiente restricción: UML debía ser el único lenguaje permitido para la comunicación durante el desarrollo del proyecto. El objetivo era que los estudiantes experimentaran una versión simplificada de los problemas de comunicación típicos del desarrollo de software y adquirieran experiencia en la aplicación de UML para superarlos. Como resultado, los estudiantes desarrollaron modelos bastante claros y concisos.

Poco después, durante una sesión de diseño, dos equipos independientes trabajaron en la misma tarea. El primer equipo solo podía comunicarse mediante UML, como se describió anteriormente, mientras que al otro se le permitía comunicarse verbalmente en lenguaje natural. Resultó que el primer equipo, con sus limitaciones, realizó la tarea de forma más eficiente que el segundo. Los diagramas UML creados por el primer equipo eran más sólidos, detallados, legibles y elaborados.

Posteriormente, Vladimir L. Pavlov realizó varios experimentos adicionales con el fin de determinar si las sesiones de modelado "silenciosas" eran más productivas que las tradicionales. En estos experimentos, los equipos que trabajaron en silencio demostraron ser al menos tan eficientes como los demás, e incluso, en algunos casos, superaron a los equipos tradicionales.

Algunas de las interpretaciones de estos resultados son las siguientes:

La restricción del uso del lenguaje natural puede estimular la creatividad de los diseñadores, además de obligarlos a mantenerse concentrados en su trabajo;
Trabajar en modo silencioso puede obligar a los diseñadores a descubrir explícitamente todos los supuestos subyacentes en las primeras etapas del proceso de diseño;
UML no se considera una carga superflua e irrelevante para las necesidades de la vida real (como un lenguaje de "solo escritura"), sino que, por el contrario, los diseñadores pueden empezar a mostrar una mayor preocupación por la calidad y la legibilidad de sus modelos.

Posteriormente, se concibieron ideas para realizar nuevos experimentos con el fin de encontrar un método para comparar UML con lenguajes naturales. La premisa de estos experimentos consistía en asignar tareas de "traducción" directa (de un lenguaje natural a UML) e inversa (de UML a un lenguaje natural) a dos equipos de diseñadores de software profesionales. Un equipo realizaría la traducción directa y el otro, la inversa. El objetivo era observar la similitud entre el resultado de la traducción inversa y el texto original, verificando así la corrección del modelo UML.

Los experimentos demostraron que, para la información que describe sistemas de software, UML posee la capacidad expresiva suficiente para mantener el contenido del modelo. Los textos obtenidos tras la traducción inversa desde UML resultaron semánticamente equivalentes al original.

Los experimentos sugirieron que el modelo del ciclo completo de desarrollo de software existía como una serie de traducciones. En experimentos posteriores, se demostró que la verificación de la traducción inversa es un método para garantizar que los entregables de cada etapa de desarrollo no pierdan ni malinterpreten nada de lo producido en la etapa anterior. Este método se ha denominado "Trazabilidad Semántica Inversa" y ha demostrado ser un complemento sólido para el Marco de Modelado P.

Principios básicos

Trazabilidad semántica inversa

La trazabilidad semántica inversa es un método de control de calidad que permite probar los resultados de cada paso de la traducción. Antes de pasar a la siguiente fase, se realiza una " ingeniería inversa " de los artefactos actuales y el texto restaurado se compara con el original. Si existe una diferencia entre ambos textos, se corrigen los artefactos probados para eliminar el problema (o se corrige el texto inicial). En consecuencia, cada paso se confirma retrocediendo y asegurándose de que el desarrollo se mantenga en el camino correcto. De esta manera, los problemas se pueden detectar y corregir sin demoras, evitando que se acumulen y se propaguen a las fases posteriores del ciclo de desarrollo. La palabra clave en el nombre de este método es " semántica ". Se basa en la comparación semántica de las versiones original y restaurada de un texto, centrándose en el "significado" del texto, no en las "palabras" específicas que contiene.

Los escenarios de uso más frecuentes reportados por los primeros usuarios del método de trazabilidad semántica inversa son:

Validación de modelos UML: los ingenieros de calidad restauran una descripción textual de un dominio y se comparan la descripción original con la restaurada.
Validación de los cambios del modelo para un nuevo requisito: a partir de una versión original y una versión modificada de un modelo, los ingenieros de calidad restauran la descripción textual del requisito y comparan las descripciones original y restaurada.
Validación de una corrección de errores: a partir del código fuente original y modificado , los ingenieros de calidad restauran una descripción textual del error corregido y comparan las descripciones original y restaurada.
Integración de un nuevo ingeniero de software en un equipo: un nuevo miembro del equipo recibe la tarea de realizar la trazabilidad semántica inversa de los artefactos clave de los proyectos actuales.

Modelaje sin palabras

Originalmente concebido como un método avanzado para enseñar Análisis y Diseño Orientado a Objetos con UML a los estudiantes, el Modelado Sin Palabras, en esencia, restringe el uso de medios de comunicación que involucren, directa o indirectamente, un lenguaje natural. De esta manera, un equipo de diseñadores se ve obligado a utilizar el lenguaje de modelado como el único lenguaje disponible para comunicarse durante una sesión de diseño.

Incorporación del marco de modelado P en el ciclo de vida del desarrollo de software (SDLC)

Independientemente del tipo de proceso de desarrollo que se utilice en una organización ( cascada , espiral , diversos métodos iterativos-incrementales u otros), existen ciertos procesos, como el diseño de software , el control de calidad , la gestión de recursos humanos , la gestión de riesgos , la gestión de la comunicación , etc., a los que se pueden aplicar los principios del marco de modelado P, especialmente en las primeras etapas de un proyecto , cuando las actividades de control de calidad son mínimas o prácticamente inexistentes.

Requisitos y limitaciones

Todos los participantes de la sesión de modelado P deben dominar algún lenguaje de modelado gráfico .
Se requiere un mínimo de 8 personas cualificadas para una sesión completa de modelado P.
Se requiere un mínimo de 3 personas cualificadas para una sesión RST eficaz.
El marco de modelado P no ofrece la posibilidad de detectar aspectos ambiguos, contradictorios e incompletos en los requisitos o las solicitudes del cliente.
La sesión de modelado sin palabras requiere una gran cantidad de energía y esfuerzo por parte de los participantes.

Crítica

El marco de modelado P obviamente tiene margen de mejora. Por ejemplo:

Las sesiones de modelado P requieren recursos adicionales sin conocimiento del artefacto original y añaden una carga de trabajo extra para los programadores .
Al realizar RST, los textos deben compararse manualmente, lo que significa que el marco carece de automatización.
Una de las posibles consecuencias de la RST es que la gente "diseña para la RST", es decir, crea artefactos de forma que puedan reconstruirse fácilmente, sin añadirles ningún valor nuevo.
No existe evidencia estadística confiable sobre la efectividad del marco de modelado P.
Las “sesiones de diseño silencioso” tienen una aplicabilidad bastante limitada: solo a sistemas y organizaciones que pueden y necesitan documentar el sistema en un lenguaje de modelado gráfico. Este no es el caso cuando:
- La empresa no cuenta con suficientes desarrolladores que dominen con fluidez ningún lenguaje de modelado gráfico y sepan cuándo y cómo aplicarlo, lo que implica estar altamente cualificados.
- La empresa no utiliza de forma extensiva ningún lenguaje de modelado gráfico.
Las sesiones de modelado P no pueden ayudar a diferenciar entre un buen diseño y un mal diseño.

Referencias

Vladimir Pavlov, Anton Yatsenko. Uso de la pantomima en la enseñanza de OOA y OOD con UML . 18.ª Conferencia IEEE sobre Educación y Capacitación en Ingeniería de Software (CSEE&T) , Ottawa, Canadá.
Vladimir Pavlov, Anton Yatsenko. El experimento Babel: un entrenamiento avanzado basado en pantomimas en OOA y OOD con UML . 36.º Simposio Técnico de la ACM sobre Educación en Ciencias de la Computación (SIG CSE 2005) , St. Louis, Missouri, EE. UU .

Enlaces externos

Sitio web de Microsoft (MSF)
Sitio web de IBM (RUP)
Sitio web de OMG UML
Sitio web de Vladimir L. Pavlov
Documento técnico sobre el marco de modelado P
SE201: Introducción a la ingeniería de software