Project Report

Project Report Description page

Certificate from company
Certificate from College
Acknowledgement
1.) Introduction
1.1) Company Profile
1.2) Existing System and Need for System
1.3) Operating environment and Technologies used.
2.) Proposed System
2.1) Objectives of system
2.2) Uses Requirement
3.) Analysis and Design
3.1) Data Flow Diagram
3.2) ER Diagram
3.3) Tables
3.4) Menu Tree
3.5) Input Screens
3.6) Report Format
4.) Testing and Implementation
5.) Conclusions
6.) Bibliography
1.2.) EXISTING SYSTEM AND NEED FOR SYSTEM

1.2.1.) EXISTING SYSTEM

This software has been developed for IMPERIAL AUTO INDUSTRIES

LTD. concerning all the details given by company. By this software
anyone can handle customer complaint details without any difficulty.
To maintain customer complaint details and to generate the complaints
report to the clients they have to maintain the following information in
various files:
1. In the first file they record the client’s personnel information,
such as client code, client name, address, etc. this details are
entered in this file when the new client comes into the
organization.
2. The second file is used to record the product details of each
individual product, this file, this file contain the detail like the
product code and all other details concerning about products.
3. The third file records the complaints of the customers, which we
received from the customers. Each complaint is assigned a
separate a CCR No. i.e. Customer Complaint Number. This file
records the detailed description of the complaint. Against each
CCR No. There is a Customer Name, Code, Imperial part number
& Customer part no.
1.2.2.) NEED FOR SYSTEM

The package that I designed can handle the Complaints details without
any difficulty & with a little bit of effort. As the work is one manually
before, so it will be very time consuming & required a large efforts to
maintain the files. By computerizing the system these files can be
handle with a small effort & in less time.
The chances of duplicity of complaints are negligible. The Customer
Complaint Report can be generated easily by getting the information
without any problem from all the related files. The package is designed
by using GUI concept there for it is very user friendly & easy to use.

1.3.) OPERATING ENVIRONMENT

HARDWARE REQUIREMENTS

 Processor 486 or Higher

 RAM 128
 1 GB Hard disk space
 RS232 Port
 Monitor 15”
 CD Rom 52X
 Printer
 Mouse
 Key Board

SOFTWARE REQUIREMENTS

 Operating System : Windows 98 or Windows 2000

 Front End : Visual Basic 6.0
 Back End : Oracle 9i
 Crystal Reports 8.5 and above
 MSDN HELP.
This application package uses VISUAL BASIC 6. For inputs/outputs
user will use Menu for working on the system. They will use forms for
displaying the database and also for view/update this.
Software
 System should be run under windows 95, 98, window NT 4.0
environment.
 Reports should be designed in Seagate Crystal Reports.
 Oracle 9i should be used as backend to store database.
 Forms should be designed in Microsoft Visual Basic 6.0 to enhance
the productivity, for expressive form design, and less update time.
Hardware
 Visual Basic 6.0 and other application package should be installed
on the Pentium III and other compatible machine.
 Any machine that is connected to LAN must have Microsoft Visual
Basic 6.0 and Seagate Crystal Report packages.
2.1.) PROPOSED SYSTEM

The package that I designed can handle the Complaints details without
any difficulty & with a little bit of effort. As the work is one manually
before, so it will be very time consuming & required a large efforts to
maintain the files. By computerizing the system these files can be
handled with a small effort & in less time. The chances of duplicity of
complaints are negligible. The Customer Complaint Report can be
generated easily by getting the information without any problem from
all the related files. The package is designed by using GUI concept
there for it is very user friendly & easy to use.

Planning information systems has become increasingly important

because information is a vital resource & company assets, more &
more funds are committed to information system & system
development is a serious business for computers that incorporate
databases & networking. The initial investigation has the objectives of
determining the validity of the user request for a candidate system &
whether a feasibility study should be conducted. The objective of the
problem posed by the user must be understood within the framework
of the organizations MIS plan.

Fact- finding is the first step in the initial investigation. It includes a

review of written documents, on site observation, interviews & the
questionnaires. The next step is fact analysis which evaluates the
element, related to the input & the output of the given system. Data
flow diagrams & other charts are prepared during this stage .The
outcome of initial investigation is to determine whether an alternative
system is feasible. The proposal details the findings of the
investigation. Approval of the document initiates a feasibility study,
which leads to the selection of the best candidate system.

2.2.) OBJECTIVES OF SYSTEM

 The aim of this project is to deliver a verified & validated data

retrieval system.
 The primary objective of design & development of this system is
to simplify the process of report generation.
 It should provide correct data in the reports independent of the
objects & conditions used.
 Should reduce the time for provisioning of requested data.
 The enterprise managers can easily get data for analysis
purposes.

2.3.) USER REQUIREMENT

The foremost requirement is to provide initial reporting framework.

 Should provide feature of Single point-of-entry to access reports.

 Should provide a range of information demand addressed.

 Should provide Business Self Service where possible to take up

business decisions.

 Should provide Data Abstraction.

 Treat data from a business perspective instead of from an

application perspective

 Should embed in itself Service-Oriented Architecture.

 Should be Maintainable.
 Should be Business aligned

 Should provide a framework for Efficient Report Development

Process

 Should have a detailed source data analysis for effective modeling

of universe.

 Should provide feature for changing the login and password of the
logged in user.

 Should cater to adhoc-reporting requirements of the customer.

THE TOOLS OF STRUCTURED ANALYSIS

Traditional tools have limitations. System flowcharts focus more on

physical than on logical implementation of the candidate system.
Because of these drawbacks, structured tools were introduced for
analysis. They include data flow diagrams, a data dictionary, structured
English, decision trees and decision tables. The traditional approach to
analyses focuses on cost/benefit and feasibility analysis, project
management, hardware and software selection, and personnel
considerations.

The DFD clarifies system requirements and identifies major

transformations that will become programs in system design. It is the
starting point in the system design that decomposes the requirement
specifications down to the lowest level of detail.

A data dictionary is a structured repository of data about data. It offers

the primary advantages of documentation and improving analyst/user
communication by establishing consistent definitions of various
elements, terms and procedures. A decision tree sketches the logical
structure based on some criteria. It is easy to construct, read, and
update. It shows only the skeleton aspects of the picture however, and
does not lend itself to calculations.

Structured English uses logical constructs and imperative sentences

designed to carry out instructions for action. Decision are made
through IF, THEN, ELSE and SO statements. This tool is highly
correlated with the decision tree.

COST/BENEFIT ANALYSIS

Data analysis prerequisite to cost/benefit analysis. From the analysis,

system design requirements are identified and alternative evaluated.
Analysis of cost and benefits of each alternative guides the selection
process. Therefore, knowledge of cost and benefit categories and
evaluation method is important.
In developing cost estimates, we need to consider hardware,
personnel, facility, operating, and supply costs. In addition, a system is
expected to provide benefits. We identify each benefit and assign it a
monetary value for cost/benefit analysis. Cost/benefit analysis gives a
picture of the various costs, benefits, and rules associated with each
alternative system. Costs and benefits are classified as tangible, direct
or indirect, fixed or variable.
Once the evaluation of the project is complete, actual results are
compared against standards or alternative investments. The decision
to adopt an alternative system can be highly subjective, depending on
the analyst or user’s confidence in the estimated cost and benefit
values and the magnitude of the investment.
 3.1.) DATA FLOW DIAGRAM (DFD):

3.1.1.) CONTEXT LEVEL DIAGRAM (CLD):

Complaint Details

Customer Details
Customer Books Complaint & Parts Details Customer Complaint
Analysis

Complaint Details
& Letters

Corrective Action and Customer Complaint

Preventive Action Detail
Report
C.A. & P.A. Detail
0.0

Query

Center Details

Management Production Center

Reports
3.1.2) DFD 1.0
3.1.3) DFD 2.0

3.1.4) DFD 3.0

3.1.5) DFD 4.0

3.1.6) DFD 5.0
3.3.) ENTITY RELATIONSHIP DIAGRAM (ERD)
3.4.) TABLE DESIGN
 TABLE -CCR

FORMAT/FIELD
FIELD NAME DATA TYPE SIZE

CCRNo Varchar2 12
CCRDate Date/Time dd/mm/yyyy
Status Varchar2 2
CopyTo Varchar2 5
CustCode Number Single
IPartNo Number Double
CustPartNo Varchar2 18
CommuCode Varchar2 1
ContactPerson Varchar2 30
RefNo Varchar2 15
RefDate Date/Time dd/mm/yyyy
CompReason1 Varchar2 1
CompReason2 Varchar2 1
CompReason3 Varchar2 1
CompReason4 Varchar2 1
CompReason5 Varchar2 1
CompReason6 Varchar2 1
CompReason7 Varchar2 50
CompReason8 Varchar2 1
OtherReason Varchar2 1
OtherReasonNote
s Varchar2 30
CompDetails Varchar2
BER Varchar2
SSRDate Date/Time dd/mm/yyyy
CAINDate Date/Time dd/mm/yyyy
PAINDate Date/Time dd/mm/yyyy
CloseDate Date/Time dd/mm/yyyy
LetterDate1 Date/Time dd/mm/yyyy
LetterDate2 Date/Time dd/mm/yyyy
LetterDate3 Date/Time dd/mm/yyyy
LetterDate4 Date/Time dd/mm/yyyy
LetterText Varchar2
 TABLE - CCR
ANAL

FIELD SIZE /
FIELD NAME DATA TYPE FORMAT
CUSTOMER
CCR NO. MASTER
Varchar2 12
QAREFNO Varchar2 15
FIELD
RECEIVING DATA TYPE FIELD
NAME
DATE DATE / TIME SIZE/FORMAT
DD/MM/YY
CLOSE DATE DATE / TIME DD/MM/YY
CustCode
STEP 1 Number
Varchar2 5 50
Name 1
RESP Varchar2
Varchar2 30 50
Add1 1
TDATE Varchar2
DATE / TIME 20 DD/MM/YY
Add2
STEP 2 Varchar2
Varchar2 20 50
Add3 2
RESP Varchar2
Varchar2 20 50
Pin
TDATE 2 Number2
DATE / TIME 10 DD/MM/YY
PerCode
STEP 3 Number2
Varchar2 10 50
RESP 3 Varchar2 50
TDATE 3 DATE / TIME DD/MM/YY
STEP 4 Varchar2 50
RESP 4 DEPARTMENT
Varchar2 50
TDATE 4 MASTER
DATE / TIME DD/MM/YY
STEP 5 Varchar2 50
RESP
FIELD 5 Varchar2
DATA TYPE 50
FIELD
NAME 5
TDATE DATE / TIME SIZE/FORMAT
DD/MM/YY
STEP 6 Varchar2 50
RESP 6 Varchar2
Dept_code Number 5 50
TDATE
Name 6 DATE / TIME 20 DD/MM/YY
Varchar2
PADATE DATE / TIME DD/MM/YY
STEP 7 Varchar2 50
RESP 7 Varchar2 50
TDATE 7 FORM
Varchar2 50
BER Varchar2
MASTER 50
AUTHORITY 1 Varchar2 20
AUTHORITY
FIELD 2 Varchar2
DATA TYPE 20
FIELD
AUTHORITY
NAME 3 Varchar2 20
SIZE/FORMAT
AUTHORITY 4 Varchar2 20
FormID Varchar2 10
FormName Varchar2 35
MenuName Varchar2 35
Desc Varchar2 50
IsToolbarIma
ge Varchar2 1
ButtonName Varchar2 20

TABLE -
LIST DATA

FIELD NAME DATA TYPE FIELD SIZE/FORMAT

GenNo Number 10
PlantId Varchar2 2
PlantName Varchar2 15
LastCCRNo Varchar2 4
LastEcnNo Varchar2 4
LastSystemID Varchar2 4
LastDeptCode Varchar2 4
LastPrinterID Varchar2 4
LastEmpCode Varchar2 4
UPS Varchar2 10
ESILimit Number 7
ESIRate Number 7
PFLimit Number 7
MaxEPF Number 7
MaxFPF Number 7
CPFRate Number 7
EPFRate Number 7
FPFRate Number 7
MonSchLUPDT Date/Time Date/Time
 TABLE-LOGIN
MASTER

FIELD SIZE /
FIELD NAME DATA TYPE FORMAT

Dept Varchar2 10
PassWord Varchar2 10

TABLE-MONSCH

FIELD SIZE /
FIELD NAME DATA TYPE FORMAT

I_PART_NO Number 10
Quantity Number 10
Despatch Number 10
Backlog Number 10

TABLE-PART
MASTER

FIELD SIZE /
FIELD NAME DATA TYPE FORMAT

CustCode Number 10
IPartNo Number 10
CustPartNo Varchar2 18
Description Varchar2 35
CenterCode Varchar2 2
Sys_Date Date/Time dd/mm/yyyy

PRODUCTION
 CENTER MASTER

FIELD
FIELD NAME DATA TYPE SIZE/FORMAT

CenterCode Number 6
CenterName Varchar2 10
Resp. Person Varchar2 15

USER MASTER

FIELD
FIELD NAME DATA TYPE SIZE/FORMAT

UserID Number 6
Name Varchar2 30
DeptName Varchar2 30
LoginName Varchar2 10
PassWord Varchar2 10
SuperUser Varchar2 1

USER RIGHTS

FIELD
FIELD NAME DATA TYPE SIZE/FORMAT

Dept_Code Number 4
FormID Varchar2 50
Access Varchar2 50
3.5.) MENU TREE

File
Login as New User

Exit

Data Entry
CCR Generation
CCR Analysis
Update Customer Master
Update Item Master

Reports
Detail Reports
Statuswork Complaints
Customerwise Complaints
Plantwise Complaints
Areawise Complaints
Datewise Complaints
Reason wise Complaints
Reponsibilitywise Complaints
Executivewise Complaints

Plantwise Complaint Reasons

Repeatative Part CCR Report

Scheduled Parts Complaints

 Summary Reports
Areawise CCR
Plantwise CCR
Customerwise CCR
Monthwise CCR
Reponsibilitywise CCR
Repeatative Partwise CCR

Delay Reports
Seven Steps
Corrective Action
Preventive Action

Graphs
Responsible person Vs. Complaints
Responsible Person Vs Complaints Status
Production Center Vs Complaints
Months Vs Complaints
Executive Vs Complaints

Setup
User Master
User Rights

Window
Tile Horizontallly
Tile Vertically
Cascade
Arrange Icon
3.7.) INPUT SCREENS

3.7.1.) CCR GENERATION

3.7.2.) CCR ANALYSIS LIST OF CCR
3.7.3.) CCR ANALYSIS DETAILS
3.7.4.) CCR ANALYSIS PROCESS STEPS

3.7.5.) STATUSWISE COMPLAINT DETAILS INPUT SCREEN

3.7.6.) USER RIGHTS INPUT SCREEN
3.7.6.) PASSWORD CHANGING SCREEN
REPORT – CCR GENERATION
REPORT – PLANTWISE COMPLAINTS
REPORT – AREAWISE COMPLAINT DETAILS
REPORT – PARTWISE COMPLAINTS REASONS
TEST PROCEDURES & IMPLEMENTATION

Theoretically, a new designed system should have all modules in

working order, but in reality, each module works independently. The
purpose of system testing is to consider all the likely variations to
which it will be subjected and then push the system to its limits it is
tedious but necessary step in system development. During system
testing, the system is used experimentally to ensure that the software
does not fail. In other words, we can say that it will run according to
its specification and in the way users expect. Special test data are
input for processing, and the results examined. A limited number of
users may be allowed to use the system so that analyst can see
whether they try to use it in unforeseen ways.
The objective of system testing is to ensure that all individual
programs are working as expected, that the program link together to
meet the requirements specified and to ensure that the computer
system and the associated clerical and other procedures work
together. The system testing is the responsibility of the analyst who
determines what conditions are to be tested, generates test data,
produced a schedule of expected results, runs the test data and then
compares it with the computer processed results with the expected
results. The analyst may also be involved in procedures testing. When
the analyst is satisfied that the system is working properly, he hands it
over to the users for testing. The importance of system testing by the
user must be stressed. Ultimately it is the user must verify the system
and give the go ahead.

During testing, the system is experimentally to ensure that the

software does not fail, i.e., that it will run according to its
specifications and in the way user expect it to. Special test data is
input for processing (Test plan) and the results are examined to locate
unexpected results. A limited number of users may also be allowed to
unexpected ways. It is preferably to find these surprises before the
organization implement the system and depends on it. In many
organizations, persons other than those who write the original
programs perform testing. Using persons who do not know how.

Certain parts were designed or programmed ensure more complete an

unbiased testing and more reliable software. Parallel running is often
regarded as the final phase of system testing. Since the parallel
operation of two systems is very demanding in terms of user resources
it should be embarked on only if the user is satisfied with the results of
testing—it should not be started if the problems are known to exist.

TESTING CAN BE DONE AS:

 UNIT TESTING

In unit testing analyst test the programs making up a system. For this
reason unit testing is sometimes called program testing. Unit testing
gives stress on the modules independently of one another, to find

errors. This helps the tester in detecting errors in coding and logic that
are contained within that module alone. For each, it provides the
ability to enter, modify or retrieve data and respond to different types
of inquires or prints reports. The test cases needed for unit testing
should exercise each condition and option.

Unit can be performed from the bottom up, starting with smallest and
lowest level modules and processing with one at a time. For each
module in bottom up testing a short program is used to execute 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.

 SYSTEM TESTING

The important and essential part of the system development phase,

after designing and developing the software is system testing. We
cannot say that every program or system testing is perfect and
because of lack of communication between the user and design, some
error is in the software development. The number and nature of errors
in a newly designed system depend on some usual factors like
communication between the user and designer; the programmer’s
ability to generate a code that reflects exactly the systems
specification and the time frame for the design. Theoretically, a new
designed system should have all the parts or sub systems are in
working order, but in reality, each subsystem works independently.
This is the time to gather all the subsystem in to one pool and test the
whole system to determine whether it meets the user requirements.
This is the last change to detect and correct errors before the system
is installed for user acceptance testing. The purpose of system testing
is to consider all the likely variations to which it will be subjected and
then push the system to its limits.

Testing is an important function to the success of the system. System

testing makes a logical assumption that if all the parts of the system
are correct, the goal will be successfully achieved. Another reason for
system testing is its utility as a user-oriented vehicle before
implementation.
  PROGRAM TESTING

A Program represents the logical elements of a system. For a program

to run satisfactorily, it must compile & test data correctly and tie in
properly with other programs. Program testing checks for 2 types of
errors:
 Syntax error
 Logic error
A syntax error is a program statement that violates one or more rules
of the languages in which it is written. These errors are shown through
error messages generated by the computer. All the syntax has been
removed.
A logical error in the other hand deals with incorrect data fields output
of range items an invalid combination. The programs are checked for
syntax under MS-Access environment & the codes are carefully written
& each logical path is traced during the testing for avoiding the logical
errors. No error is left for correction.
PREPARATION OF TEST DATA
The data that is undergoing the test condition is the critical part of any
business or department within a firm. In this, the data that is to be
checked is selected or recommended as per the requirement of the
company by taking consideration of various departments in a
company.
TESTING WITH DUMMY DATA
Sometimes it is very risky or probable to test the data that is
flowing through a proper channel in the firm as any miss-happening
can cause the loss of vital information of the company, which
ultimately affects the accuracy of the company’s work. So, it is
preferable to check the various test conditions of a project on dummy
data that is not a part of company’s information channel. This data
may be anything taken from the open minds present in the
organization with a standard framework that suits the real conditions
too. In my project, I had first check the various test conditions by
taking a planned raw data and gone through the various validations
and checks over this dummy data.
TESTING WITH LIVE DATA
This is the kind of testing in which we apply the various
validations and checks on the real data that comes from various
internal and external sources. This testing is the part of software
resolution of the firm. This testing happens within a particular time
frame over the live data of the company. During our training period,
the development of the project was in the way of progress, so it was
quite difficult to check the various test conditions with the real data of
the company. So we could not performed this testing up to the mark.

CONCLUSION
The System (Software) has been developed at Imperial Auto Industries
Ltd. with the help of my Project guide and other colleagues. The
development of this software tool is based on in V.B (Front end). This
software provides comfort to the employees of Company enabling
them to update different data-records easily using this GUI tool.
Since it was a new technology to me I had to put in a lot of effort,
firstly to learn the technologies used and then to implement it and
work on it. The dedication and hard work, which leads to fruitful
results is unexplainable. The charm of committing a mistake and then
finding it out and in the process learning new things is a lesson that I
have learnt during the development of this project.

This project has been an experience to me and has enhanced my skill

set to a new degree while at the same time exposing me to the
manner in which Software professional works in a realistic company
environment.

BIBLIOGAPHY

Mastering VISUAL BASIC 6.0

Evangelos petroutsos
Software Engineering

Pankaj jalote

pressman

Database Systems

s. b. navathe

bipin. C. desai