P-Modeling Framework

P-Modeling Framework is a package of guidelines, methods, tools and templates for the development process improvement. P-Modeling framework can be integrated into any other SDLC in use, e.g., MSF Agile, MSF CMMI, RUP, etc.

History

The origins of P-Modeling Framework come from "The Babel Experiment" designed by Vladimir L. Pavlov in 2001 as a training program for software engineering students that was aimed at making students go through a “condensed” version of communication problems typical for software development and gain the experience of applying UML to overcome these problems.

This experiment was done in the following manner. A team of students was assigned the task of designing a software system with the following restriction factor: UML had to be the only language allowed for communication while working on the project. The premise was intended to make students go through a “condensed” version of communication problems typical for software development and gain the experience of applying UML to overcome these problems. As the result of this experiment, students developed quite clear and concise models.

A little later, during a design session, there were two independent teams working on the same task. The communication means of the first team was restricted to UML as described above, while the other team was allowed to communicate verbally using a natural language. It turned out that the first, more restricted team, performed the task more efficiently than the other one. The UML diagrams created by the first team were more sound, detailed, readable, and elaborated.

Subsequently, Vladimir L. Pavlov conducted a number of additional experiments intended to reveal whether the “silent” modeling sessions are more productive than the traditional ones. In these experiments, silent teams appeared to be at least as efficient as the others, and in some cases the silent teams outperformed the traditional ones.

Some of the interpretations of these results are the following:

The restriction on using a natural language may stimulate creativity of the designers as well as force them to stay focused on their job;
Work in speechless mode may force designers to explicitly uncover all underlying assumptions at the very early stages of the design process;
UML is not treated as a superfluous burden irrelevant to real-life needs (as a “write-only” language) — instead, the designers may begin to demonstrate greater concern about the quality and readability of their models.

Afterwards, ideas were constructed for conducting additional new experiments with the intention of finding a method to compare UML to natural languages. The premise in these experiments was to set up forward (from a natural language to UML) and backward (from UML to the natural language) "translation" tasks for two teams of professional software designers. This would be done with one team performing the forward translation and the other one performing the backward translation. The intention was to observe how closely the outcome of the backward translation resembled the original text, thus providing verification of correctness of UML model.

The experiments showed that, for information describing software systems, UML has sufficient power of expression required to maintain the model's content. Texts obtained after the backward translation from UML were semantically equivalent to the original.

The experiments suggested the model of the entire software development cycle existed as a series of translations. In subsequent experiments backward translation verification has been demonstrated as a method to help guarantee deliverables of each development step do not lose, or have misinterpreted, anything that was produced at the previous step. This method has been named "Reverse Semantic Traceability." It has proven to be a solid second part completion to the P-Modeling Framework.

Basic principles

Reverse Semantic Traceability

Reverse Semantic Traceability is a quality control method that allows testing outputs of every translation step. Before proceeding to the next phase, the current artifacts are “reverse engineered”, and the restored text is compared to the original. If there is a difference between these two texts – the tested artifacts are corrected to eliminate the problem (or initial text is corrected.) Consequently, every step is confirmed by stepping back and making sure that development stays on the correct track. In this way, issues may be discovered and fixed without delays, so they do not accumulate, and do not cascade to subsequent phases of the development cycle.
The key word in the name of this method is “Semantic.” It is based on the fact the original and restored versions of a text are to be compared semantically, with a focus on the “meaning” of the text, not on particular “words” used in it.

The highest usage scenarios reported by early adopters of Reverse Semantic Traceability method are:

Validating UML models: quality engineers restore a textual description of a domain, original and restored descriptions are compared.
Validating model changes for a new requirement: given an original and changed versions of a model, quality engineers restore the textual description of the requirement, original and restored descriptions are compared.
Validating a bug fix: given an original and modified source code, quality engineers restore a textual description of the bug that was fixed, original and restored descriptions are compared.
Integrating new software engineer into a team: a new team member gets an assignment to do Reverse Semantic Traceability for the key artifacts from the current projects.

Speechless modeling

Being originally invented as an advanced training to teach Object-Oriented Analysis and Design with UML to students, the Speechless Modeling, in essence, is a restriction on using communication means directly or indirectly involving a natural language. In this way, a team of designers is forced to use the modeling language as the only language available for communication during a design session.

Incorporating P-Modeling Framework into Software Development Life Cycle (SDLC)

Regardless of what type of development process is used in an organization; waterfall, spiral, various iterative-incremental or some others, there are certain processes, such as software design, quality control, human resources management, risk management, communication management, etc. to which can P-Modeling Framework principles can be applied, especially in the earlier stages of a project when quality control activities are either minor or (virtually) absent.

Requirements and limitations

All the P-Modeling Session members should speak some graphical modeling language fluently.
Minimum of 8 qualified people required for full-blown P-Modeling Session.
Minimum of 3 qualified people required for an efficient RST Session.
P-modeling Framework doesn’t provide the possibility to detect ambiguous, contradicting, and incomplete aspects in requirements or client requests.
Speechless Modeling Session requires large amount of energy and efforts from participants.

Criticism

P-Modeling Framework obviously has some room for further improvement. For example:

P-Modeling Sessions require additional resources without knowledge of the original artifact and add extra workload for programmers.
While doing RST, texts should be compared manually which means that the framework lacks automation.
One of the possible outcomes in RST is the situation when people "design for RST" — they create artifacts in a way they can be easily reconstructed, without adding new value.
There’s no reliable statistical evidence of the P-Modeling Framework effectiveness.
The “silent design sessions” have quite a narrow applicability: only to systems and organizations that can and need document the system in graphical modeling language. This is not the case when:
- Company doesn’t have enough developers “speaking any graphical modeling language” fluently and knowing when and how to apply it, which means very highly qualified.
- Company doesn’t use any graphical modeling language extensively.
P-Modeling Sessions can’t help to differentiate between good design and bad design.

References

Vladimir Pavlov, Anton Yatsenko. Using Pantomime in Teaching OOA&OOD with UML. 18th IEEE Conference on Software Engineering Education and Training (CSEE&T), Ottawa, Canada.
Vladimir Pavlov, Anton Yatsenko. The Babel Experiment: An Advanced Pantomime-based Training in OOA&OOD with UML. 36th ACM Technical Symposium on Computer Science Education (SIG CSE 2005), St Louis, Missouri, USA.