The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.  The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.
 

Topics

Business Case Development Process - Project Specific Prepare Environment for Project Conceive New Project Development Process - Ready for Iteration Software Development Plan - Lifecycles Defined Prepare Environment for Iteration System Analyst Software Architect Tester roles Plan Project Manage the Scope of the System Manage the Scope of the System Define the System Perform Architectural Synthesis Perform Architectural Synthesis Monitor and Control Project Manage Iteration Plan Iteration Define Evaluation Mission Test Strategy Software Requirements - Outlined Architecture - Proof-of-Concept Established Software Requirements - Prioritized Risks - Identified and Prioritized Iteration Assessment Iteration Plan - Next Iteration Iteration Plan - First Iteration Risks Vision Vision - Refined Understand Stakeholders Needs Analyze the Problem Software Requirements - Identified Project Manager Process Engineer

Workflow details typically performed in an iteration in Inception for medium sized projects.

Objectives To top of page

The primary objectives of the Inception phase include:

  • Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.
  • Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design tradeoffs.
  • Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios
  • Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow)
  • Estimating potential risks (the sources of unpredictability) (See Concepts: Risk)
  • Preparing the supporting environment for the project.

Essential Activities To top of page

The essential activities of the Inception include:

  • Formulating the scope of the project. This involves capturing the context and the most important requirements and constraints to such an extent that you can derive acceptance criteria for the end product.
  • Planning and preparing a business case. Evaluating alternatives for risk management, staffing, project plan, and cost/schedule/profitability tradeoffs.
  • Synthesizing a candidate architecture, evaluating tradeoffs in design, and in make/buy/reuse, so that cost, schedule and resources can be estimated. The aim here is to demonstrate feasibility through some kind of proof of concept. This may take the form of a model which simulates what is required, or an initial prototype which explores what are considered to be the areas of high risk. The prototyping effort during inception should be limited to gaining confidence that a solution is possible - the solution is realized during elaboration and construction.
  • Preparing the environment for the project, assessing the project and the organization, selecting tools, deciding which parts of the process to improve.

Milestone To top of page

The Lifecycle Objectives Milestone evaluates the basic viability of the project. See Milestone: Lilfecycle Objectives for details.

Tailoring Decisions To top of page

The example iteration workflow shown at the top of this page represents a typical Inception iteration in medium sized projects. The Sample Iteration Plan for Inception represents a different perspective of the breakdown of activities to undertake in an Inception iteration. This iteration plan is more complete in terms of workflow details and activities, and as such, more suitable for large projects. Small projects might decide to do only a subset of these workflow details, deviations should be challenged and documented as part of the project-specific process.

 

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

Rational Unified Process   2003.06.13