CS101: Introduction to Computer Science I

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 gives a good undertaking of the traditional approach stating:

• 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.

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" 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 realized 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:

• 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. defined the agile manifesto as follows:

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

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 its 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 realize that it is useful to have access to the customer throughout the development effort, so that team can easily prioritize 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 realize 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 requirements and analysis, and more time is spent on construction, testing, and transition.

Agile processes on the other hand, spend time on each activity in each iteration. During each iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development, test, etc.) are undertaken. The goal is to have stable software which could be shipped at the end of each iteration. At the beginning of each iteration, all stakeholders meet to reorganize 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 its 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.

Source: Chris Collins, https://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.