Activity:
|
Purpose
|
|
Role: Process Engineer | |
Frequency: Once every iteration in the software project. | |
Steps | |
Input Artifacts: | Resulting Artifacts: |
More Information: | |
Tool Mentors: |
Workflow Details: |
The Development Process is prepared for use at the onset of the project and updated as necessary in the beginning of an iteration. When the new or updated development process is ready, you need to launch it to the project. This means that you make the process Website public, together with the development case, new guidelines, new templates, and new tools. Unless the change is trivial, you need to educate the people in the project to use the new process and tools.
Inform all project members about any significant update to the tailored process. This includes the process Website, development case, guidelines, templates and tools. If the project has a project web site, the changes should be posted there, in addition to notifying the project members.
The process Website of the configured process is typically published from the RUP Builder to a location on a Webserver accessible to all project members. Alternatively, the Website may be copied onto the project member's local hard drive. See Tool Mentor: Publish Process Configuration Using RUP Builder for further information. A development case, either as part of a project Web, or as a standalone document or Website, will also need to be launched to the project for every significant modification.
Since the development case contains a project's deviations from the underlying development process, it will typically change more frequently than the process Website itself, and as such it's often re-launched for every iteration. Guidelines and templates prepared for an iteration will also be made public upon iteration start. Guidelines and templates are either an integral part of the process Website, or they may be linked up using the development case. For details on how to make guidelines and templates an integral part of the process Website, see Tool Mentor: Packaging Project-specific Assets into Thin Plug-ins with RUP Organizer.
Unless the change is trivial, you need to educate the project members about the new process, including development case, guidelines, templates and tools.
The following are commonly used ways to educate the project members:
While presenting the new material and educating project members, you are likely to receive feedback and discover defects in the development case, guidelines, templates or tools, or even in the underlying process descriptions. Trigger change requests where appropriate. Some changes may be requested on the underlying process and will often need to be addressed outside the scope of the project, for example by the process group responsible for the organization wide development process. Other issues may be raised against the way the project has chosen to tailor the process and a resolution to the problem should be considered for the next internal release of the process, usually the coming iteration.
It is often worth while to follow up a process launch to ensure that the project
members "got the message". It is perceived as difficult by many individuals
to ask for clarifications during a presentation, especially when a lot of people,
internal and external, are present. In many projects, the responsibilities of
a Process Engineer also includes performing
process mentoring to help the project members applying the techniques described
by the process. This work will often result in feedback you don't usually capture
during a launch.
Rational Unified Process |