My undergraduate Thesis report " Analysis Design & Development of University Student Payment System "
A
project report on
Analysis,
Design & Development of University Student Payment System
The Report submitted to the Department of Computer Science &
Engineering of World University of Bangladesh in partial fulfillment of the
requirement of the degree of B.Sc. in Computer Science & Engineering.
Md. Mojibul Hoque
Reg: WUB-03/10/23/504
and
Md. Belal Hossain
Reg: WUB-03/10/23/489
Supervised by:
Kazi
Hassan Robin
Senior Lecturer
Department of Computer Science and Engineering
World University of Bangladesh
January, 2014
LETTER OF TRANSMITTAL
January, 2014
To
Mr. Kazi Hassan Robin
Senior Lecturer
Department of Computer
Science and Engineering
World University of
Bangladesh (WUB)
House # 3/A, Road # 4,
Dhanmondi, Dhaka 1205,
Bangladesh
Subject: Submission of the Project Report.
Dear Sir,
We
are pleased to submit the project report entailed “University Student Payment
System”. It was a great pleasure to work on such an important topic. The report
is prepared according to the requirement and guidelines of WUB.
We
believe that the report will certainly help you in evacuating our project work.
It would be a great pleasure for us
interpret any part or whole of the report whenever necessary.
Sincerely yours
Md. Mojibul Hoque Md.Belal
Hossain
Reg: WUB-03/10/23/504 Reg:
WUB-03/10/23/489
DECLARATION
We
hereby declare that this project work entitled “University Students Payment System” has been supervised by Mr. Kazi Hassan Robin, Head of the
Department of CSE, World University of
Bangladesh. We further assure that this project work was not submitted
either in whole or part for any Degree or Diploma in any university previously.
We herby warrant that the work we have presented does
not breach any existing copyright rule.
We
further undertake to indemnity the university against any loss or damage from
breach of the forgoing obligation.
Md. Mojibul Hoque Md.Belal
Hossain
Reg: WUB-03/10/23/504 Reg:
WUB-03/10/23/489
CERTIFICATE
This
is to certify that the project report on “University
Students Payment System” is a bona fide record of project work done by Md. Mojibul Hoque Reg: WUB-03/10/23/504
and Md. Belal Hossain Reg:
WUB-03/10/23/489 For the partial fulfillment for the requirements of the
degree of “B.Sc in Computer Science and Engineering” from the Department of
Computer Science of engineering from the World University of Bangladesh (WUB).
This
project paper has been carried out under my guidance and is a record of the
bona fide work carried out successfully by the students.
Project Supervisor
Mr. Kazi Hassan Robin
Senior
Lecturer
Department
of Computer Science and Engineering
World University of Bangladesh
(WUB)
ACKNOWLEDGEMENT
We are extremely grateful and
remain indebted to Almighty ALLAH who has guided us in all ventures to
successfully complete this project. We are thankful to the grace and the help
received from him. It is our pleasure to thank our honorable Vice Chancellor of
WUB, Professor Dr. Abdul Mannan
Choudhury, to whom we owe a lot for giving us an opportunity to complete
our project.
The project would not be
successful without the constant and valuable guidance of Mr. Kazi Hassan Robin,
Head of the Department of CSE, our
supervisor for the project, who had rendered all sorts of support as and
when required. We are thankful for his constructive criticism and valuable
suggestions, which has benefited us a lot while implementing the project on “University Student Payment System”. He
had been a constant source of inspiration and motivation for our hard work. He
had been very co-operative throughout this project work. Through this column,
it would be our upmost pleasure to express our warm regards to him for his
encouragement, and co-cooperativeness.
We are greatly indebted to all
teachers and staffs of the Department of Computer Science and Engineering and
other departments of the World University of Bangladesh for their kind assistance in
accomplishment of this project work.
We are
thankful to our all friends, who are indeed, very close to our heart. One can never find the right
words to thank one's parents. We will always be indebted for the love and care
that our parents have showed on us, and have done every possible effort to
reach us at this stage. We are very lucky to get such caring and loving
parents. We feel the same way for our parents who have been the source of our
inspiration.
Authors:
Md. Mojibul Hoque Md.Belal
Hossain
Reg: WUB-03/10/23/504 Reg:
WUB-03/10/23/489
Table of Contents
Table of Figures
ABSTRACT
University Student Payment System ‘USPS’
is an online base bespoke application system. It is mainly an accounting system
but it is not a conventional accounting system. It has some specialty; it is
specific only for student. Students will be able to pay their tuition and other
semester fees online using this system. Guardian will able to pay their
students fees through online and able to see the student financial statement.
It has various message options to notify transaction information like as mobile,
emailing also own messaging system. On demand University Student Payment System
users will be able to view receipts, payment statement from anywhere in the
world using Internet.
At the primary stage of developing
University Student Payment System, we have studied similar systems. Most of
systems are e-commerce system. USPS has some similarity with e-commerce system,
because students have payment their fees using their bank account, credit or
debit card and using their mobiles through third party payment gateway.
Requirement collection, analysis and
design are the part of the software development process. It is discovering the
purpose of the system its help to design application. In this system uses
various methods. Interviewing is one of them. Use case, Data flow diagram, flow
chart are design base on system analysis.
Iterative methodology has been used to
develop University Student Payment System. Iterative methodology is one of the
most uses software developing method in Software engineering field. It is very
suitable for bespoke software application. Because its allow more flexibility
for changes. Planning, Requirements, Analysis and Design, Implementation,
Deployment, Testing and evaluation are the part of iterative methodology.
University Student Payment System very
scalable and secure system and it is easily customizable on future demand. It
has some limitations. University Student Payment System uses Oracle Platforms
and Oracle are not free it’s required a licenses from Oracle corporation, USA.
USPS (University Student Payment System) has no integrated payment gateway but
it has an option to interface with third-party payment gateway service
provider. Develop own payment gateway and incorporate within University Student
Payment System is our future plan. In future University Student Payment system transfer
to open source technology for relieves software licensing issue and open the
access for new software engineer.
CHAPTER 1: INTRODUCTION
1.1 University Student Payment System (USPS)
University
Student Payment System (USPS) is an online based application software that
integrates account related issues for students, guardians, and the accounts
department of an University. At present World University of Bangladesh (WUB) is
using manual account payment system. But it has many limitations. The present manual
system is not capable of providing quick complete account details on request of
students, guardians and exam control. Due to manual processing of payments,
long ques are often created in front of accounts department. As a consequence this
student often misses their classes and exams. In order to get rid of those
problems we have developed University Students Payment System.
Using
this University Student Payment System student and their guardians will be able
to pay various university fees online using their debit or credit cards.
Students and their guardians will be able to see all payments records any time
they wish. They will also be able to see future payment schedules. They will be
able to print receipts as well. The accounts department of the university will
be able to generate various types of reports on a particular student of a batch
for a particular month or for any time period. The account department will be
able to track down all pending payments of any student with few clicks.
1.2 Justification
In manual system
students manually pay their fees in accounts department. Every time long que is
generated due to this staffs of accounts dept also faces several problems attending
so many students at the same time.
In
order to eliminate this type of Problem and saving the valuable time as well as
make simple and friendly complete payment system. We recommended online payment
system. It is the solution to solve the present problematic system. It may
improve the whole process of this WUB especially accounts departments.
The
proposed system is online based software. This application securely keeps
student information and keeps financial transaction record. Student easily pays
their fees and accountant taken the fees from the student very easily. After
the transactions system will inform user through various way like mobile
messaging, email and application own messaging system.
1.3 Objectives:
The
objectives of the project are as follows:
1.
To design & develop an online payment system
through which students/ parents will be able to make payments and print/ view
receipts, payment history from virtually anywhere.
2.
To enable the accounts department of the University to
keep the payment records stored in a secured manner and to generate various
types of reports on the basis of the payments of the students.
CHAPTER- 2: OVERVIEW
2.1 Literature Review
Before
starting the analysis and design of USPS we have studied similar systems well.
There is no similar research result that covers all the aspects that we would
discuss. Most of the research results in the area of payment system are
concerned with e-commerce. Nevertheless, the following are some that are
related to our proposed model.
Discuss
a multi-user electronic bill presentment and payment model that enhance the
current billing systems as well as overcome the problems of the periodic
generation of billing reports and mail volumes. The biller sends the detailed
bills to the consolidation website and the summery to the customers. The
registered customers (of the consolidation website) could check and pay the
bills at any time. Here, the consolidation website could have many
registered-biller clients.
Presents
a pilot project to determine the feasibility of adopting an application service
provider solution to support procurement by multiple federal agencies using a
variety of different legacy transaction systems.
2.2 University Student Payment System (Overview)
The simplest way to pay student fees is online, by debit or
credit card, using the University’s secure payment system the following cards are
accepted:
- Credit
card processing for VISA and MasterCard
- Debit
card processing for DBBL Nexus card, Brac Bank debit card
- Bank
Account processing for Dutch Bangla Bank, Brac Bank
This
system is secure and operates in conjunction with SSLCOMMERZ. A receipt will be
sent to the e-mail address used when making the payment. Student should keep
this as proof of payment. This business process covers the management of
student payment system for the University where any fees are managed in the
student management system.
2.3 Scope of the study
The
purpose of USPS is to manage and calculate all student financial information,
including tuition fees and other charges, receivables, invoices, payments and
refunds.
- Ensures timely and accurate
charges are applied to students and sponsors
- Minimizes or eliminates
manual intervention required to charge fees by using a rules based
- Methodology triggered by
attributes of the student, course and units of study enrolled.
- Informs students and
sponsors of their obligations in a clear, accurate and timely manner
- Facilitates easy payment by
students and sponsors
- Provides ease of access to
account information for students, encouraging self-service
- Students can easily access
information about amounts owing, including a breakdown of Charges and
payment due dates.
- Clear and transparent
charging methodologies (maintaining quality and integrity of information)
- Recognition of full fee with
any discounts acknowledged as credits on the student account
- Charges should be automatic
based on rules
- Account posting to Finance
should be automatic and daily
- Account reconciliation
should be regular and easy.
- Minimizes the administrative
work for staff.
- Minimizes or eliminates
manual intervention required to charge fees by using a rules based
- Methodology triggered by
attributes of the student, course and units of study enrolled.
- Information is available to
the right people.
- Reporting capabilities are
well developed.
Integrates
efficiently and effectively with the Finance System
3.1 Methodology
We
have used the iterative methodology to accomplish University Student Payment
System web development project. This methodology is designed to take care of
such big projects. The large and complicated projects chiefly demand better
development and testing procedures. The iterative methodology is well known for
its repeated testing process. Hence, we choose iterative methodology for
developing software solutions. Iterative development is a way of breaking down
the software development of a large application into smaller chunks. In
iterative development, feature code is designed, developed and tested in
repeated cycles. With each iteration, additional
features can be designed, developed and tested until there is a fully
functional software application ready to be deployed to customers.
Typically
iterative development is used in conjunction with incremental development in
which a longer software development cycle is split into smaller segments that
build upon each other. Iterative and incremental development is key practices
in agile development methodologies. In agile methodologies, the shorter
development cycle, referred to as an iteration or sprint, is time-boxed
(limited to a certain increment of time, such as two weeks). At the end of the
iteration, working code is expected that can be demonstrated for a customer.
Iterative
development contrasts with a traditional waterfall method in which each phase
of the software development life cycle is “gated.” Coding doesn’t begin until
design of the entire software application is complete and has gone through a
phase gate review. Likewise, testing doesn’t begin until coding is complete and
has passed necessary phase gate reviews.
The
purpose of working iteratively is to allow more flexibility for changes. When
requirements and design of a major application are done in the traditional
method (sometimes referred to as BDUF or Big Design Up Front), there can be
unforeseen Iterative development prescribes the construction of initially small
but ever-larger portions of a software project to help all those involved to
uncover important issues early before problems or faulty assumptions can lead
to disaster.
Iterative
life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just
part of the software, which can then be reviewed in order to identify further
requirements. This process is then repeated, producing a new version of the
software for each cycle of the model.
Requirements of the complete system are clearly
defined and understood. When the project is big. Major requirements must be
defined; however, some details can evolve with time.
Planning
Planning
is an objective of each and every activity, where we want to discover things
that belong to the project. An important task in creating a software program is
extracting the requirements or requirements analysis. Customers typically have
an abstract idea of what they want as an end result, but do not know what
software should do. Skilled and experienced software engineers recognize incomplete,
ambiguous, or even contradictory requirements at this point. Frequently
demonstrating live code may help reduce the risk that the requirements are
incorrect.
Once
the general requirements are gathered from the client, an analysis of the scope
of the development should be determined and clearly stated. This is often
called a scope document.
Certain
functionality may be out of scope of the project as a function of cost or as a
result of unclear requirements at the start of development. If the development
is done externally, this document can be considered a legal document so that if
there are ever disputes, any ambiguity of what was promised to the client can
be clarified.
Implementation,
Testing and Documenting
Implementation
is the part of the process where software engineers actually program the code
for the project. Software testing is an integral and important phase of the
software development process. This part of the process ensures that defects are
recognized as soon as possible.
Documenting
the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing
of an API, be it external or internal. The software engineering process chosen
by the developing team will determine how much internal documentation (if any)
is necessary. Plan-driven models (e.g., Waterfall) generally produce more
documentation than agile models.
Deployment
and Maintenance
Deployment
starts directly after the code is appropriately tested, approved for release,
and sold or otherwise distributed into a production environment. This may
involve installation, customization (such as by setting parameters to the
customer's values), testing, and possibly an extended period of evaluation.
Software
training and support is important, as software is only effective if it is used
correctly. Maintaining and enhancing software to cope with newly discovered
faults or requirements can take substantial time and effort, as missed
requirements may force redesign of the software.
3.2 Phases / Steps
Incremental
development slices the system functionality into increments (portions). In each
increment, a slice of functionality is delivered through cross-discipline work,
from the requirements to the deployment. The unified process groups
increments/iterations into phases: Inception, Elaboration, Construction, and
Transition.
- Inception: Identifies project scope,
requirements (functional and non-functional) and risks at a high level but
in enough detail that work can be estimated.
- Elaboration: Delivers a working
architecture that mitigates the top risks and fulfills the non-functional
requirements.
- Construction: Incrementally fills-in the
architecture with production-ready code produced from analysis, design,
implementation, and testing of the functional requirements.
- Transition: Delivers the system into
the production operating environment.
3.3 Advantages
- Generates working software
quickly and early during the software life cycle.
- More flexible – less costly
to change to change scope and requirements.
- Customer can respond to each
built.
- Lowers initial delivery
cost.
- Easier to manage risk
because risky pieces are identified and handled during it’d
iteration.
- In iterative model less time
is spent on documenting and more time is given for designing.
3.4 Disadvantages
§ Needs
good planning and design.
§ Needs
a clear and complete definition of the whole system before it can be broken
down and built incrementally.
§ Each
phase of iteration is rigid with no overlaps.
CHAPTER- 4: REQUIREMENT ANALYSIS AND DESIGN
4.1
Requirement:
Requirements process is the
part of software development in which people attempt to discover what is
desired. This presupposes that there is some objective need, and analysis will
reveal what that need is. To make things more complicated, any project has a
number of different stakeholders with different interests, and it is usually
not feasible to incorporate all desires of all stakeholders. Choices have to be
made and somebody has to put some effort into making the stakeholders accept
the resulting requirements specification.
•
Finding out what the problem is, and what kind
of solution is desired (steps 1–3)
•
Drawing up a requirements specification for the
desired solution (steps 4–6)
•
Maintaining the requirements specification when
requirements change later on in the project (step 7) In each phase we can
distinguish four different kinds of activities:
·
Preparation:
getting organized before you start, finding out what you are going to do and
whom we may want to talk to, etc.
·
•
Elicitation:
going out and finding requirements, by asking people, observing, reading
documents, etc.
•
•
Engineering:
putting things together: specifying what elicited and observed, organizing and
combining things. There is always an element of design involved.
•
•
Negotiation
and decision making: This is politics, rather than engineering, but is an
inevitable part of getting a requirement specification accepted. The complete
life cycle model is shown in Figure 1. The phases cycle through the different
activities, yielding our seven steps:
In
order to find out the requirements we have used interviewing techniques.
4.2 Interviewing
Total number of interviewing
people 10 (Ten)
- Students – 05
- University Accountant - 01
- Exam Control Executive - 01
The interviews Questions are
Below:
§
University Accountant
o
Question:
Sir, we are developing a Student Payment System (SPS) for our thesis
project. Can you describe how to collect various fees from student and how do
you store it in the register?
o
Answer: I
cannot answer this question. I require permission from higher authority.
§
Exam Control Executive
o
Question: Sir, we are developing a Student
Payment System (SPS) for our thesis project. How to collect student financial statement;
please describe the statement collection procedure?
o
Answer: It is a university internal matter. So
cannot describe you. It’s requires permission from high authority of the university.
§
Students
o
Question: How do you pay your tuition fees?
o
Answer: Every student tell us they pay their tuition
fees in accounts sections.
o
Question: Do you feel any bothering to pay your
fees?
o
Answer: Most of them students tell they feel
nuisance, because almost in accounts sections student maintain a long queue to
pay their fees.
o
Question: Do you pay you fees all at once or in
installment per semester?
o
Answer: All most every student pay their fees in
installment and a few of them pay all at once.
o
Question: Is there any option to pay fee online
or any other method?
o
Answer: No, There is no option to pay fee
online. All fees are collected by accounts department.
o
Question: Is there any option to collect or view
previous financial statement?
o
Answer:
There no easy way to collect or view previous statement. It is very
painful when students lost their payment receipt.
o
Question: Is there any option to guardian know
financial statement?
o
Answer:
Options available not so easy.
Findings from the interviews:
Everybody
keep their viewpoint like student’s wants to pay their fee in online they are not
very comfortable with the current system. That works very lengthy. And
reporting opportunity is very low.
Guardian
wants to keep update themselves that his/her boy/girl gives tuition fee timely
and they also wants to view total transaction history at a glance.
University
Accountant have many problem to keep fast and secure the student payment record
as per their customize reporting.
Exam
Control Executive has dependency on accounts department manual reporting. They
want online system to see real-time transaction update.
After
considering all of requirements we develop a system design to overcome all
complexity of current system.
4.3 Flow Chart of Proposed University Student Payment System
 |
Fig 3.3: Flow chart of University
Student Payment System
4.4 Technical Requirements:
Server Side:
- Oracle 11g database Server
- Oracle forms for develop the application.
- Oracle Reports of reporting tools.
Client Side:
- Any updated web browser.
- Adobe PDF reader.
- Java runtime environment (JRE)
- For online payment Bank Card is mandatory.
CHAPTER- 5: DESIGN AND DEVELOPMENT
The
purpose of design phase is to plan a solution of the problem Specified by the
requirements document. This phase is the first step in moving from the problem
domain to solution domain. The design activity often results in three separate
outputs: architecture design, high level design and detailed design.
5.1 Design specification
The
topic provides idea regarding general structure of application keeping system
constrains and functionality, in view. The design mean to plan or sketch out
the form and method of a solution. The design represents the major
characteristics of the final system and determines the upper bound in quality
for the system. System design emphasizes on two aspects of a system:
- Dividing the system into
component.
- Defining interrelationship
between systems.
System
design consists of two steps:
- Logical design
- Physical design
Logical design
The logical
design of a system pertains to an abstract representation of the data flows,
inputs and outputs of the system. This is often conducted via modeling, using an
over-abstract (and sometimes graphical) model of the actual system. In the
context of systems design are included. Logical design includes ER Diagrams i.e.
Entity Relationship
Diagram and Use case Diagram
Physical design
The physical design relates to the actual input and
output processes of the system. This is laid down in terms of how data is input
into a system, how it is verified/ authenticated, how it is processed, and how
it is displayed as In Physical design; the following requirements about the
system are decided.
- Input requirement.
- Output requirements.
- Storage requirements.
- Processing Requirements.
- System control and backup or recovery.
Put another way, the physical portion of systems
design can generally be broken down into three sub-tasks:
- User
Interface Design
- Data
Design
- Process
Design
We divided the project design into four modules
- Input design
- Output design
- Database design
- Control design
Input
design
Once
the output requirements have been finalized, the next step is to find out what data
need to be made available to the system to produce the desired outputs. The
basic documents in which these data are available need to be identified. If
necessary, these documents may have to be revised or new documents may have to
be introduced.
Output
design
The
starting point of the design process is the proper knowledge of system requirements
which will normally be converted in terms of output.
Database design
Database design is the process of producing a detailed
data model of a database. This logical data model contains all the needed
logical and physical design choices and physical storage parameters needed to
generate a design in a Data Definition Language, which can then be used to
create a database. A fully attributed data model contains detailed attributes
for each entity.
The term database design can be used to describe many
different parts of the design of an overall database system. Principally, and
most correctly, it can be thought of as the logical design of the base data
structures used to store the data. In the relational model these are the tables
and views. In an object database the entities and relationships map directly to
object classes and named relationships. However, the term database design could
also be used to apply to the overall process of designing, not just the base
data structures, but also the forms and queries used as part of the overall
database application within the database management system (DBMS).
Control
design
The
control design indicates necessary procedures which will ensure correctness of
processing, accuracy of data, timely output etc. this will ensure that the
system is functioning as per plan.
5.4 Entity Relationship Diagram (ERD)
An
entity-relationship (ER) diagram is a specialized graphic that illustrates the
relationships between entities in a database. ER diagrams often use symbols to
represent three different types of information. Squire box commonly used to
represent entities. Oval represents attributes. Diamonds represent operations.
Lines represent relationships between entities.
|
CHAPTER – 6: Project Description
University
Student Payment System is bespoke application system. This system runs on a web
browser. Its application consist of Java based technology so its require a JVM
or JRE. That’s why this application is not depend on Operating System. It is
run any operating system which is support JVM.
University
Student Payment System has various users depend on their rules. There are:
§
Administrator: Administrator is the root user of
University Student Payment System. He control or supervise the whole system. He
create user and provide necessary writes to them.
§
Student: Student is another user of this system.
Student has limited access to this system. Student only view own payment
statement and have an option to pay own fees.
§
Guardian: Guardian is another user of this
system.
§
Account Executive: account executive is very
important user in University Student Payment system. They have access to fees
collection form and have rights to see previous financial statements.
Here
describe important forms of University
Student Payment System with screen shot.
Login Form: This is a
login form of University Student Payment System. It is design a simple. So it’s
very user friendly. Here only two input items, User Id and Password. User input
their user id and password to login the Student Payment System.
Main
Form: This is the main form of Student Payment System. You say it also menu
form of Student Payment System. Because here you see the tree menu which is
populate base on login user rights.
Institute
Setup Form: This is the institute setup
form. First time when this system run
required an institute name so Institute name setup using this form.
Master
Code Setup Form: Master code is an
internal code to run the Student Payment System. Student Payment System
administrator uses this form to add new functionality or code as per institute
authorities.
Course
Setup form: New course setup or modify
existing course name administrator of University Student Payment uses this
form.
Program Setup Form: New
program setup or modify existing program name administrator of University
Student Payment uses this form.
Fees Setup Form: New
fees setup or modify existing fees administrator of University Student Payment
uses this form.
Chart of Accounts: New
chart of account setup administrator of University Student Payment uses this
form.
Student Setup Form:
It has an option to setup new student or fetch existing student
information from excel sheet.
Program Course Mapping Form:
This is a form to assign course to program and also setup course credit
hours.
Department Setup Form: Administrator of University Student
Payment System setup new department and has an option to update related
information.
Employee Setup Form: Administrator of University Student
Payment System enters new employee information and has an option to update
related information.
User ID Reset Form: Administrator of University Student
Payment System reset user id using this form.
Payment Schedule Generation Form: This is the form to generating payment
schedule of particular student.
Fees Collection Form:
This is the main of Student Payment System. Account executive collected
various fees of student using this form. Collection receipt automatically
populate after transactions. All transaction is store in a secure way.
CHAPTER – 7: CONCLUSION
University
student payment system is flexible and good software. This application help the
student to free from unwanted hassle to given fees and possible to get previous
transaction easily. Employees are providing good service to the student on
demand. Therefore create a better relation with student.
Iterative
methodology uses to develop University Student Payment System. This methodology
ensure bespoke application develop correctly and ensure proper quality. This
project develops on oracle fusion middleware 11g release 2. It is the flagship
platform of Oracle Corporation, USA.
University
student payment system is environment friendly. It is keeping the record
electronically. Therefore it is help us to reduce paper consumption.
7.1 Limitation
Every project has some limitation
University Student Payment System not out of them. This system has some
limitation. Limitations are described here:
- Payment Gateway not integrated - USPS (University Student Payment System) has no integrated payment gateway. There for needs a third-party payment gateway.
- Front End and Back End restriction – Proposed system run only Oracle database and require Oracle fusion middleware forms and reports 11g.2 or later. Oracle fusion middle ware is a java based applications development tools. Required JRE (Java runtime environment) software.
- Mobile device not supported – Proposed system is web based bespoke application software but it is not run on mobile device.
- Web browser software mandatory – Standard web browser require to running this proposed application. It has another name web based bespoke application software.
- Licensing issue – Oracle database and Application server are not free. Required license from Oracle Corporation.
7.2 Future Work
University
Student Payment System is bespoke application software. It is always
incorporated new feature and fixing limitation in future. Here describe most
important future plan to rich the software feature:
- Integrated
Payment Gateway
- Develop own payment gateway and incorporate in University Student
Payment System.
- Mobile
apps –
Develop mobile apps an incorporated in University Student Payment System.
- Use open source technology – Transfer total work in open source technology. It is relieve software licensing issue and ensure more control on the system.
REFERENCES
Bhatt, G., & Emdad, A., (2001) An analysis of
virtual value chain in e-commerce. The Journal Of Logistics and Information
Management, 14(1/2):78-84
Boateng, R. Molla A., Heeks, R and Hinson, R. (2009).Advancing
e-commerce beyond
readiness in a developing economy: experiences of Ghanaian
Firms, journal of electronic commerce in
organizations
Creswell, J, W.,(2003) , Research design
:qualitative , quantitative and mixed methods approach 2ndedition Sage
Publication Inc.
Currie, W., (2000) The Global Information Society,
Chichester. Wiley
Docs.oracle.com(2014)
Oracle® Database Installation Guide 11g
Release 2 [Online] Available from:
[Accessed:
01 March 2014]
Docs.oracle.com(2014)
Oracle® Fusion Middleware System
Requirements and specifications for Oracle Forms and Reports 11g Release 2
(11.1.2) [Online] Available from:
[Accessed:
01 March 2014]
Entity-relationship
model(2014) [Online] Available from:
[Accessed: 15 Marc 2014]
Efendioglu, M. A & Yip, V. F., (2004) Chinese
culture and e-commerce: an exploratory study, interacting with computers
16(1) (2004) 45-62
Fisher, C., (2007) Researching and Writing a
Dissertation: a guide book for business students. Pearson Education
Limited.
GOOGLE.COM
(2014) Integrated electronic presentment
and payment of bills by different entities US 7778901 B2[Online] Available
from:
[Accessed:
20 Feb 2014]
Kenny, C., (2003) The internet and economic growth
in less developed countries: a case of managing expectations? Oxford
Development Studies 31(1) 99-113.
Kirkman, G., et al (2002) The global information
technology report 2001-2002 .Oxford
University Press. New
York
Kshetri, N., (2007) Barriers to e-commerce and
competitive business models in developing countries. Electronic Research
and Applications 6(2007) 443-452
Schneider, G.P. & Perry J.T., (2001) Electronic
Commerce, 2nd Edition, Course Technology –Thomson learning. Canada
Turban, E et al., (2008) Electronic commerce: a
managerial perspective, Pearson Education Inc, New Jersey
Zhang Jian, “Analyzes based on
the SET agreement electronic commerce safety mechanism”, Netinfo Security,
2006(10),pp:9-11.
Comments
Post a Comment