Guidelines: Development Case
Topics
- Explanation
- Variable Elements in Software Engineering Processes
- Difficult Configurations
- Delegating Process Responsibility
- Representing a Development Case Online
Explanation 
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 project-specific process 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 is a further refinement of this configured process, and 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 configured process and other guidelines or styleguides.
The process engineer is responsible for configuring the process, deciding how the development process will look, deploying the process Website, and "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
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
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 in 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.
The extended RUP tool set provides automation in the area of RUP customization. Refer to the Rational Process Workbench(TM) product for more information om recommended strategies for tailoring the RUP.
Delegating Process
Responsibility
The development case should not 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
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 configuration (project-specific or organizational) as needed. See Concepts: RUP Tailoring for more details.
A Web Site with Navigational Tools
There are great benefits to represent your project-specific process like the RUP Website. By always publishing your project's process from the RUP Builder tool, you get all this for free. The resulting Website has the exact same functionality and look & feel as the classic RUP Website.
We recommend that you integrate the development case in your project web site, if you have one.
Integrated with RUP Online
You can also integrate the development case in the RUP online. This can be done using the Personal Process View or My RUP feature on a server based RUP Website. This approach will add a new view into the process configuration, manifested as a separate tab in the RUP Treebrowser. In this view you can add nodes for the pages that constitutes the development case. See Tool Mentor: Personalize the RUP Website using Personal Process View or My RUP, for detailed information on how to create Process Views inside the RUP Website.
