An Automated Process for Agile Software Development

Every software developer knows: Deadlines aren't met regardless of how "realistic" planning was. IT systems don't live up to the customer's expectations no matter how much detail the requirements were documented in.

Agile methods – lead by extreme programming – are going to change all this. Their secret: a requirements-driven, iterative approach which is specially structured around an individual project team. For some project managers, this probably sounds like chaos and anarchy all rolled into one.

But are agile projects uncontrollable? Not at all – provided that they are carried out according to a defined process.

actiF – A Process Model for Agile Software Development

Agile methods and especially eXtreme programming present the latest attempt to master the biggest challenge in software development – getting a grip on constantly changing requirements, deadline delays and substandard quality. The principal concepts available to master this challenge are:

• Including the customer in the project team
• Consistent orientation to the requirements, or more exactly to their value to the customer's company
• Short release cycles
• Iterative approach organized by the project team itself
• Integrated testing

If you want to successfully transfer these concepts into practice, you need to derive a concrete approach model from them – one which all those involved in the project can follow. microTOOL GmbH has created just such an agile process under the name actiF for their own product development and for their customers' projects, as well.

The process – you can read about its central components in the following pages – was conceptualized for object-oriented development with the UML on Windows platforms. It calls for the use of the UML tool objectiF and is tailored for implementation in C# et al with Microsoft Visual Studio .NET, as well as for testing with NUnit. Starting with version 5.0, objectiF offers fine-tuned integration with Microsoft Visual Studio .NET.

The Process Learns to Walk

How do you design an agile process that has a real chance of being brought to life in actual projects? An important hint was supplied by Jim Highsmith, one of the pioneers of agile methods. He advises us to [3] , "Think flow, not batch." We took his advice to heart and made the agile process workflow-capable. In other words, the process can be automated by a workflow management tool in a project.

The workflow management system used – in-Step – makes the project activities, their predecessors and successors visible in their current states of editing. In addition, it shows each activity's input and output products together with their current and planned states. Like this, the course the project is taking is made comprehensible to everyone involved. Figure 1 shows you what this looks like in reality.

When you work using iteration, version management becomes especially important. Another reason to use in-Step: The tool also offers the functions of a configuration management system. It keeps track of all of the products which are created throughout the project and records their version histories. in-Step supports the Source Code Control (SCC) interface von Microsoft and is used as a standard SCC provider. This makes configuration management of results especially convenient when you're developing in Microsoft Visual Studio .NET.

eXtreme programming is – in the words of its inventor – "an easy, efficient, low-risk, flexible, calculable, exact and enjoyable way of developing software." But won't the ease, flexibility and fun disappear when you "squeeze" the development process into the framework of a workflow management system?

in-Step doesn't weigh down the development process. Our experience shows the opposite: It makes you more confident and facilitates communication. This is because a lot of questions ("Is ... already started/finished?", "Where's the ...?") no longer have to be asked. And making the project flow visible helps the whole team to do the right thing at the right time. If something unexpected happens, the project manager knows what the options are. And customers can keep an eye on what's going on with their money. What does in-Step expect from the team in return? Every member of the project has to signalize the beginning and end of their activities with a mouse click, check their results in and out and select the correct state after a product's finished.

Requirements – The Motor of Agile Development

Once all the technical equipment is in place, the process runs like this: As soon as the targets of the project and the commercial purpose of the new application have been set, the requirements can be defined. These are formulated in just a few sentences as a series of stories. This is done by the team together with the customer. The stories are saved in the tool during the meeting. To record the requirements, simply fill out the onscreen form provided by in-Step. Figure 2 shows you this form. The entered requirements are saved as XML files and – as with all results in in-Step – are added to configuration management.

All of the stories should take roughly the same amount of time to complete – from about five to ten workdays. Our experience shows: It comes as second nature for a project team which is familiar with the application area of the system in development to structure requirements into stories of equal length. But what if the application area is too unfamiliar for formulating stories? Then every means is justified: The process purposely allows enough room for developing so-called free products. Free products can be automatically connected to the workflow and called directly from within in-Step for editing with the right tool. Like this, you can create UML activity diagrams with objectiF, for example, for analyzing business processes or use case diagrams to describe the system. When it comes to stabilizing requirements, modeling business classes with objectiF and prototyping them afterwards also proves useful. The application generator JANUS [4] from otris AG out of the Dortmund, Germany supports this approach, for example.

Whatever additional tools you decide to use, the goal is not to extensively document the requirements analysis. The important thing is: All of those involved understand the application area and its problems. The team should be put in the position where they are able to formulate stories and, thus, define small, realizable units. This is the condition for the next project activities: release and iteration planning.

Agile Yes – Unplanned No

An IT system is realized through a series of releases. We chose a release cycle of every three months. The main thing is: Every release needs to offer the customer more uses. The subject of release planning is to determine which of the many requirements will be fulfilled with each release. Once again the whole team comes into play. And the customer needs to be present here, as well. This is because one of the central criteria for selecting which requirements form a release is the customer's specific commercial interests. Another important point is the possible functional dependencies which make it necessary to realize certain requirements together.

The road to a release usually passes though two to three iterations. A part of the requirements for the release are fulfilled with each iteration – exactly which part is determined in iteration planning. The requirements are chosen according to completely difference criteria than in release planning. The technical workload, the technical dependencies, the common testability and the availability of human resources are the decisive factors here. The team estimates the workload for each story which is to be realized within one phase of iteration. eXtreme Programming [5] pragmatically suggests planning "using yesterday's weather", meaning let your experience with previous projects and releases guide you. But how can you rely on yesterday's weather when none of the "weather reports" were written down? This is why the process calls for recording the estimated workload for each story together with the first solution ideas which arise during iteration: The onscreen form used for recording the requirements also offers corresponding entry options for this. In this way, a sort of memory is created in the project which can be tapped into for later releases or projects.

The process allows new requirements to be defined, existing requirements to be discarded and requirements to be moved between iterations and releases any time. These actions are reflected in the planning of course. in-Step doesn't just know the planned workload; the tool also keeps track of the planned and actual duration of the project's activities. This makes it easier for the project manager to adjust planning as needed.

The Customer is On Board

As in eXtreme programming, in our approach the developers are responsible for that the code runs. They test the methods of the classes they developed and create test classes for this purpose. These test classes are not planned or designed in advance. They are implemented directly and added to configuration management in in-Step.

Testing higher lever system performance works completely differently. Here, it's not just the developers who carry the responsibility, but the customer, as well: In the framework of release and iteration planning, the team decides which behaviors will be tested to which degree. In this way, the customer who is involved in planning has a direct say on where "good enough" is sufficient and where the quality of system performance needs to be especially high. in-Step also provides an onscreen form for testing requirements and saves it in XML files. The tool distinguishes between three kinds of requirements testing: Testing requirements for operational behavior, problem domain behavior (these requirements usually arise during release planning) and technical behavior (resulting from iteration planning). Test suites are created for the testing requirements. They are designed – contrary to the test classes for elementary behavior – using class diagrams in objectiF and implemented using the NUnit framework. But wait, we haven't gotten to implementation yet! Let's go back to the process' driving force, the requirements.

Always Know Where You Are

Requirements go through several different states over the course of an iterative phase before they have been accepted by the customer. All of the states are managed by a tool. The workflow management system in-Step enables you to run as many project evaluations as you'd like. It makes sense to evaluate the requirements from time to time and generate a report of all of those which are in the state ordered or implemented, for example. Figure 3 illustrates this approach. Using this simple method, you are given an effective way of measuring internal project progress. It says a lot more than the usual comparison of planned/current start and end states of the project activities.

Nothing lasts Forever – Design via Refactoring

The requirements assigned to an iterative phase are the input information for the activities Design, Implementation, Integration and Test. These same activities occur in each step of iteration. This has a considerable effect on the design strategy. Since the design is extended and – unavoidably – changed in every phase of iteration, there is no stable design document until the last iteration of the last release. We accept this fact in our process: All that's designed in each step of iteration is exactly what's needed to fulfill the requirements assigned to the iteration. No attempt is made to create a flexible design which already tries to meet possible future requirements. This approach has a significant consequence: continual refactoring. The goal of refactoring is to make changes and extensions to the design in such a way that (1) the results are comprehensible and (2) the perceptible behavior of the parts developed in previous iterations does not change, as can be shown in regression tests. objectiF is used for design. Class diagrams are a must. Package diagrams are also used to describe the software architecture. The use of other UML instruments, such as sequence or state diagrams is left up to the developers. And to make sure that using a tool doesn't slow down the development process, objectiF has been technically integrated into in-Step so that the diagrams to be edited can be called directly from the context of the project's activities. Figure 4 shows what the working environment looks like.

Refactoring is made easier because objectiF automatically supports a whole series of refactoring methods. Refactoring classes include extracting interfaces, extracting super or subclasses, moving methods and attributes, renaming classes, methods, attributes and parameters, as well as correcting inheritance structures.

A new release is created after implementation at the end of each iterative phase. The release is then subject to a regression test. Up to the results of the last iteration, which is then distributed and introduced, these in-between releases are not meant for real operation. Each one of the forms a starting point for the successive iteration, the next step on the way to a finished system.

Conclusion

The goal of agile software development is to offer the customer a functioning system as quickly as possible. It's assumed that during the course of the project the customer's priorities will change, new requirements will arise or existing requirements will have to be modified. The instability of the requirements is made manageable by a defined process. If the process is created so that it is oriented to the project flow, the flow can be controlled. The way of achieving this is via a workflow management system. This tool support has an interesting impact: The agile process is made scalable and isn't limited to very small projects.

According to the agility principle of "traveling light", tools and methods are only used as needed. Three project tasks should definitely be aided by tools, however, because these tasks are the key to a successful project: managing the requirements and their implementation, software development with continual refactoring and developing and running of tests.

in-Step, objectiF and the process model actiF form a high performance team for agile software development.

This solution is not just for the products of a software manufacturer's product development process. Other areas of application include anywhere where product development relies heavily on fulfilling requirements, such as in consulting projects for IT service providers or in the change management domain of an IT organization.

Copyright © 2001 - 2010 microTOOL GmbH, Berlin. All rights reserved. Last Change: 4 February 2008