Artifacts Produced in the Inception Phase

The RUP defines several artifacts that are produced during the achievement of the Lifecycle Objectives Milestone. I will define each artifact and add perspective from the point of view of an outsourced project.

The Project Business Case

The Business Case defines the economic advantages obtained from successful project execution. What overall problem would be solved by the project's results? What would happen if a decision not to pursue the project were made? Are there other alternatives to spending funds on this project? Could the same solution be obtained from a Commercial Off-The-Shelf (COTS) product? If so, how do the costs of the COTS solution compare to a custom solution, and what are the advantages and disadvantages of each? These are the sorts of questions that the Business Case is designed to answer.

On most outsourced projects, these questions have already been answered. If your role on the project is that of a contractor, it is worthwhile to thoroughly understand the Business Case, because it will influence your judgment for the many decisions yet to come. Certainly, it is helpful to read any Vision documents produced by the customer. See the later section "Seeing the World Through the Customer's Eyes" for other ideas.

The Project Vision Statement

The Vision Statement is written from the perspective of the customer and end users. Its purpose is to define what project success looks like. In other words, if the project were successful, what would the product look like? What are its key characteristics and features, and how will this help its users perform their functions better? One key difference between the Business Case and the Vision Statement is that the Business Case considers all options for solving the problem, without delving too deeply into the specifics of any single solution, except for the costs, advantages, and disadvantages. The Vision Statement assumes that you have decided to conduct the project. It defines, at a management level, how management will be able to tell if the mission has been accomplished.

Although most outsourcing organizations may have elements of a Vision Statement identified, it may not be formally stated in a document. If this is the case, the contractor's role is twofold:

• Help the customer define and envision what the product will do and how it will help the customer.

• Work closely with your project team to communicate this vision, and promote the vision to everyone on the project. The goal is for the project team to understand the problem from the customer's perspective and to buy in to the ideas the customer has for solving the problem.

The Project Risk List and Risk Management Plan

Every project has risks. Successful projects recognize the risks and tackle them head-on. In fact, the RUP was designed to help uncover risks as early as possible in the project lifecycle.

Many projects not only maintain a list of risks to the project but also define a Risk Management Plan describing how the project risks will be identified, communicated, and managed. The concepts of risk and risk management are so important that Chapter 8, "Identifying and Managing Risks," is devoted to them.

The Project Software Development Environment

In the Inception phase, the team's software development environment is established. These tools support the disciplines, such as visual modeling, requirements management, change request management, configuration management, and testing. Some examples of these tools were shown in Chapter 6, "Establishing the Software Development Environment."

The Project Software Development Plan (SDP)

Most contractors have company procedures that dictate the contents of an SDP. The SDP defines the methodologies, tools, and processes used to conduct the project. The SDP should also define the estimated resources and roles needed for the project. It may also be possible at this point to estimate how many iterations the project will require and their expected duration. But it is not possible to plan in detail the contents of each iteration.

It should be noted that the resource estimates, schedules, and so on produced in the SDP are estimates only. As the project progresses, you must adjust these estimates. Therefore, the SDP is an example of a "living and breathing" document that gets updated periodically during the project.

The RUP also suggests the optional creation of a product acceptance plan, which may be contained within the SDP. In an outsourced project, a product acceptance plan is vital. It states what the customer will consider proof that the project has been successfully accomplished. The details of such a plan may not be completely known during Inception. But a draft of the document should be produced and shared with the customer. Even if the detailed contents of the document are not completely known, the existence of the document signals to the customer that you expect the customer to consider specific criteria that will enable it to sign off on the project. Obviously, this document can and should be updated over time, and the document should be shared with the contracting organization. I have seen several projects that have had difficulty coming to a conclusion because there was no agreed upon criteria to indicate when the project was done. This is a source of angst for both the customer and the contractor.

The Iteration Plan

The Iteration Plan is a detailed, fine-grained plan showing a list of activities and tasks that are to be accomplished in a specific period of time. These tasks and activities are driven by specific risks and requirements assigned to that iteration.

The focus of the Iteration Plan changes from phase to phase. In the Inception phase, examples of iterations might be to clarify the project's scope and vision, possibly through the creation of prototypes. In general, an iteration should always produce something executable; however, the Inception phase is the one exception to this rule.

Iteration Plans cannot be produced reliably far in advance. The nature of iterative development is such that an iteration's success (or failure) dictates the contents or order of subsequent iterations. Consequently, detailed planning too far in advance will cause those plans to be rewritten as the project progresses.

The Development Process

The RUP is a customizable process framework. For each project, a document should be prepared explaining the development process to be used on the project and which artifacts will be produced. This document is called a Development Case. It is important to confer with the customer on the Development Case. On some projects, your Statement of Work may already specify what artifacts are official deliverables to the customer. These may or may not map well to the suggested artifacts defined by the RUP. Your Development Case should take this into account.

The Project Glossary

Many are tempted to skip creating a glossary, because it seems like a trivial exercise. But the glossary serves two purposes not immediately apparent:

• It helps those new to the project to get up to speed more quickly with the key terms, abbreviations, and acronyms commonly in use on the project.

• Without a glossary, project personnel will learn the meaning of the terms through osmosis. This is not a reliable or consistent way to learn the language of the customer's environment. The glossary establishes a common repository for the proper definitions of the terms used.

The Use Case Model

A Use Case Model should be created during the Inception phase that captures the following:

• The system's key actors. This includes all the system's important users, as well as other external entities, such as other systems, that must interface with the system being built.

• The system's key use cases. You should identify the most important functionality areas of the system to be built. Each area is a use case, and for each use case, the threads of functionality (flows) should be explained step by step.

Optional Artifacts

The RUP also suggests some optional artifacts that may or may not be necessary during the Inception phase:

• Business Analysis Model. If the system to be built involves a significant or complex business process, or workflow, a Business Analysis Model should be built. This model describes the business rules of the organization that will use the system to be built. This model is created without regard for how the system will be implemented. This serves as a reference when formulating the system's functional requirements.

• Functional prototypes. If there is significant uncertainty over the conceptual ideas presented in the Vision Statement, a small prototype can be built. The purpose of the prototype can be one or more of the following:

  • Gain consensus on what the product's form or look and feel should be.

  • Demonstrate viability of a new technology or to prove that the use of a new technology is technically feasible.

  • Explore certain aspects of a system's requirements that are particularly risky, such as performance and throughput concerns.

  • Gain the confidence of potential supporters of a system by producing a proofof-concept.