Concepts: Implementing a Process in a Project
Topics
- Introduction
- General planning guidelines
- Approaches to implementing process and tools
- Inception iteration example
Introduction 
This page explains how to implement process and tools in a software development project by performing the activities described in the Environment discipline. It also discusses the Project Management discipline, which deals with planning the project, identifying risks, and managing, monitoring, and evaluating the project.
It's important to understand that there are different ways to implement process and tools, as described in the section "Approaches to Implementing Process and Tools". The approach you choose depends on the current state of the project and its surrounding organization, therefore, do an assessment of the project and its surrounding organization.
The page Concepts: Environment Practices gives a list of proven practices that help you improve process and tools on a project.
If you want to know more about how to implement process and tools in an organization, refer to the Process Engineering Process (PEP), a component in the Rational Process Workbench(TM) product.
General Planning Guidelines
These general guidelines apply in almost every project:
- Before the project starts: Before the project actually starts, people who act as process engineers, tool specialists, and project managers must be trained in the Rational Unified Process (RUP). This is crucial to the project's success. If the project members do not know what to do, they probably will not succeed.
- Inception phase: During this phase, you typically focus on understanding how to improve the way you manage requirements (Requirements discipline) and how you manage the project (Project Management discipline).
- Elaboration phase: By the end of the Elaboration phase, all process and tools are in place. The most critical part of this phase is often how to perform configuration and change management because in the Construction phase, the work is performed by development teams working in parallel.
- Construction phase: No new process or tools are introduced in this phase. The focus here is to produce the product, therefore the development environment must be stable. In the Construction phase, the motivation is to get new people on the project up-to-speed.
- Transition phase: No new process or tools are introduced. In the Transition phase, the focus shifts from project-specific process improvement to project post-mortems, gathering project experiences from the current project, summarizing them, and packaging them in a form that future projects can use. These gathered experiences serve as input to improving process and tools for developing of the next evolution of the product.
Approaches to Implementing
Process and Tools
It's important to understand the basic approaches to implementing process and tools on a software development project. These approaches are:
- "Change everything". This means that the project adopts the entire RUP and a complete set of new tools.
- "Improve process and tools". This means that the project decides to improve some areas of the process and tools by adopting parts of the RUP and supporting tools.
How much of the RUP to adopt and how many new tools you decide to implement on a specific project depend on:
- What problems are identified and prioritized for the project
- The capacity for change
These are factors you typically uncover during an assessment of the project and its surrounding organization. This information is captured in Artifact: Development-Organization Assessment.
"Change Everything" (back to Approaches ...)
A project can decide to adopt the complete RUP and start to use a new set of tools for one or several of the following reasons:
- There is no process or tools in place and the project needs everything-a complete process and all tools.
- All, or most, of the people are new hires and no commonly accepted way of working exists.
- The project will shift to a new technology for the organization, which means that the existing process and tools will become obsolete.
If you decide to introduce the complete RUP and tools onto your project, then it's important to incrementally implement the process and tools. By implementing process and tools in a step-by-step procedure, it's easier to manage the risks and it makes these changes less overwhelming for the people on the project. The following diagram illustrates when the different Environment artifacts would be developed over a project's lifecycle.
The evolution of the Environment artifacts in a project where "everything is new".
Comments to the plan:
- Overall: The Business Modeling discipline is skipped altogether.
- Inception: Focus on introducing the Requirements and Project Management disciplines. To reduce the number of new factors, the user-interface parts of Requirements are not introduced. The project manager decides what parts of the Project Management discipline to use.
- Elaboration iteration E-1: Analysis & Design and Architecture are most important in the Elaboration phase. Automated Test and Configuration & Change Management are not as crucial this early in the project because the number of project members is relatively low. This can be introduced later in the project.
- Elaboration iteration E-2: Test tools and process are introduced to automate testing. Rational RequisitePro is introduced to manage the changing requirements.
- Elaboration iteration E-3: In the Construction phase, the work will be performed by development teams working in parallel. Therefore, it's crucial to have the Configuration & Change Management discipline in place at the end of the Elaboration phase. The deployment manager decides how to perform the discipline in the Deployment discipline.
- Construction: Nothing new is introduced. From an Environment perspective, the focus during the Construction phase is to get all new people on the project up-to-speed.
- Transition: Nothing new is introduced. The process and tools are refined as needed.
"Improve Process and Tools" (back to Approaches ...)
The people on a project in an organization where a process and tools are in place, have the capability to develop a system. These people have a common way of working, which is a process that may be more, or less, well documented.
The long-term goal may be to adopt the complete RUP and a complete set of new tools. However, the short-term goal is to improve on one or several areas of the process and tool support. These should be areas that have high improvement potential.
The diagram below shows an example of a project that has decided to adopt the Requirements discipline along with tools, such as RequisitePro and Rational Rose, to improve the way requirements are managed. The project has also decided to introduce the Analysis & Design discipline.
The evolution of the Environment artifacts when improving Requirements and Analysis & Design.
It's important to understand that the diagram above is only an example. The parts of the process you decide to improve on will differ between projects, depending on the problems and needs of a particular project. You must assess the project and its surrounding organization to find out those parts of the process you want to improve or which tools you want to introduce.
Inception Iteration Example
The following is an example of an iteration in the Inception phase where the Requirements discipline is introduced. Each entry in the Gantt chart is described in detail after the diagram.
Example of an iteration in the Inception phase
The basic workflow described in Sample Iteration Plan: Inception Phase applies with these variations and extensions.
Project Management
Bring the project from the initial germ of an idea to a point at which a reasoned decision can be made to continue or abandon it. The main results are initial drafts of Artifact: Business Case, Artifact: Software Development Plan, and Artifact: Risk List.
Identify risks in the project, including those risks associated with implementing the new process and tools. The result is the Artifact: Risk List.
Plan the phases. The main result is the section titled Project Plan in the Artifact: Software-Development Plan. This includes the Phase Plan where you'll find the major milestones with their achievement criteria, including criteria for the Environment discipline.
Plan the iteration in detail, including the Environment discipline and all other disciplines. The main result is an Artifact: Iteration Plan, with all workflow details and activities of the Environment discipline, as well as all other process disciplines.
The use of process and tools is appraised as part of the evaluation of the iteration. The results are:
- Artifact: Iteration Assessment. This includes problems or issues with process and tools used by the project team that may be addressed in subsequent iterations.
- Artifact: Status Assessment. This is for assessments other than iteration.
The project manager monitors the daily work, including the process and tools.
At the end of the iteration, the risks are re-evaluated, including risks associated with process and tools. Some risks are mitigated during the iteration and new risks are identified. The primary result is an updated Artifact: Risk List.
Requirements
No specific changes.
Test
Some logistic aspects of the Artifact: Test Strategy is defined that will provide the initial reasoning for the resourcing the test effort.
The test designer and a small team of testers verify that the key elements of the test approach will work against the Artifact: Architectural Proof-of-Concept. and that third-party component selections are verified as being testable.
Environment
Assess the current state of the organization and decide what parts of the process and those tools on which you want to focus in the first iterations. In this case the project decided, based on the assessment, to start implementing process and tools. The results are:
- Artifact: Development Process which is an initial version of the project-specific process.
- Artifact:Tools. The project's need for development tools is identified.
Prepare the process and tools for the Requirements discipline together with the supporting tools so the people on the project can start using them. (Of course, other disciplines can be prepared.) Make sure that the people on the project understand how to use the development case, use-case modeling guidelines, and tools. In addition to standard training courses, we recommend that you arrange a one-day workshop where the project members will get hands-on experience. See Activity: Launch Development Process and Concepts: Environment Practices.
The results of performing the workflow detail are:
- The Artifact: Development Case where the Requirements discipline is described in detail.
- Tailored document templates-see Artifact: Project-Specific Templates-for artifacts in the Requirements discipline, such as the Artifact: Vision, Artifact: Requirements Management Plan, and Artifact: Stakeholder Requests.
- Tailored guidelines-see Artifact: Project-Specific Guidelines-for central Requirements activities, such as the Use-Case Modeling activities.
- Requirements tools are set up and ready to use by the people on the project.
The system administrator supports the developer during the iteration.
Training
- All members of the project attend a course that gives an overview of the RUP in order to get an overview of the project's lifecycle.
- The people who work on Requirements need to attend a course where they learn the details of the Requirements discipline in the RUP.
Mentoring
- Process Mentor 50%. Someone who acts as a process engineer to support the project manager and other people on the project in using and configuring the process.
- Requirements Mentor 50%. Someone who facilitates the Requirements work, by leading workshops, reviewing results, and answering specific questions about requirements.
