Home 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.

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.

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)

Cumulative cost

1.Determine Progress 2. Identify and

objectives resolve risks

Operational
Review 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 Release

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.

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).
 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.

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.
 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.