IDSP Report

PROJECT REPORTON

INTEGRATED DISEASE SURVEILLANCE PROJECT

Undertaken at

NATIONAL INFORMATICS CENTRE

DEPARTMENT OF INFORMATION TECHNOLOGYNEW DELHI

UNDER THE GUIDENCE OF

INTERNAL GUIDE EXTERNAL GUIDE

Mr. SUBHRAJYOTI BORDOLOI J.R.D KAILAYLecturer (Sr. Technical Director)Deptt. Of Computer Application TRAINING DIVISIONAssam Engineering College National Informatics CentreGuwahati New Delhi

SUBMITTED BY

JAYANTA BAISHYA 6th SEMESTERROLL NO. 05/21

MASTER OF COMPUTER APPLICATIONASSAM ENGINEERING COLLEGE

ASSAMGAUHATI UNIVERSIT

GOVERNMENT OF INDIAMINISTRY OF COMMUNICATIONS & INFORMATION TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

National Informatics Centre

This is to certify that Mr. Jayanta Baishya ID.N0 10039 a student of

Master of Computer Application from Assam Engineering College

(Gauhati University) has done his full-semester project training at

Training Division , NIC, New Delhi, from 2nd July to 14th November. The

project work entitled “Integrated Disease Surveillance Project”

embodies the original work done by Mr. Jayanta Baishya during his above

full semester project training period.

Project Guide/HOD Head, Training Division

Declaration

I, Jayanta Baishya, hereby declare that the project entitled

“Integrated Disease Surveillance Project” which is being submitted in

partial fulfillment of the requirements for the awards of degree of Master

of computer application from the Assam Engineering College, Guwahati

is an own record carried out by me under the supervision of J.R.D Kailay,

Project Head and Sr. Technical Director of National Informatics Centre.

The matter embodied in this project has not been submitted so far for

the award of any degree or diploma.

Jayanta Baishya

Assam Engineering College

Gauhati University

ASSAM ENGINEERING COLLEGE DEPERTMENT OF COMPUTER APPLICATIONS

GUWAHATI 781013

CERTIFICATE

This is to certify that the project work entitled “ Integrated Disease Surveillance Project: Implementation of Form S” for NIC, Delhi is a excellent work carried out by Mr. Jayanta Baishya, a student of Assam Engineering College, Guwahati.

This project work has been prepared as a fulfillment of the requirement for the degree of MCA to be awarded by Gauhati University. This work has not been presented earlier for any other academic activity.

I wish him all success in life.

Mr. Jyotiprakash Goswami Assistant Professor In-charge,

Department of Computer Application, Assam Engineering College,

Guwahati-781013.

ASSAM ENGINEERING COLLEGE DEPERTMENT OF COMPUTER APPLICATIONS

GUWAHATI 781013

CERTIFICATE

This is to certify that the project work entitled “ Integrated Disease Surveillance Project: Implementation of Form S” for NIC, Delhi is a excellent work carried out by Mr. Jayanta Baishya, a student of Assam Engineering College, Guwahati. He has done this project under my supervision and guidance to the best of my knowledge.

This project work has been prepared as a fulfillment of the requirement for the degree of MCA to be awarded by Gauhati University. This work has not been presented earlier for any other academic activity.

I wish him all success in life.

Mr. Subhrajyoti Bordoloi Lecturer,

Department of Computer Application, Assam Engineering College,

Guwahati-781013.

Acknowledgements

The ability to help and patience to exercise diligence and provide support is a quality admonished by very few .No job in this world, however trivial or tough cannot be accomplished without the assistance of the others. I would hereby take the opportunity to express my indebtedness to people who have helped me to accomplish this task. The present line of accomplishment is not a formality but an honest word of appreciation that has exactly been felt by during my Training.

First and foremost I would like to thanks J.R.D Kailay (HOD/GUIDE) Sr. Technical Director, Training Division Group NIC,Delhi for providing unwavering support and the opportunity to work in this organization and also to Mr. Sanjay Kumar, Scientist of NIC for his great advice and support throughout this project. I am immensely thankful to my internal supervisor Mr S. Bordoloi, Lecturer of CA Department, Assam Engineering College, for his incessant and perpetual cooperation and encouragement, and Mr J P Goswami, Assistant Professor, Assam Engineering College, for his constant guidance and inspiration throughout MCA.

I am also wish to express my sincere gratitude and thanks to Maushumi Barooah madam for providing unwavering support throughout my MCA life.

I also take this opportunity to express my indebtedness to all my respected teachers and worker of Assam Engineering College for their kind consent, expert guidance, valuable suggestions and affectionate encouragement.

Jayanta Baishya MCA,6th Semester Assam Engineering College

ABSTRACT OF THE PROJECT

Project Title: Integrated Disease Surveillance Project (IDSP)

Abstract: IDSP developing task is carries by training division at NIC under the Health ministry. As we know India is currently passing through epidemiological transition. Many states in India have good health delivery systems while other states are lagging far behind. Health problems of some states are predominantly due to communicable diseases while in others it is due to Non communicable diseases. Any system that intends to the futuristic will need to take this variability into account and cater to the differential needs of the country and will need to be decentralized and state specific. The program will take into account the wide geo-political and socio-economic differences in the country and tailor its implementation to levels suitable for the given region of the country. In the first phase of IDSP, in those states with advanced health delivery the implementation will be to improve the functions further while in those states with poor health delivery the program will establish a basic and essential module of surveillance Equity in health delivery is one of the emphases for the government. Through an effective disease surveillance program health of vulnerable populations in underdeveloped regions in India will be better understood and corrective steps will be taken to improve their conditions. As a project by WHO, India Health Ministry implementing this surveillance project in various level. I am doing my project which is mainly based on FORM S, which is the SYNDROMIC SURVILLANCE. In this project I am going to develop a system in which a registered user can submit all the syndromic surveillance details for a particular reporting unit. The user is a district level user and details are collected from various reporting unit. Reports are submitted to central server each week. After all the syndromic data are properly submitted to the central server my next task is to generate various reports which are again based on FORM S. As a front end I will use three tier architecture to develop the system. I will use Jsp/Servlet and PostgreSQL as back end.

Tools and Technologies used:

JDK 1.5MyEcllipse 6.0PostgreSQL 8.2

Tomcat 6.0Windows XP

NIC Division Allotted: Training Division (Health Ministry of India)

Module Name: Implementation of Form S (Syndromic Surveillance).

CONTENTS

Chapter 1: Organizational Profile

1.1 About National Informatics Centre

Chapter 2: System Study2.1 Problem Definition2.2 Existing System2.3 Proposed System 2.3.1 Purpose 2.3.2 Scope 2.3.3 Objective

Chapter 3: Project Description

Chapter 4: Feasibility Study

4.1 Introduction4.2 Economic Feasibility4.3 Technical Feasibility4.4 Behavioral Feasibility

Chapter 5: Requirement Specification

5.1 Introduction5.2 Requirement Specification5.3 System Specification

Chapter 6: System Analysis

6.1 Introduction6.2 Tools used for system analysis6.3 Data Flow Diagram6.4 Data Dictionary

Chapter 7: System Environment

7.1 Client-Server Paradigm7.2 Technology Used7.3 Tomcat 6.07.4 PostgreSQL 8.2

Chapter 8: System Design

8.1 Introduction8.2 Structured Design8.3 Database Design

Chapter 9: Testing and Implementation

9.1 Overview9.2 Introduction9.3 Types of System Testing9.4 System Implementation

Chapter 10: System Security

Chapter 11: Future Enhancement

Chapter 12: Conclusion

Chapter 13: Project Snap Shots

Appendix A: Bibliography

ABOUT THE ORGANIZATION

1.1 About NIC:

National Informatics Centre (NIC) of the Department of Information Technology is

providing network backbone and e-Governance support to Central Government, State

Governments, UT Administrations, Districts and other Government bodies. It offers a wide

range of ICT services including Nationwide Communication Network for decentralized

planning, improvement in Government services and wider transparency of national and

local Governments. NIC assists in implementing Information Technology Projects, in close

collaboration with Central and State Governments, in the areas of (a) Centrally sponsored

schemes and Central sector schemes, (b) State sector and State sponsored projects, and (c)

District Administration sponsored projects. NIC endeavors to ensure that the latest

technology in all areas of IT is available to its users. NIC Headquarters is based in New

Delhi. At NIC Headquarters, a large number of Application Divisions exist which provide

total Informatics Support to the Ministries and Departments of the Central Government.

NIC computer cells are located in almost all the Ministry Bhawans of the Central

Government and Apex Offices including the Prime Minister’s Office, the Rashtrapati

Bhawan and the Parliament House. Apart from this, NIC has various Resource Divisions at

the Headquarters, which specialize into different areas of IT and facilitate the Application

Divisions as well as other NIC Centres in providing state-of-the-art services to the Govt. At

the State level, NICs State/UTs Units provide informatics support to their respective State

Government and at the District level lie the NIC District Informatics Offices.

NIC has conceptualised, developed and implemented a very large number of projects for

various Central and State Government Ministries, Departments and Organisations. Many of

these projects are continuing projects being carried out by various divisions of NIC at New

Delhi Headquarters and State/District centres throughout the country. Some of the most

important note worthy projects, which offer a glimpse of the multifaceted, diverse activities

of NIC, touching upon all spheres of e-governance and thereby influencing the lives of

millions of citizens of India are given below:

Agricultural Marketing Information Network (AGMARKNET)

Central Passport System

Community Information Centres (CICs)

Computerized Rural Information Systems Project (CRISP)

Court Information System (COURTIS)

Department of Agriculture Network (DACNET)

Examination Results Portal

India Image

Land Records Information System (LRIS)

National Hazardous Waste Information System (NHWIS)

Public Grievance Redress and Monitoring System (PGRAMS)

Spatial Data Infrastructure (SDI)

Training

Video Conferencing

SYSTEM STUDY

2.1 PROBLEM DEFINITION:

To make a system in which a registered user can submit the Syndrominc

Surveillance details of a week for a particular reporting unit. The user will be district level

user and only he/she can submit the details to central server. Additionally the user can also

update the details that he already submitted and also he/she can delete an entry. The next

problem is to generate various types of reports which are also base on FORM S. The

various reports mainly contains “Form Submission Report” i.e. this reports shows which

reporting unit submitted the Syndromic data in time or late.

Then the other reports are like, weekly Form S report, Comparison Report, Progressive

report. There will also be a graphical format of report for various types of report.

The next main problem I have to implement in this project is to sending the data that

submitted in a local server to the central server. For there will be a process by which a

district level user can create a text file which contains the data of FORM S in a local server,

then this user will upload the file to the central server machine and there the data of the

FORM S from the text file is restored into the database.

2.2 EXISTING SYSTEM:

As India is a big country it is very difficult to monitor the health status of the people

in different region. There is no any direct source by which the central health ministry

becomes aware about the condition in any part of the country in time. The existing system

is indirect one. i.e. the state government has to give the details about the condition to the

central ministry. But on the other hand for a big state, it is also become quite difficult to

collect the data form different parts of the state such they can give the details to the central

government in time.

2.3 PROPOSED SYSTEM

2.3.1 Purpose:

The proposed system aims at making the above system automated and online. This

online system gives the central ministry a direct source by which it can able to get the all

health status in different region in the country at any time. As mentioned earlier there is no

any direct source by which the central government can get the details about the health

condition in different parts of the country. Again as mentioned by world health

organization (WHO) the number of people infected or died by the communicable disease is

become very large in India. So there should be quick steps to prevent this. Now with the

proposed system the government can get the details about the people that are affected by

the communicable disease and take necessary steps in time.

2.3.2 Scope:

The system will provide the user interfaces such that the record keeping and

retrieval of the relevant information becomes matter of just few clicks without any hassle.

The proposed system will give a direct way by which government can get full

details about the affect of communicable disease in the country. So it gives an excellent

support to prevent the communicable disease.

In the proposed system each reporting unit has to submit the report to main server

in every week, so government will get the current status at any time.

In the proposed system there will be a facility by which it gives an alert to the

government about highly affection by communicable disease in a particular region.

2.3.3 Objective:

The underlying objective of the system is to be able to give the health support to the

people of that region who are affected by the communicable disease.

The primary aim of development of current phase of the program is to introduce a

uniform and systematic approach towards monitoring of the affect of communicable

disease in the country and to help the government to give a health support and moral

support to the people of the country.

The program was initiated with a goal of help reduce the burden of morbidity and

mortality due to various communicable diseases in the country by:

Establishing a sustainable decentralized system of disease surveillance

for timely and effective public health action.

Integrating disease surveillance activities. To avoid duplication and facilitate

sharing of information across all disease control programs so that valid data are available

for appropriate health decision.

Under this program a weekly web-based reporting system has been established in all

districts.

***************************************

PROJECT DESCRIPTION

3.1 PROJECT DESCRIPTION

The system to be developed will be referred as Integrated Disease

Surveillance Project (IDSP). Integrated Disease Surveillance Program is intended to be

the back bone of public health programs in the country. IDSP will provide essential data to

monitor progress of on going disease control program and help in allocation of resources

and will be crucial in obtaining political and public support for the health programs. It will

help to identify areas of health priority where more inputs are necessary.

The Integrated Disease Surveillance Project (IDSP) covering all states in

India seeks to assist the central and state governments to shift from a centrally driven,

vertically organized disease surveillance system to one which is coordinated by the center

and implemented by the states, districts and communities.

India is currently passing through epidemiological transition. Many states in

India have good health delivery systems while other states are lagging far behind. Health

problems of some states are predominantly due to communicable diseases while in others it

is due to Non communicable diseases. Any system that intends to the futuristic will need to

take this variability into account and cater to the differential needs of the country and will

need to be decentralized and state specific. The program will take into account the wide

geo-political and socio-economic differences in the country and tailor its implementation to

levels suitable for the given region of the country. In the first phase of IDSP, in those states

with advanced health delivery the implementation will be to improve the functions further

while in those states with poor health delivery the program will establish a basic and

essential module of surveillance Equity in health delivery is one of the emphasis for the

government. Through an effective disease surveillance program health of vulnerable

populations in underdeveloped regions and tribal populations in India will be better

understood and corrective steps will be taken to improve their conditions.

Surveillance is particularly important for the early detection of outbreaks of

diseases. In the absence of surveillance, disease may spread unrecognized by the

responsible health care or public health agency, because sick people would be seen in small

numbers by many individual health care workers. By the time the outbreak is recognized,

the best opportunity to take intervention measures might have been over. Surveillance is

essential for the early for the early detection of emerging (new) or re-emerging

(resurgent) infectious diseases. In the absence of surveillance, individual health care

workers may not recognize the new disease. The continuous monitoring is essential for the

‘early signals’ of any outbreak of any endemic, new or resurgent disease and the action

loop to take effective public health action should be short and effective if disease

surveillance were to prevent emerging epidemics.

Surveillance data can be effectively used for the purpose of social

mobilization and make public participate more effectively in control of important diseases.

This is an important step in reducing the burden of disease in the community.

In recent years, Indian people facing a lot of trouble due to the

communicable diseases and non communicable diseases . So Indian government tries to

take necessary actions for prevention of those diseases in the specific affected area in time

with the help of the data comes from different regions in India. Integrated Disease

Surveillance Project (IDSP) is a decentralized, state based surveillance program in the

country. It is intended to detect early warning signals of impending outbreaks and help

initiate an effective response in a timely manner. It is also expected to provide essential

data to monitor progress of on-going disease control programs and help allocate health

resources more efficiently.

The IDSP proposes a comprehensive strategy for improving disease surveillance and

response through an integrated approach. This approach provides for a rational use of

resources for disease control and prevention.

In the integrated disease surveillance system:

The district level is the focus for integrating surveillance functions.

All surveillance activities are coordinated and streamlined. Rather than

using scarce resources to maintain vertical activities, resources are

combined to collect information from a single focal point at each level.

Several activities are combined into one integral activity to take advantage

of similar surveillance functions, skills, resources and target populations.

The IDSP integrates both public and private sector by involving the private

practitioners, private hospitals, private labs, NGOs, etc and also emphasis on

community participation.

The IDSP integrates communicable and non-communicable diseases.

Common to both of them are their purpose in describing the health problem,

monitoring trends, estimating the health burden and evaluating programs for

prevention and control.

Integration of both rural and urban health systems as rapid urbanization has

resulted in the health services not keeping pace with the growing needs of

the urban populace.

The gaps in receiving health information from the urban areas needs to be

bridged urgently.

Integration with the medical colleges (both private and public) would also

qualitatively improve the disease surveillance especially through better

coverage.

The overall general objective of the IDSP is to provide a rational basis for decision-making

and implementing public health interventions that are efficacious in responding to priority

diseases. Keeping this in mind the main objectives of the IDSP are:

To establish a decentralized district-based system of surveillance for

communicable and non-communicable diseases so that timely and effective

public health actions can be initiated in response to health challenges in the

urban and rural areas

To integrate existing surveillance activities (to the extent possible without

having a negative impact on their activities) so as to avoid duplication and

facilitate sharing of information across all disease control programs and

other stake holders, so that valid data are available for decision making at

district, state and national levels.

Types of Surveillance in IDSP:

Depending on the level of expertise and specificity, disease surveillance in IDSP will be of

following three categories:

i. Syndromic – Diagnosis made on the basis of symptoms/clinical pattern by

paramedical personnel and members of the community.

ii. Presumptive – Diagnosis made on typical history and clinical examination by

Medical Officers.

iii. Confirmed – Clinical diagnosis confirmed by an appropriate laboratory test.

The cases that have been detected and recorded need to be compiled and

transmitted to the next level on a regular basis. This should be done every Monday from

each type of reporting unit. Reports from sub- centers, PHC/CHC, Medical Colleges, SPPs,

Private Hospitals etc

should be sent to the district surveillance unit of each district on Monday of every week.

All reporting centers will provide zero reporting if no cases were detected.

There are five steps in the surveillance procedure, which must be carried out at each level,

starting from the Primary Health Centre (PHC). Each level must have the capacity for

analyzing and using surveillance data for early detection, prevention and control of

outbreaks. The five recommended steps are:

Collection of data

Compilation of data

Analysis and interpretation

Follow up action

Feedback

My work in this project is based on the first type of surveillance in IDSP. i.e . on

Syndromic Surveillance . I have to maintain the syndromic surveillance details in form s .

So in this project my overall task is to maintain the Form S.

The main function to perform in this project are like ..

1. Implementation of Form S.

In this project the user in the district level will submit the Form S fields weekly.

The user is also able to edit and delete an entry.

2. To generate various reports that based on Form S.

2. Create a backup file of Form S entry in database, upload that file to central server

And then restore that backup file in the database of central server.

FEASIBILITY STUDY

4. FEASIBILTY STUDY

4.1 Introduction to System Design Development Life Cycle

System development, a process consisting of two major steps of System Analysis and

Design, starts when Management or sometimes system development personnel realize that

a particular business system needs improvement.

The System Development Life Cycle (SDLC) method is thought of as the set of

activities that analysts, designers and users carry out to develop and implement an

information system The Systems Development Life Cycle method consist of the following

activities: -

1. Preliminary investigation, which comprises of Feasibility Study.

2. Determination of system requirements.

3. System Design.

4. System testing.

5. Implementation.

4.2 Feasibility Study

Preliminary investigation examine project feasibility; the likelihood the system will

be useful to the organization .The main objective of the feasibility study is to test the

technical, Operational and Economical feasibility of the development computerized system

.All system are feasible if they are unlimited resources and infinite time. There are three

aspects in the feasibility study portion of the preliminary investigation:

1. Technical Feasibility.

2. Operational Feasibility.

3. Economical feasibility.

4.2.1 Technical Feasibility

It involves determining whether or not a system can actually be constructed to solve the

problem at hand. The technical issues raised during the feasibility stage of the investigation

were:

1. N.I.C. has well equipped Labs where all the H/W and S/W tools are available that

are needed to run the application. So it doesn’t require extra investment to run the

proposed application.

2. The proposed application will provide all the necessary information to all the users,

inside and outside the organization, and across the world also if loaded on web.

3. Expandability will be maintained in the new system. New modules can be added

later on the application, if required in the future.

4. The application will have User-friendly Forms and Screens, all validation checks.

So the new system guarantees accuracy, reliability, ease of access and data security

4.2.2 Operational Feasibility

Proposed projects are of course beneficial only if can be turned into information

systems that will meet the organization’s operating requirements. Operational feasibility

aspects of the project are to be to be taken as an important part of the project

implementation. Following questions helped us to test the operational feasibility of system:

I. Is there sufficient support for the project for management? From user?

II. Will the system be used and work properly if it is being developed and

implemented?

III. Will there be any resistance from the users that will undetermined the possible

Application benefits?

The system is targeted to be in accordance with the above-mentioned issues.

Beforehand , the management issues and user requirements has been taken into

consideration. So there is no question of resistance from the users that can undetermined

the possible application benefits. The well-planned design would ensure the optimal

utilization of the computer resources and would help in the improvement of performance

status.

4.2.3 Economical Feasibility

A system that can be developed technically and that will be used if installed must

still be a good investment for the organization. In the economical feasibility, the

development cost in creating the system is evaluated against the ultimate benefit derived

from the new systems. Financial benefits must equal or exceed the cost.

The system is economically feasible. Since the interface for Integrated Diseases and

Surveillances Program is very new and resources such as tools and technology are freely

available.

****************************************

REQUIREMENT SPECIFICATION

5. REQUIREMENT SPECIFICATION

5.1 Introduction:

Requirement Specification is the most important phase of the SDLC. During this

phase our Project Manager is in constant contact with the Customer to find out

requirements of the project in detail (A rough estimation is made during the first phase of

SDLC, i.e. before the feasibility study). Main tasks in this phase include Requirement

Determination, Risk Analysis, Setting up Schedules, and deciding Deliverables.

Communication with the Customer is carried out using any of the following means of

communication, such as Instant Messenger, Email, Phone, Voice Chat or personal meeting.

A System Requirement Specification Document is prepared at the end of this phase.

5.2 Functional Requirements:

R1: Title: IDSP Form module.

Description: User will log into the system and after successful login it can go to the

IDSP Form S process. User will enter the name of the BLOCK and its corresponding

reporting unit name for whom Form S will be going to submit by the user also user

will enter the reporting week (the week no for reporting) then user can go to any of the

following three module. i.e. it contain three sub module.

R1.1: Title: Form S submission module.

Description: In this process user will submit all necessary details that necessary

in the Form S and submit it to the server.

Input: Name of the health worker, name of supervisor and user will submit all

details about the seek people (number of people affected and died by a

particular diseases give in the Form S) under the given reporting unit.

Output: After successfully submitting the Form S, the system will give a

feedback to the user as he/she successfully submitted or not.

R1.2: Title: Form S edit module.

Description: In this process user will edit all necessary details that already

submitted in the Form S.

Input: Updated details about the seek people (number of people affected and

died by a particular diseases give in the Form S) under the given reporting

unit.

Output: After updating the Form S, the system will give a feedback to the

user as he/she successfully updated or not.

R1.3: Title: Form S delete module.

Description: In this process user will delete all necessary details that already

submitted in the Form S.

Input: Name of the block, reporting unit and reporting week no.

Output: After updating the Form S, the system will give a feedback to the

user as he/she successfully deleted or not.

R2: Title: Form S report generation module.

Description: This module will give the all-necessary report that needed by user about

Form S. In the report generation module various types of reports are to display

according to user selection.

Input : User will select the type of report that he/she wants to see.

Output: According to the types of report, the different module will display the

different reports.

R2.1: Title: Form S form submission report module.

Description: This report should display, how many reporting unit is delay or

in time for a particular reporting week under a particular block and then it

should display which reporting unit under that given block is in time or late.

Input: Name of the block, reporting unit, reporting week no and year.

Output: Firstly it should display the report as block wise i.e. how many

reporting unit is in time or delay in a given reporting week and then it

should display which reporting unit is delay or in time.

R2.2: Title: Form S syndromic surveillance report module.

Description: This report should give the details about the Form S. In this report

the user will give the details about the diseases and type of report that he/she

want and according to that different report should display. Each report should

display in hierarchal order. i.e. first it should display the report district wise,

then block wise under the selected district and then reporting unit wise under

the selected block.

Input: Type of diseases, type of report (Weekly, Comparison,

Progressive, Line Chart and Bar Chart), Name of the state and week

number.

Output: Type wise it should display the report to the user.

R2.2.1: Title: Form S weekly syndromic surveillance report module.

Description: It should generate the reports according to the week as

entered by user. i.e. it should give the details of the entry in Form S

according to the week as entered by the user.

Input: Week number, state name.

Output: Report as district wise, then block wise and finally

reporting unit wise.

R2.2.2: Title: Form S progressive report module.

Description: It should generate the reports according to the

week as entered by user but the report should be a progressive

one. i.e it should give the details of the entry in Form S about

the effected people in a particular week number and should

show the progressive status with respect to the previous week.

Input: Week number, state name.



R2.2.3: Title: Form S comparison report module.

Description: It should generate the reports according to the

year as entered by user but the report should be a comparable

one with respect to the previous year of the entered year. i.e. it

should display the number of the diseases effected people in

two successive year in comparable way.

Input: Year, state name.



5.3 Nonfunctional Requirements:

1.Maintainabilty: Back up of database should be taken periodically.

2.Portability: This application will run on both WINDOWS and UNIX platform.

3.Usability: The system should be easy to use and should have a very easy to use user interface.

4.Reliabilty: The system will be highly reliable and cannot be fooled.

5.Extensibilty: The system could be extended to integrate with the main IDSP system.

6.Security: The whole system is about security and that’s why security is must. It must be highly secure and difficult to break without detection.

*********************************************

SYSTEM ANALYSIS

6. ANALYSIS OF THE SYSTEM

6.1 Introduction:

System analysis is a detailed study of various operation performed by a system. The

aim of the system analysis is to deliver system in line with the user requirements. It is

activity that encompasses most of the task that we can collectively call Computer System

Engineering. Analysis of PIS is performed by the following object-oriented methodologies.

The purpose of the object-oriented analysis is to model the real world system so that it can

be understood. To do this we have to abstract important real world system features first and

defer small; details until later. The successful analysis model states that what we must

done, without restricting, how it done and avoid implementation decisions. The result of

the analysis should understand the problem as a preparation of design.

The real world model consists object, dynamic and functional models but during

analysis of PIS we have skipped the object and dynamic model as the activities and actions

are clearly defined.

6.2 Structured System Analysis:

Structured System Analysis is asset of techniques and graphical tools that allow the

analysis to develop a new kind of specification that are easily understandable to the user. It

is an ordered approach that works from the high level views to lower level details in which

the user needs are presented through the use of dataflow diagram. Structured analysis aids

in defining the requirements the new system so that the user has a system they need.

The goal of structured analysis: -

1. Use graphics whenever possible.

2. Differentiate between logical and physical entity.

3. Begin with an examination of the board picture of the system.

4. Build a logical system model of the proposed system from the physical model to

express the building blocks of the system to programmer analyst.

Characteristics of the structured analysis: -

1. It depicts a picture of what is being specified and easy to understand

presentation of the application.

2. The process is portioned, so that a clear picture about the system flow from

general to specific can be made.

3. The element of the system specify in the precise, concise and highly readable

manner. It calls for rigorous study of the user area.

6.3 Tools for Structured Analysis:

A number of structured tools are used for analysis for the candidate system.

Some basic tools are: -

1. Context diagram.

2. Dataflow diagram.

3. Data dictionary.

Context Diagram:

The model, which represents the whole system in a single process showing the

external entities that, interacts with the system, is called Context Diagram. It shows all

external entities that interact with the system and dataflow between these entities and the

system. It contains a single process. But it plays a very important role studying the current

system.

System flowchart is the graphical representation of the system operational sequences

within the system. It shows the system flow sequence among the process of the system.

Dataflow Diagram:

Dataflow diagram is a graphical representation of a system that indicates the flow

of data to and run from the system. DFD also provide an overview of data that a system

process, what transformation of the data are done, what files are used and where the results

flow. It clarifies system requirements and identifies major transformation that will become

programs in a system design.

DFDs are nothing more than a network of related system functions and indicate from

where information is received and to where it is sent. It is the starting point in the system

that decomposes the requirement specifications down to the lowest level detail.

The four symbols in DFD, each of which has its meaning. They are given below: -

1. External entities are outside to system but they either supply input data in

the system or use the system output. These are represented by square of

rectangle. External entities that supply data into a system are sometimes

called Sources. External entities that use system data are sometimes called

sinks.

2. Dataflow models that passages of data in the system and are represented

by line by joining system components. An arrow indicates the direction of

the flow and the line is labeled by the name of the dataflow.

3. Process show that the systems do. Each process has one or more data

inputs and one or data outputs. Circles in DFD represent them. Each high

level process may be consisting of more than one lower level processes.

Process will be expanded in sequent level DFD. A circle or a bubble

represents a process that transforms incoming data flow into outgoing

dataflow.

The high level processes in a system are: -

o Receivable process.

o Verifiable process.

o Disposal process.

4. File or data store is a repository of data. They contain data that is retained

in the system. Process can enter data into data store or retrieved data from

the data store. An open rectangle is a data store, data at rest.

The following diagrams illustrate the notation and the symbols used to create the DFDs.

: A Process.

: The external entities i.e. user.

: The arrowhead shows the flow of information.

: The table in which information will be stored.

: Database.

DFD for the proposed System:

The Data Flow Diagram (DFD) for the proposed system is shown in the following pages in

order of their process from the highest level to the lowest level of procedures.

Context Diagram IDSP System:

Level 1 DFD for IDSP System:

NOTE: (a) No. Of Infected People, No. Of People Died, Late Entry.

Level 2 DFD for Report Generation Process:

Level 3 DFD for Form Submission Report Process:

Level DFD for Syndromic Surveillance Process:

Level 4 DFD for Weekly Report:

Level 4 DFD for Bar Chart Generation Process:

Level 4 DFD for Line Chart Generation:

Level 2 DFD for Form S Process:

Level 2 DFD for Form S Process: (Cont…)

Level 2 DFD for Create New User Process:

Data Dictionary:

It is a structured place to keep details of the contents of data flows, processes and

data store, a data dictionary is a structured respiratory of data about data. It is a set of

rigorous definition of all DFD data elements and data structures and serves as a valuable

document to the organization at the time of future enhancement.

There are three classes of items to be defined in the data dictionary.

1. Data Element: The smallest unit of data that provides for no further

decomposition is called data element.

2. Data Structures: It consists of a group of data elements handled as a unit.

3. Data Flows and Data Stores: Data Flows are data structures in motion,

whereas data stores are data structures at rest. A data stores is a location

where data structures are temporarily located.

SL. No

FIELD NAME DATA TYPE FIELD LENGTH

DESCRIPTION SOURCE

1 statecode character varying

2 State Code State, District, Block, Reporting Unit,

Disease_threshold, form_s, User_table

2 statename character varying

50 State Name State

3 districtcode character varying

3 District Code District, Block, Reporting Unit, Disease_threshold, form_s, User_table

4 districtname character varying

50 District Name District

5 blockcode character varying

3 Block Code Block, Reporting Unit, form_s,

6 blockname character varying

50 Block Name Block

7 reporting_code character varying

5 Reporting Unit Code

Reporting Unit, form_s

8 reporting_name character varying

50 Reporting Unit Name

Reporting Unit

9 district_pop Long Int - District Population District10 block_pop Long Int - Block Population Block11 reporting_pop Long Int - Reporting Unit

PopulationReporting Unit

12 disease_code character varying

5 Disease Code Disease, Disease_threshold

13 disease_name character varying

50 Disease Name Disease

14 threshold_value Integer - Threshold value of Diseases

Disease_threshold

15 myear Integer - Year of reporting form_s16 name_worker character

varying30 Name of the

health workerform_s

17 supervisor_name character varying

30 Name of the supervisor

form_s

18 dt_week_from Date - Date of reporting form_s

19 Id_dsu character 3 DSU ID form_s20 fever_c_m Integer - No of male for

fever caseform_s

21 fever_c_f Integer - No of female for fever case

form_s

22 fever_d_m Integer - No of male died for fever case

form_s

23 fever_d_f Integer - No of female died for fever case

form_s

24 wtrystool_c_m Integer - No of male died for fever case

form_s

25 wtrystool_c_f Integer - No of male for Loose Watery Stool case

form_s

26 wtrystool_d_m Integer - No of female for Loose Watery Stool case

form_s

27 wtrystool_d_f Integer - No of male died for Loose Watery Stool

form_s

28 Jaundice_c_m Integer - No of female died for Loose Watery Stool

form_s

29 Jaundice_c_f Integer - No of female for Jaundice case

form_s

30 Jaundice_d_m Integer - No of male died for Jaundice

form_s

31 Jaundice_d_f Integer - No of female died for Jaundice

form_s

32 paralysis_c_m Integer - No of male for Paralysis case

form_s

33 paralysis_c_f Integer - No of female for Paralysis case

form_s

34 paralysis_d_m Integer - No of male died for Paralysis

form_s

35 paralysis_d_f Integer - No of female died for Paralysis

form_s

36 unusualsympt_c_m Integer - No of male for Unusual Symptom

form_s

37 unusualsympt_c_f Integer - No of female for Unusual Symptom

form_s

38 unusualsympt_d_m Integer - No of male died for Unusual Symptom

form_s

39 unusualsympt_d_f Integer - No of female died for Unusual Symptom

form_s

40 weekno Integer - Reporting week form_s41 late Character 1 Late entry for

reportingform_s

42 mdate Timestamp - Time of reporting form_s43 u_id Character 10 User ID User Table

varying44 pwd Character

varying10 Password User Table

45 add Character varying

50 User Address Master Table

46 remarks Character varying

50 User Remark Master Table

47 permission_frm Character varying

50 From where permission is given

Master Table

48 permission_to Character varying

50 To whom permission is given

Master Table

49 user_status Character varying

50 User Status Master Table

50 date Date - Date of login Master Table

Flow Charts:

A flow chart is a graphical or symbolic representation of a process. Each step in the process flow is represented by a different symbol and contains a short text description of the process step in the flow chart symbol. The flow chart symbols are linked together with arrow connectors (also known as flow lines).

IDSP FORM SUBMISSION STATUS (WEEKLY REPORT)

DATA ENTRY PROCEDURE FOR SYNDROMIC SURVEILLANCE

GENERATION OF SYNDROMIC SURVEILLANCE REPORT

SYSTEM ENVIRONMENT

7. System Environment

7.1 Tool and Technology Used:

The following tools and technology are used to develop the system

Hardware:

Intel Pentium® processor at 500 MHz

Minimum 512 MB memory

Software:

Component Software Name and Version Availability

Operating SystemWindows XP

SharewareWeb Server Tomcat 6.0 Freeware

Database PostgreSQL 8.2 Freeware

Browser Mozila Firefox, IE explorer Licensed

Database Connectivity

PstgreSQL Driver 8.2 Freeware

Java Development Kit

J2SDK1.5.2_05 Freeware

Client script language

Java Script Freeware

Application Servlet Servlet 2.4 or higher Freeware

Java Server Pages JSP 2.0 or higher Freeware

7.2 Architectural Fundamentals

Client-Server Paradigm

The paradigm of arranging for one application program to wait passively for

another application to initiate communication pervades so much of distributed computing it

has been given a name:

The Client - Server paradigm of interaction.

The term Client and Server refer to the two application involved in a

communication. The application that actively initiates contact is called a client, while the

application that passively waits for contact is called server.

Multiple Services on One Computer

A single, server – class computer can offer multiple services at the same time. On

such system, one server program runs for each service being offered. Although a computer

can operate multiple servers, the computer needs only a single physical connection to the

Internet. Running many servers on a single computer is practical because a server does not

consume computational resources while waiting for a request.

Client/Server Database System

Client/Server system are constructed so that the database can reside on a central

computer, known as a server, and be shared among several users. Users access the server

through a client or Server application:

In a two-tier Client/Server system, user runs an application on their local computer,

known as a client that connects over a network to the server running SQL Server.

The client application runs both business logic and the code to display output to the

user, and is also known as a thick client.

In multi-tier client/server system, the client application logic is run in two locations:

The thin client is run on the user’s local computer and is focused on

displaying results to the user.

The business logic is located in server application running on a server. Thin

clients request functions from the server application. Which is itself a

multithread application capable of working with many concurrent users .The

server application is the one that opens connections to the database server

and can be running on the same server as the database, or it can connect

across the network to a separate server operating as a database server.

To develop this system we used three-tier architecture, where presentations are done

with JSP and all business logics are performed in JSP bean and servlet.

Also we used JavaServer Pages Model 2 architecture that is also known as MVC

architecture , where models are created with the JSP bean and controlling is done by servlet

and view is done by JSP.

7.2 Technology Used

7.2.1 Java

Java is an object-oriented language. Java was designed to be easy for

professional programmer to learn and use efficiently. Java inherits the C/C++ syntax and

the object-oriented features of C++. Java can be used to create two types of programs-

applications and applets.

An output of a Java compiler is not executable code. Rather, it is a byte code. Byte

code is a highly optimized set of instruction that is designed to be executing by the Java

Run-time system, which is called the java virtual machine. Translating a java program into

bytecode helps makes it much easier to run a program in a wide variety of environments.

Because the execution of every java program is under the control of JVM, the JVM can

contain program and prevent it from generating side effects outside of the system. The use

of bytecode enables the java run-time system to execute programs much faster.

Benefits of using Java

Java is Secure. Java achieves the protection by confining a java program to the java

execution environment and not allowing it to places extraordinary demands on a page,

because the programs must execute reliably in a variety of system. The hard-to-track-

down bugs are simply impossible to create in Java.

Java is multithreaded. Java was designed to meet the real-world requirement of

creating interactive, networked pages. To accomplish this, Java supports multithreading

programming, which allows you to write pages that perform multiple tasks

simultaneously.

Java is dynamic. Java programs carry with them substantial amount of run-time type

information that is used to verify and resolve accesses to objects at run time. This

makes is possible to dynamically link code in a safe and expedient manner.

Java’s exception handling. Java’s exception handling avoids the problem of checking

errors and handling them manually and brings run time error management into object-

oriented world. Access to other parts of the computer. Java programs can be

dynamically downloaded to all the various types of platform. Thus, it is portable.

Java is robust. It is a strictly typed language; it checks your code at compile time.

However, it also checks your code at run time. Thus the ability to create robust program

was given high priority in the design of java. The multi-platform environment of the

web

Introduction to JSP :

JavaServer Pages (JSP) is a technology based on the Java language and enables the development of dynamic web sites. JSP was developed by Sun Microsystems to allow server side development. JSP files are HTML files with special Tags containing Java source code that provide the dynamic content.

Introduction to Java Servlets:

Java Servlets provide the means through which Web Applications can be written in

Java. Web Applications allow a web site to be dynamic rather than straight static pages. In

other words, Servlets transform a web site with plain text and images into a rich interactive

environment for the user. In the beginning, Web Servers were made to just serve basic text

content and images. However, in order to provide an interactive environment, the web

server had to be extended to allow programs or scripts to be executed. This interface was

standardized as CGI.

The browser would load an HTML page consisting of some form elements such as

text boxes or check boxes. Then, the user would fill in the form and submit it to the web

server. The Web Server would take the form data and submit the data to the CGI program.

When the CGI program runs, it outputs the relevant HTML or other data back to the Web

Server, which acts as a middleman and sends the data back to the browser. The diagram

below illustrates the life cycle of a browser getting results from a CGI program.

Why Use Servlets?

Servlets have a variety of enhancements over plain CGI. The most fundamental

advantage of Servlets is that they are tightly coupled to the Web Server. If you recall from

the diagram above, the web server whose lifetime exists only during the particular user

request typically launches CGI scripts as a separate process. It turns out that the CGI model

is extremely inefficient and slow especially with interpreted languages such as Perl or Java.

First, operating systems typically incur some overhead in simply launching another

process. When you think about it, an operating system really has to do quite a bit. It has to:

Allocate memory for the process.

Copy information about the environment that the parent process was running in so that

there is a security context.

And the web server (parent process) must be constantly aware of the child process in

order to send the CGI output back to the user's web browser.

Second, an interpreted language typically has to load an entire program to interpret the

script before the program can even execute. In the case of Perl, this is the Perl executable.

In the case of Java, it is the Java binary. Even on a small program and a relatively fast

machine, a Java program can take a second or more to start.

Moreover we use Java Servlet because of the following reasons:

Efficient: As compared with the CGI. Java Servlet provides a much more efficient

method of handling user request. A CGI program needs to create a separate process for

each user request. When a Servlet receives a user request it simply spawns another

thread within the same process and handles the request. This makes it possible for

hundred and thousand of users to access the same servlet simultaneously without

bringing down the server. This was appositively impact on performance, generate

multiple request do not generate processes, as does a CGI program. Good server

implementations use thread pools to constrains the number of thread that can be used to

services the client request, and prevent the machine grinding to halt. Servlets also have

more alternatives than do regular CGI programs for optimization such as catching

previous computations, keeping database connection open, and the like.

Access to enterprise java APIs: Since Servlets are the extension of the java platform;

they can access all the java APIs. A java servlet can send and receive emails, invoke

method of remote objects using RMI or COBRA, obtain directory information using

the JNDI package, make use of Java Beans (EJB) or any other parts of java platform.

Platform Independence: The servlet code is compiled into byte code that are

interpreted by a platform-specific Java Virtual Machine (JVM) on the web server.

Since the Servlets themselves are made up of machine independent byte code, you can

freely move your Servlets to any other platform that supports Java.

Reusability: Creating component parts to an application is one-way to achieve reuse,

using object-oriented to encapsulate shared functionality is another Java uses both. It is

a completely object-oriented language and as such provides mechanism for reuse.

Modularity: When developing a complete server-side application, your program can large

and complex. It is always better to break down an application into discrete modules that are

responsible for specific task. When you do this, this makes your application very easy to

maintain and understand. Java Servlets, JSPs and Java Beans provide a way to modularize

your application-breaking application down into tiers and tasks.

7.2.2 Tomcat 6.0

Tomcat is a server container responsible for handling client request, passing the

request on to a servlet, and returning the request to a client. It includes many additional

features that makes it useful platform for developing and deploying web application and

web services.

Tomcat Directory Structure

Directory Name Description

bin Contains start-up/shutdown Scripts.

config Contains various configuration files including server.xml(Tomcat’s main configuration file) and web.xml that sets the default values for the various web application deployedTomcat.

doc Contains miscellaneous documents regarding Tomcat.

lib Additional class libraries and support files required by the Development tools.

logs This is where the Tomcat places its log and output files.

src The servlet APIs source files. These are only the empty interfaces and abstract classes that should be implemented by any servlet container.

webapps Contains sample web application.

7.2.3 PostgreSQL 8.2

PostgreSQL is an object-relational database system that has the features of traditional

commercial database systems with enhancements to be found in next-generation DBMS

systems. PostgreSQL is free and the complete source code is available.

There are several ways of measuring Postgresql8.2: features, performance, reliability,

support, and price.

Features :

PostgreSQL has most features present in large commercial DBMSs, like

transactions, subselects, triggers, views, foreign key referential integrity, and

sophisticated locking. We have some features they do not have, like user-defined

types, inheritance, rules, and multi-version concurrency control to reduce lock

contention.

Performance :

PostgreSQL's performance is comparable to other commercial and open source

databases. It is faster for some things, slower for others. Our performance is usually

+/-10% compared to other databases.

Reliability :

We realize that a DBMS must be reliable, or it is worthless. We strive to release

well-tested, stable code that has a minimum of bugs. Each release has at least one

month of beta testing, and our release history shows that we can provide stable,

solid releases that are ready for production use. We believe we compare favorably

to other database software in this area.

Support :

Our mailing lists provide contact with a large group of developers and users to help

resolve any problems encountered. While we cannot guarantee a fix, commercial

DBMSs do not always supply a fix either. Direct access to developers, the user

community, manuals, and the source code often make PostgreSQL support superior

to other DBMSs. There is commercial per-incident support available for those who

need it.

Price :

We are free for all use, both commercial and non-commercial. You can add our

code to your product with no limitations, except those outlined in our BSD-style

license stated above.

*********************************************

SYSTEM DESIGN

8.1 Introduction

The system design is a solution, a “how to” approach to the creation of a new

System. The design phase focuses on the detailed information of the system recommended

in the feasibility study. Emphasis is on translation of performance specification into design

specification. The design phase is a transition from a user-oriented document to a document

oriented to programmers or database personnel. System design goes through two phases of

development: -

1. Logical Design and

2. Physical Design

Logical design review the present system; prepare input and output specification;

make edit security, and control specification; detail the implementation plan, and prepare a

Logical design walkthrough. The physical design maps out details of physical system plan,

the system implementation, device a test and implementation plan, and specify any new

hardware and software.

8.1.1 Logical Design

A Data Flow Diagram shows the logical flow of system and defines the boundaries

of the system. Logical design specify the user specify the user needs a level of detail that

virtually determines the information flow into and out of the system and require data

resources. Logically design describes the, outputs, databases and procedures. All in a

format that meets user requirements.

8.1.2 Physical Design

The physical design produces the working system by defining the system

specification that tells the programmers exactly what the candidate system must do. The

physical design consist of the following steps:

1. Design of the physical system

Design the database and specify backup procedures.

Specify input/output media.

Design physical information flow through the system and physical design

walkthrough.

2. Plan system implementation

Prepare a conversion schedule and a target date.

Determine the training procedure, courses and timetable.

3. Devise a test and implementations plan and specify any new hardware and

software.

8.2 Structured Design:

Structured design is flow methodology. It is an attempt to minimize the complexity

and makes a problem manageable by subdividing it into smaller segments or module.

Structured design begins with system specification that identifies inputs and outputs

describe the functional aspects of the system.

Designing of project consist of number of steps. The design of the Integrated

Disease Surveillance Program (IDSP) consists of the following steps:

DATABASE DESIGN

INPUT /OUTPUT DESIGN

8.3 Database Design

The design of database describes how data should be organized around the user

requirements. It should be organized around the user requirements. It should be designed in

the line with the activity and volatility of the information and the nature of the storage

media and devices. One of the important steps in designing the database is normalization.

Normalization is the process of refining the data model and making the data more efficient.

This technique logically groups the data over the number of tables, which are independent

and contain no unnecessary or redundant data.

E R Diagram:

An entity-relationship (ER) diagram is a specialized graphic that illustrates the

interrelationships between entities in a database. ER diagrams often use symbols to

represent three different types of information. Boxes are commonly used to represent

entities. Diamonds are normally used to represent relationships and ovals are used to

represent attributes.

There are three basic elements in ER models:

Entities are the "things" about which we seek information.

Attributes are the data we collect about the entities.

Relationships provide the structure needed to draw information from multiple entities.

Table Design:

Normalization:

Basically database normalization is the process of efficiently organizing data in a

database. There are two goals of the normalization process: eliminate redundant data and

ensure data dependencies make sense. Both of these are worthy goals as they reduce the

amount of space a database consumes and ensure that data is logically stored.

First Normal Form:

The normalization process involves getting our data to conform to three progressive

normal forms, and a higher level of normalization cannot be achieved until the previous

levels have been achieved(there are actually five normal forms, but the last two are mainly

academic and will not be discussed). The first normal form or 1NF involves removal of

redundant data from horizontal rows. We want to ensure that there is no duplication of

data in a given row, and that every column stores the least amount of information

possible(making the field atomic).

In our case database has been normalized in 1NF, since there is not any non-atomic

field.

Second Normal Form:

Where the 1NF deals with redundancy of data across a horizontal row, second

normal form deals with redundancy of data in vertical columns. As stated earlier, the

normal forms are progressive, so to achieve 2NF, tables must already be in 1NF and there

must be a primary key in each table.

In our case database has been normalized in 2NF, since there is primary key in

every table upon which other key is dependant.

Third Normal Form:

In 3NF we are looking for data in our tables that is not fully dependant on primary

key, but dependant on other value in the table. In other words there must not be any

transitive dependency in out tables.

In our case database has been normalized in 3NF, since there is not any transitive

dependency in our tables.

Considering by various records regarding the IDSP (Form S) system, the design of

the database is developed so that it can satisfy the entire requirement and should be

efficient enough. The database consisting of 9 tables. All the tables are interrelated using

the key code that is unique in each case entity.

State (TABLE)

This is the table containing data about the states. In this project this table contain

data as state_code and state_name.

District (TABLE)

This is the table containing the data about the districts. In this project this table

contain data as district_code, district_name, district_population.

Block (TABLE)

This is the table containing the data about the blocks. In this project this table

contain data as block_code, block_name, block_population.

Reporting Unit (TABLE)

This is the table containing the data about the Reporting Units. In this project this

table contain data as reporting_code, reporting_name, reporting_population.

Disease (TABLE)

This is the table containing the data about the Diseases. In this project this table

contain data as disease_code, disease_name.

Disease_Threshold (TABLE)

This is the table containing the data about the disease threshold. As each district

has different threshold values ,to maintain those value this table is used. In this project

this table contain data as disease_code, threshold_value, district_code, state_code .

Patient_info (TABLE)

This is one of the important table in this project. As main issue of IDSP is to

maintain the details about the effected people by different disease in the country. So

this table maintain the those details . The different data contains in this table are nos of

effected people in different disease, state_code, district_code, block_code, ru_code,

week_no, year.

User (TABLE)

This table contain the user information of IDSP. The data contain in this table as

user_ID, password,district_code, state_code.

Master_table (TABLE)

This table contain the user information that are used for official purpose, like the

name of the supervisor under whom the user worked, who gave the permission to the

user etc. The data contain in this table as user_ID, address, permission_from,

permission_to etc.

1.Table Name: State


state_code character varying 2state_name character varying 50

Constrains: Primary Key (state_code)

2.Table Name: District


district_code character varying 3state_code character varying 2district_name character varying 50district_pop bigint -

Constrains: Primary Key (state_code, district_code)

Foreign Key (state_code)

3.Table Name: Block


block_code character varying 3district_code character varying 3state_code character varying 2block_name character varying 50block_pop bigint -

Constrains: Primary Key (state_code, district_code, block_code)

Foreign Key (state_code, district_code)

4.Table Name: Reporting Unit


reporting_code character varying 5block_code character varying 3district_code character varying 3state_code character varying 2

reporting_name character varying 50reporting_pop bigint -

Constrains: Primary Key (state_code, district_code, block_code, reporting_code

Foreign Key (state_code, district_code, block_code)

5.Table Name: Disease


disease_code character varying 5disease_name character varying 50

Constrains: Primary Key (disease_code)

6.Table Name: Disease_threshold


disease_code character varying 5state_code character varying 2district_code character varying 3threshold_value integer -

Constrains: Primary Key (state_code, district_code, disease_code)


7.Table Name: patient_info


state_code character varying 2district_code character varying 3block_code character varying 3myear integer -name_worker character varying 30supervisor_name

character varying 30

reporting_unit character varying 30dt_week_from date -id_dsu character 3fever_c_m integerfever_c_f integerfever_d_m integerfever_d_f integer

wtrystools _c_m

integer

wtrystools _c_f integerwtrystools _d_m

integer

wtrystools _d_f integerJaundice_c_m integerJaundice_c_f integerJaundice_d_m integerJaundice_d_f integerparalysis_c_m integerparalysis_c_f integerparalysis_d_m integerparalysis_d_f integerunusualsympt_c_m

integer

unusualsympt_c_f

integer

unusualsympt_d_m

integer

unusualsympt_d_f

integer

weekno integerlate character 1mdate Timestamp without

time zone

Constrains: Primary Key (state_code, district_code, block_code, reporting_unit, myear,

weekno)

Foreign Key (state_code, district_code, block_code, reporting_unit)

8.Table Name: User_Table


u_id character varying 10pwd character varying 10district_code character varying 3state_code character varying 2

Constrains: Primary Key (u_id)


9.Table Name: Master_Table


u_id character varying 10add character varying 50remarks character varying 30permission_frm character varying 30permission_to character varying 30user_status character varying 30date Date -

Constrains: Primary Key (u_id)

Foreign Key (u_id)

SYSTEM TESTING AND

IMPLEMENTATION

9. SYSTEM TESTING:

9.1 Overview:

Once source code has been generated, software must be tested to uncover and

correct as many errors as possible before delivering to the customer. Thus the goal is to

design a series of test cases that have a high like hood of finding errors. Testing begins in

the small and progresses to the large. This means that early testing focuses on a single

component to uncover errors in program logic and function. After individual components

are tested, they must be integrated. Testing continues as the software be constructed.

Finally, a series of high order tests are executed once the full software is operational.

9.2 Introduction:

During the system testing, the system is used experimentally to ensure that the

software does not fail, that is, it run according to its specifications and in the way user

expect.

System testing is vital to the success of the system. The idea behind testing is to

come up with the errors that otherwise may become an obstacle during the functioning of

the project. Test cases are devised with this purpose in mind. A test case is a set of data that

the system will process as normal input. However, the data are created with the express

intent of determining whether the system will process them correctly.

The importance of software testing and its limitations with respect to software

quality cannot be over emphasized. Because of its importance and the large amount of

project effort associated with it, it becomes necessary to the test the system before its

implementation.

Necessity of system testing:

Some of the necessities of testing process include the following:

1. Once a system has been designed, it is necessary to undergo an exhaustive testing

before installing the system. This is important because in some cases a small system

error, not detected and corrected before installation, may explode into much larger

problem later on.

2. Inadequate testing or non-testing may lead to errors that may be costly when they

appear months later on.

3. Another necessity for the system testing is its utility as a user oriented vehicle

before implementation, since even the best program is worthless if it does not meet

the user requirement.

9.3 Types of testing:

Some types of testing that are used in the system are:

String testing (Input Validation)

In this type of testing, the input data are tested to examine whether they confirm to

the given standards. Client-side and Server-side Validation codes are written to catch my

invalid input data.

Unit Testing:

Unit testing focuses verification effort on the smallest unit of software design- the

software component or module. In unit testing, each module are taken and tested

extensively to uncover as many errors as possible.

Integration Testing:

Integration testing is a systematic technique for constructing the program structure

while at the same time conducting tests to uncover errors associated with interfacing. The

objective is to take unit tested components and build a program structure that has been

dictated by design.

Regression Testing:

Regression testing is type of integration testing. In this testing, some subset of tests

that have already been conducted is re-executed to ensure that changes have not been

propagated unintended side effects.

Validation Testing:

Validation Testing is successful when a software functions in a manner that can be

reasonably expected by the customer. Reasonable expectations are defined in the system

Requirement Specification that describes all user- visible attributes of the software. Test

cases are designed to ensure that all the functional requirements are satisfied, all the

behavioral characteristics are achieved and all the performance requirements are attained.

Various modules are tested thoroughly to see whether all the requirements that were

specified in SRS are met.

System Testing:

System Testing is series of different tests whose primary purpose is to fully exercise

the web-based system. The some essential tests that are done are:

Recovery Testing:

Recovery testing is system test that forces the system to fail in a variety of

ways and verifies that recovery is performed either automatically or manually. Test

has been conducted to put an array out of bound and check weather the system is

able to handle this situation or stops functioning all together.

Security Testing:

Security testing attempt to verify that protection mechanism built into the

system will, in fact protect it from improper penetration. During testing, the tester

plays the role of the individual desires to penetrate the system. As the system being

developed in web based system and is a project undertaken by the Health Ministry

of India, it needs to be fool proof as far as security is concerned.

1. Anybody who does not have a Login ID and Password cannot enter to the

system to add, delete and update the data.

2. A user can register him/herself into the system if he/she is a valid health worker.

He has to submit all necessary details at the time of registration.

3. The connectivity to the database is secure, so that only authorized user can

access the database.

9.4 System Implementation:

A crucial phase in the systems life cycle is successful implementation of new

system. The new design implementation simply means converting a new system design

into an operational one. This involve creating compatible files , training and operating staff

and installing hardware and terminal etc. before the system is up and running. The

objective of implementation is to put the tested system into operation while holding costs

and risks.

After a through testing of the system as described above, the system is ready for

implementation. The system has been demonstrated recently to the WHO person and

officers related to IDSP.

10. SYSTEM SECURITY

Every candidate system must provide built in features for security and integrity of data. Without

safeguard against unauthorized access, fraud, embezzlement, fire and natural disaster, a system

could be so vulnerable as to threaten the survival of the organization. The end user is always

concerned about security along with increased dependence on the computer. In the system

development, the developer and the system analyst must consider measures for maintaining data

integrity and controlling security at all times. This involves built-in hardware features, programs

and procedure to protect candidate system from unauthorized access.

Physical Security

The most costly loss in software is program error. It is possible to eliminate such error proper

testing routines. Parallel runs should be implemented whenever possible. Physical security

provides safeguards against the destruction of hardware, databases and documentation; fire,

flood, theft, sabotage and cave dropping; and loss of power through proper backup.

Database Security

The proper use of the file library is another important security features. This involves

adequate file backup and reliable personal to handle file documentation when needed.

File backup means keeping duplicates copies of the master and the other key files and

storing them in suitable environmental conditions.

Application Security

The complexity of the system makes auditing necessary. Neither the auditor nor the user can

verify the system check itself. The internal controls required means that the programmer and

analyst build controls into every system. Developing a corporate auditing policy will ensure

that future system meet the minimum requirements for security and control against fraud and

embezzlement.

Transaction Entry

A logical failure occurs when activity to the database is interrupted with no chance of

completing the currently executing transactions. When the system is and running again it is

not known whether or not modification are still in memory or were made to the actual data.

Through still readable, the database may be inaccurate.

11. FUTURE ENHANCEMENT:

In this module I developed the system only for Form S and also on creation of backup file, uploading the file and restore it on the central server.

Moreover there are various tasks are there in the IDSP system. This module can be integrated with the other module in the IDSP system, like Form P, Form L, and Form W etc also with IDSP GSI system.

This system being web- based and an undertaking of Health Ministry, needs to be thoroughly tested and hence better encrypted facility and be developed to enhance the security of the system. Only after the system is fool proof then the system be uploaded to Internet.

13. PROJECT SCREEN SHOTS:

IDSP Home Page:

IDSP select form type page:

In this page appears after successfully logged in by the authenticated user. Here user will select the form type he/she going to submit/update or delete.

Form S Detail selection page:

In this page the user will select the necessary option for Form S submission.The user will select mainly Block Name, Reporting Unit Name, Week No (From and To).

Form S Submit Form:

In this form the user will submit all details of Form S. After submitting all details the user will click submit button to stored datas into server.

Form Submit validation:

After successfully inserting the datas unto server, this validation will appear.

Form S update form:

Form S update validation:

Form S update/delete validation if data is not available:

Form S delete form:

IDSP Form S report menu page:

In this menu the user will select the diseases types and report types for which he/she wantsto view the report.

IDSP report view district wise:

Form S district wise bar chart view:

Form S district wise bar chart view( weekly):

Form S district wise line chart view:

Form S district wise line chart view (weekly):

Back up file upload page:

12. CONCLUSION:

The objective of the project was to develop IDSP (Form S) system, which helps to perform the function, related to health status to the people of India.

It was a good experience developing this project. Working together in a team helped me to communicate better. I understand the importance of planning and designing as a part of software development. The concept of peer-review helped to rectify the problems as and when they occurred and also helped me to get some valuable suggestions that were incorporated by me.

Developing the project has helped me to gain some experience on real-time development procedures.

Bibliography:

Books:

Complete Reference in JAVA

By Herbert Schildt

Java for the Web with Servlets, JSP, and EJB

By Budi Kurniawan

System Analysis and Design

By Elias M. Awad

Database System Concepts, Fifth Edition

By A. Silberschatz, H. F. Korth, and S. Sudarshan.

Mastering Java Script

By James Jaworski

Websites:

www.java.sun.com www.devguru.com www.w3school.com www.roseindia.com www.javaworld.com

Documents

IDSP Report