Sei sulla pagina 1di 120

UNIT – 1

Unit I Syllabus
• Software Engineering paradigms –
Waterfall Life cycle model – Spiral Model
– Prototype Model – Fourth Generation
Techniques – Planning – Software
Project Scheduling, – Risk analysis and
management – Requirements and
Specification – Case Study for Project
Plan and SRS.
Session - 1
- To understand the subtle introductory
concepts in software engineering
What is Software ?
- That which encompasses
a) Instructions
b) Data Structures &
c) Documentation
Features of Software ?
- Not manufactured but developed and
- Does’nt wear-out but deteriorates over time
- Most of the software are custom-built

Figure 1 - Wear-out Vs Deterioration

Enter Software Engineering
Seminal definition of SE
- The establishment and use of sound
engineering principles in order to obtain
economically software that is reliable and
works efficiently on real machines.
IEEE CS definition
- (1)The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; (2)
The study of approaches as in (1).
• Software engineering covers not only
the technical aspects of building
software systems, but also
management issues, such as directing
programming teams, scheduling, and
• Software engineering is a discipline
whose aim is the production of fault-
free software, that is delivered on
time, within budget, and satisfies the
user’s needs.



process model

a “quality” focus

Figure 2 – A Layered Technology


- Engineering approach to software

(Construction example)
- Systematic collection of past experience
a) Techniques
b) Methodologies &
c) Guidelines
The height of Software Engineering


Esoteric Past
Experience Craft
Systematic Use of Past
Experience and Scientific Basis
Unorganized Use of
Past Experience
Why Software Engineering ?
[1] Acquiring skills to build large
programs and systems
a) Growth in size, complexity and
difficulty level of an exponential
b) When the size of software increases,
the ad-hoc approach breaks down
Why Software Engineering ?
[2] Able to solve complex problems
a) Breaking problems into smaller and
manageable parts
b) Practicing techniques like
specification, design, interface
development, testing, project
management etc.
Why Software Engineering ?

[3] Acquiring skills to become a

better programmer
a) Higher productivity
b) Using quality procedures,
techniques and programs
Why Software Engineering ?
Challenges in SE today ?
a) Effort Intensive activity
b) High Cost
c) Long development time
d) Changing needs of users
e) High risk of failure, user acceptance,
performance, quality parameters
Why Software Engineering ?
Reasons for software failure
1) Schedule Slippages
2) Cost overruns
3) Does not solve user’s problem
4) Poor quality of software
5) Poor maintainability
Why Software Engineering ?
What leads to failures as identified
a) Ad-hoc approaches
b) No proper planning
c) Deliverables not taken care of
d) Poor understanding of user’s
e) No control or review
f) Poor understanding of cost and effort by
both developer and user
Session - 2
- To understand what a software process
framework does, and the generic phases
in software development
- To know the use of a process model, the
different process models that can be
used while developing effective quality
A Software Process

A series of steps involving activities,

constraints, and resources that
produce an intended output of some
A Software Process

Process is Set of activities

Activities of a Software Process

a) Process Framework
b) Framework activities
c) Umbrella activities
The Software Process
Common process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

Note : Refer Fig 2.2 on Page 55 in Pressman 6th edition

A Software Process
Framework Activities
1) Work tasks
2) Work Products
3) Quality Assurance points
4) Project Milestones
A Software Process
Generic Framework Activities
1) Communication
2) Planning
3) Modeling
4) Construction &
5) Deployment
A Software Process
Umbrella activities
1) Software Project Management
2) Formal Technical Reviews
3) Software Quality Assurance
4) Software Configuration Management
5) Document Preparation and Production
6) Reusability Management
7) Measurement &
8) Risk Management
The Systematic Process


Design Models


Generic Phases
1) Definition Phase
- Focusing on “what” the software is
2) Development Phase
- Focusing on “how” the software
3) Maintenance Phase
- Focusing on “changes” to the software
Process Models
• Waterfall model
• Software automation
• V-Model
• Rapid Application Development Model RAD
• Spiral Model
• WIN – WIN Spiral Model
• Iteration model
• Incremental model
• Component-based software engineering
• Prototyping
• Rapid prototyping
• Fourth Generation Techniques
• Concurrent Development Model
• Formal Methods Model
• Combining paradigms
Process Models
Waterfall Model – Classic Life Cycle
Waterfall Model - Highlights
• Oldest and most widely used paradigm
• Activities ‘flow’ from one phase to
• If there are corrections, return to a
previous phase and ‘flow’ from there
Waterfall Model - Advantages
• Good for planning and well-defined /repeated
Pitfalls :
• Real-time projects often do not follow the
• All requirements may not be stated explicitly
by customer
• Customer only sees the results after some
• Developers are often delayed at certain phases
Spiral Model
Spiral Model - Highlights
• Originally proposed by Boehm, couples
iterative nature of prototyping and the
systematic aspects of the waterfall
• Software is developed in series of
incremental releases
• Each iteration produces a more complete
• Better management through risk
Spiral Model – Pitfalls
• May be difficult to convince customers
that evolution is controllable
• Demands risk assessment expertise -
major risk will cause problems if not
• Relatively new and not widely used -
cannot determine performance
Note: An alternate spiral model is the
“Win-Win Spiral Model”
Prototyping Model
What is software/system prototyping ?
- Rapid software development to validate
- In the past, the developed system was
normally thought of as inferior in some
way to the required system so further
development was required
- Now, the boundary between prototyping
and normal system development is
blurred and many systems are developed
using an evolutionary approach
Prototyping Model
Uses of System Prototypes
• The principal use is to help customers and
developers understand the requirements for
the system
– Requirements elicitation. Users can experiment
with a prototype to see how the system supports
their work
– Requirements validation. The prototype can
reveal errors and omissions in the requirements
• Prototyping can be considered as a risk
reduction activity which reduces requirements
Prototyping Model
Benefits of Prototyping
• Misunderstandings between software
users and developers are exposed
• Missing services may be detected and
confusing services may be identified
• A working system is available early in
the process
• The prototype may serve as a basis for
deriving a system specification
• The system can support user training
and system testing
Prototyping Model
The Prototyping Process

Establish Define
Develop Evaluate
prototype prototype
prototype prototype
objectives functionality

Prototyping Outline Executable Evaluation

plan definition prototype report
Prototyping Model

Prototyping benefits in a nutshell

• Improved system usability
• Closer match to the system needed
• Improved design quality
• Improved maintainability
• Reduced overall development effort
Prototyping Model

Requirements Quick Building

gathering and
refinement design prototype

Engineer Refining Customer

product prototype evaluation

Prototyping Model - Highlights
• Developer and customer determine
objectives and draft requirements
• Prototype quickly produced and
evaluated by customer
• Prototype then refined, and re-evaluated
• Process iterated, before final product
Advantages: Customer participation and
better requirements
Prototyping Model - Pitfalls

• Problem 1: Customer may see

prototype as working model and expects
fast results
• Problem 2: Developer compromised
when producing prototype quickly, e.g.
different operating system or
programming language
Fourth Generation Techniques
• Use of software tools that allow
software engineer to specify s/w
characteristics at higher level
• The tools generate codes based on the
specification given
• More time in design and testing -
increase productivity
• Tools may not be easy to use, codes
generated may not be efficient
Fourth Generation Techniques



using 4GL

Fourth Generation Techniques
Features of 4GL Tools
• Non-procedural languages for Database query

• Report generation

• Data manipulation

• Screen interaction and definition

• Code generation

• Graphics/spreadsheets and High-level graphics

Fourth Generation Techniques
• Dramatic reduction in software
development time.
• Improved productivity for software
• Not much easier to use as compared
to programming languages
Fourth Generation Techniques
- A fourth-generation programming
language(1970s-1990) (abbreviated
4GL) is a programming language or
programming environment designed
with a specific purpose in mind, such
as the development of commercial
business software
Fourth Generation Techniques

Types of 4GLs
a) Report Generators
b) Forms Generators
c) Ambitious 4GLs (Fourth Generation
Fourth Generation Techniques
Successful 4GLs
a) Forte TOOL
b) PowerBuilder
c) DataFlex…

Database Query Languages

b) Informix-4GL
c) Progress-4GL…
Fourth Generation Techniques
Report Generators
a) BuildProfessional
b) Oracle Reports
c) PostScript etc…

GUI Creators
b) Omni’s Studio
c) OpenROAD…
Session - 3
- To highlight the importance of planning
in the software systems life cycle
- To know the different types of software
planning and its overall benefits
1) Vital Inputs
• This is the most important ingredient in
software development
• Proper planning procedures to track the
progress of the project
• Role of a Project/Technical Manager
• Drafting an initial plan
• Revising a plan as the project
2) The Project Plan
- Looking for resources required for the
- Outlining the WBS (Work Breakdown
Structure) and the schedule
Items that need to be included in a Project
a) Introduction
b) Project Organisation
c) Risk Analysis
d) Hardware and Software requirements
e) Work Breakdown
f) Project Schedule
g) Monitoring and reporting mechanisms
Regular revision of the project plan to be
done as the project progresses
Plan Description
Quality plan Describes the quality procedures and standards that will be
used in a project. See Chapter 27.
Validation plan Describes the approach, resources and schedule used for
system validation. See Chapter 22.
Configuration Describes the configuration management procedures and
management plan structures to be used. See Chapter 29.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required. See Chapter 21.
Staffdevelopment plan. Describes how the skills and experience of the project team
members will be developed. See Chapter 25.

Table – Types of Plan

3) Milestones and deliverables
- Need for data and documents for
project mangers to update and revise
- Developing milestone reports at the
end of every process activity
- Deliverables are the artifacts that
are given to the customer
- Deliverables are always the
milestones. The vice-versa is not true.
Questions on topics covered till
Session 4 - Project Scheduling
- To understand how project schedules
need to be drafted
- To know the different ways by which
project tasks can be tracked
Project Scheduling
Vital Reasons for delivering a
software late
1) Unrealistic deadlines
2) Changing customer requirements
3) Honest underestimates of the amount
of effort and total resources required to
complete the project
4) Predictable and Unpredictable risks not
taken into account
5) Not able to foresee technical difficulties
Project Scheduling
6) Not also able to foresee human
7) Miscommunication among project staff
8) Failure by the project management
team to rescue a project going behind
Project Scheduling
How to handle unrealistic deadlines
- Perform a detailed estimate using
historical data from past projects
- Delivering the critical functionality at the
earliest and other functionality later
- Convince the client that the imposed
deadline is unrealistic
- Use an incremental approach that gives
the following suggestions
Project Scheduling
a) Increasing the budget and bringing on
additional resources
b) Removing certain other low-level
c) Convince the client about post-project
delivery disaster
Project Scheduling
Objectives of the Project Manager
1) Defining all the project tasks
2) Building an activity network and identifying
the interdependencies
3) Identifying critical tasks within the activity
4) Generating a timeline that shows the actual
and planned progress of each task
5) Track the task’s progress one day at a time
6) The schedule should allow the project to be
controlled and the progress to be monitored
Project Scheduling
Basic Principles of Project Scheduling
a) Compartmentalization
b) Interdependency
c) Time allocation
d) Effort validation
e) Defined Responsibilities
f) Defined Outcomes &
g) Defined Milestones
Project Scheduling
Table – Example of a Project Schedule
Table – Example of a task in a
project schedule
Project Scheduling

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity charts

requirements and bar charts
Project Scheduling
Important items used in a Scheduling
a) Tables – holds the task summary
b) Bar Charts – Schedule Vs Time
c) Activity Charts – Graphical items that
show the task dependencies and critical
path(longest path in the activity graph)
Project Scheduling
Example of a Table
Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Project Scheduling
Activity Chart - Example
1 4 /7 /0 3 15 da y s
15 da y s
M1 T3
8 day s T9
T1 5 day s 4 /8/ 03 2 5 /8/ 03
2 5 /7 /0 3
4 /7 /0 3 T6 M4 M6
st art 2 0 day s 7 day s
15 day s
T7 T 11
25 /7 /0 3 11 /8/ 03 5 /9/ 03
10 da y s 10 day s
M2 M7 M8
T4 T5 15 da y s

T 10 10 da ys
1 8 /7 /0 3
T 12
2 5 day s
T8 Fini sh
19 /9/ 03
Project Scheduling
4 /7 11 /7 1 8/7 2 5/7 1 /8 8 /8 1 5/8 2 2/8 2 9/8 5 /9 1 2/9 1 9/9
St art
T 11
Fini sh
Project Scheduling
Staff Allocation Chart
Project Scheduling
Gantt Charts
Session 5 - Risk Management
- Risk identification
- Risk projection (estimation)
- Risk mitigation, monitoring, and
Risk Management
• A risk is a potential problem – it might happen
or not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions,
places, etc.
• Two characteristics of risk
– Uncertainty – the risk may or may not happen,
that is, there are no 100% risks (those, instead, are
called constraints)
– Loss – the risk becomes a reality and unwanted
consequences or losses occur
Risk Management
Categorization of Risks – One way to do it
1) Project risks
– Threaten the project plan
– If they become real, it is likely that the project
schedule will slip and that costs will increase
2) Technical risks
– They threaten the quality and timeliness of the
software to be produced
– If they become real, implementation may become
difficult or impossible
3) Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or
the product
Risk Management
Sub-categories of Business risks
1) Market risk – building an excellent product or
system that no one really wants
2) Strategic risk – building a product that no longer
fits into the overall business strategy for the
3) Sales risk – building a product that the sales
force doesn't understand how to sell
4) Management risk – losing the support of senior
management due to a change in focus or a
change in people
5) Budget risk – losing budgetary or personnel
Risk Management




Fig : Risk Management Tasks
Risk Management
Two Risk Strategies – Proactive and
a) Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the
problem rapidly (fire fighting)
– Crisis management is the choice of management techniques
b) Proactive risk strategies
– Steps for risk management are followed
– Primary objective is to avoid risk and to have a contingency
plan in place to handle unavoidable risks in a controlled and
effective manner
Risk Management
Steps to follow in Risk Management
1) Identify possible risks; recognize what can
go wrong
2) Analyze each risk to estimate the probability
that it will occur and the impact
(i.e., damage) that it will do if it
does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal,
critical, and catastrophic
4) Develop a contingency plan to manage
those risks having high probability
and high impact
Risk Management
Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks
in specific subcategories
• Can be organized in several ways
– A list of characteristics relevant to each risk
– Questionnaire that leads to an estimate on
the impact of each risk
– A list containing a set of risk component and
drivers and their probability of occurrence
Risk Management
Questionnaire on Project Risk
1) Have top software and customer managers
formally committed to support the project?
2) Are end-users enthusiastically committed to
the project and the system/product to be
3) Are requirements fully understood by the
software engineering team and its
4) Have customers been involved fully in the
definition of requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
Risk Management
• The impact of each risk driver on the risk
component is divided into one of four
impact levels
– Negligible, marginal, critical, and
• Risk drivers can be assessed as
impossible, improbable, probable, and
Risk Management
Contents of a Risk Table
• A table that provides a project manager with a
simple technique for risk projection
• It consists of five columns
– Risk Summary(short description of the risk)
– Risk Category(one of seven risk categories)
– Probability – estimation of risk occurrence based on
group input
– Impact – (1) catastrophic (2) critical (3) marginal
(4) negligible
– RMMM – Pointer to a paragraph in the Risk
Mitigation, Monitoring, and Management Plan
Risk Management

Table : Contents of a Risk Table

Risk Management
Assessing the Risk Impact
- This can be assessed by Risk Exposure given
as follows
RE = P * C where
P – The probability of occurrence of a risk
C – The cost to the project if the risk occurs
A software application has got 60 components.
The project manager finds that there is a 90%
probability of the components i.e. 20 out of the
60 components will have to be re-developed
again. The total cost of developing one
component on an average is Rs 2000. Find RE ?
Risk Management
P = 90% probability that 20 out of 60
software components will have to be
C = Total cost of developing 20 components is
Rs. 40,000
RE = .90 x 40,000 = 36,000
Risk Management
RMMM(Risk Mitigation, Monitoring and
Management) Plan
• An effective strategy for dealing with risk.
Three issues need to be considered.
- Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary
strategy and is achieved through a plan
– Example: Risk of high staff turnover
Risk Management
The RMMM Plan
- A part of the software development plan
or can be a separate document
- Once RMMM becomes documented and
the project has begun, the risk
mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance
– Risk monitoring is a project tracking activity
Risk Management
• Risk monitoring has three objectives
– To assess whether predicted risks do, in
fact, occur
– To ensure that risk aversion steps defined
for the risk are being properly applied
– To collect information that can be used for
future risk analysis
• The findings from risk monitoring may
allow the project manager to ascertain
what risks caused which problems
throughout the project
Risk Management
Examples of top risks
• Shortage of technically trained manpower
• Too many requirement changes
• Unclear requirements
• Not meeting performance requirements
• Unrealistic schedules
• Insufficient business knowledge
• Working on new technology
Risk Management
Seven Principles of Risk Management
• Maintain a global perspective
– View software risks within the context of a system
and the business problem that is is intended to
• Take a forward-looking view
– Think about risks that may arise in the future;
establish contingency plans
• Encourage open communication
– Encourage all stakeholders and users to point out
risks at any time
• Integrate risk management
– Integrate the consideration of risk into the software
Risk Management
• Emphasize a continuous process of risk
– Modify identified risks as more becomes known and
add new risks as better insight is achieved
• Develop a shared product vision
– A shared vision by all stakeholders facilitates better
risk identification and assessment
• Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders
when conducting risk management activities
Session 6 – Requirements and
- To understand the need for an
SRS(Software Requirements
Specification) and the structure of a
requirements document
- To know how the process of
requirements gathering should be done
for a software application, the
characteristics, components etc…
Requirements and Specification
IEEE definition of requirement
“A condition of capability needed by a user
to solve a problem or achieve an
IEE definition of requirement(IEE87)
“A condition or capability that must be
met or possessed by a system … to
satisfy a contract, standard, specification,
or other formally imposed document …”
Requirements and Specification
Problems in developing the SRS
a) Changing requirements with time
b) Not able to document the complete
needs of the project
c) Incorrect interpretation or specification
of the requirements
d) Creating an effective and stable SRS is
Requirements and Specification
Need for SRS
- Communication gap between the client
and the developer. The SRS should
bridge this gap
- Helping clients understanding their own
- Establishes the basis for agreement
between the client and the supplier on
what the software product will do
- A high-quality SRS reduces the
development cost
Requirements and Specification
- Provides a reference for validation of the
final product
- The three desirable attributes for any
project i.e. cost, schedule and quality
can be formally estimated using the SRS
- Boehm’s investigation (Out of 54%
errors found during later stages of the
SDLC, 45% errors originated in the
requirements phase
- A high-quality SRS is a pre-requisite to
high quality software
Requirements and Specification
Phase Cost (person-
Requirements 2
Design 5
Coding 15
Acceptance Test 50
Operation and 150
Table : Cost of fixing requirement errors
Requirements and Specification
Requirement Process
User needs

Figure : The requirement
Specification process


Validated SRS
Requirements and Specification
Concepts which can be used to
perform the RA in an effective manner
a) Divide and Conquer
b) Organizing large volumes of information
c) Using diagrams like data flow diagrams,
object diagrams etc…
Problem Analysis
- To gain an understanding of the needs,
requirements, and constraints on the
Requirements and Specification
Analysis involves the following
a) Interviewing clients and users
b) Reading manuals
c) Studying current systems
d) Helping client/users understand new
e) Like becoming a consultant
f) Must understand the working of the organization ,
client, and users
Requirements and Specification
i) Basic principle: problem partition
j) Partition w.r.t what?
Object - OO analysis
Function - structural analysis
Events in the system – event partitioning

DFM (Data Flow Modeling)

- Focuses on functions performed in the
- Uses dataflow diagrams and functional
decomposition in modeling
Requirements and Specification
• The Structured System Analysis and
Design (SSAD) methodology uses DFD to
organize information, and guide analysis
• A DFD shows flow of data through the system
– Views system as transforming inputs to
– Transformation done through transforms
– DFD captures how transformation occurs
from input to output as data moves through
the transforms
– Not limited to software
Requirements and Specification
The DFD has four symbols:
1.Squares representing external entities,
which are sources or destinations of data.
2.Rounded rectangles
representing processes, which take data as
input, do something to it, and output it.
3.Arrows representing the data flows, which
can either be electronic data or physical
4.Open-ended rectangles
representing data stores, including
electronic stores such as databases or XML
files and physical stores such as or filing
cabinets or stacks of paper.
Requirements and Specification
DFD Example
Requirements and Specification
Characteristics of SRS
• Correct
• Complete
• Unambiguous
• Consistent
• Verifiable
• Traceable
• Modifiable
• Ranked for importance and/or stability
Requirements and Specification
• Correctness
– Each requirement accurately represents some
desired feature in the final system
• Completeness
– All desired features/characteristics specified
– Hardest to satisfy
– Completeness and correctness strongly related
• Unambiguous
– Each requirement has exactly one meaning
– Without this errors will creep in
– Important as natural languages often used
• Verifiability
– There must exist a cost effective way of checking if the
s/w satisfies requirements
Requirements and Specification
• Consistent
– two requirements don’t contradict each other
• Traceable
– The origin of the req, and how the req relates to
software elements can be determined
• Ranked for importance/stability
– Needed for prioritizing in construction
– To reduce risks due to changing requirements
Requirements and Specification
Components of an SRS
• An SRS must specify requirements on
– Functionality
– Performance
– Design constraints
– External interfaces
Requirements and Specification
Functional Requirements
• Heart of the SRS document; this forms the
bulk of the specs
• Specifies all the functionality that the
system should support
• Outputs for the given inputs and the
relationship between them
• All operations the system is to do
• Must specify behavior for invalid inputs too
Requirements and Specification
Performance Requirements
• All the performance constraints on the
software system

• Generally on response time , throughput etc

=> dynamic

• Capacity requirements => static

• Must be in measurable terms (verifiability)

– Eg resp time should be xx 90% of the time
Requirements and Specification
Design Constraints
• Factors in the client environment that
restrict the choices
• Some such restrictions
– Standard compliance and compatibility with
other systems
– Hardware Limitations
– Reliability, fault tolerance, backup req.
– Security
Requirements and Specification
External Interface
• All interactions of the software with
people, hardware, and software
• User interface most important
• General requirements of “friendliness”
should be avoided
• These should also be verifiable
Requirements and Specification
Structure of an SRS standardized by IEEE
• Introduction
– Purpose , the basic objective of the system
– Scope of what the system is to do , not to do
– Overview
• Overall description
– Product perspective
– Product functions
– User characteristics
– Assumptions
– Constraints
Requirements and Specification
 Specific requirements
 External interfaces
 Functional requirements
 Performance requirements
 Design constraints
 Acceptable criteria
 desirable to specify this up front.
• Having a good quality SRS would help in
understanding all the required components
for software development
• The requirement phase has 3 major sub
– analysis , specification and validation
• Analysis
– for problem understanding and modeling
– Methods used: SSAD, OOA , Prototyping
• Key properties of an SRS: correctness,
completeness, consistency, traceability,
• Specification
– must contain functionality, performance
,interfaces and design constraints
– Mostly natural languages used
• Validation - through reviews
Case Study – Project Plan
Example : Waste Management Inspection
Tracking System

Refer to pdf document and explain ?

Case Study – SRS
Example : Waste Management
Inspection Tracking System

Refer to pdf document and explain ?