INTRODUTION TO SCOPE OF SOFTWARE ENGINEERING

Engr . M. Fahad Khan

Lecturer Software Engineering Department

University Of Engineering & Technology Taxila

Outline

• Introduction to Software Engineering

• Software Life Cycle

• Software Requirements Specification

• Software Design Principles

• Software Architecture

• Introduction to Software Design

• Object-Oriented Analysis and Design Methods

• Software Project Management

• Software Testing

• Software Maintenance

• Software Quality Assurance

• Software Configuration Management

Course Overview• Lectures

• Tutorials

• Assessment– Final Exam 40%

– Project 30%

• Software Requirement 10%

• Software Design and Prototype 10%

• Final Report and Demonstration 10%

– Mid exam 20%

– Quiz 10%

• Study Hours

Course Materials

• Software Engineering, Ian Sommerville, 7th Edition, Addison Wesley,

2004.

• Pattern-oriented Software Architecture (POSA) Vol 1-5

• Essential Software Architecture, Ian Gorton, Springer 2006

• Architecting Secure Software Systems, Auerbach Publications, 2009

• “Software Engineering: A Practitioner‟s Approach” 5th Ed. by Roger

S. Pressman, Mc-Graw-Hill,2007

Introduction to Software Engineering

What is Software Engineering• Software

– programs that provide function & performance

– data structures for information manipulation

– documents that describe the operations and use of

the programs

• Engineering

– A discipline that applies scientific and technical

methods in the design and production of a product

Definition of Software Engineering

IEEE Definition:

The application of a systematic, disciplined,

quantifiable approach to the development,

operation, and maintenance of software

Another Definition of Software Engineering

The practical application of scientific

knowledge in the design and construction of

computer programs and the associated

documentation required to develop, operate,

and maintain them

(Boehm)

Objectives of Software Engineering

• To improve quality of software products

• To increase customer satisfaction

• To increase productivity

• To increase job satisfaction

“This is not just a programming course”

Historical Background

• Early days of computing, programs were

written to make hardware work

• Programming was not a discipline, more like

a hobby or “art form”

• However, computer developments require

larger programs to be developed e.g.

compilers and operating systems

• Programming becomes a profession

Computer Expenditure

Software Maintenance

Hardware Maintenance

Software

Development

1955 2009

100%

Software Crisis

• The large programming projects required

many programmers working together

• The projects were not delivered on time and

costs more than initial budget - software

crisis

• Software Engineering methods were

developed to overcome these problems

The Systematic Process Use In Software

Engineering

Problem

Models

Solution

Analysis

Design

Development

Testing

Software Characteristics

• Software is developed or engineered, not

manufactured in the classical sense

• Software doesn‟t “wear out”

• Most software is custom-built, rather than

being assembled from existing components

What Is A Good Software?

• Software is intangible

• Good software is subjective

• Some qualities that is used to assess:

– correctness

– reliability

– usability

– integrity

– reusability

Software Applications

• System Software

• Real-time Software

• Business Software

• Engineering & Scientific Software

• Embedded Software

• Personal Computer Software

• Artificial Intelligence Software

Software Life Cycle

“What happens in the „life‟ of software”

Software Life Cycle

a quality focus

process

methods

tools

Software Engineering Layers

Software Process

• Activities in software projects

• Characterised by a common process

framework

– Framework activities - task sets

– Umbrella activities

• “Process maturity” enables development of

quality software products

Common Process Framework

Common Process Framework

Umbrella activities

Framework Activities

Task sets

Tasks

Milestones, Deliverables

SQA points

Generic Phases

• Definition Phase

– Focus on „what‟ the software is

• Development Phase

– Focus on „how‟ the software works

• Maintenance Phase

– Focus on „change‟ to the software

Definition Phase

• Identify information to be processed

• Identify system behavior - functions and performance

• Determine constraints, interfaces, validation criteria

• Major tasks:

– System engineering

– Software project planning

– Requirements analysis

Development Phase

• Define data structures, function implementation,

procedural details, interfaces

• Translate design to programming language

• How testing is performed

• Major tasks:

– Software design

– Code generation

– Software testing

Maintenance Phase

• Reapplies definition and development

phases to existing software

• Types of changes:

– Correction

– Adaptation

– Enhancement

– Prevention

Umbrella Activities

• Software project tracking and control

• Formal technical reviews

• Software quality assurance

• Software configuration management

• Document preparation and production

• Reusability management

• Measurement

• Risk management

Software Engineering Paradigms

• Waterfall Model

• Prototyping Model

• Rapid Application Development (RAD)

• Incremental Model

• Spiral Model

• Component Assembly Model

• Fourth Generation Techniques (4GT)

System

Engineering

Analysis

Design

Code

Testing

Maintenance

Waterfall Model

Waterfall Model Characteristics

• The classic life cycle - oldest and most widely

used paradigm

• Activities „flow‟ from one phase to another

• If there are corrections, return to a previous

phase and „flow‟ from there again

• Major advantages: Good for planning and well-

defined/repeated projects

Prototyping Model

Requirements

gathering and

refinement

Building

prototype

Quick

design

Customer

evaluation

Refining

prototype

Engineer

product

Start

Stop

Rapid Application Development

(RAD)

Business

Modeling

Data

Modeling

Process

Modeling

Application

Generation

Testing &

Turnover

Team #1 Business

Modeling

Data

Modeling

Process

Modeling

Application

Generation

Testing &

Turnover

Team #2

RAD Characteristics

• “High-speed” version of waterfall model

• Primarily for information systems applications

• Requirements well-understood, fully functional system

produced in short time

• The application modularised - major functions can be

completed in 3 months

• Separate teams complete the functions, then integrated

as a whole

• Requires human resource and commitment

analysis design code test 1st increment

analysis design code test 2nd increment

analysis design code test 3rd increment

Incremental Model

Incremental Model Characteristics

• Software separated into different

“increments” - complete working portions

• Focus on delivery of operational product with

each increment - can be evaluated

• Useful when insufficient staff and can be

planned to manage technical risks, e.g.

waiting for new hardware

Spiral Model

Customer

Communication

PlanningRisk Analysis

Engineering

Construction & Release

Customer

Evaluation

Spiral Model Characteristics

• Originally proposed by Boehm, couples

iterative nature of prototyping and the

systematic aspects of waterfall model

• Software is developed in series of

incremental releases

• Each iteration produces a more complete

product

• Better management through risk analysis

Component Assembly Model

Identify

candidate

components

Look up

components

in library

Available?

Extract

components

Build

components

Construct

System

yes

no

Component Assembly Characteristics

• Use of object-oriented technology

• Components - classes that encapsulate both

data and algorithms

• Components developed to be reusable

• Paradigm similar to spiral model, but

engineering activity involves components

• System produced by assembling the correct

components

Requirement

gathering

Design

Strategy

Implementation

for 4GL

Testing

Fourth Generation Techniques (4GT)

4GT Characteristics

• Use of software tools that allow software

engineer to specify s/w characteristics at higher

level

• The tools generate codes based on specification

• More time in design and testing - increase

productivity

• Tools may not be easy to use

Software Requirements Specification

“Writing down the requirements”

Software Requirements Specification

• From our understanding of the problem, we

now write down what the customer wants

from the software

• Documentation of what the software is

supposed to be

• Many companies regard it as „contract‟

between customer and developer

• The basis for validation and verification

Using Natural Language

• More than 50% of the content of the

specifications are usually written using plain

• Easy to produce

• Easy for customer to understand

• Can be improved by using structured form,

using fields and description placed in fields

Examples of Specifications

• The printout of outstanding creditors are

done monthly at the end of each month.

• Purchase orders are automatically generated

when the item quantity reaches below the

reorder level.

• Usually the report is produced based on the

code given.

Problems of Natural Language

• Lack of clarity

– Words such as “some”, “usually”, “probably”

• Ambiguity

– Some words have more than one meaning

• Context dependency

– Same word in different sentences have

different meaning

– Depends on whole paragraph/page/document

Using Diagrams

Graphical representation of the analysis can

present the information better using:

• Entity-Relationship Diagrams

• Data Flow Diagrams

• State Transition Diagrams

– event table, action table

• Decision Tables

• Decision Trees

Good Specifications

• Correct

• Complete

• Consistent

• Unambiguous

• Functional

• Verifiable

• Traceable

• Easily changed

Software Design Principles

“Producing the software blueprint”

Designing A House• If you are asked to design a house…

Room 1

Living

Room

KitchenRoom 2

D

D

D

D

W

W W

W

WC

What Is Design?

• Explaining the idea/concept of something

• Usually with graphical diagrams

• With the intention to build from the

explanation

• So a design is a representation of a product

or a system with sufficient detail for

implementation

The Second Task

Problem

Models

Solution

Analysis

Design

Development

Testing

Designing Software

• From our understanding of the problem, we start

building the software

• Translate the analysis model into the design

model

• Map the information from the analysis model to

the design representations - data design,

architectural design, interface design,

procedural design

Translation Model

Data Dictionary

Entity-

Relationship

DiagramData Flow

Diagram

State-Transition

Diagram

Data design

Architectural design

Interface

design

Procedural

design

Design Principles

• Design process should not suffer from

“tunnel vision”

• The design should be traceable to the

analysis model

• The design should not reinvent the wheel

• The design should “minimise intellectual

distance” between the software and the

problem in the real world

Design Principles (Continued)

• The design should exhibit uniformity and

integration

• The design should be structured to

accommodate change

• The design should be structured to degrade

gently, even when deviate data, events, or

operating conditions are encountered

Design Principles (Continued)

• Design is not coding, coding is not design

• The design should be assessed for quality

as it is being created

• The design should be reviewed to minimize

conceptual errors

• Abstraction

• Refinement

• Modularity

• Software

Architecture

• Control Hierarchy

• Structural Partitioning

• Data Structure

• Software Procedure

• Information Hiding

Fundamental concepts which provide

foundation to design correctly:

Design Concepts

Abstraction

• Identifying important features for representation

• There are many levels of abstraction depending

on how detailed the representation is required

• Data abstraction - representation of data objects

• Procedural abstraction - representation of

instructions

Refinement

• Stepwise refinement - top-down design strategy

by Niklaus Wirth

• Starting at the highest level of abstraction, every

step of refinement „decompose‟ instructions into

more detailed instructions

• Complementary to abstraction

Modularity

• Software is divided into separately named

and addressable modules

• “Divide and conquer” approach - problem is

broken into manageable pieces

• Solutions for the separate pieces then

integrated into the whole system

S1

S2

S3

S4

S5

P5

P4P3

P2P1

Divide & Conqure

Software Architecture

• Modules can be integrated in many ways to

produce the system

• Software architecture is the overall structure of

the software

• The hierarchy of components and how they

interact, and the structure of data used by the

components

• Use of framework models, and possible reuse of

architectural patterns

Examples of Software Architecture

S1

S2

S3

S4

S5

S3

S2 S4 S5

S1

Vertical Integration

superordinate module

Control hierarchy

hierarchy of components

subordinate module

Control Hierarchy

• Hierarchy of modules representing the

control relationships

• A superordinate module controls another

module

• A subordinate module is controlled by

another module

• Measures relevant to control hierarchy:

depth, width, fan-in, fan-out

g hed

i

f

a b c

M

Fan-out

Fan-in

Width

Depth

Structure Terminology

Structural Partitioning

• Program structure partitioned horizontally

and vertically

• Horizontal partitioning defines separate

branches for each major program function -

input, process, output

• Vertical partitioning (aka factoring) defines

control (decision-making) at the top and work

at the bottom

Data Structure• Representation of the logical relationship among

individual elements of data

• Structure of information will affect the procedural

design – access , processing ,etc.

• Classic data structures: scalar item, sequential

vector, n-dimensional space, linked list,Ques

• Other data structures are constructed using the

above data structures

Software Procedure

• Processing details of individual modules

• Precise specification of processing, including

sequence of events, exact decision points,

repetitive operations, and data

organisation/structure

• Procedure is layered - subordinate modules

must be referenced in processing details

Information Hiding

• Information (procedure and data) contained

within a module is inaccessible to other modules

that have no need for such information

• Effective modularity is achieved by independent

modules, that communicate only necessary

information

• Ease of maintenance - testing, modification

localised and less likely to propagate

Problems in Software Architectural Design

• An ad hoc approach to design does not

scale with respect to the size and complexity

of the application.

• As the number of functions and quality

attributes grows, so does the need for more

control of the application design.

Obstacles to Achieving High-Quality

Architectural Design• A lack of awareness of the importance of

architectural design to software development.

• A lack of understanding of the role of the software architect.

• A widespread view than designing is an art form, not a technical activity.

• A lack of understanding of the design process.

Obstacles to Achieving High-Quality Architectural

Design (Cont‟d)

• A lack of design experience in a

development organization.

• Insufficient software architecture design

methods and tools.

• A lack of understanding of how to evaluate

designs.

• Poor communication among stakeholders.

When Are the Architecture Design Activities

Done?• They can be practiced during any phase of

the development process.

• However, to be of greatest benefit they

should be done as early as possible.

• These activities can be viewed as a linear

set of steps that can be repeated whenever

missing information or hidden assumptions

are identified.

Function and Product Planning

• An application‟s architecture must address

end-user needs.

• The architecture must be (partially)

perceivable to the users of the application.

• Architecting begins with a specification of an

application or system in terms of the

functions, capabilities, and other qualities

that it must possess.

Form and Interaction Design• According to Alan Cooper design can be

divided into interaction design and program design.

• Interaction design is that which directly affects the ultimate end user of the application.

• All other design is called program design.

• Poor interface design contributes to cognitive friction or “the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem permutes.”

• The interaction design is the user‟s conceptual model or virtuality.

Tasks and Activities of Design

• Origin of the task

• Organization

• Novelty

• Production

• Technology

• Horizontal domain

• Quality attributes

Origin of the Task

Possible origins for a design task:

Product planning (especially for commercial

software)

In-house software (custom systems)

Systems integration

Production and field testing

Organization

• The design process is usually organized around

the structure of the development organization.

• Two common types of organization are:

– Product-oriented – product development and

production responsibilities are divided among

different divisions based on product type.

– Problem-oriented – work is organized according to a

division of labor along domain boundaries such as

database administration, user interface design, etc.

• Each organizational type affects the choice of

design activities and how they are performed.

Novelty

Some design task require much more

invention and creative problem solving than

others. The novelty of the problem can be

categorized as follows:

Original design

Adaptive design

Variant design

Original Design

• Starts with a clean slate.

• May be created through the synthesis of

known solution principles and existing

technology.

• May require inventing something new.

Adaptive Design

• Starts with known or established solution

principles.

• Adapts the principles to fit the current

problem.

• May involve some original design as new

components are added to meet new

requirements.

Variant Design

Starts with an existing design.

Modifies the design with respect to

some nonfunctional quality attributes.

For example, changes to improve

performance of certain operations, or

be able to handle greater user loads.

Production

• Software may be created for either:

– A One-off custom system

– Commercial software for sale

• For one-off systems functionality, maintainability,

performance, reliability and/or availability are

typically the most important qualities.

• For Commercial systems functionality,

performance, extensibility, adaptability, and

usability are commonly the paramount qualities.

TechnologyDifferent technologies require different design

methods. Some technology areas that affect design methods are:

Information representation

Data storage

Data transformation

Business logic

User interface design

Vendor platforms

Horizontal Domain

• Systems can be characterized by their

relative complexity.

• Systems can be divided horizontally into

layers or horizontal domains where each

layer has its own complexities.

• The demarcation of a horizontal domain is

based on the types of concerns addressed

by design and the patterns, methods, and

tools specific to a domain.

Quality Attributes

• One of the largest factors that affect the

design task is the set of required quality

attributes of the system.

• The architect must find a balance among the

competing quality attributes.

• Many passes through the design process

may be needed as design tradeoffs are

considered and proposed designs are

evaluated.

Common Quality Attributes

• Functionality

• Buildability

• Cost and time to market

• Performance

• Usability

• Security

• Availability and reliability

• Modifiability

Object-Oriented Analysis and Design

Methods

“How to create and define objects?”

Object-Oriented Analysis

• Identify the objects and classes

• Identify the object attributes

• Identify operations on objects and classes

• Define object and class relationships

• Model dynamic concepts

Identify the objects and classes

• Grammatical Analysis

– Nouns are objects and attributes

– Verbs are operations or services

• Tangible entities (things), roles, events,

interactions, etc. in application domain

• Use behavioural approach

– Participants in behaviours as objects

• Scenario-based analysis

Identify the object attributes

• Specify attributes (instance variables) of

objects in problem domain

• These are to be recorded, displayed, stored,

and/or manipulated in functions of the

domain

Identify operations on objects and classes

• Operations that are used to interact with the

objects and classes

• Each class has a protocol that captures the

messages or operations that could be

handled by the class or its instances

• Users or “clients” of classes and objects deal

primarily with the external operations of the

class

Example Scenario

“The Office Information Retrieval System (OIRS) can

file documents under some name in one or more

indexes, retrieve documents, display and maintain

document indexes, archive documents and destroy

documents. The system is activated by a request from

the user and always returns a message to the user

indicating the success or failure of the request.”

Objects Identified

Index

Name

Display

Delete entry

Add entry

User

Get command

Put message

Document

Name

File

Retrieve

Archive

Destroy

Retrieval

System

User command

Define object and class relationships

Capture relationship between classes.

Typical relationships:

• Inheritance

– Organisation of classes or entity types in

problem domain

• One-to-One, One-to-Many, Many-to-Many

– relationships that exist between objects that

reference each other

Example of Inheritance

Person

StudentEmployee

MarketingPersonSalesPerson

SalesManager

Example of Other Relationships

Country City

PersonCompany

File User

Has-capital

Works-for

Accessible-by

One-to-One

One-to-Many

Many-to-Many

Model dynamic concepts

• State transition diagrams

– Specify states of the objects

– Specify events that trigger transitions

– Specify actions taken due to transitions

• Data flow diagrams

– Describe flow of objects and information

• Timing diagrams

– Illustrate object interations over time

State transition diagram

Black’s

turn

White’s

turn Start

Black

moves

White

moves

checkmate

checkmate

stalemate

stalemate

Draw

White

wins

Black

wins

Data flow diagram

Customer

Update

Verify

Account

password

amount

cash

Coded

password

old

balance

Password

ok

new

balance

Timing diagramsCaller Phone line Callee

Caller lifts receiver

Dial tone begins

Dials number

Ringing tone Phone rings

Answers phone

Tone stops Ringing stops

Phones connected Phones connected

Callee hangs up

Connection broken Connection broken

Object-Oriented DesignDetailed specifications of the following:

• Subsystems or class categories

– Partitioning the system, providing interfaces,

interactions, and mapping to targeted system

• Class definitions

– structure or representation

– behaviour or operations

– implementation algorithms

– additional support classes for implementation

Object-Oriented Design (Continued)

• Class relationships

– Containment

– Referencing

– Aggregation

– Inheritance

• Object diagrams and object relationships

– Descriptions of how objects interact

– Class interaction - what classes are used by

another class

Object-Oriented Design (Continued)

• State transition

– Extends state transition diagrams in analysis

• Timing diagrams

– Extends timing diagrams in analysis

• Designing algorithms

– implementation algorithms and logic

• Physical compilation units

– Compilation modules, interface specifications

Software Project Management

“What is happening in the project?”

Project

• A group of tasks performed in a definable time

period in order to meet a specific set of

objectives

• Features

– likely to be unique (one-time program)

– have specific start and end time (life cycle)

– have work scope that can be categorised into

definable tasks

– has a budget, require use of resources

A Simple Project

“Going to the movies with friends”

Management

• The planning, organising, staffing, directing

and controlling of company resources to

meet the company‟s objectives

Definition of Project

Management

• The planning, organizing, directing, and

controlling of resources for a specific time

period to meet a specific set of one-time

objectives

Primary Objectives of Project Management

• To meet specified performance

– ... within cost

– ... and on schedule

Project Management Activities

• Establish project objectives

• Defining work requirement

• Determining work timing

• Establishing resource availability and

requirements

• Establishing a cost baseline

• Evaluating and optimizing the baseline plan

Project Management Activities (Continued)

• Freezing the baseline plan

• Tracking the actual costs

• Comparing the progress and cost to the

baseline plan

• Evaluating performance

• Forecasting, analyzing and recommending

corrective action

Benefits of Project Management

• Identification of function responsibilities to ensure

that all activities are accounted for, regardless of

personnel turnover

• Minimizing the need for continuous reporting

• Identification of time limits for scheduling

• Identification of a methodology for tradeoff

analysis

Benefits of Project Management (Continued)

• Measurement of accomplishment against

plans

• Early identification of problems

• Improved estimating capabilities for future

planning

• Knowing when objectives cannot be met or

will be exceeded

Project Management Concerns

• Resources inadequate

• Meeting (“unrealistic”) deadlines

• Unclear goals/direction

• Team members uncommitted

• Insufficient planning

• Breakdowns in communications

• Changes in goals and resources

• Conflicts between departments or functions

Project Management Problems

Resources of A Company

• Money

• Manpower

• Equipment

• Facilities

• Materials

• Information/technology

Obstacles in Project Management

• Project complexity

• Customer‟s special requirement

• Organizational restructuring

• Project risks

• Changes in technology

• Forward planning and pricing

Project Management Skills

• Communication Skills

• Organizational Skills

• Team Building Skills

• Leadership Skills

• Coping Skills

• Technological Skills

Project Plan

“What are you going to do in the project?”

Project Plan Elements• Project Objective & Scope

• Schedule

• Team Organization

• Project Standards and Procedures

• Documentation Plan

• Quality Assurance Plan

• Resource Management Plan

• Configuration Management Plan

Hierarchical Organization

Democratic Organization

Team Leader

• Communications with Lecturer

• Coordination of Project Activities

• Final say in decisions if the team is unable to

reach a decision

Programming Leader

• Responsible for programming activities

• Coordination of software development tasks

• Knowledge of programming language and

tools

Quality Manager

• Responsible for quality in project work

• Coordination of testing and review activities

• Ensure that quality standards are adhered

e.g. version control and document formats

Document Manager

• Responsible for documentation activities

• Coordination of document preparation tasks

• Keeps „master copy‟ of all project documents

Resource Manager

• Responsible for project resources

• Treasurer - manages the costs of the project

• Ensures that resources are obtained for

project tasks e.g. computer resources

Project Standards Example

• All documents must have a version number

• All documents must be prepared using MS

Word

• All meetings must have minutes

• Project file name extensions, suffixes,

prefixes

Software Configuration

• Computer programs

– Source code

– Executable code

• Documents that describe the computer

programs

– For technical staff

– For users

• Data

– Within the program and external to it

Software Configuration Item

• A document or an artifact that is explicitly placed

under configuration control and that can be

regarded as a basic unit for modification

• Examples:

– requirement documents

– design document

– code of a module

– test plan

SOFTWARE TESTING

What is Software TestingSeveral definitions:

“Testing is the process of establishing confidence that a program or

system does what it is supposed to.” by Hetzel 1973

“Testing is the process of executing a program or system with the

intent of finding errors.” by Myers 1979

Software testing is the process of analyzing a software item to detect

the differences between existing and required conditions (that is, bugs)

and to evaluate the features of the software item (IEEE, 1986; IEEE,

1990).

Testing ObjectivesThe Major Objectives of Software Testing:

1 Identify the magnitude and sources of development risk reducible by

testing.

2 Perform testing to reduce identified risks.

3 Know when testing is completed.

4 Manage testing as a standard project within the development

project.

Major goals:

uncover the errors (defects) in the software, including errors in:

- requirements from requirement analysis

- design documented in design specifications

- coding (implementation)

- system resources and system environment

- hardware problems and their interfaces to software

Who does Software Testing

- Test manager

- manage and control a software test project

- supervise test engineers

- define and specify a test plan

-Test Analyst

- design and implement one or more test scripts

- assist the team leader in the generation of test specification doc.s

-Software Test Engineers and Testers

- define test cases, write test specifications, run tests

- Independent Test Group

Who does Software Testing

-Development Engineers

- Only perform unit tests and integration tests

- Quality Assurance Group and Engineers

- Perform system testing

- Define software testing standards and quality control process

Why we go for testing?Well, while making food, its ok to have something extra, people

might understand and eat the things you made and may well

appreciate your work. But this isn't the case with Software

Project Development. If you fail to deliver a reliable, good and

problem free software solution, you fail in your project and

probably you may loose your client. This can get even worse!

So in order to make it sure, that you provide your client a proper

software solution, you go for TESTING. You check out if there is

any problem, any error in the system, which can make software

unusable by the client. You make software testers test the

system and help in finding out the bugs in the system to fix them

on time. You find out the problems and fix them and again try to

find out all the potential problems.

What is the role of tester

A tester is a person who tries to find out all

possible errors/bugs in the system with the

help of various inputs to it. A tester plays an

important part in finding out the problems with

system and helps in improving its quality.

If you could find all the bugs and fix them all,

your system becomes more and more reliable.

A tester has to understand the limits, which

can make the system break and work abruptly.

The more number of VALID BUGS tester finds

out, the better tester he/she is!

Software Errors, Defect & FaultWhat is a software error?

Definition #1:

“A mismatch between the program and its specification is an

error in the program if and only if the specification exists and is correct.”

Definition #2:

“A quality problem that is discovered by software engineers or

others before the software is released to end user.

software Defect & Software Fault?

A quality problem that is discovered after the software has been

released to end users

A programmer

makes a mistake.

The mistake manifests

itself as a fault [or

defect] in the program.

A failure is observed

if

the fault [or defect] is

made visible.

Software Testing Activities- Test Planning

Define a software test plan by specifying:

- a test schedule for a test process and its activities, as well as

assignments

- test requirements and items

- test strategy

- Test Design and Specification

- Conduct software design based well-defined test generation methods.

- Specify test cases to achieve a targeted test coverage.

- Test Set up:

- Testing Tools and Environment Set-up

- Test Suite Set-up

- Test Operation and Execution

- Run test cases manually or automatically

Software Testing Activities- Test Result Analysis and Reporting

Report software testing results and conduct test result analysis

- Problem Reporting

Report program errors using a systematic solution.

-Test Management and Measurement

Manage software testing activities, control testing schedule,

measure testing complexity and cost

- Test Automation

- Define and develop software test tools

- Adopt and use software test tools

- Write software test scripts and facility

- Test Configuration Management

- Manage and maintain different versions of software test suites,

test environment and tools, and documents for various product

versions.

Verification & ValidationSoftware testing is one element of a broader topic that is often referred to as

===> Verification and Validation (V&V)

Verification --> refers to the set of activities that ensure that software correctly implements

a specific function.

Validation --> refers to a different set of activities that ensure that the software that has

been built is traceable to customer requirements.

Boehm [BOE81]:

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”

The definition of V&V encompasses many of SQA activities, including

formal technical reviews, quality and configuration audits

performance monitoring, different types of software testing

feasibility study and simulations

When to Stop testingIts difficult to determine exactly when to stop Testing. The following are some

of the cases which can help to decide when to reduce/stop Testing:

1)Deadlines(Release/Test Deadlines etc)

2)Test cases completed with certain percentage passed.

3)Test budget depleted.

4)Coverage of code/functionality requirements reaches a specified point.

5)Bug rate falls below a certain level.

6)Beta or Alpha testing period ends.

Software Testing Myths- We can test a program completely. In other words, we test a program

exhaustively.

- We can find all program errors as long as test engineers do a good job.

- We can test a program by trying all possible inputs and states of a program.

- A good test suite must include a great number of test cases.

- Good test cases always are complicated ones.

- Software test automation can replace test engineers to perform good software

testing.

- Software testing is simple and easy. Anyone can do it. No training is needed.

Software Testing Limits

- Due to the testing time limit, it is impossible to achieve total confidence.

- We can never be sure the specifications are 100% correct.

- We can never be certain that a testing system (or tool) is correct.

- Test engineers never be sure that they completely understand a software

product.

- We never have enough resources to perform software testing.

- We can never be certain that we achieve 100% adequate software testing.

The Mind of a Tester

Kaner, Bach, and Pettichord describe four different kinds of thinking

exhibited by a good tester:

1. Technical thinking: the ability to model technology and understand

causes and effects

2. Creative thinking: the ability to generate ideas and see possibilities

3. Critical thinking: the ability to evaluate

ideas and make inferences

4. Practical thinking: the ability to put

ideas into practice

Ten Principles Of Good software Testing

1. A necessary part of a test case is a definition of the expected output or result.

2. A programmer should avoid attempting to test his or her own program.

3. A programming organization should not test its own programs.

4. Thoroughly inspect the results of each test.

5. Test cases must be written for input conditions that are invalid and

unexpected, as well as for those that are valid and expected.

6. Examining a program to see if it does not do what it is supposed to do is only

half the battle; the other half is seeing whether the program does what it is not

supposed to do.

7. Avoid throwaway test cases unless the program is truly a throwaway program.

8. Do not plan a testing effort under the assumption that no errors will be found.

9. The probability of the existence of more errors in a section of a program is

proportional to the number of errors already found in that section.

10. Testing is an extremely creative and intellectually challenging task

Tester Versus Developer Roles In Software EngineeringIn the beginning, there was the software developer and he was mighty. He could write

specifications, could code programs, could test programs, and could deliver perfect systems.

Testers were non-technical employees who volunteered to come into the office on a weekend

and pound on a computer keyboard like a trained monkey in exchange for pizza and beer. The

emergence of a massive Y2K catastrophe threat changed technical perceptions forever. The

software developer‟s shiny armor of invincibility was considerably tarnished, whereas the

tester‟s technical acumen rose and shone like the sun. It is now very clear that both the

developer and the tester have specific, complementary, highly technical roles to fulfill in the

development of good software.

Type Of Testing

Testing is often divided into black box testing and white box testing.

Black box testing is a strategy in which testing is based solely on the requirements and

specifications. Unlike its complement, white box testing, black box testing requires no

knowledge of the internal paths, structure, or implementation of the software under test.

White box testing is a strategy in which testing is based on the internal paths, structure, and

implementation of the software under test. Unlike its complement, black box testing, white

box testing generally requires detailed programming skills.

An additional type of testing is called gray box testing. This involves having access to internal

data structures and algorithms for purposes of designing the test cases, but testing at the

user, or black-box level.

This is particularly important when conducting integration testing between two modules of code

written by two different developers, where only the interfaces are exposed for test.

Method Of TestingThere are two basic methods of performing

software testing:

1. Manual testing

2. Automated testing

Manual TestingAs the name would imply, manual software testing is the process of an individual or individuals

manually testing software. This can take the form of navigating user interfaces, submitting

information, or even trying to hack the software or underlying database. As one might

presume, manual software testing is labor-intensive and slow.

There are some things for which manual software testing is appropriate, including:

1. User interface or usability testing

2. Exploratory/ad hoc testing (where testers do not follow a „script‟, but rather testers

„explore‟ the application and use their instincts to find bugs)

3. Testing areas of the application which experience a lot of change.

4. User acceptance testing (often, this can also be automated)

Manual Testing

The following are the steps followed at Paradigm for

Manual Testing;

1. Test Analysis

2. Test Planning

3. Test Case Design

4. Test Execution

5. Status Reporting with Pass/Fail

6. Regression test

Automated TestingAutomated software testing is the process of creating test scripts that can then be run

automatically, repetitively, and through many iterations. Done properly, automated

software testing can help to minimize the variability of results, speed up the testing

process, increase test coverage (the number of different things tested), and ultimately

provide greater confidence in the quality of the software being tested.

There are, however, some things for which automated software testing is not appropriate. These

include:

End user usability testing is not typically a good candidate for automated testing.

Tests for areas of the application which experience a lot of change are also not a good candidate

for automation since this can lead to substantial maintenance of test automation scripts.

Such areas of the application may be more effectively tested manually.

It is important to note that test automation is software, and just like the software you are building

for internal or external customers, it must be well-architected.

Automated testing Life Cycle

Manual Vs automated Testing

Manual tests are those that require human intervention to perform a test procedure.

Automated tests can be designed to replicate any user/application activity in a high-

speed and easily replicated environment. Not all tests should, or can be, automated.

Certain processes that require human intervention, such as loading special paper

into a printer, cannot be automated by a software tool.

Automation is a not a Replacement of Manual Testing :

Test automation is expensive and it is an addition, not a replacement, to manual

testing. It can be made cost-effective in the longer term though, especially in

regression testing.

What Tools Does :

Many test automation tools provide record and playback features that

allow users to record interactively user actions and replay it back any

number of times, comparing actual results to those expected.

Can test automation improve test effectiveness?

Yes, Automating a test makes the test process:

1. Fast

2. Reliable

3. Repeatable

4. Programmable

5. Reusable

Manual Vs automated Testing

Software Maintenance

“Taking care of the software”

A Few Questions

• “Have you tried to modify someone else‟s

program?”

• “Would you like someone else to modify your

program?”

• “How easy is it to update your program?”

• “Have you looked at a program that you

have completed a few months ago and tried

to make changes to it?”

Software Maintenance

• Process of changing a system after it has

been delivered and is in use

• Last phase in software engineering process

• Evolution of software - changing it to

maintain its ability to survive

• Goal of software engineering - to ease the

maintenance process & reduce costs

Maintenance Activities

• Corrective Maintenance - diagnosis and

correction of reported errors

• Adaptive Maintenance - modifications to properly

interface with changing environments new

hardware, OS, devices

• Perfective Maintenance - implementing new

system requirements after system is successful

Maintenance Effort Distribution

Corrective

Maintenance

17%

Adaptive

Maintenance

18%

Perfective

Maintenance

65%

Maintainability

• The ease with which software can be

understood, corrected, adapted and/or

enhanced

• Key goal that guides the SE process

• Important quality to be considered in all

activities including design, coding and testing

Classic Maintenance Problems

• Difficult or impossible to trace evolution of

software through many versions/releases

• Difficult or impossible to trace the process

through which software was created

• Difficult to understand “someone else‟s”

program

• “Someone else” is often not around to explain

Classic Maintenance Problems (Continued)

• Documentation doesn‟t exist or is awful

• Most software is not designed for change

• Maintenance has not been viewed as glamorous

work

Maintenance Cost Factors• Non-technical factors

– Application domain

– Staff stability

– Program age

– External environment

– Hardware stability

• Technical factors

– Module independence

– Programming

language

– Programming style

– Program Validation

– Documentation

– Configuration

Management

Structured vs Unstructured Maintenance

Configuration?

Evaluate design

Plan approach

Modify design

Recode

Evaluate design

Evaluate code

Maintenance request

?

ReviewReview

Test and release

Software Code

Structured Maintenance

• Software configuration exists

• Tasks include evaluation of design

documentation, assessment of change impact,

modify design, review, & coding

• Regression tests conducted before release

• Can be done due to earlier SE approach

• Amount of wasted effort reduced, overall quality

of change/correction is enhanced

Unstructured Maintenance

• Only source code available

• Tasks include evaluation of code, make

changes, review

• Impact of changes difficult to assess

• Regression testing cannot be done because no

records of previous testing

• Difficulties due to development without well-

defined methodology

Preventive Maintenance

• Software is changed to improve future

maintainability or reliability

• More common term in maintenance of

hardware and other physical systems

• Characterised by

– reverse engineering

– re-engineering

Software Reverse Engineering

• Originally a process in hardware - disassemble

a hardware product to understand the design

and specifications

• In software, it‟s the process of analysing a

program to create a representation at a higher

level of abstraction

• Usually from the source code or executable

code, create the design and specifications of a

software

Reverse Engineering Process

System to be

re-engineered

System

information

store

Traceability

materials

Data structured

diagrams

Program structured

diagramsAutomated

analysis

Manual

annotation

Document

generation

Software Re-engineering• Takes information of an existing system and

restructures the system to achieve higher

quality

• Usually takes the result of reverse

engineering as starting point

• Makes the system more maintainable -

improve the structure, create new

documentation, and easier to understand

Re-engineering Activities

• Source code translation

– Language upgrade, new platform, new language

• Program restructuring

– Structure corrupted in maintenance, improve

logic, program modularisation

• Data re-engineering

– Clean up data problems and inconsistencies,

database migration

Software Quality Assurance

“What is quality software and how to achieve it?”

What Is Quality Software?

• Is it software that works?

• Is it software that is error-free?

• Is it software that is very well-documented and

has help facility for all its functions?

• Is it software that does not „hang‟ the machine?

• Is it software that does not „bomb‟?

Group Project

• How do you ensure the quality of the

software you are developing?

• Have you defined the standards and tasks to

ensure the quality of the software?

• Will the customer say that your software is a

quality product?

• Are you fulfilling the customer‟s

expectations?

Software Quality Definition

Conformance to

• Explicitly stated functional and performance

requirements

• Explicitly documented development standards,

and

• Implicit characteristics that are expected of all

professionally developed software

(Pressman)

McCall‟s Software Quality Factors

Product

Revision

Product

Transition

Product Operations

McCall‟s Software Quality Factors

• Product Operations

– Operational characteristics

• Product Revision

– Ability to undergo changes

• Product Transition

– Adaptability to new environments

Product Operations Factors

• Correctness (Does it do what I want?)

• Reliability (Does it do it accurately all of the

time?)

• Efficiency (Will it run on my hardware as well

as it can?)

• Integrity (Is it secure?)

• Usablility (Is it designed for the user?)

Product Revision Factors

• Maintainability (Can I fix it?)

• Flexibility (Can I change it?)

• Testability (Can I test it?)

Product Transition Factors

• Portability (Will I be able to use it on another

machine?)

• Reusability (Will I be able to reuse some of

the software?)

• Interoperability (Will I be able to interface

with another system?)

Alternative Measurements

• Hewlett-Packard developed a set of quality

factors - FURPS

– Functionality - features, capabilities, overall

– Usability - human factors, consistency, doc.

– Reliability - failure, accuracy, MTBF, recovery

– Performance -speed,response time, efficiency

– Supportability - maintainability, testability

• Quality metrics for each step in SE process

Software Quality Assurance

• Quality assurance - essential activity for any

business that produces products to be used

by others

• SQA - a planned and systematic pattern of

actions to ensure quality in software

• “Quality is Job #1”

SQA Activities

• Application of Technical Methods

• Conduct of Formal Technical Reviews

• Software Testing

• Enforcement of Standards

• Control of Change

• Measurement

• Record keeping and Reporting

Application of Technical Methods

• Use of technical methods and tools

• Analyst achieve high quality specifications

• Designer develop high quality designs

• Ability to measure quality in specifications

and designs

Conduct of Formal Technical Reviews

• FTR is an activity to assess quality

• A stylised meeting conducted by technical

staff with the sole purpose of uncovering

quality problems

• Found to be effective in uncovering defects

in software

Software Testing

• To identify errors in software developed

• Test case design methods produces tests to

be used on the software

• Development of test strategy for a set of

tests that uncovers all possible errors

• Thorough testing is not as effective as

expected in most cases

Enforcement of Standards

• Formal standards and procedures varies

from company to company

• Could be dictated by customer, regulations,

or self-imposed

• If formal (written) standards exist, they must

be followed to ensure quality

• Assessment of compliance is done through

FTR or audit

Control of Change

• Every change has potential for introducing

errors or creating side effects that propagate

errors

• Change control process ensures quality

• Formalizing requests for change, evaluating

nature of change, and controlling the impact

of change

Measurement

• Integral part to any engineering discipline

• Software metrics must be collected to track

quality

• Also to assess the impact of methodological

and procedural changes on improved

software quality

Record keeping and Reporting

• Historical record for project - results of

reviews, audits, change control, testing,

other SQA activities

• Provide procedures for collection and

dissemination of SQA information

• Dissemination to development staff based on

need-to-know basis

Software Review

• like a “filter” for SE process

• must be applied at various points during

development

• all technical work need reviewing

• also checks one‟s mistakes

• helps to discover defects early

– design can introduce 50 - 65% of errors

– review can uncover 75% of them

– cost of subsequent steps reduced

ISO 9000

• Set of standards that can be applied to a range of

organisations from manufacturing through to

service industries

• ISO 9001 - general standards, applies to design,

development, maintaining products

• ISO 9000-3 - supporting document for software

development

• Various countries also have own standards

ISO Certification

• Some countries have bodies which certify

that the quality process in an organisation

conforms to ISO requirements

• In Malaysia, SIRIM performs this function

• Customer looks for certification in an

organisation to indicate the quality of

products or services

Areas covered by ISO 9001

• Management Responsibility– Control of non-conforming products

– Handling, storage, packaging and delivery

– Purchaser-supplied products

– Process control

– Inspection and test equipment

– Contract review

– Document control

– Internal quality audits

– Servicing

Areas covered by ISO 9001 (Continued)

• Quality System– Design control

– Purchasing

– Product identification and traceability

– Inspection and testing

– Inspection and test status

– Corrective action

– Quality records

– Training

– Statistical techniques

Quality Management SystemISO 9000

Quality Models

Organisational

Quality Manual

Project 1

Quality Plan

Project 2

Quality Plan

Project 3

Quality Plan

Organisational

Quality Process

Project Quality

Management

instantiated as

documents

is used to develop instantiated as

ISO & SQA

• An organisation that have SQA tasks in

place and a quality management process

would have most of ISO elements

• Ideally quality management should be

separate from project management

• This is to ensure quality considerations are

not compromised by concerns of budget and

schedule

Process Improvement

• Understanding existing processes and

changing these processes

– to improve product quality

– and/or to reduce costs and development time

• Assume that key factor to product quality is

the quality of development process

• kaizen - process of continuous process

improvement

Capability Maturity Model

• Developed by Software Engineering Institute

(SEI) of Carnegie-Mellon U

• SEI was established to improve the

capabilities of US software industry

• Focus on improving the process of software

engineering

• Similar to ISO, organisations are assessed

and certified to be on Level 1 to Level 5

Process Maturity Model

Level 2

Repeatable

Level 4

Managed

Level 3

Defined

Level 1

Initial

Level 5

Optimising

Level 1 Initial

• No effective management procedures or

project plans

• No organisational mechanisms to ensure

consistent use of formal procedures

• Successful software depends more on

individual skill rather than organisation

Level 2 Repeatable

• Formal management, quality assurance and

configuration control procedures

• Organisation can successfully repeat

projects of the same type

• Lack of formal process model

Level 3 Defined

• Organisation has defined its process and

has a basis for qualitative process

improvement

• Formal procedures are in place to ensure

that the defined process is followed in all

software projects

Level 4 Managed

• Organisation has a defined process and a

formal programme of quantitative data

collection

• Process and product metrics are collected

and fed into the process improvement

activity

Level 5 Optimizing

• Organisation is committed to continuous

process improvement

• Process improvement is budgeted and

planned and is an integral part of the

organisation‟s process

Key Process Areas

• Level 1 Initial

– none

• Level 2 Repeatable

– Software configuration management

– Software quality assurance

– Software subcontract management

– Software project tracking and oversight

– Software project planning

– Requirements management

Key Process Areas (Continued)

• Level 3 Defined

– Peer reviews

– Intergroup coordination

– Software product engineering

– Integrated software management

– Training programme

– Organisation process definition

– Organisation process focus

Key Process Areas (Continued)

• Level 4 Managed

– Software quality management

– Quantitative process management

• Level 5 Optimising

– Process change management

– Technology change management

– Defect prevention

Software Configuration Management

“The only constant is change ...”

What is S/w Configuration Management?

• SCM is the discipline for systematically

controlling the changes that take place during

development

• Umbrella activity that is applied throughout SE

process

• SCM is easier at the start of development and

gets more complex towards the end

Sources of Change

• New business or market conditions

• New customer needs

• Reorganisation and/or business downsizing

• Budgetary or scheduling constraints

Main Elements of SCM• Identification

– What are the configuration items?

• Control

– How changes should be controlled?

• Status Accounting

– What changes have been made?

• Auditing

– Is the system being built to satisfy the needs?

Software Configuration

• Computer programs

– Source code

– Executable code

• Documents that describe the computer

programs

– For technical staff

– For users

• Data

– Within the program and external to it

Software Configuration Item

• A document or an artifact that is explicitly placed

under configuration control and that can be

regarded as a basic unit for modification

• Examples:

– requirement documents

– design document

– code of a module

– test plan

Baselines Definition

IEEE definition:

“A specification or product that has been

formally reviewed and agreed upon, that

thereafter serves as the basis for further

development, and that can be changed only

through formal change control procedures”

Baselines

• A baseline is essentially a set of SCIs

• The items have been reviewed, corrected, and

approved

• Baselines should be used as reference point

• Baselines should only be changed through

formal procedures

• Careful definition and control of different

baselines should be done

Examples of Baselines

• Functional baseline (requirements)

• Design baseline

• Product baseline (developed system)

Configuration Control

• Version control - procedures and tools to

manage different versions of configuration

objects

• Change control - procedures and tools to

provide a mechanism for the control of

changes

Version Control

• Process of identifying and keeping track of

different versions and releases of a system

• Procedures to ensure that different versions of a

system may be retrieved when required and not

accidentally changed

• Version management is almost always supported

by automated tools

Evolution Graph

Obj

1.0

Obj

1.1.1

Obj

1.1.2

Obj

1.1

Obj

1.2

Obj

2.0

Obj

1.3

Obj

1.4

Obj

2.1

Versions, releases & variants

• Version - an instance of a system that differs

from other instances

– different functionality

– performance

– repair of system faults

• Release - version that is distributed to

customers

• Variant - sometimes used when differences are

small

Change Control

• Focuses on managing changes to the

different forms of the SCIs

• Engineering change proposal - basic

document used for defining & requesting for

a change.

• Configuration Control Board (CCB) is

responsible for configuration management

• CCB evaluate proposal & approve/reject it

Change Control ProcessNeed

for

change

Other

SCM

tasks

Change

request

generated

Change

report

generated

Place on

queue

for change

ECO

generated

Requestor

is informed

Evaluation

CCA

decision

Reject

Approve

Technical merits, Side effects

Overall impact, Project cost

Engineering Change Proposal

• proposed change

• reason(s)

• baselines & SCIs that are affected

• cost

• schedule impacts

• procedures for the change

Engineering Change Order

• Change description

• Constraints

• Audit review criteria

Change Process

• Object to be changed is “checked out”

• Change is made

• Appropriate SQA activities applied

• Object is “checked in” to the database

• Version control mechanisms applied for next

version

Change Process Diagram

Software

Engineer Project

Database

Check-out

Check-in

Access

control

Configuration object

(baseline version)

Configuration object

(baseline version)

Ownership

info

lock

unlock

Configuration object

(extracted version)

Configuration object

(modified version)

Audit info

Status Accounting/Reporting

• Keeps record of how the system evolves and

what is its current status (administrative

nature)

• Can be complex due to the existence of

executable and non-executable forms

Status Reporting Process

Configuration

Identification

Configuration

Audit

Configuration

Control

Status

Reporting

CSR

Report

CSR

Database

SCIs

Changes

Deficiencies

Status Accounting Tasks

• Record baseline establishment time

• Record when SCI came into being

• Information about each SCI

• Engineering change proposal status

• Status of the approved changes

Configuration Audit

• Concerned with determining how accurately

the current software system implements the

system defined in the baseline &

requirements document

• Also concerned with increasing the visibility

and traceability of the software

• Also establish a new baseline

Auditing

• How do we know a change is properly

implemented?

– Formal technical reviews - assess the SCI to

determine consistency with other SCIs

– Software configuration audit

• SCI changes made?

• FTR conducted?

• SE standards followed?

• SCM procedures followed & updates properly done?

• Related SCIs updated?

Any Question

If you have any query please feel free to ask

Phone: +92-51-9047-574

Fax: +92-51-9047-420

Email: fahad@uettaxila.edu.pk

University Of Engineering & Technology Taxila Pakistan