Guidelines: Development Case

Development Case

The development-case description describes the development process that you have chosen to follow in your project.

Topics

Explanation

Expressed in terms of business engineering, the software development process is a business process; the Rational Unified Process product is a generic business process for object-oriented software engineering. A development case is a static configuration (focusing on what to do, and how to do it) of the Rational Unified Process product, i.e., a business process for software engineering, tailored to a specific project, product, and organization.

A development case should show how the generic Rational Unified Process applies to the context of your organization. This means that you will modify the process, and adapt the terminology.

A development case should also provide an overview of the process to be followed, something digestible for everyone on the project. For details, the development case should refer to the Rational Unified Process, and other guidelines, or style guides.

Process configuration is the activity of deriving a development case from the more general process presented in the Rational Unified Process. For a sample of a development case, see Development Case Sample.

The person responsible for configuring the process is the process engineer. The process engineer decides how the development process should look, is responsible for "installing" the development case in the development organization (team, project or company), and teaching the developers how to use it.

Keep in mind that introducing a new development process, such as the Rational Unified Process, into an organization is always a risk. You should always weigh the advantages of a new technique, against the cost of introducing the change. Introducing a change should be considered both from a managerial perspective as well as a technical perspective.

Once a development case has been set up by the process engineer, the project manager can instantiate and execute it for the given project. This is often called process enactment.

As the process unrolls, lessons are learned during the process itself, which are used by the process engineer as feedback to improve the process.

Variable Elements in Software Engineering Processes

This section reviews the constituents of a process that are likely to be modified, customized, added or suppressed in a given development case.

Core process workflows
It is rather rare that a software project would completely skip one of the core process workflows (Analysis & Design, Implementation, and so on); in exceptional cases, some may have been executed by other organizations: Requirements, or Deployment. It is however more likely that specific workflows within or across core process workflows would be modified.
Artifacts
Projects are far more likely to differ by the artifacts that they have to produce, update, and deliver. At one extremity of the range, you can imagine a totally paperless project, maintaining only a small number of artifacts electronically, supported by tools (spreadsheets, design tools, programming tools, testing tools), delivering software and documentation only electronically on disks, CD or via the World-Wide Web. At the other extremity of the range, there are projects which must for contractual, regulatory or organizational reasons, produce and maintain a much larger set of documents, probably on paper. In some cases complete models can be omitted.
Activities
Activities are likely to vary for at least two reasons. Because activities use artifacts as input, and produce or update artifacts as output, they are affected by the modification of these artifacts; in particular if some artifact, or some element of information in an artifact is no longer necessary the corresponding steps maybe suppressed, or significantly modified.
But activities may also be modified to introduce specific techniques, methods, and tools that pertain to the particular application domain, or development expertise: design steps, programming languages, automatic code generation tool, measurement techniques, and so on.

At a more detailed level, other elements of the process can be modified, added, or suppressed:

Thinking steps or performing steps in activities.
Guidelines and guidance for activities.
Notation: subsetting the UML, or using stereotypes to address some specific need for some or all models.
Checkpoints for inspections and reviews.
Workers.
Tool support to automate some activities.
Terminology changes, for instance to adapt the process to the organizational context.

In summary, the process engineer has a wide range of decisions to make to create a well-adjusted development case out of the Rational Unified process.

Finally, a development case may have to be adjusted to take advantage certain well-established company practices and standards: documents, terminology, and so on.

Difficult Configurations

Certain forms of configuration are hard to implement and should be considered very carefully. For example:

Change in process architecture
Wide-ranging re-packaging of the activities in another set of core process workflows (to match an existing process or organization) may lead to a lot of effort for very little gain. It is often more practical to simply establish a mapping to assess that all aspects are covered by the Rational Unified Process. Remember that the core process workflows are not phases executed sequentially; they are containers for activities. They are executed again and again at each iteration, and often concurrently within one iteration.
Changes in terminology
Although substituting one word for another may sound a trivial exercise in word processing, such changes should be considered very carefully. In the domain of software engineering, organizations often use the same word with slightly different meaning, or different words to mean just the same thing. Making isolated changes in the Rational Unified Process may lead to a process that is very difficult to understand. One solution is to create a "translation table" for the terminology, which translates between the Rational Unified Process terminology, and the organization's terminology.

Examples of "dangerous" words: system, phase, role, activity, model, and document.

If the results of the process have to be captured in a language other than English, then terminology issues are more complex. In which case you have to translate the descriptions of artifacts, documents, reports and possibly other parts of the Rational Unified Process to this other language.

Delegating Process Responsibility

The development case does not have to capture the entire process. In reality a lot of responsibility, and decisions about the process (and the artifacts in particular) are delegated to the members of the software development project. For example, if there is an experienced, good project manager, you may leave it to this individual to decide what plans to produce and how to produce them. In the same way many project managers does not bother how each team member design his/her part of the system, as long as they deliver the expected functionality, on time, with a reasonable level of quality.

One reason for having a process description as all is for several people to share information. If this is not the case, then the cost of maintaining the process description may be too high. So, you may decide to not have and maintain the process description for one or several workflows. This does not mean that you do not put effort into that particular workflow, nor does it mean that you do not think it is important. For example, you may employ a very good test manager, give her all possible support, but leave it to her to decide how to work, and what artifacts to produce.

Representing a Development Case Online

A development case can be represented in different ways.

One or several web pages

The easiest is to represent it as a Microsoft® Word document, but we recommend you to represent the development case as one or several web pages with hyperlinks to the Rational Unified Process when needed. See the Tool Mentor: Adding External Links to Rational Unified Process, for more details on how to add hyperlinks to Rational Unified Process. If you have developed an organization-specific process product, based on the Rational Unified Process, the development case will, of course, have hyperlinks to it (see Concepts: Process Configuration, for more details).

A web site with navigational tools

If you want you could build the development case as a web site with navigational tools, very much as the Rational Unified Process online itself. For example, you can use web development tools such as Microsoft® FrontPage®, and the Rational Unified Process tools. The provide information on how to develop web pages, see Guideline: Rational Unified Process Style Guide. See the tool mentors that describe how to use FrontPage, and the Rational Unified Process tools, Rational Unified Process Development Tool Mentors.

Integrated with Rational Unified Process online

You can also integrate the development case in the Rational Unified Process online. This can be done by just modifying the treebrowser, and add a new entry to the Development Case, and to the project-specific guidelines. See Tool Mentor: Modifying the Treebrowser for details. However, there is a clear drawback with this approach, since you will then make the Rational Unified Process specific to the project, by adding project specific information to the Rational Unified Process. This means that we can only recommend this approach if the Rational Unified Process online will be used in one single project.

Rational Unified Process 5.1 (build 43)