Project Report on Policy File Track and Trace System.pdf

Track and Trace System
[T&TS]
Zafar Ahmad
Roll # L – 519679
MBA – IT Program
Ms. Shamoona Shahid
Course Leader
MIMS, Multan
Department of Computer Science
Allama Iqbal Open University
H – 8, Islamabad
Year 2004
Developed By:
Supervised By:

i
I hereby declare that this software, neither as a whole nor as a part thereof has been copied
out from any source. It is further declared that I developed this software and this report
entirely on the basis of my personal efforts made under the sincere guidance of my project
supervisor.
If any part of this software proved to be copied or found to be a report of some other, I
shall standby the consequences.
No portion of the work presented in this report has been submitted in support of any
application for any other degree or qualification of this or any other University or institute
of learning.
I further declare that this software and all associated documents, reports, and records are
submitted as partial requirement for the degree of MBA – IT.
I understand and transfer copyrights for these materials to Allama Iqbal Open University,
Islamabad.
I shall not sale this software and documents and shall not get any financial gains from
these.
Student Name: Zafar Ahmad Signature: ________________
Project Supervisor: Ms. Shamoona Shahid Signature: ________________
Declaration

ii
This is to certify that we have read the project report submitted by Mr. Zafar Ahmad, Roll
# L – 519679, under MBA – IT program, and in our judgment that this report is of
sufficient standard to warrant its acceptance by Allama Iqbal Open University, Islamabad,
for MBA – IT degree.
Examination Committee
1. Internal Supervisor Name: _____________________
Designation Signature: _____________________
Study Center
2. Internal Examiner Name: ______________________
Designation Signature: ______________________
Study Center
3. External Examiner Name: ______________________
Designation Signature: ______________________
Study Center
Final Approval

iii
First of all, I am very grateful to Almighty Allah Who provided me strength and made
capable of doing this project to meet with the realistic interpretation of the matter.
Obviously, I have nothing to do except His blessings.
I certainly believe that skills and hidden abilities remain useless if no one is there to help
to bring these attributes at forefront and polish them in a fruitful manner. No doubt, the
teacher does it well. So my utmost thanks and gratitude to my beloved and Hon’ble
teachers in the entire program; and especially, in this project, Ms.Shamoona Shahid,
Internal Supervisor, whose selfless efforts and guidance make me so capable to complete
the task as it was dreamed.
With the blessings of beloved parents; we remain successful in the entire length of career
and life. I have no words to thank to my beloved parents whose advice and guidance, love
and affection, and experience made me capable to distinguish between wrong and the right
path in my career development phases. Specially, I salute to the dignity of my mother due
to which I have been successful so far and also would love to seek her guidance at step-by-
step during the remaining course of life. May Allah bless my parents a long life and keep
me joining their association to eternal!
Motivation and moral support plays a very vital role to do things consistently. I would also
like to thank to my class fellows who always encouraged my to come out of the
difficulties, as and when encountered during the work; and extended their cooperation in
consultation with respect to the project.
From the core of my heart, my sincere thanks are due to Mr. Abdul Salam, Assistant
General Manager, PHS Department, State Life, Regional Office, Multan, whose
facilitation made the environment feasible for me to learn and concentrate on studies with
good time management during the entire length of program. It is because of him, I got the
concept of this project “Track and Trace System” and opportunity to go through whole of
the manual procedures. This helped me a lot in understanding the procedural mechanism
to put this task to the computer. I really admire and salute to him.
In the last, but not the least, it would be unfair, if I leave this acknowledgement without
the name of Mr. Muhammad Ashraf Bhatti, Assistant General Manager, Personnel &
General Services Department, Multan Zone. He is the person who kept the environment
feasible for me to remain on the track with consistent pace to end of the project. I
thankfully acknowledge him for providing such support.
May Allah be kind to all of us!
Zafar Ahmad
Acknowledgement

iv
Project Title Track & Trace System
Organization State Life Insurance Corporation of Pakistan,
Regional Office, Multan
Objectives - To respond the queries on file position instantly in
order to keep the policyholder satisfied
- To judge the efficiency of Decision Committee
- To manage investigation cases, duplicate file
creation cases, Wafaqi Mohtasib Complaints,
Claims Cases, Underwriting Cases and Msic.
Complaint cases properly
- To avoid the management pressure for doing
work in a haste
- To minimize the chances of lost in transit of
file(s) in PHS – Department, Regional Office,
Multan
- To provide a reasonable/satisfied answer to the
local management as well as higher authorities
on the queries asked for relating to decision/file
movement status.
- To perform the activities in an arranged, planned
and systematic way.
- To get the work done effectively and efficiently
on the activities to be performed, as focused in
the scope of the project, at PHS – Regional
Office, Multan.
Developed By Zafar Ahmad
Roll # L – 519679
MBA – IT Program
Supervised By Ms. Shamoona Shahid
Course Leader
MIMS - Multan
Tools Used Visual Basic 6.0 (Enterprise Edition)
Microsoft Access XP
Operating System Windows XP (Professional)
System Used System 2.0 GHz P-IV
Monitor 17” G74 IBM
Project in Brief

v
The software named as “Track and Trace System” is developed to solve the problem faced
at Sate Life Insurance Corporation of Pakistan, PHS – Department, Regional Office,
Multan.
The main function of the department is to pass decision on different claim and life
proposed cases for fresh business passed to this office from the respective Zonal Office
within the jurisdiction of Multan Region. In addition to this job, Misc. Complaints, Claims
Investigation and Duplicate File Creation matters also taken into account here. As there
are number of files remain in transit. Hence to address prompt queries and timely disposal
requires tracking and tracing with the minimum time span. So this project is designed to
address these issues in an organized way. At Regional Level, decision making process is
the key activity on the part of the Departmental Head(s), Focusing on PHS – Department,
in order to facilitate the Regional Underwriting Committee (RUC) and Regional Claims
Committee (RCC); there was a need to make the incoming stuff from different Zones so
arranged that decision process be completed in minimum period of time.
In addition to above, during the course of the process, queries, from Regional Chief,
Principal Office and the concerned Zone, are required to be entertained promptly and to
satisfy with the answer on the justified status over the case. The higher authorities, at
Principal Office ask step-by-step progress and fate on the proposal cases and RCC
decision on claims cases and expect the immediate response.
The study begins with the recognition of problem and later on objectives and scope is
drawn to move forward on the right track. Having profound analysis of the existing
system through its manual procedures; a new system is proposed which satisfies the basic
requirements with some additional features to address the over all functioning of the
department.
This software is used to facilitate the management with the handful information to judge
efficiency over decision making process and fulfills the objectives as dreamed in
developing of the system.
Abstract

1. Introduction of the Organization...........................................................................................................1
1.1 Nature of the Organization ..........................................................................................................1
1.1.2 Vision ........................................................................................................................................2
1.1.3 Mission Statement ..................................................................................................................2
1.1.4 Organizational Objectives .......................................................................................................2
1.1.5 Quality Policy...........................................................................................................................2
1.2 Organizational Hierarchy .............................................................................................................2
1.2.1 Organizational Setup Hierarchy..............................................................................................3
1.2.2 Region-wise/Zone-wise Hierarchy..........................................................................................3
1.2.3 Division/Department-wise Hierarchy.....................................................................................4
1.2.4 Controlling Hierarchy...............................................................................................................5
1.2.5 Organizational Hierarchy on Project Target Area..................................................................5
1.3 Problem Definition .......................................................................................................................8
1.4 Scope of the Project.....................................................................................................................9
1.5 Broad Based Objectives.............................................................................................................11
1.6 Specific Objectives .....................................................................................................................11
1.7 Feasibility Report........................................................................................................................11
1.7.1 Hardware & Software............................................................................................................11
1.7.2 User Expertise ........................................................................................................................12
1.7.3 Cost Analysis..........................................................................................................................12
2. Detail Study of the Existing System....................................................................................................13
2.1. Underwriting Cases ....................................................................................................................13
2.1.1 Drawbacks in Underwriting Cases Management System ..................................................16
2.2 Duplicate File Creation Matters.................................................................................................16
2.2.1 Drawbacks in Duplicate File Creation Matter......................................................................20
2.3. Death Claims Investigation Cases.............................................................................................20
2.3.1 Drawbacks in Investigation Cases........................................................................................23
2.4 Claims Cases ...................................................................................................................................24
2.4.3 Drawbacks in Claims Cases Management System ............................................................27
2.5 Miscellaneous Complaint Cases ....................................................................................................28
2.5.1 Drawbacks in handling of Misc. Complaint Cases .............................................................30
3. Proposed System.................................................................................................................................32
3.1 Objectives....................................................................................................................................32
3.2 Proposed System........................................................................................................................33
3.2.1 Requirement Specifications of the Proposed System........................................................33
3.2.2 Activities to be performed by the Proposed System...........................................................33
3.2.3 Cost Benefit Analysis of Proposed System..........................................................................34
3.2.4 Data Flow Diagram (DFD) .....................................................................................................35
3.2.5 Prototyping Requirements....................................................................................................35
3.4 Benefits/Main Features of the Proposed System....................................................................36
4. System Design .....................................................................................................................................37
4.1 Input Design................................................................................................................................37
4.1.1 Input Design Process.............................................................................................................38
4.1.2 General Principles of Input Design.......................................................................................38
Table of Contents

4.2 Output Design .............................................................................................................................40
4.2.1 General Principles of Output Design ....................................................................................40
4.2.1 Guidelines for Output Design................................................................................................41
4.3 Database Design ........................................................................................................................41
4.4 Database Design ........................................................................................................................43
5. System Implementation......................................................................................................................70
5.1 Programming Tool......................................................................................................................70
5.1.1 Why Visual Basic....................................................................................................................70
5.1.2 Advantages of Visual Basic...................................................................................................70
5.1.3 Prominent Features of Visual Basic .....................................................................................71
5.2 Database Selection ....................................................................................................................72
5.2.1 Features/Benefits of MS-Access ..........................................................................................72
5.3 Hardware Used ...........................................................................................................................74
6. System Testing & Evaluation ..............................................................................................................75
6.1 Principles of Testing...................................................................................................................75
6.2 Software Testing Methods .........................................................................................................76
6.2.1 Test Case Design ...................................................................................................................76
6.2.2 White-Box Testing..................................................................................................................76
6.2.3 Basic Path Testing .................................................................................................................77
6.2.4 Control Structure Testing ......................................................................................................77
6.2.5 Black-Box Testing ..................................................................................................................77
6.3 Software Testing Strategies.......................................................................................................78
6.3.1 Unit Testing ............................................................................................................................78
6.3.2 Integration Testing.................................................................................................................78
6.3.3 Function Testing.....................................................................................................................80
6.3.4 System Testing.......................................................................................................................80
6.4 Code Testing ...............................................................................................................................81
6.5 Project Testing Report................................................................................................................82
6.6 Conclusion...................................................................................................................................82
7. Future Extension ..................................................................................................................................84
7.1 Death Claim Repudiated Cases.................................................................................................84
7.1.1 Sketched Interface/Report...................................................................................................87
7.2 SMSB Cases................................................................................................................................89
7.3 Wafaqi Mohtasib Complaint Cases................................................................................................90
7.3.1 Drawbacks in handling of Wafaqi Mohtasib Complaint Cases..........................................93
8. User Guide ............................................................................................................................................94
8.1 Method for Logon ............................................................................................................................95
8.1.1 Method to Change Password................................................................................................95
8.2 Description – Data Entry Form.......................................................................................................96
8.2.1 Method for Addition of New Record.....................................................................................96
8.2.2 Method of Searching of a Record.........................................................................................98
8.2.3 Method of Editing of a Record..............................................................................................99
8.3 Description on Proposal File - Update Mode ...............................................................................100
8.3.1 Method of Searching of a Record.......................................................................................101
8.2.3 Method of Editing/Updating of a Record...........................................................................102

A. Appendices.........................................................................................................................................104
A1. Data Flow Diagram........................................................................................................................104
A.1.1 Level 0 DFD..........................................................................................................................104
A.1.1 Level 1 DFD..........................................................................................................................104
A2. Entity – Relationship Diagram .....................................................................................................105
A2.1 Claim Cases .........................................................................................................................105
A2.2 Proposal File Cases .............................................................................................................106
A2.3 Duplicate File Creation Cases.............................................................................................107
A2.4 Investigation Cases..............................................................................................................108
A2.5 Misc. Complaint Cases ........................................................................................................109
A2.6 Quick Look on ER - Diagram...............................................................................................110
A3. Glimpses - at Start Up ...................................................................................................................111
A3.1 Splash Screen ......................................................................................................................111
A3.2 Main MDI Form ....................................................................................................................111
A3.3 Security First ........................................................................................................................112
A4. Sample Input Screens...................................................................................................................112
A4.1 From Option Menu...............................................................................................................112
A4.2 From the Pull-down Menu – New File ................................................................................113
A5. Output/Input Screens....................................................................................................................116
A6. Glimpse from Reports...................................................................................................................117
A7. Facilitation Scenes........................................................................................................................118
A7.1 The Calculator ......................................................................................................................118
A7.2 The Tig-Tag-Toe ....................................................................................................................118
A7.3 About the Programmer .......................................................................................................119
B. References .........................................................................................................................................120
C. Abbreviations .....................................................................................................................................121

C
H
A
P
T
E
R
When we have gone through this chapter, we will be able to aware about:
 The organization State Life Insurance Corporation of Pakistan, its
history of Nationalization, vision, mission with quality policy and
objectives formulated to make people happy life with State Life.
 Hierarchy prevails at Principal Office, Regional and Zonal Level.
Particularly, the hierarchy at project target area with the description
that “Who is answerable to whom?”
 Definition and get fully conversant on the problem taken into
account, scope of the project and set of objectives to meet in terms of
requirement
 Feasibility Report in terms of hardware/software, cost and expertise.
0
1

1. Introduction of the Organization
State Life Insurance Corporation of Pakistan (SLIC) is the only organization in
government sector dealing with life insurance business over a period of 3 – decays. The
corporation operates its business in 26 – Zones controlled with the assistance of four
regions in the country with its Principal Office at State Life, Building # 09, Dr.Zia-ud-Din
Ahmad Road, Karachi.
Life Insurance was nationalized vide President Order number 10 of 1972 dated March 20,
1972 and widely known as “Life Insurance Nationalization Order (LINO)”
Coherent purpose of Life Insurance Nationalization was “to safeguard the interest of
general public’s funds and to run the Life Insurance Business on sound and smooth lines
for the prosperity of the society and economy”.
Thirty-two Life Insurance Companies were nationalized and merged in anew Government
owned Corporation named as “State Life Insurance Corporation of Pakistan”
To provide insurance to every Pakistani at affordable price and his doorstep in the ever
and top most objective of the Corporation since it establishment.
Zonal Offices have been increased from five to twenty-six in the last three decay with four
Regional Office to control the operational activities in the middle of the organizational
structure. More or less sub-zonal offices are also working throughout the country. Besides
there are more than 700 Area Offices servicing in the remote areas. State Life is also
operating in U.K, Dubai and Kuwait to serve off-shore Pakistani nationals.
State Life’s fund since 1973 has been grown from 1.5 billions to 9.6 billion. Presently Sate
Life is providing insurance cover to more than 5.5 million people. State Life enjoys
privilege of the statutory provision that provides Government guarantee to the policies
issued by the Corporation.
1.1 Nature of the Organization
State Life transacts life insurance business, which is broadly categorized as Individual life
insurance and Group life insurance.

1.1.2 Vision
State Life’s vision is to provide life insurance coverage to maximum number of people
and providing best services at lowest cost but the main emphasize has been on
procurement of good quality new business. AND
”To widen area operation of life insurance and making it available to as large a section of
population as possible, extending it from the comparatively more effluent sections of
society to the common man in town and villages.”
1.1.3 Mission Statement
“To remain the leading insurer in the country, by meeting our commitments to our valued
policyholders and the nation.”
1.1.4 Organizational Objectives
Maximum return to policyholders through: -
- Economizing expenses
- Efficient Management practice
- Sound internal management
- Effective means of mobilization National Savings
- To widen the area of operation of Life Insurance
- To use the policyholder fund in the widen interest of the community
1.1.5 Quality Policy
“To ensure satisfaction of our valued policyholders in processing new business, providing
after sales service and optimizing return on Life Fund through a Quality Culture and to
maintain our position as the leading life insurer in Pakistan.”
1.2 Organizational Hierarchy
Simply stated, the Corporation having a Principal Office (Head Office) controls the
operational structure by setting up Zonal Offices at different location s all over the country
through its Regional Office(s) in the middle of the hierarchy. Zonal Office is further
expanded, with respect to the quantum of the business, to Sub-Zonal Office(s), Sector
Office(s), Area Office(s) and other field offices.
An over-view of the hierarchy is given in the following way: -

1.2.1 Organizational Setup Hierarchy
1.2.2 Region-wise/Zone-wise Hierarchy
Principal Office
Zonal Office
Regional Office
Sector Office Sub Zonal Office
Area Office
Principal Office
State Life Building # 09, Dr. Zia-Ud-Din Ahmad Road Karachi
Southern Region
Karachi
Central Region
Lahore
Northern Region
Islamabad
Multan Region
Multan
Multan
Zone
Rahim Yar Khan
Zone
Sahiwal
Zone
Bahawalpur
Zone
Dera Ghazi Khan
Zone
Rawalpindi
Zone
Abbotabad
Zone
Swat
Zone
Islamabad
Zone
Peshawar
Zone
Mir Pur (AJK)
Zone
Karachi (Southern)
Zone
Mir Pur Khas
Zone
Karachi (Central)
Zone
Larkhana
Zone
Karachi (Eastern)
Zone
Quota
Zone
Hyderabad
Zone
Sukhar
Zone
Lahore (Central)
Zone
Lahore (Eastern)
Zone
Gujranwala
Zone
Faisalabad
Zone
Sialkot
Zone
Sargodha
Zone
Gujrat
Zone

1.2.3 Division/Department-wise Hierarchy
Zone Office
B&A
Department
Marketing / Zonal Head
Secretariat
PHS
Department
NB
Department
IA&E
Department
Agency
Department
Law
Department
P&GS
Department
Field Marketing
Department
Real Estate
Department
Law
Division
Investment
Division
IA&E
Division
PHS
Division
International
Division
G&P
Division
B&A
Division
Marketing
Division
P&GS
Division
State Life,
Principal Office,
Karachi
Regional
Training Academy
PHS/NB
Department
B&A
Department
P&GS
Department
Regional
Secretariat &
Marketing
Department
Regional
Office

1.2.4 Controlling Hierarchy
• A Divisional Head controls a Division and accordingly a Departmental Head
controls the concerned department.
• Each Division, at Principal Office is responsible for controlling the functions of the
respective department(s) at Zonal as well as Regional level.
• Each Regional Incharge controls and supervises the affairs of the respective
department at Zonal level, under the jurisdiction of that concerned Region.
• Principal Office, over all controls the affairs of the Corporation, mainly through
the concerned Divisional Heads. Similarly Regional Office through Regional Chief
and Zonal Office through Zonal Head control the overall affairs of the Region and
Zone.
• Normally, the Divisional Head(s), at Principal Office, passes the instructions/
guidelines through their Regional Incharge(s) but can communicate directly with
the Zonal Incharge(s) of respective departmental, as the case may be.
1.2.5 Organizational Hierarchy on Project Target Area
With respected to this project, here we take the opportunity to elaborate the focus area
falling in the hierarchy on which the project is targeted.
The project is focusing the activities performed at Regional Level at their PHS/NB
Department Hierarchy of Regional level is given above. Here, we are discussing the
PHS/NB Department at Regional and Zonal Level and to make ourselves fully conversant
how these departments communicate and request are entertained by the Regional Incharge
PHS/NB at Regional Level. Regional office takes the stuff from the respective
departments at Zonal Level e.g. affairs, decision-making, financial powers beyond the
limit or any other request from the Incharge – PHS, etc of PHS/NB Department, Multan
Zone are decided at PHS/NB Department, Regional Office, Multan. Similarly, affairs of
B&A Department of Zonal Office, Multan will be dealt by B&A Department, Regional
Office, Multan and same is the case with other departments. It is also pertinent to mention
here that we are focusing the PHS Department, Regional Office, Multan and the respective
departments at Zonal level within the jurisdiction of Multan Region.

Zone Department
Communication
Hierarchy
MULTAN
PHS – Supervised by Incharge – PHS, Multan Zone
Each Incharge of
respective
Department
seeks guidelines/
reports to
Regional
Incharge – PHS,
Multan
NB – Supervised by Incharge – NB, Multan Zone
R.Y.KHAN
PHS – Supervised by Incharge – PHS, R.Y.Khan Zone
NB – Supervised by Incharge – NB, R.Y.Khan Zone
SAHIWAL
PHS – Supervised by Incharge – PHS, Sahiwal Zone
NBS – Supervised by Incharge – NB, Sahiwal Zone
D.G.KHAN
PHS – Supervised by Incharge – PHS, D.G.Khan Zone
NB – Supervised by Incharge – NB, D.G.Khan Zone
BAHAWALPUR
PHS – Supervised by Incharge – PHS, Bahawalpur Zone
NB – Supervised by Incharge – NB, Bahawalpur Zone
Similarly, the other Incharge(s) of respective departments in the zones within the
jurisdiction of Multan Region are required to seek guidelines and report to their concerned
Regional Incharge(s) at Regional Level.
Focusing on the scope of the project and to better understand the problem, in the next
section, here is an opportunity to explain some of the key functions that are performed in
PHS – Department, Regional Office, Multan and the Regional Incharge – PHS, has to
meet with the job responsibilities as narrated below: -
1. Fresh Proposal file(s), on new insurance cases, are received in PHS – Department,
Regional Office, Multan, from the respective Incharge(s) – NB of respective Zone,
duly recommended by the Zonal Underwriting Committee (ZUC) formed at each
Zonal Level. At Regional level, a committee named as RUC (Regional
Underwriting Committee) is setup to make a decision on the case beyond the limit
of ZUC but within the designated underwriting limit of RUC as delegated by the
top management (Divisional Head – PHS, Principal Office, Karachi). Regional
Incharge – PHS acts as convener of this committee.
Regional
Training Academy
B&A
Department
PHS/NB
Department
P&GS
Department
Regional Chief
Secretariat
Regional
Office

2. Death Claims, Accidental Death Benefits (ADB) Claims, Accidental Injury
Benefits Claims (AIB), Special Major Surgical Benefits (SMSB) cases are received
in PHS – Department, Regional Office, Multan, from the respective Incharge(s) –
PHS of respective Zone, duly recommended by the Zonal Claims Committee
(ZCC) formed at each Zonal Level. At Regional level, a committee named as RCC
(Regional Claims Committee) is setup to make a decision on the case beyond the
limit of ZCC but within the designated Claims limit of RCC as delegated by the
top management (Divisional Head – PHS, Principal Office, Karachi). Regional
Incharge – PHS acts as convener of this committee.
3. In order to get approval to create a duplicate policy file at the loss of the original
one, case is received at PHS – Department, Regional Office, Multan. The case is
recommended and sent by the respective Incharge – PHS Department of the
concerned Zone to get approval for creation of the new one. The Regional Incharge
PHS, Multan Region is authorized to examine the matter and accord approval.
4. Wafaqi Mohtasib Complaint cases relating to repudiation of Death claims are
received in the Regional Office and accordingly dealt with these cases.
5. Miscellaneous complaint cases relating to PHS poor Services (i.e. delay in
surrender, loan, alteration etc) to policyholders are also received and dealt to meet
the realistic interpretation of the matter.
6. Monthly Information Statements (MIS) are received from PHS/NB Departments of
concerned Zone(s), on prescribed formats, as desired by the PHS – Division,
Principal Office, Karachi. These statements are checked, compiled and then
transmitted to Principal Office.
These are some of the main functions that are performed in PHS – Department, Regional
Office, Multan. However, some other tasks like arrangement of seminars, training
programs relating to PHS/NB, special assignments entrusted by Principal Office, from
time to time, etc are also done.
Mainly, the top four items, as listed above are taken in the scope of the proposed project
and all sort of efforts are made to improve the performance of PHS – Department,
Regional Office, Multan to the extent of time management, prompt and to facilitate speedy
decision making process.

1.3 Problem Definition
At Regional Level, decision making process is the key activity on the part of the
Departmental Head(s), Focusing on PHS – Department, in order to facilitate the Regional
Underwriting Committee (RUC) and Regional Claims Committee (RCC); there was a
need to make the incoming stuff from different Zones so arranged that decision process be
completed in minimum period of time. Generally at the each month end closing and
particularly at December closing when proposal files, on which the underwriting decision
is required to be taken on the same day and communicated as well, are received in bulk.
Then it becomes very difficult to manage and complete the activity using the manual
prevailing process.
In addition to above, during the course of the process, queries, from Regional Chief,
Principal Office and the concerned Zone, are required to be entertained promptly and to
satisfy with the answer on the justified status over the case. The higher authorities, at
Principal Office ask step-by-step progress and fate on the proposal cases and RCC
decision on claims cases and expect the immediate response.
Following the manual process, it is difficult to update the record position and honour the
status/movement position queries. There is a need of a system to get thing done effectively
and efficiently.
Considering another aspect, if any delay is caused in completing the task, local
management (Zonal Head), Regional Chief and Divisional Head(s) at Principal Office,
Karachi, take a serious view and keep on knocking the concerned official until they are
satisfied with the clarification. In order to explain the position, and pinpoint the real
problem area or official that actually caused for delay in process; it is desperately needed
to plan, organized and implement a sound track and trace system so that task be
accomplished with minimum use of time, other resources to meet the end of the
interpretation and to avoid further complications.
With the commence of office hours, observing the manual system, file(s) is received in
PHS – Department, Multan Region; following activities are necessarily required to be
performed on a proposal file particularly.

a. File receiving (Date is mentioned)
b. Allocating a unique serial number
c. Entering necessary particulars, taken from the file, in a Register
d. Placing a Summary Sheet / Brief Sheet in the file
e. Referring the case to Chief Medical Examiner (C.M.A).
f. Calling committee members and putting the case in the meeting after the file is
received from C.M.A.
g. Getting decision from the committee members on the proposal/file.
h. Preparing fate and sending to the concerned Zone if approved, otherwise to higher
authorities for consideration or the case may be.
i. Updating the record on each movement (i.e. file movement status)
j. Entertaining the queries as stated above, during the course of this exercise.
Similarly, files regarding death claim cases, claims investigation cases, duplicate file
creation matters and etc are also received in a large numbers. More or less, the activities,
as stated above, are required to be performed. Obviously, during the course of the
performance of these activities till the dispose of the file from the Department; constantly,
different sort of queries are welcomed and answered on step-to-step movement of the file
and fate/decision at the end.
Using the manual system, to the extent of record (movement position and updation) and
fulfilling the queries; it becomes very difficult to cope with the flow of information
without any delay. Also, at one point-in-time, at a particular level of activity, if an official
(officer or staff) delay the matter and dispose off the activity inefficiently or shows
negligence in meeting job responsibilities; it is very difficult to clearly point out where the
problem actually exist or the person to whom the responsibility be fixed.
Hence there is a need of such a mechanism in remedy of above problems faced by the
management, prepare the information in any easy way, to get the information instantly,
and to avoid management pressure.
1.4 Scope of the Project
Scope of the project explains the constraints to the extent of features of the system can
accommodate the changes, from time to time, in respect of procedures and policies and to
what extent the system will perform in solution of the defined problem.
First, the proposed system limits it utility and activities to the extent of PHS – Department,

Regional Office, Multan. There are a number of other activities, in addition to the
activities performed as explained under the topic of problem definition, which are
summarized as under: -
01- Monthly Information Statements (MIS), relating to PHS – Department(s) of Zone
in the jurisdiction of Multan Region (i.e. Multan, R.Y.Khan, Sahiwal, D.G.Khan,
Bahawalpur), are received, checked, compiled and transmitted to Principal Office,
Karachi.
02- Correspondence regarding provision of guidelines/instruction to the lines
departments, as directed by PHS – Division, Principal Office, Karachi or sought
out by the Departmental Heads, on case-to-case basis.
03- Entertaining queries and providing suggestions/solutions on the hurdles faced from
time to time at Zonal level in lines departments.
04- Monitoring, checking and evaluation of practices being made at Zonal level in the
lines departments. (For example, surprise visit of underwriting section, claims
sections etc)
05- Arranging workshops/seminars and training programs on need basis at zonal as
well as Regional level relating to PHS/NB matters in order to make Executives and
operatives fully conversant and practicable on the rules & regulations and
procedural aspect of the policies in operation.
06- Any other assignment/job assigned by the Principal Office
The items, listed above are beyond the scope of the project but very much included in the
project and focused to computerize the following assignments, being performed manually
at PHS – Department, Regional Office, Multan.
a. Record management and decision-making on the files upon Death Claims, Surgical
Benefit Claims, and Normal Injury Claims cases beyond the scope of the lines
departments, till the dispatch of the file carrying RCC decision.
b. Dealing with fresh proposal files, activities relating to record management,
decision of RUC and sending the file to concerned department/division.
c. Wafaqi Mohtasib record management on the complaints only relating to the death
claims repudiated cases or delay in process of the other claims.
d. Record management on Duplicate Policy File creation, Death Claims Investigation
cases and miscellaneous complaint cases to the extent of no duplicate file is
created twice, to whom investigation file is marked, report received and constant
follow-up over investigation and compliant cases.

1.5 Broad Based Objectives
- To get the work done effectively and efficiently on the activities to be performed,
as focused in the scope of the project, at PHS – Regional Office, Multan.
- To avoid the management pressure for doing work in a haste
- To perform the activities in an arranged, planned and systematic way.
- To provide a reasonable/satisfied answer to the local management as well as higher
authorities on the queries asked for relating to decision/file movement status.
1.6 Specific Objectives
- To minimize the transit of file(s) lost which is received in PHS – Department,
Regional Office, Multan.
- To respond the queries on file position instantly
- To settle the death claim cases/injury/special surgical benefit claims as early as
possible with the minimum use of resource particularly in time management.
- To address the Wafaqi Mohtasib complaint cases in a coherent way so that genuine
grievances of the complainant be mended for without delay.
- To judge the efficiency of RCC/RUC to the extent of cases submitted decided and
disposed of ratio.
- To properly manage investigation cases, duplicate file creation cases reported to
the department and misc. complaint cases and fresh proposal file cases so that tack
and trace be done in a coherent way and done the work effectively and efficiently.
1.7 Feasibility Report
To get the existing practices, with in the defined scope of the project, transform to the
computer system; it is proposed to develop a computerized system name as “Track and
Trace System” using Microsoft Access and Visual Basic. The feasibility is judged on the
following aspects:-
1.7.1 Hardware & Software
In PHS – Department, Multan Region, a Computer System P – IV (2 GHz) is available
carrying 256 MB RAM, HDD 40 GB, FDD 3.5”, CD ROM and 15” Display Screen. The
department is using a licensed software(s) Windows – XP (Professional Edition) as

operating system and MS – Office, XP as application package. Normally the department
uses MS – Word to meet with the correspondence/typing and MIS using MS – Excel.
There is no use of MS – Access although available in the purchased Office package.
These resources, to the extent of hardware and software requirement for the proposed
track and trace system, are sufficient and quite enough to cope with the obligations. So
there is no need to get new software or include new hardware for the development,
implementation and maintenance of the proposed system.
1.7.2 User Expertise
Presently, a Computer Operator (B.Sc. with One year Diploma in Computer Applications),
is working in the department. He possess eight year experience of computer operations
using application software particularly MS – Office. Having brief analysis, such
experience is quite enough to understand the operations of the proposed system and to get
the functions done from the machine. The person responsible for computer operations
needs no intensive formal training to understand the functions of the proposed system.
1.7.3 Cost Analysis
It is analyzed that necessary hardware, software and user expertise are very much
available in the department. So, no extra expense even to a single penny is required to
incur to initiate the proposed track and trace system. In addition to this, environmental
conditions are very much favourable (i.e. centrally air-conditioned office, management
and user/operator is eager to adopt the computerized system with the objective to improve
the overall performance); therefore, there is no such cost the department has to bear to
make the daily operations convenient to them and this leads to the proposed system highly
cost effective regarding all ingredients.
Hence, in all respects, the development, implementation, adoption and then maintaining
the proposed system is very much feasible and applicable in the prevailing conditions,
environment of PHS – Department, Regional Office, Multan.

When we have gone through this chapter, we will be able to know about:
 The number of work areas and activities are being performed in
connection with the project scope. Manual procedures and practices
prevailing in the existing system
 Sub Activities integrated with each other to shape up one complete
task
 Format of recording of the data i.e. maintaining registers under
different segment work job. The drawbacks creating hindrances
towards efficiency in terms of time consumption in particular and
effectiveness regarding performance cost relationship
 Diagram in analysis of the existing system
C
H
A
P
T
E
R
0
2

2. Detail Study of the Existing System
In previous chapter, as defined in the scope of the project, we have focused on the
following four components and made a detailed analysis of the existing manual system
against each of the category, narrated as under: -
2.1. Underwriting Cases
In PHS – Department, Regional Office, Multan, the fresh proposal file(s), which are
beyond the limit of the Zones: Multan, Rahim Yar Khan, Dear Ghazi Khan, Sahiwal &
Bahawalpur, within the jurisdiction of Multan Region are received from the respective
Incharge – NB, dully recommend by their respective Zonal Underwriting Committee
(ZUC), with the request to accord decision of Regional Underwriting Committee (RUC)
whether the proposal be accepted or not.
After having the proposal file received, following activities are performed to make it
presentable to the RUC.
01- A unique serial number is allocated to each proposal file (e.g. RUC – 0001/2004)
with the date on which the file is received.
02- Following particulars, taken from the file, are entered in a Register, as per format
given below: -
(1) (2) (3) (4) (5)
Ref # Proposal # Zone Life Proposed
Table
& Term
RUC-0001/2004 82-1625-04 BAHAWALPUR MR. M.ASLAM 03/20
RUC-0002/2004 85-1928-04 D.G.KHAN MR.M. IMRAN 05/21
(6) (7) (8) (9)
Sum
Assured
File
Received on
File
Returned on
Remarks
25,00,000 15-05-2004 Under Process
10,00,000 16-05-2004 17-05-2004 Accepted

The elaboration of these particulars is given as under: -
i. Reference number is the same as that of serial number as mentioned on the cover
page of the file at the time of receiving. The format of this reference number is
designed in such a way that RUC-continuous serial number/current year. RUC is
taken with respect to the matter pertains to Regional Underwriting Committee,
continuous serial number is a sequence of incoming files and current year reflects
the year in which the file is first time received in the Regional Office.
ii. Proposal # is taken from the Proposal File. This number is unique with respect the
Zone-wise serial number but the format is same for each Zone. There are three
parts of writing a proposal Number. The format is like Zone Code – Proposal Case
Number – The year in which the proposal is received in the Zone. The Principal
Office assigns zone code uniquely to each Zone. For example, The Zone Code 82
will always mention the Zone “Bahawalpur” while 85 is assigned to D.G.Khan
whereas 08 is fixed for Multan Zone and etc. Proposal Case Number is maintained
at Zonal Level. It is a sequence number of proposal-received order in different
plans. For example 1625 means that 1625 proposals are received so for in the
particular year in Bahawalpur Zone, as stated above. The digit next to Proposal
Serial Number shows the year in which this particular proposal is received in the
Zone. As stated above in 85-1625-04, here 04 shows that the proposal number
1625 pertaining to Bahawalpur Zone is received in the year 2004.
iii. The column titled as Zone, simply states that the zone from which the proposal
pertains to. The name of the zone is written under this column.
iv. Under the column of “Life Proposed”, the name of the person is mentioned who
intends to take the policy (Life Risk Coverage).
v. Table and Term are actually two attributes. The Table number shows the plan
number, which the life proposed, intends to purchase. This plan number is a unique
number given to the product (policy plan) by the Corporation to identify the
product (it may be termed as product ID). The other component “Term” stands for
the number of years to which the life proposed intends to make the agreement with
the Corporation for its life risk coverage. Simply stated, it shows the period of a
life policy. This agreement may be for 10, 15, 20 years or any other choice of life
proposed. As above 03/20 explains that the life proposed intends to purchase an
endowment individual life plan (03 is the product ID for individual life plan) for a
period of 20 years.
vi. Under the column of “Sum Assured”, an amount is written for which the life
proposed intends to purchase the policy. Actually, it shows worth of the policy. For
example, as stated above, 25,00,000 (25 Lac) is written as sum assured means that
the life proposed intends to purchase life policy coverage of 25 Lac for the period
of 20 years under plan 03.
vii. “File Received on” column shows the date on which the file is received in PHS –
Department, Multan Region. It is worth mention that the column may attain
different value (date) if the particular file is received more than one time, in the
department for different reasons. For example, first time file is received on 15-05-

2004 but it returned to meet with certain requirements. After having requirements
fulfilled, this particular file is again received from the Zone; the date on which the
file is again received is also entered under this column. No new reference number
will be marked to the file, which already carries the reference number.
viii. Similarly, the column “File Returned on” shows the date on which the file
dispatched to the concerned Zone/ or to the appropriate authority, as the case may
be. This column may also attain more than one value in case the file gets transit
more than once in Regional Office, Multan.
ix. In the last but not the least, the column “Remarks” gets much of the description on
the activities performed on that particular file. It carries movement status on
activity to activity performed on the file, fate on the case, file returned description
and etc. On having profound analysis of this column; this column may get the
description as stated below: -
i. Under Process
ii. Requirements Called ( in case of in-complete case)
iii. Proposal Accepted at ordinary rates
iv. Proposal Declined (if not accepted)
v. Difference of Opinion, File sent to Principal Office
vi. File Sent to Chief Medical Advisor (CMA) on dated: ______
vii. Fresh Medical Called.
viii. File Returned to concerned Zone &
ix. Other special notes pertaining to the case
In addition to maintaining of this register and to keep the register up-to-date in order to
honour the queries as described in the previous chapter; we have to summarize the results
on the following points, after having done the activities on monthly, quarterly and yearly
basis.
01- Monthly/Quarterly/Half-yearly and yearly statement(s) showing the number of
cases received from a particular Zone.
02- The number of cases declined/accepted/difference of opinion (on
monthly/quarterly/Half-yearly and yearly basis).
03- Number of pending cases
04- Number of cases on which the requirements are called but not received
05- Number of cases received under a particular Table (Plan of the policy)
06- Or any other report asked by the management.

2.1.1 Drawbacks in Underwriting Cases Management System
In the aforementioned description on examining the manual existing system under the
category of underwriting cases and keeping in view the expectations of management to
honour the quires promptly and to get the reports, as mentioned above, effectively and
efficiently; following drawbacks and weakness of the existing system are pointed out that
cause for too much delay in meeting the required standard of performance.
a. Focusing on the format of the Register as described above, taking from the last
column – Remarks, it is examined that it takes a lot of description and status on
most of the separate activities is embedded under a single heading. For example,
decision taken on the file, requirements called, file sent, narration of the decision
and in between activities from file received to dispatch are recorded under this
column. It comes very difficult to scrutinize and to count manually the cases
declined, pending, accepted etc; and one can imagine the laborious work required
to be done when monthly/quarterly/yearly statements are desired on different
components as described in the above list of reports. When the management needs
such sort of information; the operator has to scrutinize each of the rows very
minutely to avoid the chances of error on having a report. It consumes a lot of time
when the transactions are in bulk. Some times, this column, under a particular row,
is so filled that an additional space on some other page is allocated. Doing this, for
particular information, a number of pages are referred to accumulate the scattered
information. Long and short, this column “Remarks” is so filled and occupies a lot
of information that should be separately recorded in dream of getting list of above
reports. Moreover, the queries can’t be properly addressed when this row is bulky
and difficult to dig out the answerable status.
b. When a particular file is received more than once; the file received column and the
file returned column is filled more than one date(s).
c. Table and term are two separate items, which are embedded into a single column.
When there is need to prepare the statement(s) of cases under a particular Table
and term, it becomes very difficult to summarize the results as the quantum of the
cases increases.
d. We have to count and analyze row by row when zone-wise list is required to arrive
the number of cases, in analysis of increased quantum of cases reported from
different zones. It becomes very laborious exercise and cause for waste of time
affecting the other activities to be performed in time.
2.2 Duplicate File Creation Matters
Policy File(s), containing the record of the policyholder(s), is created, maintained and kept
under safe custody at Zonal Level. During the course of the working on a policy file,
transit from department to department or for some other reason, if a file is lost, then a set

procedure is given to the Zonal Incharge(s) – PHS/NB to re-construct the file. The
procedure to reconstruct the duplicate policy file is initiated at Zonal level. With all sorts
of necessary requirements dully completed in all respects, as per laid down procedure and
instructions of the Principal Office, file is passed to the Regional Incharge to accord final
approval for its reconstruction. Discussion on the procedure and activities done at Zonal
Level, for this assignment, is beyond the scope of this project. However, we would focus
on the activities performed at Regional Office level once the file is received to accord
approval for reconstruction.
On receipt of the case for duplicate file, Regional Incharge wholly and solely examines the
matter on case-to-case basis and decides to accord approval after meeting all necessary
ingredients. Here, we will only discuss the file movement, status on the matter,
requirement position if any, pending and disposed off cases – means to the extent of
record management and smooth tracking and tracing of the file. For this purpose, a
Register is maintained as per format given below: -
1. A unique serial number is allocated to each proposal file (e.g. DUP – 0001/2004)
2. Following particulars, taken from the file, are entered in a Register, as per format
given below: -
(1) (2) (3) (4) (5)
Ref # Policy Number Zone Policyholder
Table
& Term
DUP-0021/2004 508035489-0 BAHAWALPUR MR. M.INAM 03/20
DUP-0022/2004 508391339-6 D.G.KHAN MR.M. IBRAHIM 07/21

(6) (7) (8) (9) (10
Date of
Commencement
Sum
Assured
File
Received on
File
Returned on
Remarks
01-04-1982 1,00,000
01-12-2003
15-12-2003
04-01-2004 Approved
31-12-1985 2,50,000 21-04-2004 22-04-2004 Requirements called
a Reference number is the same as that of serial number as mentioned on the cover
designed in such a way that DUP-continuous serial number/current year. DUP is
taken with respect to the matter pertains to Duplicate File, continuous serial
number is a sequence of incoming files and current year reflects the year in which
the file is first time received in the Regional Office.
b Policy # is taken from the papers of the file. Here is an opportunity to discuss the
mechanism of conversion of proposal # into a policy number. As stated earlier,
when a fresh proposal is received, a unique proposal number is assigned to each
proposal. After having necessary process completed, if proposal is accepted, then a
unique serial number named as “Policy Number” is issued to the particular file.
During the entire length of the policy contract, the holder of the policy is regard
with reference to a policy number. It is a nine digit continuous serial number with
one digit code carrying a hyphen between continuous serial number and digit code.
If a policy file is lost, obviously, it would have been issued a unique policy
number. So, this policy number is taken from the papers contained in the case
presented for creation of a duplicate file.
c The column of Zone simply states that the zone from which the policy pertains to.
The name of the zone from the file received is mentioned.
d Under the column of “Policyholder”, the name of the person is mentioned whose
life risk is covered under that particular policy and is the actual holder of the policy
contract.
e The elaboration of the column titled as “Table and Term” is the same as given
above in the matter of “Underwriting Cases”. However, it mentioned here, when
the proposal is converted into policy, only the status of life proposed is changed to
policyholder while other contents, as agreed upon, remains the same, as given in
the initial proposal form, dully signed by the life proposed/policyholder.
f The commencement date is also called Risk Date. In the policy contract, this date
shows the period from which the life risk of the life proposed/policyholder is
covered – means, actually, the policy contract between the Corporation and the
policyholder starts form this date, and maturity of the policy contract is calculated
using the date of commencement of the policy under the prescribed term. This date
is also available in the file presented for duplicate record creation.
g Under the column of “Sum Assured”, an amount is written for which the
policyholder is given risk. Actually, it shows worth of the policy. For example, as

stated above, 1,00,000 (One Lac) is written as sum assured means that the life risk
for the policyholder is covered for sum of Rs.1,00,000.
h “File Received on” column shows the date on which the file is received in PHS –
Department, Multan Region. It is worth mention to here that the column may attain
different values (date) if the particular file is received more than one time, in the
department for different reasons. For example, first time file is received on
01-12-2003 but it returned to meet with certain requirements. After having
requirements fulfilled, this particular file is again received from the Zone; the date
on which the file is again received is also entered under this column. No new
reference number will be marked to the file, which already carries the reference
number.
i Similarly, the column “File Returned on” shows the date on which the file
j In the last but not the least, the column “Remarks” gets much of the description on
i. Under Process
ii. Requirements Called (in case of in-complete case)
iii. Approved for reconstruction of duplicate file
iv. Pending
v. Approved and File returned to the concerned Zone.
honour the queries as described in the previous chapter; the following reports are prepared
using the data form this register: -
01- List of cased on which the requirements were called but not received
02- Statement of Pending Cases (Under Process)
03- Zone-wise/year-wise list of duplicate files on which the approve accorded

2.2.1 Drawbacks in Duplicate File Creation Matter
category of duplicate file creation matter and keeping in view the expectations of
management to honour the quires promptly and to get the reports, as mentioned above,
effectively and efficiently; following drawbacks and weakness in the existing system are
pointed out that cause for delay in meeting the required standard of performance.
column – Remarks, it is examined that it takes a lot of description and most of the
separate activities status is embedded under a single heading. For example,
decision taken on the file, requirements called, file sent, narration of the decision
and in between activities from file received to dispatch are recorded under this
column. It comes very difficult to scrutinize and to count manually the cases,
pending, accepted etc. When the management needs such sort of information; the
operator has to scrutinize each of the rows very minutely to avoid the chances of
error on having a report. It consumes a lot of time when the transactions are in
bulk. Some times, this column, under a particular row, is so filled that an additional
space on some other page is allocated. Doing this, for particular information, a
number of pages are referred to accumulate the scattered information. Long and
short, this column “Remarks” is so filled and occupies a lot of information that
should be separately recorded in dream of getting list of above reports. Moreover,
the queries can’t be properly addressed when this row is bulky and difficult to dig
out the answerable status.
c. Table and term are two separate items, which are embedded into a single column.
When there is need to prepare the statement(s) of cases under a particular Table
and term, it becomes very difficult to summarize the results as the quantum of the
cases increases.
d. We have to count and analyze row by row when zone-wise list is required to arrive
the number of cases, in analysis of quantum of cases reported from different zones.
It becomes very laborious exercise and cause for waste of time affecting the other
activities to be performed in time.
2.3. Death Claims Investigation Cases
PHS – Department at Zonal level has to carry death claim investigation on early death
claims or the cases on which the ZCC/RCC calls investigation. In the definition of early
death claims cases are: those claims are submitted with in the period of two years on
enforce policies. Most of the zones have their own claim examiner(s) as appointed by the
Principal Office. But some of the zones like Bahawalpur, D.G.Khan, and Sahiwal have no

expertise to carry out this specific job. Hence, they move such cases to Regional Incharge
– PHS, Multan with the request to arrange the death claims investigation completed
thorough a claim examiner or some suitable officer and return the file alongwith the
investigation report. Therefore, the files under death claims investigation are received in
PHS – Department, Multan Region and the Regional Incharge – PHS has to meet with the
job assignment. It is pertinent to point out that the other zones not falling within the
jurisdiction of Multan Region may also send their investigation cases, in case the claims
investigation area falls very much within the jurisdiction of Multan Region. For example,
PHS – Department, Lahore (Central Zone) may request to the Regional Incharge – PHS,
Multan Region to honour them with an investigation report in case the deceased belong to
Multan Region even policy pertains to Lahore Central Zone. So, these requests are also
honoured. Long and short, investigation matter may come from all over the Corporation.
On receipt of a death claims investigation file, the file is examined and by the Regional
Incharge – PHS and then marked for investigation to an appropriate claims examiner or
some officer on which the case is entrusted. The claim examiner is requested to get the
matter investigated and submit the report direct to the concerned zone under intimation to
the Regional Incharge – PHS, Multan. It is examined that following activities are
performed on a death claims investigation file. For this purpose, a Register is maintained
as per format given below: -
01- A unique serial number is allocated to each policy file (e.g. INVES – 0001/2004)
given below: -
(1) (2) (3) (4) (5)
Ref # Policy Number
Concerned
Zone
Deceased Name
Table
& Term
INVES – 0003 /2004 508035489-0 BAHAWALPUR MR. M.INAM 03/20
INVES – 0004/2004 508391339-6 D.G.KHAN MR.M. IBRAHIM 07/21

(7) (8) (9) (10
Sum
Assured
File
Received on
File Marked
To
File
Returned on
Remarks
1,00,000
01-12-2003
15-12-2003
Mr. Nauman Akmal
Multan Region
04-01-2004
Investigation Report
received; file returned
2,50,000 21-04-2004 Multan Zone 22-04-2004 File sent for investigation
01- Reference number is the same as that of serial number as mentioned on the cover
designed in such a way that INVES-continuous serial number/current year. INVES
is taken with respect to the matter pertains to investigation, continuous serial
number is a sequence of incoming files and current year reflects the year in which
the file is first time received in the Regional Office.
02- In regard to the column titled as “Policy number”, the description is same as
elaborated under the heading “Duplicate File Cases”.
03- The column “Concerned Zone” simply states that the zone from which the death
claim policy file pertains to and received from. The name of the zone from the file
received is recorded
04- Under the column of “Deceased Name”, the name of the person is mentioned
whose life risk is covered under that particular policy and is the actual holder of the
policy contract. It is also called policyholder, when alive. In case of death of the
policyholder, this title is changed to the word Deceased.
05- The elaboration of the column titled as “Table and Term” is the same as given
06- The explanation on the column “Sum Assured” is same as narrated above in the
matter of duplicate file creation supported with the sentences written under
underwriting cases.
07- “File Received on” – explanation is same as given above.
08- “File Marked To” column may attain different values. Basically, under this
column, the name of the examiner is written to whom investigation is marked by
the Regional Incharge – PHS. If the case is required for a claim examiner other
than the Regional Office then only zone name is mentioned and the name of claim
examiner is left at the discretion of the referred Zonal Incharge – PHS. For
example, if the matter is required to get the investigation from a claim examiner
associated with Multan Zone; file is sent to the Incharge – PHS, Multan Zone
requesting to get the case investigated from the claim examiner and submit the
report to the concerned zone under intimation to the Regional Incharge – PHS.
09- Similarly, the column “File Returned on” shows the date on which the file

10- As usual as stated above, the column “Remarks” gets much of the description on
a. Under Process (if case is not yet marked and placed on the table of the
Regional Incharge – PHS)
b. Referred for Investigation
c. Investigation Report Received
d. Report and file sent to concerned zone.
honour the queries as described in the previous chapter; the following reports are prepared
using the data form this register: -
a. List of cases referred but report/reply not received
b. Statement of under Process cases / Unmarked Cases
c. Zone-wise/year-wise list of Investigation cases
2.3.1 Drawbacks in Investigation Cases
category of investigation cases and keeping in view the expectations of management to
honour the quires promptly and to get the reports, as mentioned above, effectively and
efficiently; following drawbacks and weakness in the existing system are pointed out that
cause for delay in meeting the required standard of performance.
separate activities status is embedded under a single heading. For example, file
referred to or marked for investigation, reminder sent to referred zone/person to
complete the investigation or reminder on report not received, file sent to the
concerned zone alongwith report etc. It comes very difficult to scrutinize and to
count manually the cases, required to follow-up the cases, disposed off cases and
etc. When the management needs such sort of information; the operator has to
scrutinize each of the rows very minutely to avoid the chances of error on having a
report. It consumes a lot of time when the transactions are in bulk. Some times, this
column, under a particular row, is so filled that an additional space on some other
page is allocated. Doing this, for particular information, a number of pages are
referred to accumulate the scattered information. Long and short, this column

“Remarks” is so filled and occupies a lot of information that should be separately
recorded in dream of getting list of above reports. Moreover, the queries can’t be
properly addressed when this row is bulky and difficult to dig out the answerable
status.
c. On the column Table/Term; the observation is same as given above in case of
Duplicate file cases and underwriting cases.
d. Having observations on the column Concerned Zone; the concerns are same as
given above categories.
2.4 Claims Cases
In PHS – Department, Regional Office, Multan, the policy files against the lodged on
policy claims, which are beyond the limit of the Zones within the jurisdiction of Multan
Region are received from the respective Incharge – PHS, dully recommend by their
respective Zonal Claims Committee (ZCC), with the request to accord decision of
Regional Claims Committee (RCC) whether the claim be accepted or rejected/repudiated.
Before to list down the categories of claims cases; here is an opportunity to clarify that the
procedure of lodging of every type of following claims, calculation of claims liability and
other requirements are beyond the scope of this project. The process from intimation of the
death claim to the final payment on the claim, if accepted, meeting with all necessary
requirement are done at zonal level. The claim file, completed in all respects, is moved to
RCC, seeking final decision, only on those cases, which are above the given limit of ZCC.
Now, the brief description on each of the category of claims cases is given below: -
a. Death Claims Cases – These claims are lodged after the death of the
policyholder/life proposed by the claimant.
b. SMSB Claims Cases – SMSB stands for Special Major Surgical Benefit. This
claim is applicable on all enforce policies. On the request of the policyholder, some
amount is advanced, meeting with other terms and conditions of eligibility of this
claim, on his/her request, in case the policyholder has to undergo with major
surgical; for example, bye-pass. This claim is entertained in the life of the
policyholder under policy terms and conditions.
c. AIB Claim – stands for Accidental Injury Benefit. This claim is entertained, as per
policy terms and conditions, on acquiring injuries during the insured life risk as per

policy contract. The cost of medicines/treatment is given as per claim and policy
contract worth.
On having any of the above claim file received in PHS – Department, Regional Office,
Multan; following activities are done with reference to track and trace system: -
01- A unique serial number is allocated to a policy claim file (e.g. RCC – 0001/2004)
given below: -
(1) (2) (3) (4) (5)
Ref # Policy Number
Concerned
Zone
Deceased Name
Table
& Term
RCC – 0001 /2004 508035489-0 BAHAWALPUR MR. M.INAM 03/20
RCC – 0002/2004 508391339-6 D.G.KHAN
MR.M.
IBRAHIM
07/21
(7) (8) (9) (10
Sum
Assured
Claim
Category
File
Received on
File
Returned on
Remarks
1,00,000 SMSB
01-12-2003
15-12-2003
04-01-2004
RCC approved claim,
File Returned
2,50,000 Death Claim 21-04-2004 22-04-2004
Claim Declined,
File Returned
i. Reference number is the same as that of serial number as mentioned on the cover
designed in such a way that RCC-continuous serial number/current year. RCC is
taken with respect to the matter pertains to Regional Claims Committee,
continuous serial number is a sequence of incoming files and current year reflects
the year in which the file is first time received in the Regional Office.
ii. In regard to the column titled as “Policy number”, the description is same as
elaborated under the heading “Duplicate File Cases”.
iii. The column titled as Zone, simply states that the zone from which the policy file
pertains to. The name of the zone is written under this column.
iv. Under the column of “Deceased Name/Policyholder”, the name of the person is
mentioned whose life risk is covered under that particular policy and is the actual
holder of the policy contract. It is also called policyholder, when alive and the
nature of the claim is AIB or SMBS. In case of death of the policyholder, this title
is changed to the word Deceased.

v. The description under the column(s) Table/Term & Sum Assured is the same as it
is given in the case of underwriting matters, duplicate file cases or death claims
investigation matters.
vi. As for as the column under title “Claim Category” is concerned; this cell may take
three kind of values in regard to the type of the claim: SMSB Claim, AIB Claim
and Death Claim.
vii. Description in regard to “File Received on” and “File Returned To” column(s) is
the same as given above in case of Investigation matters; Duplicate files cases and
underwriting cases.
viii. In the last but not the least, the column “Remarks” gets much of the description on
and etc. On having profound analysis of this column; this column gets the notes as
stated below: -
▪ Under Process
▪ Requirements Called
▪ Sent for Reinvestigation
▪ Liability Accepted and File Returned
▪ Liability Accepted and File sent to RCC
▪ Liability Repudiated
▪ Liability Repudiated and File sent to P.O.
▪ Difference of Opinion and File sent to RCC
▪ Liability Accepted
▪ File sent to Zone to decide in ZCC
honour the queries as described in the previous chapter; we have to summarize the results
on the following points, after having done the activities on monthly, quarterly and yearly
basis.
1. Statement of Under Process Cases
2. Statement of Repudiated Cases, on monthly basis, to be sent to P.O., as per desired
format
3. Monthly statement of SMSB approved cases
4. Statement recording the disciplinary actions, if recommended, on repudiated cases

5. Work efficiency showing statements; e.g., how may cases reported, repudiated,
accepted, quantum of cases under a specific category, zone-wise claims cases,
cases marked for reinvestigation and etc.
6. Number of cases on which the requirements are called but not received
7. Or any other report asked by the management.
The above information is dig-out using the register as per format given above. However,
specifically in order to get the statement(s) on “Repudiated Claims Cases” and SMSB
Cases, as per pre format desired by Principal Office; following two registers, in addition to
above register, are maintained: -
2.4.3 Drawbacks in Claims Cases Management System
category of claims cases and keeping in view the expectations of management to honour
the quires promptly and to get the reports, as mentioned above, effectively and efficiently;
following drawbacks and weakness of the existing system are pointed out that cause for
too much delay in meeting the required standard of performance.
In analysis of whole of the claims cases handling mechanism and going through the
format(s) of all the registers maintained here, most of the flaws are experienced same as
encountered in Duplicate File cases, Underwriting Cases and Claims Investigation Cases.
So, we skip the elaboration on those columns, which are similar and have been discussed
earlier in this chapter under one or the other category; the columns like: Concerned Zone,
Table & Term, File Received on, File Returned on and Remarks. On these columns,
observations may be considered same as earlier. Now, we will discuss the remaining
columns under which the observations are recorded that may hinder the problems in
smooth flow of data.
a As noted above under the column of “Claims Category”, it attains more than one
value with respect to the type of the claim (AIB, SMSB, Death Claim). When
query on specific type of cases, is required, the operator has to count the same type
of data under this column vigilantly to arrive the conclusion which becomes more
difficult when required information is too scattered and bulky. It is also the case
with the columns: Reasons for Repudiation and Supplementary Contract.
b Here, we would like to comment of “Disciplinary Action Column”. With profound
analysis, it is pointed out that the column possesses a lot of bulky, in-different

information. This column contains information about the person against which the
disciplinary action recommended (name, designation, code number etc), the case
referred to the personality to take action, feedback, follow-up response is also
recorded in this column (when the case referred, reminder date, if any, fate on the
action recommended etc). When the higher authorities seek information about the
disciplinary action matter; one can imagine how it would be so difficult and
complicated to find out the desired information and put into different prescribed
columns as desired by the authorities. This is the main drawback in follow-up and
implementation mechanism dealing with disciplinary action matters.
2.5 Miscellaneous Complaint Cases
PHS – Department, Regional Office, Multan has to entertain Misc. complaint cases with
respect to the policyholder services. For example, a policyholder applied for loan on
his/her policy. Eventually, there is no response from the concerned zone, delay in process
of the application or any other reason due to which the policyholder (customer) is not
satisfied with the quality of the service. The policyholder has right to approach to the
Regional Incharge – PHS, Multan to bring the matter in notice his notice and Regional
Chief, Multan. Such complaints are received directly in PHS – Department, Regional
Office, Multan or may come through the office of the Regional Chief, Multan. When these
sorts of complaints are received, Regional Incharge – PHS, Multan Region seek comments
for the concerned Incharge – PHS, at Zonal Level, falling within the jurisdiction of Multan
Region and remains in touch with the proceedings to mend for the complaint in order to
satisfy the customer. It has been experienced that generally, following nature of
complaints are received regarding poor services to the policyholder: -
a. Delay in process/un-due requirements in Policy Surrender Cases
b. Delay in the Policy Loan cases
c. Alternation matter services (Required changes in Policy Schedule, e.g., change in
nominee, Table/Term etc)
d. Policy Late Fee Concession matter
e. Complaint against official on misbehave, charges leveled by the policyholder
On receipt of any nature of compliant, action is taken promptly. For the purpose, a register
is maintained to keep the record of these complaint cases, progress on these cases and
follow-up on the cases so that the genuine grievances of the complainant are addressed in
a coherent way.

01- A unique serial number is allocated to each complaint Application (e.g. Misc –
0001/2004) with the date on which the file is received.
02- Following particulars, taken from the complaint application, are entered in a
Register, as per format given below: -
(1) (2) (3)
Ref # Subject
Concerned
Zone
Misc – 0003 /2004
Complaint of Mr. Muhammad Arshad, Policy #
508035489-0, against Incharge – PHS, Bahawalpur
Zone regarding delay in process of policy surrender
BAHAWALP
UR
Misc – 0004/2004
Complaint of Mr. Muhammad Anees, Policy #
508391339-6, against Incharge – PHS, Dera Ghazi
Khan Zone regarding delay in process of policy
Loan
D.G.KHAN
(4) (5) (6)
Complaint
Received on
Complaint
Referred on
Remarks
15-01-2004 16-01-2004
On 16-01-2004; Comments called from Incharge – PHS,
Bahawalpur
On 05-02-2004; Reply received stating the compliant is
solved
21-03-2004 22-04-2004
On 22-04-2004; Copy of the complaint sent to Incharge –
PHS, D.G.Khan Zone with the directions to solve the
matter under intimation to this office
On 03-05-2004; Reminder sent to Incharge – PHS,
D.G.Khan
On 15-05-2004; Reply received. Complaint is settled.
01- Reference number is the same as that of serial number as mentioned on the cover
designed in such a way that Misc-continuous serial number/current year. Misc is
taken with respect to the matter pertains to Miscellaneous Complaint cases,
continuous serial number is a sequence of incoming applications and current year
reflects the year in which the application is first time received in the PHS –
Department, Regional Office, Multan
02- In is observed that the column “Subject” carries a number of information
embedded in one cell. It contains the information of name of the complainants, the
person/department against which the complaint is made, nature of the complaint
i.e. the matter on which the compliant pertains to and particularly the policy
number (the key element) on which the complaint initiated. Putting the data above
in this column does self-explanatory elaboration.
03- The elaboration on the column “Concerned Zone” is the same as done earlier on
different work categories, explained in this chapter so for.

04- The column “Complaint Received On” is the same as that of “File Received on”
Column. Hence the elaboration is the same and self-explanatory.
05- The column “Complaint Referred On’ resembles with the column “File Marked
To” column as elaborated in the category of “Death Claims Investigation Cases”.
06- As usual as stated above, the column “Remarks” gets much of the description on
the activities performed on that particular complaint application. It carries
movement status on activity to activity performed on the matter, fate on the case,
file returned description and etc. On having profound analysis of this column; this
column may get the description as stated below: -
i. Date and the person to which the complaint referred
ii. Date when the reminder sent, in case of no reply or non-compliance of the
instructions.
iii. Follow-up Activities on the matter to meet with realistic interpretation of
the matter
honour the queries; the following reports are prepared using the data form this register: -
a. List of cased on which the cases referred but report/reply not received
b. Statement of settled cases
c. Zone-wise/year-wise list of complaint cases
d. Current status on a particular complaint case
2.5.1 Drawbacks in handling of Misc. Complaint Cases
category of Miscellaneous Complaint Cases and keeping in view the expectations of
separate activities status is embedded under a single heading. For example, the
application referred to, the date of which it referred, reminder sent to referred
zone/person to respond, complaint settled, pending for reply, etc. It comes very
difficult to scrutinize and to count manually the cases, required to follow-up the
cases, settled and etc. When the management needs such sort of information; the
error on having a report. It consumes a lot of time when the activities are in bulk.

Some times, this column, under a particular row, is so filled that an additional
b. The observations on the column “Subject” is similar as recorded above. This
column also contains a lot of information that should be recorded under separate
columns to make the required information easy to access. The information like
name of the complainant, policy number on which the complaint is initiated,
complaint against to, nature of the complaint, etc is mentioned under one column.
On of the main drawback is that, when query is required on a particular policy
number; each and every row is scrutinized with laborious work to get the required
result.
In conclusion of our discussion, in chapter # 02, we have gone through whole of the
mechanism regarding track and trace system being done manually, keenly observed and
pointed out areas where work is to be done in the way to get right track towards objectives
as drawn in Chapter # 01. In the next chapter, we would come up with suggesting in shape
of proposed system that would take place of the existing system to get thing done better
and in fruitful way.

Department of Computer Sciences, Allama Iqbal Open University, Islamabad
MBA – IT Program, Report under Course “Software Project”, Code # 3419
Track and Trace System Ver 1.0.0
State Life Insurance Corporation of Pakistan, PHS – Department, Regional Office, Multan
 The objectives of the proposed system chalked out in the light of the
expectations of the user and with respect to the problem defined in
the result of existing system analysis
 System Proposal to be put for design keeping in view requirement
specifications, prototyping, proposed activities to be performed by
the system and having cost – benefit analysis to justify its feasibility
 The enlistment of benefits/main features in a dream of proposal
design chalked out in system proposal given for further proceedings.
 View to Main System Analysis Diagram that how it will act, once the
proposed system is designed and implemented.
C
H
A
P
T
E
R
0
3

32
Written & Composed By: Zafar Ahmad
Roll # L –519679, MBA – IT Program, Spring – 2004
3. Proposed System
To rectify the problems in existing system we intend to propose a system that actually
address the problem and provide a well managed system. Introducing the automated
system can solve the current problems, which is being faced by the user. The new system
will easily handle the problem of maintaining the records of files in transit of Regional
Office. The main Objective of the new system is to solve the problems in the current
system. Here are some points, which are being followed or fulfill by the new system. Here
are some points, which are being followed or fulfill by the new system.
3.1 Objectives
The proposed system shared formally defined and centrally controlled collection of data.
The system is infects collection of computer files that can be accessed easily and quickly
using different criteria as per required by the organization.
The main objectives are listed as under: -
• Data sharing can be easily and automatically
• User friendly system, and can be maintainable
• Stored records in less space as compare to the paper
• Security of data is the top priority
• Act as catalyst for Decision making process
• It provides environment in which all departments work in coordination through
whole of the fulfillment process.
• To address the queries promptly
• Fast file Tracking and Management of Record
• Lost of Policy files be minimized
• To provide a fully graphical window based application, to increase the user interest
and satisfaction.
• To provide good security of the information by applying the user authorization and
authentication.
• To reduce the paper cost.

33
3.2 Proposed System
In order to put the system proposal which should definitely meet the with the solution of
the defined problem in the prevision chapter(s); we have to go through the requirement
analysis, Types of requirements, coupled with the prototyping requirements as discussed
here as under: -
3.2.1 Requirement Specifications of the Proposed System
The proposal of an automated system can solve the current problems. The new system
will easily handle the problem of maintaining the records of Policy Files received in PHS
Department. The main Objective of the new system is to solve the problems in the current
system. Here are some points, which are being followed or fulfill by the new system.
• Provide a fully graphical window based application, to increase the user interest
and satisfaction.
• Provide good security of the information by applying the user authorization and
authentication.
• Reduce the paper cost.
• Reduce the time in re-enter the data at different places.
• Provide user-friendly environment that it will reduce the cost of training of the
user.
• To remove the data redundancy.
• To maintain up-to-date information.
3.2.2 Activities to be performed by the Proposed System
• It’s an old saying that “Time is Money” so new system should save that money for
the people who are interacting with the system.
• The new system will provide the quick and correct information to user.
• The new system will keep the record management of all the components like
Claims Cases, Duplicate Case etc.
• The new system will ensure to provide the consistent information to the user.
• The new system will be reliable.

34
• The new system will update and validate the records automatically.
• The new system should reduce the burden of record management by doing the
work automatically like serial no generation and date generation etc.
• The new system will generate different types of reports for the management.
• The new system will be user-friendly interface.
• The new system will reduce the paper work.
• The new system will be portable.
• Trouble shooting of the new system will be easy.
• The new system has to do some extra features like rebuilding of indexes.
• There should a feature of login and password.
Keeping all of the above features this shows we are looking for the perfect system.
Anybody who is related to the field of computer science knows that it is impossible to
make a Perfect system. Bugs are present in every system but it depends that how many
bugs are present in the system. It also depends that if the system is crashed than how
quickly system will recover. It is more important that which tools are used in the
development in the system. As we know that the current system is working manually so
the process of the information is unstructured, so the proposed system is dreamed that it
should be able to handle the information structurally.
3.2.3 Cost Benefit Analysis of Proposed System
Cost & Benefit Analysis is a relatively simple and widely used technique for deciding
whether to go for the system or not. As its name suggests, to use the technique simply add
up the value of the benefits of a course of action, and subtract the costs associated with it.
Costs are either one-off, or may be ongoing. Benefits are most often received over time. In
its simple form; cost/benefit analysis is carried out using only financial costs and financial
benefits.

35
SR.
#
Item
Description
Cost
Associated
Required
For Project
Remarks
01. Hardware Rs. 50,000/= Nil
Supplied by the Department as
already there, provide by their
Principal Office
02. Software Rs.30,000/= Nil
Already Purchased by the
Corporation and provided to this
Office. This software is used to
develop this Project
03. Training - Nil
As already trained personnel is
working there; however,
orientation training on the
system may be provided by the
developer.
TOTAL COST Rs. 80,000/= Nil
As the system is being
developed to meet the
obligation for MBA – IT
degree. Hence Free of Cost.
3.2.4 Data Flow Diagram (DFD)
To exhibit the requirements for the flow of data, we use data flow diagrams. Here again
hierarchy is expressed by layering, so that different levels of detail are shown in different
layers. We begin by considering the system as a transformer of data. We examine the data
that flows into the system, how it is transformed, and how it leaves the system. The
emphasis is on the flow of the data, not on the flow of control.
A DFD shows the flow of a data through a system. The system may be an organization, a
manual procedure, a software system, a mechanical system, a hardware system, or only
combination of these. A DFD shows the movement of data through the different
transformation or processes in the system. The processes are shown by named circles
(‘bubbles’) and named arrows entering or leaving the bubbles represent data flow. A
rectangle represents a source or sink, and is a net originator or consumer of data. A source
or a sink is typically outside the main system of study. [DFD can be shown in the
Appendices Section of this Report].
3.2.5 Prototyping Requirements
When a customer works with us to determine requirements, sometimes the customer is
uncertain of exactly what is required or needed. The requirement analysis may yield a

36
wish list of what the customer would like to see, but it is not clear whether the list is
complete. In some situations, customer or users are involved in the analysis and design
processes so those requirements can be modified as we examine available options. In other
cases, the customer knows what is needed or wanted, but we are not certain whether the
requirements are realistic.
Although a customers needs are stated in the requirements definition, the customer is
sometimes uncertain of details or options desired. By involving customers in design,
various requirements or situations are demonstrated and customers can choose among
them. For this reason, rapid prototyping is sometimes though of as a requirement
specification tool rather than as a design technique. In either case, rapid prototyping helps
us work with customer to determine what is really wanted or needed This is also taken into
account in the proposed system.
3.4 Benefits/Main Features of the Proposed System
• It is to store the information of each file received in the department
• It is helpful in tacking of the files and make access easy to physical searching of
the file
• The number of reports may be generated for quick decision-making.
• The information is accessible to those who need it at right time and right place.
• The system helps management policies and efficiency of the department.
• The proposed computerized system is easy to use and will save the labor time.
• The proposed computerized system is user friendly and will save the retrieving
information in time and space of information storage.
• The proposed computerized system will prevent error and provide information in a
form that makes it capable of being used.

 The input design, principles to follow for a concise, complete and
correct input design to come. Also some guidelines which are
required to follow in designing an input design
 The Output design, types of output prevailing in the current scenario
and number of devices through which output can be generated
 How coding should be done
 The database design, maintaining a database dictionary - the most
important component used in database applications. Entity –
Relationship Diagram and description of fields with there different
attributes. Hence complete system design is there for implementation
C
H
A
P
T
E
R
0
4

37
4. System Design
System Design consists of Input/Output Design, interface design and the most important
database design in case of database application. In this phase, a lot of work is required to be done
so that the design should be accurate and understandable to the extent if implemented works fine
with out any discrepancy encountered when put to the programmer to develop. For a good design
to come, these ingredients should be blend in their fine specifications; here we discuss one by
one: -
4.1 Input Design
Interface Design is composed of Input Design and Out Put Design. First, we will discuss the
Input Design. For this design, there is some list of consideration: -
• Use selection phase boundaries on DFD
• Review audience and purpose
• Review performance requirements
• Review security and control requirements
• Determine media
• Determine general format
• Design dialogue (if necessary)
• Prototype
The purpose of taking all these aspects into consideration is just to capture the data and get the
data into a format suitable for the Computer. Here are two methods: -
• Batch: Batch input involves collecting data via "source" documents, and periodically
keying or scanning them for entry into the system, one group or "batch" at a time.
• On-line: Online input involves capturing data at its point of origin and directly entering
the information into the system.

38
Human factor also implies that to what extent the laborious work has to be done by the operator.
Therefore, in designing of input it should be considered that minimum amount of volume of data
to be put by the system user that would lead to easy completion and rapid data entry.
4.1.1 Input Design Process
In the process of input design, we identify the input requirements of the new system and define
the basic contents in project repository. This leads to specify design parameters such as data
capture, data entry, and data input. Also we have to chalk out the sketch about prototype the
source document or input screens and layout the format of screens or batch input files using
either display layout charts or input layout charts, respectively. The next step is specify input
devices like: keyboard, pointing device, telephone key pad, optical readers and bar code
scanners, magnetic ink character recognition, magnetic disk, tape, stripe voice recognition,
punched cards .
In the choice of Media, we have Paper, Film, Video display and. In the design of input, there
apply some principles as under: -
4.1.2 General Principles of Input Design
A concrete input design is judged on the principle, if it is ensured that: -
• Minimize the volume of data by:
• Enter only variable data
• Do not input data that can be calculated or stored in computer programs
• Use codes for appropriate attributes
• Source documents should be easy to complete:
• Include instructions for completing the form
• Minimize the amount of handwriting

39
• Documents should be easily and quickly entered:
• Data to be entered (keyed) should be sequenced so it can be read top to bottom
and left to right.
• Portions of the form that are not to be input are placed in or about the lower right
portion of the source document.
• Internal Controls for Inputs:
• Monitor number and amount of transactions
• Make sure data is valid
• Completeness checks (required vs. optional)
• Limit and range checks
• Combination checks
• Self-checking digits
• Picture checks
• Provide usable error messages
• Input Forms Design:
• Do not assume forms cannot change
• Provide instructions
• Minimize handwriting
• Put administrative info at bottom of form
As for as proposed system is concerned, the input designed is chalked out in such a way that
input to the system will be passed on directly taken from the file received from the concerned
zone with the help of the covering letter contained therein. No separate form is designed for data
entry to the system. Normal Key board, Mouse is used as input devices.

40
4.2 Output Design
Generally, there are two types of output: -
• External outputs -- leave the system
• Internal outputs -- stay inside the system
In designing of output, it should be kept in mind that the output, usually in the form of a report,
should be readable, bounded to timeline, relevant and focused to the issue and more ahead
acceptable.
4.2.1 General Principles of Output Design
General Principles of output design comprises to: -
• Computer outputs should be simple to read and interpret.
• The timing of computer outputs is important
• The distribution of computer output must be sufficient to assist all relevant system users.
• The computer outputs must be acceptable to the system users who will receive them
Output Design Process starts with review of output requirements and then it is perceived that
how the output date-flow will be implemented. Prototype layout is designed using spreadsheets,
DBMS and 4th
Generation Tools. After doing this, report/output layouts are finalized i.e. printer
spacing chart, display layout charts. In output devices: printer, video devices, audio devices,
magnetic disk, tape, stripe computer output microfiche, microfilm is considered. The Format of
an output may comprise to Tabular, Grouped, Graphic or Narrative.

41
4.2.1 Guidelines for Output Design
In order to make the output complete, concise, correct, there are certain guidelines to follow: -
• Make simple to read and interpret
• Title, date, time
• Section headings
• Column headings
• Expanded codes
• Legends
• Use consistent labels, spacing, etc.
• Right information, right place, right time
In the proposed system, printer generated reports are designed as output. [Glimpses on Reports
can be seen in the Appendices Section]
4.3 Database Design
The first sight that attracts the user is the interface. Attractive and convenient interface keep the
user in touch with the system. The user finds get job done in an easy and simple way. Graphic
User Interface (GUI) plays an important role in making things quiet easy for the user. The
following are the most common elements used to attract the user in this system
Windows: The most pervasive element used in GUIs is the window. It could be considered to be
a metaphor for a "window" into the computer, but it is dependent on idioms for its operation. The
GUI paradigm, however, allowed for the user to see into multiple areas within the computer, and
the window metaphor was born. Visual Basic does well in developing such interface as Multi
Document Interface (MDI).

42
Events: An "event," with respect to user interfaces, is any function initiated by the user.
Selecting something from a pull-down menu, clicking a button or a checkbox, and closing a
window are all examples of events. By visually presenting all of the possible events to the user,
the need for a quick reference card vanished. Also, the advent of pointing devices such as the
mouse allowed entirely new kinds of events to be implemented, such as "drag and drop." It is a
common concept that events were born of the GUI age. So event driven programming is
designed in the Track and Trace System.
Pull-down Menus / Drop-down Menus: Pull-down menus are menus that the user can "pull
down" from the menu bar that traverses the top of the screen. On some platforms these are called
"drop down" menus because the user does not need to hold the mouse button down in order for
the menu to remain visible. Such interface is designed for the T&TS. MDI Form is such example
in this System
Command Buttons: A push button is simply a rectangle that appears on a panel with some sort
of label or icon inside it. The metaphor is to any button you'd find in the physical world, such as
on a calculator or telephone. Clicking on a command button will cause some sort of action will
occur. This button will be activated when the Enter key is pressed. This component is also
included in the designing of T&TS and most of the work is done through these buttons: like
navigation, save, edit, add etc.
Icons: Icons are small pictures that generally represent objects in the
physical world or are used for functions or actions. Icons can be
"clickable" and used to initiate an event. These are sometimes referred to
as "buttons," as they become hybrids of buttons and icons. The icon(s) are used as to present
System Logo, Command Button Pictures to facilitate navigation, Edit etc.

43
Radio Buttons: A radio button is small circle with some sort of label beside
it. A black dot inside the circle indicates that the button is selected. The
absence of a dot indicates that the button is unselected. When one button is
pushed in, whatever other button had been pushed in will pop out. In this way,
only one button can be pushed in at a time. Similarly, with the radio button form object, clicking
on one option will cause whatever other option that had been selected to become unselected. The
Radio button interface is designed to have a selection over Reference Number or Proposal/Policy
Number search in this Track and Trace System
Text Box: It is the most commonly used interface object. A text field is
simply a space in which the user can type text. Text fields are usually
contained within a rectangle, but it could just be space on a panel that can
accept text. Obviously, the Text Box(s) are used to contain data, show data and to pass on the
data to the database.
Labels: It is also most commonly used interface object. To mention caption of the Text Box and
to get the user recognized the purpose of the filed to which the label is associated, this object is
used so frequently.
Mask Box: In order to facilitate the user, Mask Edit Box is designed so that consistent data be
entered especially in Reference Number text box as RCC-____/____, Table/Term data entry,
Policy Number as _________-_ .
4.4 Database Design
With respect to the scope of the project database is designed keeping in view the normalization
of data, no redundancy, easy and fast access from the database and isolation of independent
multiple relationships. The elaboration on Data Dictionary is given as under: - [Entity –
Relationship Diagram (ERD) can be viewed in the Appendices Section of this report].

44
Table Name: ZoneOption
Table Purpose: To equip the user with the option to add new Zone Name, in case a new
Zone is created in the Organization and a policy file is received from such
Zone.
Associated Interface:
Table Name: CategoryOption
Table Purpose: To equip the user with the provision of option to add new Claim Category
in particular or type of complaint/proposal on the different kinds of files
which may receive other than the routine category type like: DEATH
CLAIM, ADB CLAIM, FIB CLAIM, etc.
SR.
#
Field Required
for / Needed
Field Attributes
Description
Name Type Size
Posi
tion
01.
To enlist the
number of
Category Type
CatgCode
Byte 1 0
This field is used to assign
unique number to a Category
Name Entered in the Table. This
number may also be called as
Serial Number for the new
entered category type.
SR.
#
Field
Required for /
Needed
Field Attributes
Description
Name Type Size Position
01.
Count for
number of
Zone(s) Name
are
entered/created
Zone
Code
Byte 1 0
This field is used to
assign unique number to a
Zone Name Entered in
the Table. This number
may also be called as
Serial Number for the
Zone Name.
02.
To enter the
Name of the
Zone
Zone
Name
Text 30 1
Name of the Zone like
MULTAN, SAHIWAL,
etc is saved in this field.

45
SR.
#
Field Required
for / Needed
Field Attributes Description
02.
To enter the
Name of the
Category Type
CatgType
Text 30 1
This field holds the name
assigned to the category to
which nature of the file pertains
to
Associated Interface: FrmClaimCategory
Table Name: ActionOption
Table Purpose: To facilitate with the provision of option to add as many unique number of
actions, which are, required to take on any one type of file. This will
provide a list of actions to choose the appropriate one instead on
developing the new wording each time to take similar kind of action. For
example; the Action UNDER PROCESS may also be written as FILE IS
UNDER PROCESS, UNDER CONSIDERATION. Although the meaning
of these is somewhat the same but different wording may lead to
inconsistency of data. To remove this discrepancy, this table is design to
provide the list of actions taken so for and to add any new one different to
the prevailing options.
SR.
#
Field Required for /
Needed
Field Attributes
Description
01.
To enlist the number
of Action/Status
ActionCode
Byte 1 0
This field is used to
assign unique number
to a Action/Status
Entered in the Table.
This number may also
be called as Serial
Number for the new
entered Action/ Status
02.
To enter the Action/
Status wording
ActionName
Text 50 1
This field holds the
actual wording given to
Action/ Status to which
nature of Action
performed.
Associated Interface: FrmActionOption

46
Table Name: ClaimMasterFile
Table Purpose: This table is design to store the particulars of each and every policy file
received for decision of Regional Claims Committee. The fields of this
table are taken in such a way that necessary particulars from such file are
recorded permanently and easily traceable even file is attempted to record
with change of cover over lapse of considerable time. This Table is treated
as Master Table for each type claim cases.
SR.
#
Field Required for /
Needed
Field Attributes
Description
01.
To assign unique
serial number to each
claim file received for
decision of claims
committee
ReferenceNumber
Text 13 0
The
format
of
this
serial
number
is
designed
as
RCC-serial
number/year;
here
RCC
is
taken
with
respect
to
Regional
Claims
Committee,
serial
number
represents
the
sequence
of
files
received.
It
is
taken
as
four-character
digit
(e.g.
0001).
The
year
represents
the
current
year
in
which
file
received.
(e.g.
four
character
like
2004)
02.
To regard the case
with respect to the
unique policy number
available from the file
received for decision
PolicyNumber
Text 11 1
This
is
a
unique
number
which
is
given
to
each
policy
when
the
policy
is
issued.
All
the
record
of
the
life
proposed
is
maintained
against
this
unique
number.
This
is
an
10
digit
number
with
the
digit
code
bears
format
like
000000000-0

47
03.
To record the Name
of the Life Insured
i.e. the name of the
person to whom the
policy is issued/ life
risk covered
Policyholder
Text 35 2
This
name
is
taken
from
the
policy
file
received.
As
Death
Claim
is
concerned,
the
name
of
the
policyholder
is
now
termed
as
Name
of
the
Deceased.
04.
To record the amount
of the life risk
coverage
SumAssured
Long 4 3
This
figure
is
taken
from
the
policy
file
that
represents
the
amount
for
which
the
life
risk
is
covered.
Typically,
it
is
termed
as
“
Sum
Assured”
.
05.
To record the Table
of the policy contract
Table
Text 2 4 In
common
understanding,
it
is
called
the
product
ID.
There
are
a
number
of
policy
plans
to
offer.
The
Corporation
has
given
a
unique
number
to
each
of
its
policy
plan
i.e.
product
regarded
as
Table
number.
This
information
is
also
extracted
from
the
policy
file.
06.
To record the total
period for which life
risk is covered
Term
Text 2 5
This
figure
represents
the
total
number
of
years
for
which
the
life
risk
is
covered;
e.g.
10,
15,
20
years
etc.

48
07.
To record the name
of the Zone from the
policy file is
received.
Zone
Text 15 6
Obviously,
this
re-
presents
the
name
of
the
concerned
Zone
within
the
jurisdiction
of
respective
Region,
from
the
policy
file
pertains
to.
08.
To record the type of
the claim on which
the decision is
required.
ClaimCategory
Text 15 7
As
within
the
portfolio
of
Regional
Claims
Committee,
there
may
come
different
sort
of
claims
like
DEATH
CLAIM,
AIB
CLAIM,
etc.
In
order
to
make
distinguish,
a
field
is
defined
to
record
the
category
of
the
claim.
The
type
of
the
claim
is
extracted
from
the
request
of
the
ZCC
placed
in
the
policy
file.
09.
To record the date
when the policy file
is received in the
PHS – Department.
FileReceivedOn
Text 10 8
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
file
is
received
and
Reference
number
is
issued.
This
makes
helpful
in
evaluating
that
how
much
time
spent
to
take
the
decision
with
the
comparison
of
date
of
return
of
the
policy
file.

49
10.
To record the date
when the policy file
is returned after
necessary work done.
FileReturnedOn
Text 10 9
This
date
represents
the
dated
when
the
file
dispatched
to
the
desired
destination
or
returned
to
the
concerned
Zone
after
the
decision
of
RCC.
The
difference
of
period
between
the
dated
received
and
returned
presents
the
time
period
for
the
policy
file
held
with
this
office.
11.
To record the
decision of the RCC
in precise wording
Decision
Text 25 10
This
field
is
designed
to
record
the
to-the-
point
decision
of
RCC
over
a
particular
case.
On
the
Update
Form,
Radio
Buttons
are
used
to
pass
the
data
in
this
field.
12.
To record the last
performed action on
the file
ActionTaken
Text 50 11
From
receipt
of
the
file
to
dispatch
of
the
file;
there
may
be
number
of
actions
taken
on
it.
To
record
the
Last
performed
action
is
stored
in
this
field.
It
also
serves
the
purpose
of
the
Latest
Status
on
the
File
with
respect
to
the
process
in
PHS
Department.
A
combo
box
is
used
with
a
number
of
list
options
available
there
and
an
appropriate
is
picked.
Associated Interface: FrmClaimMasterFile

50
Table Name: ProposalMsterFile
Table Purpose: This table is designed to store basic information relating to proposal file(s)
received for decision of Regional Underwriting Committee. The
information is taken as master record on a particular proposal file. The
structure of the table is described as under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type Size
Posi
tion
01.
To assign unique
serial number to
each proposal file
received for
decision of claims
committee
ReferenceNumber
Text 13 0
The
format
of
this
serial
number
is
designed
as
RUC-serial
number/year;
here
RUC
is
taken
with
respect
to
Regional
Underwriting
Committee,
serial
number
represents
the
sequence
of
files
received.
It
is
taken
as
four-
character
digit
(e.g.
0001).
The
year
represents
the
current
year
in
which
file
received.
(e.g.
four
character
like
2004)
02.
To record the case
with respect to the
unique proposal
number available
from the file
received for
decision
ProposalNumber
Text 12 1
This
is
a
unique
number
which
is
given
to
each
proposal
when
the
proposal
is
received
at
Zonal
Level..
This
number
is
then
converted
into
policy
number
if
the
proposal
is
accepted
by
RUC.
The
first
two
digits
represents
the
zone
code,
middle
part
of
the
format
is
used
for
sequence
number
of
the
proposal
received
and
the
remaining
part
is
used
to
represent
two
digit
year
to
which
the
proposal
pertains.
The
format
is
composed
00-
0000000-00

51
03.
To record the Name
of the Life
proposed
LifeProposed
Text 35 2
This
name
is
taken
from
the
proposal
file
received.
It
is
the
name
of
the
person
who
intends
to
get
life
insurance
coverage
04.
To record the
amount of the life
risk coverage
SumAssured
Long 4 3
This
figure
is
taken
from
the
proposal
form
that
represents
the
amount
for
which
the
life
risk
needs
to
be
covered.
Typically,
it
is
termed
as
“
Sum
Assured”
.
05.
To record the Table
of the proposed
policy plan
Table
Text 2 4
In
common
understanding,
it
is
called
the
product
ID.
There
are
a
number
of
policy
plans
to
offer.
The
Corporation
has
given
a
unique
number
to
each
of
its
policy
plan
i.e.
product
regarded
as
Table
number.
This
information
is
also
extracted
from
the
policy
file.
06.
To record the total
period for which
life risk is required
to be covered
Term
Text 2 5
This
figure
represents
the
total
number
of
years
for
which
the
life
risk
is
required
to
be
covered;
e.g.
10,
15,
20
years
etc.

52
07.
To record the name
of the Zone from
the proposal file is
received.
Zone
Text 15 6
Obviously,
this
represents
the
name
of
the
concerned
Zone
within
the
jurisdiction
of
respective
Region,
from
the
proposal
file
pertains
to.
08.
To record the date
when the proposal
file is received in
the PHS –
Department.
FileReceivedOn
Text 10 7
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
file
is
received
and
Reference
number
is
issued.
This
makes
helpful
in
evaluating
that
how
much
time
spent
to
take
the
decision
with
the
comparison
of
date
of
return
of
the
proposal
file.
09.
To record the date
when the proposal
file is returned after
necessary work
done.
FileReturnedOn
Text 10 8
This
date
represents
the
dated
when
the
file
is
dispatched
to
the
desired
destination
or
returned
to
the
concerned
Zone
after
the
decision
of
RUC.
The
difference
of
period
between
the
dated
received
and
returned
presents
the
time
period
for
the
policy
file
held
with
this
office.

53
10.
To record the
decision of the
RUC in precise
wording
DecisionOnProposal
Text 15 9
This
field
is
designed
to
record
the
to-the-point
decision
of
RUC
over
a
particular
case.
On
the
Update
Form,
Radio
Buttons
are
used
to
pass
the
data
in
this
field.
11.
To record the last
performed action on
the file
ActionTaken
Text 50 10
From
receipt
of
the
file
to
dispatch
of
the
file;
there
may
be
number
of
actions
taken
on
it.
To
record
the
Last
performed
action
is
stored
in
this
field.
It
also
serves
the
purpose
of
the
Latest
Status
on
the
File
with
respect
to
the
process
in
PHS
Department.
A
combo
box
is
used
with
a
number
of
list
options
available
there
and
an
appropriate
is
picked.
Index Name: IdxRef
Primary Key ReferenceNumber
Associated Interface Form: FrmProposalCaseEntry

54
Table Name: DuplicatePolicyMasterFile
Table Purpose: This table is designed to store basic information relating to the case
received for approval of creation of duplicate policy file. The
information is taken as master record on a particular policy file. The
structure of the table is described as under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type Size
Positio
n
01.
To assign unique
serial number to
each case which is
received for
approval of
duplicate file
creation.
DupPolicyRefNo
Text 13 0
The
format
of
this
serial
number
is
designed
as
DUP-serial
number/year;
here
DUP
is
taken
with
respect
to
duplicate
file
creation,
serial
number
represents
the
sequence
of
files/cases
received.
It
is
taken
as
four-character
digit
(e.g.
0001).
The
year
represents
the
current
year
in
which
file
received.
(e.g.
four
character
like
2004)
02.
To record the case
with respect to the
unique policy
number available
from the file
received for
approval.
DupPolicyFileNumber
Text 11 1
This
is
a
unique
number
which
is
given
to
each
policy
when
the
policy
is
issued.
All
the
record
of
the
life
insured
is
maintained
against
this
unique
number.
This
is
an
10
digit
number
with
the
digit
code
bears
format
like
000000000-0
03.
To record the Name
of the policy owner
DupPolicyholder
Text 35 2
This
name
is
taken
from
the
policy
file
received.
This
represents
the
name
of
the
policyholder
whose
life
risk
is
covered.

55
04.
To record the
amount of the life
risk coverage
DupSumAssured
Long 4 3
This
figure
is
taken
from
the
policy
file
that
represents
the
amount
for
which
the
life
risk
is
covered.
Typically,
it
is
termed
as
“
Sum
Assured”
.
05.
To record the Table
of the policy plan
DupTable
Text 2 4
In
common
understanding,
it
is
called
the
product
ID.
There
are
a
number
of
policy
plans
to
offer.
The
Corporation
has
given
a
unique
number
to
each
of
its
policy
plan
i.e.
product
regarded
as
Table
number.
This
information
is
also
extracted
from
the
policy
file.
06.
To record the total
risk overage is
given.
DupTerm
Text 2 5
This figure represents
the total number of
years for which the life
risk is covered; e.g. 10,
15, 20 years etc.
07.
To record the name
of the Zone from
the file is received.
DupZone
Text 15 6
Obviously,
this
represents
the
name
of
the
concerned
Zone
within
the
jurisdiction
of
respective
Region,
from
the
policy
file
pertains
to.

56
08.
To record the date
when the life risk
coverage
commences.
DupDateCommence
Text 10 7
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
policy
risk
coverage
commences.
Typically
this
dated
is
regarded
as
date
of
commencement.
09.
To record the date
when the file is
received in the PHS
– Department.
DupFileReceivedOn
Text 10 8
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
file
is
received
and
Reference
number
is
issued.
This
makes
helpful
in
evaluating
that
how
much
time
spent
to
take
the
decision
with
the
comparison
of
date
of
return
of
the
proposal
file.
10.
To record the date
when the file is
returned after
necessary work
done.
DupFileReturnedOn
Text 10 9
This
date
represents
the
dated
when
the
file
is
dispatched
to
the
desired
destination
or
returned
to
the
concerned
Zone
after
having
decision
of
competent
authority.
The
difference
of
period
between
the
dated
received
and
returned
presents
the
time
period
for
the
policy
file
held
with
this
office.
11.
To record the
decision of the
competent authority
in precise wording
DupFileDecision
Text 15 10
This
field
is
designed
to
record
the
to-the-
point
decision
to
approve
or
reject
the
case
for
duplicate
file
creation
On
the
Update
Form,
Radio
Buttons
are
used
to
pass
the
data
in
this
field.

57
12.
To record the last
performed action on
the file
DupActionTaken
Text 50 11
From
receipt
of
the
file
to
dispatch
of
the
file;
there
may
be
number
of
actions
taken
on
it.
To
record
the
Last
performed
action
is
stored
in
this
field.
It
also
serves
the
purpose
of
the
Latest
Status
on
the
File
with
respect
to
the
process
in
PHS
Department.
A
combo
box
is
used
with
a
number
of
list
options
available
there
and
an
appropriate
is
picked.
Index Name: DupPolicy
Primary Key DupPolicyFileNumber
Index Name: DupRefNo
Foreign Key DupPolicyRefNo
Associated Interface Form: FrmDuplicateCase
Table Name: ClaimInvCaseMasterFile
Table Purpose: This table is designed to store basic information relating to the case
received for death claim investigation purpose. The information is
taken as master record on a particular policy file. The structure of
the table is described as under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type
Siz
e
Position
01.
To assign unique
serial number to
each case which is
received for death
claim investigation
InvPolicyRefNo
Text 13 0
The
format
of
this
serial
number
is
designed
as
INV-serial
number/year;
here
INV
is
taken
with
respect
to
nature
of
work
i.e.
investigation,
serial
number
represents
the
sequence
of
files/cases
received.
It
is
taken
as
four-character
digit
(e.g.
0001).
The
year
represents
the
current
year
in
which
file
received.
(e.g.
four
character
like
2004)

58
02.
To record the case
with respect to the
unique policy
number available
from the file
received for
investigation.
InvPolicyFileNumber
Text 11 1
This
is
a
unique
number
which
is
given
to
each
policy
when
the
policy
is
issued.
All
the
record
of
the
life
insured
is
maintained
against
this
unique
number.
This
is
an
10
digit
number
with
the
digit
code
bears
format
like
000000000-0
03.
To record the Name
of the policy owner
InvPolicyholder
Text 35 2
This
name
is
taken
from
the
policy
file
received.
This
represents
the
name
of
the
policyholder
whose
life
risk
is
covered.
04.
To record the
amount of the life
risk coverage
InvSumAssured
Long 4 3
This
figure
is
taken
from
the
policy
file
that
represents
the
amount
for
which
the
life
risk
is
covered.
Typically,
it
is
termed
as
“
Sum
Assured”
.
05.
To record the Table
of the policy plan
InvTable
Text 2 4
In
common
understanding,
it
is
called
the
product
ID.
There
are
a
number
of
policy
plans
to
offer.
The
Corporation
has
given
a
unique
number
to
each
of
its
policy
plan
i.e.
product
regarded
as
Table
number.
This
information
is
also
extracted
from
the
policy
file.

59
06.
To record the total
risk overage is
given.
InvTerm
Text 2 5
This
figure
represents
the
total
number
of
years
for
which
the
life
risk
is
covered;
e.g.
10,
15,
20
years
etc.
07.
To record the name
of the Zone from
the file is received.
InvZone
Text 15 6
Obviously,
this
represents
the
name
of
the
concerned
Zone
within
the
jurisdiction
of
respective
Region,
from
the
policy
file
pertains
to.
08.
To record the date
when the life risk
coverage
commences.
InvDateCommence
Text 10 7 This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
policy
risk
coverage
commences.
Typically
this
dated
is
regarded
as
date
of
commencement.
09.
To record the date
when the file is
received in the PHS
– Department.
InvFileReceivedOn
Text 10 8
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
file
is
received
and
Reference
number
is
issued.
This
makes
helpful
in
evaluating
that
how
much
time
spent
to
accomplish
the
task
with
the
comparison
of
date
of
return
of
the
proposal
file.

60
10.
To record the date
when the file is
returned after
necessary work
done.
InvFileRetrunedOn
Text 10 9
This
date
represents
the
date
when
the
file
is
dispatched
to
the
desired
destination
or
returned
to
the
concerned
Zone
after
having
investigation
report
from
the
claim
investigator.
The
difference
of
period
between
the
date
received
and
returned
presents
the
time
period
for
the
policy
file
held
with
this
office.
11.
To record the status
on investigation in
transit.
InvFileDecision
Text 15 10
This
field
is
designed
to
record
the
to-the-point
description
to
get
the
investigation
report
and
dispatch
to
the
destination.
On
the
Update
Form,
Radio
Buttons
are
used
to
pass
the
data
in
this
field.
12.
To record the last
performed action on
the file
InvActionTaken
Text 50 11
From
receipt
of
the
file
to
dispatch
of
the
file;
there
may
be
number
of
actions
taken
on
it.
To
record
the
Last
performed
action
is
stored
in
this
field.
It
also
serves
the
purpose
of
the
Latest
Status
on
the
File
with
respect
to
the
process
in
PHS
Department.
A
combo
box
is
used
with
a
number
of
list
options
available
there
and
an
appropriate
is
picked.
Index Name: InvPolicy
Primary Key InvPolicyFileNumber
Index Name: InvRefNo
Foreign Key InvPolicyRefNo
Associated Interface Form: FrmInestigationCaseEntry

61
Table Name: MiscComplaintMasterFile
Table Purpose: This table is designed to store basic information relating to the
Misc. Complaint cases received from the policyholders pertaining to
the matter of Policyholder Services. From the complaint, basic
information is extracted and recorded using the structure of this
table. The information is taken as master record on a particular
complaint. The structure of the table is described as under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type
Siz
e
Position
01.
To assign unique
serial number to
each complaint
received in the
deptt.
MiscReferenceNumber
Text 14 0
The
format
of
this
serial
number
is
designed
as
MISC-serial
number/year;
here
MISC
is
taken
with
respect
to
nature
of
work
i.e.
Miscellaneous
complaint,
serial
number
represents
the
sequence
of
files/cases
received.
It
is
taken
as
four-
character
digit
(e.g.
0001).
The
year
represents
the
current
year
in
which
file
received.
(e.g.
four
character
like
2004)
02.
To record the case
with respect to the
unique policy
number available in
the complaint
lodged by the
policyholder.
MiscPolicyNumber
Text 11 1
This
is
a
unique
number
which
is
given
to
each
policy
when
the
policy
is
issued.
All
the
record
of
the
life
insured
is
maintained
against
this
unique
number.
This
is
an
10
digit
number
with
the
digit
code
bears
format
like
000000000-0.
The
complainant
refers
this
number
in
his/her
complaint.

62
03.
To record the Name
of the policy owner
Miscpolicyholder
Text 35 2
This
name
is
taken
from
the
complaint.
Generally,
the
name
of
the
complainant
is
the
name
of
the
policyholder.
04.
To record Nature of
the Complaint.
MiscComplaintNature
Text 35 3
Here,
the
nature
of
the
complaint
is
mentioned
like
Surrender
Value,
Loan
Calculation,
Premium
embezzlement
etc.
05.
To record the name
of the
person/official/depa
rtment to which the
file pertains i.e.
entity against which
the complaint is
lodged.
MiscComplaintAgainst
Text 35 4
This
field
is
used
to
focus
on
the
official/department
to
which
the
matter
pertains;
e.g.
LOAN
SECTION,
SEURRENDER
SECTION,
REVIVAL
SECTION,
DEATH
CLAIM,
Incharge
–
Revival
Section,
etc.

63
06.
To record the name
of the Zone to
which complaint
pertains.
Zone
Text 15 5
Obviously,
this
represents
the
name
of
the
concerned
Zone
within
the
jurisdiction
of
respective
Region,
from
the
policy
file
pertains
to,
on
which
the
complaint
is
lodged.
07.
To record the date
when the complaint
is received in the
PHS – Department.
FileReceivedOn
Text 10 6
This
represents
the
date
(the
format
is
dd-mm-yyyy)
when
the
file
is
received
and
Reference
number
is
issued.
This
makes
helpful
in
evaluating
that
how
much
time
spent
to
address
the
genuine
grievances
of
the
complaints
in
comparison
with
the
disposed
off
date
or
settled
date.
08.
To record the date
when the matter is
settled or disposed
off.
DisposedOn
Text 10 7
This
date
represents
the
date
when
the
complaint
is
settled/disposed
off
or
genuine
grievances
of
the
complainant.
The
difference
of
period
between
the
date
received
and
disposed
off
dated
presents
the
time
period
taken
to
settle
things
amicably.
09.
To record the status
on compliant with
respect to the
grievances.
Decision
Text 15 8
This
field
is
designed
to
record
the
to-the-
point
description
to
record
the
decision
on
the
complaint
like:
Pending,
Disposed
Off,
Settled,
Follow-
Up
etc.

64
10.
To record the last
performed action on
the case.
ActionTaken
Text 50 9
From
receipt
of
the
complaint
to
dispose
off;
there
may
be
number
of
actions
taken
on
it.
To
record
the
Last
performed
action
is
stored
in
this
field.
It
also
serves
the
purpose
of
the
Latest
Status
on
the
File
with
respect
to
the
process
in
PHS
Department.
A
combo
box
is
used
with
a
number
of
list
options
available
there
and
an
appropriate
is
picked.
Index Name: idxpolicy
Primary Key MiscPolicyNumber
Index Name: idxreference
Foreign Key MiscReferenceNumber
Associated Interface Form: frmMiscComplaintCase
Table Name: ClaimSummary
Table Purpose: This table is designed to record activity-to-activity performed steps
in process of Decision on the Claim File. This table has relation
with the Claim Master File. This information is treated as
Notes/Summary on the step-by-step actions performed until the file
is sent to destination. The structure of the table is described as
under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type Size
Positio
n
01.
To record the policy
number against with
the action is
required to be
recorded. This
policy number will
make a reference to
the record available
in the concerned
master table.
PolicyNumber
Text 11 0
This is the same
number as recorded in
the related claim master
file. This filed is taken
here to make
relationship as one-to-
many related with the
basic record stored in
concerned master data
file.

65
02.
To record the date
on which the action
is taken
ActionDate
Text 10 1
This represents the date
in the format (dd-mm-
yyyy) when the
specified action is
taken.
03.
To record the
narration/decryption
of the action
performed on a
particular case. ActionNotes
Text 70 2
Actually, this field
stores the description or
records the minutes on
the activity performed
on the file. These are
termed as “Notes or
Case History” reflects
the performed activity-
to-activity notes on the
file/case.
Index Name: ClaimSummaryPolicyNumber
Primary Key PolicyNumber
Associated Interface Form: FrmClaimUpdate
Table Name: ProposalSummary
in process of Decision on the Claim File. This table has relation
with the Claim Master File. This information is treated as
under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type Size
Positio
n
01.
To record the
proposal number
against with the
action is required to
be recorded. This
proposal number
will make a
reference to the
record available in
the concerned
master table.
ProposalNumber
Text 13 0
This
is
the
same
number
as
recorded
in
the
related
propsoal
master
file.
This
filed
is
taken
here
to
make
relationship
as
one-to-many
related
with
the
basic
record
stored
in
concerned
master
data
file.

66
02.
To record the date
on which the action
is taken
ActionDate
Text 10 1
This
represents
the
date
in
the
format
(dd-mm-
yyyy)
when
the
specified
action
is
taken.
03.
To record the
of the action
performed on a
particular case.
ActionNotes
Text 70 2
Actually,
this
field
stores
the
description
or
records
the
minutes
on
the
activity
performed
on
the
file.
These
are
termed
as
“
Notes
or
Case
History”
reflects
the
performed
activity-to-
activity
notes
on
the
file/case.
Index Name: ProposalNubmerSummary
Primary Key ProposalNumber
Associated Interface Form: FrmProposalUpdate
Table Name: DupSummary
in process of Decision on the Duplicate File Creation matter. This
table has relation with the Duplicate Master File. This information
is treated as Notes/Summary on the step-by-step actions performed
until the file is sent to destination. The structure of the table is
described as under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name Type Size
Positio
n
01.
number against with
the action is
required to be
recorded. This
policy number will
make a reference to
in the concerned
master table.
DupPolicyFileNumber
Text 11 0
This
is
the
same
number
as
recorded
in
the
related
duplicate
master
file.
This
filed
is
taken
here
to
make
relationship
as
one-
to-many
related
with
the
basic
record
stored
in
concerned
master
data
file.

67
02.
To record the date
on which the action
is taken
ActionDate
Text 10 1
This
represents
the
date
in
the
format
(dd-mm-
yyyy)
when
the
specified
action
is
taken.
03.
To record the
of the action
performed on a
particular case.
ActionNotes
Text 70 2
Actually,
this
field
stores
the
description
or
records
the
minutes
on
the
activity
performed
on
the
file.
These
are
termed
as
“
Notes
or
Case
History”
reflects
the
performed
activity-to-
activity
notes
on
the
file/case.
Index Name: DuplicateSummaryPolicyNumber
Primary Key DupPolicyFileNumber
Associated Interface Form: FrmDuplicateUpdate
Table Name: InvClaimSummary
in process of Investigation Claim Case. This table has relation with
the Investigation Master File. This information is treated as
under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name
Typ
e
Size
Positio
n
01.
number against with
the action is
required to be
recorded. This
policy number will
make a reference to
in the concerned
master table.
InvPolicyFileNumber
Text 11 0
This
is
the
same
number
as
recorded
in
the
related
Investigation
master
file.
This
filed
is
taken
here
to
make
relationship
as
one-
to-many
related
with
the
basic
record
stored
in
concerned
master
data
file.

68
02.
To record the date
on which the action
is taken
ActionDate
Text 10 1
This
represents
the
date
in
the
format
(dd-mm-yyyy)
when
the
specified
action
is
taken.
03.
To record the
of the action
performed on a
particular case.
ActionNotes
Text 70 2
Actually,
this
field
stores
the
description
or
records
the
minutes
on
the
activity
performed
on
the
file.
These
are
termed
as
“
Notes
or
Case
History”
reflects
the
performed
activity-to-activity
notes
on
the
file/case.
Index Name: InvestigationSummaryPolicyNumber
Primary Key InvPolicyFileNumber
Associated Interface Form: FrmInvUpdate
Table Name: MisSummary
in process of Miscellaneous Complaint Case. This table has relation
with the Misc. Case Master File. This information is treated as
under: -
SR.
#
Field Required for
/ Needed
Field Attributes
Description
Name
Typ
e
Size
Positio
n
01.
number against with
the action is
required to be
recorded. This
policy number will
make a reference to
in the concerned
master table.
MiscPolicyFileNumber
Text 11 0
This
is
the
same
number
as
recorded
in
the
related
Misc.
Master
file.
This
filed
is
taken
here
to
make
relationship
as
one-to-many
related
with
the
basic
record
stored
in
concerned
master
data
file.

69
02.
To record the date
on which the action
is taken
ActionDate
Text 10 1
This
represents
the
date
in
the
format
(dd-mm-yyyy)
when
the
specified
action
is
taken.
03.
To record the
of the action
performed on a
particular case.
ActionNotes
Text 70 2
Actually,
this
field
stores
the
description
or
records
the
minutes
on
the
activity
performed
on
the
file.
These
are
termed
as
“
Notes
or
Case
History”
reflects
the
performed
activity-to-activity
notes
on
the
file/case.
Index Name: MiscSummaryPolicyNumber
Primary Key MiscPolicyFileNumber
Associated Interface Form: FrmMiscUpdate

 The selection of programming language/ tool to develop the system
as proposed and designed keeping in view of the requirement of the
user.
 The database selection to support with the programming tool and
requirements of the security and accessibility approach of the user.
 Hardware put in operation to get find piece of blend of all ingredients
in shape of developed project.
 Reason(s) for selecting Language tool/Database/Hardware applied.
 Support from the customer in shape of logistic support, feasible
environment to work smoothly and with consistent peace of mind.
C
H
A
P
T
E
R
0
5

70
5. System Implementation
Once the system is proposed the software design phase have been accomplished, the
designer moves towards the development/implementation phase of software in accordance
with the proposed system and design specification. Here, we will discuss the tool used for
coding purpose and Database used, in particular to develop the project. However,
Hardware required also takes place in the scenario.
5.1 Programming Tool
Selection of the software for the development of the system is the most crucial stage of the
system design .The choice of the software tool is important and definitely depends upon
the problems in hand. After devoting a lot of time to this purpose, we agreed on the Visual
Basic6 to be quite appropriate for the proposed system. The programming is done using
the Visual Basic. Here is the answer for the decision implemented.
5.1.1 Why Visual Basic
The Visual Basic is a high performance language which support high level database i.e.
MS Access and MS SQL. The databases are mostly maintained by SQL, which is
conceded as the heart of the RDBMS. Its popularity is due to easy of use, flexibility and
capability.
5.1.2 Advantages of Visual Basic
There are quite a number of reasons for the enormous success of Visual Basic (VB):
• The structure of the Basic programming language is very simple, particularly as to
the executable code.
• VB is not only a language but also primarily an integrated, interactive development
environment ("IDE").
• The VB-IDE has been highly optimized to support rapid application development
("RAD"). It is particularly easy to develop graphical user interfaces and to connect
them to handler functions provided by the application.
• The graphical user interface of the VB-IDE provides intuitively appealing views
for the management of the program structure in the large and the various types of
entities (classes, modules, procedures, forms,).

71
• VB provides a comprehensive interactive and context-sensitive online help system.
• When editing program texts the "IntelliSense" technology informs you in a little
popup window about the types of constructs that may be entered at the current
cursor location.
• VB is a component integration language, which is attuned to Microsoft's
Component Object Model ("COM").
• COM components can be written in different languages and then integrated using
VB.
• Interfaces of COM components can be easily called remotely via Distributed COM
("DCOM"), which makes it easy to construct distributed applications.
• COM components can be embedded in / linked to your application's user interface
and also in/to stored documents (Object Linking and Embedding "OLE",
"Compound Documents").
• There is a wealth of readily available COM components for many different
purposes.
5.1.3 Prominent Features of Visual Basic
• Event Driven Programming: An event is an action recognized by a form, report or
control. When you want a form report or control to respond to an event in a
particular way you can write a Visual Basic Code for those events.
• Fast Processing: Visual Basic is the fastest and easiest way to create application
for MS windows. In Visual Basic we can develop more effective application in less
time.
• Multi Users Support: Visual Basic is design to allow users to share frequently use
programs and data thus decreasing memory, I/O cost and increasing throughput.
• Capabilities and Data Security: It provides advanced architecture maximizes
facilities to multi user transaction and protects our data from unauthorized access
using MS Access and SQL.
• Creating User Interface: The user interface is perhaps the most important part of
the application. The interface is the application they probably are not aware of the
code. That is executing behinds the scenes.
• Creating Menus with Menu Editor: Menus are one of the most important and
characteristic elements of the window user interface. Visual Basic provides an
efficient menu editor for designing menus.

72
• Create Toolbars: We can further enhance applications menu interface with
toolbars. Toolbars contains toolbar buttons, which provides quickly access to the
most frequently used commands in an application.
• Responding to Mouse and Keyboard Events: Visual Basic applications can
respond to a variety of mouse events and keyboard events, e.g. forms, reports,
picture box, and images control can detect the position of the mouse pointer, can
determine we there a left or right most button is being pressed and can respond to
different combinations of mouse buttons and shift, ctrl, alt keys.
• Forms and Controls: Forms and controls are basic building blocks use to create
the interface. Forms are objects that expose properties, which define their
appearance methods, which define their behavior and interaction events with the
user.
5.2 Database Selection
Selection of the database is as important and significant as the developing tool itself. There
are a number of database(s) available but the choice is MS – Access: Database provide by
Microsoft, to develop the designed system. Number of reasons can be put in favour of
selection of this database in shape of its nature and supporting capabilities with Visual
Basic – 6. Some of the key features that make it justified of selecting and implementation
is done, are elaborated as under:-
5.2.1 Features/Benefits of MS-Access
Sr.
#
Key Features Benefits
01. XML Support
In addition to being the standard technology for
interchanging data on the Web, Extensible Markup
Language (XML) is quickly becoming the preferred
technology for exchanging data between business software
applications. Microsoft Access 2002 provides powerful,
intuitive ways of sharing XML data regardless of differences
in the platform, data format, protocol, schema, or business
rules. By using Access' familiar user interface, you can easily
create XML data or schema documents from Jet or SQL
Server structures and data. You can also use XML data from
other applications in your forms, reports and data access
pages. For example, suppose your data is scattered across a
wide variety of sources — internal SQL servers, Excel
spreadsheets, and other data providers like SAP. Since these
sources use XML as their data interchange format, you could
create a series of aggregation queries in Access to pull this
data into views and then design forms and reports by using
those views.

73
02.
Extended Property
Support with
Microsoft SQL
Server 2000
The built-in integration between Microsoft Access 2002 and
Microsoft SQL Server 2000 has improved significantly by
the inclusion of support for extended SQL database
properties from within your Access project. By using
extended properties in your Access 2002 projects, you can
implement such features as lookup relationships, validation
rules (also called constraints), text formatting, and
subdatasheets. You can use extended properties with tables,
views, stored procedures, and functions, just like you can
with similar objects in Access data files. Using extended
properties makes it easy to save column widths, row heights,
fonts, and input mask settings from one Access project
session to another. Extended properties make it even easier
to migrate your business applications from Access databases
to Access projects connected to Microsoft SQL Server.
03.
Round-tripping
You can now work with and modify Access 2000 files in
Access 2002 without converting the file format. This allows
you to easily share different versions of database files with
other Access users.
04.
Multiple Undo and
Redo
You now have the ability to undo and redo multiple actions
in Design view in all objects in your Microsoft Access
databases and in views, stored procedures, and functions in
your Microsoft Access project.
05.
Batch Updates in
Access Projects
using Microsoft SQL
Server
You can now have Access 2002 projects batch all data entry
and send it to the server when the user navigates from a
record, closes a form, or selects a command. You can also
create a button on your form that saves all records or undoes
all changes to records, programmatically.
06.
Updateable Off-line
Data Access Pages
You can now take the data access pages in your Access
project offline, make changes to them on your laptop, and
have them automatically synchronize when you reconnect to
the SQL server. Changes to the off-line pages are made to an
Access project connected to a local Microsoft SQL Server
2000 Desktop Engine (formerly MSDE).
07.
Conversion Error
Logging
If problems are encountered when converting from Access
95 and later versions, Access 2002 will now create a table
that lists information about each error, making it much easier
to identify and solve problems.
08.
Subforms/Subreports
that Live in Design
view
You can now open subforms or subreports in their own
Design view window directly from within the form or report
or from the View menu. Scrolling has also been improved so
that it is easier to work with subforms and subreports in
Design view.
09.
Password Security in
an Access Project
You can now change the logon password specified in an
Access project connected to a Microsoft SQL Server 6.5 or
later version database directly from within your Access 2002
menu.

74
10.
The Linked Table
Wizard
The Linked Table Wizard guides you through the process of
linking your tables to a SQL Server database, and does this
all from within your Access project.
11.
Improved Support
for International
Complex-scripts
Access 2002 now exposes complex-script interface items
easily, which means that with a simple click, you can switch
the reading direction from left-to-right to right-to-left in
language-specific objects.
5.3 Hardware Used
With respect to the programming tool and database applied for the system development;
following hardware is put into operation to the get the work done. The Hardware profile
mentioned here as under is already available in the PHS – Department, Multan Region. So
there was no need of some thing extra to purchase for the proposed system as per design.
• PENTIUM – III 2.0 GHz
• WINDOWS XP [Licensed]
• Monitor IBM G74
• 128 MB RAM
• 40 GB HDD
• 1.44 FDD
• CD ROM Drive
• Key Board 104 Key
• Mouse A4 Tack
• Printer Cannon BJC – 4200
With help of all these ingredients, the proposed system is developed with out any
significant difficulty as the logistic support by the Department made it convenient to work
consistently with the added advantage of conducive environment in the office.

 The Principles of Testing and the methods available there to test the
software project.
 Strategies of the Testing like: Unit Testing, Integration Testing,
White Box Testing, etc
 To perform Test Code on the project and more than else test from the
hands of the customer on real valued data.
 The Use of Project Testing Report and analysis over there to come
across the conclusion about the performance, security, recovery, and
stress level testing aspect.
 Finally, to draw a conclusion of activities carried in testing project.
C
H
A
P
T
E
R
0
6

75
6. System Testing & Evaluation
Software has infiltrated almost all areas in the industry and has over the years become
more and more wide spread as a crucial component of many systems. System failure in
any industry can be very costly and in the case of critical systems (fight control, nuclear
reactor monitoring, medical applications, etc.) it can mean lost human lives. These "cost"
factors call for some kind of system failure prevention. One way to ensure system's
reliability is to extensively test the system. Since software is a system component, it
requires a testing process also.
Software testing is a critical component of the software engineering process. It is an
element of software quality assurance and can be described as a process of running a
program in such a manner as to uncover any errors. This process, while seen by some as
tedious, tiresome and unnecessary, plays a vital role in software development.
The process of software testing involves creating test cases to "break the system" but
before these can be designed, most of the following principles are observed before testing
of this software is commenced: -
6.1 Principles of Testing
• Testing should be based on user requirements. This is in order to uncover any
defects that might cause the program or system to fail to meet the client's
requirements.
• Testing time and resources are limited. Avoid redundant tests.
• It is impossible to test everything. Exhaustive tests of all possible scenarios are
impossible, simple because of the many different variables affecting the system
and the number of paths a program flow might take.
• Use effective resources to test. This represents use of the most suitable tools,
procedures and individuals to conduct the tests. The test team should use tools that
they are confident and familiar with. Testing procedures should be clearly defined.
Testing personnel may be a technical group of people independent of the
developers.
• Test planning should be done early. This is because test planning can begin
independently of coding and as soon as the client requirements are set.

76
• Testing should begin at the module. The focus of testing should be concentrated on
the smallest programming units first and then expand to other parts of the system.
We look at software testing in the traditional (procedural) sense and then describe some
testing strategies and methods used in Object Oriented environment. We also introduce
some issues with software testing in both environments.
6.2 Software Testing Methods
There are many ways to conduct software testing, but the most common methods rely on
the following steps.
6.2.1 Test Case Design
Test cases should be designed in such a way as to uncover quickly and easily as many
errors as possible. They should "exercise" the program by using and producing inputs and
outputs that are both correct and incorrect. Variables should be tested using all possible
values (for small ranges) or typical and out-of-bound values (for larger ranges). They
should also be tested using valid and invalid types and conditions. Arithmetical and logical
comparisons should be examined as well, again using both correct and incorrect
parameters. The objective is to test all modules and then the whole system as completely
as possible using a reasonably wide range of conditions.
6.2.2 White-Box Testing
White box method relies on intimate knowledge of the code and a procedural design to
derive the test cases. It is most widely utilized in unit testing to determine all possible
paths within a module, to execute all loops and to test all logical expressions.
Using white-box testing, the software engineer can: -
• Guarantee that all independent paths within a module have been exercised at least
once
• Examine all logical decisions on their true and false sides
• Execute all loops and test their operation at their limits; and
• Exercise internal data structures to assure their validity

77
This form of testing concentrates on the procedural detail. However, there is no automated
tool or testing system for this testing method. Therefore even for relatively small systems,
exhaustive white-box testing is impossible because of all the possible path permutations.
6.2.3 Basic Path Testing
Basis path testing is a white-box technique. It allows the design and definition of a basis
set of execution paths. The test cases created from the basis set allow the program to be
executed in such a way as to examine each possible path through the program by
executing each statement at least once.
To be able to determine the different program paths, the engineer needs a representation of
the logical flow of control.
6.2.4 Control Structure Testing
Condition testing can be utilized to design test cases which examine the logical conditions
in a program. It focuses on all conditions in the program and includes testing of both
relational expressions and arithmetic expressions. This can be accomplished using branch
testing and/or domain testing methods. Branch testing executes both true and false
branches of a condition. Domain testing utilizes values on the left-hand side of the relation
by making them greater than, equal to and less then the right-hand side value. This method
test both values and the relation operators in the expression. Data flow testing method is
effective for error protection because it is based on the relationship between statements in
the program according to the definition and uses of variables. Loop testing method
concentrates on validity of the loop structures.
6.2.5 Black-Box Testing
Black box on the other hand focuses on the overall functionality of the software. That is
why it is the chosen method for designing test cases used in functional testing. This
method allows the functional testing to uncover faults like incorrect or missing functions,
errors in any of the interfaces, errors in data structures or databases and errors related to
performance and program initialization or termination.

78
To perform successful black-box test, the relationships between the many different
modules in the system model need to be understood. Next, all necessary ways of testing all
object relationships need to be defined. For this, a graph representing all the objects can be
constructed. Each object is represented by a node and then links between the nodes show
the direct node-to-node relationship. An arrow on the link shows the direction of the
relationship. Each node and link is the further described by node weight or link weight
respectively. This method is called graph-based testing
6.3 Software Testing Strategies
In order to conduct a proper and thorough set of tests, the types of testing mentioned
below should be performed in the order in which they are described. However, some
system or hardware can happen concurrently with software testing.
6.3.1 Unit Testing
Unit testing procedure utilizes the white-box method and concentrates on testing
individual programming units. These units are sometimes referred to as modules or atomic
modules and they represent the smallest programming entity. Unit testing is essentially a
set of path test performed to examine the many different paths through the modules. These
types of tests are conducted to prove that all paths in the program are solid and without
errors and will not cause abnormal termination of the program or other undesirable results.
6.3.2 Integration Testing
Integration testing focuses on testing multiple modules working together. Two basic types
of integration are usually used: top-down or bottom up.
Top down, as the term suggests, starts at the top of the program hierarchy and travels
down its branches. This can be done in either depth-first (shortest path down to the deepest
level) or breadth-first (across the hierarchy, before proceeding to the next level). The main
advantage of this type of integration is that the basic skeleton of the program/system can
be seen and tested early. The main disadvantage is the use of program stubs until the
actual modules are written. This basically limits the up-flow of information and therefore
does not provide for a good test of the top level modules.

79
Bottom-up type of integration has the lowest level modules built and tested first on
individual bases and in clusters using test drivers. This insures each module is fully tested
before it utilized by its calling module. This method has a great advantage in uncovering
errors in critical modules early. Main disadvantage is the fact that most or many modules
must be build before a working program can be presented.
Integration testing procedure can be performed in three ways: Top-down, Bottom-up, or
using an approach called "Big-Bang"
• Top-Down Strategy: Top down integration is basically an approach where
modules are developed and tested starting at the top level of the programming
hierarchy and continuing with the lower levels. It is an incremental approach
because we proceed one level at a time. It can be done in either "depth" or
"breadth" manner. Depth means we proceed from the top level all the way down
to the lowest level. Breadth, on the other hand, means that we start at the top of the
hierarchy and then go to the next level. We develop and test all modules at this
level before continuing with another level. Either way, this testing procedure
allows us to establish a complete skeleton of the system or product. The benefits of
Top-down integration are that, having the skeleton, we can test major functions
early in the development process. At the same time we can also test any interfaces
that we have and thus discover any errors in that area very early on. But the major
benefit of this procedure is that we have a partially working model to demonstrate
to the clients and the top management. This of course builds everybody’s
confidence not only in the development team but also in the model itself. We have
something that proves our design was correct and we took the correct approach to
implement it. However, there are some drawbacks to this procedure as well: Using
stubs does not permit all the necessary upward data flow. There is simply not
enough data in the stubs to feed back to the calling module. As a result, the top
level modules can not be really tested properly and every time the stubs are
replaced with the actual modules, the calling modules should be re-tested for
integrity again.
• Bottom-Up Strategy: Bottom-up approach, as the name suggests, is the opposite
of the Top-down method. This process starts with building and testing the low
level modules first, working its way up the hierarchy. Because the modules at the
low levels are very specific, we may need to combine several of them into what is
sometimes called a cluster or build in order to test them properly. Then to test these
builds, a test driver has to be written and put in place. The advantage of Bottom-up
integration is that there is no need for program stubs as we start developing and
testing with the actual modules. Starting at the bottom of the hierarchy also means
that the critical modules are usually build first and therefore any errors in these
modules are discovered early in the process. As with Top-down integration, there
are some drawbacks to this procedure. In order to test the modules we have to
build the test drivers which are more complex than stubs. And in addition to that

80
they themselves have to be tested. So more effort is required. A major
disadvantage to Bottom-up integration is that no working model can be presented
or tested until many modules have been built. This also means that any errors in
any of the interfaces are discovered very late in the process.
• Big-Bang Strategy: Big-Bang approach is very simple in its philosophy where
basically all the modules or builds are constructed and tested independently of each
other and when they are finished, they are all put together at the same time. The
main advantage of this approach is that it is very quick as no drivers or stubs are
needed, thus cutting down on the development time. However, as with anything
that is quickly slapped together, this process usually yields more errors than the
other two. Since these errors have to be fixed and take more time to fix than errors
at the module level, this method is usually considered the least effective. Because
of the amount of coordination that is required it is also very demanding on the
resources. Another drawback is that there is really nothing to demonstrate until all
the modules have been built and integrated.
6.3.3 Function Testing
Function testing is a testing process that is black-box in nature. It is aimed at examining
the overall functionality of the product. It usually includes testing of all the interfaces and
should therefore involve the clients in the process. Because every aspect of the software
system is being tested, the specifications for this test should be very detailed describing
who, where, when and how will conduct the tests and what exactly will be tested. The
portion of the testing that will involve the clients is usually conducted as an alpha test
where the developers closely monitor how the clients use the system. They take notes on
what needs to be improved.
6.3.4 System Testing
Final stage of the testing process should be System Testing. This type of test involves
examination of the whole computer system. All the software components, all the hardware
components and any interfaces. The whole computer based system is checked not only for
validity but also for met objectives. It should include recovery testing, security testing,
stress testing and performance testing.
• Recovery testing uses test cases designed to examine how easily and completely
the system can recover from a disaster (power shut down, blown circuit, disk crash,
interface failure, insufficient memory, etc.). It is desirable to have a system capable
of recovering quickly and with minimal human intervention. It should also have a

81
log of activities happening before the crash (these should be part of daily
operations) and a log of messages during the failure (if possible) and upon re-start.
• Security testing involves testing the system in order to make sure that unauthorized
personnel or other systems cannot gain access to the system and information or
resources within it. Programs that check for access to the system via passwords are
tested along with any organizational security procedures established.
• Stress testing encompasses creating unusual loads on the system in attempts to
break it. System is monitored for performance loss and susceptibility to crashing
during the load times. If it does crash as a result of high load, it provides for just
one more recovery test.
• Performance testing involves monitoring and recording the performance levels
during regular and low and high stress loads. It tests the amount of resource usage
under the just described conditions and serves as basis for making a forecast of
additional resources needed (if any) in the future. It is important to note that
performance objectives should have been developed during the planning stage and
performance testing is to assure that these objectives are being met. However,
these tests may be run in initial stages of production to compare the actual usage to
the forecasted figures.
6.4 Code Testing
To evaluate the functionality, reliability and validity of the coding done against each and
every event relating to the concerned object (text box, command button, option button,
mask edit box etc), is tested and found the following results in compiled form given as
under: -
Sr.
#
Form
for the
Purpo
se of
Object Name Event Test Result
01.
Security
Text Box to enter
Password
Enter
On wrong Password; Message Box
“Incorrect Password”
On correct Password; Excess to Main
Document Form
Command Button Click
On wrong Password; Message Box
“Incorrect Password”
On correct Password; Excess to Main
Document Form
Command Button to
Change Password
Click
Caption Changed “Don’t Change
password or vice versa
Exit Button Click
Access to Main Form is denied,; Exit
from the system

82
02.
Claim
Case
–
Entry Text Box for
Reference #
Enter /
Lost
Focus
Without proper or duplicate reference
number; message box “ Incorrect
Reference #”
On successful entry; control is
automatically shifted to next field of
name
Text Box for
Policyholder Name
Enter /
Lost
Focus
With out alphabetic, control is not
shifted to next field.
On successful, lowercase letters are
converted to uppercase and control is
shifted to take policy number.
Similarly, other testing operations on coding is done and found correct as designed.
6.5 Project Testing Report
Sr.
#
Testing Name Report
01. Security Testing
Especially, the Logon measures are so concrete; no flaw is
observed, if wrong password is given. There is no way to
move forward except with correct password. Coding is
done successfully.
02. Performance Testing
It is monitored that during high load of data, the system
performance satisfactorily
03. Recovery Testing
It is examined that system is easily recovered and no
damage of data from a disaster (power shut down, blown
circuit, disk crash, interface failure, insufficient memory,
etc.)
04. Function Testing
The overall functionality of the system is examined. It
includes testing of all the interfaces. On every aspect, the
system is tested and conduct of the system found exact and
satisfactory.
05. Unit Level Testing
The function of every event/procedure/method of the object
placed on the form is tested and performance is quite
satisfied as per designed by the programmer.
06. Integration Testing
As all individual components are tested separately and
found correct; then these are combined, performance is
checked by integrating and found satisfactory.
6.6 Conclusion
In conclusion, we properly tested the code with respect to “true” testing. A proper method
is driven by the environment, the situation and, most importantly, by the objectives. As a
general rule, no one method alone is sufficient.

83
As the system is put in the hands of the customer and the real valued data is given to the
system; all the functions of the system work properly. No flaw is observed. This holds true
under both the traditional (procedural) and object oriented models.
Software testing is an important part of the software development process. It is not a single
activity that takes place after code implementation, but is part of each stage of the
lifecycle. During coding and then in the implementation stage, the individual code against
each and every object is tested and left no discrepancy there.
We conclude that customer report is more than any thing else. In this case, our customer is
satisfied with the performance of the system. No complaint is registered. Hence, the
system operations are fine than just. The software is Bug Free.

 The facility by making addition of a component to maintain the
record on Death Claim Repudiated case, follow-up on disciplinary
actions recommend therein by RCC
 The projected interface to handle the repudiated cases and prompt
actions against the responsible officials.
 The analysis on Special Major Surgical Benefit (SMSB) cases and
projected report by an addition of an interface taking basic roots
through the Claims Record management feature.
 Ground work to induct the component to facilitate the user to manage
the cases pertaining to Wafaqi Mohtasib.
C
H
A
P
T
E
R
0
7

84
7. Future Extension
With respect to the future extension of this project can be viewed in terms of the following
components. As in the detailed study of the existing system, there is a need of prompt and
coherent actions to be taken on repudiated cases and the follow up over recommended
disciplinary actions by RCC. Here we have chalked out a sketch in a dream to get benefit
from this project by making an extension of these components. Besides this, the
management of SMSB cases can also be taken as an extension of this project. We discuss,
these sexual one by one: -
7.1 Death Claim Repudiated Cases
The format of information to be computerized is discussed here as under: -
(1) (2) (3) (4) (5)
Zone Policy # Name of Assured Risk Date
Date of
Revival
BAHAWALPUR 508539478-3 LATE TEHMENA RANI 01-03-2003 -
D.G.KHAN 508275992-8
LATE MUNAZA
KOUSAR
01-06-2002 -
(6) (7) (8) (9) (10)
Date of
Death
Cause of Death
Reason for
Repudiation
Sum
Assured
Supplementary
Contract
28-03-2003 Blood Pressure
Pre-Insurance
Ailment
100,000
ADB on
Both lives
19-05-2003 Heart Attack
Pre-Insurance
Ailment
200,000
ADB on Male
Life
FIB 10 % for 10
years
(11)
Disciplinary action(s) against officials, if recommend, by the Regional Claims Committee
01- Recovery of Commission from the entire channel
02- Termination of Mr. Muhammad Alam, Sales Manager, Code # 780456
03- De-list Dr. Muhammad Toor form the panel of State Life
NIL
Some of the components of this register are self-explanatory. However, column(s), which
are new one, are described as under: -
i. The title “Deceased Name/Policyholder Name/Life Proposed Name” is now
termed as “Assured Name. The contents are the same and taken from the “Death
Claim Register” as elaborated earlier.

85
ii. Risk date is the same as elaborated the column “Date of Commencement” under
the topic of “Duplicate File Creation”. Only the name of the commencement date
is changed as Risk Date but elaboration is same.
iii. During the prescribed term of the policy contract, if the status of the policy risk
coverage is termed as LAPSE or Paid-Up due to non-compliance of the policy
terms and conditions, for one reason or the other; the policyholder is provided an
opportunity to get the policy status ENFORCE by reviving the policy. For the
purpose of understanding, here, three terms used are explained as under: -
a. LAPSE – if the policyholder fails to pay the 2nd
year premium with in the
grace period of 30 days from due of the premium; the policy contract
attains the status LAPSE. Under this status, no life risk is covered and
obviously none of the claim is entertained as per policy privileges.
b. PAID-UP – are those policies, which are gone due to short of premium
after 2nd
year paid under the option of automatic paid-up in regard to policy
terms and conditions. No claim on such policy is entertained.
c. ENFORCE – the policy carrying this status enjoys the maximum of the
claim benefits, as per policy terms and conditions.
Here, we are not concerned with the procedure of the revival to get the LAPSE or
PAID-UP status in the ENFORCE status. Only, the death claim file is examined to
see how many times and when the policy got revived, if any. The respective date(s)
of revival is noted and entered in this register. Hence this column may get more
than one date(s) value, if the policy is got revived more than one time during the
entire length of policy period.
iv. “Date of Death” and “Cause of Death” is taken from the Death Claims Papers
submitted by the claimant supported with the Death Certificate of the
Deceased/policyholder. All this stuff is available in the file and summarized in the
“Policy Summary Sheet”, prepared at Zonal Level. These particulars are also taken
into account the “Brief Summary Report”, prepared for RCC. Hence, these
particulars are taken into the above referred register.
v. When as death claim liability is repudiated by the ZCC/RCC, clear-cut reasons on
solid grounds, are recorded in the decision of respective claims committee. On
having RCC decision sheet, normally, the following reasons are noted in
repudiation cases: -
a. Pre – Insurance Ailment: this shows that the policyholder provide fake
particulars about his/her health etc at the time of signing proposal and
concealed the true picture which may result into declined of proposal.
When, this fact is established during death claim investigation supported

86
with different evidences like previous medical record, history, disease etc;
such claim repudiation is given the reason as “pre-insurance aliment”
means the assured was suffering from a particular disease before taking the
policy.
b. Record Tempering – The claimant, to fetch the death claim, provides fake
documents; when this fact is proved during the course of death claim
investigation, the reason is given as “Record Tempering.
Hence, the column “Reason of Repudiation”, in the registered, takes the value by
examining the file, ZCC Summary Sheet, RCC Briefing Sheet. Normally, this
column takes only one value for one repudiated claim.
vi. The description of “Sum Assured” is the same as given above.
vii. Under one policy, the policyholder may get a number of supplementary contracts
alongwith the basis life risk coverage. The name of some of these contracts are
given as under: -
a. AIB – Accidental Injury Benefit
b. ADB – Accidental Death Benefit
c. FIB – Family Income Benefit
Here, we are not concerned with the procedure and elaboration over these
supplementary contracts. Going through the file supported with the ZCC/RCC
summary sheet(s), the number of supplementary contracts, taken if any, is
mentioned in the above column of this referred register. This column may get more
than one value, in case the deceased enjoyed the benefits of more than one
supplementary contract over a period policy life.
viii. The last column of this registered is titled as “Disciplinary action(s) against
officials, if recommend, by the Regional Claims Committee”. Certainly, a death
claim is repudiated on solid grounds with concrete evidences under unanimous
decision of RCC. In the RCC decision, on having minute observation of the case, if
committee members feel that some official’s negligence or collaboration with the
claimant to earn the claim using unfair means; it may recommend some
disciplinary actions to be taken against pin-point official (staff/officer). So, these
recommended actions are recorded under this column and Regional Incharge –
PHS, Multan Region takes a close look and remains in touch with the concerned
authority until or unless the implementation of the decision is met with its realistic
interpretation. So, follow up activities on these recommendations are also recorded
under this column. The kind of data, this column may take, can be viewed in the
above specimen-referred register.

87
7.1.1 Sketched Interface/Report
To manage such information and to make this component as part of the project, the
following interface is designed for repudiated cases and concrete follow up on
recommended disciplinary in such cases:-
This interface shows the details of the case on which the claim liability repudiated by RCC.
This interface is used to record the number of disciplinary actions recommended of a death claim case on
which liability is repudiated. The above information is extracted for the Death Claim Master Table where as
the table on the bottom has many-to-one relationship with the parent table.

88
This interface explains the description on the status of implementations of decision/recommendations against
which the disciplinary action recommended due to the liability repudiated. This facilitates over follow-up
action over these cases.
This is an extraction from the report generated through the management record on repudiated cases through
the interfaces sketched as above.

89
7.2 SMSB Cases
In regard to future prospect of the project, the information on SMSB cases can also be
managed as discussed here as under in shape of a register maintained format: -
(1) (2) (3) (4) (5) (6)
Sr.
#
Policy Number
Name of the
Policyholder
Sum
Assured
T/T
Date of
Commencement
01. 508551987-6 MR. M. AKRAM 150,000 03/20 31-12-1996
02. 508333564-3 MR. ABDUL HAMEED 150,000 19/20 01-05-1997
(7) (8) (9) (10) (11) (12)
Date of
Revival
Date of
Surgery
Nature of
Surgery
Amount
Advanced
Date of
Advance
Zone
- 05-05-2004 By Pass 50,000 06-06-2004 BAHWALPUR
- 21-12-2003 By Pass 50,000 08-06-2004 MULTAN
By observing the format of this register and one can see that most of the columns
contained in the registered are described under the category of “claims cases”, in one way
or the other. This Register is maintained on month-to-month basis and report as per above
format is sent to the PHS – Division, Principal Office, Karachi, on the cases, which are
approved by RCC. As noted above, Policy Number, Name of the Policyholder, Sum
Assured, Table & Term (T/T), Date of Commencement, Date of Revival and Zone are
elaborated above. However, description on the remaining items is given as under: -
- Date of Surgery: the date on which the surgery of the policyholder done is taken
from the paper available in the file as submitted by the policyholder. This date is
brought forward on the summary sheet prepared for RCC decision and accordingly
picked in this register after decision of the committee
- Nature of Surgery: elaborates the type of the surgery though with the
policyholder undergone. For example, policyholder passed through “Bye Pass” –
reflects the nature of the surgery. On having examination of the papers available in
the file, this column is filled.
- Amount Advanced: The amount approved by RCC to grant the policyholder as
loan to compensate the expenses incurred on the above treatment is termed as
advance. This amount is deducted (without interest) against the sum assured at
maturity time of the policy or cash value, as the case may be, which every is
earlier.

90
- Date of Advanced: After having SMSB claim approved, the file is returned to the
concerned Zonal Incharge – PHS. The department arranges payment to the
policyholder. The date, on which the department pays to the policyholder against
this claim, is communicated and accordingly entered under this column in above
register.
This information can be maintained by making an addition of a form having link with the
main claim form and master data table.
7.3 Wafaqi Mohtasib Complaint Cases
As we discussed in Chapter # 02 that Department has to maintain Miscellaneous
Complaint cases. Accordingly, we made this component as part of the current project.
Similarly, PHS – Department, Regional Office, Multan has to entertain the complaint
cases on the policies pertaining to Multan Region, upon which Wafaqi Mohtasib Forum is
knocked regarding repudiation of death claims in particular and poor performance meeting
with policyholders’ requests for Policy Surrender, Loan etc. The office of the Wafaqi
Mohtasib, at Federal level, has the powers through its Regional Offices to mend for the
complaint regarding public offices falling within the jurisdiction of Federal Government.
Our valued policyholder, if feels unsatisfied in meeting his/her request, may knock the
WM Forum. Upon receipt of the complaint at WM Office, the copy of the same is
received to the Regional Concerned through our Principal Office, Karachi. The Regional
Incharge – PHS has to deal with such cases during the course of proceeding at WM Office.
In order to maintain the record, prompt and early reply and address the genuine grievances
of the complainant; upon receipt of complaint, a register is maintained for the purpose.
For the purpose, ground work is done with a view to have next version of this project with
the addition of this component as part of the project. Here, we take the opportunity its
manual procedure being carried out and drawbacks in managing it.
01- A unique serial number is allocated to each Wafaqi Mohtasib Complaint case (e.g.
WM – 0001/2004) with the date on which the copy of the complaint is received.
02- Following particulars, taken from the complaint application, are entered in a
Register, as per format given on the next page: -

91
(1) (2) (3) (4) (5)
Ref # Complaint # Policy # Name of Assured
Name of
Complainant
WM – 001/2000 H/19388/2000 508300147-6 Allaha Ditta Arshad Self
WM – 003/2000 L/9595/2000 503855949-6 Nazir Ahmad Sabira Alia
(6) (7) (8) (9) (10) (11)
Nature of the
Compliant
Zone Decision
Last Date of
Report
Report
Submitted on
Last date of
Rejoinder
AIB Claim MULTAN AGAINST
09-07-2002
17-07-2002
- -
Death Claim MUTLAN 04-06-2002 -
(12) (13) (14)
Date of
Submission
of Rejoinder
Hearing Date Remarks
-
09-07-2002
24-07-2002
30-07-2002
File Sent to Multan Zone, on 23-07-2002
-
09-07-2002
30-07-2002
17-10-2002
01- Reference number is issued by the Principal Office, as per record maintained there
to communicate with the concerned Zone. The format of this reference number is
designed in such a way that WM-continuous serial number/the year case pertains
to. WM is taken with respect to the matter pertains to Wafaqi Mohtasib, continuous
serial number is a sequence of incoming cases as reported to Principal Office and
current year reflects the year in which the application is first time received
Principal Office, Karachi.
02- The column “Complaint Number” contains the serial number issued by the WM –
Office upon receipt of application from the complainant. This number is unique to
them. WM – Office refers this number while communicating with the agency or
the complainant. This number is written as per format followed by the WM –
Office.
03- Policy Number shows the policy upon which the complainant has the grievances
with the Corporation and the matter on which whole of the conflict arise between
the complainant and State Life.

92
04- Name of the Assured shows the name of the policyholder or the name of the
deceased, in case of death claim.
05- Name of the complainant may be same as that of the name of the Policyholder, if
the conflict pertains to other than death claim case. Obviously, in case of death
claim matter, the name of the complainant would be nominee or any other relative
of the deceased.
06- Nature of the complaint shows the category of the matter on which dispute arise.
For example, death claim, AIB Claim, Surrender Value Case, Loan Case and etc.
07- The column “Zone” is the same as done earlier on different work categories,
explained in this chapter so for.
08- In the “Decision” column, the word “AGAINST/LOST” is written in case WM –
Decision is done against the Corporation. Similarly, the word “WON” will get the
place in the column for the cases on which decision is made in favour of State Life.
09- “Last Date of Report” – contains the date(s) on which the report/comments are
called on the complaint.
10- In response to the above column, “Reported Submitted On” contains the date(s) on
which the report is submitted to WM – Office.
11- In case, there is a need to submit some information, in addition to the written
report, which the Corporation/WM – Office deems so; a report named as rejoinder
is submitted accordingly. “Last date of Rejoinder” contains the date(s) fixed to
submit the report.
12- “Date of Submission of Rejoinder” contains the date(s) on which the required
report is submitted.
13- “Hearing Date” column contains the date(s) fixed for hearing of the case wide step
to step proceedings at WM – Office.
14- In the “Remarks” Column, case proceedings, file/case movement positions,
internal work activities notes, carried on the case, are recorded.
honour the queries; the following reports are prepared using the data form this register: -
a. List of cased on which the cases referred but report/reply not received
b. Statement of LOST/WON cases
c. Cause List of the incoming cases to be heard shortly
d. Zone-wise/year-wise list of complaint cases
e. Current status on a particular complaint case

93
7.3.1 Drawbacks in handling of Wafaqi Mohtasib Complaint Cases
category of Wafaqi Mohtasib Complaint Cases and keeping in view the expectations of
separate activities status is embedded under a single heading. For example, the
application referred to, the date of which it referred, reminder sent to referred
zone/person to respond, complaint settled, pending for reply, etc. It comes very
difficult to scrutinize and to count manually the cases, required to follow-up the
cases, settled and etc. When the management needs such sort of information; the
error on having a report. It consumes a lot of time when the activities are in bulk.
Some times, this column, under a particular row, is so filled that an additional
Hence, these components can become part of the project in future. Here we have the
ground work to get these jobs done in the incoming version of this project.

 The procedure of getting in to the system, Logon procedure, change
password procedure and to move to the Main Document Form
 How the data is put to the Data Entry Form on different components
like Claims Cases, Record on Proposal File etc. In addition to this,
we would understand the procedure of saving, retrieving, editing and
navigating from record to record.
 The Updation procedure and view of report on the screen
 How to get access and use of the facilitation ingredients from the
Pull Down Menu on the Main Form.
 And how to get entertainment on Tig–Tag–Toe
C
H
A
P
T
E
R
0
8

94
8. User Guide
In order to make things convenient to the user, here, we elaborate how the user can get the
work done by using this software. This software is quite easy to handle and menu driven
coupled with the help on tool-tip text available on object to object.
We discuss the manual from Splash Screen of the T&TS to reporting process and exit of
the system in detail so that each and every aspect be addressed in a sufficient way: -
After Installation of the software, on having double click or enter on the T&TS icon or
selecting from menu to get execution of the file; a splash screen is appeared on the
monitor screen with the two command buttons as shown below: -
On the top of the screen, having sight on
the name of the Allah, the user will
observe software name “Track and Trace
System” moving from right to left on the
screen and stops as it reaches in the
center of the line. The AIOU Logo is
appeared in the middle of the screen
with green background colour. Also logo
and name of the Corporation to which the system pertains is worth seeing here. The
current date and time (as per system date/time setting) are taken right on this screen.
On clicking the picture (door to enter) the user will get access to the next Form/Screen. By
having selection and pressing Click on the exit Door the user will leave the T&TS and
back to the screen as was before execution of the system.
From entrance door, the user will find the screen having the title “Get Authorization” with
the Main Form in the background. The user will have no access even or unless he/she is
authorized.
In order to get authorizations, the user has to put the key password in the enabled Text
Box. The key word should be in small letters no numeric characters are allowed. If the key

95
words put by the user are the same on comparison with the already given to the system,
the user will on the Main Menu Form of T&TS.
8.1 Method for Logon
• Type the password characters in
the text box bearing caption:
Enter Key Word(s)
• Press Enter or Click on the
Command Button bearing
caption “Enter”
On this form, the user has the facility to
change the password as per procedure
given as under: -
8.1.1 Method to Change Password
1. Get focus on the Change Password Command Button, press Enter or Click on it.
The user will get the text box(s) pertaining to Change Key words enabled and the
text box on the top of the form as disabled. Also the caption of the Clicked
Command Button will be changed as “Don’t Change Password”
2. Type the password characters in the text box bearing caption: Existing Key
Word(s) and press enter. These characters should be the same as stored key words
to get authorization.
3. Put New Key words in the text box bearing caption New Key Words and Press
Enter or Click on the Command Button bearing caption “Enter”. The password
characters are changed successfully. Confirmation message is displayed. Now the
user may get the authorized with the new changed password.
4. During the change password process; by clicking the Command Button bearing
caption “Don’t Change Password” the user can cancel the operation of change
password and can use the old password/already stored for getting authorization to
the Main Menu Form.

96
After having successful authorization, this Main Menu Form comes in focus and its all
Pull Down Menu can be accessed. From the First Pull Down Menu New File, the first
option Claim Cases or pressing the Short Cut Key Ctrl+C, the user accesses the
following form: -
8.2 Description – Data Entry Form
• This form /interface is used
to record the Fresh Files (the
files which are received first
time in PHS Deptt) as New
Entry received particularly
on death claim cases for
consideration of RCC
• Navigation of Records can
be done
• Searching is possible by exercising one of the options: By Reference Number or
Policy Number
• Previous Record / Next Record Status is also displayed as the Navigation
command buttons (First, Previous, Next, Last) are exercised.
• Edit, Save, New, Cancel, command buttons are there to facilitate the user enter
New Record and Editing to confirm save to the concerned database table.
8.2.1 Method for Addition of New Record
• On the receipt of a claim file, to Enter New
Record, press the New Record Button. On
Click the button, the text boxes of this form
turn into blank to get fresh data. The user may cancel the operation of new case
entry by clicking the Cancel Command Button

97
• The cursor blinks in the text box bearing caption Reference Number
RCC-____/____. The user has to put the assigned serial number like 0001 and year
like 2004. On entry on correct serial number as per format, the cursor will
automatically shift the control to the next text box of caption Name of the
policyholder/Deceased. The control will never shit to this field unless the
Reference Number is given in correct format. Duplicate Serial Number is not
allowed.
• Enter the Name of the Policyholder/Deceased; be taken from the file. This field
cannot be left blank. Numeric data is not allowed. However, if the user wants to
left the name blank at this stage for one reason or the other then blank spaces can
be moved and the press enter. On pressing the Enter Key, the text written in this
field is converted to Upper Case Letters before to focus move on to next text box
for entering of Policy Number.
• Enter the Policy Number taken from the file. No duplicate policy number is
allowed. Control will never shift to next text box unless the policy number is
entered correct and as per format.
• Here put the figure for Sum Assured of the policy. In the next two boxes, the user
has to enter two digits for each of the text box to provide Table and Term of the
policy respectively. The control will never move on to next unless the
• On having control to the combo box named as Zone, pick one of the Zone Name
from the list relevant to the file pertains. This column can never be left blank. On
having successful selection, the control shifts to next combo box named as Claim
Category. In case the required Zone Name is not mentioned in the list then: -
o Close this Form
o Go on to the form Named as Zone Option from the Pull Down Menu
“Option” and add the required name there; then move to this Entry Form.
You will get the new added Zone Name here in the concerned Combo box
List.

98
• Similarly select the category of the claim from the Claim Category combo box list
relevant to the nature of the claim. The field can never be left blank. On having
successful selection, the control shifts to next text box for date of receipt of the file.
In case the required Claim Category descriptions is not enlisted here then: -
o Close this Form
o Go on to the form Named as Category Option from the Pull Down Menu
“Option” and add the required name there; then move to this Entry Form.
You will get the new added Category Name here in the concerned Combo
box List
• In this text box enter Date of Receipt of the File (format: dd-mm-yyyy). Date next
to the current date is not allowed. The control will never shift to next text box if the
date is not entered in correct format.
• On successful entry of date of receipt of file; the user has to select the Current
Action from the list available in the controlled combo box. In case the required
Action Taken descriptions is not enlisted here then: -
o Close this Form
o Go on to the form Named as Action Option from the Pull Down Menu
“Option” and add the required description for action taken there; then move
to this Entry Form. You will get the new added Action Taken Description
here in the concerned Combo box List.
• After having successful, entry of data in the above columns, the control is shifted
to the Save Command Button. Press the Save command Button to store the record
in the concerned table and become part of the database permanently.
In this way, the transition of new record entry is completed.
8.2.2 Method of Searching of a Record
• On exercising on of the options Reference # or
Policy #, from this Search Record By Options

99
Button, the user can search the desired record to have a view or for the editing
purpose.
• On having click on
the option having
caption Reference #,
an Input Box shown
here is appeared to get
the data for the
required field to search. The descriptions self-explanatory. On providing the
reference number as per format; the record on the desired input is displayed, if it
matches with the data available in the concerned table otherwise Message Box
“Record Not Found” is displayed.
the option having
caption Policy #, an
Input Box shown here
is appeared to get the
data for the required
field to search. The descriptions self-explanatory. On providing the policy number
as per format; the record on the desired input is displayed, if it matches with the
data available in the concerned table otherwise Message Box “Record Not Found”
is displayed.
8.2.3 Method of Editing of a Record
• After the record search operation to arrive at desired
record or for the current record; on pressing the Edit
Record Button, the user is allowed to make editing
(e.g. Correction of Spelling of Name Field, change of Table/Term, Sum Assured
etc).
• If the user presses the Edit Command Button then: -

100
o Navigation Stops
o Record Search Option is disappeared
o The Command button takes the form as shown here
• Make Changes as desired in the current record. Press Save Command Button.
Cancel Button may be used before to save button, if the changes are required to be
discarded.
• After having saved, the changes are permanently done. The disabled functions,
commanded buttons, etc are restored i.e. navigate freely, add new button is
available, searching is available and to exit also.
• Obviously, Exit Command button is used to exit /unload/hide this form and return
to the Main Menu Form.
As for as the other options from the Pull Down Menu “New File” are concerned, the
Opening, Navigation, Adding New Record, Editing of Current Record, Search through the
available options as on the form and exit functions are some like the same as described
comprehensively above in “Claim Cases”. However, glimpses over the remaining can be
seen in the Appendices Section.
Now we move to the next Pull Down Menu named as “Update” and discuss how the
record is taken in view as soft copy or updation is done. We take the Proposal Cases into
focus, here: -
8.3 Description on Proposal File - Update Mode
• This form /interface is used
to update the action taken on
the proposal file case and
view the current status on the
case supported with the case
activity – to – activity based
notes in the grid below.

101
• Navigation of Records can be done
• Searching is possible by exercising one of the options: By Reference Number or
Proposal Number
• Edit, Save, command buttons are there to facilitate the user to Edit and Save to the
concerned database table.
8.3.1 Method of Searching of a Record
• On exercising on of the options
Reference # or Proposal #, from this
Search Record By Options Button, the
user can search the desired record to have a view or for the editing purpose.
the option having
caption Reference #,
an Input Box shown
here is appeared to get
the data for the
required field to search. The description is self-explanatory. On providing the
reference number as per format; the record on the desired input is displayed, if it
matches with the data available in the concerned table otherwise Message Box
“Record Not Found” is displayed.
• On having click on the
option having caption
Proposal #, an Input
Box shown here is
appeared to get the data
for the required field to
search. The description is self-explanatory. On providing the proposal number as

102
per format; the record on the desired input is displayed, if it matches with the data
available in the concerned table otherwise Message Box “Record Not Found” is
displayed.
8.2.3 Method of Editing/Updating of a Record
• After the record search operation to arrive at
desired record or for the current record; on
pressing the Edit Record Button, the user is
allowed to make editing or updating in the fields (Decision by RUC, File Returned
On, Action Taken) in the Grid Case History Notes on the fields (Proposal Number,
Date when activity performed and Notes)
• If the user presses the Edit Command Button then: -
o Navigation Stops
o Record Search Option is disabled
o Option Frame Decision By RUC is activated
o The Command button takes the form as shown here
• Make Changes as desired in the
current record. Press Save Command
Button. From Close Button may be
used before to save button, if the
changes are required to be discarded.
• On successful data pass to the Decision by RUC text box, user may enter the Date
of Return of File to destination, if so; otherwise to control will be shift to Action
Taken Combo Box; the user has to select the Current Action from the list available
in the controlled combo box. In case the required Action Taken descriptions is not
enlisted here then: -
o Close this Form
o Go on to the form Named as Action Option from the Pull Down Menu
“Option” and add the required description for action taken there; then move

103
to this update Form. You will get the new added Action Taken Description
here in the concerned Combo box List.
• The control can be taken in the Grid to record the case history as per column
available.
• After having successful, updation of data in the above columns, the control is
shifted to the Save Command Button. Press the Save command Button to store the
record in the concerned table and become part of the database permanently.
• After having saved, the changes are permanently done. The disabled functions,
commanded buttons, etc are restored i.e. navigate freely; searching is available
also.
As for as the other options from the Pull Down Menu “Record Update” are concerned, the
Opening, Navigation, Editing of Current Record, Search through the available options as
on the form and exit functions are some like the same as described comprehensively above
in “Claim Cases”. However, glimpses over the remaining can be seen in the Appendices
Section.
Now we move to the next Pull Down Menu named as “Update” and discuss how the
record is taken in view as soft copy or updation is done. We take the Proposal Cases into
focus, here: -
So for now we have discussed the methodology of getting work done through the Pull
Down Menus. Similarly, the procedure through the Facilitation Menu and Report Menu is
also as easy as described above. There is more elaboration on it in the Appendices Area.

104
A. Appendices
In this section, we visualize how the data passes through the system in Data Flow Diagram
(DFD), the attributes set in Entity Relationship Diagram (ER – Diagram), the interaction
Interface to facilitate the user for passing data to the system and the sample of the Out output
screen are glimpsed here as under: -
A1. Data Flow Diagram
A.1.1 Level 0 DFD
Received Process
Presents Returns
Searches / Shows Searches / Returns Shows Stores /
Stores Stores Searches
Database Database Database
A.1.1 Level 1 DFD
Query Regional Office
Report
Record
PHS
Database
Information
File Decision Returned
Admin Decision Searches
Returns
Presents

105
A2. Entity – Relationship Diagram
A2.1 Claim Cases
ActionDate ActionNotes
PolicyNumber
Claim
Summary
Action
Taken
Decision
Reference
Number
File
Returned On
File
Received On
Policy
Number
Term
Table
Claim
Category
Sum
Assured
Policy
holder
Zone
Claim
MasterFile

106
A2.2 Proposal File Cases
Proposal
Number
Proposal
Summary
Action
Taken
Decision
Reference
Number
File
Returned On
File
Received On
Proposal
Number
Term
Table
Sum
Assured
Life
Propsoed
Zone
Proposal
MasterFile

107
A2.3 Duplicate File Creation Cases
DupPolicy
FileNumber
Dup
Summary
DupDate
Commencement
DupAction
Taken
DupFile
Decision
DupPoliy
RefNo.
DupFile
Returned On DupFile
Received On
DupZone
DupTerm
DupTable
DupSum
Assured
Dup
Policyholde
r
DupPolicy
FileNumber
Duplicate
PolicyMaster File

108
A2.4 Investigation Cases
InvPolicy
FileNumber
InvClaim
Summary
InvDate
Commencement
InvpAction
Taken
InvFile
Decision
InvPoliyR
efNo.
InvFile
Returned On InvFile
Received On
InvZone
InvTerm
InvTable
InvSum
Assured
Inv
Policyholde
r
InvPolicy
FileNumber
ClaimInvCase
Master File

109
A2.5 Misc. Complaint Cases
MiscPolicy
FileNumber
Misc
Summary
Action
Taken
Decision
MiscReferen
ceNumber
Disposed
On File
Received On
Zone
MiscComplai
ntAgaisnt
MiscComplai
ntNature
Misc
Policyholder
Misc
PolicyNumber
MisComplaint
Master File

110
A2.6 Quick Look on ER - Diagram
Database Design on Track and Trace System

111
A3. Glimpses - at Start Up
A3.1 Splash Screen
Fig: 1 on having execution of the System; the first ever screen appears on the
Monitor Screen.
A3.2 Main MDI Form
Fig: 2 on entrance through the above door; the main container (i.e. MDI Form)
of the system is appeared.

112
A3.3 Security First
A4. Sample Input Screens
A4.1 From Option Menu
Fig: 3 To get access on the Main Menu, user has to pass
the Security Test by Getting Authorization at this form.
Fig: 4 The user may exercise the
facility to add New Zone Name by
using this interface, as and when
New Zone is created or a file received
from the Zone not enlisted earlier.
Fig: 5 Here the system provides
the option to enlist name of the
category to which a particular file
pertains to, not available on the
entry form. By Adding option
here, user can get the same on the
respective entry/update form.

113
Fig: 6 As on the previous interface, similarly, here, the user can opt different Action
Description which are required to be taken during the course of process
A4.2 From the Pull-down Menu – New File
Fig: 7 The interface shows the record entered pertaining to the files received for RCC Decision. This is
the form used for new entry of the file received for decision on claim cases, particularly death claims
cases.

114
Fig: 8 The interface shows the record entered pertaining to the files received for RUC Decision. This
is the form used for new entry of the file received for decision of Underwriting Committee on Fresh
Proposal Cases for Life Risk Coverage.
Fig: 9 The interface is used to manage the record for the cases received to create duplicate policy files
on having lost the original ones. The request is put to Regional Inchrage – PHS for approval.

115
Fig: 10 As per requirement, the Death Claim Investigation is done on having Death Claim Reported.
Such request with the file is received. So, in order to maintain the record, this form is used to make the
proper entry of such files.
Fig: 11 On receipt of complaints relating to Policyholder Services, this form is used to register the
complaint assigning unique serial number and ensure the prompt action to address the genuine
grievances of the complainant.

116
A5. Output/Input Screens
As the heading depicts two features Output & Input on the same screen makes it justified
in the sense that the interface simultaneously used for both purposes as view of report of a
particular case and invites the user to exercise the utility to update the record as and when
needed.
Fig: 12 This is the scene that shows the information compiled on Mater Table of Claims Cases and
Notes recorded in the other table with the current status on the case – Report View (Output Screen) On
the other side, the interface provides privileges to the user to update the actions taken from time to time
and record Decision and Case History as Notes on the file.

117
A6. Glimpse from Reports
This view is extracted from the Report generated on data taken from Claim Master File

118
A7. Facilitation Scenes
In addition to meet the necessary obligations under T&TS, user is facilitated through the
“Facilitation Menu” by providing access over Shell Applications like Calculator and
Solitaire. Also a Game Named “Tig Tag Toe” is also provided. The facilitation Menu ends
up with message from the person behind the seen i.e. Developer of the project. Here are
the clips given under: -
A7.1 The Calculator
A7.2 The Tig-Tag-Toe
The Calculator
available from the
windows
operating system
can be used
without leaving
T&TS
For some entertainment, a
game is designed here. With
some partner, user can get
enjoyment by playing this
game. Also Solitaire can be
called with out leaving this
system

119
A7.3 About the Programmer

120
B. References
Pressman, R.S. (1997) Software Engineering, a practitioner's approach. U.S.A.,
McGraw Hill.
Humphrey, W.S. (1989) Managing the software process. U.S.A., Addison-Wesley.
Marick, B. (1995a) Testing Foundations, part 1.
http://www.stlabs.com/MARICK/1-fault.htm.
Marick, B. (1995b) Testing Foundations, part 2.
http://www.stlabs.com/MARICK/2-scen.htm.
Binder, R.V. (1994) Testing Object-Oriented Systems: A Status Report.
http://www.rbsc.com/pages/ootstat.html.
Binder, R.V. (1995) Object-Oriented Testing: Myth and Reality.
http://www.rbsc.com/pages/myths.html.
Humphrey, Watts S, "Managing the Software Process", Addison-Wesley
Publishing Company, Inc., 1989
McConnell, Steve, "Software Quality at Top Speed", August 1996.
http://www.construx.com/stevemcc/art04.htm
Voas, J and Miller, K.W., "Using Fault Injection To Assess Software Engineering
Standards", Proceedings of Int'l. Symp. on Software
Engineering Standards, August, 1995.
Marick, Brian, "Classic Testing Mistakes", 1997
"Software Testing Techniques"
URL: http://hebb.cis.uoguelph.ca/~deb/27320/testing/testing.html
"Software Inspections"
URL: http://www.sei.cmu.edu/str/descriptions/inspections_body.html
Hower, Rick, "Software QA and Testing Frequently-Asked-Qustions, Part 1", 1998
URL: http://www.charm.net/~dmg/qatest/qatfac1.html

121
C. Abbreviations
ABBREVIATION STANDS FOR
ADB Accidental Death Benefit
AIB Accidental Injury Benefit
B&A Budget & Accounts
Deptt. Department
DFD Data Flow Diagram
DUP Duplicate
ERD Entity Relationship Diagram
FIB Family Income Benefit
FMD Field Marketing Development
IA&E Internal Audit & Evaluation
INVES Investigation
MISC Miscellaneous
NB New Business
P&GS Personnel & General Services
PHS Policyholder Service
RCC Regional Claims Committee
RCS Regional Chief Secretariat
RUC Regional Underwriting Committee
SMSB Special Major Surgical Benefit
T&TS Track & Trace System
WM Wafaqi Mohtasib
ZCC Zonal Claims Committee
ZHS Zonal Head Secretariat

Project Report on Policy File Track and Trace System.pdf

More Related Content

Similar to Project Report on Policy File Track and Trace System.pdf

More from Zafar Ahmad

Recently uploaded

Project Report on Policy File Track and Trace System.pdf