Professional Documents
Culture Documents
Final Revision
Final Revision
Final Revision
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
Chapter 2
Software Processes
3
24-Nov-21
4
24-Nov-21
Incremental development
Specification, development and validation are interleaved. May
be plan-driven or agile.
10
5
24-Nov-21
Incremental Development
12
6
24-Nov-21
Chapter 3
13
14
7
24-Nov-21
Refactoring
15
Pair Programming
16
8
24-Nov-21
Scrum
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
20
10
24-Nov-21
System Stakeholders
Stakeholder types
End users
System managers
System owners
External stakeholders
21
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
23
Usability requirements
24
12
24-Nov-21
25
Chapter 5
System Modeling
26
13
24-Nov-21
Activity Diagram
28
14
24-Nov-21
29
30
15
24-Nov-21
31
32
16
24-Nov-21
33
Chapter 7
17
24-Nov-21
Build or Buy
35
36
18
24-Nov-21
Design Models
37
38
19
24-Nov-21
Implementation Issues
Open-Source Systems
40
20
24-Nov-21
Chapter 8
Software Testing
41
Program Testing
You check the results of the test run for errors, anomalies or
information about the program’s non-functional attributes.
42
21
24-Nov-21
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
45
46
23
24-Nov-21
Stages of Testing
47
Development Testing
48
24
24-Nov-21
Unit Testing
49
Automated Testing
25
24-Nov-21
A setup part, where you initialize the system with the test
case, namely the inputs and expected outputs.
51
System Testing
52
26
24-Nov-21
Test-Driven Development
27
24-Nov-21
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
56
28
24-Nov-21
Release Testing
57
User Testing
58
29
24-Nov-21
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