CSCI3100: Software Engineering

Software Development

January 5, 2025

Why learn about software engineering?

Software is eating the world

• Software taking over the economy

• AI saving the world
– E.g. protect us from harms like the climate crisis and provide an avenue for new
medicines and space exploration

Learning software engineering could help you get a job (unless AI can replace programmers)

What is software?

• A set of items of objects that form a configuration consists of

– Programs
– Development documents
– Data
– User guides
• Does not exist in nature, an engineered artifact
– Will not die, but will degrade
– Complex

1
Software exists everywhere

• Product
– Delivers computing potential
– Produces, manages, acquires, modifies, displays, or transmits information
• Vehicle for delivering a product
– Supports or directly provides system functionality
– Control other programs (e.g. OS)
– Effects communications (e.g. networking software)
– Help developers to build other software (e.g. IDE)

Software application categories

• System software
• Engineering/scientific software
• WebApps (Web applications)
• AI software
• Ubiquitous computing - Networks of sensors and computing units built into every objects
• Net souring - The web as a computing engine. E.g. Ethereum
• Open source - Source code open to the public
• Others: Data mining, grid computing, cognitive machines, …

Difficulties in writing software

Software engineering is one the most complex things humans have ever done

• Intangible - Unlike building a bridge in civil engineering where we can detect cracks
• Hard to see whether the software is working right, especially at grand-scale
– What if the software is wrong, and the tests are wrong? Wrong + wrong =>
seemingly right �

• Virtual world is huge, but our brains are slow and small
– Process only 10 bits/s
• Software development is a complex and dynamic team sport that requires collaboration
and effective communication
– Specification does not align with the requirements?

2
 – Wrong units used?
∗ NASA lost the $125 million Mars Climate Orbiter spacecraft after a 286-day
journey to Mars

Maintaining software

Software is not “write once and for all”. It must be changed to

• Align with new computing environments or technology

• Meet new business requirements
• Be more interoperable with other more modern systems or databases
• Be viable within a network environment
• Bug fixes. Yes! Bugs can be dormant and lurk in the dark, wait for the best moment to
bite you…
– Discovery of 24 years old bug in the Linux kernel TCP implementation

If the software is not written in the most desirable way of “high cohesion and low coupling”

• Replacement software must be developed, which is time consuming

• Bugs can easily be induced

Unsuccessful software development is in fact not uncommon:

• The Standish Group releases a report on software development every year

– 2015 report
∗ Succeeded, Challenged - Delivered something but: reduced functionality, late,
over budget, Failed - Cancelled without delivering anything
• In 2015, 19% out of ~5000 projects failed (cancelled or people did not use the software
in the end)

3
Why do (software) projects fail?

• A very interesting website… Catalog of catastrophe

• Many possible factors
– Poor testomg strategies and quality management
∗ E.g. In 2022, a project in Australian Stock Exchange failed to be delivered
despite two years of delay. Not only did the project delay, but the software was
also written so bad that 50% of the code had to be rewritten…

Figure 1: Review on the failed Australian Stock Exchange’s project development process by
Accenture

Legend: green (satisfactory), orange (developing), yellow (emerging), red (ad-hoc)

Software development process

• Systematic software development activities that every one should learn and follow
– Roadmap/template to success
– Goal: Meet user expectations with the best implementation within certain budget
regarding time and money
• No single process model suits all scenarios

4
 – Process model on textbooks are just templates on which necessary engineering de-
cisions are expected to be made to suit your needs

• Describe how the following activities are ordered, planned, and monitored
– Requirements capture
– Design
– Implementation
– Testing, debugging
– Maintenance
– Management of the software development process

What software development looks like?

“Mobile suit” development process in Gundam universe:

1. Soldiers meet engineers to specify needs => Soldier needs

2. Engineers design the mobile suit’s appearance, layout, functions, output power, user
interfaces etc, in high level according to the available budget => High level plan
3. Tech lead and organization approve the plan
4. Come up with detailed designs => Detailed plan
5. Tech lead and organization approve the plan

6. Build the mobile suit => Prototype, 𝛼 model, 𝛽 model, MKI, MKII etc
7. Tech lead and organization approve the builds
8. “Product” validation and testing
9. Factories start (mass) production
10. Soldiers start piloting the mobile suit in real war zones

5
 Image source

11. Maintenance
1. Collect real data (not by simulation) to improve the design
2. Fix defects, upgrade aged armour etc

Is the process similar of different from software development process?

Five main elements in software development process

1. Requirements capture
2. Design
3. Implementation
4. Verification
5. Operations and maintenance

• Which one is the most difficult to achieve well?

• How should they be ordered?

6
• Requirements capture - Identify what the software must do (not how)
– After a feasibility study of customer’s demand
– Identify and document the exact requirements for the system
– Involve customer, developer, and user
– How to resolve conflicts when multiple stakeholders have different requirements?
– Prioritise which requirements should be met and in which release
– How to deal with evolving requirements?

• Design - How should the software do that?

– A software system is developed to meet the requirements
– Higher level than code
– Sometimes a modelling language (e.g. unified modelling language (UML)) is em-
ployed
– Multiple levels of design:
∗ Architectural design e.g server-client, peer-to-peer
∗ High-level design e.g. object-oriented class partition
∗ Detailed design e.g. Use quick-sort to solve them all!

• Need to consider: how comprehensive the design is, robustness to requirement changes,
security, efficiency, division of responsibility, testability etc

• Implementation - coding and beyond, to produce the actual product for the customer
– Main ideas on modules (units): divide and conquer.
– Super-detailed design internals (no word can describe the design, only code can do)
– Coding
– Unit testing
– Managing code evolution
– Writing developer-oriented documentation

• Verification

7
 – Testing at multiple levels: unit tests written before coding by developers, during
coding by developers, user acceptance testing
– Debugging: Why did it crash? Why doesn’t it work? “It works on my computer”

• Operations and maintenance - Any post-release change

– Corrective, adaptive, perfective maintenance
– Bugs fixing
– Enhance/optimise the current functionality
– Refactoring

An exaggerated example

• User expectation Image source

8
 • Implementation Image source

In general, the most difficult step in the process: Requirements Capture, to identify user needs
accurately

“You don’t know mechanics,” the en-

gineer (right) told Char Aznable (left) (Image source unknown)

Software engineering:

1. About ordering and structuring the five main elements

9
 • E.g. Analyse all requirements in the very beginning? Or get just enough require-
ments and implement them bit by bit?
• E.g. How to divide the project and delegate the tasks to a team of people?

Given some constraints:

• Time, money, number of available developers, types and levels of expertise, user
acceptance etc

2. About reviewing (1)

Two extremes of how we can structure the five main elements of software development pro-
cess:

• Waterfall model, also known as the “classic life cycle”

10
 Figure 2: Waterfall model

• All-connected model

11
Figure 3: All-connected model

12
Brief overview of software development process models

Waterfall model

Figure 4: Waterfall model

• A reasonably linear workflow

• Can be used when the requirements are well understood
• Drawbacks
– Real projects rarely follow the sequential flow
– Hard to state all requirement explicitly (uncertainty)

13
Incremental model

Figure 5: Incremental model

• Combines the elements of the waterfall model in an iterative fashion

– All overall requirements are analysed in one shot first
– Development is divided into several smaller projects
∗ Specific requirements analysis for each small project
∗ Tackle the small projects in parallel (overlapping), or one after another (sequen-
tial)
• Each linear sequence (usually a waterfall, but other model can be used) produces deliv-
erable increments

14
Rapid application development (RAD) model

Figure 6: RAD model

• A high-speed adaptation achieved by component based constructions in parallel

• Drawbacks
– Require sufficient human resources
– Developers have to commit the rapid-fire activities
– Should not be used when technical risks are high

15
Prototyping model

Figure 7: Prototyping model

• Evolutionary
– Customers only defines a set of general objectives
– Serves as a mechanism for identifying software requirements
• Makes people feel comfortable:
– Users get a feel for the actual system
– Developers build something immediately upon getting feedbacks

• Pitfall for developers:

16
 – Compromises implementation
∗ Inappropriate OS/programming language
∗ Inefficient data structures/algorithm
– Consequence: too comfortable with the choices and forget the reasons why they
were inappropriate

Spiral model

Figure 8: Spiral model

• Evolutionary
• Each pass results in adjustment to the project plan
• Prototyping can be applied in some passes
• Focus on identifying and resolving risks

17
The Unified Process (UP)

Figure 9: Unified process

• Construction phase supports both iterative and incremental development approaches

• Not a specific model, but a framework
• Is all requirements work done upfront?
• Variants
– Enterprise Unified Process adds additional practices on top of the Unified Process
– Agile Unified Process and Open Unified Process are lighter versions of the Unified
Process

• Inception
– Vision document
– Initial use-case model

18
 – Initial project glossary
– Initial business case
– Initial risk assessment

• Inception (cont’d)
– Project plan
∗ Phase and iterations
– Business model
∗ If necessary
– One or more prototypes

• Elaboration
– Address known risks
– Use-case model
– Supplementary requirements
– Analysis model
– Software architecture description
– Executable architectural prototype for user validation
– Preliminary design model
– Revised task list

• Elaboration (cont’d)
– Project plan including
∗ Iteration plan
∗ Adapted workflows
∗ Milestones
∗ Technical work products
– Preliminary user manual

• Construction
– Design model

19
 – Software components
– Integrated software increment
– Test plan and procedure
– Test cases
– Support documentation
∗ User manuals
∗ Installation manuals
∗ Description of current increment

• Transition
– Delivered software increment
– Beta test reports
– General user feedback

Question

Suppose you are going to build a software. You know this project can be divided into 3 parts
clearly and you are planning to go through requirements, design, implementation, test, and
deployment for each part. It can be assumed that you can complete close to 100% of the
features of each part. What type of software development process model do you suggest your
team should adopt?

20