Online complaint Management system

TABLE OF CONTENTS
Chapter No Topic Name Page No
List of Acronyms
IV
List of Figures
V
List of Tables
VI
Abstract
VII
1

INTRODUCTION 01
1.1

Purpose 01 1.2

Product Perspective 01 1.3

Site Adaptive Requirements 02

2

LITERATURE SURVEY 03
2.1 Introduction 03 2.2 Proposed System 03
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
2.3 Module Description 04 2.4 Reports 05
3 REVIEW OF THE STATE OF ART 07
3.1

Feasibility Study 07 3.1.1 Economical Feasibility 07 3.1.2

Operational Feasibility 07 3.1.3

Technical Feasibility 07 3.2

Software Requirements Specifications 08 3.3

Nonfunctional Requirements 09 3.4

System Process Model 10

4

SYSTEM DESIGN 18
4.1 ER Diagram 18
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
4.2 Data Dictionary 18 4.3 Data Flow Diagrams 20

4.4 Unified Modeling Language 21 4.4.1 Use Case Diagram 23 4.4.2 Activity Diagram 26 4.4.3
Collaboration Diagram 27 4.4.4 Class Diagram 29 4.4.5 Sequence Diagram 30
5
IMPLEMENTATION 32
5.1 Coding

32
6

SYSTEM TESTING 39
6.1 Testing 39 6.2 Testing Strategy 39 6.3 Test Approach 43 6.4 Test Cases 44
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
7 SCREEN SHOTS 47
7.1 Screens 47
8

CONCLUSION

57
8.1 Summary 57 8.2 Future enhancements 58
REFERENCES 59

LIST OF ACRONYMS
S NO Acronym Description Page No
1 SRS Software Requirement Specification 08 2 DFD Data Flow Diagram 19 3 UML Unified Modeling
Language 20
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
LIST OF FIGURES AND TABLES LIST OF FIGURES S NO Figure No Figure Name Page No
1

3.1 Spiral Model 10 2 3.2

Designing Stage Diagram
12 3 3.3
Development Stage Diagram
13 4 3.4
Integration Stage 14 5 3.5 Installation & Acceptance 15 6 4.1 ER Diagram 17 7 4.2 Use Case Diagram 23
8 4.3 Activity Diagram 25 9 4.4 Class Diagram 28
LIST OF TABLES
S NO Table Number Table Name Page No
1
4.1 Product Information 19
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
2 4.2 Complaint Details 19
ABSRACT
Customers may have complaints about its products. They will be given an product id for each product,
where they can send complaint based on the product id when they find a fault product .The complaints
can be assigned to different persons and will get tracked to closure. The “Online Complaint Management
System” (OCMS) software is an independent application. It is a self-contained product.

The traditional forum system consists of public meeting or presentation involving a discussion usually
among experts and often including audience participation. In General the forums may belong to specific
issues like WAP forum, MATH forum, Economic forum, Freedom forum, Software forum etc. In
particular, Consumer Forum deals with customer rights against vendors or the manufactures of the faulty
products. Our Web Enabled Call Center (WECC) does all the jobs that are done in conventional system
but, here, everything is done in more formal and efficient manner. This system acts as an interface
between the customers and call engineers thereby enabling them to forward their complaints to the
appropriate call engineer. Hence, making the work easy for both the complaint raiser and the person who
resolves the complaint. Here, in complaint tracking, it fulfills different requirements of administrator and
customer more efficiently.
Key Words:
Consumer Forum, Economic Forum, Web Enabled Call Center (WECC), Fault Product, Freedom Forum,
Software Forum.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
CHAPTER1 INTRODUCTION
1.1 Introduction
An organization’s customers may have complaints about its products. They will be given an product id
for each product, where they can send an email when they have a complaint to register. The complaint id
will get converted to complaints and get assigned to the persons handling that product. The complaints
can be assigned to different persons and will get tracked to closure. The person handling the complaint
will have the facility to communicate with the customer via emails through the system.
1.2 Product Perspective
The “Online Complaint Management System” software is an independent application. It is a self-
contained product. The system interfaces, user interfaces and hardware interfaces related with this
software are defined as follows.
1.2.1 System Interfaces
The client systems should be able to share the data available in the data base through the network
connection.
1.2.2 User Interfaces
The screen formats and menu structure should be in such a way that even have users will find it easy to
use. The product must be use-friendly and very inter-active. The functionality provided by the system like
displaying error messages should adapt itself to the different users of the software.
1.2.3 Software Interfaces
Operating System : Any Windows OS. Client Software : Any Web Browser (Internet Explorer).
Communication Network : Internet.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
Intermediate Language : JVM.
1.2.4 Memory Constraints
The system would require disk space of 10 GB and a 256 MB HDD and 64 MB RAM for client systems.
Operation
The users can first make a register a complaint a particular based on the product id. The system provides
the customer with a pin code which gives him access to either make any changes in his reservation or
cancel a reservation. These must also be back up of data to enable any easy recovery from any features.
1.3 Site Adaptive Requirements
The “OCMS” software is an independent and self-contained product and no modification are required to
adapt to a particular installation.
Product Functions
•

The major functions include •

Providing product complaint details •

Complaint registration for a particular product id, date and time and also providing with a pin code as a
customer address. •

Allowing the customer to view sstatus of the complaint. •

Displaying a report of the number of complaints for a particular product.

Advantages:
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇
•

Very less time required. •

Very less cost.

Risk is low. •

No technical knowledge is needed for the user. •

Easy to maintain
CHAPTER2
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
LITERATURE SURVEY
2.1 Introduction:

The customer has to visit forums and made complaint against a faulty product. The complaint will be
discussed in the presence of customer, vendor and a team of expert committee along with judge. The final
decision making is a time consuming so the customer has to revisit the forum to get the result.
2.2 Proposed System:

Our Web Enabled Call Center does all the jobs that are done in conventional system but, here, everything
is done in more formal and efficient manner. This system acts as an interface between the customers and
call engineers thereby enabling them to forward their complaints to the appropriate call engineer. Hence,
making the work easy for both the complaint raiser and the person who resolves the complaint. Here, in
complaint tracking, it fulfills different requirements of administrator and customer more efficiently. The
specific purpose of the system is to gather and resolve complaints that arise in different projects handled
by the organization.
2.3 Existing System:

The traditional forum system consists of public meeting or presentation involving a discussion usually
among experts and often including audience participation. In General the forums may belong to specific
issues like WAP forum, MATH forum, Economic forum, Freedom forum, Software forum etc. In
particular, Consumer Forum deals with customer rights against vendors or the manufactures of the faulty
products.

Disadvantages of Existing System:

The customer has to visit forums and made complaint against a faulty product. The complaint will be
discussed in the presence of customer, vendor and a team of expert committee along with judge. The final
decision making is a time consuming so the customer has to revisit the forum to get the result.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
The site would use a database to hold customers complaints and reports generated by the technical team
.online compliant management system contains all complaint details .a complaint inventory contains all
complaints with its status reports .the system provides the facility if the customers gives the wrong
information then he
󰁇󰁇󰁇󰁇
edit the complaint details .to provide the proper information to the system. The modern online complaint
management system is comprehensive suite of identify the fault products based on the customers provided
information and generating reports for the fault products.
2.4 Module Description:
2.4.1 Registration Module
: This module is dedicated to register all the complaints from the customers whenever they come to
compliant. The process of this module is divided into two sub processes in which one registers the
complete details of the customer who wants to submit the compliant, other registers the complete details
of the compliant
2.4.2 Monitoring Module
: This module is dedicated to monitoring the complaints by searching the complaints and updating the
status of complaints at any time. The process of this module is divided into two sub processes in which
one searches for complaints and other updates the status.
2.4.3 Reports Module
: Report generation module is dedicated to produce reports based on the information to given by the user.
The process of this module is main divided into two sub processes in which one gives summary report
other gives the detailed report.
2.4.4 Administration Module
:
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Administration module is dedicated to administrate the users, divisions, categories, sections and Eros etc.
2.5 Reports:

The reports generated in project depict the up to date information about the current status of various
records. The various types of reports that will be generated in this project are as mentioned below.
2.5.1 Time oriented reports
: Time oriented reports give the information of complaints according to the time period given. The time
oriented reports are daily, weekly, monthly, yearly and also includes reports on certain period of time etc.
2.5.2 Status oriented reports
: Status oriented reports give the information of complaints according to the status given. The status
oriented reports are completed, pending and delayed reports.
2.5.3 Division wise reports
: Division wise reports give the information of complaints according to the division given.
2.5.4 Compliant wise reports:
Compliant wise reports give the information of complaints according to the compliant type given.
2.5.5 Employee wise reports:
Employee wise reports give the information of complaints according to the employee referred to solve the
compliant.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
CHAPTER3 REVIEW OF THE STATE OF ART
3.1 FEASIBILITY STUDY
Feasibility study is an important phase in the software development process. It enables the developer to
have an assessment of the product being developed. It refers to the feasibility study of the product in
terms of outcomes of the product, operational use and technical support required for implementing it.
Feasibility study should be performed on the basis of various criteria and parameters. The various
feasibility studies are: • Economic Feasibility • Operational Feasibility • Technical Feasibility
3.1.1 ECONOMIC FEASIBILITY
It refers to the benefits or outcomes we are deriving from the product as compared to the total cost we are
spending for developing the product. If the benefits are more or less the same as the older system, then it
is not feasible to develop the product.
3.1.2 OPERATIONAL FEASIBILITY
It refers to the feasibility of the product to be operational. Some products may work very well at design
and implementation but may fail in the real environment. It includes the study of additional human
resource required and their technical expertise.
3.1.3 TECHNICAL FEASIBILITY
It refers to whether the software that is available in the market fully supports the present application. It
studies the pros and cons of using particular software for the development
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
and its feasibility. It also studies the additional training needed to be given to the people to make the
application work.
3.2. SOFTWARE REQUIREMENTS

SPECIFICATIONS

Software Requirement Specification (SRS) is the starting point of the software developing activity. As
system grew more complex it became evident that the goal of the entire system cannot be easily
comprehended. Hence the need for the requirement phase arose .The software is initiated by the client
needs .The SRS is the means of translating the ideas of the minds of the clients (the i/p) into a formal
document (the o/p of the requirement phase). The SRS phase consists of two basic activities:
Problem or requirement Analysis:
The process is order and more nebulous of the two, deals with understand the problem, the goal and
constraints.
Requirement Specification
Here, the focus is on specifying what has been found giving analysis such as representation, specification
languages and tools, and checking the specifications are addressed during this activity. The requirement
phase terminates with the production of the validate SRS document. Producing the SRS document is the
basic goal of this phase. The Software Requirements Specification (SRS) begins the translation process
that converts the software requirements into the language the developers will use. The SRS draws on the
use-cases from the User Requirement Document (URD) and analyzes the situations from a number of
perspectives to discover and eliminate inconsistencies, ambiguities, and omissions before development
progresses significantly under mistaken assumptions.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Role of SRS:
The Purpose of the software requirement specification is to reduce the communication gap between the
clients and developers. Software requirement specification is the medium, through which the client and
user needs are accurately specified. It forms the basis of software development. A good SRS should
satisfy all the parties involved in the system.
3.2.1 Software Requirements:
Operating System : Any Windows OS. Client Program : Internet Explorer. Server Program : Apache
Tomcat 6.0. IDE : My Eclipse 8.6. Editors : Adobe Dreamweaver, Photoshop. Language : JAVA (JSP &
JDBC) & HTML. Client side Scripting : Java script. Database software’s : Oracle10g. Intermediate
Language : JVM.
3.2.2 Hardware Requirements:
Processor : P4 Ram : 512 MB Communication Channel : Internet Hard Disk : 10 GB Monitor : VGA
Color (256)
3.3 Non-functional Requirements: Performance

1.
Response time of the Online Complaint Management System should be less than 2 second most of the
time. Response time refers to the waiting time while the system accesses, queries and retrieves the
information from the databases (DB-user, DB schedule etc) (A local copy of flight schedule database is
maintained as DB schedule to reduce this access time).
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
2.
OCMS shall be able to handle at least 1000 transactions/inquiries per second.
3.
OCMS shall show no visible deterioration in response time as the number of users or flight schedule data
increases.
Reliability

1.
OCMS shall be available 24 hours a day, 7 days a week.
2.
OCMS shall always provide real time information about flight availability information.
3.
OCMS shall be robust enough to have a high degree of fault tolerance. For example, if the user enters a
negative number of passengers or a value too large, the system should not crash and shall identify the
invalid input and produce a suitable error message.
4.
OCMS shall be able to recover from hardware failures, power failures and other natural catastrophes and
rollback the databases to their most recent valid state.
Usability
1.
OCMS shall provide a easy-to-use graphical interface similar to other existing reservation system so that
the users do not have to learn a new style of interaction.
2.
The web interface should be intuitive and easily navigable Users should be able to understand the menu
and options provided by OCMS .
3.
Any notification or error messages generated by OCMS shall be clear, succinct, polite and free of jargon.
Integrity
1.
Only system administer has the right to change system parameters, such as pricing policy etc. The system
should be secure and must use encryption to protect the databases.
2.
Users need to be authenticated before having access to any personal data.
3.4 System Process Model:
The Software Life Cycle
1.

Encompasses all activities from initial analysis until obsolescence 2.

Formal process for software development a.

Describes phases of the development process

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
b.

Gives guidelines for how to carry out the phases 3.

Development process a.

Analysis b.

Design c.

Implementation d.

Testing e.

Deployment 4.

A structured set of activities required to develop a software system •

Specification; •

Design; •

Validation; •

Evolution. A software process model is an abstract representation of a process. It presents a description of

a process from some particular perspective.
Generic software process models
•

The waterfall model and distinct phases of specification and development. •

Evolutionary development •

Specification, development and validation are interleaved. •

Component-based software engineering There are many variants of these models e.g. formal development
where a waterfall-like process is used but the specification is a formal specification that is refined through
several stages to an implementable design.
Spiral Model
Each cycle involves the same sequence of steps as the waterfall process model. Breaks development
process down into multiple phases. Early phases focus on the construction
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
of prototypes. Lessons learned from development of one prototype can be applied to the next iteration.

Figure 3.1 Spiral model

Stages in SDLC:
♦

Requirement Gathering
♦
Analysis
♦

Designing
♦

Coding
♦

Testing
♦

Maintenance
3.4.2 Requirements Gathering

stage:
The requirements gathering process takes as its input the goals identified in the high-level requirements
section of the project plan. Each goal will be refined into a set of one or more requirements. These
requirements define the major functions of the intended application, define operational data areas and
reference data areas, and define
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
the initial data entities. Major functions include critical processes to be managed, as well as mission
critical inputs, outputs and reports. A user class hierarchy is developed and associated with these major
functions, data areas, and data entities. Each of these definitions is termed a Requirement. Requirements
are identified by unique requirement identifiers and, at minimum, contain a requirement title and textual
description.
3.4.3 Analysis Stage:
The planning stage establishes a bird's eye view of the intended software product, and uses this to
establish the basic project structure, evaluate feasibility and risks associated with the project, and describe
appropriate management and technical approaches .The most critical section of the project plan is a listing
of high-level product requirements, also referred to as goals. All of the software product requirements to
be developed during the requirements definition stage flow from one or more of these goals. The
minimum information for each goal consists of a title and textual description, although additional
information and references to external documents may be included. The outputs of the project planning
stage are the configuration management plan, the quality assurance plan, and the project plan and
schedule, with a detailed listing of scheduled activities for the upcoming Requirements stage, and high
level estimates of effort for the out stages.
3.4.4 Designing Stage:
The design stage takes as its initial input the requirements identified in the approved requirements
document. For each requirement, a set of one or more design elements will be produced as a result of
interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in
detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business
rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data
dictionary. These design elements are intended to describe the software in sufficient detail that skilled
programmers may develop the software with minimal additional input.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Figure: 3.2 Designing Phase When the design document is finalized and accepted, the RTM is updated to
show that each design element is formally associated with a specific requirement. The outputs of the
design stage are the design document, an updated RTM, and an updated project plan.
3.4.5 Development (Coding) Stage:
 The development stage takes as its primary input the design elements described in the approved design
document. For each design element, a set of one or more software artifacts will be produced. Software
artifacts include but are not limited to menus, dialogs, data management forms, data reporting formats,
and specialized procedures and functions. Appropriate test cases will be developed for each set of
functionally related software artifacts, and an online help system will be developed to guide users in their
interactions with the software.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Figure: 3.3 Development Stage The RTM will be updated to show that each developed artifact is linked to
a specific design element, and that each developed artifact has one or more corresponding test case items.
At this point, the RTM is in its final configuration. The outputs of the development stage include a fully
functional set of software that satisfies the requirements and design elements previously documented, an
online help system that describes the operation of the software, an implementation map that identifies the
primary code entry points for all major system functions, a test plan that describes the test cases to be
used to validate the correctness and completeness of the software, an updated RTM, and an updated
project plan.
3.4.6 Integration & Test Stage:
During the integration and test stage, the software artifacts, online help, and test data are migrated from
the development environment to a separate test environment. At this point, all test cases are run to verify
the correctness and completeness of the software. Successful execution of the test suite confirms a robust
and complete migration
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
capability. During this stage, reference data is finalized for production use and production users are
identified and linked to their appropriate roles. The final reference data (or links to reference data source
files) and production user list are compiled into the Production Initiation Plan. Figure: 3.4 Integration &
Test Stage The outputs of the integration and test stage include an integrated set of software, an online
help system, an implementation map, a production initiation plan that describes reference data and
production users, an acceptance plan which contains the final suite of test cases, and an updated project
plan.
3.4.7 Installation & Acceptance Test:
During the installation and acceptance stage, the software artifacts, online help, and initial production data
are loaded onto the production server. At this point, all test cases
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
are run to verify the correctness and completeness of the software. Successful execution of the test suite is
a prerequisite to acceptance of the software by the customer. After customer personnel have verified that
the initial production data load is correct and the test suite has been executed with satisfactory results, the
customer formally accepts the delivery of the software. Figure: 3.5 Installation & Acceptance Stage The
primary outputs of the installation and acceptance stage include a production application, completed
acceptance test suite, and a memorandum of customer acceptance of the software. Finally, the PDR enters
the last of the actual labor data into the project schedule and locks the project as a permanent project
record. At this point the PDR "locks" the project by architecture software items the implementation map,
the source code, and the documentation for future reference.
3.4.8 Maintenance:
Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study,
understanding of documentation later employees will be assigned work and they will undergo training on
that particular assigned category.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
CHAPTER4 SYSTEM DESIGN
4.1 ER DIAGRAM
The ER diagram is drawn to have a better understanding of the whole scenario, it was used to
conceptualize the phenomena, actions and interactions between various entities and to arrive at the
specific requirements in a comprehensive manner. The ER diagram is attached with this SRS. Figure: 4.1
ER Diagram
4.2 DATA DICTIONARY
After carefully understanding the requirements of the client the the entire data storage requirements are
divided into tables. The below tables are normalized to avoid any anomalies during the course of data
entry
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Table: 4.1 Product Information Table: 4.2 Complaint Details
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
4.3 DATA FLOW DIAGRAMS

A
data flow diagram
(
DFD
) is a graphical representation of the "flow" of data through an information system. A data flow diagram
can also be used for the visualization of data processing (structured design). Dataflow diagrams can be
used to provide the end user with a physical idea of where the data they input, ultimately has an effect
upon the structure of the whole system from order to dispatch to restock how any system is developed can
be determined through a dataflow diagram.
4.3.1 Developing a DFD
Developing Top-Down Approach
•

The system designer makes a context level DFD ,which shows the interaction (data flows) between the
system (represented by one process) and the system environment (represented by terminator).
•

The system is decomposed in lower level DFD (Zero) into a set of processes, data stores , and the data
flows between these processes and data stores.
•

Each process is then decomposed into an even lower level diagram containing its sub process.
•

This approach then continues on the subsequent sub processes , until a necessary and sufficient level of
detail is reached which is called the primitive process
4.3.2 DFD Symbols
In the DFD, there are four symbols 1.

A square defines a source(originator) or destination of system data 2.

An arrow identifies data flow. It is the pipeline through which the information flows
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
3.

A circle or a bubble represents a process that transforms incoming data flow into outgoing data flows. 4.

An open rectangle is a data store, data at rest or a temporary repository of data Process that transforms
data flow Source or Destination of data Data flow Data Store
4.4 UNIFIED MODELING LANGUAGE (UML)
The Unified Modeling language is a standard language for specifying, visualizing, constructing and
documenting the software system and its components. It is a graphical language, which provides a
vocabulary and set of semantics and rules. The UML focuses on the conceptual and physical
representation of the system. It captures the
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
decisions and understandings about systems that must be constructed. It is used to understand, design,
configure, maintain and control information about the systems.
Visualizing:
Through UML we view an existing system and ultimately we visualize how the system is going to be
after implementation. Unless we think, we cannot implement. UML helps to visualize, how the
components of the system communicate and interact with each other.
Specifying:
Specifying means building models that are precise, unambiguous and complete UML addresses the
specification of all the important analysis design, implementation decisions that must be made in
developing and deploying a software system.
Constructing:
UML models can be directly connected to a variety of programming language through mapping a model
from UML to a programming language like JAVA or C++ or VB. Forward Engineering and Reverse
Engineering is possible through UML.
Documenting:
The Deliverables of a project apart from coding are some Artifacts, which are critical in controlling,
measuring and communicating about a system during its development viz. requirements, architecture,
desire, source code, project plans, tests, prototypes, releasers etc.
Diagrams in UML:
Diagrams are graphical presentation of set of elements. Diagrams project a system, or visualize a system
from different angles and perspectives. The UML has 9 diagrams. These diagrams can be classified into
the following groups.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Static:
1. Class Diagrams. 2. Object Diagrams. 3. Component Diagrams. 4. Deployment Diagrams.
Dynamic:
1. Use-Case Diagram. 2. Sequence Diagram 3. Collaboration Diagram. 4. State Chart Diagram 5.
Activity Diagram.
4.4.1 USE CASE DIAGRAMS
Use case Diagram:
These diagrams Shows a set of use cases and actors and their relationships. These diagrams illustrate the
static use case view of a system and are important in organizing and modeling the behaviors of a system.
The Use case diagram is used to identify the primary elements and processes that form the system. The
primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram
shows which actors interact with each use case.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Client Module :
Figure: 4.2 Client Module Use Case Diagram
Administrator Module:
Figure: 4.3 Administrator Module Use Case Diagram

RegisterComplaint
Login
viewstatus
Logout
client
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Technical team module:
Figure: 4.4 Technical Team Module Use Case Diagram
4.4.2 ACTIVITY DIAGRAMS
Activity diagrams are used to represent the flow of statements. These are also useful to represent the
business and operate on step by step work flow of components in a system. It shows the overall flow
control.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Administrator Module:
Figure: 4.5 Administrator Module Activity Diagram
Check complaintsview complaintssend compliants to tech
teamverfificationdisplayerrormessageupdtae stautsSend mailsLogin\RegisterLogOutfailssuccess
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Technical team Module:
Figure: 4.6 Technical Team Module Activity Diagram

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
4.4.3 Collaboration diagram:
Figure: 4.7 Collaboration Diagram

admin : Adminstartorlogin : loginDb : DBUtilslogout : Logoutmon : MonitorComplaint

2: status( )9: commit( )10: 3: openConnection( )4: searchComplaintDetails( )8: update( )5: report( )6:
createUsers7: showStatus()1: login( )11: logout( )13: sessionClose()12: closeConnection()
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
4.4.4 CLASS DIAGRAM
Figure: 4.7 Class Diagram

Coustmerproductid : Stringname : Stringmiddlename : Stringlastname : Stringemail_id :

Stringaddress :
StringsetProductID()setName()setMiddleName()setLastName()setEmail()setAddress()opname()A
dminstartorUsername : Stringpassword :
Stringcreateusers()createdivisions()opname()RegisterComplaintcomplainttypedescriptionpostcom
plaint()loginusername : Stringpassword : Stringconformpassword :
Stringcheck()updatestatusisupdated : BooleanupdateComplaint()CheckstatuscomplaintId :
java.lang.StringshowComplaints()status()remaider()MonitorComplaintcomplaintid :
Stringcomplainttype : Stringdate : Datestatus()report()Logoutsessionout :
Integerlogout()DBUtilsisLoggedIn : BooleanisSesstionOut :
BooleanopenConnection()close()searchComplaintDetails()update()commit()sendCompalintDatail
s()showStatus()
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
4.4.5 SEQUENCE DIAGRAM Customer module :
Figure: 4.8 Sequence Diagram-Customer Module

: Coustmer : RegisterComplaint
: Checkstatusdb : DBUtilscheckstatus()openConnection(
)showcomplaintStatus()acknowledgement()update()postcomplaint( )commit()rollback ()login()logout
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Administrator Module:
Figure: 4.9 Sequence Diagram-Administrator Module

admin : Adminstartorlogin : login

Db : DBUtilslogout:Logout
mon:MonitorComplaintlogin( )status( )searchComplaintDetails( )update()commit( )report(
)showStatus()createUsersopenConnection()logout( )closeConnection()sessionClose()
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
CHAPTER 5 IMPLEMENTATION
Implementation phase will give the idea about how are we doing of project, in how many phases we are
implementing the project.
5.1 CODING:
# MySQL-Front Dump 2.0 ## Host: localhost Database: Admin

#--------------------------------------------------------

# Server version 4.0.1-alpha-nt

USE schememanager;

# Table structure for table 'applications'

DROP TABLE IF EXISTS applications;

CREATE TABLE IF NOT EXISTS applications (

ComID int(11) NOT NULL auto_increment,

ProductID int(20) ,

CusName varchar(50) ,

CusAddress varchar(255) ,

CusNo varchar(20) ,

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Status varchar(25) ,

Remarks varchar(255) ,

EmailID int(10) ,

TechID int(10) ,

); ## Table structure for table 'login' # DROP TABLE IF EXISTS login; CREATE TABLE IF NOT
EXISTS login ( UserID varchar(50) NOT NULL DEFAULT '' , Password varchar(50) NOT NULL
DEFAULT '' , Auth int(11) NOT NULL DEFAULT '1' , PRIMARY KEY (UserID) ); # # Dumping data
for table 'login' #INSERT INTO login VALUES("admin","admin","0"); INSERT INTO login
VALUES("ddo","ddo","2"); INSERT INTO login VALUES("gpo","gpo","1"); INSERT INTO login
VALUES("normal","normal","3"); INSERT INTO login VALUES("user","user","3");
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
INSERT INTO login VALUES("vara","vara","0"); INSERT INTO login VALUES("sunil","sunil","1");
INSERT INTO login VALUES("ramkumar","ramkumar","2"); INSERT INTO login
VALUES("anil","anil","0"); INSERT INTO login VALUES("vivek","vivek","2"); INSERT INTO login
VALUES("sekar","sekar","3"); INSERT INTO login VALUES("srinu","srinu","1"); INSERT INTO login
VALUES("swami","swami","2"); INSERT INTO login VALUES("pradep","pradep","3"); INSERT
INTO login VALUES("sehwag","sehwag","3"); INSERT INTO login VALUES("yuvi","yuvi","2"); #

import org.dao.DBDAO; public class AdminLogin extends HttpServlet { /** * */ private static final long
serialVersionUID = 1L; public void doGet( HttpServletRequest request,HttpServletResponse res) {
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
doPost(request,res); } public void doPost( HttpServletRequest request,HttpServletResponse res) {
Connection con=null; Statement st=null; PrintWriter pw=null; ResultSet rs=null; try {
pw=res.getWriter(); DBDAO dao1= new DBDAO(); con=dao1.getCon(); st =con.createStatement();
rs=st.executeQuery("select * from product_info1"); pw.println("<html>"); pw.println("<table border=2
color = gray>"); pw.println("<tr>"); pw.println("<center>"); pw.println(" <h4><font
color=red>"+"complaint details"+" </h4></font>"); pw.println("</center>");
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
pw.println("</tr>"); pw.println("<tr >"); pw.println("<th>"+"coustmer id"+"</th>"); pw.println("<th
>"+"name"+"</th>"); pw.println("<th>"+"lastname"+"</th>"); pw.println("<th>"+"email"+"</th>");
pw.println("<th>"+"address"+"</th>"); pw.println("<th>"+"city"+"</th>");
pw.println("<th>"+"contact"+"</th>"); pw.println("<th>"+"username"+"</th>");
pw.println("<th>"+"type"+"</th>"); pw.println("<th>"+"puchase"+"</th>");
pw.println("<th>"+"fault"+"</th>"); pw.println("<th>"+"date"+"</th>");
pw.println("<th>"+"status"+"</th>"); pw.println("</tr>"); while(rs.next()) { pw.println("<center>");
pw.println("<tr>"); pw.println("<td>"+rs.getString(10)+"</td>");
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
pw.println("<td>"+rs.getString(11)+"</td>"); pw.println("<td>"+rs.getString(12)+"</td>");
pw.println("<td>"+rs.getString(13)+"</td>"); pw.println("<td>"+rs.getString(15)+"</td>");
pw.println("</tr>"); pw.println("</center>"); }//while pw.println("</table>"); pw.println("<html>");
pw.println("<a href='admin.jsp'>"+" go back"+"</a>"); con.close(); st.close(); }//try catch(Exception e) {
pw.println(" user id is wrong:"); e.printStackTrace(); }//catch }//method }//class
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Java Script Validations:
JavaScript is the most popular scripting language on the internet, and works in all major browsers, such as
Internet Explorer, Firefox, Chrome, Opera, and Safari. •

JavaScript was designed to add interactivity to HTML pages. •

JavaScript is a scripting language. •

A scripting language is a lightweight programming language. •

JavaScript is usually embedded directly into HTML pages. •

JavaScript is an interpreted language (means that scripts execute without preliminary compilation). •

Everyone can use JavaScript without purchasing a license. •

JavaScript gives HTML designers a programming tool - HTML authors are normally not programmers,
but JavaScript is a scripting language with a very simple syntax! Almost anyone can put small "snippets"
of code into their HTML pages. •

JavaScript can put dynamic text into an HTML page - A JavaScript statement like this: document.
write("<h1>" + name + "</h1>") can write a variable text into an HTML page. •

JavaScript can react to events - A JavaScript can be set to execute when something happens, like when a
page has finished loading or when a user clicks on an HTML element. •

JavaScript can read and write HTML elements - A JavaScript can read and change the content of an
HTML element

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
CHAPTER6 SYSTEM TESTING
6.1 TESTING
Testing is the process of detecting errors. Testing performs a very critical role for quality assurance and
for ensuring the reliability of software .The results of testing are used later on during maintenance also.
TESTING OBJECTIVES
The main objective of testing is to uncover a host of errors, systematically and with minimum effort and
time. Stating formally, we can say, Testing is a process of executing a program with intent of finding an
error a successful test is one that uncovers an as yet undiscovered error. A good test case is one that has a
high probability of finding an error, if it exists. The tests are inadequate to detect possibly present errors.
The software more or less confirms to the quality and reliable standards.

6.2 TESTING STRATAGIE

1 Unit Testing
Unit testing focuses verification effort on the smallest unit of software i.e. the module. Using the detailed
design and the process specification testing is done to uncover errors with in the boundary of the module.
All modules must be successful in the unit test. •

Entry module
: Various cases of errors like invalid agents etc are verified. •

Update module
: The test cases of entry module also apply here along with update constraints. •

View module
: Only those reports could be viewed that are valid. This property is ensured.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
2. System Testing
Here the entire software system is tested. The reference document for this process is the requirements
document, and the goal OS to see a software meets its requirements. This project is tested in Linux OS
and works well in this OS environment.
3. Acceptance Testing
Acceptance test is performed with realistic data of the client to demonstrate that the software is working
satisfactorily. Testing here is focus on external behavior of the system; the internal logic of program is not
emphasized. Test cases should be selected so that the largest number of attributes of an equivalence class
is exercised at once. The testing phase is an important part of software development .It is the process of
finding errors and missing operations and also a complete verification to determine whether the objectives
are met and the user requirements are satisfied. Acceptance testing is performed along with the client to
show that to see that all requirements are satisfied Whatever may be the attributes its working well
provided all the attributes are valid. If not it displays corresponding message for getting valid attributes.
4. White Box Testing
This is the unit testing method where a unit will be taken at a time and tested thoroughly at a statement
level to find the maximum possible errors. We tested step wise every piece of code, taking care that every
statement in the code is executed at least once, the white box testing is also called GLASS BOX Testing.
5. Black Box Testing
This testing method considers a module as a single unit and checks the unit at interface and
communication with other modules rather getting into details as statement level. Here the module will be
treated as a black box that will take some

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
input and generate output. Output for a given set of input combinations are forwarded to other module.
We have performed black box testing by taking different combinations of inputs such that the input
passed will be transferred to different modules and is used correctly.
SYSTEM TEST PLAN
The entire software system is tested.
Test Condition ID Description of coverage Expected results Covered by script 1
Verification of a particular record If a particular record already exists it displays a message This type of
test in {$verify} procedure in every jsp file where a record is inserted via an interface.
2
Updating of a particular record All the details should not be updated. This type of test is covered in all the
jsp files where updations are made.
3
Validity of login Only the authorized persons must access system. This is covered in the login procedure
for the validity of a user. Table: 6.1 Testing For Entire Software
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
UNIT TEST
The Unit testing checks that one component of a product performs as desired.
Test Condition ID description of coverage Expected results Script 1
Transaction entries should allow the user to add the details of the farmers. Should not allow duplicate
records Should not allow duplicate records
2
Transaction updates should allow the user to modify some of the details only to be updated Updating and
etc
.
The respective fields are disabled before allowing them to update Table: 6.2 Unit Testing
INTEGRATION TEST
This testing activity can be considered as testing the design and hence emphasis on testing module
interaction.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Condition ID Description of coverage Expected results Covered by script 1
Completeness of details: Whether all the required values are provided or not

Should not allow entering the details if required details are not provided. A proper message has to be
displayed for requesting all details.
2
Correctness of Details:

Should not allow to insert the details if the entered details are invalid in terms of date or entry method

Proper message has to be displayed for requesting exact details.

3
Transfer of data: Whether the data given is being transferred between modules correctly without any loss or
not. Should not allow duplicate values to be transferred. Message has to be displayed after transferring
data between modules is complete.
4
Report Generation: Whether the reports generated are containing the correct results are not to be checked.
Should not allow duplicate reports. Verification procedure is done while generating the reports. Table: 6.3
Integration Test
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Testing commence with a test plan and terminates with acceptance testing. Test plan is a general
document for the entire project that defines the scope, approach to be taken and the schedule of testing as
well identifies the test item for the entire testing process and the personal responsible for the different
activities of testing. The test planning can be done in parallel with the coding and design phases. The
inputs forming the test plan are Test unit specification
•

Features to be tested
•

Approaches for testing

•

Test deliverables
•

Schedule
•

Personal allocation One of the most important activities of the test plan is to identify the test units.
Test Plan Document
A test plan is a general document for a entire project, which defines the scope, approach to be taken and
the schedule of testing, as well as identifying the test items for entire testing process and the personal
responsible for the different activities of testing. A test plan should contain the following:
Test Unit Specification
A test unit is a set of one or more modules together with associated data which are from a single program
and which are the object of testing.
Features to Be Tested
Features to be tested include all software features and combination of features that should be tested. A
software feature is software characteristics specified or simplified by the requirements of design
documents. These may include functionality, performance, design constraints and attributes.

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
All the functional features specified in the requirements document are tested .No testing will be done for
the performance.
APPROACH FOR TESTING
The approach for testing specifies the overall approach to be followed in the current project. This is
sometimes called testing criteria. All the tastings are done one by one in an order as mentioned above.
Test Deliverables
Testing deliverables should be specified the test plan, before the actual testing begins. Deliverables could
be a list of test cases that were user detail results of testing. Test summary report, test log and data about
the code coverage. Various cases of errors like non-existent can, invalid agents etc. are verified .All the
update constraints must be satisfied. Only those reports could be viewed that are valid. This property is
ensured. A completely working code without errors will be provided ie. Satisfying all their requirements.
Schedule
The test log provides chronological record of relevant details about the execution of test case. Different
activities of testing and testing of different units that have identified. Different test cases are identified
and applied to each module of the project do that each and every case of the project is verified correctly
and is working well.
Personal Allocation
Personal allocation identifies the person responsible for performing the different activities. In our project
the person responsible for performing different activities differs from time to time.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
6.3 TEST APPROACH
Testing can be done in two ways:
•

Bottom up approach
•

Top down approach

Bottom up approach
Testing can be performed starting from smallest and lowest level modules and proceeding one at a time
for each module in bottom up testing a short program executes the module and provides the needed data
so that the module is asked to perform the way it will when embedded within the larger system. When the
bottom level modules are tested attention turn to those on the next level that use the lower level once they
are tested individually and then linked with a previously examined lower level modules.
Top down approach
This type of testing starts from upper level modules. Since the detailed activities usually performed in the
lower level routines are not provided stubs are written.
󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
6.4 TEST CASES
Administrator module:
Table: 6.4 Test Case For Administrator Module

󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇󰁇 󰁇󰁇󰁇󰁇 󰁇󰁇
Client Module:
Table: 6.5 Test Case for Client Module

Documents Similar To Online Complaint Management System

Skip carousel

Sad Midterms Chapter 2

Feasibility Study


Fe as Ability Study

Feasibility Study Components Inthebox 21.02.2013

Unit-2

business Plan on Restaurant

hp


 Banking Project Report VB

Sdlc

PROJECT CONCEPTION AND PROJECT FEASIBILITY

DEVELOPMENT OF A MULTIDIMENSIONAL
FRAMEWORK FOR FEASIBILITY ASSESSMENT
OF MINI HYDRO POWER PROJECTS IN
SRI LANKAppt ruwan prnt.pdf

Module 1.pptx


 New Www Www Www Www Www Www

Copy of Impact of System Center Configuration Manager 2007 Technology at MphasiS_Maha

INSE6400 – Introduction2

System Analysis and Design 17210_1338959710.pdf

fschecklist

Hospital Management POWER POINT



(3) PMBody of Knowledge (Scope) Leangroup Org

Chapter II

Report

ee.Project-Hospital Management System

09.Project-Hospital Management System


 09.Project-Hospital Management System

Lec 1 PM ch01-1

Feasibility Study - samples

Recoverd_docx_file(21).docx

Random Access Transport Capacity

Hatch-Bennet Social Impact Partnership Act

 

Decision support n System management.pdf

Documents About Feasibility Study

Skip carousel

Port Stanley Harbour Feasibility Study Business Plan - FINAL- October 27, 2009

System Analysis and Design

Sunnyside Yard 2017 Feasibility Study


 Management Information System MCQ'S

Managed Lanes Corridor Project Feasibility Study

Oakland citywide impact fee report

4-74 Million - Feasiblity Study From Trinity River Committee Combined 03-02-10-2

St. Louis Streetcar Feasibility Study - Final (2013)

SAAD 2013


Untitled

Rail to River feasibility study

RFP Parking Feasibility - Arboretum

Contract Tariff - South Wales

Arizona-Public-Service-Co-aps-Sched-6.pdf


 Saad

Contract Tariff - South Western

SENATE HEARING, 109TH CONGRESS - AMENDMENTS TO THE RECLAMATION

WASTEWATER AND GROUNDWATER STUDY AND FACILITIES ACT

Rupp Arena task force report

City of St. Louis Streetcar RFQ

Aviation Museum Operations



Austin-Energy-Thermal-Energy-Storage-Rebate

LFO Project Memo

State-of-Massachusetts-Incentive-Area-Commonwealth-Solar-Hot-Water-Program-Construction-
Rebate

Road Sector Investment Planning in the Pacific

Art Gallery of Peterborough report


 Art Gallery of Peterborough report Appendix B

Untitled

Contract Tariff - East Midlands

UK Power Networks - Contract Tariff

Contract Tariff - Midlands

More From amol Akolkar ( amolpc86)

Skip carousel


Antacids Pictures

To Determine which Antacid could Neutralize the most Stomach Acid

Chemistry Kitchenchemistry

Chemistry in Domestic Activity

Bus Reservation System


 Employee Management System

Nursery Management

Science Chemistry Teaching Resources Documents POTENTIOMETRY

Orangejuice Prac

Testing the Amount of Juice, The Acid

Soil Biodiversity


Measurement of Emf of Commercial Cells

Different Types of Fuels

Study on Biodiversity of Soil Fungi

The PH of Various Water Samples

Chemical Fertilizer


 भू कंप

महाराष्ट्र धमम वाचवावा

क्रिकेट

महाराष्ट्रातील समाजसुधारक

छत्रपती शाहू महाराज

ने ताजी सुभाष चंद्र बोस



दहशतवाद

पर्ाम वरण व्यवस्थापन फोटो

क्रवक्रवध खे ळ

महाराष्ट्रातील महापुरुष व समाजसुधारक

नै सक्रगमक आपत्ती व्यवस्थापन आक्रण लोकसहभाग


 आर्मभट

लोकसंख्येमुळे नागरी सुक्रवधावारम होणारे पररणाम

About

 Browse books
 Site directory
 About Scribd
 Meet the team
 Our blog
 Join our team!
 Contact Us

Partners

 Publishers
 Developers / API

Legal

 Terms
 Privacy
 Copyright

Support

 Help
 FAQ
 Accessibility
 Press
 Purchase help
 AdChoices

Memberships
  Join today
 Invite Friends
 Gifts

Copyright © 2017 Scribd Inc. .Terms of service.Accessibility.Privacy.Mobile Site.Site Language:

English
English
中文
Español
‫العربية‬
Português
日本語
Deutsch
Français
Turkce
Русский язык
Tiếng việt
Język polski
Bahasa indonesia
Sign up to vote on this title
Us
cvvvvv