Software Development Models – Quick And Dirty Guide

This post is more to serve as my notes, rather than an in-depth article.

Anyhow, I have just read ‘The Art of Agile Development’ by Shire and Warden, which concentrates on the principles, practices and potential benefits of introducing the Extreme Programming methodology into your development teams. If Extreme Programming is a road you feel you may want to go down, or if you require some help with putting the ideas it brings in practice, I can highly recommend this book. For me, XP is currently not an option with the size of the development team I work in, which has been reduced to me, myself and I, together with an, I guess, Product Manager/Customer/Domain Expert, whilst we both double as testers. However, you never know what the future will bring (but you can hope!), so I wanted to give myself some background knowledge on the current popular methodologies.

So, I am going to start by looking at some of the more conventional models for a Software Development Process or Lifecycle, before moving onto the Agile models. The aim of adopting any such model is to achieve improved ‘productivity’ and ‘quality’ (big buzz words) by using a repeatable and predictable structured process. By incorporating such a model within your project management strategy is to ensure that your projects are delivered ‘successfully’, i.e. on budget, on time and with all the features in the agreed specification. All sounds fantastic in an ideal world where requirements do not change over the length of the project, and design specifications have no mistakes. Up until the revolution that is Agile, this is what we were taught. I also want to mention here that Agile type modelling has probably been used way before the term Agile was coined and applied to defined models. There are probably a large number of software teams who work to their own ideals or models using Agile type processes to enhance the holy grail of productivity and quality, and I should now add to that, delivering what the customer needs to improve their business. All models from what I have read use pretty much the same phases described below, just in a different way. I’m going to discuss these phases, how they work and the ideas behind them in another blog.

The Waterfall Model, the daddy. This uses sequential movement from Analysis (requirements), to Design, to Construction, to Integration, to Testing, to Deployment to Maintenance. This is also known as a top down strategy. This is a strict ideal where once each phase is completed, only then can the next be started. Moving onto the next phase may be dependent upon a review, which I guess can allow some flexibility if changes are required, however once a phase has been formally completed, the model discourages revisiting or changes to the previous phase.

The Big Design Upfront (BDUF) model comes from the idea of the Waterfall model, and advocates investing a large amount of time on design (without the need for prototyping or any initial implementation at this stage) as to reduce the chances of bugs being created and found within later phases.

The Spiral model is similar in phases to the Waterfall model, but like the BDUF model in that the design phase is seen as the most important. It comes with the aim of combining both Design and Prototyping, resulting in a top down/bottom up combo strategy. The idea is iterative, however, not in the way Agile defines iterations. After exhaustively defining the requirements through a number of strategies, emphasis is placed on creating a preliminary design in which all possible alternatives are investigated and strategies are used to determine the best way forward. The aim of this phase is also to find and resolve risk in each element of the design. If risks show there is uncertainty within the requirements, prototyping can be used to find a solution and an update to the requirements can be made. A preliminary scaled down version of the system is then build from the resulting design. This model is then evolved via firstly evaluation (strengths, weaknesses and risks), and then following the model in another iteration of refining requirements, then design, construction and so on. This can then be repeated.

So what is iterative development in the way Agile sees it? Well, it is basically splitting a project up into small independent chunks, and then applying to Software Development Lifecycle to each chunk until the project is created. Agile development uses this is its basis, but it places higher value on communication and feedback through Test Driven Development practices (TDD) and release of features at regular intervals, rather than meticulous planning.

Coming back to the traditional goals of increased productivity, increased quality and development success (on time, on budget, and with all features) I should start by saying that XP is no magic bullet. It is described as a “Way of working differently, not faster, although it has been noted that Agile teams usually have above average productivity”.

So maybe it can hit these goals? But then that depends on whether you define success as stated, or whether this definition of success is limited as it does not take into consideration whether the project hits its business targets of generating cash or improving process or whatever it may be.

This is where an Agile model differs vastly from its predecessors. The aim of an Agile approach is to not only bring personal (increased productivity) and technical (quality of work) success, but also “organisational success”, i.e. to deliver value for decreasing costs by changing and adapting to changing business needs and requirements as and when decisions are made and new data is uncovered. This is done through TDD, regular reviews, continual code improvements and therefore enhanced maintainability.

Let’s look at the most complete Agile model, Extreme Programming or XP. XP gears itself towards technical excellence and code longevity using pairs programming where two people review every piece of code. It focuses on operational success by only releasing new features (a feature contains a number of tasks or stories) when they make business sense. This requires code integration from developers so features are ready for release when required. By only working on a single feature at a time and requiring completion before the next is started, this reduces unexpected delays and allows teams the freedom to change direction when business needs dictate them to. A team will commit to a number of tasks/stories for the length of a single iteration, usually a week or two. In a nutshell, XP is about responding to change and technical excellence. The phases of Analysis (requirements gathering), Design, Construction, Integration and Testing are performed simultaneously each day.

According to the book I just read, XP is about:

• Satisfing customers first with continuous delivery of functionality
• Always welcoming changing requirements
• Preference to shorter timescales for delivery, 2 weeks to 2 months
• Working with the business in a joint effort
• Using working software is the best measure of progress
• Attention to technical excellence for best agility and longevity
• Reflecting continuously to improve efficiency

The Analysis phase will consist of the Product Manager, someone who talks with the business and decides what needs to be done will create the requirements for a feature. Estimates by the coders will then allow more details to be added to the requirements before they can be coded.

The Design phase is integrated with coding and testing. As mentioned previously, TDD is used. The requirements are used to create customer tests, preferably with a customer, or someone who knows how the feature needs to work providing the insight and business logic. The tests are passed on to the coders who in pears create work on tasks/stories of the current feature, constantly refactoring and improving the code base. Once coding is complete, unit, integration and end to end testing are done. The code is then passed over for exploratory and performance/stability testing, with root cause analysis applied to any issues found. Regression testing is applied on integration to ensure nothing else has broken.

Deployment first occurs to a demo system. This is timely at the end of the current iteration. The real deployment is dependent on business needs.

After completion of the current iteration a period called retrospectives occurs. Here, the team talk about what went well, what didn’t, how the process can be improved, and anything which is hindering progress. Finally, the next iteration is discussed and planned.

This is a quick and dirty summary of the XP model, which is far more complex then what I have written here. For more information, I would suggest reading ‘The Art of Agile Development’ by Shore and Warden.

Lastly, I want discuss Scrum, another popular Agile model. Scrum is arguably a scaled down version of XP, for smaller development teams. The aim is to produce a feature, or set of features, which are tested and shippable, within a given time-frame (time-boxed), which rather than being pre-defined, is set by the team.
This iteration is called a Sprint. The features going into the Sprint come from what is known as the Product Backlog, a maintained (by the Scrum Master) set of prioritised (by the Product Manager) high level requirements. Any items not complete are removed from the Sprint. Which items go into the next Sprint is determined at a Sprint planning meeting.

As with XP, the aim of Scrum is to be able to adapt to changing business needs and by working in small Sprints, the focus for development can change and when required.

There are a number of further Agile models such as Feature Driven Development (FDD) built around a core set of industry best practice, Agile Unified Process (AUP) and Dynamic System Development Method (DSDM). I hope to look at these in due course.

Related posts:

1. Logically Modelling Requirements for Analytical Systems