Software Engineering

Chapter 1:

Software Engineering Fundamentals

Contents
 What is software?
 Software types
 Nature of software.
 What is software engineering?
 Stakeholders in Software engineering
 software quality.
 Software Process
 Software process models.
 Automated process support (CASE)
 Software Engineering and the Engineering Profession

1/16/2025 2
What is software?
 Software is collection of computer programs,
procedures, rules, and associated
documentations and data (IEEE).
 There are different types of software
 Custom (Bespoke) : For a specific customer
 Example: web sites, air traffic system, etc
 Generic: Often called COTS (Commercial Off The Shelf)
or Shrink-wrapped.
 Sold on open market
 Example: word processors, spread sheets,
compilers, etc
 Embedded: Built into hardware
 Hard to change

1/16/2025 3
Types of software…
 Real time software: Must react immediately
 Safety is often a concern
 e.g. control and monitoring systems
 Almost all embedded systems have hard real-time constraint.
 Data processing software: Used to run businesses
 Accuracy and security of data are key concerns
 Functions: recording sales, managing accounts, printing bills
 Some software has both aspects
 e.g.. Telephone system (managing phone calls and billing for those
calls)

 Can you think other ways to categorize software?

1/16/2025 4
The Nature of Software...
 Software is intangible
 Hard to understand development effort
 Software is easy to reproduce
 Cost is in its development

 in other engineering products, manufacturing is the costly

stage
 The industry is labor-intensive
 Hard to automate
 Untrained people can hack something together
 Quality problems are hard to notice

1/16/2025 5
The Nature of Software ...
 Software is easy to modify
 People make changes without fully understanding it.
 Software does not ‘wear out’
 It deteriorates by having its design changed:
 Changes often tend to introduce new defects

 Conclusions
 Demand for software is high and rising
 Much software has poor design and is getting worse
 We are in a perpetual ‘software crisis’
 We have to learn to ‘engineer’ software

1/16/2025 6
What is Software Engineering?
 The process of solving customers’ problems by
the systematic development and evolution of
large, high-quality software systems within cost,
time and other constraints

 Other definitions:
 IEEE: (1) the application of a systematic, disciplined, quantifiable
approach to the development, operation, maintenance of
software; that is, the application of engineering to software. (2)
The study of approaches as in (1).
 The Canadian Standards Association: The systematic activities
involved in the design, implementation and testing of software to
optimize its production and support.

1/16/2025 7
What is Software Engineering?…

 Solving customers’ problems

 This is the goal of every software engineering
 Sometimes the solution is to buy, not build
 Adding unnecessary features does not help solve
the problem
 Software engineers must communicate effectively
to identify and understand the problem

1/16/2025 8
What is Software Engineering?…

 Systematic development and evolution

 An engineering process involves applying well
understood techniques in a organized and
disciplined way
 Many well-accepted practices have been formally
standardized
 e.g. by the IEEE or ISO
 Most development work is evolution

1/16/2025 9
What is Software Engineering?…
 Large, high quality software systems
 Software engineering techniques are needed
because large systems cannot be completely
understood by one person.
 Teamwork and co-ordination are required
 Key challenge: Dividing up the work and
ensuring that the parts of the system work
properly together
 The end-product must be of sufficient quality

1/16/2025 10
What is Software Engineering?
 Cost, time and other constraints
 Finite resources
 The benefit must outweigh the cost
 Others are competing to do the job cheaper and faster
 Inaccurate estimates of cost and time have caused many
project failures
 Just like mechanical engineers design mechanical
systems and electrical engineers design electrical
systems software engineers design software
systems.
 However, software differs in important ways from
the artifacts produced by other engineering
discipline.
1/16/2025 11
Stakeholders in Software
Engineering
 1. Users
 Those who use the software
 2. Customers
 Those who pay for the software
 3. Software developers
 4. Development Managers

 All four roles can be fulfilled by the same person

1/16/2025 12
Example - ATM stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators

1/16/2025 13
Software Quality...
 Is the degree to which a system, component or
process meets customer or user needs or
expectations.
 Usability: Users can learn it and fast and get their job done
easily
 Efficiency: It doesn’t waste resources such as CPU time
and memory
 Reliability: It does what it is required to do without failing
 Maintainability: It can be easily changed
 Reusability: Its parts can be used in other projects, so
reprogramming is not needed

1/16/2025 14
Software Quality and the
Stakeholders
Customer: User:
solves problems at easy to learn;
an acceptable cost in efficient to use;
terms of money paid and helps get work done
resources used

QUALITY
SOFTWARE

Developer: Development manager:

easy to design; sells more and
easy to maintain; pleases customers
easy to reuse its parts while costing less
to develop and maintain

1/16/2025 15
Software Quality: Conflicts and
Objectives
 The different qualities can conflict
 Increasing efficiency can reduce maintainability or
reusability
 Increasing usability can reduce efficiency

 Setting objectives for quality is a key engineering

activity
 You then design to meet the objectives
 Avoids ‘over-engineering’ which wastes money

 Optimizing is also sometimes necessary

 E.g. obtain the highest possible reliability using a fixed
budget
1/16/2025 16
Internal Quality Criteria

 Internal quality refers to Characterize aspects of

the design and source code of the software
 Have an effect on the external quality attributes
 E.g.
 The amount of commenting of the code
 The complexity of the code

1/16/2025 17
Short Term Vs. Long Term Quality

 Short term:
 Does the software meet the customer’s
immediate needs?
 Is it sufficiently efficient for the volume of data we
have today?
 Long term:
 Maintainability
 Customer’s future needs
 Scalability: Can the software handle larger
volumes of data?

1/16/2025 18
 Chapter Two

Software Process
 Software Process [ software development life
cycle (SDLC)] is structured set of activities
required to develop a software system.
 Requirement Specification - what the system should
do and its development constraints
 Development (design and implementation (Coding)) -
production of the software system
 Testing (Validation) - checking that the software is
what the customer wants
 Maintenance (Evolution) - changing the software in
response to changing demands

1/16/2025 19
Software requirement
specification
 Requirements specification is the process of
establishing:
 what services are required and,
 the constraints on the system’s operation and
development

 The “what” of the software life cycle

1/16/2025 20
The requirements engineering process

1/16/2025 21
Software design and
implementation
 The process of converting the system
specification into an executable system
 Software design
 Design a software structure that realises the
specification
 Implementation
 Translate this structure into an executable
program
 The activities of design and implementation are
closely related and may be inter-leaved.

1/16/2025 22
The software design process

1/16/2025 23
Coding - Programming and
debugging
 Translating a design into a program and removing
errors from that program
 Programming is a personal activity - there is no
generic programming process
 Programmers carry out some program testing to
discover faults in the program and remove these
faults in the debugging process
 The debugging process:

1/16/2025 24
 Software Verification and
 validation
Verification and validation is intended to show that a
system conforms to its specification and meets the
requirements of the system customer
 Varies Types of testing:
 Unit testing - individual components are tested
 Module testing - related collections of dependent components
are tested
 Sub-system testing - modules are integrated into sub-systems
and tested. The focus here should be on interface testing
 System testing - testing of the system as a whole. Testing of
emergent properties
 Acceptance testing - testing with customer data to check that it
is acceptable

1/16/2025 25
Testing phases

1/16/2025 26
 Software Maintenance (evolution)
 Software is inherently flexible and can change.
 As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change

1/16/2025 27
 Software process models
 software development projects are large and
complex
 a phased approach to control it is necessary
 A software process model is an abstract representation
of a process
 Each process model represents a process from particular
perspective.
 Examples of process perspectives are
 Workflow perspective - sequence of activities
 Data-flow perspective - information flow
 Role/action perspective - who does what

1/16/2025 28
Generic software process models
 Code-and-Fix process model
 The waterfall process model
 Spiral process Model
 Incremental development process model
 Evolutionary development process model
 Formal Transformation process model
 Reuse-based development process model
 V-Model (Reading Assignment)
 Time Boxing (Reading Assignment)
 Extreme programming (Reading Assignment)

1/16/2025 29
Code-and-Fix process model
 This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs out).
Work is in random order.
 Advantages of this model:
 No administrative overhead
 Signs of progress (code) early.
 Low expertise, anyone can use it!
 Useful for small projects.

1/16/2025 30
Code-and-Fix, disadvantages

 Dangerous!
 No visibility/control
 No resource planning
 No deadlines
 Mistakes hard to detect/correct

 Impossible for large projects

 communication breakdown
 chaos.

1/16/2025 31
Waterfall model

 Linear sequence of stages/phases

 Requirements – HLD – DD – Code – Test – Deploy
 The following phase should not start until the
previous phase has finished: no feedback
 But in practice, phases overlap and may return
to a previous phase.
 The phases partition the project, each
addressing a separate concern

1/16/2025 32
Waterfall model

1/16/2025 33
Waterfall model…
 The drawback of the waterfall model:
 Requires that requirements are well-specified and
unchanging.
 Assumes a sequential flow, which real projects rarely
follow
 Working version becomes available very late (after
coding)
 Developers may have to wait due to dependent tasks
 This model is only appropriate when the
requirements are well-understood

1/16/2025 34
Waterfall model…
 Advantages of waterfall model:
 Easy to understand and implement.
 Widely used and known (in theory!)
 Fits other engineering process models: civil,
mechanical etc.
 Reinforces good habits: define-before- design,
design-before-code
 Identifies deliverables and milestones
 Works well on large/mature products and weak
teams.

1/16/2025 35
Spiral process Model

 Extends waterfall model by adding iteration to

explore/manage risk.
 A spiral model is divided into a number of
framework activities, also called task regions.
 Typically, there are between three and six task
regions.
 Delivers the software in a series of incremental releases
 When risks are high and need to be resolved, it is
reasonable to use this approach

1/16/2025 36
Spiral process Model…,

1/16/2025 37
Spiral process Model…
 Objective setting
 Specific objectives for the phase are identified
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the
key risks
 Development and validation
 A development model for the system is chosen which can
be any of the generic models
 Planning
 The project is reviewed and the next phase of the spiral is
planned

1/16/2025 38
Spiral process Model…

1/16/2025 39
Spiral process Model…
 customer communication – tasks required to
establish effective communication between
developer and customer.
 planning – tasks required to define resources,
timelines and other project related information
 risk analysis – tasks required to assess both
technical and management risks

1/16/2025 40
Spiral process Model…

 engineering – tasks required to build one or more

representations of the application
 construction and release – tasks required to
construct, test, install and provide user support (e.g.
documentation & training)
 customer evaluation – tasks required to get
customer feedback on evaluation of the software
representations created during the engineering stage
and implemented during the installation stage

1/16/2025 41
Spiral Process Model…
 Advantages:
 Realism: the model accurately reflects the iterative
nature of software development on projects with
unclear requirements.
 Flexible: incorporates the advantages of the waterfall
and evolutionary methods.
 Comprehensive model to decreases risk.
 Good project visibility.
 On each iteration, plans, costs, risks and schedules
updated and project manager get more accurate
estimate of number of required iterations

1/16/2025 42
Spiral Process Model…

 Spiral Process Model Problems

 Needs technical expertise in risk analysis and risk
management to work well.
 Model is poorly understood by non technical
management, hence not so widely used.
 Complicated model, needs competent
professional management.
 High administrative overhead.

1/16/2025 43
Incremental development model
 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.
 Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can continue
to evolve.

1/16/2025 44
Incremental development model…

1/16/2025 45
Incremental development model…

 Incremental development model advantages:

 Customer value can be delivered with each
increment so system functionality is available
earlier.
 Client does not have to pay for entire software
together.
 Early increments act as a prototype to help elicit
requirements for later increments
 Lower risk of overall project failure.
 The highest priority system services tend to
receive the most testing.

1/16/2025 46
Incremental development model…

 Incremental development model problems:

 Increments may be difficult to define
 Software may be difficult to maintain
 When the “core” product is well understood and
increments can be easily defined, it is
reasonable to use this approach.

1/16/2025 47
Evolutionary development model

 Evolutionary development is based on the idea

of developing an initially implementation,
 exposing this to user comment and
 refining this through many versions until an adequate
system development.

 When requirements are not well understood, it

may be reasonable to use this approach.
 A prototype’s purpose is to understand
requirements. A better (good quality) product
must be subsequently developed.

1/16/2025 48
Evolutionary development
model…

1/16/2025 49
Evolutionary development
model…
 There are two types of evolutionary development
 Exploratory development
- Objective is to work with customers and to evolve
a final system from an initial outline specification.
- Should start with well-understood requirements.
- The system evolves by adding new features as
they are proposed by customer.

1/16/2025 50
Evolutionary development
model…
 Throw-away prototyping
 Objective is to understand the system requirements.
Should start with poorly understood requirements
 Develop “quick and dirty” system quickly;
 Expose to user comment;
 Refine;
 Until adequate system is developed.
 Particularly suitable where:
 detailed requirements not possible;
 powerful development tools (e.g. GUI) available

1/16/2025 51
Evolutionary development
model…
 Evolutionary development model advantages:
 The resulting system is easier to use
 User needs are better accommodated
 Problems are detected earlier
 The design is of higher quality
 The development incurs less effort
 Evolutionary development model Problems:
 Lack of process visibility
 Systems are often poorly structured
 Special skills (e.g. in languages for rapid prototyping)
may be required

1/16/2025 52
 Evolutionary development model…

 The users and the designers must be well aware

of the issues and the pitfalls
 Use prototyping when the requirements are
unclear.

 Applicability
 For small or medium-size interactive systems
 For parts of large systems (e.g. the user interface)
 For short-lifetime systems

1/16/2025 53
Formal systems development
 Based on the transformation of a mathematical
specification through different representations to
an executable program.
 Transformations are ‘correctness-preserving’ so it
is straightforward to show that the program
conforms to its specification.
 Embodied in the ‘Clean room’ approach to
software development

1/16/2025 54
Formal systems development

 Problems
 Need for specialised skills and training to apply the
technique
 Difficult to formally specify some aspects of the
system such as the user interface.
 Advantage
 The resulting software will have high quality
 Applicability
 Critical systems especially those where a safety or
security case must be made before the system is put
into operation

1/16/2025 55
Reuse-oriented development
 Based on systematic reuse where systems are
integrated from existing components or COTS
systems
 Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
 System Validation
 This approach is becoming more important but
still limited experience with it

1/16/2025 56
Process Models & Process
visibility
 Software systems are intangible so managers
need documents to assess progress.
Process model Process visibility
Waterfall model Good visibility, each activity produces some
deliverable
Evolutionary Poor visibility, uneconomic to produce
development documents during rapid iteration
Formal Good visibility, documents must be produced
transformations from each phase for the process to continue
Reuse-oriented Moderate visibility, it may be artificial to
development produce documents describing reuse and
reusable components.
Spiral model Good visibility, each segment and each ring
of the spiral should produce some document.

1/16/2025 57
Automated process support (CASE)
 Computer-aided software engineering (CASE) is
software to support software development and
evolution processes
 CASE examples
 Graphical editors for system model development
 Data dictionary to manage design entities
 GUI builder for user interface construction
 Debuggers to support program fault finding
 Automated translators to generate new versions of a
program

1/16/2025 58
Case technology

 Case technology has led to significant

improvements in the software process though
not the order of magnitude improvements that
were once predicted.
 Software engineering requires creative thought - this is
not readily automatable
 Software engineering is a team activity and, for large
projects, much time is spent in team interactions.
CASE technology does not really support these

1/16/2025 59
CASE classification

 Classification helps us understand the different

types of CASE tools and their support for process
activities
 Functional perspective:
 Tools are classified according to their specific function
 Process perspective
 Tools are classified according to process activities that are
supported
 Integration perspective
 Tools are classified according to their organisation into
integrated units

1/16/2025 60
Functional tool classification

1/16/2025 61
 R eeng in eer in g to ol s

Test in g to ol s

D eb ug gi ng too ls

P r o gr am an aly si s t oo ls

L an gu age- p rocessi ng
t oo ls

M eth od sup po r t t oo ls

P r o to ty pi ng to ol s

C o nf i gu rat io n
m anag em ent t oo ls

C h an ge m anag em ent to ol s

D o cum en tat io n to ol s

E d it in g to ol s

P l ann in g to ol s

S p eci f icat io n D esig n I m pl em ent at io n V er if i cat io n

and

Process Activity-based classification V al id ati on

1/16/2025 62
CASE integration
 Tools
 Support individual process tasks such as design
consistency checking, text editing, etc.
 Workbenches
 Support a process phase such as specification or
design
 Environments
 Support all or a substantial part of an entire software
process.
 Normally include several integrated workbenches

1/16/2025 63
Tools, workbenches, environments

1/16/2025 64
CASE TOOLS

 CASE Tools can broadly be classified into two

 Upper-CASE:
 Tools to support the early process activities of
requirements and design
 Lower-CASE:
 Tools to support later activities such as
programming, debugging and testing

1/16/2025 65
Software Engineering and the
Engineering Profession
 The term Software Engineering was coined in 1968
 People began to realize that the principles of engineering
should be applied to software development
 Engineering is a licensed profession
 In order to protect the public
 Engineers design artifacts following well accepted
practices which involve the application of science,
mathematics and economics
 Ethical practice is also a key tenet of the profession
 In many countries, much software engineering does
not require an engineering license, but is still
engineering
1/16/2025 66
Ethics in Software Engineering
 Software engineers shall
 Act consistently with public interest
 Act in the best interests of their clients
 Develop and maintain with the highest standards
possible
 Maintain integrity and independence
 Promote an ethical approach in management
 Advance the integrity and reputation of the
profession
 Be fair and supportive to colleagues
 Participate in lifelong learning

1/16/2025 67