1.

INTRODUCTION

ORGANISATION PROFILE

Synopsis

Synopsis :-
 The Work Order Sysrem is mainly designed to provide fast and
effective user environment for Call centre activities. This application software
is based on Model view controller architecture. The Client side forms used for
display forms the view, database connections, business logics are developed
and are represented as models, while controllers are pages used to link model
with the view.
There is a product support team consisting of 3 groups. Their duty is to
attend the customer, make new problem report, solving the problems and test
the product before giving back to the customer. The manager form deals with
the Report generation and modification of customer details entered by call
agent. In the primitive two tier architecture the validations of the data are
performed in client side or at the server side. This caused the delay in data
retrieval and transmission.

2. SYSTEM ANALYSIS

2.1 FEASIBILITY STUDY

During the feasibility study, the feasibility of the project – the likelihood of the
proposed system is analyzed.

The feasibility study was carried out on the overall integrated package. Three
key consideration in involved in the feasibility analysis are Operational, Technical
and Economical.

Operational Feasibility
The main objective here is to find out whether
The system will work once it is developed and installed.
There is sufficient support for the project from the management.
The current business methods are acceptable to the users.
 An investigation is conducted and as a result the following conclusions are
derived.
There is sufficient support form the managerial level
The current methods are done manually and take lot of time.
The persons involved in the current working system are met and
discussions are held with them to evolve a system with which they
have good participations and interest.

Technical feasibility
Technological feasibility analyses the following areas.
Technology and manpower is available are not.
Capacity to hold the data that is required to use the new system.
Provision to respond to users regardless of their number and
location.
Provision for further expansion.
Guarantee of accuracy, reliability, ease of access and data security.

An investigation is conducted and as a result the following conclusions are

derived.
The necessary technology to implement the proposed system is
available in the organization.
Main hardware equipment such as computers with the required
Capacities is also available.
Hence the system is technically feasible.

Economical Feasibility
Issues to be considered in the economical feasibility are
Financial benefits must equal or exceed the costs.
The solution should be cost effective.
Must be worth to pursue the project.

2.2 EXISTING SYSTEM

Manually when records are maintained it becomes very difficult to retrieve

correct details of all information . Customers who may be even 10-20 yrs old
can come with a problem and it will be a daunting task to refer old records. In
most cases the product might have been outdated and staffs in charge of that
particular product might not be available though possible problems and its fix
may be already available which are known only for that old employee.
It will be a daunting task to prepare yearly, monthly and weekly reports based
on different aspects if the records are maintained manually. Since the product
might have been bought in any of the branch offices of the company having all
the data related to each and every branch in every other branch that too with
concurrent updation of data is never possible without going in for
computerization.

2.3 PROPOSED SYSTEM

The system is designed in such a way that the end user of the
product need be aware of inner workings but to know only his duty and to
operate the keyboard. Computerized records are easy to maintain and at the
end of every month or whenever we need information it’s easy to view or get.
In this way reports can be generated anytime and one can be sure that data
when the pattern is changed the consolidated reports may not show us correct
data of all administration work pertaining to the call centre. Collection details
will be accurate as the related data is systematically entered.

Benefits:

The manpower is reduced, user easily to collect the information about

the product and also collect the operation of the product. At the time of product
installation if any problem arise easily customer contact the call centre and
rectify the installation problem through the online. This is the advantages
when details are computerized
3. System Configuration
3.1 H/W System Configuration

Processor - Pentium –III

Speed - 1.1 Ghz

RAM - 256 MB(min)

Hard Disk - 20 GB

Floppy Drive - 1.44 MB

Key Board - Standard Windows Keyboard

Mouse - Two or Three Button Mouse

Monitor - SVGA

3.2 S/W System Configuration

OPERATING SYSTEM :Windows 2000.

Technology : .NET
DATABAS : SQLServer 7.1

3.3 About the Software

JAVA:
Java is used as front-end
tool for developing the project. To run Java there is no need to have any particular
operating system, as it is platform independent. This must have certain hardware and
software installed on your computer. The key considerations were summed up by the
Java team in the following list of buzzwords:
 Simple
 Security
 Portability
 Object-oriented
 Robust
 Multithreaded
 Architecture-Neutral
 Interpreted
 High Performance
 Distributed
 Dynamic

THE JAVA 2 ENTERPRISE EDITION

The Java 2 Platform,
Enterprise Edition (J2EE), has rapidly established a new programming model for
developing distributed applications. This model is based on well-defined components
that can automatically take advantage of sophisticated platform services. These
components can be developed according to standard guidelines, combined into
applications, deployed on a variety of compatible server products, and reused for
maximum programmer productivity. This model is intended to both standardize and
simplify the kind of distributed applications required for today's networked
information economy.

 J2EE Platform Benefits

With features designed to
expedite the process of developing distributed applications, the J2EE platform offers
several benefits:

 Simplified architecture and development

 Freedom of choice in servers, tools, and components
 Integration with existing information systems
 Scalability to meet demand variations
  Flexible security model

HYPER TEXT MARKUP LANGUAGE

HTML was specifically

developed to use along with the Hyper Text Transfer Protocol (HTTP) to encode
documents for display on the World Wide Web.
HTML is defined in the
HTML Standard, currently Version 4.0x. HTML standards are recommended by the
World Wide Web Consortium,   W3C.  W3C also oversees the standardization of
technologies related to the World Wide Web and publishes the HTTP (Hypertext
Transfer Protocol) standards. HTML is initials for Hyper Text Markup Language.
HTML is pronounced one letter at a time as if you are spelling the word HTML. It is
not pronounced as "hit mill" and it is NOT a programming language. HTML cannot
be used to write programs and it cannot control the precise layout of a web page.
Web browsers are used to
view HTML documents. Two popular web browsers are the Netscape Navigator 4.x
and the Microsoft Internet Explorer 5.x. Browsers control the layout of a web page

JavaScript:

JavaScript enables you to embed commands in

an HTML page. JavaScript is powerful and simple. HTML
provides a good deal of flexibility to page authors, but HTML by
itself is static; after being written, HTML documents can’t interact
with the user other than by presenting hyperlinks. Scripting
languages act as the glue that binds every thing together.
JavaScript mainly provides a fairly complete set of built- in
functions and commands, enabling you to perform math
calculations, manipulates strings, play sounds, open new windows
and new URLs, and access and verify input to your web forms.
 JavaScript can also set the attributes, or
properties , of web page elements and other objects present in the
browser.
This way you can change the behavior of
plugs–in or other objects without having to rewrite them.
JavaScript commands

Macromedia Dreamweaver
 Macromedia Dreamweaver2.0 is one of the HTML Editor

 It also includes DHTML effects

 It is used to connect the forms to Servlets

 It is used to Hyperlinks the web pages

 It is used to create Templates

It is used to attach Sound files and Animation files along with our
Source.

The JavaServer Pages(JSP):

JavaServer Pages ™
technology is the Java ™ platform

technology for building applications containing dynamic Web

content such as HTML, DHTML, XHTML and XML. The

JavaServer Pages technology enables the authoring of Web pages

that create dynamic content easily but with maximum power and

flexibility.
 Advantages:
Write Once, Run Anywhere ™ properties
High quality tool support
Reuse of components and tag libraries
Separation of dynamic and static content
Support for scripting and actions
Web access layer for N-tier enterprise application architecture(s)

JSP page:

A JSP page is a text-based document that

describes how to process a request to create a response. The description
intermixes

template data with some dynamic actions and leverages on the Java

Platform.The features in the JSP technology support a number of

different paradigms for authoring of dynamic content. JSP pages can be

used in

combination with Servlets, HTTP, HTML, XML, Applets,JavaBeans

components and Enterprise JavaBeans components to implement a broad

variety of application architecture(s) or models.

 Maximum performance and scalability through its unique design

with the Windows’NT multi-threaded architecture.
 Central and easy-to-use the Graphical User Interface (GUI).
 Automatic authentication of users by the Operating System.

ENTERPRISE JAVABEAN (EJB):

EJB is a standard server side component model

for component

transaction monitors.It automatically takes in to account many of the

requirements of business systems-security,resourse

pooling,persistence,concurrency and transasction integrity.

Overall goals

The Enterprise JavaBeans (EJB) architecture has the following goals:

• The Enterprise JavaBeans architecture will be the standard

component architecture for building distributed object-oriented business
applications in the Java programming language. The Enterprise
JavaBeans architecture will make it possible to build distributed
applications by combining components developed using tools from
different vendors.

• The Enterprise JavaBeans architecture will make it easy to write

applications. Application developers will not have to understand low-
level transaction and state management details, multi-threading,
connection pooling, and other complex low-level APIs.

• Enterprise JavaBeans applications will follow the “Write Once, Run

Anywhere” philosophy of the Java programming language. An enterprise
Bean can be developed once, and then deployed on multiple platforms
without recompilation or source code modification.

• The Enterprise JavaBeans architecture will address the

development, deployment and runtime aspects of an enterprise
application’s life cycle.

• The Enterprise JavaBeans architecture will define the contracts

that enable tools from multiple vendors to develop and deploy
components that can inter operate at runtime.
 • The Enterprise JavaBeans architecture will be compatible with
existing

server platforms. Vendors will be able to extend their existing products to

support Enterprise JavaBeans.

• The Enterprise JavaBeans architecture will be compatible with

other Java programming language APIs.

• The Enterprise JavaBeans architecture will provide

interoperability between enterprise Beans and Java 2 Platform Enterprise
Edition (J2EE) components as well as non-Java programming language
applications.

• The Enterprise JavaBeans architecture will be compatible with the

CORBA protocols.

Enterprise Bean Provider

The Enterprise Bean Provider is the producer of enterprise

beans. The system output is an ejb-jar file that contains one or more
enterprise beans. The Bean Provider is responsible for the Java classes
that implement the enterprise bean’s business methods, the definition of
the bean’s remote and home interfaces and the bean’s deployment
descriptor.
The deployment descriptor includes the structural information of the
enterprise bean and declares all the enterprise bean’s external
dependencies.

Application Assembler

The Application Assembler combines enterprise beans

into larger deployable application units. The input to the Application
Assembler is one or more ejb-jar files produced by the Bean Provider(s).
The Application Assembler outputs one or more ejb-jar files that contain
the enterprise beans along with their application assembly instructions.
The Application Assembler inserts the application assembly instructions
into the deployment descriptors.
The Application Assembler can also combine enterprise beans with
other types of application components (JSP) when composing an
application. The EJB specification describes the case in which the
application assembly step occurs before the deployment of the enterprise
beans. However, the EJB architecture does not preclude the case that
application assembly is performed after the deployment of all or some of
the enterprise beans.

Deployer

The Deployer takes one or more ejb-jar files produced by a Bean

Provider or Application Assembler and deploys the enterprise beans
contained in the ejb-jar files in a specific operational environment. The
operational environment includes a specific EJB Server and Container.
The Deployer is an expert at a specific operational environment and is
responsible for the deployment of enterprise Beans.The Deployer uses
tools supplied by the EJB Container Provider to perform the deployment
tasks. The deployment process is typically two-stage:
 • The Deployer first generates the additional classes and interfaces
that enable the container to manage the enterprise beans at runtime.
These classes are container-specific.
• The Deployer performs the actual installation of the enterprise
beans and the additional classes and interfaces into the EJB Container.

EJB Server Provider

The EJB Server Provider is a specialist in the area of distributed

transaction management, distributed objects, and other lower-level

system-level

services. A typical EJB Server Provider is an OS vendor, middleware

vendor, or

database vendor. The current EJB architecture assumes that the EJB
Server

Provider and the EJB Container Provider roles are the same vendor.
Therefore,

it does not define any interface requirements for the EJB Server Provider.

EJB Container Provider:

The EJB Container Provider provides

• The deployment tools necessary for the deployment of enterprise

beans.
• The runtime support for the deployed enterprise bean instances.
 The focus of a Container Provider is on the development of a scalable,
secure,

transaction-enabled container that is integrated with an EJB Server. The

Container Provider insulates the enterprise Bean from the specifics of an

underlying EJB Server by providing a simple, standard API between the

enterprise Bean and the container. This API is the Enterprise JavaBeans

component contract. The Container Provider typically provides support

for

versioning the installed enterprise Bean components.The Container

Provider

typically provides tools that allow the system administrator to monitor

manage

the container and the Beans running in the container at runtime.

Persistence Manager Provider

The Persistence Manager interacts with the Container to receive

notifications related to the lifecycle of the managed beans. The current
EJB architecture, however, does not architect the full set of SPIs
between the Container and the Persistence Manager. These interfaces are
currently left to the Container Provider and Persistence Manager
Provider.

System Administrator
 The System Administrator is responsible for the configuration and
administration of the enterprise’s computing and networking
infrastructure that includes the EJB Server and Container. The System
Administrator is also responsible for overseeing the wellbeing of the
deployed enterprise beans applications at runtime.
4. System Design

4.1 NORMALIZATION

The normal forms are used to ensure that various types of anomalies and are
not introduced inconsistencies into the database.
Unnormalized form

An Unnormalized relation contains non-atomic values i.e. each rows may

contain multiple set of values for some of the columns these multiple values in a single
row are also called non-atomic values. There are no tables in unnormailzed form.

First Normal Form

A relation scheme is said to be in the first normal form

(1NF) if the values in the domain if each attribute of the relation are atomic. In other
words only one value is associated with each attribute and the value is not a set of values
or list of values. All the tables here are atomic.

Second Normal Form

A relation is in Second Normal Form (2NF) if it is in

the first normal form and if all nonprime attributes are fully functionally dependant on
the relation key(s). All tables satisfy the second normal form.
 4.2 Table design:

The database mainly used to store the data, all the information are
stored in to the master database.

One of the highly prudent ways of storing, retrieving, analyzing and

managing data. There are six tables used in this project. They are given
below,

1. customer - a list of customers who have bought Fabmax

products
2. product – a list of products and their support personnel
3. custprod – a list of customer / product pairs
4. problems - record of reported problem
5. problog – a log of events in the life of a reported problem
6. employees – users of the system

Table name – customer

Field name Data type Size Constraints
Customerid Varchar 50 Primary key
Customername Varchar 50
Phone Number

Table name - product

Field name Data type Size Constraints
Productid Number 9 Primary key
Productname Varchar 50
Productsupport Varchar 50
Person Varchar 50
Leaddeveloper Varchar 50
Leadtester Varchar 50
 Table name – custprod
Field name Data type Size Constraints
Customerid Varchar 50 Foreign key
Productid Varchar 50 Foreign key
Datepurchased Date / time 8

Table name – problems

Field name Data type Size Constraints
Problemid Varchar 50 Primary key
Description Varchar 50
Severity Numeric 9
Date reported Date / time 8
Date resolved Date / time 8
Customerid Varchar 50
Productid Varchar 50

Table name – problog

Field name Data type Size Constraints
Problemid Varchar 50
Timestamp Date / time 8
Eventide Numeric 9
Comments Varchar 50

Table name – employees

Field name Data type Size Constraints
Employeeid Varchar 50
Name Varchar 50

Data Flow Diagram:

DATA FLOW DIAGRAM

Level - 0
Level - 1
Level -2
Level - 3
E-R Diagram:
5. System Description

The actors of the product support team may be

1. Customers
2. Call centre agent
3. Product support
4. Developer
5. Quality assurance
Customers of this company may have problems in using their products and to
rectify those they would be reporting to the company and they would be assisted first
by a call centre agent. If a problem is not software related then calls are routed to
sales or customer service team. Otherwise, agent verifies the customer to be a valid
purchaser of the specified product. If so, agent creates a problem report and gives
him a customer identification no. He then routes the problem to a product support
group which is meant for that product.

The product support group gives customer a call and obtains all the
information relating to the problem. If the problem is due to lack of required
hardware, failure to install the product properly then product support person helps the
customer resolve the problem to the extent possible and then closes the problem
report.

If the problem is code-related, it may be that other customers have

encountered it and a fix already exists. If so, the fix is documented in the knowledge
base, which the product support person can search by appropriate keywords. The
patch or procedure necessary to fix the problem is sent to the customer via e-mail or
made available over the Web.

If the problem is not found in the knowledge base, it is routed to the

developer. The developer analyzes the problem and attempts to reproduce it. It may
be the product is working as designed, in which case the defect is routed back to
product support marked “not a bug”. Otherwise the developer tries to isolate the bug
and to develop a fix. After unit testing the fix, the developer routes the problem to
quality assurance. The problem report may be updated to indicate how to reproduce
the problem and where to get the code patch necessary to fix it.

The quality assurance support person for the product receives the problem
report from development and tests the fix. This is an integration test, in which the
effect of the new code established test cases, the problem is rerouted to development.
Otherwise, the fix is routed to product support, so the customer can be contacted and
supplied with new code.

At any point, system users can look up the status of the problem, and
comments to it, and route the problem to its next destination. Each routing is
accompanied by e-mail sent to the new problem owner. That part is not developed
here and is undertaken in separate module using JMS.

process flow

To summarize, the system users and their functions are as follows

Call center agent

Verifies customer entitlement
Entries new problems
Can look up status of existing problems

Product support
Receives incoming problem reports from call center agent
Can view outstanding problems by product
Interviews customer
Updates problem status
Adds comments
Routes problem to development

Developer
Receives problem reports from product support
Can view outstanding problems by product
Analyzes problem and develops fix
Adds comments to problem report
Routes problem to quality assurance

Quality assurance
Receives problem reports and fixes from development
Performs integration test
Adds comments to problem report
Routes fixed problems to product support
May route problem back to developer if tests fail.

In addition to product support team, there lies another actor who is the
manager in-charge of the entire technical support process. He has the power to
browse through the status of each and every problem. He can prepare number
of reports like
Reports based on
a) problems which are solved
b) problems in progress (In support phase or development phase or testing
phase)
c) unsolved (Failed to get solved in development phase)
d) calls made between 2 days
e) product wise call report

6. System Testing And Implementation

Testing:
 Software configuration includes a software requirements specification, a
design specification and source code. Test configuration includes a test plan and
procedure any testing tools and test cases and their expected.

User requirements test :

This is the test done at the time of requirements document URS(User

Requirement Specification). In this, the requirements are tested for clarity,
redundancy, feasibility and objectivity. As soon as the requirements are tested, the
URS can be helpful in preparing the acceptance test plan so that the user tests the
software according to the URS.

System requirement test :

From the URS we produce SRD(System Requirement Document)

which tests the validity of the system at the client end. As soon as the document is
ready, they can make a plan for the systems test conducted by the development
organization before coordinating the acceptance test.
Effective testing early in the process translates directly into long-term cost saving
from a reduced number of errors. The first trust for system is to see whether it
produces correct outputs. The test data may be artificial or live.

The software, which has been developed, has to be tested to prove its
validity. Testing is considered to be the least creative phase of the whole cycle of
system design. In the real its is the phase, which helps to bring out the creativity of
the other phases makes it shine. The “Port Trust Estate Management System (FHMC,
CISF, LAND) using the following techniques of software testing.

1. White Box Testing

By using this technique it was tested that all the individual logical paths were
executed at least once, all the logical decision were tested on both there true and false
sides. All the loops were tested with data in between the ranges and especially at the
boundary values.

2. Black Box Testing

By using this technique, the missing functions were identified and placed in
their positions. The errors in the interfaces were identified and corrected. This
technique was also used to identify the initialization and termination errors and
correct them.

Software Testing Strategies

Any software has to be tested with pre-planned strategies. As Roger

Pressmen states, the preparation for testing should start as soon as the design of
system starts, to carry out the testing in an efficient manner certain amount of
strategic planning has to be done. Any testing strategy must incorporate test
planning, test case design, test execution and the resultant data collection and
evaluation.

Unit Testing :
In the lines of this strategy all, the individual functions and modules were put
to the test independently. By following this strategy all, the errors in coding were
identified and corrupted. This method was applied in combination with the white and
black box testing techniques to find the errors in each module.

Integration Testing :
Again this software testing strategy has different approach in which
integration is carried out from the top level module to the bottom and the bottom up
approach in which integration is carried out from the low level module to the top.
The modules are tested using the bottom up approach by
introducing stumps for the top level functions.

This test used to identify the errors in the interfaces, the

errors in passing the parameters between the functions and
corrects them.

Validation Testing :
Validation testing is done to validate the inputs given by the user. The user
inputs are checked for their correctness and range. If there are errors, the error
message is given and the user is prompted again to enter the new value. If the user
types some characters in the numeric field an error message and it is demonstrated in
the following figure.

System Testing :

Software testing is an important element of software quality assurance and

represents the ultimate review of specification, design and coding. There are rules
that can serve as testing objectives. They are

Testing is a process of executing a program with the intent of

finding an error.

A good test case is one that has high probability of finding an

undiscovered error.
A successful test is one that uncovers an undiscovered error.

Testing Information Flow :

Software Configuration Evaluation
Test Result

Testing Errors

Test Configuration
Expected Result Debug

Corrections

Acceptance Testing :

Acceptance testing is sometimes performed with realistic data of the client to

demonstrate that the software is working satisfactorily. It includes database features
like integrity, consistency, security and validity.

The project is tested with different types of data to verify the quality of the
program. Some validation procedures used to verify are

To verify whether the data specified is a valid one.

To verify whether any inputs left unfilled.

To verify whether the amount specified is a valid amount.

Reports are not generated when the database contains null

data.

Message box is prompted to verify whenever an updating is

done.

After testing the system and find it successful to put the new system into
operation, there are different techniques that can be used to replace an existing system
with the new system.

 Direct Change over

In this technique, the existing system is replaced by the proposed
system after ensuring that system objectives are met. This method is adopted
in this project. This software is successfully demonstrated to Chennai Port
Trust.
  Parallel run
The proposed system is put into operation in parallel with the
existing system for a period of 60 days to monitor the performance. The
existing system becomes unoperational if the proposed system produces the
expected results.

 Pilot run
In pilot run, the system is tested with available result of the existing
system. The performance of the system is studied with the latest data.

 Staged Change over

In this technique the existing system becomes un
operational if all the stages are successfully implemented. The whole project
is through the main menu. Through the main menu all the modules and
reports are linked and called from this menu as and when required by
selecting the respective bars in the main menu. When any changes or
updating is made, reports are automatically updated.

Implementation:

The above said testing can be done virtually. In order to

implement the VB .Net for Knowledge Based Decision Support System.
Implementation includes all those activities that take place to convert from an old
system to a new one.
Three aspects of implementation are:
1.Training Personnel
2.Conversion
3.Point Implementation Review

TRAINING:
The quality of training
received by the personnel involved with the system in various capacities helps or
hinders, and may even prevent, the successful implementation of an information
system. Both system operators and users need training.
Training System Operators:
The training ensured that they were able to handle all possible operations, both
routine and extraordinary. Training also involved run procedures, which involves
working through the sequence of activities needed to use a new system on an ongoing
basis.
 CONVERSION:
Conversion is the process of changing from an old system to a new one. There are
basically four conversion methods:
 Parallel Systems-offers greatest security.
 Direct Cutover- Presents the highest risk.
 Pilot Approach
 Phase-In method
The approach followed for implementing the system was the Pilot Approach.
The working version of the system was implemented in one regional office, so that
the employees were aware that they were piloting a new system and that changes
could be made to improve the system.

The system would be installed throughout the

organization using the phase in methods. This approach had the advantage of
providing a sound training ground before full implementation.

Post Implementation Review:

After the system is implemented and conversion is
complete, review of the system is usually conducted by users and analysts alike. It is
important to determine whether the system is working, how it has been accepted and
whether adjustments are needed. The review is also important to gather information
for the maintenance of the system.
Review Questions: - The most fundamental concern during the post implementation
review is determining whether the system has met its objective, that is analysts want to
know whether the performance level of users has improved and if the system is producing
the result intended.

7.Conclusion and Future Scope

The “Work Order Sysrem for Call Centre ” has been developed to override
the problems prevailing in the practicing manual system. This software is supported
to eliminate and in some cases reduce the hardships faced by this existing system.
Moreover this system is designed for the particular need of the company to carry out
operations in a smooth and effective manner.
 The application is reduced as much as possible to avoid errors while entering
the data. It also provides error message while entering invalid data. No formal
knowledge is needed for the user to use this system. Thus by this all it proves it is
user-friendly.

The main objectives of the system that have attained are

The new system is user-friendly.

The processing is very fast whereas the earlier system is too slow.
Accurate and reliable output can be produced.
Maintenance and updating of files are also made easy.
It increases the efficiency and speed of generating report.

The developed “Work Order Sysrem for Call Centre ” is more Versatile,
flexible and updating can be done easily.

SCOPE FOR FUTURE DEVELOPMENT

 Now only text files containing queries can be uploaded, Instead all types files
has to be uploaded.
 More advanced search engine can also be upgraded.
 This application has to be dynamically linked with existing intranet
application.

A. APPENDICES

ANNEXURE-A.
1. Abbreviations

 OOPS  Object Oriented Programming Concepts

 TCP/IP  Transmission Control Protocol/Internet Protocol

 SOAP  Simple Object Access Protocol

 CLR  Comman Language Runtime

 CTS  Comman Type System

 CLS  Common Language Specification

 OR D BMS  O bject Relationa l D atabas e M anagement

S ys tem

 MSIL  Microsoft Intermediate Language

 JIT  Just-In-Time

 MFC Microsoft Foundation Classes

A.2 ONLINE RESOURCES

www.microsoft.com

www.msdn.com

www.roseindia.net

www.softlandindia.com
A.1 BIBLIOGRAPHY

Bigining with ASP.NETwith C# .NET 2003,Wrox Publication,Chris Ullman.

Bigining with ASP.NETwith VB.NET 2003,Wrox Publication,Chris Ullman.
C.J.Date An Introduction to DBMS 1996, Narosa publication.
Abraham Silberschatz, Henry.F.Korth, Sudarshar. S, 1997, Database
System Concepts, Mc Graw-Hillcomputers.Inc.,
Roger S. Pressman Software Engineering 1995 Tata.Mc.Graw-Hill.
Richard Fairley, Software Engineering concepts.
E.M.K.Rajkumar An Introduction to Oracle 8.0
Evangelos Petroutsos, Mastering Visual Basic 6.0
John W.Parfold, Microsoft Visual Basic – The Programmers comperor.
Steve Brown Visual Basic 6.0 in record time 1998, BPB Publication