Call Now: 01935 310510
Email: software [at] flexss [dot] co [dot] uk
Email: software [at] flexss [dot] co [dot] uk
The Art of Developing a Good Software Process
Zen and the Art of Developing a Good Software Process
This article is one of our "zen series" software engineering articles, inspired by the Zen and the Art of Mororcycle Maintenance book.
Software development is a phrase covering a broad range of project types. Unsurprisingly the most efficient process actually depends upon the project type and the team available to do the work. This article introduces a few “classic” software development methodologies and identifies their pros and cons. An experienced software project manager can then adapt these classics to derive their own process that best meets their project needs.
Some definitions:
Software Development Methodology: - A documented collection of principles (and/or practices) for the development of software. Defines the approach to be taken to get to a delivered software solution.
Software Development Process:A document approach to completing the tasks that make up a software development methodology. A process breaks the methodology down into distinct tasks that can be allocated to teams and monitored for progress.
The importance of using the most appropriate software development process
Commercial organisations have realised that there is money to be made from software-processes by adding their own input onto classic software development processes and then marketing and selling their methodology by tying it in with tools, training and even accreditation programmes. For a large organisation that churns through lots of projects of a similar type this may be of value as you have the safety net of familiarity and “company standards”, ease of transferring staff between projects, and common set of progress metrics across projects etc. However commercialised processes are often designed to meet too wider audience and hence I would argue that a one size fits all approach is not best practice for all projects. The selection and adaption of the software process should be considered as one of the most challenging development tasks, but the consequences of this decision are significant. Get it right and the cost savings are very significant indeed, conversely if you get it wrong expenditure mounts up with no easy way to break out of the cycle.
Common Software Development Methodologies and Related Processes
Waterfall development methodology
Defined as a sequential set of phases, with minimal overlap where the entire system is tackled at once. Often coupled with a process that includes extensive up-front planning, tight budgetary controls and extensive documentation. This is a type of “top down” approach, also known as BDUF (big design up front).
V Model Development methodology
May be thought of as an extension of the waterfall model, it still breaks the implementation down into discrete phases, it recognises that there is feedback from testing that feeds in at the requirements level, it also shows at each stage the abstraction from the implementation. This is also a type of “top down” approach.
Spiral development methodology
Identifies a planned set of iterations, each having a goal with emphasis of evaluating the delivered iteration and re examining requirements and risks prior to commencing the next phase.
Iterative development methodology
Similar to the spiral methodology above, but with less emphasis on risk management – it is commonly considered to be an iterative waterfall approach. At the end of each iteration, there is a working system with planned features, subsequent iterations add to the functionality.
Agile Development Methodology
Agile development is an extension to the iterative methodology, it too breaks a project down into functional sets that are prioritised and then implemented. Each iteration is for a required functional set, at the end of each iteration there is a working system. With this approach working code is demonstrable early, albeit for a subset of functionality. The methodology if often tied in with less formal and less documented development techniques such as XP (extreme programming), but it needn’t be the case.
Software Methodologies – Associated Processes , Pros and Cons
Waterfall Software Development Methodology
| Associated Processes | Methodology Pros | Methodology Cons |
|
Typically company standards, or large organisation standards.
e.g. DoD 2716 (Us Milatary standard) plus other formal government standards for large projects from 1970s and 1980s.
|
• Easy to understand
• Top level management easy, as simple defined cut off points in process.
• Good for small projects with well understood requirements.
• Customers understand it!
• Good for implementation off load if requirements are fully documented and understood.
• Staff can be experts in a single process stage.
|
• Changing requirements, or improvements in requirement understanding not easily catered for.
• Working software is seen late on.
• High risk and uncertainty especially on large programmes.
|
V-Model Software Development Methodology
| Associated Processes | Methodology Pros | Methodology Cons |
|
Typically company standards, rather than popularised process.
|
• Easy to understand
• Deliverables easily defined for each stage.
• Testing considered fairly early, improves likelihood of success.
• Top level management relatively easy as stages are rigid.
• Customers can understand the process and relate to progress reports.
• Staff can be experts in a single process stage.
|
• Changing requirements can be expensive to accommodate.
• No focus on early prototyping or de-risking
• High risk on large programmes.
• Working code seen late on.
|
Spiral Software Development Methodology
| Associated Processes | Methodology Pros | Methodology Cons |
|
Tailored UP (Unified Process) e.g. Rational Unified Process (Trade Marked by IBM) Clean Room
|
• Easy to understand
• Plenty of risk analysis, makes this attractive for “high-risk” or cutting edge projects.
• Suits large projects and mission /safety critical software development.
• Working software seen early.
|
• Not suitable for small projects, due to admin cost per cycle.
• Hard to estimate costs and timeframe, especially if full scope of requirements and their relative risk is not known up front.
• Tendency to do the easy stuff first must be overcome.
|
Iterative Software Development Methodology
| Associated Processes | Methodology Pros | Methodology Cons |
|
Tailored UP (Unified Process) e.g. Rational Unified Process (Trade Marked by IBM) Clean Room, Internal Company Standards
|
• Combines the well understood waterfall model with iterations, making change management easier.
• Can suit large projects, especially those where payment milestones can be tied to iteration definitions.
• Working software can be seen early.
• Working software seen early.
• Teams can be stage based, rather than functional area based. Stage off-load is theoretically possible
|
• No overlap between phases, leads to teams specialised on stage rather than function – good communication is essential.
• Dependency on previous stage, means scheduling difficult when things go wrong.
• Tendency to do the easy stuff first must be overcome.
|
Agile Software Development Methodology
| Associated Processes | Methodology Pros | Methodology Cons |
|
Agile Data, Agile Unified Process (AUP), SCRUM, AMDD
|
• Combines the well understood waterfall model with iterations, making change management easier.
• Adaptive to meet stakeholders needs.
• Working software is seen early.
• Hybrid between top-down and bottom-up development.
• Adaptive and responsive to requirements changes.
• Focuses on value to the stakeholders.
• Working functionality prioritised.
• Defines guiding principles and development roles.
|
• Means different things to different people, need to redefine the core agile principles in terms of the stakeholders interests up front.
• Less well understood, often misunderstood, can be hard to attain acceptance of this process from the customer.
• Harder to manage, but applying the appropriate process with the methodology helps.
• Difficult to explain to formal organisations.
• Principles and process does not easilly map onto safety / mission critical standards for software development.
|
Process Selection and Process Adaptation
There is growing evidence from project manager surveys that the waterfall model is failing to deliver complex software solutions. Iterative methodologies have a higher success rate. Therefore for any software project that is more than a few man months in length the best methodology choice is an iterative one.
That leaves the decision between, traditional “Iterative” development or an “Agile” development methodology and then choosing (and adapting) the process that goes with it to meet your needs and also the expectations of your customers and other stakeholders.
final word....
Choosing the right process for a particilar project is a key decision, consider your options carefully. This is an article, but the topic really deserves a whole book, the right choice is dependant upon your circumstances.
Flexible Software Solutions offers software process improvement advice throughout the UK,contact us for more details.
We believe this article (although brief) to be accurate. If you have comments or suggestions, or believe there are inaccuracies in this article - let us know, we appreciate your feedback.
The author (Rob Harwood-Smith) has been developing software and managing projects and teams for more years than he cares to mention, his experience ranges from embedded safety critical software, large scale database systems and also to custom business software solutions. After a few years as a software consultant Rob joint founded Flexible Software Solutions.
