Artifact: Development Process

	The Development Process is a configuration of the underlying RUP framework that meets the needs of the project following it. A common name for this artifact in the context of a project is Project-Specific Process.
Other Relationships:	Contains Project Specific Guidelines Project-Specific Templates Development Case
Role:	Process Engineer
Optionality/Occurrence:	All projects should follow a development process. The project-specific process is often provided to the project members via a Website.
Templates and Reports:
Examples:
UML Representation:	Not applicable.
More Information:	Concept: Process Quality Concept: The Underlying Model of the Rational Unified Process

Purpose Brief Outline Properties Timing Responsibility Tailoring

Input to Activities:  Conduct Review Create Integration Workspaces Develop Development Case Develop Iteration Plan Launch Development Process Organize Review Tailor the Process for the Project

Output from Activities:  Tailor the Process for the Project

Purpose

The purpose of the Development Process, or Project-Specific Process, is to provide guidance and support for the members of the project. "Information at your finger tips" is a metaphor that aligns well with the purpose of this artifact.

Brief Outline

Depending on the delivery mechanism chosen, an outline of the process can take many forms. For Web-based processes, such as the RUP, you can get a good feel for it's overall content by looking at it's sitemap or at the first two levels of the treebrowser.

Properties

A Development Process has no UML properties. Below is a list of characteristics and features that are important properties of a software development process :

• A well defined structure of core process elements, such as roles, activities, and artifacts, that the rest of the process description is centered around.
• Descriptive process guidance, for example descriptions of process elements, concepts, and white papers, for educational purposes.
• Prescriptive process guidance, for example step-by-step guidelines, check lists, tool mentors, for supporting the performer when producing artifacts.
• A lifecycle model. In RUP we define the iterative & incremental lifecycle by describing four phases and the notion of iterations within each phase.
• Additional resources to jump-start the production of project artifacts, such as reusable assets, guidelines, templates and examples.
• A mechanism for presenting the process guidance to it's users. In RUP, we have chosen the format of a highly navigable website, with the following attributes :
  • A search mechanism to allow the users to easily find the relevant guidance when needed.
  • A menu to allow logical browsing of the process, such as the left hand treebrowser in any RUP Website.
  • A filtering mechanism to allow for individuals to supress information that is not directly related to their day-to-day use of the process product.
  • A glossary of terms used in the process description.
• Descriptions of - and links to - supporting tools.
• Guidance on how to modify the process to fit the specific needs of a project.
  

Timing

A process tailored for a project is typically the result of work done at the onset of the project, or sometimes even prior to project start-up. As part of preparing the environment for the project, you might need to provide different views onto the underlying process, or describe finer-grained deviations from the underlying process. The project-specific process is typically updated as needed through out the project. One example of such an update is preparing specific guidelines and templates required to do the work planned for the upcoming iteration.

Responsibility

The Process Engineer role is primarily responsible for this artifact. These responsibilities include:

• Providing enough relevant process guidance for the project members to do their jobs efficiently and with acceptable quality.
• Producing a consumable version of the process, including intuitive means to navigate it's content.
• Ensuring that the project members are properly introduced to the process.
• Harvesting any feedback on the process and updating it as necessary .

Tailoring

Certain discriminators should be considered when deciding upon an approiate process for your software development project, such as required artifact formality, size of the project in terms of number of team members, duration, and budget, and the process maturity of the project members. The RUP framework supports a variety of project types, thus you will always need to tailor the process to your project-specific needs.

The project-specific process might, in some cases, consist only of a development case that serves as a filtering layer on top of the underlying process framework. Small development organizations typically do not have dedicated resources to develop an organizational-wide process, but rather use the RUP Builder product to publish the development process for the project. See RUP Builder tool mentors for details on how to use this tool to produce a project-specific process Website.

Larger development organizations, or ones with a special focus on cross-project reuse and process improvement, will typically develop one or more configurations for the organization. The project-specific process is instantiated from a matching organizational configuration. For further details on process configurations in a development-organization setting, refer to the Rational Process Workbench (RPW) product.

See Activity: Tailor the Process for the Project for details on tailoring of this artifact.

Rational Unified Process