Principles and best practices
The Unified Process is based on a set of software development principles and best practices, specifically:

  1. Develop software iteratively
  2. Manage requirements
  3. Use component-based architecture
  4. Visually model software
  5. Verify software quality
  6. Control changes to software

Develop software iteratively

Given the time it takes to develop large sophisticated software systems it is not possible to define the problem and build the solution in a single step. Requirements will often change throughout a project's development, due to architectural constraints, customer's needs or a greater understanding of the original problem. Iteration allows the project to be successively refined and addresses a project's highest risk items as the highest priority task. Ideally each iteration ends up with an executable release – this helps reduce a project's risk profile, allows greater customer feedback and helps developers stay focused.

The Unified Process uses risk-driven iterative and incremental development for the following reasons:

  • Integration is done step by step during the development process, limiting it to fewer elements.
  • Integration is less complex, making it more cost effective.
  • Parts are separately designed and/or implemented and can be easily identified for later reuse.
  • Requirement changes are noted and can be accommodated.
  • Risks are attacked early in development since each iteration gives the opportunity for more risks to be identified.
  • Software architecture is improved by repeated scrutiny.


Using iterations, a project will have one overall phase plan, but multiple iteration plans. Involvement from stakeholders is often encouraged at each milestone. In this manner, milestones serve as a means to obtain stakeholder buy-in while providing a constant measure against requirements and organisational readiness for the pending launch.

 

Manage requirements

Requirements management in The Unified Process is concerned with meeting the needs of end users by identifying and specifying what they need and identifying when those needs change. Its benefits include the following:

  • The correct requirements generate the correct product; the customer's needs are met.
  • Necessary features will be included, reducing post-development cost.


The Unified Process suggests that the management of requirements has the following activities:

Analyse the problem is about agreeing on the problem and creating the measures that will prove its value to the organisation.

Understand stakeholder needs is about sharing the problem and value with key stakeholders and finding out what their needs are surrounding the solution idea.

Define the system is about creating features from needs and outlining use cases, activities which show nicely the high-level requirements and the overall usage model of the system.

Manage the scope of the system is about modifying the scope of what you will deliver based on results so far and selecting the order in which to attack the use-case flows.

Refine the system definition is about detailing use-case flows with the stakeholders in order to create a detailed Software Requirements Specification (SRS) that can serve as the contract between your team and your client and that can drive design and test activities.

Manage changing requirements is about how to handle incoming requirement changes once the project has begun.

 

Use component-based architecture

Component-based architecture creates a system that is easily extensible, intuitively understandable and promotes software reuse. A component often relates to a set of objects in object-oriented programming.

Software architecture is increasing in importance as systems are becoming larger and more complex. The Unified Process focuses on producing the basic architecture in early iterations. This architecture then becomes a prototype in the initial development cycle. The architecture evolves with each iteration to become the final system architecture. The Unified Process also asserts design rules and constraints to capture architectural rules. By developing iteratively it is possible to gradually identify components which can then be developed, bought or reused. These components are often assembled within existing infrastructures such as CORBA and COM, or Java EE.

 

Visually model software

Abstracting programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. Using this representation, technical resources can determine how best to implement a given set of inter-related logics. It also builds an intermediary between the business process and actual code through information technology. A model in this context is visualisation and at the same time a simplification of a complex designs. The Unified Process specifies which models are necessary and why.

 

Verify software quality

Quality assessment is the most common failing point of software projects, since it is often an afterthought and sometimes even handled by a different team. The Unified Process assists in planning quality control and assessment by building it into the entire process and involving all members of a team. No worker is specifically assigned to quality; it is assumed that each member of the team is responsible for quality during the entire process. The process focuses on meeting the expected level of quality and provides test workflows to measure this level.

 

Control changes to software

In all software projects, change is inevitable. The Unified Process defines methods to control, track and monitor changes. The Unified Process also defines secure workspaces, guaranteeing a software engineer's system will not be affected by changes in another system. The concept ties in heavily with component based architectures.

 

More Information:

 

Who's Online

We have 4 guests online