You are on page 1of 51

A Project Report on

“FUEL BUNK MANAGEMENT SYSTEM”


Submitted to the

Department of Computer Application


In partial fulfillment of the course

Dual Degree Master of Computer Applications


Under the guidance of

Mrs. JISMY JOSEPH


By
JOSEPH JOHN GABRIEL(Reg no: 150297)

DEPARTMENT OF COMPUTER APPLICATIONS

SCMS SCHOOL OF TECHNOLOGY AND MANAGEMENT MUTTOM,

ALWAYE, COCHIN-683106 MAY-2018


SCMS SCHOOL OF TECHNOLOGY AND MANAGEMENT

MUTTOM, ALWAYE, COCHIN-683106

CERTIFICATE

This is to certify that the Project entitled “FUEL BUNK MANAGEMENT

SYSTEM” has been successfully carried out by JOSEPH JOHN GABRIEL

(Reg no: 150297) in partial fulfillment of the course Dual Degree Master of

Computer Applications.

Date: DIRECTOR
SCMS SCHOOL OF TECHNOLOGY AND MANAGEMENT

MUTTOM, ALWAYE, COCHIN-683106

CERTIFICATE

This is to certify that the Project entitled “FUEL BUNK MANAGEMENT SYSTEM”
has been successfully carried out by JOSEPH JOHN GABRIEL (Reg no:

150297) in partial fulfillment of the course Dual Degree Master of Computer

Applications under my guidance.

Date: Mrs. JISMY JOSEPH

(Internal guide)
SCMS SCHOOL OF TECHNOLOGY AND MANAGEMENTMUTTOM,

ALWAYE, COCHIN-683106

DECLARATION

I JOSEPH JOHN GABRIEL hereby declare that the project work entitled
“FUEL BUNK MANAGEMENT SYSTEM” is a record of original work
done under the guidance of Mrs. JISMY JOSEPH and the work has formed in
partial fulfillment of the course Dual Degree Master of Computer
Applications, affiliated to Mahatma Gandhi University Kottayam.

Date JOSEPH JOHN GABRIEL

Place:
ACKNOWLEDGEMENT

An endeavor over a long period can be successful with the advice,


support and blessings of many well-wishers. To acknowledge all of them is a
blissful opportunity showered upon me by the Almighty.

With great pleasure and privilege, I present here with full satisfaction, the

project report on “FUEL BUNK MANAGEMENT SYSTEM”. I take this

opportunity to express my gratitude and sincere thanks to all who helped me to


complete this project successfully. I first thank God Almighty, who showered his
immense blessing on my effort.

I express my gratitude and sincere thanks to the Director Prof. Indu Nair
for her kind consideration and valuable guidelines throughout the course of our
project work.

I express my sincere thanks to Mrs. JISMY JOSEPH my project guide, for

his valuable guidance, cooperation and constant encouragements throughout

the project work.

JOSEPH JOHN GABRIEL


TABLE OF CONTENTS

1. EXECUTIVE SUMMARY........................................................................................................... 8
2. BACKGROUND ........................................................................................................................... 9
2.1. EXISTING SYSTEM ............................................................................................................ 9
2.2. DEFINITION OF PROBLEM ............................................................................................. 9
2.3. PROPOSED SYSTEM ....................................................................................................... 10
3. PROJECT OVERVIEW ............................................................................................................ 11
3.1. OBJECTIVE OF THE PROJECT .................................................................................... 11
3.2. STAKEHOLDERS ............................................................................................................. 11
3.3. SCOPE OF THE PROJECT .............................................................................................. 12
3.4. FEASIBILITY ANALYSIS ................................................................................................ 12
3.4.1. Technical Feasibility ................................................................................................... 12
3.4.2. Operational Feasibility ............................................................................................... 12
3.4.3. Schedule Feasibility..................................................................................................... 12
3.4.4. Economic Feasibility ................................................................................................... 13
4. OVERALL PROJECT PLANNING ......................................................................................... 14
4.1. DEVELOPMENT ENVIRONMENT ............................................................................... 14
4.2. CONSTRAINTS .................................................................................................................. 14
4.3. DELIVERABLES ............................................................................................................... 15
4.4. ASSUMPTIONS AND DEPENDENCIES ........................................................................ 15
4.5. RISKS................................................................................................................................... 15
4.6. PROCESS MODEL ............................................................................................................ 15
4.7. TEST STRATEGY ............................................................................................................. 16
4.8. Testing environment and tools ........................................................................................... 19
5. ITERATION PLANNING ......................................................................................................... 20
5.1. SCHEDULE ......................................................................................................................... 20
5.2. RISKS................................................................................................................................... 20
6. ITERATION PLANNING ......................................................................................................... 21
6.1. USER CHARACTERISTICS ............................................................................................ 21
6.2. SUMMARY OF SYSTEM FEATURES/FUNCTIONAL REQUIREMENTS ............. 21
6.3. NON FUNCTIONAL REQUIREMENTS/ SUPPLEMENTARY SPECIFICATION . 22
6.4. GLOSSARY ......................................................................................................................... 23
6.5. BUSINESS RULES ............................................................................................................. 23
6.6. USE CASES ......................................................................................................................... 23
6.7. USE CASE DIAGRAM ...................................................................................................... 24
7. DOMAIN MODEL ..................................................................................................................... 25
8. USE CASE MODEL ................................................................................................................... 26
8.1. Use Case Text ...................................................................................................................... 26
8.2. System Sequence Diagram ...................................................... Error! Bookmark not defined.
8.3. Operation Contracts ........................................................................................................... 27
9. DESIGN MODEL ....................................................................................................................... 28
9.1. UI Design.............................................................................................................................. 28
9.2. Database Design .................................................................................................................. 32
10. TESTING ................................................................................................................................. 33
10.1. Test Cases ........................................................................................................................ 33
11. TRANSITION ......................................................................................................................... 34
11.1. SYSTEM IMPLEMENTATION ................................................................................... 34
11.2. SYSTEM MAINTENANCE ........................................................................................... 35
11.2.1. Corrective maintenance .............................................................................................. 35
11.2.2. Adaptive maintenance ................................................................................................ 36
11.2.3. Preventive maintenance .............................................................................................. 36
12. ANNEXURE ............................................................................................................................ 36
12.1. References ........................................................................................................................ 36
12.2. Annexure I: User Interview Questionnaires ................................................................ 36
1. EXECUTIVE SUMMARY

The ONLINE MATRIMONIAL SYSTEM involves providing users with a ease to search and
find partners . This project involves creating a website for the managing the user preference
for faster and perfect matching for the users.

The main objective of Matrimonial Web Application is to provide Grooms and Brides with
excellent matchmaking experience by exploring the opportunities and resources to meet true potential
partner. Keeping this objective in mind, this project have a world renowned online matchmaking
services that will touch the souls of millions of people all over the globe.

Users of the system are:

ADMINISTRATOR
USERS

The main functions are:-

 The main purpose of this application is to facilitate matchmaking business by applying


the information in the field.
 It helps the user by providing profiles of perspective “Bride” or “Groom” and other
information regarding them online.
 User can get information regarding their dream life partner at his/her home at his/her
convenience.
 This application also provides a search utility which helps those users who have a
certain criteria of qualities in mind to make online matrimonial easier.
 User also has the power of handling their own security by accepting or decaling the
friend request
Matrimonial Web Application will allow a new user to register and after successfully registration
and validation , users profile will be visible to other users.
Matrimonial website which will provide platform to a lot of Bride/Groom for finding perfect
match. There are different sectors like Registration, Friend, Search, etc. So the Bride/Groom can get
their interest for find their partner. Bride/Groom can directly search Partner according to their required
criteria. The Bride/Groom can use match By Email functionality so he/she can get directly E-mail
interested users for the match.
2. BACKGROUND

2.1.EXISTING SYSTEM

 As the existing system Marriage Bureau System is manual form entry is done
on paper by persons assigned to do it. They have to maintain each applicant’s
bio-data and their requirement in separate files.
 Applicants arrive with their bio-data such as name, address, their personal
information such as age, height, qualifications, occupation, income and
requirements for desired match.
 User manually feed these all information on paper. Even the most important
task of finding desired matches is done manually by comparing principle
attributes

2.2.DEFINITION OF PROBLEM

 A lot of information can be misplaced during manual entry and even if its online the
security offered is very vague and not reliable

 The user don’t get their suitable match easily

 The precise match can be done according to the advanced search, which isn’t
available.
2.3.PROPOSED SYSTEM

This Online Matrimonial System provides an easy to use interface from which the
user can see the profiles which are under their interest, send friend request in the
convenient way possible and also get further details about the user profile.

After the friend request is send to an user, the system waits till the user accepts the
friend request. It only shows the name and the profile picture if you’re not a friend
Once accepted the mobile number, email id and other pictures are visible. Hence
providing the safety of its own.

The user can block/ report the users and the reported user is then notified to the
admin. Further the admin flags the users, preventing the user to again sign in or
make a new id with the same e-mail id.
3. PROJECT OVERVIEW

3.1.OBJECTIVE OF THE PROJECT

What is Matrimonial Web Application?

The main objective of Matrimonial Web Application is to provide Grooms and Brides with
excellent matchmaking experience by exploring the opportunities and resources to meet true
potential partner. Keeping our objective in mind, we have created a world renowned online
matchmaking services that will touch the souls of millions of people all over the globe.

What are the purposes of Matrimonial Web Application?

The purposes of the Matrimonial Web Application are:


• The main purpose of this application is to facilitate matchmaking business by
applying the information in the field.
• It helps the user by providing profiles of perspective “bride” or “groom” and other
information regarding them online.
• User can get information regarding their dream life partner at his/her home at his/her
convenience.

3.2.STAKEHOLDERS

Users: Users can register and they can go on with updating the picture and adding the habits
and hobbies they can also find their suitable mate by advanced searching. The users can also
send the friend request to people and also report if required.

Administrator: The admin overlooks the functioning of the system and is responsible for
flagging the reported users for preventing them to use the id again. They can also see the user
statistics and the report.
3.3.SCOPE OF THE PROJECT

• Matrimonial website which will provide platform to a lot of Bride/Groom for finding perfect
match.
• There are different sectors like Registration, Partner , Search, etc. So the Bride/Groom can get
their interest for find their partner. Bride/Groom can directly search Partner according to their required
criteria.

3.4.FEASIBILITY ANALYSIS

3.4.1. Technical Feasibility

Technical feasibility assesses whether the current technical resources are


sufficient for the new system. If they are not available, can they be upgraded to
provide the level of technology necessary for the new system? It checks whether the
proposed system can be implemented in the present system without supporting the
existing hardware. Currently,

Technology exists to develop a system.


The proposed system is capable of holding data to be used.
The proposed system is capable of providing adequate response
and regardless of the number of users.

Hence, we can say that the proposed system is technically feasible.

3.4.2. Operational Feasibility

Operational feasibility determines if the human resources are available to


operate the system once it has been installed. The resources that are required to
implement or install are already available within the application itself. The easy and
simple user interface makes it effortless to work on. Even new users would be able to
work with the system with ease.

3.4.3. Schedule Feasibility


Schedule Feasibility is the process of accessing the degree to which the
potential time frame and completion dates for all major activities within a project meet
the same time frame previously set by the restaurant.

Schedule feasibility study for the design is shown below

Problem identification 5
Requirement analysis 10
Overall design 20
Construction 22
Testing 15

3.4.4. Economic Feasibility

Economic feasibility determines whether the time and money are available to
develop the system. It also includes the purchase of new equipment, hardware, and
software. Since software product must be cost effective in the development, on
maintenance and in the use. Since the hardware and resources are already available
with the restaurant and the restaurant can afford to allocate the required resources.
4. OVERALL PROJECT PLANNING

4.1.DEVELOPMENT ENVIRONMENT

Hardware Specifications

Processor: Pentium IV or above


Memory: 512 MB
Display: Color Monitor
Keyboard: Windows compatible
Mouse: Windows compatible

Software Specifications

Software Interface

i. Server side
: HTML, CSS,
Front End jQuery,JAVA
Back End : MySQL
Operating System : Windows/Linux
ii. Client side
Operating System : Windows/Linux
Software packages : Web Browser

4.2.CONSTRAINTS

The set of constraints that we come across this system is as follows:

User interface is only in English i.e. no other language option is available.

Unauthenticated user cannot add or update any data.

Limited to HTTP/HTTPS
4.3.DELIVERABLES

List of documents that shall be delivered are User Manual

System maintenance documentation.


Application archive with source
code. Database backup
Complete source code.

4.4.ASSUMPTIONS AND DEPENDENCIES

• All roles are created in the system already but further registration of users on
given roles can be done.
• Roles and tasks are predefined and are made known to the administrator.
.

4.5.RISKS

Some of the risks are follows


Database crash will cause heavy data loss

Wrong input will cause discrepancies in data

Availability of the network

4.6.PROCESS MODEL

The process model for developing the project is Agile model


The phases are:-
Requirement analysis
System study
Designing
Construction
Testing
Maintenances

Being agile, the project was adaptable to make changes even in the last stage of
development. It being an incremental model multiple development cycles was introduced.
Cycles are divided up into smaller, more easily managed modules. Each module passes
through all the phases. The process continues till the complete system is achieved.
4.7.TEST STRATEGY

System Testing

Testing is the penultimate step of software development. An elaborate testing of the data
is prepared and the system is using the test data. While doing testing, errors are noted and
correction is made. The users are trained to operate the developed system. Both hardware and
software securities are made to run the developed system successfully. System testing is aimed at
ensuring the system works accurately before the live operation commences. Testing is vital to the
system. System testing makes a logical assumption that if all parts of the system are correct, the
goal will be successfully achieved. The system is subjected to a variety of tests; unit testing,
integration testing and system testing. A series of testing are performed for the proposed system
before the system is ready for user acceptance testing. Nothing is complete without testing, as it
is vital success of the system. Normally, testing of any Large Systems will be in two parts.
Testing activity is involved right from the beginning of the project. At the very first stage of
testing, the goals and objectives are set. This simplifies the limits or borders of testing process.
Before testing, the tester should plan what kind of data he is giving for test. Give data inputs as
functional, boundary, stress, performance, usability values etc.
TYPES OF TESTING
Unit Testing

Unit Testing will be done to test field validations, navigation,


functionality of the programs and its block. These tests are applied on various functions
within each program and other critical program blocks. Table given below gives the outline of
three-sample test cases for Unit testing performed on the system.
Module Testing

Module Testing will be done to test the interaction between the various
programs within one module. It checks the functionality of each program with relation to
other programs within the same module. It then tests the overall functionality of each module.
Integration Testing

The major concerns of integration testing are developing an incremental


strategy that will limit the complexity of entire actions among components as they are added to
the system. Developing a component as they are added to the system, developing an
implementation and integration schedules that will make the modules available when needed, and
designing test cases that will demonstrate the viability of the evolving system. Though each
program works individually they should work after linking them together. This is also referred to
as interfacing. Data may be lost across interface and one module can have adverse effect on
another. Subroutines after linking may not do the desired function expected by the main routine.
Integration testing is a systematic technique for constructing program structure while at the same
time conducting tests to uncover errors associated with the interface. In the testing, the programs
are constructed and tested in small segments.
Validation Testing

This provides the final assurance that the software meets all the
functional, behavioral and performance requirements. The software is completely assembled
as a package. Validation succeeds when the software functions in a manner in which user
wishes. Validation refers to the process of using software in live environment in order to find
errors. During the course of validation the system failure may occur and sometime the coding
has to be hanged according to the requirement. Thus the feedback from the validation phase
generally produces changes in the software. Once the application was made of all logical and
interface errors, inputting dummy data ensure that the software developed satisfied all the
requirements of the user. The dummy data is known as test cases.
Output Testing

After performing the validation testing, the next step is output testing
of the proposed system since no system could be useful if it does not produce the required
output in the specific format. Asking the users about the format of output they required, tests
the output generated in two ways. One is on screen and another is printed format.

The output format on the screen found to be correct as the format was designed in the system
design phase according to the user needs. For the hard copy also, the output comes out as the
specified requirement by the user. Hence output testing does not result in any correction in the
system.

Acceptance Testing

Acceptance testing (also known as user acceptance testing) is a


type of testing carried out in order to verify if the product is developed as per the standards
and specified criteria and meets all the requirements specified by customer. This type of
testing is generally carried out by a user/customer where the product is developed externally
by another party.

Acceptance testing falls under black box testing methodology where the user is not
very much interested in internal working/coding of the system, but evaluates the overall
functioning of the system and compares it with the requirements specified by them. User
acceptance testing is considered to be one of the most important testing by user before the
system is finally delivered or handled over to the end user. Acceptance testing is also known
as validation testing, final testing, QA testing, factory acceptance testing and application
testing etc. And in software engineering, acceptance testing may be carried out at two
different levels; one at the system provider level and another at the end user level (hence
called user acceptance testing, field acceptance testing or end-user testing).

Acceptance test refers to the acceptance of data into the system for processing. The
acceptance test contributes to the consistency and smooth working of the system. The system
under consideration is tested for users at a time for developing and making changes whenever
required.
System Testing

When a system is developed, it is hoped that it performs properly. In


practice however some errors always occur. The main purpose of testing and information
system is to find the errors and correct them. A successful test is one which finds an error. The
main objectives of system testing are:

 To ensure during operation the system will perform as per specifications.

 To make sure that the system meets the requirements during operation.

 To verify that the controls incorporated in the system function as intended.

 To see that when correct inputs are fed to the system the outputs are correct.

 To make sure that during operation incorrect input and output will be deleted.

The scope of a system test should include both manual operations and computerized.
Operation system testing is a comprehensive evaluation of the programs, manual procedures,
computer operations and controls. System testing is the process of checking if the developed
system is working according to the original objectives and requirements. All testing needs to be
conducted in accordance to the test conditions specified earlier.

4.8.Testing environment and tools

The hardware specification used for testing

Operating system Windows 10


Memory 4 GB
Hard Disk 1 TB

Hardware Specification
The software specification used for testing

Tools Netbeans,Workbench
Front End HTML, CSS, JavaScript, JAVA
Back End MySQL

Internet Standard HTTP, HTTPS


Operating System Windows 10

Software Specification

5. ITERATION PLANNING

5.1.SCHEDULE

SERIAL
NO. TASK DURATION
1 Problem identification 5
2 Requirement analysis 10
3 Overall design 20
4 Construction 22
5 Testing 15

Total 72 days

5.2.RISKS

Wrong input
No internet connection

6. ITERATION PLANNING

6.1.USER CHARACTERISTICS

All users of the system are expected to have basic knowledge of using a computer
and basic knowledge in English language.

Users of the system

• Administrator
• User

6.2.SUMMARY OF SYSTEM FEATURES/FUNCTIONAL REQUIREMENTS

The main modules are:

USER REGISTRATIONS
The module where the customers enter their personal details and the new users are
automatically added to the database. Existing user’s information is retrieved as per
required.

ADMIN PAGE
The Admin page is used to display all details of the users as well as stats of the users.
He may see all the reported users and the users number from different categories.

REPORT GENERATION

Administrator has the ability to generate reports about various things. He may
generate which users are from which cities and the number of people gender wise.

PICTURE UPDATION

The Users can update their profile picture and other gallery pictures according to
their wish.

EDIT PROFILE
The Users can update their profile whenever and however needed.
6.3.NON FUNCTIONAL REQUIREMENTS/ SUPPLEMENTARY
SPECIFICATION

The nonfunctional requirements which define the system performance are:

Accuracy:

The level of accuracy in the proposed system will be high. All operations would be done
correctly and it ensures that whatever information that comes from the center is accurate.

Reliability:

The reliability of the proposed system will be high. The reason for the increased
reliability of the system is that system uses correct formulas to calculate the results.

Immediate Response:

The system is highly responsive because it uses well accurate formulas to calculate
required results provided the user should enter the valid input data.

Easy to Operate:

The system should be easy to operate and should be such that it can be developed
within a short period of time and fit in the limited budget of the user.
The other non-functional requirements are:

o Security

o Maintainability

o Extensibility

o Reusability

o Resource utilizations

6.4.GLOSSARY

DBMS Database Management System

Admin Administrator

6.5.BUSINESS RULES

The information should be correct and valid.

6.6.USE CASES

USER REGISTRATION
The users enter their personal details and the new users are automatically added to the
database. Existing user’s information is retrieved as per required. In this manner, we have a table
having all unique customers that have used the system .
USER MANAGEMENT
The admin can disable certain users once reported

REPORT MANAGEMENT
The admin can create various reports as he needs and use them to better improve his
business.

6.7. USE CASE DIAGRAM

Administrator

Customers
6.8. E-R DIAGRAM
7. DOMAIN MODEL
8. USE CASE MODEL

1.0 Use case Name

Admin

1.1 Basic Flow

Admin starts this use case. It provides the capability for the admin to verify different procedures.

2.0 Flow of Events

2.1 Basic Flow

Admin perform the main activity like flagging the users generating the report

2.2 Alternate Flows

2.2.1 Invalid Password

An invalid password is entered. The user can re-enter a password or terminate the use case.

2.2.2 Invalid Username:

The system informs the user that the username is invalid. The user can re-enter the username or
terminate the use case.

3.0 Special Requirements

There are no special requirements for this use case.

4.0 Preconditions

There are no special requirements for this use case.

5.0 Post Conditions

There are no post conditions.

6.0 Extension Points

There are no extension points.


1.0 Use case Name

User.

Brief Description

User can perform several operations on the system like registration, login. He or she can also edit his
or her profile, searching facility is also there.

2.0 Flow of Events

2.1 Basic Flow

User can perform mainly four activities.

Registration:-

Before using this system the user must have to register in the system. He have to fill up the form and
enter his/her profile in the database.

Login:-

The existing users are giving his/her userid & password to access their accounts. If they are
successfully login then they can edit or update their accounts.

Edit profile:-

The user can also edit his/her personal profile in the system but first he/she have to login in the
system.

2.2 Alternate Flows

2.2.1 Invalid Password

An invalid password is entered. The user can re-enter a password or terminate the use case.
2.2.2 Invalid Username:

The system informs the user that the username is invalid. The user can re-enter the username or
terminate the use case.

3.0 Special Requirements

The user must be first login to access his accounts.

4.0 Preconditions

The user must be first login to access his accounts.

5.0 Post Conditions

There are no post conditions.

6.0 Extension Points

There are no extension points.


User Registration

8.2.Operation Contracts

Operation: registerUser (username: string, address: string, phone: int)

Cross Reference: Use case: User registraion


Preconditions: Web server is up
Postconditions:
- A new registration instance was created.
- Accepted username, password are stored it in respective attributes.
- After validation, data are inserted into database.
9.SYSTEM SEQUENCE DIAGRAM
10.ACTIVITY DIAGRAM

DISPLAY RECORDS

SEARCH RECORDS
UPDATE RECORD

11. CLASS DIAGRAM

ADMIN CLASS DIAGRAM


LOGIN CLASS DIAGRAM

USER CLASS DIAGRAM


12
DESIGNMODEL
12.1.UI Design

Home- matrimonial page

About Us Page
Contact info page

Success Stories
Registration Form-1
UPLOADING PROFILE PIC

HOME PAGE
EDIT PROFILE

UPDATE PROFILE PICTURE


ADVANCED SEARCH

SEARCH RESULT
GALLERY

FRIEND REQUEST
ADMIN PAGE
9.2.Database Design

16.1.1 Bad_report
16.1.1.1 br_username VARCHAR (25)
16.1.1.2 br_flag int (2)
16.1.1.3 br_admin_flag int (5)
16.1.2 extra_images
16.1.2.1 idextra_images int (11)
16.1.2.2 e_userid VARCHAR (20)
16.1.2.3 e_filename VARCHAR (20)
16.1.3family_info
16.1.3.1 fam_asc int (4)
16.1.3.2 fam_status, VARCHAR (25)
16.1.3.3 fam_brother_status,VARCHAR (12)
16.1.3.4 fam_brothers,INT(11)
16.1.3.5 fam_sister_status,VARCHAR (12)
16.1.3.6 fam_sisters,INT(11)
16.1.3.7 fam_mother_status,VARCHAR (12)
16.1.3.8 fam_father_status,VARCHAR (12)
16.1.3.9 fam_contact,VARCHAR (10)
16.1.3.10 fam_location,VARCHAR (60)
16.1.3.11 fam_values,VARCHAR (10)
16.1.3.12 fam_type,VARCHAR (12)
16.1.3.13 fam_username,VARCHAR (17)

16.1.4 friend
16.1.4 .1 f_status,VARCHAR (16)
16.1.4.2 f_who,VARCHAR (10)
16.1.4.3 f_you,VARCHAR (10)
16.1.4.4 idfriend,INT(10)
16.1.5 Login

16.1.5.1 lg_password,VARCHAR (12)


16.1.5.2 lg_username,VARCHAR (12)

16.1.6 misc
16.1.6.1misc_music,VARCHAR (12)
16.1.6 .2misc_language,VARCHAR (12)
16.1.6.3 misc_eat_habit,VARCHAR (12)
16.1.6.4 misc_income,VARCHAR (12)
16.1.6.5 misc_additional_degree,VARCHAR (12)
16.1.6.6 misc_edu_detail,VARCHAR (12)
16.1.6.7 misc_highest,VARCHAR (12)
16.1.6.8 misc_disabilty,VARCHAR (12)
16.1.6.9 misc_email,VARCHAR (12)

16.1.7 partner_pref
16.1.7 .1 pp_city,VARCHAR,utf8,45,5,0
16.1.7 .2 pp_fam_loc,VARCHAR,utf8,20,18,0
16.1.7 .3 pp_fam_val,VARCHAR,utf8,12,7,0
16.1.7 .4 pp_fam_type,VARCHAR,utf8,7,7,0
16.1.7 .5 pp_food,VARCHAR,utf8,15,4,0
16.1.7 .6 pp_body_type,VARCHAR,utf8,7,7,0
16.1.7 .7 pp_age,INT,binary,11,2,0
16.1.7 .8 pp_id,INT,binary,11,1,0
16.1.7 .9 pp_email,VARCHAR,utf8,50,17,0

16.1.8 phy_activitiy

16.1.8.1 phy_hobbies,VARCHAR,utf8,250,133,0
16.1.8.2 phy_sports,VARCHAR,utf8,200,38,0
16.1.8.3 phy_email,VARCHAR,utf8,50,17,0
16.1.9 registration
16.1.9.1 reg_id,INT,binary,11,2,0
16.1.9.2 reg_name,VARCHAR,utf8,50,16,0
16.1.9.3 reg_dob,DATE,binary,10,10,0
16.1.9.4 reg_email,VARCHAR,utf8,70,18,0
16.1.9.5 reg_mstatus,VARCHAR,utf8,15,6,0
16.1.9.6 reg_religion,VARCHAR,utf8,15,9,0
16.1.9.7 reg_nationality,VARCHAR,utf8,20,8,0
16.1.9.8 reg_state,VARCHAR,utf8,20,11,0
16.1.9.9 reg_city,VARCHAR,utf8,20,9,0
16.1.9.10 reg_drinking,VARCHAR,utf8,12,10,0
16.1.9.11 reg_smoking,VARCHAR,utf8,12,3,0
16.1.9.12 reg_qualification,VARCHAR,utf8,15,13,0
16.1.9.13 reg_about,VARCHAR,utf8,500,198,0
16.1.9.14 reg_dp,VARCHAR,utf8,100,51,0
16.1.9.15 reg_bodytype,VARCHAR,utf8,12,8,0
16.1.9.16 reg_weight,INT,binary,11,2,0
16.1.9.17 reg_height,INT,binary,11,3,0
16.1.9.18 reg_occupation,VARCHAR,utf8,100,58,0
16.1.9.19 reg_contact,VARCHAR,utf8,10,10,0
16.1.9.20 reg_job,VARCHAR,utf8,45,29,0
16.1.9.21 reg_gender,VARCHAR,utf8,7,6,0

16.1.10 report_history
16.1.10.1 re_when,DATE,binary,10,10,0
16.1.10.2 re_reported_who,VARCHAR,utf8,45,16,0
16.1.10.3 re_who_reported,VARCHAR,utf8,45,17,0
16.1.10.4 re_id,INT,binary,11,1,0

16.1.11 request

16.1.11.1 idrequest,INT,binary,11,1,0
16.1.11.2 req_by,VARCHAR,utf8,45,17,0
16.1.11.3 req_who,VARCHAR,utf8,45,17,0
16.1.11.4 req_status,INT,binary,11,2,0
16.1.11.5 req_when,DATE,binary,10,10,0
16.1.11.6 req_action,DATE,binary,10,10,0

16.1.12 success_story
16.1.12.1 to_who,VARCHAR,utf8,45,0,0
16.1.12.2 idsuccess_story,INT,binary,11,0,0
16.1.12.3 who_id,VARCHAR,utf8,45,0,0
16.1.12.4 message,VARCHAR,utf8,100,0,0
16.1.12.5 when,DATE,binary,10,0,0
10. TESTING

10.1. Test Cases


Incorrect information of existing users

A recurring user must only enter his phone number to retrieve the rest of his
details, in case he enter it wrong, the transaction will not be processed. Precondition:
The phone number does not exist in database.
Assumption: Only authorized phone numbers have the ability to retrieve rest of details.
Test Steps:
1. Goto Registration Page
2. Enter credentials
3. Submit the credentials
Expected Result: Wrong phone number must be prompted with a message showing
invalid number in credentials.

Proper Registration of Users

New users are expected to enter valid details into the system when ordering for
the first time.
Precondition: Data access permissions are to be well defined Assumption:
Every users are defined with access permissions of their own. Test Steps:
1. Submit cart and then reach the registration page
2. Enter details and press submit
3. Information given regarding unique customer
ID. Expected Result: Incorrect fields must be prompted.
11. TRANSITION
11.1. SYSTEM IMPLEMENTATION

Implementation is the process of having the system personal checks out and put
equipment to use, train the users to use the new system and construct any file that are
needed to see it. The final and important phases in the system lifecycle are the
implementation of new system. The file conversion is the most time consuming and
expensive activity in the implementation stage. System implementation refers to the
step necessary to install a new system to put into the operation. The implementation
has different meaning, raining from the conversion of basic application to complete
replacement of computer system. Implementation includes all these activities that
take place to covert from old system to new system. The new system may be totally
new replacing and existing manual or automated system or it may be major
modification to an existing system. The method of implementation and time scale
adopted is found out initially. The system is tested properly and at the same time the
users are trained in new procedure. Proper implementation is essential to provide a
reliable system to meet organization requirements. Successful implementation may
not guarantee improvement in the organization using the new system, but it will
prevent improper installation. The implementation involves the following things:-
1. Careful planning.
2. Investigation of the system and constrains
3. Design the methods to achieve the changeover.
4. Train the staff in the changed phase.
5. Evaluation of change over method.

After converting as a package, it has been delivered to the customers where it is


implemented and tailored to meet the specific requirements.

11.2. SYSTEM MAINTENANCE

Like house work, dirty clothes and weeds, system work never seems to an end;
users almost always want changes or encounter problems. Thus the system
maintenance part of the system process deserves special attention. It is during system
maintenance that the analyst:
1. Resolves necessary changes
2. Correct errors.
3. Enhance or modifies the system.
4. Assign staff to perform maintenance activities.
5. Provides for scheduled maintenance.

Most system spends the bulk of their time in the maintenance phase, with constant
enhancements and repairs. Studies show that more money is spent in this forth phase
than in all of the others combined. Writing system is that require as little maintenance as
possible is one of the primary goal as well as one of the benefits of today’s modern
methodology of software development. Maintenance ids divided into three categories.

1. Corrective maintenance.
2. Adaptive maintenance.
3. Preventive maintenance.

11.2.1. Corrective maintenance


It has to do with the removal of residual errors present in the product when it is
delivered as well as errors introduced into the software during its maintenance
accounts for about 20% of the maintenance cost.
11.2.2. Adaptive maintenance
It involves adjusting the application to changes in the environment, that is a new
release of the hardware or the operating system or anew database system. It also
accounts for nearly 20% of the maintenance cost.
11.2.3. Preventive maintenance
It involves changing the software to improve some qualities. It accounts for over
50% of maintenance costs. Here changes are due to the functions offered by the
application, and new functions, improve the performance of application etc.
Maintenance is not such a difficult task. The above three maintenance tasks can
be easily carried out under this system.

12. ANNEXURE
12.1. References

Websites

[1] https://www.w3schools.com/css/css_intro.asp
[2] https://www.tutorialspoint.com/css/
[3] html.net/tutorials/css/lesson1.php
[4] www.phpsnaps.com/snaps/view/php-image-slideshow-auto

12.2. Annexure I: User Interview Questionnaires

1 How would you approach the system?


2 What about usability of this system?
3 What are normal project requirements?

You might also like