What Is Project and How Does the Project Get Started

Rational Unified Process (RUP): A new way to look at Project Development Life Cycle

Abstract:

The paper highlights the key concept of the iterative process of the software development lifecycle- IBM Rational Unified Process (RUP) and the difference with Waterfall methodology. Based on writer’s experiences with both of the Software development lifecycle, the paper unfolds the basic difference of these methodologies along with explaining RUP Iteration, which is time boxed mini Waterfall methodology, with the chance of revisiting the methodology at the end of each cycle. The paper also moves along explaining the description of the disciplines, artifacts with respective roles along with what these artifacts capture as it progresses.

What is Project and how does the Project get started:

Project usually can be formulated by a company’s internal and external needs and activities such as ‘Strategic Initiative’ which in other words part of Company’s Strategic Plan, company’s business unit initiative, regulatory or compliance requirement, information technology improvement and maintenance etc. There are several general steps ‘an idea’ goes through prior it is being approved:

·  Formulate an idea or concept

·  Gain Management Support/Sponsorship

·  Develop an appropriate Business Case

·  Obtain resource commitments

·  Begin project and follow chosen methodology

Software Project Life Cycle and difference between the methodologies:

“The Project Life Cycle refers to a logical sequence or stages of activities to accomplish the project’s goals or objectives.” (Visitask, 2010) Waterfall and Rational Unified Process (RUP) are two proven but very different methodologies for initiating and managing projects in order to ensure successful on time implementation of a project within budget and with expected functionality. The key difference between Waterfall methodologies and RUP can be segmented in few practices.

RUP is an Iterative Development process where the team builds the system in smaller portion focusing on the risk early. Each smaller portion which is called ‘iteration’ is a mini-waterfall method resulting in an executable portion of the system. Waterfall on the other hand focuses on to complete everything in succession. Finish the requirements, and then design the system, then code and then test. Below figure shows how feedback loop is confined to the previous step.

Figure 1 Disciplines in Waterfall model (Wapedia. 2011).

Also in RUP Risk management is critical to where as Risk Management minimally influence the process in Waterfall method.

RUP also is a ‘Use Case driven’ methodology for capturing requirement where Use Cases are usually description of the function in narrative, plain English of the primary input and in Waterfall requirements often contain design and implementation information and most cases requirement captured in declarative statement. (Idiom Software Ltd .2011)

Also in Waterfall method requirement specs are very large and stand on its own. It is very inefficient to track from lower to higher level of detail. In RUP details unfolds as progressive level where successive level provides more depth than the previous level .Also test cases can be traced to the requirements they validate.

What is RUP:

RUP is the short form of IBM Rational Unified Process which focuses on performing all of the software development tasks in smaller time segment referred to as iterations. The iterations move through phases that have specific goals. RUP is supported by the use of the Rational tool set.

RUP is based on following practices:

·  Develop software iteratively

·  Manage Use Cases and requirements

·  Use component based architecture

·  Model software visually

·  Verify software quality

·  Control changes to software (IBM Developer Works.2004)

Below Figure 2 references Phases, Disciplines and Iterations within RUP. Each discipline is expressed in terms of roles (who performs the task), activities (how they perform these tasks), and artifacts (what the activity achieves). A role defines the behavior and responsibilities of an individual, or a group of individuals, responsible for activities and artifacts. (IBM Developer Works.2004)

Figure 2: Phases, disciplines and iterations in RUP (IBM Corporation.2007)

Disciplines:

§  Business Modeling: The modeling techniques which is used to define business processes.

§  Requirements: The technique of eliciting stakeholder requests and transforming them into set of requirements that provides the scope for the project the system to be built and provide detailed requirements for what the system must do.

§  Analysis and design: The process of transforming Requirements into the specifications for the design of the software the project will develop.

§  Implementation: The process of developing, organizing, and unit testing and integrating the components implemented based on design specifications.

§  Test: The process of evaluating and assessing the product quality.

§  Deployment: The activities associated with ensuring that the software product is available for its users.

§  Configuration and change management: The process of controlling and synchronizing the creation of the set of work products composing a software system.

§  Project Management: Activities that focus on project planning, risk management, monitoring progress and metrics.

§  Environment: The management of the software development environment that supports the development team, including both processes and tools.

Phases and Iterations:

RUP is composed of four phases. Inception, Elaboration, Construction and Transition. Since RUP follows an iterative approach, a phase may consist of one or more iterations.

Inception:

Inception is Lifecycle Objective Milestone of the project where project team and stake holders agree on scope via Vision & Outlined Use Cases, Use Case Prioritization Matrix have been drawn where roughly 20% of requirements have been detailed.

Goal: to achieve concurrence among all stakeholders on the objective of the project. The phase is important for both new development and enhancements; however there is more emphasis on this phase for new development efforts.

The major objectives of the Inception phase are –

·  Establishing the project’s software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be the product and what is not.

·  Discerning the criteria use cases of the system: the primary scenarios of the operation that will drive the outcomes of the project.

·  Estimating the overall cost and schedule for the project in high-level.

·  Estimating potential risk or sources of unpredictability.

·  Preparing the supporting environment for the project.

Elaboration:

Lifecycle Architecture Milestone of the project where candidate architecture has been completed and technical risk mitigated. 80% to90% of requirements has been detailed in this phase.

Goal: to baseline the architecture and design of the system to provide a stable basis for the bulk of the development effort in the next phase, Construction.

The major objectives of this phase are –

·  To ensure that the architecture, requirements and plans are stable enough and the risks sufficiently mitigated to be able to predictably determine the cost and schedule for the completion of the development. For most projects passing this milestone also corresponds to the transition from a light-and-fast, low-risk operation to a high cost and high risk operation with a substantial organizational inertia.

·  To address all architecturally significant risks of the project

·  To establish a base lined architecture which typically exposes the top technical risks of the project.

·  To produce an evolutionary prototype of production quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks.

·  To demonstrate that the baselines architecture will support the requirements of the system at a reasonable cost and in reasonable time.

·  To establish a supporting environment.

Construction:

This phase produces the product with Initial Operational Capability. Product is working in this phase and system test completed.

Goal: to clarify the remaining requirements and completing the development of the system based upon the base lined architecture.

The major objectives of this phase are –

·  To minimize development costs by optimizing resources and avoiding unnecessary scrap and rework.

·  Achieve adequate quality as rapidly as practical.

·  Complete the analysis, design, development and testing of all required functionality.

·  To iteratively and incrementally develop a complete product that is ready to transition to its user community.

·  To decide if the software, the sites and the users are all ready for the application to be deployed.

Transition:

In this phase Product is completed and waiting for release.

Goal: to ensure that the software is available to users.

The major objectives of this phase are –

·  Beta testing to validate the new system against user expectations.

·  Beta testing and parallel operation relative to a legacy system that it’s replacing.

·  Training of users.

·  Tuning activities such as bug fixing, enhancement for performance and usability.

·  Obtaining acceptance of the final product from the stakeholders through methods such as User Acceptance Testing (UAT).

Iterations:

The iterations are set period of time within a project in which the project team produces a stable, executable portion of the project’s scope. Iterations are ‘time boxed’ which means the schedule for an iteration should be regarded as fixed, and the scope of the iterations content will be actively managed to meet that schedule. The number of iterations will be determined by what is required within each phase to reach the life cycle.

Content management is mostly iteration based also early and continuous risk mitigation is a big priority in all iteration. Iteration generally ranges from one week to three months. Iteration also accommodate changing requirements, product improvement and refinement facilitated in iteration, increased learning and product improvement and increased reusability are few usability of iterations.

Artifacts:

“Artifacts are either final or intermediate work products produced and used during a project. Artifacts capture and convey project information, and may take various shapes or forms.” (Rational Software Corporation. 2003) To make developing a complete software system manageable, the artifacts are organized into sets. Several artifacts can be used in a number of disciplines. There are several Artifacts or work products required to produce throughout the stages in Project Life Cycle. Below are the few.

Vision:

This artifact provides a high-level basis for the more detailed technical requirements that are visible to the Stakeholders. It is written from the customers' perspective, focusing on the features of the system and acceptable levels of quality (non-functional requirements)

Basically the Vision Work Product is the mechanism in RUP to capture the project’s scope.

There are 4 key areas of the Vision:

●  Problem Statement

●  Stakeholder and User Descriptions

●  Stakeholder Needs

●  System Features

Use Case Diagram – Use Case

A Use Case is a textual specification describing the interaction between actors and the system. The Use Case diagram provides an overview of the system's intended behavior and intended functionality for the system. It is a visual representation of how the users of a system interact with it.

Figure: 3 shows how Use Case diagrams receive input from Vision doc and also Use Case diagrams contain Use Cases. (Rational Software Corporation. 2003)

Figure 3: Use Case Diagram (Rational Software Corporation. 2003)

Referring to figure 3 , Use Case diagram ‘the stick figure’ refers as Actor and the ‘ovals’ refer use case model element. There will be one use case model element for each identified Use Case.

An Actor is a role that a person, another system, device, and time or clock plays when directly interacting with the system. The Use Case is written from the Actors point of view which describes what the system must do, not ‘how’ it will be implemented in the system.

Supplementary Spec:

Supplementary Spec captures the system requirements that are not readily captured in the Use Cases of the Use Case model.

Quality attributes of the system to be captured through Supplementary Specs, including:

•  Usability requirements

•  Performance requirements

•  Reliability requirements

•  Supportability requirements

Below figure 4 refers to the Supplementary Specification which captures the Technical requirement that did not get captured in Use Case.

Figure 4: Supplementary Specification

Use Cases and Supplementary Specs are basically the detailed requirement for the project. In most cases Functional and Business Rules were separated from detailed

requirement document of Waterfall model and translated into Use Case Models and Specifications. System-wide Non Functional requirement, System-Wide Business Rules and Design Constraints are translated into Supplementary Specifications.

The Requirements Prioritization Matrix:

The Requirements Prioritization Matrix is an Excel base Spreadsheet tool used to rank all identified and outlined Use Cases and/or other requirements to enable iteration planning. It has several color coded categories where it ranks the issues on the basis how much the issues impact Use Cases/or other key requirements.

There are 4 categories in the Matrix:

Critically Ranked : Use Cases and/or other requirements have one or more attributes: technical risk, domain contribution, non-functional issues, and business value.

Secondarily Ranked : Use Cases and/or other requirements support the Critical ones and have a modest impact on architecture.

Ancillary Ranked : Use Cases and/or other requirements are of have no impact on architecture and are of least importance to the project.

Out of Scope : Use Cases and/or other requirements are functionality that has been taken out of scope through negotiation if trivial or a change management process if material.

The Master Test Plan and Strategy:

This Artifact facilitates the planning, control and strategic approach of the test effort. It defines the general approach that will be employed to test the software and to evaluate the results of that testing, and is the top-level plan that will be used by managers to govern and direct the detailed testing work. Apart from helping to estimate the project testing resource it also provides the visibility to the stakeholders the test effort to gain the approval.

There are 9 key areas of the Master Test Plan and Strategy-

•  Purpose, Intended Audience and Scope- The purpose of this document is to recommend and describe the testing strategies to be employed; intended Audience is Stakeholders both internal and external and the scope such as the functionality and usability of the intended project.