2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

Home All topics Software engineering principles Approaches to software engineering

Approaches to software engineering

A Level Software project management

The software industry has grown from nothing in 50 years. As the industry has expanded, so have different programming paradigms, which have
brought about a number of different tools and techniques. For example, early software development had a focus on a structured approach, both
to code generation and project development. The waterfall method originated in this context. Modular programming, i.e. decomposing projects
and dispersing the parts to teams, prompted many early refinements to working practices, such as style guides. The development of OOP and
the availability of off-the-shelf classes probably sparked the move to more iterative development. Event-driven programming was a driver for
rapid prototyping.

Modern large-scale software development now involves the production of the most complex systems ever developed — often utilising systems
and data from many third parties, over which an organisation has limited control. It is in this context that functional programming as a paradigm,
with its emphasis on immutable states and minimising side effects, is now becoming more popular.

Managing multiple teams requires adherence to common conventions and standards. Organisations that develop systems will have their own
standards and preferred methods. If you know anyone who develops software, you might find it interesting to find out the methodology that they
use and how it works in practice.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 1/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

A Level The waterfall lifecycle

In the early days of systems development, the stages of a project were carried out sequentially. This meant that the entirety of each stage had to
be completed, formally documented, discussed, agreed, and signed off before the next stage could begin. This has been described as the
waterfall lifecycle.

This method requires a lot of investment in the early stages, when developers must carry out analysis and write detailed descriptions of the
requirements. Once the requirements are agreed, they are 'fixed'. The approach was adopted from practices in engineering and construction,
where it was crucial that the specification of the design for large civil and mechanical engineering projects be finalised before construction
began.

Figure 1: Waterfall method

When software development moved beyond the realm of individual developers and small groups, formal project management methodologies
were developed that provided a common framework to allow people to manage large projects. Two well-known approaches adopted at the time
were SSADM (Structured Systems Analysis and Design Method) and PRINCE (Projects in Controlled Environments), both of which have a
heavy emphasis on documentation. These approaches complemented the waterfall method and required each stage to be 'signed off' by the
client and developer before the next stage could begin.

Suitability and benefits

If the user requirements are clearly understood and well specified, the waterfall lifecycle methodology can be suitable. However, for innovative
and complicated projects where not much is known at the beginning, this approach is unlikely to be successful.

Despite its disadvantages, the approach is well structured and well understood. Having clearly defined stages makes the project easier to plan,
and there are clear lines of responsibility. Large projects can be split into a set of smaller subprojects and each can be approached using its own
'waterfall'.

Criticism
The waterfall method is criticised for its rigidity, the large volumes of documentation that it requires, and the lack of user involvement. The client is
involved in signing off on the analysis and evaluation, but has little input during the design and build stages of the project.

It is heavily dependent on an accurate specification of the requirements. Often the client is not able to fully articulate what is wrong with the system
that they are using, or what they really want. They may not really understand the capabilities of technology, or the risks of being 'early adopters'.
Also, sometimes the development process takes so long that the original requirements no longer reflect what is needed.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 2/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

The testing phase is scheduled towards the end of the development cycle, which means that if defects are found, there may not be sufficient time
to address them. Finally, the stakeholders do not have a chance to review the end product until after the release.

A Level The spiral model

The spiral model is a development method that uses the same steps as the waterfall method, but also uses project cycles, each culminating in
a version of the software (a prototype) that is formally reviewed to inform the next cycle. This pattern is repeated until the final product is created.
The method has a specific focus on identifying and managing risks. Each cycle is split into four stages:

Determine objectives
Identify and resolve risks
Develop and test
Plan (the next iteration)

Cumulativ e cost

1.Determine Progress 2. Identify and

objectives resolve risks

Operational
Re v ie w Requirements
plan Prototype 1 Prototype 2 prototype
Concept of Concept of
operation requirements Detailed
Requirements Draft
design

Development Verification Code

plan & Validation

Integration
Test plan Verification
& Validation
Test

Implementation

4. Plan the Re le ase

next iteration 3. Development
and Test

Figure 2: The Spiral approach

Conny via Wikimedia Commons, [Public Domain]

The risk management stage is a key difference between the spiral method and other approaches. In any iteration, if the risks cannot be managed
successfully, the project can be stopped.

Suitability and benefits

The emphasis on risk management makes the spiral approach suitable for large-scale, high-risk projects. These might be projects where
technologies are unproven or multiple organisations are involved.

Criticism
Project teams will need to include a risk management expert (someone who has been trained to identify and quantify risk). This will add to the
cost of the project.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 3/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

A Level Agile methodologies

In general, the agile approach advocates building prototypes, testing, and incorporating feedback as soon as possible. Once a
prototype is built, it is reviewed to see what is good or bad about it. At the next stage, the prototype can be modifed and new features can be
added if required.

Most organisations now use a more agile approach. For example, the Raspberry Pi projects site was developed using an agile methodology: it
started off with few projects and limited functionality; today, it contains hundreds of projects and many additional features for users. Starting with a
small prototype allowed the developers to make frequent, iterative changes to build a product that is fit for purpose as well as easy to adapt.

Agile methodologies were first described in the Manifesto for Agile Software Development produced by a group of industry experts. The
manifesto proposed twelve principles for software development:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Suitability and benefits

The agile approach is suitable for many projects and is widely used. Some people argue that the agile approach is suitable only for small- to
medium-scale development projects. However, large projects can be decomposed (broken up into smaller subprojects) so that work can be
allocated across multiple teams and managed separately.

Criticism
The use of prototypes is often criticised for giving rise to scope creep. This is where the client continually adds to the requirements when each
prototype is evaluated (as they think of new features or functionality).

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 4/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

A Level Rapid application development (RAD)

Rapid application development (RAD) is an agile approach to software development based around prototyping. It puts less emphasis on
rigid planning and more emphasis on an adaptive process.

A prototype is a version of the system, or part of the system, that lacks full functionality. For example, a prototype GUI may provide a mock-up of
the screen layouts, but the buttons may not do anything. A prototype can be shown to the user, who can give feedback, and this can inform the
development process. Users often find it much easier to provide constructive feedback on something that looks like the real thing, rather than on
paper sketches or drawings. Prototypes are often used in addition to, or sometimes even in place of, formal design specifications.

Suitability and benefits

RAD is especially well suited for developing software where the requirements are unclear, or for projects where the user interface is an important
part of the project. It is good for smaller projects where there are smaller development teams that include users or their representatives.

Because of its emphasis on continuous feedback, it is not suitable for projects where the users are hard to contact or do not want to be actively
involved.

Criticism
Critics of the technique argue that it encourages sloppiness — a 'try-it-and-see' approach — and ignores the importance of making sure that the
overall system architecture is right. Also, projects can sometimes take far longer than anticipated where users make continuous requests for
minor changes.

A Level Extreme programming

Extreme programming (XP) is another agile approach to software development. However, where RAD focusses on the refinement of the
objectives, XP focusses on the refinement of the code.

The core principle is that there should be frequent releases in short development cycles, and continual communication with the customer. In XP,
the user (or a representative of the users) is part of the development team. They are there to focus on the 'user journey' and to provide feedback
at every stage of the project.

There are several key differences between the XP method and RAD. The importance of code quality is paramount in XP. The development and
feedback loops are much shorter, and the releases are not called 'prototypes', but are working versions of a system component.

At the start of each release, there is a planning phase that determines what will be developed and how it will be tested. Programming is done in
pairs, with two programmers working in collaboration to develop, test, and review code. There is a heavy emphasis on development standards
and strict version control. At the end of each release, there is a listening (feedback) stage that will inform the next release.

Suitability and benefits

The main benefit of the extreme programming approach is that code quality is high. This means that there are fewer bugs, and therefore, less
time needs to be spent fixing them. Also, having a user on each team means that there is a strong focus on getting the user journey
(requirements) absolutely right.

Criticism
The main criticism of extreme programming — as with all forms of iterative development — is that of scope creep, due to a lack of firm
requirements at the outset of the project. In addition, it requires a high degree of communication and collaboration, which can sometimes be
difficult, or even impossible, if team members do not work in the same office. As with RAD, the client has to commit to having one or more users
actively involved throughout the project.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 5/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

A Level Scrum and Kanban

Scrum and Kanban are popular methodologies that implement an agile approach.

Scrum
A Scrum project has three roles: the Product Owner, the Scrum Master, and the Team.

The Product Owner is responsible for maintaining the business aspect of the development: managing the stakeholders, setting
priorities concerning the released features, communicating business decisions, and ensuring the business value of the product. They
provide 'user stories' and the developers translate these into specific tasks; an overarching goal or feature of the project is called an 'epic'.
The Product Owner is responsible for the Product Backlog, which is an ordered list of everything that is known to be needed in the product.
The Product Owner determines the priorities within the Backlog (because they know what is valuable in terms of business).
The Scrum Master is not the team leader — in fact, there is no team leader. The Scrum Master safeguards the team's performance and
the quality of the product. They work to remove any impediments that are preventing the Team from achieving its goals, and facilitate
practices that improve the Team's productivity.
Each Scrum Team is self-organising, and the entire Team addresses any issues or problems together. This means that there is a wide
sense of project ownership for the whole Team, and it encourages creativity and innovation.

Projects are run as a series of Sprints. Each Sprint will take no more than one month and will deliver something for the client to review. A design
and flexible plan will guide the work of the Team throughout the Sprint. Every day, there is a Daily Scrum, which is a 15-minute 'stand-up'
meeting to review progress and create a plan for the next 24 hours.

At the end of each Sprint, there is a Sprint Review:

The Team demonstrates the new features to the Product Owner and the stakeholders
The Team reports on, and discusses, what went well during the Sprint, what problems arose, and how they were solved (or not)
The Product Owner reports on progress against the Product Backlog
The participants discuss any new requirements or changes to existing requirements

The Sprint Review allows the team to receive feedback from users (e.g. stakeholders). Based on that feedback, the Product Owner adapts the
Product Backlog to ensure that the 'learning' has been taken into consideration for the next Sprint.

At the end of the Sprint, there is a Sprint Retrospective meeting that focusses on the relationships between the people in the Team and
evaluates the processes that were followed. This meeting is not about the product release, but rather about the working environment, the quality
of collaboration, and the Team's processes.

Kanban
Kanban is a popular framework that promotes full transparency of work, and focusses on maximising work throughput, i.e. on moving things
from 'In progress' to 'Done'. In Japanese, 'kanban' literally translates to 'visual signal'. The work of all Kanban teams revolves around a kanban
board, allowing team members to see the state of every piece of work at any time.

Some organisations use whiteboards, but most use a virtual board system, such as Trello.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 6/7

2/5/24, 10:49 AM Approaches to softw are engineering — Isaac Computer Science

Figure 3: Kanban board

At a minimum, the board will have four columns: 'To do', 'In progress', 'Blocked', and 'Done'. In a typical scenario, every task is represented
by a separate card that is labelled with the name of the task and, for work in progress, the name of the team member who is responsible for its
delivery. The card will contain a short description of the task and a list of anyone else who is working on it. There can be links to supporting files,
and there is often space for comments and other useful information.

Allowing team members to see the state of every work item at any given point in time, as well as all of the associated details, ensures increased
focus, full traceability, and fast identification of blockers and dependencies. A Kanban project has a continuous flow of work (in contrast to
Scrum's defined sprints). Once the team completes a task, they take the next piece of work from the backlog.

A key concept of the Kanban approach is that of limiting 'work in progress' and focussing on maximising work throughput. It is thought that
multitasking leads to inefficiency. A Kanban team is only focussed on the work that's actively in progress. Once a team member completes a
task, they move on to the next task at the top of the to-do list. The project manager can reprioritise tasks in this list without disrupting the work of
the team.

This page contains content reproduced from the Manifesto for Agile Software Development, (© 2001 Beck, Beedle, Bennekum, Cockburn,
Cunningham, Fowler, Grenning, Highsmith, Hunt, Jeffries, Kern, Marick, Martin, Mellor, Schwaber, Sutherland and Thomas) "This declaration may be
freely copied in any form, but only in its entirety through this notice."

All teaching materials on this site are available under the Open Government Licence v3.0, except where otherwise stated.

https://isaaccomputerscience.org/concepts/prog_softeng_approaches?examBoard=all&stage=all&topic=softw are_engineering_principles 7/7