The Waterfall Cycle

The waterfall cycle was one of the first development methodologies to be designed and works in a linear fashion with order as follows:

Requirements / Analysis: Finding out the software and system requirements for the project. This step also includes documenting responses from questionaires, as well as feedback from observation and structured interviews.
Design: Fesability based on TELOS:
- Technical - Is the project technically possible?
- Economic - Can the project be afforded? Will it increase profit?
- Legal - Is the project legal?
- Operational - How will the current operations support the change?
- Scheduling - Can the project be done in time?
Implementation: Producing and coding the program. Creating features and a working product
Testing: Making sure all aspects of the program work, through white/black box or alpha/beta testing. This also includes performance benchmarking
Maintainance: Correcting any issues & optimising inefficient areas of code. Also includes adaptive maintainance to keep the product up-to-date and compatible over time.

The waterfall model is a sequential methodology, meaning the next phase can only begin once the previous has been completed. This means that if one step must be revisited, all other steps have to be revisited. This makes the whole process take much longer, however allows for a lot more documentation. Due to its slow and inefficient design, waterfall isn't normally used today, however it was still used in many projects.

Pros Cons When is it used?

Simple and easy to understand, as each step is laid out in a clear order. Can't accomodate changes in requirements or specifications late in the process, as the whole development process must be redone from the start. Uncomplicated projects where requirements are firmly set in stone.

Lots of documentation, as each step must be described and recorded. Excessive of documentation takes lots of time, and efficient code isn't prioritised. Projects where the customer does not need an early build or prototype.

Easy to arrange meetings and schedule tasks. Sequential process makes judging progress easy Working software isn't produced till the cycle is finished. This means the customer can't have early access to give feedback. Short and simple projects

Pros	Cons	When is it used?
Simple and easy to understand, as each step is laid out in a clear order.	Can't accomodate changes in requirements or specifications late in the process, as the whole development process must be redone from the start.	Uncomplicated projects where requirements are firmly set in stone.
Lots of documentation, as each step must be described and recorded.	Excessive of documentation takes lots of time, and efficient code isn't prioritised.	Projects where the customer does not need an early build or prototype.
Easy to arrange meetings and schedule tasks. Sequential process makes judging progress easy	Working software isn't produced till the cycle is finished. This means the customer can't have early access to give feedback.	Short and simple projects

Agile Methodologies

One example of an agile methodology is Extreme Programming (XP):

Extreme programming consists of small teams working towards small releases. Projects are usually divided into iterations which are improved on with future iterations. Programmers work in pairs with one programming and one testing at all times. This allows constant checking to find bugs as soon as possible and get them fixed, meaning the result is usually very stable code. The customer is always available to communicate feedback, meaning any changes that need to be made can be done instantly, rather than having to wait up to months for new features to be developed. Extreme programming encourages not just communication, but teamwork. While pairs of programmers work together constantly, daily stand-up meetings ensure constant progress. This is essential as small teams are often only developing parts or modules of a full product.

Agile methods of software development were created by a group of software engineers in 2001. They got together to discuss the growing field of what were referred to as lightweight methods. In response to the issues created by the waterfall model, they decided upon the now referred to 'agile' model. They then wrote the Manifesto for Agile Software Development.

Pros Cons When is it used?

High quality of code, as there is continuous testing, and programmers are frequently swapping roles; reducing errors due to tiredness or tedium. Both programmers working in a pair must be in the same geographic location, as they are working closely with each other. In cases where the product needs to be implemented early on in the process..

Paired programming provides a sustainable pace, so there's less chance of tired programmers. The customer has to provide a representitive to work in collaboration with the programming team. Tasks in which the requirements are subject to change.

All programmers are following the same guidelines, meaning code should be more compatible and efficient. Working software isn't produced till the cycle is finished. This means the customer can't have early access to give feedback. Short and simple projects

Pros	Cons	When is it used?
High quality of code, as there is continuous testing, and programmers are frequently swapping roles; reducing errors due to tiredness or tedium.	Both programmers working in a pair must be in the same geographic location, as they are working closely with each other.	In cases where the product needs to be implemented early on in the process..
Paired programming provides a sustainable pace, so there's less chance of tired programmers.	The customer has to provide a representitive to work in collaboration with the programming team.	Tasks in which the requirements are subject to change.
All programmers are following the same guidelines, meaning code should be more compatible and efficient.	Working software isn't produced till the cycle is finished. This means the customer can't have early access to give feedback.	Short and simple projects

Rapid Application Development

Rapid Application Development can take several forms, but is mainly based around this model:

Decide requirements
Build prototype
Evaluate prototype with customer
Improve prototype, or release as final version based on feedback

Rapid application development (RAD) is a term originally used to describe a software development process introduced by James Martin in 1981. However today, it is used to refer to methodologies that use prototypes (a model with reduced functionality) and iteration (repeating the cycle many times until the final product is reached). Each prototype is evaluated by the customer, who leaves feedback. If necessary, the prototype is improved until it becomes the final product.

Pros Cons When is it used?

Useful when the starting requirements are unclear or are subject to change Creating efficient code is not a high priority Should only be used when a system can be modularised (split up) to be delivered in an incremental manner

Ideally results in a product with ideal usability as the consumer has given feedback on prototypes till they're happy with it. Uses up lots of the customer's time as they have to try out the product and give feedback till they're happy with it. When the customer is unsure of what the final product should look like.

Pros	Cons	When is it used?
Useful when the starting requirements are unclear or are subject to change	Creating efficient code is not a high priority	Should only be used when a system can be modularised (split up) to be delivered in an incremental manner
Ideally results in a product with ideal usability as the consumer has given feedback on prototypes till they're happy with it.	Uses up lots of the customer's time as they have to try out the product and give feedback till they're happy with it.	When the customer is unsure of what the final product should look like.

Rapid Application Development: The Spiral Model

The spiral model was first documented in 1988 by Barry W Boehm. It adds both risk analysis and RAD (Rapid Application Development) to the waterfall cycle. It splits the cycle into four quadrants four quadrants, consisting of stages.

Quadrant 1: Determining objectives and constraints
Quadrant 2: Evaluating alternative methods, Risk analysis (Risks are identified and solved is possible) If risks are too high, project may be cancelled
Quadrant 3: Developing a prototype, includes simulations, models and benchmarks. This stage involves developing, testing and implementing.
Quadrant 4: Planning for the next stage begins.

Pros Cons When is it used?

Ideal for projects that mayt be large/complex and risky, as risks are analysed. Complex management can result in poor scheduling or expensive development. When significant changes to the project are expected to occur during development.

Users are able to preview the system early (i.e at the end of a cycle). Process is fairly complicated, resulting in inefficient code. In high risk situations.

Changes in requirements of specifications can easily be made at the start of a cycle. Proper risk analysis (hiring well trained analysts etc) can get very expensive. When the customer is unsure of requirements/final functionality.

Programming Techniques

A Level Computer Science