Concept: Implementing a Process in a Project








var backPath = './../../../';
var imgPath = './../../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_4U33kAILEdq-_NKqZM1EhA", "_nB0hwAITEdqu-LkyOdB8SQ", "_yeKmwtnmEdmO6L4XMImrsA", "2.870714010568015E-306"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_AUv4MAIMEdq-_NKqZM1EhA", "_Zk3m0ACGEdqrKcHWz1HoWw", "{ADDC62A7-8E36-4DCE-9E5C-211B0950EBB5}", "2.870714010568015E-306"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_AUv4MAIMEdq-_NKqZM1EhA", "_So65gAIUEdqEutyfYo0quQ", "_yeKmwtnmEdmO6L4XMImrsA", "2.870714010568015E-306"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_Zk3m0ACGEdqrKcHWz1HoWw", "{ADDC62A7-8E36-4DCE-9E5C-211B0950EBB5}", "2.870714010568015E-306"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_kC0pcN7GEdm8G6yT7-Wdqw", "_yeKmwtnmEdmO6L4XMImrsA", "2.870714010568015E-306"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_vzRNgDIcEdqDs_9ORT1Rig", "2.870714010568015E-306"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);










Concept: Implementing a Process in a Project















This concept page describes the overall roadmap for implementing a process and it's supporting tools in a software development project.






Relationships



Related Elements


Environment


Environment


Process Engineer






Main Description



Introduction These guidelines describe 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 (see  Artifact: Development Organization Assessment).  These guidelines describe some possible approaches for implementing a process in a project.  In addition, Concept: Environment Practices describes some fundamental practices that are useful for implementing the environment of a software project.  For more information on the process tailoring aspects of a process implementation, see Tailoring RUP. 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 Process ceremony varies a lot in different development organizations. Some are very process mature, and have dedicated process groups to look after the definition and improvements of the process throughout the organization. Others are only concerned with project-specific tailoring. The approach taken to tailor the process for the project, depends heavily on the organization's process ceremony, as well as several other factors.  For instance: The development organization's process maturity. The size of the project in terms of calendar time and number of development resources. The project members previous exposure to similar processes. The formality requirements of the project. For more information on the factors affecting process implementation, see Guideline: Process Discriminants. The following are the basic approaches to implementing process and tools on a software development project:  " 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 depends on a number of factors.  These factors are described in Guideline: Process Discriminants.  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 work products would be developed over a project's lifecycle.    The evolution of the Environment work products 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 work products 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 for Classic RUP Inception applies with these variations and extensions. Project Management Activity: Conceive New Project 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. Activity: Evaluate Project Scope and Risk Identify risks in the project, including those risks associated with implementing the new process and tools. The result is the Artifact: Risk List.  Plan Project Plan the phases. The main result is the section titled Project Plan in the 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.    Note: The tailored Development Process has a major impact on the Software Development Plan, and vice versa. Therefore, the development of the project plan and the tailoring of the process must be coordinated.  Activity: Plan for Next Iteration Plan the iteration in detail, including the Environment discipline and all other disciplines. The main result is a Artifact: Iteration Plan, with all activity details and tasks of the Environment discipline, as well as all other process disciplines. Activity: Manage Iteration 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. Activity: Monitor Control Project The project manager monitors the daily work, including the process and tools. Activity: Evaluate Project Scope and Risk 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 Activity: Define Evaluation Mission Some logistic aspects of the Artifact: Test Strategy is defined that will provide the initial reasoning for the resourcing the test effort. Activity: Verify Test Approach 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 third-party component selections are verified as being testable. Environment Activity: Prepare Environment for Project 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.  Note: The Software Development Plan has a major impact on the tailored Development Process and vice versa. Therefore, the tailoring of the process and the development of the project plan must be coordinated.  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.  Activity: Prepare Environment for an Iteration 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.) See Task: Tailor the Development Process for the Project . Make sure that the people on the project understand how to use the development process, 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 Task: Launch Development Process. The results of performing the activity are: The Development Process where the Requirements discipline is described in detail, including Tailored document templates for work products in the Requirements discipline, such as the Artifact: Vision,  Artifact: Requirements Management Plan, and Artifact: Stakeholder Requests Tailored 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. Activity: Support Environment During an Iteration The system administrator supports the developer during the iteration.  Training All members of the project should 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 the RUP discipline that is being "rolled out" should attend a course where they learn the details of the discipline. Mentoring Mentoring is key to a successful process implementation.  In general, the following mentors are needed: 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. <Discipline Specific> Mentor 50%. Someone who facilitates the discipline-specific work, by leading workshops, reviewing results, and answering specific questions.  For more information on mentoring, see Concept: Mentoring.





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();