Software Engineering
Introduction
How well are we doing as developers?
To answer that question, The Standish Group began researching the outcome of software development projects over 25 years ago.
Survey results have been analysed and published at two-yearly (now yearly) intervals since 1994 as “The Chaos Report”.
It’s a good place to start…
COMP3297: Software Engineering 2
3
The Standish Chaos Report
The results of the first survey, in 1994, were a huge shock to the industry at that time.
The 1994 Report found:
Only 16% of development projects in the USA were completed on-time, on-budget, and with all the originally planned features.
31% were cancelled before they were completed.
The remaining 53%, on average:
overran their original cost estimate by 89%,
exceeded their original schedule by 122%,
provided only 61% of the features in the original specification.
COMP3297: Software Engineering
Chaos Report: Traditional Resolution Definition
Focus is on quality of development.
Classifies software projects as:
Successful
Completed on time and within budget, offering all features and functions as initially specified
Challenged
Completed and operational, but over-budget and over-time estimate, or offers fewer features and functions than originally specified
Failed
Cancelled at some point during development or never used
COMP3297: Software Engineering 4
All CHAOS Reports to 2010: Standish Group
Year studied 1994 1996
1998
2000
2002
2004
2006
2008
2010
16
53
31
27
33
4
0
26
46
28
28
49
23
34
51
15
29
53
18
35
46
19
32
44
24
37
42
21
0% 20%
40% 60%
80%
100%
COMP3297: Software Engineering
Succeeded Challenged
Failed
5
Chaos Report: Modern Resolution Definition
Should we really judge “success” in terms of delivering the system exactly as specified at the beginning of the project? Some managers might say “yes”, but users will say “no”.
Reacting to criticism, Standish changed the definition in 2015 and re-analysed data for the past few years. The new definition is:
Successful
Completed on time and within budget, offering all features and functions as initially specified with a satisfactory result.
Here the different definition of success reflects how teams were actually judged by clients: for example “solution was delivered and met its success criteria within a range acceptable to the organization”
Challenged
Completed and operational but over budget, late, or with unsatisfactory results Failed
Cancelled at some point during development or never used
COMP3297: Software Engineering 6
Recent CHAOS Data: Modern Resolution All approaches grouped for each year. Data to 2015.
Year studied
2011
2012
2013
2014 2015
0% 20% 40%
60% 80% 100%
29
49
22
27
56
17
31
50
19
28
55
17
29
52
19
50,000 projects worldwide, from small enhancements to massive re-engineering
COMP3297: Software Engineering
BTW, is cancellation always a bad outcome?
7
Larger projects are particularly risky.
CHAOS RESOLUTION BY PROJECT SIZE
SUCCESSFUL
CHALLENGED
FAILED
GRAND
8%
27%
65%
LARGE
13%
36%
51%
MEDIUM
14%
39%
47%
MODERATE
30%
46%
24%
SMALL
70%
18%
12%
COMP3297: Software Engineering 8
Traditional vs Agile
Brief introduction later
Traditional
We’ll revisit
9
Early approaches to software engineering were modelled on what worked for other engineering disciplines like civil engineering to produce high-quality results, on a predictable schedule and budget.
They emphasised:
– careful, detailed planning at the beginning of a project
– extensive documentation including complete specifications of requirements, analysis and design models, and formal quality assurance documentation
– usually, commitment to a contract
This is known as heavyweight Plan-driven development, or Plan-and-Document
methodology.
COMP3297: Software Engineering
Traditional
Planning and thorough specification is still required, in some form, for critical systems and massive, complex multi-year projects like developing control systems for a new aircraft.
But the overheads are huge. Too big for smaller products where the documentation may never even be read.
Also, knowledge is never perfect at the start of a project. Initial specifications will be wrong and rework will be needed.
Plan and Document approaches aren’t flexible enough to respond to change and work will need to be redone after it is “finished”. Means software can’t be delivered quickly in most cases.
COMP3297: Software Engineering 10
Agile
The idea is to take a more lightweight approach, dropping rigid plans and documentation and focusing on the software itself.
Agile approaches deliver working software to customers quickly, get feedback for changes and build those into future versions, adding further functionality and repeating the cycle.
Incremental development
Agile aims to deliver what is valuable and to avoid working on anything that is not of value.
COMP3297: Software Engineering 11
The Agile Manifesto
“Manifesto for Agile Software Development”
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions Working software Customer collaboration Responding to change
over processes and tools
over comprehensive documentation over contract negotiation
over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
COMP3297: Software Engineering 12
Success rates improving
Data (www.cio.com) show an improvement from 2016 onwards. “Champion” organizations exist that can achieve 80+% success rates.
Possible factor is the adoption of agile approaches:
“…organizations that embrace agile methodologies and practices for project management are more likely to be successful.”
“…mindset shift may have a lot to do with the increasing success rates of projects, as success is less about following strictly defined processes and more about agility and creativity.”
For large projects (2018): Large agile projects succeed at twice the rate of non-agile projects, and fail half as often.
COMP3297: Software Engineering 13
Traditional vs. Agile. All project sizes.
Period: 2011-2015
Trad Agile
Period: 2013-2017
Trad Agile
0% 20% 40%
2020 Report (Secondary source)
Trad Agile
11
60
29
39
52
9
0% 20% 40%
60% 80%
100%
26
53
21
42
50
8
60% 80%
100%
14
57
29
42
49
9
0% 20% 40% 60% 80%
100%
COMP3297: Software Engineering
14
What makes software development different?
COMP3297: Software Engineering
15
Other branches of engineering seem to achieve better results with traditional approaches.
Why is it so difficult to achieve similar success in software development?
What makes software development different?
1. Software is relatively easy to create and modify – it’s not hard to write code – but it is not easy to create or modify software well.
Consequences: Poor quality products
Poorly trained developers can easily create poorly designed products that work but that are very fragile and difficult to maintain even by good developers.
Similarly, it is easy to destroy a good design by modifying it poorly when adding new code.
Consequences: Software decline
Software doesn’t “wear out”. It gets continually modified over its long lifetime and tends to get worse – more complex – until further changes can’t be done safely.
COMP3297: Software Engineering 16
What makes software development different?
2. Unlike many other engineered products, the software itself is invisible to customers and users.
They see only the effect of the software. They can’t see the amount of work needed to develop it.
And, related to last slide, they can’t see poor code quality.
Consequences: Unreasonable expectations
Customers, users and, often, managers underestimate the time and effort needed for development – both initial development and requested changes
Customers expect changes can be made easily at any point in development
COMP3297: Software Engineering 17
“Just a small change – we want the bridge to do this.”
“Oh, and can you add another level for trains?”
COMP3297: Software Engineering 18
What makes software development different?
3. Software systems, particular large ones, are highly complex.
For a developer or maintenance engineer working on a component, it can be difficult to fully understand its effect on the rest of the system.
Analyzed and retrieved late last year:
How big: how many lines of code?
COMP3297: Software Engineering 19
What makes software development different?
A few other factors to consider:
4. Development is still a highly skilled task at all levels.
Unlike other branches of engineering, not much can be automated. But we can reuse.
5. Software engineering usually requires experts in one domain (software development) to create systems for members of another domain.
We usually don’t have expert knowledge of the application area – we aren’t the future users of the system.
6. Typically, there are many possible solutions to a particular problem, and no single, standard, best solution.
We constantly must evaluate costs versus benefits.
COMP3297: Software Engineering 20
Result: Crisis?
Developers are required to develop and maintain complex systems without adequate resources – insufficient staff, budget and time. Often it is their own fault.
Developers in many cases are unable to satisfy the expectations of managers and customers.
Under pressure, quality is the first victim. A lot of existing software is of poor quality … and is becoming worse.
To fight this, we first need a software process that helps us tackle our two main enemiesà
COMP3297: Software Engineering 21
Main enemies: 1 Complexity
Large systems are complex – many components must interact to provide the functionality required by users
The problem the system is required to solve (the required functionality) is usually complex too. The real-world is messy.
Because large systems are developed in teams, the required communication and coordination is also complex.
Our approach to development must handle complexity:
in the system being developed
in the development process itself
COMP3297: Software Engineering 22
Main enemies: 2 Change
Large systems take a long time to develop
their environment and the needs of stakeholders are likely to change
during development
if ignored, it can happen that technical development is executed
“perfectly” but the product is a failure Large systems have a long lifetime
can expect a lot of modification during that lifetime in order to adapt to new requirements or new technology – the real-world changes
Our approach to development must support constant change:
during initial development, and
after delivery
COMP3297: Software Engineering 23
Software Engineering to the rescue!!
Software Engineering exists as our attempt to tackle these problems.
COMP3297: Software Engineering 24
Engineering Software
Software Engineering takes us:
FROM:
undisciplined and unpredictable software development
TO:
a systematic, well-understood, repeatable
process
for creating high-quality software products
COMP3297: Software Engineering
26
Software Process
A set of activities and the way those activities are structured to develop a software product
Systematic, but less than other branches of engineering.
So, the process has two aspects:
It defines the activities
It specifies how they are organized into a project.
The objective of that project is to transform a user’s true needs into a software system.
Different projects will have many broad activities in common. But that does not mean all projects should be organized the same way.
Software engineers select and customize a process model to suit
the needs of their project.
COMP3297: Software Engineering 27
What are the general steps in any technical project (not only software projects)?
Analyse the domain and customers’ needs. Specify what is required to satisfy that need.
Design and build a solution
Make sure the “solution” really solves the customers’ problem
Maintain it until the end of its operational lifetime
COMP3297: Software Engineering 28
Technical Activities in software development
The next slides are a bit of a boring list.
Why should you know this?
Do we do all of this?
Grouped into four fundamental software engineering activities:
Software Specification
Software Development Software Testing Software Evolution
COMP3297: Software Engineering
29
Software Specification
Also known as requirements engineering. The objective is to understand and define:
– what services the system is required to provide.
– what constraints there are on the system’s operation and development.
Very important to get both of these right.
Costs of mistakes can be huge – it means you are building the wrong system.
COMP3297: Software Engineering 30
Software Specification Activities
Requirements Elicitation and Analysis
Elicitation is discovering stakeholder requirements.
Learn about the problem domain. Typically, build models of its key concepts and relationships.
Identify the scope of the system.
Build an understanding of user tasks and goals, and associated business
objectives. Discover users’ quality expectations.
Then analyse that information to better understand:
– functional requirements
– quality constraints on how we must deliver that functionality
– the relative importance of each functional and quality requirement.
Objective: understand the problem and what is needed as a solution.
COMP3297: Software Engineering 31
Software Specification Activities
Requirements Specification
Translate the results of elicitation and analysis into written requirements and models suitable for their intended audiences.
Often in a more abstract form for customers and end-users, and a detailed form for developers.
Objective: document the requirements
Requirements Validation
Check that the specified requirements are realistic, consistent and complete. Fix them if they are not.
Objective: ensure we have specified the right system
COMP3297: Software Engineering 32
Software Development
This takes us from the requirements specification to an executable system.
It involves design, to specify the structure of the software and its data models, and then implements those designs.
COMP3297: Software Engineering 33
Software Development Activities
Software Design
Architectural Design:
The overall structure of the system in terms of its major components, how they interact, and how they are distributed across processors.
Component Design:
The internal design of components or, if available, suitable reusable components (for example, Commercial Off-The-Shelf software components [COTS] that can be purchased rather than built).
Database Design:
The data structures that must be persisted and type of DBMS, if any, that will be used to do that.
User Experience Design:
How the user will interact the system
Software Implementation
Writing the code. Common to require programmers to unit test their own code
before delivering it.
COMP3297: Software Engineering 34
Software Testing
Confirm that the system:
• conforms to its specification
Verification – did you build the system right?
• satisfies the true needs of its users and customers Validation – did you build the right system?
COMP3297: Software Engineering 35
Software Testing Activities
Component Testing
Testing a single component independently looking for defects. Typically done by developers as part of their unit testing
Integration and System Testing
Components are tested together with other components on which they depend. We are looking for defects in their interfaces and interactions.
Then test to see whether they satisfy functional and quality requirements.
User Acceptance Testing
Before a system goes into production (that means deployed for use in the real world), it is tested by the customer, ideally with real data under real world conditions.
This is where we try to answer that question “Did we build the right system?”
COMP3297: Software Engineering 36
Software Evolution
The maintenance stage which begins when the system is deployed. It continues until the end of its operational lifetime.
Modifying the system to:
• Fix defects
• Add new functionality, modify existing functionality, improve performance, etc.
• Adapt to new technology
• Improve its maintainability
Since change also comes during development, it is useful to view the whole of development as an evolutionary process from the start of the project to the end of the system’s life.
COMP3297: Software Engineering 37