ABIS Infor - 2012-01
RUP and Agile and the like
Abstract
For more than 50 years we have been writing applications, and we have made tremendous progress on the technical side (hardware and software). Mastering and managing the software production process appears to be one of the toughest challenges, as indicated by the myriad of software development methods and process models that keep appearing and fading away. The last decade, a lot of attention went to incremental and iterative approaches like the Rational Unified Process (RUP) and several methods grouped under the 'Agile' umbrella.
Introduction
In the beginning (of the computing era) there was only darkness: our programs were unstructured (spaghetti code) and we had no clue how to structure the development process. Around 1970 we introduced structured programming to get more modular coding, thereby improving readability, maintainability and reusability. And on the process level we introduced structured development methods, describing and organizing the main activities (or call it steps, flows, roles, disciplines, ...) to achieve working software: requirements gathering, analysis, design, construction, testing, etc.
After that, each of the subsequent methods tried to improve on the previous ones, by formulating a different way to perform the same activities, or renaming and refining them (e.g. functional analysis, detailed design), and suggesting more/other tools to achieve the goal, and more/other deliverables (documents, models, diagrams, modules) to be produced.
Actually the word 'method' - or in full: software development method(ology) - does not have a single and precise definition. It embraces many aspects. Apart from describing the aforementioned activities, roles and deliverables, it also (implicitly or explicitly) adheres to a software development process model (or in short: a process), specifying the software life cycle.
The first methods assumed a Waterfall process: every step (from requirements to delivery) is only executed once. The Waterfall process got criticized for its rigidity: it does not deal well with changing or unclear requirements, design uncertainties etc.
As a reaction, from the 1980s on, methods started incorporating a cyclical approach, allowing earlier delivery and continuous improvement. Some efforts: RAD, Spiral, Iterative & Incremental. This is where the story of RUP and Agile starts.
The Rational Unified Process (RUP)
The RUP is a concrete implementation of the open Unified Process, which was developed mainly by Booch, Rumbaugh and Jacobson in the late 1990s - the 'tres amigos' working for Rational (the CASE tool vendor, since 2003 part of IBM), and who also stood at the cradle of the Unified Modelling Language (UML).
The main characteristics of the RUP are:
- delivering incrementally over many short and time-boxed iterations (iterating over all the activities each time); a typical iteration would last 2 weeks to 2 months;
- use-case driven: use cases are a technique for gathering & structuring the (mainly functional) requirements, which drives the entire project;
- architecture centric: although not everything is designed 'up-front', solid architectural tests and choices should be made early.
Actually the RUP calls itself a software development process model framework, thereby indicating that there are many degrees of freedom, and that it can be implemented in many different ways, depending on the situation. The original UP specifications mentioned e.g. 32 different roles (Systems Analyst, Requirements Specifier, Software Architect, Designer, etc.), and more than 100 different deliverables (documents, modules, etc.), often to be produced/revised at each iteration.
Although the RUP does not impose to use all of these options all the time, many RUP projects suffered from this 'embarras du choix'. The movement, that reacted to this aspect of 'too much ceremony', is known as the Agile Development.
Agile Software Manifesto
In 2001 a group of 17 leading software gurus formulated the Manifesto for Agile Software Development, which summarized the principles of 'lightweight' development as they were present in several emerging methods such as Extreme Programming, Scrum and DSDM, to form a counterpart to the RUP, with values such as:
- prefer individuals and interactions over processes and tools
- prefer working software over comprehensive documentation
- prefer customer collaboration over contract negotiation
- prefer responding to change over following a plan
This was concretized into 12 principles:
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily co-operation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
Agile methods
In fact the several member methods of the Agile movement do concentrate on various aspects.
The most popular Agile emanation, Scrum (1995), stems from the manufacturing world, and is not specific for software development: it concentrates on the project management aspect, with characteristics such as
- the roles: product owner (represents business), the development team (around 7 people), the scrum master (facilitating/enforcing the scrum principles);
- the backlog: the items to be realized, often formulated as user stories;
- the sprint: time-boxed iteration for realizing the sprint backlog (e.g. 2 weeks)
- daily short (stand-up) meetings with main roles
While also adopting standard agile features such as frequent delivery (e.g. 2 weeks iteration), small self-organizing teams and heavy customer participation, Extreme Programming (XP, 1999) adds specific software accents:
- test driven development: tests are developed before the actual code; continuous testing & integration; daily production;
- pair programming (compensates for minimal documentation, avoids code ownership);
- frequent refactoring to improve architecture;
In 2006 IBM/Rational produced a explicitly lightweight version of the (R)UP, calling it OpenUP and donating it to the community as a part of the openEclipse Process Framework (EPF). It is not clear whether this OpenUP gathered much momentum until now. In fact several other parties (e.g. Scott Ambler) have published their own lightweight RUP implementation.
Agile adoption and criticism
Many of the Agile principles are just 'common sense' and were already practised by well-organized teams long before the publication of the Agile Manifesto. It appears that the approach needs skilled, experienced and motivated team members, with little place for junior developers.
Since the Agile requires small self-organizing teams, there may be a scalability issue (although there exists something like 'a Scrum of Scrums'): for large and/or mission-critical projects, most enterprises still prefer the Waterfall model with its stricter up-front planning.
Want to find out more about Scrum and Agile? Take a look at http://www.abis.be/html/en1590.html.