Artifacts > Environment Artifact Set > Development Case > Guidelines > Development Case

SWEN 5135 Configuration Management


Development Case		 The development case describes the development process you have chosen to follow on your project.
Topics

Explanation To top of page

Expressed in terms of business modeling, the software development process is a business process, whereas the Rational Unified Process (RUP) product is a generic business process for object-oriented software engineering. A development case is a static configuration of the RUP product; that is, it's a business process for software engineering tailored to a specific project, product, and organization. The development case focuses on what to do and how to do it.

A development case shows how the generic RUP applies to the context of your organization. This means that you modify the process and adapt the terminology.

A development case also provides an overview of the process to be followed, something understood by everyone on the project. For details, the development case should refer to the RUP and other guidelines or styleguides.

Process configuration is the activity of deriving a development case from the more general process presented in the RUP. For a sample of a development case, see Example: Development Case.

The process engineer is responsible for configuring the process, deciding how the development process will look, "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 RUP, into an organization is always a risk. You must continually weigh the advantages of a new technique against the cost of introducing the change. Consider introducing a change from both a managerial and a technical perspective.

Once a development case is set up by the process engineer, the project manager instantiates and executes it for the given project. This is often called process enactment.

As the process unfolds, 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 To top of page

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

  • Disciplines
    A software project would rarely skip one of the disciplines, such as Analysis & Design, Implementation, and so on, completely. In exceptional cases, some disciplines, such as Requirements or Deployment, may have been executed by other organizations. However, it's more likely that specific workflows within or across disciplines 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, imagine a totally paperless project that electronically maintains only a small number of artifacts, is supported by tools such as spreadsheets, design tools, programming tools, and testing tools, and only delivers software and documentation electronically on disk, CD or over the World-Wide Web. At the other extreme, there are projects that must produce and maintain a much larger set of printed documents for contractual, regulatory or organizational reasons. In some cases, complete models can be omitted.
  • Activities
    Activities are likely to vary for at least two reasons. Activities that use artifacts as input and produce, or update, artifacts as output 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. Activities are also modified to introduce specific techniques, methods, and tools that pertain to the specific application domain or development expertise, such as design steps, programming languages, automatic code generation tools, measurement techniques, and so on.

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

  • Steps in activities
  • Guidelines and guidance for activities
  • Notations, such as using subsets of the UML or using stereotypes to address some specific need for some, or all, models
  • Checkpoints for inspections and reviews
  • Roles
  • Tool support to automate some activities
  • Terminology changes, for instance to adapt the process to the organizational context

In summary, the process engineer must make a wide range of decisions to create a well-adjusted development case out of the RUP. A development case may have to be adjusted to take advantage of certain well-established company practices and standards, such as documents, terminology, and so on.

Difficult Configurations To top of page

Certain configuration forms are difficult to implement and must be considered very carefully. For example:

  • Change in process architecture
    Wide-ranging repackaging of the activities in another set of disciplines to match an existing process or organization may lead to a lot of effort for very little gain. Often, it's more practical to simply establish a mapping to assess whether all aspects are covered by the RUP. Remember that the disciplines are not phases sequentially executed—they are containers for activities, and are executed again and again at each iteration, often concurrently within one iteration.
  • Changes in terminology
    Although substituting one word for another may sound like a trivial exercise in word processing, such changes must be considered very carefully. In the domain of software engineering, organizations often use the same word with slightly different meanings, or different words that mean the same thing. Making isolated changes in the RUP may lead to a process that is very difficult to understand. One solution is to create a "translation table" for the terminology that translates between the RUP terminology and the organization's terminology.

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

If the process results are captured in a language other than English, the terminology issues are more complex where you must translate the descriptions of artifacts, documents, reports, and possibly other parts of the RUP to this other language.

Delegating Process Responsibility To top of page

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 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 on what plans to produce and how to produce them. In the same way, many project managers aren't concerned about how each team member designs his or her part of the system, as long as they deliver the expected functionality on time and within a reasonable level of quality.

One reason for having a process description at all is so several people can share information. If this is not the case, then the cost of maintaining the process description may be too high. Therefore, you may decide not to have, or maintain, the process description for one or several disciplines. This doesn't mean that you don't put effort into that particular discipline, nor does it mean that you don't think it's important. For example, you may employ an excellent test manager, provide all possible support, but leave it to that test manager to decide how to work and what artifacts to produce.

Representing a Development Case Online To top of page

A development case can be represented in several different ways:

One or Several Web pages

It's easiest to represent it as a Microsoft Word document, however, we recommend you represent the development case as one or several web pages with hyperlinks to the RUP when needed. See Toolkit: Adding External Links to Rational Unified Process for more details on how to add hyperlinks. If you have developed an organization-specific process product based on the RUP, the development case will have hyperlinks to it. See Concepts: Process Configuration for more details.

We recommend that you integrate the development case in your project web site, if you have one. See Toolkit: Working With Project Webs.

A Web Site with Navigational Tools

You could build the development case as a web site with navigational tools, like the RUP online. That is, you can use Web development tools such as Microsoft® FrontPage® and the RUP tools. For specific information about how to develop web pages, see the Toolkit: Rational Unified Process Styleguide. Also see Process Engineer Toolkit for those tool mentors that describe how to use FrontPage and the RUP tools. 

We recommend that you integrate the development case in your project web site, if you have one. See Toolkit: Working With Project Webs.

Integrated with RUP Online

You can also integrate the development case in the RUP online. This can be done by modifying the treebrowser and adding a new entry to both the Development Case and the project-specific guidelines. See Toolkit: Modifying the Treebrowser for details. However, there is a clear drawback to this approach, since you make the RUP specific to the project when you add project-specific information to the RUP. We only recommend this approach if the RUP online will be used in a single project.

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process