UNDERSTANDING

SOFTWARE ENGINEERING

IN AN EASY WAYYYY....
What is software?
 Computer programs and associated
documentation

 Software products may be developed for a

particular customer or may be developed for a
general market
 Software products may be
 Generic - developed to be sold to a range of
different customers
 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 production
Software engineers should
 adopt a systematic and organised approach to their
work
 use appropriate tools and techniques depending on
 the problem to be solved,
 the development constraints and
 the resources available
What is the difference between software
engineering and computer science?
Software
Computer Science
Engineering
is concerned with
 theory
 fundamentals  the practicalities of
developing
 delivering useful software

Computer science theories are currently

insufficient to act as a complete supporting for
software engineering, BUT it is a foundation for
practical aspects of software engineering
What is a software process?
 A set of activities whose goal is the
development or evolution of software
 Generic activities in all software processes
are:
 Specification - what the system should do
and its development constraints
 Development - production of the software
system
 Validation - checking that the software is what
the customer wants
 Evolution - changing the software in response
to changing demands
Types of Software
 Application software
 Easy-to-use programs designed to perform specific
tasks
 Application software makes computer popular and easy
to use
 Common application software:
 Microsoft Word, WordPerfect
 PowerPoint
 Netscape, Internet Explorer
 PhotoShop, Photo-Paint
 Quick Time
 Dreamweaver
System Software
 System software
 Programs that support the execution and
development of other programs
 Two major types

 Operating systems

 Translation systems (compilers & linkers)

System Software - Operating
System
 Controls and manages the computing resources
 Examples
 Windows, Unix, MSDOS,
 Important services that an operating system
provides:
 Security: prevent unauthorized users from accessing
the system
 Commands to manipulate the file system
 Input and output on a variety of devices
 Window management
 Utility Software
 Utility software (a type of
system software) is
designed to help you
monitor and configure
settings for your
computer system
equipment, the operating
system, or application
software
 A desktop widget is a
specialized utility program
that appears on a
computer’s screen-based
desktop
Chapter 3: Computer Software 9
What is the difference between software
engineering and system engineering?
 Software engineering is part of
System engineering
 System engineering is concerned with all
aspects of computer-based systems development
including
 hardware,
 software and
 process engineering
 System engineers are involved in
system specification,
architectural design,
integration and deployment
The System Development Life
Cycle

Hardware,
Hardware,software,
software,data,
data, System—Set
System—Setof ofcomponents
components
people,
people,and
andprocedures
proceduresthat
that that
thatinteract
interactto
toachieve
achieve
work
worktogether
togethertotoproduce
produce common
commongoalgoal
quality
qualityinformation
information
Businesses
Businessesuseusemany
manytypes
typesofof
systems
systems
The System Development Life
Cycle Who participates in the system
development life cycle?
The System Development Life
Cycle
What is a systems analyst?

Responsible for designing and

developing information system

Communication between users

and IT professionals
The System Development Life
Cycle
What is the project team?

Formed to work on project from beginning to end

Consists of users, systems analyst, and other IT professionals

Project leader—one member of the team who

manages and controls project budget and schedule
 The System Development
Life Cycle
Requirements
Establish customer’s needs
Collection
Model and specify the requirements
Analysis
(“what”)
Model and specify a solution
Design
(“how”)

Implementation Construct a solution in software

Validate the solution against the

Testing
requirements
Repair defects and adapt the
Maintenance
solution to new requirements

NB: these are ongoing activities, not sequential phases!

© Oscar Nierstrasz ESE — Introduction ESE 1.18
The System Development Life
Cycle
What are guidelines for system development?

Arrange tasks into phases (groups

of activities)
Involve users (anyone for whom system is being
built)

Develop clearly defined standards (procedures company expects

employees to follow)
SYSTEMS DEVELOPMENT
LIFE CYCLE (SDLC)
SDLC PHASE ACTIVITIES
1. Planning •Define the system to be developed
•Set the project scope
•Develop the project plan
2. Analysis •Gather business requirements
3. Design •Design the technical architecture
•Design system models
4. Development •Build technical architecture
•Build databases and programs
5. Testing •Write test conditions
•Perform testing
6. Implementation •Write user documentation
•Provide training
7. Maintenance •Build a help desk
•Support system changes
The System Development Life
Cycle
What is the planning phase?
Begins when steering committee receives project request
Steering
committee—
decision-making
body for the
company

Function of committee:

Form project
Review and development
Prioritize Allocate
approve project team for each
project requests resources
requests approved
project
The System Development Life
Cycle
What is the analysis phase?

Conduct preliminary Perform detailed

investigation, also analysis
called feasibility
study
The System Development Life
Cycle
What is the preliminary investigation?
 Determine exact nature of problem or improvement
and whether it is worth pursuing
 Findings are presented in feasibility report, also known as a feasibility study
The System Development Life
Cycle
What is feasibility? Operational
feasibility

Measure of Four feasibility

how suitable tests:
system Schedule
feasibility
development
will be to the Economic
company feasibility
(also called Technical
cost/benefit feasibility
feasibility)
 The System Development Life
Cycle
What is detailed analysis?
1. Study how current system
works

2. Determine user’s wants, needs,

and requirements

3. Recommend solution

Sometimes called logical design

The System Development Life
Cycle
What is the Assesses
system proposal? feasibility
of each
alternative
solution

Presented to
Recommen
steering
ds the most
committee,
feasible
which decides
solution for
how system
the project
will be
developed
The System Development Life
Cycle Horizontal market
What are possible solutions? Horizontal market
software—meets
software—meets
needs
needsofofmany
many
companies
Buy
Buypackaged
packagedsoftware—prewritten
software—prewritten companies
software
softwareavailable
availablefor
forpurchase
purchase
Vertical
Verticalmarket
market
software—designed
software—designed
for
forparticular
particularindustry
industry
Write
Writeown
owncustom
customsoftware—software
software—software
developed
developedat
atuser’s
user’srequest
request

Outsource—have
Outsource—haveoutside
outsidesource
source
develop
developsoftware
software
The System Development Life
Cycle
What is the design phase?

Acquire
Acquirehardware
hardwareand
andsoftware
software

Develop
Developall
alldetails
detailsof
ofnew
neworor
modified
modifiedinformation
informationsystem
system
The System Development Life
Cycle
What is needed to acquire new hardware and
software?

Talk
Talk with
with other
other Surf
Surf Web
Web
systems
systems analysts
analysts

Read
Read print
print and
and online
online
Visit
Visit vendors’
vendors’ stores
stores trade
trade journals,
journals,
newspapers,
newspapers, and
and
magazines
magazines

 Identify all hardware and software requirements of new or modified system

The System Development Life
Cycle
What is documentation?
Collection and summarization
of data and information

Includes reports, diagrams,

programs, and other deliverables
The System Development Life
Cycle
What are three basic documents used to
summarize technical specifications?
Vendor quotes
Identifies Request for quotation (RFQ) price(s) for
product(s) listed
you want product(s)

Vendor selects
Request for proposal (RFP)
product(s) that
meet(s) your
requirements and Less formal method
then quotes price(s) that uses standard
form to request
information about
Request for information (RFI) product or service
The System Development Life
Cycle
What is a detailed design?
Detailed design specifications for components in proposed solution

Includes several activities

Database
Database Input
Inputand
and Program
Program
design
design output
outputdesign
design design
design
The System Development Life
Cycle
What is a prototype?

Working
Working model
model of
of
proposed
proposed system
system

Beginning
Beginning aa prototype
prototype too
too early
early
may
may lead
lead to
to problems
problems
 The System Development Life
Cycle
 Software tools designed to support activities of system
development cycle
The System Development Life
Cycle
What is the implementation phase?
 Purpose is to construct, or build, new or modified
system and then deliver it to users

Convert to new system

Train users

Install and test new system

Develop programs
The System Development Life
Cycle What are the three types of tests
performed by system developers?

Unit Test Systems test

Verifies each Verifies all programs

individual program in application work
works by itself together

Integration Test

Verifies application
works with other
applications
 The System Development Life
Cycle
What is training?

 Showing users exactly

how they will use new
hardware and software
in system
The System Development Life
Cycle
What is the support phase?
 Provides ongoing assistance after system is implemented
Conduct post-implementation system review—meeting to find out if
information system is performing according to expectations

Identify errors

Identify enhancements

Monitor system performance

What are the attributes of good
software?
The software should deliver the required
functionality and performance to the user and
should be maintainable, Reliability and usable
 Maintainability
 Software must evolve to meet changing needs
 Reliability
 Software must be trustworthy
 Efficiency
 Software should not make wasteful use of system
resources
 Usability
 Software must be usable by the users for which it
was designed
What is Quality?
Software Quality is conformance to:
 explicitly stated functional and performance
requirements,
 explicitly documented development
standards,
 implicit characteristics that are expected of all
professionally developed software.

© Oscar Nierstrasz ESE — Software Quality ESE 11.40

Problems with Software
Quality
 Software specifications are usually incomplete and often
inconsistent

 There is tension between:

 customer quality requirements (efficiency, reliability, etc.)
 developer quality requirements (maintainability, reusability, etc.)

 Some quality requirements are hard to specify in an unambiguous

way
 directly measurable qualities (e.g., errors/KLOC),
 indirectly measurable qualities (e.g., usability).

Quality management is not just about reducing defects!

© Oscar Nierstrasz ESE — Software Quality ESE 11.41
Hierarchical Quality Model
Define quality via hierarchical quality model, i.e. a number of quality
attributes (a.k.a. quality factors, quality aspects, ...)
Choose quality attributes (and weights) depending on the project
context
Quality attribute
...

Reliability may be further

refined into
Software Efficiency subattributes
Quality
Usability

Maintainability

Portability

© Oscar Nierstrasz ESE — Software Quality ESE 11.42

Quality Attributes
Quality attributes apply both to the product and
the process.

 product: delivered to the customer

 process: produces the software product
 resources: (both the product and the
process require resources)
 Underlying assumption: a quality process leads to
a quality product (cf. metaphor of manufacturing
lines)
© Oscar Nierstrasz ESE — Software Quality ESE 11.43
Quality Attributes ...
Quality attributes can be external or internal.

 External: Derived from the relationship between the environment

and the system (or the process). (To derive, the system or process
must run)
 e.g. Reliability, Robustness

 Internal: Derived immediately from the product or process

description (To derive, it is sufficient to have the description)
 Underlying assumption: internal quality leads to external quality (cfr.
metaphor manufacturing lines)
 e.g. Efficiency

© Oscar Nierstrasz ESE — Software Quality ESE 11.44

Correctness, Reliability, Robustness

Correctness
 A system is correct if it behaves according to its specification
 An absolute property (i.e., a system cannot be “almost correct”)
 ... in theory and practice undecidable

Reliability
 The user may rely on the system behaving properly
 Reliability is the probability that the system will operate as expected over a
specified interval
 A relative property (a system has a mean time between failure of 3 weeks)

Robustness
 A system is robust if it behaves reasonably even in circumstances that were
not specified
 A vague property (once you specify the abnormal circumstances they
become part of the requirements)
© Oscar Nierstrasz ESE — Software Quality ESE 11.45
Efficiency, Usability
Efficiency (Performance)
 Use of resources such as computing time, memory
 Affects user-friendliness and scalability
 Hardware technology changes fast!
 First do it, then do it right, then do it fast

 For process, resources are manpower, time and money

 relates to the “productivity” of a process

© Oscar Nierstrasz ESE — Software Quality ESE 11.46

Efficiency, Usability ...
Usability (User Friendliness, Human Factors)

 The degree to which the human users find the system (process)
both “easy to use” and useful
 Depends a lot on the target audience (novices vs. experts)
 Often a system has various kinds of users (end-users, operators,
installers)
 Typically expressed in “amount of time to learn the system”

© Oscar Nierstrasz ESE — Software Quality ESE 11.47

Maintainability
 External product attributes (evolvability also
applies to process)

Maintainability
 How easy it is to change a system after its
initial release
 software entropy  maintainability gradually
decreases over time

© Oscar Nierstrasz ESE — Software Quality ESE 11.48

Maintainability ...
Is often refined to ...

Repairability
 How much work is needed to correct a defect

Evolvability (Adaptability)
 How much work is needed to adapt to changing requirements (both
system and process)

Portability
 How much work is needed to port to new environment or platforms

© Oscar Nierstrasz ESE — Software Quality ESE 11.49

Verifiability, Understandability
 Internal (and external) product attribute

Verifiability
 How easy it is to verify whether desired attributes are there?
 internally: e.g., verify requirements, code inspections
 externally: e.g., testing, efficiency

Understandability
 How easy it is to understand the system
 internally: contributes to maintainability
 externally: contributes to usability

© Oscar Nierstrasz ESE — Software Quality ESE 11.50

Productivity, Timeliness,
Visibility
 External process attribute (visibility also
internal)

Productivity
 Amount of product produced by a process for
a given number of resources
 productivity among individuals varies a lot
 often:
productivity (∑ individuals) < ∑ productivity (individuals)

© Oscar Nierstrasz ESE — Software Quality ESE 11.51

Productivity, Timeliness, Visibility ...
Timeliness
 Ability to deliver the Function
product on time
System
 important for marketing User needs capability
(“short time to market”)
 often a reason to sacrifice
other quality attributes
 incremental development
may provide an answer
Time
t0 t1 t2 t3 t4
initial
delivery redesign

© Oscar Nierstrasz ESE — Software Quality ESE 11.52

Productivity, Timeliness,
Visibility ...
Visibility (Transparency)
 Current process steps and project status are
accessible
 important for management
 also deal with staff turn-over

© Oscar Nierstrasz ESE — Software Quality ESE 11.53

Quality Control Assumption
Project Concern = Deliver on time and within budget

External (and Internal) Process Attributes

Product Attributes

Assumptions:

Internal quality External quality

Process quality Product quality

Control during project Obtain after project

Otherwise, quality is mere coincidence!

© Oscar Nierstrasz ESE — Software Quality ESE 11.54
 NB:
NB: Quality
Quality Management
Management
should
should bebe separate
separate from
from
The Quality Plan project
project management
management to
independence
independence
to ensure
ensure

A quality plan should:

 set out desired product qualities and how
these are assessed
 define the most significant quality attributes
 define the quality assessment process
 i.e., the controls used to ensure quality
 set out which organisational standards
should be applied
 may define new standards,
 i.e., if new tools or methods are used
© Oscar Nierstrasz ESE — Software Quality ESE 11.55
Software Quality Controls
1. Reviews
— Inspections for defect removal (product)
— Progress Assessment Reviews (product and
process)
— Quality reviews (product and standards)

2. Automated Software Assessment

— Measure software atributes and compare to
standards (e.g., defect rate, cohesion, etc.)
© Oscar Nierstrasz ESE — Software Quality ESE 11.56
Types of Quality Reviews
A quality review is carried out by a group of
people who carefully examine part or all of a
software system and its associated
documentation.

 Reviews should be recorded and records

maintained
 Software or documents may be “signed off” at a
review
 Progress to the next development stage is
thereby approved
© Oscar Nierstrasz ESE 11.57
ESE — Software Quality
 Types of Quality Reviews
…
Review type Principal purpose
Driven by checklist
> detect detailed errors in any
Formal Technical
product
Reviews
> mismatches between
(a.k.a. design or
requirements and product
program inspections)
> check whether standards have
been followed.
Driven by budgets, plans and
schedules
> check whether project runs
Progress reviews according to plan
© Oscar Nierstrasz ESE — Software Quality ESE 11.58
> requires precise milestones
Review Meetings
Review meetings should:
 typically involve 3-5 people
 require a maximum of 2 hours advance
preparation

© Oscar Nierstrasz ESE — Software Quality ESE 11.59

Review Minutes
The review report should summarize:
1. What was reviewed
2. Who reviewed it?
3. What were the findings and conclusions?

The review should conclude whether the product is:

4. Accepted without modification
5. Provisionally accepted, subject to corrections (no follow-up review)
6. Rejected, subject to corrections and follow-up review

© Oscar Nierstrasz ESE — Software Quality ESE 11.60

Review Guidelines
1. Review the product, not the producer
2. Set an agenda and maintain it
3. Limit debate and rebuttal
4. Identify problem areas, but don’t attempt to solve every problem
noted
5. Take written notes
6. Limit the number of participants and insist upon advance
preparation
7. Develop a checklist for each product that is likely to be reviewed
8. Allocate resources and time schedule for reviews
9. Conduct meaningful training for all reviewers
10. Review your early reviews

© Oscar Nierstrasz ESE — Software Quality ESE 11.61

Sample Review Checklists (I)
Software Project Planning
1. Is software scope unambiguously defined and bounded?
2. Are resources adequate for scope?
3. Have risks in all important categories been defined?
4. Are tasks properly defined and sequenced?
5. Is the basis for cost estimation reasonable?
6. Have historical productivity and quality data been used?
7. Is the schedule consistent?
...

© Oscar Nierstrasz ESE — Software Quality ESE 11.62

Sample Review Checklists (II)
Requirements Analysis
1. Is information domain analysis complete, consistent and accurate?
2. Does the data model properly reflect data objects, attributes and
relationships?
3. Are all requirements traceable to system level?
4. Has prototyping been conducted for the user/customer?
5. Are requirements consistent with schedule, resources and
budget?
...

© Oscar Nierstrasz ESE — Software Quality ESE 11.63

Sample Review Checklists (III)
Design
1. Has modularity been achieved?
2. Are interfaces defined for modules and external system elements?
3. Are the data structures consistent with the information domain?
4. Are the data structures consistent with the requirements?
5. Has maintainability been considered?

...

© Oscar Nierstrasz ESE — Software Quality ESE 11.64

Sample Review Checklists (IV)
Code
1. Does the code reflect the design documentation?
2. Has proper use of language conventions been made?
3. Have coding standards been observed?
4. Are there incorrect or ambiguous comments?

...

© Oscar Nierstrasz ESE — Software Quality ESE 11.65

Sample Review Checklists (V)
Testing
1. Have test resources and tools been identified and acquired?
2. Have both white and black box tests been specified?
3. Have all the independent logic paths been tested?
4. Have test cases been identified and listed with expected results?
5. Are timing and performance to be tested?

© Oscar Nierstrasz ESE — Software Quality ESE 11.66

Review Results
Comments made during the review should be classified.
 No action.
 No change to the software or documentation is required.
 Refer for repair.
 Designer or programmer should correct an identified fault.
 Reconsider overall design.
 The problem identified in the review impacts other parts of the design.

Requirements
Requirements andand
specification
specification errors
errors may
may have
have
to
to be
be referred
referred to
to the
the client.
client.

© Oscar Nierstrasz ESE — Software Quality ESE 11.67

Queries?
Thank You all