Unified Process vs Agile Processes

Introduction to the Unified Process

The traditional view of system implementation is seen as a series of steps toward implementation,
covering areas such as analysis, design, construction, documentation, handover, etc. Hay (1997)
gives a good undertaking of the traditional approach stating:

Many methodologies are organized around the “system development life cycle”, an organization
of the steps required to develop systems. This is expressed as consisting of:

 Strategy – The planning of an organization’s overall systems development effort.

 Analysis – The detailed definition of requirements for a particular area of the
business.
 Design – The specific application of technology to the requirements defined during
analysis.
 Construction – The actual construction of the system.
 Documentation – Preparation of the user manuals, reference manuals, etc. to
describe the system.
 Transition – The implementation of the system, so as to make it part of the
infrastructure of the organization.
 Production – The ongoing monitoring of the system to ensure that it continues to
meet the needs of the organization.

Most methodologies portray the system development life cycle in terms approximating these.
Some go so far as to give it the acronym “SDLC”.

In many respects, the engineering approach to software was largely informed by the engineering
approach to any other type of project. It was assumed that the process of building software, was
analogous to design for manufacturing, or building a house, for example. The processes of
requirements gathering, analysis, design, construction, documentation and hand-over would
progress sequentially from one to another, with little interaction between those sub processes, such
as the progression from conceptual architecture to concrete construction of a building.

This has become known as the “Waterfall” (De Wille & Vede, 2008) process, as each process is
substantially complete before a subsequent process begins. Thus all requirements must be
gathered before analysis begins, and analysis complete before design begins, etc.

Based on experience of numerous software projects run under the waterfall process, software
practitioners began to feel that the approach was not suitable to software development, as the
process was rather heavyweight, and document centric. The output of each process was usually a
document which became the input for the subsequent process. Other disadvantages of the process
were that it was inflexible to change, and managed risk poorly.
The Unified Process (UP) deals with these limitations of the waterfall process by becoming an
iterative process. The creators of UP realised that it was almost impossible to specify all
requirements completely and accurately before moving on to analysis and design. As such, each
phase of the process can interact with previous phases. For example, during analysis, it may be
found that some requirements are not specified, and can be gathered as needed as the process
progresses.

The Unified Process is divided into four phases of (Wikipedia, 2008):

 Inception,
 Elaboration,
 Construction,
 Transition.

During the inception phase, feasibility is studied and the business case, and project scope are
understood, requirements are gathered, and use cases are defined. Finally risks are assessed, and
a preliminary estimate of project cost and time line is produced.. Elaborations leads to the
definition of a large majority of the system requirements. Common processes undertaken in this
phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only
basic notation) and package diagrams (architectural diagrams).

Construction is the largest part of the process where engineers take the previously developed
requirements, use cases, and system architecture and build the software. UML diagrams used
during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction
Overview diagrams. Finally Transition is the phase where the software, documentation and system
training is delivered to the customer, and any feedback incorporated.

At each phase of the process, the Unified Process requires that priority is given to the most critical
risks, as early in the project life cycle as possible. As each iteration is undertaken, the deliverables
must be selected in order to ensure that the greatest risks are addressed first.

Introduction to Agile Processes

Beck, Beedle, Van Bennekum, Cockburn, et al. (2001) defined the agile manifesto as follows:

We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
Several agile processes have since been developed around these guiding principles. Those are
Extreme Programming (XP), Scrum, Test Driven Development, Use Case Driven Analysis and
Design, etc. Each takes these guidelines, and expresses a software development process, though
each process differs in it’s focus and the process specifics.

“Individuals and interactions over processes and tools” is usually taken to mean that software is a
collaborative effort between all project stakeholders, including engineers, end users, customers,
management, marketing, etc. Agile prefers face to face communications above the traditional
document based communication mechanisms used by other processes.

“Working software over comprehensive documentation” attempts to ease the burden of previous
software processes. System design documentation should be seen as a useful tool for engineers to
be used as needed. Previous software processes had mandated the production of lots of
documentation before system implementation could begin. Software producers then had the
overhead of producing and maintaining these documents, though they added little to no value to
the customer who was more interested in working software, than the intermediate work needed to
produce it.

“Customer collaboration over contract signing”, brings the customer into the development team as
an equal stakeholder. Other methodologies only interact with the customer at the beginning during
requirements gathering, and at the end during deployment. Agile processes realise that it is useful
to have access to the customer throughout the development effort, so that team can easily prioritise
tasks based on risk and business value.

“Responding to change over following a plan”. As software takes months to years to produce, the
customer’s needs are likely to change during the project. This guideline along with the previous
allow the customer to define which requirements are the most valuable at any given time during
development. The project team can then focus on those functions which add the most value for
the customer on an ongoing basis. Planning can still be undertaken, though all stakeholders realise
that the plan is mutable, and can change often as development proceeds.

Comparisons
All software development processes define a list of activities to undertake, what order the activities
should proceed in, what the inputs and outputs of each activity should be, etc. What few software
process specifies is when to stop. It’s often too easy to overuse a process, and continue to produce
system designs, resulting in a heavyweight, document centric process. Essentially, process is
followed for process sake, rather than adding value to the stakeholders of the project.

Although UP is iterative, it follows the general phases of inception, elaboration, construction, and
transition in a more or less linear fashion. As the development proceeds less time is spent on Commented [RF1]: The requirements, analysis, design
and implementation phase takes place in both Agile and UP,
requirements and analysis, and more time is spent on construction, testing, and transition. the difference between Agile processes and the Unified
Process is that these phases are managed differently. Thus,
Agile processes on the other hand, spend time on each activity in each iteration. During each focusing on different phases at different times.
iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development, test,
Thus the same skills used for requirements, analysis and
etc.) are undertaken. The goal is to have stable software which could be shipped at the end of each design are used in both approaches.
iteration. At the beginning of each iteration, all stakeholders meet to reorganise requirements and
their priorities, while at the end of the iteration, working software is demonstrated to the
stakeholders. This ensures that customer value is being added at all times, and that progress is
being made on what matters, working software.

UP and it’s relative the Rational Unified Process (RUP) are quite comprehensive, and were
designed to be modified to suit the project being developed. This adds another layer of complexity
to the development effort, as the process has first to be modified before being implemented. While
this allows for the flexibility to use UP on any project, it requires teams to have access to UP
experts to ensure that the process is being defined and used properly.

Agile on the other hand tends to be used for small to medium sized projects involving teams up to
10 closely knit developers. Once teams become bigger than this, agile methodologies begin to
fail, as they don’t scale to large teams, or teams spread across geographies.

Conclusion
Both UP and agile methods attempt to bring the focus of software development back
onto software. Since it is software that is shipped, and paid for, then using a project team’s
resources to develop software that addresses customer requirements should be the main focus of
any project. While documentation, design and analysis are necessary parts of the development
approach, they should be seen as useful tools to be used as needed, and not ends in themselves.