24-Nov-21

SOFTWARE ENGINEERING
ITE 3110

Final Revision

Chapter 1

Introduction

1
 24-Nov-21

Software products

 Generic products
 Stand-alone systems that are marketed and sold to any
customer who wishes to buy them.
 Examples – PC software such as graphics programs, project
management tools; CAD software; software for specific markets
such as appointments systems for dentists.

 Customized products
 Software that is commissioned by a specific customer to meet
their own needs.
 Examples – embedded control systems, air traffic control
software, traffic monitoring systems.

Product specification

 Generic products
 The specification of what the software should do is owned by the
software developer.

 Customized products
 The specification of what the software should do is owned by the
customer for the software and they make decisions on software
changes that are required.

2
 24-Nov-21

Essential attributes of good software

Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve

to meet the changing needs of customers.
This is a critical attribute because software change is an
inevitable requirement of a changing business environment.
Dependability and Software dependability includes a range of characteristics
security including reliability, security and safety.
Dependable software should not cause physical or economic
damage in the event of system failure. Malicious users should
not be able to access or damage the system.
Efficiency Software should not make wasteful use of system resources
such as memory and processor cycles. Efficiency therefore
includes responsiveness, processing time, memory utilisation,
etc.
Acceptability Software must be acceptable to the type of users for which it
is designed. This means that it must be understandable,
usable and compatible with other systems that they use.

Chapter 2

Software Processes

3
 24-Nov-21

The software process

 A structured set of activities required to develop a

software system.

 Many different software processes but all involve:

 Specification – defining what the system should do;
 Design and implementation – defining the organization of the
system and implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing
customer needs.

Plan-driven and agile processes

 Plan-driven processes are processes where all of the

process activities are planned in advance and progress
is measured against this plan.

 In agile processes, planning is incremental and it is

easier to change the process to reflect changing
customer requirements.

4
 24-Nov-21

Software process models

 The waterfall model

 Plan-driven model. Separate and distinct phases of specification
and development.

 Incremental development
 Specification, development and validation are interleaved. May
be plan-driven or agile.

 Integration and configuration

 The system is assembled from existing configurable
components. May be plan-driven or agile.

The Waterfall Model

10

5
 24-Nov-21

Incremental Development

 The cost of accommodating changing customer

requirements is reduced.
 The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall model.

 It is easier to get customer feedback on the development

work that has been done.
 Customers can comment on demonstrations of the software and
see how much has been implemented.

 More rapid delivery and deployment of useful software to

the customer is possible.
 Customers are able to use and gain value from the software
earlier than is possible with a waterfall process. 11

Integration and Configuration

 Based on software reuse where systems are integrated

from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf
systems).

 Reused elements may be configured to adapt their

behaviour and functionality to a user’s requirements.

 Reuse is now the standard approach for building many

types of business system.

12

6
 24-Nov-21

Chapter 3

Agile Software Development

13

Rapid Software Development

 Rapid development and delivery is now often the most

important requirement for software systems.

 Plan-driven development is essential for some types of

system but does not meet these business needs.
 Agile development methods emerged in the late 1990s
whose aim was to radically reduce the delivery time for
working software systems.

14

7
 24-Nov-21

Refactoring

 This improves the understandability of the software by

Programming team and so reduces the need for
documentation.

 Changes are easier to make because the code is well-

structured and clear.

 Re-organization of a class hierarchy to remove duplicate

code.

 The replacement of inline code with calls to methods that

have been included in a program library.

15

Pair Programming

 Pair programming involves programmers working in

pairs, developing code together.

 It encourages refactoring as the whole team can benefit

from improving the system code.

 In pair programming, programmers sit together at the

same computer to develop the software.

 The sharing of knowledge that happens during pair

programming is very important as it reduces the overall
risks to a project when team members leave.

16

8
 24-Nov-21

Scrum

 Scrum is an agile method that focuses on managing

iterative development rather than specific agile practices.
 There are three phases in Scrum.
 The initial phase is an outline planning phase where you
establish the general objectives for the project and design the
software architecture.
 This is followed by a series of sprint cycles (normally 2–4
weeks). where each cycle develops an increment of the system.
 The project closure phase wraps up the project, completes
required documentation such as system help frames and user
manuals and assesses the lessons learned from the project.

17

Chapter 4

Requirements Engineering

18

9
 24-Nov-21

What is a requirement?
 It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification.

Types of requirement
 User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
 System requirements
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor. 19

User and system requirements

20

10
 24-Nov-21

System Stakeholders

 Any person or organization who is affected by the

system in some way and so who has a legitimate
interest.

 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders

21

Functional and non-functional requirements

 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
 May state what the system should not do.

 Non-functional requirements
 Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
 These define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are I/O
device capability, system representations, etc.
 Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless. 22

11
 24-Nov-21

Types of non-functional requirement

23

Usability requirements

 The system should be easy to use by medical staff and

should be organized in such a way that user errors are
minimized. (Goal)

 Medical staff shall be able to use all the system functions

after four hours of training. After this training, the
average number of errors made by experienced users
shall not exceed two per hour of system use. (Testable
non-functional requirement)

24

12
 24-Nov-21

Requirements engineering processes

There are a number of generic activities common to all

processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.

25

Chapter 5

System Modeling

26

13
 24-Nov-21

UML Diagram Types

 Activity diagrams, which show the activities involved in a

process or in data processing.

 Use case diagrams, which show the interactions between

a system and its environment.

 Sequence diagrams, which show interactions between

actors and the system, and between system components.

 Class diagrams, which show the object classes in the

system and the associations between these classes.

 State diagrams, which show how the system reacts to

internal and external events. 27

Activity Diagram

28

14
 24-Nov-21

Use cases in the Mentcare system involving the

role ‘Medical Receptionist’

29

Sequence diagram for View patient information

30

15
 24-Nov-21

Classes and associations in the MHC-PMS

31

The Consultation class

32

16
 24-Nov-21

State diagram of a microwave oven

33

Chapter 7

Design and Implementation

17
 24-Nov-21

Build or Buy

 In a wide range of domains, it is now possible to buy off-

the-shelf systems (COTS) that can be adapted and
tailored to the users’ requirements.
 For example, if you want to implement a medical records system,
you can buy a package that is already used in hospitals. It can
be cheaper and faster to use this approach rather than
developing a system in a conventional programming language.

 When you develop an application in this way, the design

process becomes concerned with how to use the
configuration features of that system to deliver the
system requirements.

35

Context and Interaction Models

 A system context model is a structural model that

demonstrates the other systems in the environment of
the system being developed.

 An interaction model is a dynamic model that shows how

the system interacts with its environment as it is used.

36

18
 24-Nov-21

Design Models

 Design models show the objects and object classes and

relationships between these entities.

 There are two kinds of design model:

 Structural models describe the static structure of the system in
terms of object classes and relationships.
 Dynamic models describe the dynamic interactions between
objects.

37

Examples of design models

 Subsystem models that show logical groupings of

objects into coherent subsystems.

 Sequence models that show the sequence of object

interactions.

 State machine models that show how individual objects

change their state in response to events.

 Other models include use-case models, aggregation

models, generalisation models, etc.

38

19
 24-Nov-21

Implementation Issues

 Focus here is not on programming, although this is

obviously important, but on other implementation issues
that are often not covered in programming texts:
 Reuse: Most modern software is constructed by reusing existing
components or systems. When you are developing software, you
should make as much use as possible of existing code.
 Configuration management: During the development process,
you have to keep track of the many different versions of each
software component in a configuration management system.
 Host-target development: Production software does not usually
execute on the same computer as the software development
environment. Rather, you develop it on one computer (the host
system) and execute it on a separate computer (the target
system). 39

Open-Source Systems

 The best-known open source product is, of course, the

Linux operating system which is widely used as a server
system and, increasingly, as a desktop environment.

 Other important open source products are Java, the

Apache web server and the mySQL database
management system.

40

20
 24-Nov-21

Chapter 8

Software Testing

41

Program Testing

 Testing is intended to show that a program does what it is

intended to do and to discover program defects before it is put
into use.

 You check the results of the test run for errors, anomalies or
information about the program’s non-functional attributes.

 Can reveal the presence of errors NOT their absence.

 Testing is part of a more general verification and validation

process, which also includes static validation techniques.

42

21
 24-Nov-21

Testing Process Goals

 Validation testing
 To demonstrate to the developer and the system customer that
the software meets its requirements
 A successful test shows that the system operates as intended.

 Defect testing
 To discover faults or defects in the software where its behaviour
is incorrect or not in conformance with its specification.
 A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

43

Verification vs Validation

 Verification:
"Are we building the product right”.
 The software should conform to its specification.

 Validation:
"Are we building the right product”.
 The software should do what the user really requires.

44

22
 24-Nov-21

Inspections and Testing

 Software inspections: Concerned with analysis of

the static system representation to discover problems
(static verification)
 May be supplement by tool-based document and code analysis.

 Software testing: Concerned with exercising and

observing product behaviour (dynamic verification)
 The system is executed with test data and its operational
behaviour is observed.

45

Inspections and Testing

46

23
 24-Nov-21

Stages of Testing

 Development testing, where the system is tested during

development to discover bugs and defects.

 Release testing, where a separate testing team test a

complete version of the system before it is released to
users.

 User testing, where users or potential users of a system

test the system in their own environment.

47

Development Testing

 Development testing includes all testing activities that

are carried out by the team developing the system.

 Unit testing, where individual program units or object classes are

tested. Unit testing should focus on testing the functionality of
objects or methods.

 Component testing, where several individual units are integrated

to create composite components. Component testing should
focus on testing component interfaces.

 System testing, where some or all of the components in a

system are integrated and the system is tested as a whole.
System testing should focus on testing component interactions.

48

24
 24-Nov-21

Unit Testing

 Unit testing is the process of testing individual

components in isolation.

 It is a defect testing process.

 Units may be:

 Individual functions or methods within an object
 Object classes with several attributes and methods
 Composite components with defined interfaces used to access
their functionality.

49

Automated Testing

 Whenever possible, unit testing should be automated so

that tests are run and checked without manual
intervention.

 In automated unit testing, you make use of a test

automation framework (such as JUnit) to write and run
your program tests.

 Unit testing frameworks provide generic test classes that

you extend to create specific test cases. They can then
run all of the tests that you have implemented and
report, often through some GUI, on the success of
otherwise of the tests.
50

25
 24-Nov-21

Automated Test Components

 A setup part, where you initialize the system with the test
case, namely the inputs and expected outputs.

 A call part, where you call the object or method to be

tested.

 An assertion part where you compare the result of the

call with the expected result. If the assertion evaluates to
true, the test has been successful if false, then it has
failed.

51

System Testing

 System testing during development involves integrating

components to create a version of the system and then
testing the integrated system.
 The focus in system testing is testing the interactions
between components.
 System testing checks that components are compatible,
interact correctly and transfer the right data at the right
time across their interfaces.
 System testing tests the emergent behaviour of a
system.

52

26
 24-Nov-21

Test-Driven Development

 Test-driven development (TDD) is an approach to

program development in which you inter-leave testing
and code development.
 Tests are written before code and ‘passing’ the tests is
the critical driver of development.
 You develop code incrementally, along with a test for that
increment. You don’t move on to the next increment until
the code that you have developed passes its test.
 TDD was introduced as part of agile methods such as
Extreme Programming. However, it can also be used in
plan-driven development processes.
53

TDD process activities

 Start by identifying the increment of functionality that is

required. This should normally be small and
implementable in a few lines of code.
 Write a test for this functionality and implement this as
an automated test.
 Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
 Implement the functionality and re-run the test.
 Once all tests run successfully, you move on to
implementing the next chunk of functionality.
54

27
 24-Nov-21

Benefits of test-driven development

 Code coverage
 Every code segment that you write has at least one associated
test so all code written has at least one test.
 Regression testing
 A regression test suite is developed incrementally as a program
is developed.
 Simplified debugging
 When a test fails, it should be obvious where the problem lies.
The newly written code needs to be checked and modified.
 System documentation
 The tests themselves are a form of documentation that describe
what the code should be doing.
55

Regression Testing

 Regression testing is testing the system to check that

changes have not ‘broken’ previously working code.
 In a manual testing process, regression testing is
expensive but, with automated testing, it is simple and
straightforward. All tests are re-run every time a change
is made to the program.
 Tests must run ‘successfully’ before the change is
committed.

56

28
 24-Nov-21

Release Testing

 Release testing is the process of testing a particular release

of a system that is intended for use outside of the
development team.
 The primary goal of the release testing process is to
convince the supplier of the system that it is good enough
for use.
 Release testing, therefore, has to show that the system delivers its
specified functionality, performance and dependability, and that it
does not fail during normal use.
 Release testing is usually a black-box testing process
where tests are only derived from the system specification.

57

User Testing

 User or customer testing is a stage in the testing process

in which users or customers provide input and advice on
system testing.

 User testing is essential, even when comprehensive

system and release testing have been carried out.
 The reason for this is that influences from the user’s working
environment have a major effect on the reliability, performance,
usability and robustness of a system. These cannot be replicated
in a testing environment.

58

29
 24-Nov-21

Types of user testing

 Alpha testing
 Users of the software work with the development team to test the
software at the developer’s site.
 Beta testing
 A release of the software is made available to users to allow
them to experiment and to raise problems that they discover with
the system developers.
 Acceptance testing
 Customers test a system to decide whether or not it is ready to
be accepted from the system developers and deployed in the
customer environment. Primarily for custom systems.

59

30