engr . m. fahad khan lecturer software engineering...
TRANSCRIPT
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: [email protected]
University Of Engineering & Technology Taxila Pakistan