Dave Bouwmen of Arcdeveloper fame has started a thread on software development processes used by GIS consultancy companies, so I thought I'd describe a little how ours has evolved. Many years ago when our consultancy group got going most of our projects were relatively small and standalone, and historically we have tended to do most of our work following a DSDM method. This is a RAD approach which allows us to focus on the key requirements first, and start to time-box deliveries to our customers, but to maintain flexibility as the project progresses. It has been pretty successful for us in the past on small to medium sized projects, however DSDM does raise a couple of issues. One of the main criticisms of DSDM is that it does not scale to very large systems, as well as some other approaches do. The key reason for this is the focus on prototyping requirements early and expanding these through the lifetime of the project, this tends to mean that the overall architectural framework may initially get ignored which could lead to scalability problems later. It tends to work well on projects where the framework is already well known or dictated by the products chosen, so for example developing an Extension to ArcGIS would be a good project for this approach, as it is mostly worrying about the client functionality and the UI, which are easy to prototype then extend, and there is not much need to think about architectural scalability. The second issue with adopting a RAD approach is that it can often be hard to fit this with the expectations of the customer, delivering software in an interactive manner requires resources from the customer to receive the deliveries and to test and provide constructive, timely feedback. A large percentage of our customers are public sector organisations who are often under-resourced, so its vital with this approach that all parties know exactly what they are getting when, and what resources are going to be required to make the project a success.

There have been a number of trends in the last few years that mean we have had to evolve our development approach. The size and technical complexity of projects has tended to get larger, which means that scalability and architecture is much more of an issue than ever before. Integration with other IT systems is much more common which means projects are tend to be based around building interfaces and components rather than end-to-end systems. The shape and architecture of GIS projects is now infinitely more varied that it used to be, with desktop, web, mobile and database systems, being mixed together in different combinations. To deal with these issues we have moved now to a process based on RUP, this allows us to keep the flexibility of an iterative approach, but to focus more heavily on getting the architecture correct to begin with. Its not a huge step from DSDM, but focuses on the bigger picture to begin with before breaking the project down into smaller iterations. Its good to have an flexible approach that can cope with change during the project, but its important to get the fundamentals right near the beginning, as it can be expensive to change the entire architecture once the project is well under way.

I'm also a fan of some of the agile development processes, particularly around agile modelling, and the AUP which attempts to simplify the full RUP approach into something a little more lightweight and flexible.

Its interesting to see what other organisations are up to, and what the constraints on adopting other approaches is.