SOFTWARE ENGINEERING

1
CSC 317: Software engineering Semester: 1, 23/24

Class Hours: WED-4:30-6:30 Venue:

G11

Instructor: Dr. Emmanuel Office Hours: Monday – Friday,

Dortey Tetteh 8.00am – 5.00pm

Phone Number: (Cell): Email: [email protected]

0244572711
COURSE CONTENT
UNIT – 1
Overview: Introduction: FAQ's about software engineering, Professional and ethical
responsibility.
Socio-Technical systems: Emergent system properties; Systems engineering;
Organizations, people and computer systems; Legacy systems.

UNIT – 2
Critical Systems, Software Processes: Critical Systems: A simple safety-critical
system; System dependability; Availability and reliability.
Software Processes: Models, Process iteration, Process activities; The Rational
Unified Process; Computer Aided
Software Engineering.

UNIT – 3

requirements; User requirements; System requirements; Interface

specification; The software requirements document.
Requirements Engineering Processes: Feasibility studies; Requirements
elicitation and analysis; Requirements validation; Requirements
management. 3
UNIT – 4
System models: Context models; Interaction models, Structural
models, Behavioral models; Model-driven engineering
UNIT – 5
Software Design : Architectural Design: Architectural design
decisions; System organization; Modular decomposition styles; Control
styles.
Object-Oriented design: Objects and Object Classes; An Object-
Oriented design process; Design evolution.

UNIT – 6
Verification and Validation: Verification and Validation: Planning;
Software inspections; Automated static analysis; Verification and
formal methods.
Software testing: System testing; Component testing; Test case design;
Test automation.
4
Text Books:

1. Ian Sommerville: Software Engineering, 8th

Edition, Pearson Education, 2007. (Chapters-: 1,
2, 3, 4, 5, 6, 7, 8, 11, 14, 17, 21, 22, 23, 25, 26)
2. "Software Engineering: A Practitioner's
Approach" by Roger S. Pressman.
3. "Design Patterns: Elements of Reusable Object-
Oriented Software" by Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides, and Grady
Booch.
4. "Agile Software Development with Scrum" by
Ken Schwaber and Mike Beedle.

5
Assessment

• Assignments, quizzes, presentations and end-of-

semester examinations are continually used to
obtain information about student performance.
• Continuous assessment (40 marks)
• Assignments, (Group presentation) – 10%
• Quiz 1– 10%
• Quiz 2 – 10%
• Class attendance – 10%
• End-of- semester examination (60 marks)
6
What is Software?
•Software is a set of computer-programs and associated documentation.
•A software-system consists of a no. of programs such as
→ configuration-files used to set-up programs
→ system-documentation describes the structure of the system and
→ user-documentation explains how to use the system.

•Two types of software-products:

1)Generic
➢Developed to be sold to a range of different customers.
2) Bespoke (custom)
➢Developed for a single customer according to their specification.

What is Software Engineering?

•Software-engineering is an engineering-discipline which is concerned
with all aspects of software- development

•Software-engineers should
→ adopt a systematic approach to their work and
→ use appropriate tools/techniques depending on
1.Problem to be solved
2.Development constraints
3.Resources available
7
Figure 1.1: Stages in software engineering

8
What is the difference between Software Engineering
and Computer Science?

• Software-engineering is concerned with all aspects of

software-development i.e. design, development and delivery
of software.
• Computer-science is concerned with theory and
fundamentals.

What is the difference between System Engineering

and Software Engineering?
• System-engineering is concerned with all aspects of
computer-based systems development including
→ hardware/software and
→ process-engineering.
• Software-engineering is part of system-engineering. This
deals with the design, development and delivery of
software.

9
What is a Software Process?
• A set of activities whose goal is the development of
software.
• Four main activities:
1. Software Specification
➢ This answers following questions:

→ what does the customer need?

→ what are the constraints?
2. Software Development
➢ Software is designed and programmed.

3. Software Validation
➢ Software is checked to ensure that it is what the

customer requires.
4. Software Evolution
➢ Software is modified to adapt to changing

customer- and market-requirements. 10

What is a Software Process Model?
• A simplified representation of a software-process, presented
from a specific perspective.
• Process-models may include
→ activities part of the software-process and
→ roles of people involved.
• Examples of process-model:
1. A Workflow Model
➢ This shows

→ sequence of activities in the process and

→ inputs & outputs of activities.
➢ The activities represent human-actions.

2. A Dataflow( or Activity model)

➢ This represents the process as a set of activities.

➢ Each activity carries out some data-transformation.

➢ The activities may be carried out by

→ people or
→ computers.
3. A Role/Action Model
➢This represents
→ roles of the people involved in the process and
→ activities for which the people are responsible. 11
Generic Models
1. The Waterfall Approach
• This represents the activities as separate process-phases such as
→ design
→ implementation and
→ testing.
• After each stage is defined, it is 'signed-off, and development goes on
to the next stage.
2. Iterative Development
• This approach interleaves the activities of
→ specification
→ development and
→ validation.
• An initial-system is rapidly developed from very abstract-specifications.
• The initial-system is then refined with customer-input to produce
a system that satisfies the customer's needs.
• The system may then be delivered.
3. CBSE (Component-based Software Engineering)
• This approach assumes that parts of the system already exist.
• The development-process focuses on integrating the available parts
(rather than developing them from scratch).
12
What is CASE?

• CASE stands Computer-Aided Software Engineering.

• CASE is software-system designed to support routine-activities in

software-process.

• Routine activities include

→ editing design diagrams

→ checking diagram consistency and

→ keeping track of program tests that have been run.

13
Attributes of good software
1. Maintainability
• Software should be written in such a way that it may evolve to meet
the changing needs of customers.
2. Dependability
• Dependability has a range of features such as
→ reliability
→ security and
→ safety.
• Dependable-software should not cause physical or economic damage in
event of failure.
3. Efficiency
• Software should not waste system-resources such as
→ memory-cycles and
→ processor-cycles.
• Efficiency includes
→ response-time
→ processing-time and
→ memory-utilization.
4. Usability
• Software must be usable, without undue effort, by the user.
• Software should have an appropriate
→ user interface and 14
→ proper documentation.
What are the key challenges facing Software Engineering?
1. The Heterogeneity Challenge
• Increasingly, systems are required to operate across networks that
include
→ different types of computers
→ different kinds of support systems and
→ different platforms.
• It is often necessary to integrate new software with older legacy-
systems.
2. The Delivery Challenge
• The challenge is shortening delivery-times for large systems without
compromising system-quality.
• Many traditional software engineering techniques are time-
consuming.
• However, businesses today change very rapidly. So, their supporting-
software must change equally rapidly.
3. The Trust Challenge
• The challenge is to demonstrate that the software can be trusted by
its users.
• As software is a part of many aspects of our lives (work, study,
leisure), it is essential that we can trust that software.
• This is true for remote-systems accessed through a web-page
interface. 15
Professional and Ethical Responsibility

1. Confidentiality
• You should normally respect the confidentiality of your employers or
clients.
2. Competence
• You should not misrepresent your level of capability.
• You should not knowingly accept work that is outside your capability.
3. Intellectual Property Rights
• You should be aware of local laws governing the use of intellectual
property such as
→ patents and
→ copyright.
• You should be careful to ensure that the intellectual property of
employers and clients is protected.
4. Computer Misuse
• You should not use your technical skills to misuse other people's
computers.
• Computer misuse ranges
→ from relatively trivial (game playing on an employer’s machine)
→ to extremely serious (distribution of viruses).
16
SOCIO-TECHNICAL SYSTEMS
Introduction
• A system is a purposeful collection of interrelated components that
work together to achieve some objective.
• Two categories of systems:
1. Technical Computer-based Systems
➢ These are systems that include hardware- and software-
components but not procedures and processes.
➢ Examples: televisions, mobile phones.
2. Socio-technical Systems
➢ These include one or more technical systems.
➢ These also include knowledge of how the system should be used
to achieve some broader objective.
➢ These systems have defined operational processes.
➢ These systems include people (the operators) who are governed
by organizational policies and rules. 17
Essential characteristics of Socio-technical Systems
1. They have emergent properties that are properties of the
system as a whole rather than associated with individual parts
of the system.
Emergent properties depend on both
→ system-components and
→ relationships between components
2. They are often non-deterministic. i.e. when presented with a
specific input, they may not always produce the same output.
3. The extent to which the system supports organisational-
objectives depends on
→ stability of the objectives
→ relationships and conflicts between objectives and
→ how people in the organisation interpret the objectives.
18
Emergent System Properties

1. Functional Emergent Properties

• These appear when all the parts of a system work
together to achieve some objective.
• For example, a bicycle has the functional property
of being a transportation-device once it has been
assembled from its components.
1. Non-functional Emergent
• These properties relate to the behaviour of the
system in its operational environment.
• Examples are
→ reliability
→ performance
→ safety and
→ securi1ty.
19
Systems Engineering
• This is the activity of specifying, designing, implementing,
validating, deploying and maintaining socio-technical systems

• System-engineers are concerned with

→ software & hardware and
→ system's interactions with users and its environment.

The systems engineering process 20

System Requirements Definitions
• These specify what the system should do (its functions) and its
essential and desirable system properties.

• Three types of requirements:

1. Abstract Functional Requirements
➢ The basic functions that the system must provide are defined at

an abstract-level.
➢ More detailed requirements are defined at the subsystem-level.

2. System Properties
➢ These are non-functional emergent system properties such as

→ availability
→ performance and
→ safety.
3. Characteristics that the System must not exhibit
➢ It is sometimes as important to specify what the system must

not do as it is to specify what the system should do.

21
System Design
This is concerned with how the system functionality is to be provided by the
components of the system

1. Partition Requirements
➢ You analyse the requirements and organise them into related groups.
2. Identify Subsystems
➢ You should identify subsystems that can individually or collectively meet the
requirements.
➢ Subsystem identification may also be influenced by other organizational or
environmental factors.
3. Assign Requirements to Subsystems
➢ This should be straightforward if the requirements partitioning is used to
drive the subsystem identification.
4. Specify Subsystem Functionality
➢ You should specify the specific functions provided by each subsystem.
➢ You should also try to identify relationships between subsystems.
5. Define Subsystem Interfaces
➢ You define the interfaces that are provided and required by each subsystem.
➢ Once these interfaces have been agreed upon, it is possible to develop
22
these subsystems in parallel.
System Modelling

• The system is decomposed into a set of interacting subsystems.

• Each subsystem should be represented in a similar way until the
system is decomposed into functional components.
• Functional components provide a single function.
By contrast, a subsystem usually is multifunctional.
• These are normally illustrated graphically in a system-architecture
model
• The system-architecture may be presented as a block diagram
showing
→ major subsystems and
→ interconnections between these subsystems.

23
A simple burglar alarm system

• Subsystem descriptions in the burglar alarm system

Movement Sensors
➢ Detects movement in the rooms monitored by the system
Door Sensors
➢ Detects door opening in the external doors of the building.
Alarm Controller
➢ Controls the operation of the system.
Siren
➢ Emits an audible warning when an intruder is suspected.
Voice Synthesizer
➢ Synthesises a voice message giving the location of the suspected intruder.
Telephone Caller
➢ Makes external calls to notify security, the police, etc. 24
Subsystem Development
• The subsystems identified during system-design are implemented.
• This may involve starting another system-engineering process for individual
subsystems.
• Occasionally, all subsystems are developed from scratch during the development
process.
• Normally, some of the subsystems are COTS systems (commercial off-the-shelf)
that are bought for integration into the system. (COTS means built-in
component).
• Subsystems are usually developed in parallel.
• When problems are encountered that cut across subsystem boundaries, a
system modification request must be made.

Systems Integration
• The basic idea:
1. Take the independently developed subsystems and
2. Then, integrate them to make up a complete system.
• In incremental-integration, subsystems are integrated one at a time.
• Incremental-integration is considered best approach for 2 reasons:
1. Usually, it is impossible to schedule the development of all the
subsystems so that all subsystems are all developed at the same
time.
2. Incremental integration reduces the cost of error-location.
• Once the components are integrated, an extensive system-testing takes place.
• Faults that are a consequence of invalid assumptions about other subsystems are
often exposed.
25
System Evolution
• Large, complex systems have a very long lifetime. They must evolve to
meet changing requirements.
• Four reasons why evolution is costly:
1. Changes must be analysed from a technical- and business-perspective.
2. When subsystems interact, unanticipated problems can arise.
3. There is rarely a justification for original design decisions.
4. System-structure is corrupted, as changes are made to it.
• Systems that have evolved over time are often dependent on
obsolete hardware/software
technology. If they have a critical role in an organisation, they are known as
legacy systems.

System Decommissioning
• This means taking the system out-of-service after the end of its useful
operational lifetime.
• For hardware systems, this may involve disassembling and recycling
materials or dealing with toxic substances.
• Software has no physical decommissioning problems,
but some software may be incorporated in a system to assist with
decommissioning process.
• If the data in the decommissioned-system is still valuable to
your organisation, then you may have to convert it for use by
some other system.
26
Legacy Systems
• These systems are socio-technical systems that have been developed
in the past, often using older technology.
• These systems include
→ hardware & software and
→ legacy processes & procedure.
• These systems are often business-critical systems. They are
maintained because it is too risky to replace them.

Legacy system components 27

• Logical parts of legacy system

1. System Hardware
➢ In many cases, legacy-systems have been written for mainframe-hardware
that is no longer available.
➢ The mainframe-hardware is expensive to maintain.
➢ The mainframe-hardware may not be compatible with current organisational-
policies.
2. Support Software
➢ The legacy-system relies on OS & compilers provided by the old hardware-
manufacturer. Again, these softwares may be no longer supported by their
original providers.
3. Application Software
➢ The application-system is usually composed of a number of separate programs
that have been developed at different times.
4. Application Data
➢ These are the data that are processed by the application-system.
➢ In many legacy systems, an immense volume of data has accumulated over
the lifetime of the system.
5. Business Processes
➢ These processes are used in the business to achieve some business-objective.
➢ Business-processes may be
→ designed around a legacy-system and
→ constrained by the functionality that it provides.
6. Business policies and Rules
These are definitions of how the business should be carried out and constraints on the
business.
28