Software Engineering - Methodologies

Fail to Prepare – Prepare to Fail

Software projects are HUGE, if you just sat down at your computer and started to hack away at code then you’re screwed from the moment you start. For projects of this scale we need a well defined process or ‘methodology’ to follow.

With a process, it becomes easier to plan and allocate your resources, the only problem is; good processes are hard to come by and no one process is appropriate for all projects!

 

The Processes

In  software engineering, the larger a project is, the more ceremony is required to complete the project. Because of this it really does depend on what process you use for your project.
Here’s a list of some of the processes in popular use today, ordered in decreasing amounts of ceremony required:

• Formal / Rigorous development processes – This type is only really suitable for small, well defined systems(projects)
  
• Waterfall processes
  
• Flexible Iterative processes – For example a Unified Process
  
• Agile Methods – Such as XP (eXtreme Programming) and SCRUM

Waterfall – Nan desu ka

The Waterfall process really can be visualized as a waterfall as you flow through each step in the process, and is usually the most popular process to use for software projects:

• Requirements gathering
• Systems Analysis
• Design
• Coding (Implementation)
• Testing
• Maintenance

However, the Waterfall process does have its downsides. For example, the later a problem is found then the more it will cost to fix it – so lots of effort has to be used at the beginning to get it right (which is impossible… unless you’re some kind of super genius?)

Yet, there are some advantages. Because of the fact that there are deliverables at the end of each stage, this can make budgeting and planning a lot easier.
Everything is well documented in the Waterfall process; so causes of problems can be clearly identified.

 

A non-flowing Waterfall

the Waterfall process has looooots of problems, in fact there's so many i really can’t be bothered to type them all out, so here’s a quick bulleted list of them :)

• Deliverables are often not produced on time or are “fudged” – fudged is the “blank tape trick”, where one team passes a blank tape of deliverables to another team because they never finished there side of the project on time.
  
• Analysis Paralysis can often occur – this is when the planning stage is never really finished, so coding can never start.
  
• The finished system that is eventually delivered never meets the users requirements – this is because with the Waterfall process you very rarely get the requirements correct the first time.
  
• Users never see anything working until very late so they can’t tell you that you misunderstood, as well as the fact that they probably change their minds about what they want (pfft, fussy users :P )

Agile Methods – What is it?

Agile Methods is one of the better processes to choose when planning a software project. This is because they aim to reduce the amount of required ceremony to a minimum and respond to changing requirements.

Agile methods are done iteratively, such as they consist of short cycles where part of the project is produced.

You have constant interactions with the users, so you’re constantly up-to-date on new requirements, and changes to the systems.

 

XP – eXtreme Programming

XP (no not Windows XP!) stands for eXtreme Programming, and is one of the most popular Agile Methods.

With XP, the requirements of a system are gathered from ‘user stories’ or ‘use cases’. XP also has the customer constantly available at all times.

The best thing of XP, is the way the programming is done. the method is called “Programming in Pairs”, this is where:

• One person codes
• The other persons reviews that code (for errors, and better ways of doing it)
• Then they swap positions

Like just mentioned above, you can refactor the code whenever and wherever possible, this is when the code is changed, but the functionality of the system stays the same. For example, more efficient algorithms.

 

Unified Process (UP) – What is it?

the Unified process what designed by the same three people who gave us UML, and is the nearest to an industry-standard process we have. Unified Process is again iterative, and assumes that you cannot get all of the requirements correct at the start (which is still true by the way… unless, erm… you have mind-reading powers?!? :D )

This process also distinguishes between phases, disciplines and artefacts – which i shall explain now:

 

UP Phases

UP Phases are sequences over time:

1. Inception – Initial feasibility study and project go-ahead
   
2. Elaboration – A more detailed study and production of high-rick parts of the system. Iterative except for very small projects
   
3. Construction – The bulk of the work which is done iteratively
   
4. Transition – Acceptance testing or maintenance. For example, moving on to the next project

UP Disciplines

This is the various activities needed in an Object-Oriented software construction project, such as:

• Requirements Gathering
• Domain Modelling
• Class Designing
• Coding and then
• Testing

If you look really carefully you will notice something. See it? those phases above correspond to the phases of the Waterfall process :) (well, ish) The only difference is that these ones are not done is a strict time order. There could be some coding near the start and maybe some requirements gathering towards the end.

 

UP Artefacts

Artefacts are the things you make as part of the processes, such as UML diagrams, Reports and the code itself.

 

Iterative Development

This is when development takes place in sets of timeboxed iterations that usually last between 4-6 weeks. Each iteration produces a production version of a subset of the required systems.

Timeboxing means that if you don’t get it done in time, don’t extend the time, just change the plan accordingly.

Only use iterative development on projects you want to succeed

By Martin Fowler