Professional Documents
Culture Documents
TABLE OF CONTENTS
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.4 Reports
05
4 SYSTEM DESIGN
18
4.1 ER Diagram
18
GRIET/MCA,HYD Page 2
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
GRIET/MCA,HYD Page 3
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
3 UML Unified
Modeling Language 20
GRIET/MCA,HYD Page 4
LIST OF FIGURES AND TABLES
LIST OF FIGURES
LIST OF TABLES
S NO Table Number Table Name
Page No
GRIET/MCA,HYD Page 5
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.
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.
GRIET/MCA,HYD Page 6
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 client systems should be able to share the data available in the data base through the
network connection.
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.
GRIET/MCA,HYD Page 7
Intermediate Language : JVM.
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.
Product Functions
• Complaint registration for a particular product id, date and time and also
providing with a pin code as a customer address.
Advantages:
GRIET/MCA,HYD Page 8
• Very less time required.
• Very less cost.
• Risk is low.
• No technical knowledge is needed for the user.
• Easy to maintain
CHAPTER2
GRIET/MCA,HYD Page 9
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.
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.
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.
GRIET/MCA,HYD Page 10
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 able 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.
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
GRIET/MCA,HYD Page 11
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.
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.
Status oriented reports give the information of complaints according to the status given.
The status oriented reports are completed, pending and delayed reports.
Division wise reports give the information of complaints according to the division
given.
GRIET/MCA,HYD Page 12
CHAPTER3
REVIEW OF THE STATE OF ART
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.
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.
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
GRIET/MCA,HYD Page 13
and its feasibility. It also studies the additional training needed to be given to the people
to make the application work.
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.
GRIET/MCA,HYD Page 14
Role of SRS:
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).
GRIET/MCA,HYD Page 15
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
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
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.
GRIET/MCA,HYD Page 16
b. Gives guidelines for how to carry out the phases
3. Development process
a. Analysis
b. Design
c. Implementation
d. Testing
e. Deployment
• Evolutionary development
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
GRIET/MCA,HYD Page 17
of prototypes. Lessons learned from development of one prototype can be applied to the
next iteration.
Stages in SDLC:
♦ Requirement Gathering
♦ Analysis
♦ Designing
♦ Coding
♦ Testing
♦ Maintenance
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
GRIET/MCA,HYD Page 18
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.
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.
GRIET/MCA,HYD Page 19
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.
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.
GRIET/MCA,HYD Page 20
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.
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
GRIET/MCA,HYD Page 21
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.
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.
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
GRIET/MCA,HYD Page 22
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.
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.
GRIET/MCA,HYD Page 23
CHAPTER4
SYSTEM DESIGN
4.1 ER DIAGRAM
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
GRIET/MCA,HYD Page 24
Table: 4.1 Product Information
GRIET/MCA,HYD Page 25
4.3 DATA FLOW DIAGRAMS
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.
• 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
2. An arrow identifies data flow. It is the pipeline through which the information
flows
GRIET/MCA,HYD Page 26
3. A circle or a bubble represents a process that transforms incoming data flow into
outgoing data flows.
Data flow
Data Store
GRIET/MCA,HYD Page 27
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:
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:
GRIET/MCA,HYD Page 28
Static:
1. Class Diagrams.
2. Object Diagrams.
3. Component Diagrams.
4. Deployment Diagrams.
Dynamic:
1. Use-Case Diagram.
2. Sequence Diagram
3. Collaboration Diagram.
5. Activity 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.
GRIET/MCA,HYD Page 29
Client Module :
Login
RegisterComplaint
client
viewstatus
Logout
Administrator Module:
GRIET/MCA,HYD Page 30
Technical team module:
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.
GRIET/MCA,HYD Page 31
Administrator Module:
Login\Regi
ster
fails
success
verfification displayerro
rmessage
LogOut
GRIET/MCA,HYD Page 32
Technical team Module:
GRIET/MCA,HYD Page 33
4.4.3 Collaboration diagram:
9: commit( )
Db :
DBUtils
admin :
Adminstartor
2: status( ) 3: openConnection( )
11: logout( )
13: sessionClose()
12: closeConnection() 5: report( )
6: createUsers
7: showStatus() 8: update( )
4: searchComplaintDetails( )
logout :
Logout
mon :
MonitorComplaint
GRIET/MCA,HYD Page 34
4.4.4 CLASS DIAGRAM
Coustmer
productid : String MonitorComplaint
name : String complaintid : String
middlename : String complainttype : String
lastname : String date : Date
email_id : String
address : String status()
report()
setProductID()
setName()
setMiddleName()
setLastName() updatestatus
Adminstartor
setEmail() isupdated : Boolean
setAddress() Username : String
opname() password : String
updateComplaint()
createusers()
createdivisions()
opname()
Checkstatus Logout
complaintId : java.lang.String sessionout : Integer
showComplaints() logout()
RegisterComplaint
status()
complainttype remaider()
description
postcomplaint()
DBUtils
isLoggedIn : Boolean login
isSesstionOut : Boolean username : String
password : String
openConnection() conformpassword : String
close()
searchComplaintDetails() check()
update()
commit()
sendCompalintDatails()
showStatus()
GRIET/MCA,HYD Page 35
4.4.5 SEQUENCE DIAGRAM
Customer module :
postcomplaint( )
checkstatus() login()
openConnection( )
acknowledgement()
showcomplaintStatus()
rollback ()
update()
commit()
logout
GRIET/MCA,HYD Page 36
Administrator Module:
login( ) status( )
openConnection( )
searchComplaintDetails( )
report( )
showStatus()
update( )
commit( )
createUsers
logout( )
closeConnection()
sessionClose()
GRIET/MCA,HYD Page 37
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:
#--------------------------------------------------------
USE schememanager;
ProductID int(20) ,
CusName varchar(50) ,
CusAddress varchar(255) ,
CusNo varchar(20) ,
GRIET/MCA,HYD Page 38
Status varchar(25) ,
Remarks varchar(255) ,
EmailID int(10) ,
TechID int(10) ,
);
);
import org.dao.DBDAO;
/**
*/
{
GRIET/MCA,HYD Page 40
doPost(request,res);
Connection con=null;
Statement st=null;
PrintWriter pw=null;
ResultSet rs=null;
try
pw=res.getWriter();
con=dao1.getCon();
st =con.createStatement();
pw.println("<html>");
pw.println("<tr>");
pw.println("<center>");
pw.println("</center>");
GRIET/MCA,HYD Page 41
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>");
GRIET/MCA,HYD Page 42
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>");
con.close();
st.close();
}//try
catch(Exception e)
e.printStackTrace();
}//catch
}//method
}//class
GRIET/MCA,HYD Page 43
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.
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
GRIET/MCA,HYD Page 44
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.
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.
GRIET/MCA,HYD Page 45
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.
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.
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
GRIET/MCA,HYD Page 46
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.
Test
Description of
Condition Expected results Covered by script
coverage
ID
GRIET/MCA,HYD Page 47
UNIT TEST
The Unit testing checks that one component of a product performs as desired.
Covered by
Test description of coverage Expected Script
Condition results
ID
INTEGRATION TEST
This testing activity can be considered as testing the design and hence emphasis on
testing module interaction.
GRIET/MCA,HYD Page 48
Condition Description of
Expected results Covered by script
coverage
ID
GRIET/MCA,HYD Page 49
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.
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 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
GRIET/MCA,HYD Page 50
All the functional features specified in the requirements document are tested
.No testing will be done for the performance.
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
GRIET/MCA,HYD Page 51
6.3 TEST 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.
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.
GRIET/MCA,HYD Page 52
6.4 TEST CASES
Administrator module:
GRIET/MCA,HYD Page 53
Client Module:
GRIET/MCA,HYD Page 54
CHAPTER7
SCREEN SHOTS
This Section deals with the User Interfaces. In this project there are few Graphical User
Interfaces which gives esteemed interaction to the user without explicit knowledge about
the background programs.
7.1 Screens
To Complaint about any faulty product, the Customer need to register first. Then
the above screen appears to the Customer. The Customer has to fill the details of the
registration Form.
GRIET/MCA,HYD Page 56
Administrator Login
The above screen shows that administrator login to the site. The administrator
has full control on the site. By entering user id and password the administrator
page will be open.
GRIET/MCA,HYD Page 57
Forgot password for Customer module:
The above screen tells about the Customer Login .Similarly Administrator
every user or customer has his/her own user id and password. After entering the user id and
password the user interface will appear on the console.
GRIET/MCA,HYD Page 58
Customer Complaint editing:
The above screen tells about the customer complaint editing. The customer can edit
his/her complaint easily. To edit users their own complaint, first they need to enter their
user id and password to access their user interface.
GRIET/MCA,HYD Page 59
Check status:
The above figure tells about the user’s or customer’s complaints status. Whether
the complaint has solved successfully or not. To know the complaint status user or
customer has to login in the site by entering user id and password.
GRIET/MCA,HYD Page 60
Administrator Activities:
The above figure tells about the administrator the Administrator Activities in this
project. The Administrator has several activities in this project like to see all complaints,
send to technical team, add vendor, delete complaints, update complaints, status oriented
reports, date oriented reports, see all vendors.
GRIET/MCA,HYD Page 61
Check complaints:
Delete compliant:
GRIET/MCA,HYD Page 62
Forward complaint to technical team:
The above figure tells about the Administrator activities. The administrator
forwards the complaint to the technical team, to check the complaint and to solve the
complaint.
GRIET/MCA,HYD Page 63
Technical team Module:
GRIET/MCA,HYD Page 64
CHAPTER8
CONCLUSION
8.1 Summary
The system has been divided in modules so that each module has a separate
entity making the modifications easy without affecting its design. There is always
room for improvements in software, however efficient it may be.
The CRM for online compliant management system is a web-based application for
primarily providing training to the employees who provide customized solutions to
meet organizational needs.
This application software has been computed successfully and was also tested
successfully by taking “test cases”. It is user friendly, and has required options, which
can be utilized by the user to perform the desired operations.
The software is developed using Java as front end and Oracle as back end in Windows
environment. The goals that are achieved by the software are:
• Instant access.
• Improved productivity.
• Optimum utilization of resources.
• Efficient management of records.
• Simplification of the operations.
• Less processing time and getting required information.
• User friendly.
• Portable and flexible for further enhancement.
GRIET/MCA,HYD Page 65
8.2 Future Enhancements
Some of the future enhancements that can be done to this system are:
• OMS shall be made more dynamic and helpful to the users by enabling it to
send instant messages to the customers , of a cancelled or rescheduled flight,
through email, phone, fax etc., informing them about the change, and
providing them with other feasible alternatives.
• At present one customer can able compliant only on one product at a time in
the feature for any number of products he can able to give the complaint .
• Provide service integration with auto rental agencies and hotel chains
• Interface for the travel agents shall be provided in the future versions with
additional features like informing them of any availability of seats on a flight
which was earlier booked to capacity.
GRIET/MCA,HYD Page 66
REFERENCES
[1] www.oraclesun.com.
[2] www.w3schools.com.
[3] H. Kim, P. Howland, and H. Park, “Dimension Reduction in TextClassification
with Support Vector Machines,” J. Machine Learning Research, vol. 6, pp. 37-53,
2005.
[4] F. Sebastiani, “Machine Learning in Automated Text Categorization,” ACM
Computing Surveys, vol. 34, no. 1, pp. 1-47, 2002
[5] B.Y. Ricardo and R.N. Berthier, Modern Information Retrieval. Addison
Wesley Longman, 1999
[6] A.L. Blum and P. Langley, “Selection of Relevant Features and Examples in
Machine Learning,” Aritficial Intelligence, vol. 97, nos. 1/2, pp. 245-271, 1997.
[7] E.F. Combarro, E. Montan˜ e´s, I. Dı´az, J. Ranilla, and R. Mones,
“Introducing a Family of Linear Measures for Feature Selection in Text
Categorization,” IEEE Trans. Knowledge and Data Eng., vol. 17, no. 9, pp. 1223-
1232, Sept. 2005.
[8] K. Daphne and M. Sahami, “Toward Optimal Feature Selection,” Proc. 13th
Int’l Conf. Machine Learning, pp. 284-292, 1996.
[9] R. Kohavi and G. John, “Wrappers for Feature Subset Selection,” Aritficial
Intelligence, vol. 97, no. 1-2, pp. 273-324, 1997.
[10] Y. Yang and J.O. Pedersen, “A Comparative Study on Feature Selection in
Text Categorization,” Proc. 14th Int’l Conf. Machine Learning, pp. 412-420, 1997.
[11] D.D. Lewis, “Feature Selection and Feature Extraction for Text
Categorization,” Proc. Workshop Speech and Natural Language, pp. 212-217, 1992
[12] H. Li, T. Jiang, and K. Zang, “Efficient and Robust Feature Extraction by
Maximum Margin Criterion,” T. Sebastian, S.Lawrence, and S. Bernhard eds.
Advances in Neural Information Processing System, pp. 97-104, Springer, 2004.
[13] E. Oja, Sub Methods of Pattern Recognition. Research Studies Press, 1983.
GRIET/MCA,HYD Page 67