Purpose
  • To make the project members use the development process tailored for the project, together with the supporting tools.
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. 

Make the Changes Public

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.

Educate Project Members

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:

  • Seminar.
    If the change is small or easy to understand it can be acceptable if the process engineer presents the new on a seminar. This type of seminar typically takes 1-3 hours. This is often the preferred choice when re-launching the process for an iteration, and the changes from the last launch are minor.
  • "Kick-start" workshop.
    Arrange a one-day workshop for all project members, where they follow the new development case, guidelines, templates, and use the tools. See Work Guidelines: Development Case Workshop, for details on how to arrange such a workshop. Notice that a "kick-start" workshop assumes that the participants have taken the relevant standard training courses. "Kick-start" workshops are often done at project startup. In large projects these kind of workshops may be arranged to kick-off of a new phase or even a new iteration. Always consider the cost of the workshops against the expected value to the project.
  • Customized training courses.
    If the project member have not attended the standard training courses in process and tools, an alternative is to customize the standard training courses, to cover the project's development case, guidelines, templates and tools. However, it can be expensive to customize training courses. Generic process training, like an introductory course to the Rational Unified Process(TM), should be conducted prior to project startup, or in the early days of the project. More specialized training in techniques, methods or technologies, is often conducted "just-in-time". This means that the training is given shortly before the method or technique is to be applied in the project, to ensure that new knowledge is fresh in mind.
  • "Boot-camps".
    1-5 weeks of concentrated hands-on training. Not many organizations can afford to arrange these kinds of boot-camps, but they have proven to be efficient if there are many new factors for the people in the project. A boot-camp is typically a mixture of seminars, training courses and hands-on work with the process and tools.

Collect Feedback

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   2003.06.13