COMP3211 Software Engineering

Introduction
 Welcome to this class!

Lecturer: WANG, Qixin

Logistics

Office Hour: right after the lecture in lecture hall

/ Learn@PolyU “Discussions” -> “COMP3211
2019/20 Semester II Forum” / Email

Phone: 27667266

Email: csqwang@[Link]
Need your student ID and full name, subject title:
comp3211
Logistics
Learn@PolyU “Discussions” -> “COMP3211
2019/20 Semester II Forum”
Logistics
Course lecture notes and other materials: Learn@PolyU
Evaluation
Continuous Assessment

One Group Project (3 members/group): 25% (the

grades of same-group members can vary if
necessary, but the lecturer has the final say)

Assignments (take home, lab, and/or midterm): 25%

Assignments (in-class): 10%

Final Exam: 40%

Special arrangements during online teaching.

More on 3-people Group
Register grouping:

By Feb 27th 12:30pm send email to me on grouping:

csqwang@[Link]
Email subject: “comp3211 grouping”
Each group member's full name (Chinese name if
you have one), Net ID, email address.
If you really cannot find group mates, the TA will
assign group to you later.
More on In-class Assignments (during normal
classroom teaching)
In-class assignments (usually in the form of discussions)
are categorized as casual (i.e. not credited) or credited.
The default are casual.
Credited in-class assignments are paper based. Time
limits vary (in principle: lecture's time to finish the
same assignment + 30 seconds), but are the same to all
the classroom members. By the end of the time limit,
you must decide to submit or not immediately.
A submitted credited paper answer is worth one count
no matter correct or wrong, but must be valid. An
invalid paper answer will not be counted.
More on In-class Assignments (during normal
classroom teaching)
A valid paper answer must :
1. Be on a piece of A4 (portrait layout, only allowed in the first lecture) or
A5 (landscape layout) paper, in English, hand written, and recognizable
(size no smaller than 12 point Times New Roman font).
2. Has clearly written full name of yours on the upper left corner, and NetID
of yours on the upper right corner, followed by date, and question ID.
Note this rule is necessary to guarantee confidentiality of your paper and
personal information.
3. Has no spelling error, no grammatical error, and in full sentence(s).
4. Must be relevant to the question.
5. Imply the submitter's commitment to participate in oral discussions
related to the answer.
More on In-class Assignments (during online teaching)

In-class assignments (usually in the form of discussions)

are categorized as casual (i.e. not credited) or credited.
The default are casual. Casual discusses are conducted
in Learn@PolyU Forum or MS Teams chat box during
the MS Teams lecture meeting.
Credited in-class assignments are conducted in
Learn@PolyU Assessments. The lecturer will post an
Assignment in Learn@PolyU “Assessments” during the
MS Teams lecture meeting, and the student are
supposed to submit the answer within a given deadline.
More on In-class Assignments (during online teaching)
Use “Write Submission” to submit a text submission.
No file uploads are allowed, unless otherwise noted.
More on In-class Assignments (during online teaching)

A submitted in-class assignment answer is worth one count no matter correct

or wrong, but must be valid. An invalid paper answer will not be counted.

A valid in-class assignment answer must :

1. Be in English.
2. Be by yourself (hence can pass the plagiarism check).
3. Has no spelling error, no grammatical error, and in full sentence(s).
4. Must be relevant to the question.
5. Imply the submitter's commitment to participate in online discussions
related to the answer.
More on In-class Assignments (no matter classroom
or online teaching)
Each valid credited in-class assignment answer will be
recorded (1 count per valid credited in-class assignment
answer, maximum 3 counts per lecture per person). By
the end of the semester, the person with the maximum
accumulated counts gets the full 10 points. All other
people’s point grades are given proportionally to this
max count based on their respective counts.
More on Final Exam (during normal
classroom teaching)
2 hours

Semi-open-book: everyone is allowed to bring and only

bring 13 pieces (i.e. 26 sides) of hand-written A4 cheat
sheets to the exam. Font size no less than 10pt Times
New Roman. Non-complying cheat sheets will be
confiscated on the site.
More on Final Exam (during online teaching)

An alternative individual project will be given (pending

university approval).
More on Final Exam
Late Assessment (i.e. Makeup Exam) Policy:

Problems and difficulty level of late assessment will

surely be adjusted. Closed book exam, additional in-lab
machine programming problems, and oral defense
questions may be added. The guideline is that no one
shall be allowed to profit on increased review time by
taking late assessments.
Textbook
Ian Sommerville, 2011, Software Engineering, 9th ed.,
Pearson
What is Software Engineering?
What is software?

What is software engineering?

What is Software Engineering?
What is software?

Software consists of computer programs and all documents

associated with them (such as requirements, design models, and
user manuals)

What is software engineering?

An engineering discipline concerned with all aspects of software

production.

It tells software engineers a systematic and organized approach to

their work, and provides them proper tools depending on the
problem, constraints, and resources.
Why we need Software Engineering?
Programming myths and software crisis

"The major cause of the software crisis is that the machines have
become several orders of magnitude more powerful! To put it
quite bluntly: as long as there were no machines, programming
was no problem at all; when we had a few weak computers,
programming became a mild problem, and now we have gigantic
computers, programming has become an equally gigantic
problem." – Edsger W. Dijkstra, 1972 ACM Turing Award Lecture.
Software Process: key to organize various aspects of
the software engineering discipline.
Software Process: a set of organized activities that leads to a
software product.
Fundamental activities common to all software processes:

Specification: functionality, performance, constraints;

Design & Implementation;

Validation and verification (V & V): ensure the specification is

what the customers want; ensure the design and
implementation matches specification.

Evolution: meet changing customer needs.

Software Process: key to organize various aspects of
the software engineering discipline.

1.1 Software Process Models

1.2 Process activities

1.3 Coping with changes

1.4 Computer-aided software engineering

Software Process: key to organize various aspects of
the software engineering discipline.

1.1 Software Process Models

1.2 Process activities

1.3 Coping with changes

1.4 Computer-aided software engineering

1.1 Generic software process models

A software process model is an abstraction of certain types of

software processes.

Generic software process models:

Waterfall: separate and distinct stages of specification and

development

Evolutionary development: interleaved specification,

development, validation

Component-based software engineering: assembling from

existing components
1.1 Generic software process models

The three models are NOT mutually exclusive, but are often
used together for large system development

There are many variants of these models.

1.1.1 Waterfall
Requirement
definition

System and
software design

Implementation
and unit testing

Integration and
system testing

Operation and
maintenance

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.1 Waterfall Specification
Activity
Requirement
definition Design & Impl. Activity
VV &
& VV acitivity
Activity

System and
software design

Implementation
and unit testing Evolution
Activity
Integration and
system testing

Operation and
maintenance

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.1 Waterfall model stages
Requirements analysis and definition: establish goals, services,
and constraints.

System and software design: Partition the requirements to either

hardware or software systems.

Implementation and unit testing: Software design à programs

or program units.

Integration and system testing: Integrate and test program units

Operation and maintenance: Correct errors, improve system

units, enhance system’s services.
1.1.1 Waterfall: advantages/drawbacks
Advantages

Drawbacks
1.1.1 Waterfall: advantages/drawbacks
Advantages

Documentation is produced at each phase;

Complies with other engineering process models;
Ease of planning and management;
Ease of tracing responsibility.

Drawbacks

Hard to accommodate changes after the process is underway.

One phase has to be completed before moving onto the next
phase.
1.1.1 Waterfall: suitable software projects?
1.1.1 Waterfall: suitable software projects?
Well-understood software projects

Mature application domains where changes are limited

Mission-critical / safety-critical software

1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion version

Outline
Outline Intermedia te
Intermediate
description Development
Development versions
description versions

Final Final
version
Valida tion
Validation version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v0
version

Outline
Outline Intermedia te
Intermediate
description Development
Development versions
description versions

Final Final
version
Valida tion
Validation version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v1
version

Outline
Outline Intermedia te
Intermediate
Development
Development v0
versions
description
description versions

Final Final
version
Valida tion
Validation version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v2
version

Outline
Outline Intermedia te
Intermediate
description Development
Development v1
versions
description versions

Final Final
version
Valida tion
Validation v0version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v3
version

Outline
Outline Intermedia te
Intermediate
description Development
Development v2
versions
description versions

Final Final
version
Valida tion
Validation v1version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v4
version

Outline
Outline Intermedia te
Intermediate
description Development
Development v3
versions
description versions

Final Final
version
Valida tion
Validation v2version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion v5
version

Outline
Outline Intermedia te
Intermediate
description Development
Development v4
versions
description versions

Final Final
version
Valida tion
Validation v3version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion version

Outline
Outline Intermedia te
Intermediate
description Development
Development v5
versions
description versions

Final Final
version
Valida tion
Validation v4version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development
Concurrent
Concurr ent
acti vities
activities

Initial version
Initial
Specification
Specifica tion version

Outline
Outline Intermedia te
Intermediate
description Development
Development versions
description versions

Final Final
version
Valida tion
Validation v5version

Idea: initial implementation à user comments àrefine it à

an adequate system is developed.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.2 Evolutionary development: subtypes
Exploratory development
Work with customers and evolve a final system from an initial
outline specification
Start with well-understood requirements and add new
features as proposed by the customer

Throw-away prototyping
Objective: to better understand the customer’s requirements.
Start with poorly understood requirements to clarify what is
really needed.
1.1.2 Evolutionary development: merits
1.1.2 Evolutionary development: merits
More effective than waterfall in meeting the immediate needs
of customers.

Specifications can be developed incrementally: as users

develop a better understanding of their problem.

May be the best approach to develop small or medium sized

systems.
1.1.2 Evolutionary development: problems
1.1.2 Evolutionary development: problems
Invisible process: managers need regular deliverables to
measure progresses; frequent/quick changes hamper
documentation.
Poorly structured: continuous change tends to corrupt the
software structure.
1.1.3 Component-based software engineering (CBSE)

Software reuse is common in majority of software projects.

CBSE relies on systematic reuse of existing components or

COTS (commercial-off-the-shelf) systems.

This approach is becoming increasingly used as component

standards emerge.
1.1.3 CBSE stages

Component analysis: given the requirement specifications,

search components to implement them.
Requirements modification: modify requirements to reflect
available components. May need search for new components
if requirement cannot be changed.
System design with reuse: system framework is designed
considering reusable components.
Development and integration: Develop new system, non-COTS
parts, and integrate COTS components.
1.1.3 CBSE: reuse oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
& integration validation

Intermediate stages in a
reuse-oriented process
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.1.3 CBSE: advantages and disadvantages
1.1.3 CBSE: advantages and disadvantages

Advantages

Reduce the amount of software to develop.

Reduce cost and risks
Faster delivery

Disadvantages

May lead to a system that does not meet the real needs of
users.
Some system evolution control is lost if the new version of
reusable components are not under control.
Software Process: key to organize various aspects of
the software engineering discipline.

1.1 Software Process Models

1.2 Process activities

1.3 Coping with changes

1.4 Computer-aided software engineering

1.2 Process Activities
Four basic activities
Specification/requirement engineering
Design and implementation
Validation and Verification
Evolution

How these activities are carried out depends on the software type,
people, and organization structures.
Waterfall model: sequential organization
Evolutionary: interleaved
1.2.1 Activity 1: Software specification/requirement
engineering
Establishing what services are required; identifying constraints on
the system’s operation and development.

Errors at this stage inevitably lead to later problems in the design

and implementation.

Requirement documentation: two levels

End-users/customers: high-level statement;
System developer: more detailed specification.
1.2.1 Requirement engineering process

Requirements
Feasibility
elicitation and
stud y
analysis
Requirements
specification

Feasibility Requirements
report validation

System
models
User and system
requirements

Requirement
document

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.2.1 Four stages of requirement engineering

Feasibility study: Can the user needs be satisfied with current

technologies?

Requirements elicitation and analysis: Deriving requirements by

observing existing systems, discussing with users, etc.

Requirements specification: Translating gathered info into

requirement documents (user doc. and system doc.)

Requirements validation: Check the realism, consistency, and

completeness of requirements.
1.2.2 Activity 2: Software design & implementation

The process of converting system specification into an executable

system.

Software Design: design a structure that realizes the

specification
Implementation: translate this structure into an executable
program

Design and implementation are closely related and may be

interleaved.
1.2.2 Six design process activities
Architectural design: subsystems and their relationships
Abstract specification: within each subsystem, produce abstract
specification for each subsystem.

Interface design: design and document interface for each

subsystem.
Component design: allocate service to and design interface of
components.
Data structure design: design and specify data structures for
implementation.

Algorithm design: design and specify algorithms to provide services.

1.2.2 Software design process model
R equir ements
specifica tion

Design acti vities

Da ta
Architectur al Abstract Interface Component Algorithm
structur e
design specifica tion design design design
design

Da ta
System Software Interface Component Algorithm
structur e
architectur e specifica tion specifica tion specifica tion specifica tion
specifica tion

Design pr oducts

Feedback from one stage to another and consequent

design rework is inevitable.

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.2.2 Another design & implementation method:
structured methods

Structured methods: systematic approaches to develop a

software design.
Produce graphical models of the system.
Automatically generate code from the model.

Object-oriented design were proposed and unified in 1990s to

create the Unified Modelling Language (UML).
1.2.2 Another design & implementation method:
structured methods

Object model: object classes and their dependencies

Sequence model: workflow between objects

State transition model: object internal state transition rules

Structural model: is-a relationship, has-a relationship,

aggregation relationship

Data-flow model: data transition

1.2.2 Programming and Debugging

What is programming?
Translating a design into a program.

Programming is a personal activity: there is no generic

programming process.

Debugging: programmers carry out some program testing to

discover and remove faults in the program
1.2.2 The debugging process

Defect testing and debugging are different processes:

Testing: establishes the existence of defects
Debugging: locates and corrects the defects

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.2.3 Activity 3: Software validation and verification

Purpose of V & V: to show that a system meets the requirements

of the users, and conforms to the specifications.

How to V & V:
Checking and review processes
Testing, mathmatical/mechanical proving

Testing: execute the system with test cases that are derived from
the specification.

Math/mechanical proving: model checking, static/dynamic

analysis etc.
1.2.3 Testing process

Three stage testing process

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.2.3 Testing stages

Component or unit testing

Individual components are tested independently
Components: functions or objects or groupings of them
System testing
Testing of the system as a whole. Testing of emergent
properties is particularly important

Acceptance testing
Testing with customer data to check that the system meets
the customers’ needs.
1.2.3 Testing phases in software process

Requir ements System System Detailed

specifica tion specifica tion design design

System Sub-system Module and

Acceptance
integ ration integration unit code
test plan
test plan test plan and test

Acceptance System Sub-system

Service
test integra tion test integra tion test

Testing and development are interleaved.

Test plans link the testing and development activities.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.2.4 Activity 4: Software evolution

Software is inherently flexible and can change.

As requirements change, the software must also evolve and

change.

The distinction between development and evolution

(maintenance) is becoming irrelevant as less and less systems are
completely new.
1.2.4 System evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

Existing New
systems system

SE is more realistic to be an evolutionary process than a

development-maintenance separated process.
Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
Software Process: key to organize various aspects of
the software engineering discipline.

1.1 Software Process Models

1.2 Process activities

1.3 Coping with changes

1.4 Computer-aided software engineering

1.3 Coping with changes

Change is inevitable

Change leads to rework so the costs of change include both

rework (e.g. re-analysing requirements) as well as the costs of
implementing new functionality.
1.3 Coping with changes

Change is inevitable
Business changes lead to new and changed system requirements
New technologies open up new possibilities for improving
implementations
Changing platforms require application changes

Change leads to rework so the costs of change include both

rework (e.g. re-analysing requirements) as well as the costs of
implementing new functionality.
1.3 Reducing costs of rework
Change avoidance
Activities to foresee possible changes before significant
rework is required.
E.g. a prototype system may be developed to show some key
features to customers.

Change tolerance
Process designs to accommodate changes at low cost
Normally involves some form of incremental
development/delivery. Proposed changes may be implemented
in increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the
system) may have to be altered to incorportate the change.
1.3.1 More about prototyping
A prototype is an initial version of a system used to demonstrate
concepts and try out design options.

A prototype can be used in

Requirement engineering: help with requirement elicitation
and validation.
Design process: explore options and develop a UI design.
Testing process: run back-to-back tests.
1.3.1 More about prototyping: Benefits
1.3.1 More about prototyping: Benefits

Improved system usability

A closer match to users’ real needs

Improved design quality

Improved maintainability

Reduced development effort

1.3.1 More about prototyping: Workflow

Diagrams quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.3.1 More about prototyping: Development

May be based on rapid prototype language/tool

May involve leaving out some functionalities

Prototype should focus on areas of the product that are not

well understood

Error checking and recovery may not be included in the

prototype

Focus on functional rather than non-functional

requirements such as reliability and security
1.3.1 More about prototyping: Throw-away

Prototypes should be discarded after development as they

are not a good basis for a production system
1.3.1 More about prototyping: Throw-away

Prototypes should be discarded after development as they

are not a good basis for a production system

It may be impossible to tune the system to meet non-

functional requirements.

Prototypes are normally undocumented

The prototype structure is usually degraded through rapid

change

The prototype probably will not meet normal organizational

quality standards.
1.3.2 More about incremental development/delivery

Evolutionary development software process model is the natural

choice.

But using waterfall or CBSE, we can also do incremental

development/delivery
1.3.2 More about incremental development/delivery:
incremental delivery
Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with
each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority

requirements are included in early increments. Basic functions à
additional functions à add. add. funcs.

Once the development of an increment is started, the

requirements are frozen though requirements for later
increments can continue to evolve.
1.3.2 More about incremental development/delivery:
Differences btw incremental development/delivery

One focuses on development: from the end user’s perspective,

the increments can be invisible.

On focuses on delivery: the delivery to the end user is

incremental, visible.
1.3.2 More about incremental development/delivery:
Incremental delivery advantages
1.3.2 More about incremental development/delivery:
Incremental delivery problems
1.3.2 More about incremental development/delivery:
fusion – the agile method

Something between incremental development and incremental

delivery

Each programmer and a user proxy sit at a same desk to develop

the software.

Evaluation done by user/customer proxy

Software Process: key to organize various aspects of
the software engineering discipline.

1.1 Software Process Models

1.2 Process activities

1.3 Coping with changes

1.4 Computer-aided software engineering

1.4 Computer-aided software engineering
Computer-aided software engineering (CASE) is to support
software development and evolution processes

Activiteis automated by using CASE

Graphical editors for system model development

Data dictionary to manage design entities

Graphical UI builder for user interface construction

Debuggers to support program fault finding

Automated translators to generate new versions of a program

(e.g. from COBOL to Java)
1.4 CASE technology
CASE technology has led to significant improvements in the
software process. However, not as much as once predicted. Why?

Software engineering requires creative thought, not readily

automated.

Software engineering is a team activity and for large projects,

much time is spent in team interactions. CASE technolgy does
not really support these.
1.4 CASE tool classification: 3 perspectives
Understand the different types of CASE tools and their support
for process activities.

Fucntional perspective: classified according to their specific

function.

Process perspective: classified according to process activities

that are supported.

Integration perspective: classified according to how they are

organized into integrated units.
1.4 Functional classification of CASE tools
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management tools Version management systems, system building tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
Table quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.4 Activity based classification of CASE tools

Diagram quoted from Ian Sommerville, Software Engineering (9th Ed.), Pearson, 2011.
1.4 Integration based classification of CASE tools
Tools: Support individual process tasks such as design
consistency checking, text editing, etc.

Workbenches: Support a process phase such as specification

or design. Normally include a number of integrated tools.

Environments: Support all or a substantial part of an entire

software process. Normally include several integrated
workbenches.
1.4 Tools, workbenches, environments
C ASE
technolo g y

Tools Workbenches Environments

File Integ rated Pr ocess-centr ed

Editors Compilers
compar ators en vironments en vironments

Anal ysis and

Pro gramming Testing
design

Multi-method Single-method Gener al-purpose Langua ge-specific

workbenches workbenches workbenches workbenches
94
Diagram quoted from Ian Sommerville, Software Engineering (9 Ed.), Pearson, 2011.
th