This example schedule is for a typical iteration in the Inception Phase of a project following the Classic RUP configuration (or similar). This illustration shows how a project begins, and how the work conducted in each discipline is related to the overall schedule. It is constructed from the Workflow Details as they would appear at the time of the first iteration of the project. The intent is to indicate dependencies and show where workflows occur in parallel. The lengths of the bars in the chart (indicating duration) have no absolute significance. For example, it is not intended to convey that Conceive New Project and Define Evaluation Mission must have the same duration. There is also no intention to suggest the application of a uniform level of effort across the disciplines. An indication of the relative effort can be seen in the Process Overview. You can navigate to the corresponding Workflow Detail pages from each line of the chart - just click on the Workflow Detail name. This Gant Chart illustration was created from a Microsoft® Project® Plan.

Conceive New Project Evaluate Project Scope and Risk Manage Change Requests Manage Baselines and Releases Change and Deliver Configuration Items Create Project CM Environments Plan Project Configuration and Change Control Monitor and Report Configuration Status Prepare Environment for Project Prepare Environment for an Iteration Support Environment During and Iteration Define Evaluation Mission Analyze the Problem Understand Stakeholder Needs Define the System Manage Scope of the System Refine the System Definition Manage Changing Requirements Manage and Control Project Reevaluate Project Scope and Risk Plan Remainder of Initial Iteration Manage Iteration Plan the Project Plan for Next Iteration Identify Business Processes Refine Business Processes Design Business Process Realizations Refine Roles and Responsibilities Explore Process Automation Perform Architectural Synthesis Refine Software Development Plan Assess Business Status Diagram described in accompanying text.

A walk-through of the schedule outline

Preliminary: Define the Business Context (optional)

In cases where the system is being built to support a new or significantly changed business process, some context-setting business engineering can help to better define the environment in which the system will operate. This is especially useful if the stakeholders are having difficulties expressing the requirements on the system needed to support the new or changed business process, or have difficulty separating what the new system will do as opposed to what the new business process will do.

Defining the business context starts with Workflow Detail: Identify Business Processes. Prioritize those business processes that affects the system being built, and detail those according to Workflow Detail: Refine Business Process Definitions. Workflow Detail: Design Business Process Realizations and the Workflow Details: Refine Roles and Responsibilities shows how you further refine your understanding of the responsibilities that need to be carried out by the organization. In parallel with building the process realizations, you need to look at types of system sort, as described in Workflow Detail: Explore Process Automation.

The degree of business engineering performed depends on the desired results. If the purpose of business engineering is merely to set context for the system, the effort should be restricted to the subset of the business which will be supported by the system to be developed. Further business engineering, while perhaps valuable for other reasons, tends to be defocusing for the system development team.
Start up: Define the vision and scope of the system. The Stakeholders of the system to be developed, working with System Analysts, define the vision and the scope of the project (see Workflow Detail: Analyze Problem in the Requirements discipline, and the Artifact: Vision). The driving factor to consider in this effort is the user's needs and expectations. Also considered are constraints on the project, such as platforms to be supported, and external interfaces. Based on the early sketches of the Vision, start to define the Artifact: Business Case and document the important risks in the Artifact: Risk List.
Outline and clarify the functionality that is to be provided by system. Conduct sessions to collect stakeholders' opinions on what the system should do. This can be done using various techniques (See Work Guidelines: Storyboarding and Work Guidelines: Brainstorming). You can also include building an initial outline of the Artifact: Use-Case Model in this session. The Artifact: Glossary will likely be started to simplify the maintenance of the use-case model, and to keep it consistent. See Workflow Detail: Understand Stakeholder Needs. The main result of these sessions is the Artifact: Stakeholder Requests and an outline of the Artifact: Use-Case Model.
Consider the feasibility of the project, and outline the project plan. With the input from the use-case modeling, translate the Artifact: Vision into economic terms, updating the Artifact: Business Case, factoring in the project's investment costs, resource estimates, the environment needed, and success criteria (revenue projection and market recognition). Update the Artifact: Risk List to refer to the identified use cases and add new identified risks. Establish the initial Artifact Software Development Plan, mapping out the phases (Inception, Elaboration, Construction, and Transition), and major milestones. Define the high level approach to testing in a "Master Test Plan" (see Artifact: Test Plan).
Prepare the environment  Analyze the current state of the project and its surrounding organization (see  Workflow Detail: Prepare Environment for Project). The Role: Process Engineer develops a first version of the project-specific process (see Artifact: Development Process). The Role: Tool Specialist selects tools for the project, and sets up the tools necessary to support the Requirements work. The Process Engineer works with the different subject matter experts to prepare the initial set of relevant guidelines and templates for project use (see Activity: Prepare Guidelines for the Project and Activity: Prepare Templates for the Project).
Refine the project plan. At this stage, the stakeholders of the system to be developed should have a fairly good understanding of its vision and the feasibility of the project. An order of priority among features and use cases is established (see Workflow Detail: Manage the Scope of the System, Artifact: Iteration Plan, and Artifact: Vision). The Role: Project Manager refines the Artifact Software Development Plan, mapping out a set of iterations using the prioritized use cases and associated risks (see Artifact: Risk List). The plans developed at this point are refined after each subsequent iteration and become more accurate as iterations are completed. Note: this is a key differentiator in using this process - recognizing that initial project plan estimates are rough estimates, but that those estimates become more realistic as the project progresses and there are real metrics on which to base estimates; successive refinement of the project and iterations plans is both expected and essential.
Complete the iteration

The scope of the remaining work in this initial inception iteration (which is planned in the Artifact: Iteration Plan) will depend on the project manager's assessment of the risk (because, for example, the system is unprecedented, the domain is new to the development team, or the requirements are still not well understood or are particularly onerous). If the risk is low, there may be need for little more than clarifications of some requirements, in Workflow Detail: Refine the System Definition and Workflow Detail: Manage Changing Requirements, before a decision can be taken by the stakeholders to commit to development, and the elaboration phase can begin.

If the risks are judged to be high, then it may be necessary to do more exploration in this initial inception phase iteration, as described in the (optional) Workflow Detail: Perform Architectural Synthesis, in which the Role: Software Architect determines a set of architecturally significant requirements, which are modeled or prototyped (in Activity: Construct Architectural Proof-of-Concept), with the objective of increasing confidence in the feasibility of the project.

At the end of the initial inception iteration, the scope of the project and its associated risks are reevaluated to update the Business Case. Then the Iteration Plan for the next iteration is constructed; in parallel, the Software Development Plan and any of the artifacts it contains are updated, if this is warranted.

Result

The result of this initial iteration is a first cut at:

The scope of the project should be understood, and the stakeholders initiating the project should have a good understanding of the project's ROI (return on investment), i.e. what is returned, for what investment cost. Given this knowledge, a go/no go decision can be taken.

Subsequent Iterations In Inception

In cases where the project involves new product roll-out or creation of new technology, subsequent iterations may be needed to further define the scope of the project, the risks and the benefits. This may involve further enhancing the use-case model, business case, risk list, architectural proof-of-concept, or project and iteration plans. Extension of the Inception phase may also be advisable in cases where both the risk and the investment required are high, or where the problem domain is new or the team inexperienced.



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

Rational Unified Process   2003.06.13