The Unified Process

The Unified Process

There is a need of use case driven architecture centric, iterative and incremental software development (Unified Process). In some ways the unified process is an attempt to draw on the best features and characteristics of traditional software process models, but characterize them in way that implements many of the best principles of agile software development. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development. It focuses on the customer communication and software architecture. Unified Modeling Language is a robust notation for the modeling and development of object oriented system. UML did not provide the process framework to guide project teams in their application of the technology. UP is the framework for object oriented software engineering using UML. The five UP phases do not occur in sequence, but rather with staggered concurrency.

Phases of Unified Process

The Inception Phase:

Customer communication and planning activity. Business Requirements for the software are identified by collaborating with stakeholders. A rough architecture for the system containing fundamental features and functions is proposed. Fundamental business requirements are describes though a set of preliminary use cases. Planning identifies resources, assesses major risks defines a schedule, and establishes a basis for the phases that are to be applied as the software increment is developed.

The Elaboration Phase:

It encompasses the communication and modeling activities of the generic process model. It refines and elaborates the preliminary use cases define in the inception phase. It refines architectural representation to include five different views of the software. ( The use case model, The requirements model, The design model, The implementation model, The deployment model.). The architecture still don’t provide all features and functions required to use the system. The plan is carefully reviewed at the culmination of the elaboration phase to ensure that scope, risks, and delivery dates remain reasonable. Plan can be modified, if needed.

The Construction Phase:

It encompasses of construction activity. Requirements and design models are completed to reflect the final version of the software increment. Using the architectural model as input, the construction phase develops software components that will make each use case operational for end users. As components are being implemented, unit tests are designed and executed for each component. Integration of components are conducted.

The Transition Phase:

The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment activity. Software is given to end users for beta testing and user feedback. Defects and necessary changes are noted by user feedback. The software team creates the necessary support information that is required for the release.( User manuals, trouble shooting guides, installation procedures). A usable software is delivered.

The Production Phase:

During this phase, the ongoing use of the software is monitored. Support for the operating environment (infrastructure) is provided. Defect reports and requests for changes are submitted and evaluated. This phase coincides with the deployment activity. It is likely at the same time the construction, transition, and production phases are being conducted.

Personal and Team Process Model

The best software process is one that is close to the people who will be doing the work. Personal software process and team software process.

Personal Software Process (PSP)

The personal Software process emphasizes personal measurements of both the work product that is produced and the resultant quality of the work product. Practitioner is responsible for project planning and to control the quality of all software work products that are developed. The PSP model defines five framework activities.

Planning: Sources estimates, a defect estimate, metrics are recorded on templates, development tasks are identified and a project schedule is created.

High-Level Design: External specifications for each component is developed, a component design is created, prototypes are built if needed, uncertainty recorded and tracked.

High-Level design review: Formal verification are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.

Development: The component-level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.

Postmortem: Using the measures and metrics collected the effectiveness of the process is determined by applying statistical analysis.

PSP represents a disciplined, metrics-based approach to software engineering.

Team Software Process (TSP)

The goal of TSP is to build a self directed project team that organizes itself to produce high quality software. TSP recognizes that the best software teams are self directed. Team members set project objectives adapt the process to meet their needs. The teams control the project schedule and through measurement and analysis of the metrics collected, work continually to improve the team’s approach to software engineering. TSP defines these framework activities project launches, high level design, implementation, integration and test and postmortem (same like PSP).