Unified Process vs Agile Processes


[tweetmeme source=”gosub3000”]

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

References

  1. Anonymous (2000) Rational Unified Process.  Retrieved on May 13, from http://fox.wikis.com/wc.dll?Wiki~RationalUnifiedProcess
  2. Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A. et al. (2001) Manifesto for Agile Software Development.  Retrieved on May 13, 2008 from http://agilemanifesto.org/
  3. De Wille, E. & Vede, D.  (2008)  Software Process Models.  Retrieved on May 13, 2008 from http://www.the-software-experts.de/e_dta-sw-process.htm.
  4. Hay, D.  (1997)  The Zachman Framework: An Introduction.  Retrieved on February 2, 2008 from http://www.tdan.com/view-articles/4140/.
  5. Wikipedia Contributors  (2008)  Unified Process.  Retrieved on May 13, 2008 from http://en.wikipedia.org/wiki/Unified_Process
Advertisements

Tags: , , ,

20 responses to “Unified Process vs Agile Processes”

  1. Kevin E. Schlabach says :

    Just for the record, I’ve experienced scaling Agile to over 50 scrum teams across several locations and timezones. It can scale and be successful.

    Would I want to do it again? No. It requires a high level of commitment and effort to pull off. Though I am a fan of and prefer Agile, I wouldn’t want to be in charge of implementing agile in a 3000 person company if they have a good RUP process in place.

    Great article!

    • thejackleon says :

      dude, i so sympathise with you, RUP is effective, customisable and if it works – don’t agile it.

      • ccollins says :

        I’ve said it before and I’ll say it again, there ain’t no silver bullet process. You always have to match the process to the project.
        -Chris

  2. ccollins says :

    Thanks Kevin.
    The point about software processes that I’m beginning to realise, is that they come in different flavours, and are suitable in different situations.

    Despite the hype around agile and lightweight processes, there is no silver bullet, or one size fits all approach. You need to tailor the process to the project and your individual circumstances. Like you said, agile can scale, but only with determined and tenacious participants.

    That said, I like Scrum. I think it strikes a good balance between process and productivity. Though that may be based on the my most recent project experience. I am sure there are plenty of projects out there where Scrum would be an inappropriate process choice.

    -Chris

  3. venkat says :

    Thanks for this wonderful article. Our team is slowly moving towards Agile process from RUP. It can a lot of sense to migrate to AGILE because of the problems we are facing in software development.

    Thanks again !!!!

  4. jix says :

    Very well knitted article which highlighted most essential elements of Agile and UP processes.
    -Grand

  5. melshafaey says :

    Thanks for your clarification of differences between Agile and UP because i was always confused between Agile and AUP (Agile Unified Process), Thanks again.

  6. Ram Garg says :

    Thanks for insightful article.

  7. Jimbo says :

    I’ve successfully applied the principles in this book about scaling Agile processes to large teams:

    http://www.amazon.co.uk/Practices-Scaling-Lean-Agile-Development/dp/0321636406/ref=sr_1_3?ie=UTF8&qid=1312459364&sr=8-3

    It can be done and is done. Don’t be afraid.

  8. gordie smith says :

    Agile/scrum sounds good but what I have seen is that it is used to micro-manage. It gets old having daily meetings on software you are developing. Especially when there was not much design besides a glorified screen shot and maybe a simple use case.

    • ccollins says :

      I’ve only started practicing Agile (Scrum) recently. I can see your point, but the goal should be to have the team self-manage. If you’re being micromanaged, then you’re missing the spirit of agile.

      I agree a transition to a ‘designless’ world takes a little getting used to. We used to do big designs up front, and I never thought I’d say I missed them. Agile demands that you think on your feet as you develop features. What we’ve found useful is to very tightly constrain our user stories. For example, when we develop a feature, we’ll assume one user only, 32bit Windows only, etc. The next user story will deal with the same functionality under slightly expanded constraints, such as multiple users, or multiple different operating systems. As time goes by, the feature expands to meet the needs, but you maintain tight planning control on each user story, and each sprint. The trick seems to be to break user stories down to seemingly infinitesimal pieces, before summing them all back up.

  9. gordie smith says :

    I guess not all opinions are allowed. There was nothing wrong with my comment yesterday.

  10. Len Brown says :

    These are all good posts. We’ve used unified before with our ERP system and found it to slow down the progress for our timelines. We then changed to agile which helped considerably. I might note the development team was all seasoned staff that were knowledgeable on our requirements and deliverables.

  11. Carlos Ferreira says :

    I know this post is kinda old but I’m starting to re-learn software development processes. I say re-learn because at the university, I kinda learn OpenUP but ended up forgetting it because where I work (R&D), there is no development process. Each player is an individual piece that develops something unique that might or not, interact with other players pieces. Because of this, I have a question.

    For a scenario where each individual develops a specific piece of software which could be a small program or a library that may be integrated or not with other pieces of software,
    what method in your opinion, should be used for this kind of very distributed development scenario.

    This can be very complicated because of the “interfaces” used to connect the different blocks of software and a way to coordinate that development in an efficient and scalable way, would be great.

    • ccollins says :

      Hi Carlos,
      Most processes start with the assumption that you begin with at least a conceptual model of what it is you’re trying to build, e.g. an accounting system, a content management system, etc. It may be vague in the details but these get enumerated and fleshed out during a requirements gathering phase.

      What you’re describing seems less formal than that, perhaps one might even draw parallels to open source development where applications and libraries are created for their individual uses but coalesce over time. For example, an application requiring XML processing would refactor over time to use the most stable or most fully featured XML processing library.

      I don’t know of any process which co-ordinates this in a formalized way. To me it seems more akin to emergent behavior as individual actors maximize the use of available resources for their needs.

      Within a more formal context, then something like a Scrum of Scrums could be used to co-ordinate development across multiple sub-teams, where each team could be producing one component or library used elsewhere in the application.

      -Chris

      • Carlos Ferreira says :

        Thanks for the quick reply! :) I will look at Scrum then. Maybe it will be possible to adapt it :)

  12. Merelesita Cakau says :

    Hi Chris,
    I’m doing my assignment and it is based on developing three systems; accounting, billing and purchasing of this industry that supplies gas and electricity. Question is, should the three systems be developed as a single project or three individual project, and what approach should be use, given that this industry has a little experience with the adaptive approach.

    Hope you will reply instantly.

    Thanks.

    • ccollins says :

      Hi Merelesita,
      From a purely engineering standpoint there seems at least some amount of overlap of functionality between accounting, billing and purchasing applications. To me it would seem sensible to pool the shared functionality by modularising the design of all three systems, and sharing modules between systems where that made sense. Other modules would then take care of the application specific parts of each individual application.

      That said, there are many other factors that could influence your decision to build these systems together or separately. Such as the size and capability of your development staff, the business deadline, the project budget, etc. In my experience it is best that all stakeholders to the project come together at the planning stage and work through these issues.

      -Chris

    • Carlos Ferreira says :

      I think for reasons of scalability, you should develop them as single entities. If there is any kind of interaction between them, then there should be an API that exposes those services.

      I also agree with Chris. The project developers should meet at some point, in the beginning of the planning stage, to agree how the three entities will communicate with each other and to establish contracts for those interactions.

%d bloggers like this: