The answers by the Rational Unified Process

By Frans

What are the key answers that Rational Unified Process gives to the problems that we face in Software Engineering. If you look to the most serious problems encountered during a software engineering project then the majority of them find their root in communication problems, and the remaining problems are related to not obeying the basic software engineering practices, such as using a configuration management system. (CMM level 2 desribes these basic practices.) Communication is not only communication between the customer and the project team, but also between the analists, the architects, the designers, and the implementer, and even peer communication. Almost all project failures are caused by communication problems on a certain level. What are the answers that RUP gives to the problem of communication.

Process as the answer

RUP says that the answer is to define a good process. That is not so strange, because it is already in the name. Process is needed, but it is not the answer to the communication problem. Communication has to do with people. When there are communication problems, changing the process alone does not help. Usually, "improving" the process, leads to more regulations and longer communication lines. It leads to a further specialisation of roles, which is likely to introduce more communication problems.

Formalization as the answer

Another answer that RUP gives to communication problem is to formalize the language used for the communication. The language RUP uses is the Unified Modeling Language (UML), which is a set of diagrams that are linked with each other. However, formalizing a language is not the sole solution to a communication problem. It requires people to learn a new language and to become fluent in that language. Although people say that a picture says more than a thousands words, it is by no means true that diagrams are a better way to communicate than spoken languages or working software. The problem with diagrams is that they do not always solve communication problems.

Tooling as the answer

To answer a lot of internal communication problems, Rational provides a set of tools which support each aspect of RUP, from use cases to test cases and from user requiments engineering to round-trip engineering. Tools can indeed help with maintaining consistency and tracing between the various deliverables that a software project consists of. And tools can also support the use of a formal specification language. But tools also require discipline. A tool itself might introduce more troubles than it solves. Again, it is not obvious that tools do prevent communication problems.

The best practices

RUP talks about the six best practices, suggesting that these are the only, or at least the most important, six best practices. Not all of the best practices address the communication problems.

Develop Iteratively: Iterative development is only really going to work if it is supported by intensive communication with the customers. Because RUP divides the whole software development process in a number of phases, the intention to develop in short iterations can easy be reduce to the traditional waterfall manner of working. Iterations should be really short (weeks not months) to stimulate interaction.
Manage Requirements: Again, managing your requirements itself only works if you have good communication with the customers, otherwise it will only produce thick documents, which only will stimulate a waterfall manner of working, and stop communication. By the way, it is far more important to manage your risks than your requirements.
Use component architectures: This is a tool independent of the quality of communication.
Model visually: Again, this is a tool. It is doubtful whether visual models can replace working software in the communication with the customer. Most programmers can program without visual models. Putting extensive energy in making visual models as part of the design phase, will easily reduce RUP project into a traditional waterfall project. (It is okay, if it the models are used to generate execution code.)
Verify quality: The most used method of verifying quality is systematic testing. The best method is pair programming (continious peer review). Again, communication is the central factor.
Control changes: Without good communication between developers the goal to control changes will result in procedures that will hinder making changes in the latter stages of the project. We can only embrace changes if good communication is available.

The conclusion must be that each of these best practices have good communication as a prerequisite. Without good communication, they all fail to achieve their goal and act as stimulance for the traditional waterfall way of working where real communication is replaced by stacks of documentation that do not contribute much to producing business value for the customers.

Manifesto for Agile Software Development

This manifesto states that we should value people and interactions over processes and tools. In the last years, Agile software development methodes have gained a lot of interest, and have led to many succesfull projects where traditional style of development (waterfall) have failed. Although Robert Martin developed an agile instantiation of RUP (called dX, that is XP written upside down), I think that RUP as a replacement of traditional style of working, will not lead to a more agile way of working where good communication abounds between all stakeholders of the software development process (including the customers of course). I think it is not radical enough to break away from all the bad practices that are found in traditional software development projects, and I am afraid that in some cases the best practices will actually be perverted into bad practices that prevent healthy communication processes.

Software Engineering