[See also Phase: Inception.]
Green-field development.
| 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
modeling 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 and Workflow Detail: Identify Roles and Responsibilities. These initial definitions are then elaborated in Workflow Detail: Refine Business Process Definitions and Workflow Details: Refine Roles and Responsibilities. Beginning at the same time as the initial business process definition, the Workflow Detail: Domain Modeling should be used to capture the vocabulary and common terms of the business. Once the business processes stabilize, domain modeling is performed to define the business workers and entities. The degree of business modeling performed depends on the desired results. If the purpose of business modeling 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 modeling, while perhaps valuable for other reasons, tends to be de-focusing 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
workflow, 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 Needs 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. |
|
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 Worker: 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. |
The result of this initial iteration is a first cut at the Artifact: Vision and the Artifact: Business Case of the project, as well as the scope of the project and the Artifact: Software Development Plan. The stakeholders initiating the project should have a good understanding of the project's return on investment (ROI), that is, what is returned at what investment costs. Given this knowledge a go/no go decision can be taken.
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 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.
Back to the top