See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/323018933

ONLINE CHURCH INFORMATION SYSTEM

Thesis · February 2018

CITATIONS READS
0 8,611

1 author:

Musah Shaibu
KNDAT Research Consult
2 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

CLOUD-BASED HEALTH RECORD SYSTEM (CBHRS) View project

ONLINE CHURCH INFORMATION SYSTEM FOR SAINT PETERS CATHOLIC CHURCH View project

All content following this page was uploaded by Musah Shaibu on 20 March 2018.

The user has requested enhancement of the downloaded file.

ONLINE CHURCH INFORMATION SYSTEM FOR SAINT PETERS CATHOLIC

CHURCH, FIAPRE

MUSH SHAIBU

OCTOBER 2017
 TABLE OF CONTENT

TABLE OF CONTENT ....................................................................................................... ii

LIST OF TABLES ............................................................................................................... v
LIST OF FIGURES ............................................................................................................. vi
ABSTRACT ....................................................................................................................... vii

CHAPTER ONE................................................................................................................... 1
INTRODUCTION ................................................................................................................ 1
1.1 Background of the Project .............................................................................................. 1
1.2 Existing System .............................................................................................................. 3
1.3 Problem Statement ......................................................................................................... 3
1.4 Proposed System ............................................................................................................ 4
1.5 Objective of proposed system ........................................................................................ 5
1.6 Advantages of the proposed system ............................................................................... 5
1.7 Scope of the proposed system ........................................................................................ 6
1.8 Methods used in the project development ...................................................................... 7
1.9 Tools used....................................................................................................................... 7

CHAPTER TWO .................................................................................................................. 8

LITERATURE REVIEW ..................................................................................................... 8
2.1 Definitions ...................................................................................................................... 8
2.1.1 Church ......................................................................................................................... 8
2.1.2 Records Management .................................................................................................. 8
2.1.3 Church management software ................................................................................... 10
2.1.4 Web development ...................................................................................................... 10
2.1.5 Web development history:......................................................................................... 11
2.1.6 Online Church Information System .......................................................................... 13
2.2 Training, Support.......................................................................................................... 17

ii
2.3 Outcome of the Review ................................................................................................ 18

CHAPTER THREE ............................................................................................................ 19

METHODOLOGY ............................................................................................................. 19
3.0 Introduction .................................................................................................................. 19
3.1 Software prototyping .................................................................................................... 20
3.1.1: Types of Prototyping ................................................................................................ 22
Evolutionary prototyping ................................................................................................... 23
3.1.2 Advantages of prototyping ........................................................................................ 24
3.1.3 Disadvantages of prototyping .................................................................................... 25
3.1.4 Basic principles ......................................................................................................... 27
3.2 Spiral Model ................................................................................................................. 28
3.3 Waterfall model ............................................................................................................ 31
3.3.1: Criticism ................................................................................................................... 34
3.3.2 Supporting arguments................................................................................................ 35

CHAPTER FOUR .............................................................................................................. 37

SYSTEM SPECIFICATION .............................................................................................. 37
4.0 Introduction .................................................................................................................. 37
4.1 Hardware Application .................................................................................................. 37
4.2 Software Specification ................................................................................................. 38
4.3 System Architecture ..................................................................................................... 38
4.4 Software description ..................................................................................................... 39
4.4.1 PHP ............................................................................................................................ 39
4.4.2 JavaScript .................................................................................................................. 41
4.1.3 HTML ........................................................................................................................ 41
4.4.4 MySQL ...................................................................................................................... 43
4.5 Feasibility Study and System Analysis ........................................................................ 44
4.5.1 Feasibility Study ........................................................................................................ 44
4.5.2 System Analysis ........................................................................................................ 48
4.6 System Design .............................................................................................................. 49
4.6.2 Database design ......................................................................................................... 50

iii
4.7 User Interface of Church Information System Screen Design ..................................... 52
4.8 Testing and implementation ......................................................................................... 55
4.8.1 Testing ....................................................................................................................... 55
4.8.2 System implementation ............................................................................................. 58

CHAPTER FIVE ................................................................................................................ 60

CONCLUSIONS AND RECOMMENDATIONS ............................................................. 60
5.1 Summary ...................................................................................................................... 60
5.2 Conclusion .................................................................................................................... 60
5.3 Recommendations ........................................................................................................ 61

REFERENCES ................................................................................................................... 62

iv
 LIST OF TABLES
Table 4.1 information about the administrator who authorized to do the desired task 50

Table 4.2 information about the members of the church. ........................................... 51

Table 4.3 comments and request from members. ....................................................... 51

Table 4.4 information about the members registered to join forum. .......................... 52

v
 LIST OF FIGURES
Fig. 3.1 Three software development patterns mashed together………………. ….20

Figure 3.2: Software Prototyping Process from Summerville, Software Engineering, 7th
Edition ......................................................................................................................... 21

Figure. 3.3 Spiral Model Process from Summerville, Software Engineering, 7th Edition
..................................................................................................................................... 29

Figure. 3.4 Waterfall Model Process From Somerville, Software Engineering, 7th
Edition ......................................................................................................................... 33

Figure. 4.1 Functional Decomposition Diagram…………………………………….46

Figure 4.2 Login Panel ................................................................................................ 53

Figure 4.3 Admin Dashboard ...................................................................................... 53

Figure 4.4 Members Dashboard .................................................................................. 54

Figure 4.5 Sunday School ........................................................................................... 54

vi
 ABSTRACT
As one of the organizations engaged in community service, the church has a wide range of

activities and transactions to accommodate the needs of the congregation, both in terms of

ecclesiastical activities and financial transactions of the church. The church would also have

a considerable amount of data in a large and fairly high complexity. Under these conditions,

the church should have integrated and centralized data storage to facilitate the storage,

management, and presentation of data. The proposed system is to overcome the drawbacks

of the existing system and to help create a comprehensive database that provides the

information on the availability details and the issue details along with the member details.

Developed and implement information retrieval system for the members and the

management of the church ant to automate the entire range of activities or processes that

needs to be performed by the management before a request. The techniques for data

gathering were: Interview, observations and document analysis. The system design

technique used is the prototyping design. The new system was developed using PHP and

JavaScript as the front end and MySQL as the backend of the project. The system was tested

after development and it was able to record all member’s information accurately, retrieve

records easily using a robust search interface. The system was also able to generate varied

reports with few clicks of buttons.

vii
 CHAPTER ONE

INTRODUCTION

1.1 Background of the Project

Church information system is the system for Saint Peters Catholic Church Fiapre. The

Authorities of the church use the system for the better performance of their church service.

This system provide the online facilities for the members of the church and also for the

Administrator.

As one of the organizations engaged in community service, the church has a wide range of

activities and transactions to accommodate the needs of the congregation, both in terms of

ecclesiastical activities and financial transactions of the church. The church would also have

a considerable amount of data in a large and fairly high complexity. Under these conditions,

the church should have integrated and centralized data storage to facilitate the storage,

management, and presentation of data. [1] described the information system is formed by

the information itself.

It means that the diversity and multiplicity of occurrence of information contributed to the

need for them together to categorize, which automatically led to a certain, separate group of

information which are formed into information systems. And the development of

information system can be drawn as a part of implementation of information with

technology through analysis, design, implementation and support. The system can be

defined as a set of interrelated components that work together to achieve the desired results.

Information technology is a combination between computer technology (hardware &

software) with telecommunications technology (network data, images, sounds).

1
Thus, the definition of Whitten & Bentley [2] concluded that the information system is an

arrangement of people, data, processes, and information technology that interact to collect,

process, store, and provide the information needed to support the organization. An

information system according to [3] is an organized combination consisting of people,

hardware, software, network communications, data sources, rules and procedures that store,

acquire, transform, and distribute information in a organization. But the current problems

are recording and storage of data on the Saint Peters Catholic Church Fiapre, still manually

by utilizing the resources of different applications such as paper or a program such as Word

and Excel.

This weakness resulted in data storage separated and not centered and complicate the

administration of the church employees in acquiring and managing information that requires

a long time to present a specific report. This weakness also increases the risk of data loss,

either intentionally or unintentionally. With the implementation of data storage in DBMS

(Database management systems) is expected to help the church to eliminate data redundancy

and produce consistent data, and generated a centralized data repository and can be equipped

with integrated security and data access. In addition, the development information system

at Saint Peters Catholic Church Fiapre used the web-based application as a media renderer

that specifically facilitate the congregation in worship accessing information, news weekly,

or ecclesiastical activities and generally facilitate the congregation in accessing general

information related Saint Peters Catholic Church Fiapre. The purpose of this study is to

analyze and understand the business processes that are taking place in the church to find

weaknesses that would be the definition of the church needs, and designing information

systems that support the activities in the church.

2
1.2 Existing System

The management of the church is currently following a manual procedure. The user has to

check the availability of the required item by querying to the management. The management

has to check the availability from the register manually. After getting the availability status

the user has to fill up the membership and other forms manually. The management then

checks the validity of the forms and after checking it books the item against the respective

request. The information about the item is kept in a temporary register. When the user

submits the entire necessary document, the management enters the details of the request in

the main register of item details.

Currently each member has a file on which vital data or information about a member or

management is kept in. Apart from this the member information or data is also written on

papers and in booklets which are then stored in shelves. Other documents such as transfer

sheet, report forms and registration forms are also kept in files and stored in shelves.

Therefore, the institution has several problems with their record keeping. Since their records

can be destroyed at any time by natural environmental hazards or conditions which comes

from nowhere. It then causes the church to lose a large amount of resources and required

more management staffs.

1.3 Problem Statement

The problem definition for the system is to launch online system for Saint Peters Catholic

Church Fiapre. The whole church process is carried out in a manual order. Since it’s a

manual system it has the drawbacks such as time consumption, inefficient resource

utilization. Some of the drawbacks of the current system are:

3
 1. The members have to collect the membership and other forms by hand from the

church premises. This consumes a valuable amount of time of the management.

2. An unmanageable tangle of papers within the office.

3. Wasted clerical effort searching for information.

4. Loss of important operating information.

5. Extravagant use of high cost office space and equipment.

6. Loss of valuable historical records through destruction or neglect.

7. Difficulties in finding members and management information when needed.

8. A lot of time is spent in the generation of reports since they are using the old system.

9. A lot of time is spent in collecting data about members and management.

1.4 Proposed System

From earlier system, the members have to keep in touch with the management about the

availability of the items. The proposed system is online system. The user can login from any

place and also at any time. The main base of the proposed system is the database, which

keeps all the information about the availability status of the church. Based on this

information the user can easily get the availability status at any time without coming to the

church premises. Along with the availability status the database also keeps the information

of the Issue details and the transaction details against the respective request. This database

also keeps the information of user’s personal details, based on which the management can

check the validity of the user and its request. Based on all the above information the

management can efficiently respond all the user queries.

The main activities will be performed by the system are.

1. Online submission of the membership form by the members.

4
 2. Automation of the procedure performed by the management.

3. Report generation.

1.5 Objective of proposed system

The main objective of the proposed system is to overcome the drawbacks of the existing

system. The prime benefits and the specific objectives of the project are to:

1. create a comprehensive database that provides the information on the availability

details and the issue details along with the member details.

2. develop and implement information retrieval system for the members and the

management of the church.

3. automate the entire range of activities or processes that need to be performed by the

management before a request.

4. put the information on Internet for easy access not only for the managements but

also for the members from various places.

1.6 Advantages of the proposed system

The proposed system is a computerized system. This system has lots of advantages over the

existing system. Some of them are:

1. The user can log onto the church website from anywhere to check the availability

status, family members and issues related to the church. This saves a valuable

amount of member’s time.

2. All the data relevant to member information are stored in the database. So, the

management can get rid of the tedious job like manually searching for an available

and issue date.

5
 3. The database contains the cost information of the various items offered by the

church. So, the management can get help from the proposed system as most of the

cost calculations are done in a computerized manner and the results are again in the

database at it helps in the generation of bills.

1.7 Scope of the proposed system

The “Church Information system” software is being developed as accurate and efficient

online software for the user such as the members and also the administrator i.e. the

management of the church. In this system, the record of each request details is preserved

along with their status and transaction related to them. The system is also made secured as

all the updates of the system can be done by the authorized person i.e. the administrator

only.

The automation of an organization system such as educational system is of no news in this

technological era. It makes sure that there is easy access: large amount of data can be stored

and accurate information and data is available to the institutions. The introduction of the

automation enrollment management system also enhances diversity and a server client

relation in the institution or organizations.

In terms of information technology, where there are problems, I.T is there to solve these

problems. Therefore, automation management system will solve all problems pertinent to

solving, retrieving and generation of report for the institution. It will also help in keeping of

record accurately.

6
1.8 Methods used in the project development

Developing top of the grid efficient standard application requires proper implementation

and proper implementation begins with a good design. Ultimately, a good design also starts

with a thorough analysis. The process of analysis and design is quite complex. Many

methodologists have developed methods of the design process. A software development

methodology refers to the framework that is used to structure, plan, and control the process

of developing an information system. A wide variety of such frameworks have evolved over

the years, each with its own recognized strengths and weaknesses. One system development

methodology is not necessarily suitable for use by all projects. Each of the available

methodologies is best suited to specific kinds of projects, based on various technical,

organizational, project and team considerations. In the development of this Project, the

waterfall model was used.

1.9 Tools used

The application tools used are:

1. HTML

2. PHP

3. MYSQL Server

7
 CHAPTER TWO

LITERATURE REVIEW

2.1 Definitions

2.1.1 Church

From The Catholic Encyclopedia, The term church (Anglo-Saxon, cirice, circe; Modern

German, Kirche; Swedish, Kyrka) is the name employed in the Teutonic languages to render

the Greek ekklesia (ecclesia), the term by which the New Testament writers denote the

society founded by Our Lord Jesus Christ. The derivation of the word has been much

debated. It is now agreed that it is derived from the Greek kyriakon (cyriacon), i.e. the Lord's

house, a term which from the third century was used, as well as ekklesia, to signify a

Christian place of worship.

Also, church is defined (Wikipedia) as a Christian religious organization made up of a

congregation, its members and clergy. They are organized more or less formally, with

constitutions and by-laws, maintain offices, sometimes seek non-profit corporate status in

the United States and often have state or regional structures. Church bodies often belong to

a broader tradition within the Christian religion, sharing in a broad sense a history, culture

and doctrinal heritage with other church bodies of the same tradition.

2.1.2 Records Management

Usually about the only time records management is discussed in a church staff meeting is

when some crisis has occurred. Either files cannot be found, records are lost or have been

destroyed, or all of the filing cabinets are full and no more storage space is available.

Unfortunately, churches seldom initiate actions to manage their records in a more effective

and efficient manner [4].

8
Records management is defined (by Bill Sumners in Southern Baptist Historical Library

and Archive) as "the application of management techniques to the creation, utilization,

maintenance, retention, preservation, and disposal of records undertaken to reduce costs and

improve efficiency of recordkeeping." The entire program of the church can benefit by

improving its control of the records it maintains and creates.

Records management (RM) is defined as the practice of identifying, classifying, archiving,

and methodical destruction of records. Simply, records management includes all the

processes involved in making records findable, usable, and savable or destroyable (Missouri

Baptist Historical Commission).

Also, records management is defined in the United Methodist Church GCAH as “the attempt

to systematically control the growth and disposition, or destruction, of office, committee

and other official records.” Its basic purpose is to help answer that nagging question of what

do I keep, for how long do I keep it and when can I remove it from my office.

The world we live in revolves around information recorded on paper, film, tape, and disk—

this includes the life of the local church. Correspondence, invoices, contracts, minutes,

reports, financial records, and hundreds of other records provide the information that moves

the wheels of our institutions.

Today the volume of paper records—a fair share of it generated by computers, fast printers,

copying machines, and other advanced methods of duplication—shows no sign of

decreasing. Just to keep pace with the information explosion, an average company or

institution today may double its entire volume of records every 10 years. This same

9
statement applies to churches. With growth such as this, it is essential that church records

be handled efficiently (Bill Sumners in Southern Baptist Historical Library and Archive).

2.1.3 Church management software

Church management software is a specialized software that assists churches and other

religious organizations in organization and automation of daily operations. These packages

typically assist in the management of membership and mailings, fundraising, events, and

report generation. Churches use the packages to reduce the cost of operations and track the

growth in their congregations. The growth in the church management software business

coincides with the growing trend of using computers for religious activity [20].

2.1.4 Web development

Web development is a broad term for the work involved in developing a web site for the

Internet (World Wide Web) or an intranet (a private network). This can include web design,

web content development, client liaison, client-side/server-side scripting, web server and

network security configuration, and e-commerce development. However, among web

professionals, "web development" usually refers to the main non-design aspects of building

web sites: writing markup and coding. Web development can range from developing the

simplest static single page of plain text to the most complex web-based internet applications,

electronic businesses, or social network services.

For larger businesses and organizations, web development teams can consist of hundreds of

people (web developers). Smaller organizations may only require a single permanent or

contracting webmaster, or secondary assignment to related job positions such as a graphic

10
designer and/or Information systems technician. Web development may be a collaborative

effort between departments rather than the domain of a designated department.

2.1.5 Web development history

Since the mid-1990s, web development has been one of the fastest growing industries in the

world. In 1995 there were fewer than 1,000 web development companies in the United

States, but by 2005 there were over 30,000 such companies in the U.S. alone. The web

development industry is expected to grow over 25% by 2010. The growth of this industry

is being pushed by large businesses wishing to sell products and services to their customers

and to automate business workflow.

In addition, cost of Web site development and hosting has dropped dramatically during this

time. Instead of costing tens of thousands of dollars, as was the case for early websites, one

can now develop a simple web site for less than a thousand dollars, depending on the

complexity and amount of content. Smaller Web site development companies are now able

to make web design accessible to both smaller companies and individuals further fueling

the growth of the web development industry. As far as web development tools and platforms

are concerned, there are many systems available to the public free of charge to aid in

development. A popular example is the LAMP (Linux, Apache, MySQL, PHP), which is

usually distributed free of charge. This fact alone has manifested into many people around

the globe setting up new Web sites daily and thus contributing to increase in web

development popularity. Another contributing factor has been the rise of easy to use

WYSIWYG web development software, most prominently WebDev, Adobe Dreamweaver,

Netbeans or Microsoft Expression Studio. Using such software, virtually anyone can

11
develop a Web page in a matter of minutes. Knowledge of HyperText Markup Language

(HTML), or other programming languages is not required, but recommended for

professional results.

The next generation of web development tools uses the strong growth in LAMP, Java

Platform, Enterprise Edition technologies and Microsoft .NET technologies to provide the

Web as a way to run applications online. Web developers now help to deliver applications

as Web services which were traditionally only available as applications on a desk based

computer.

Instead of running executable code on a local computer, users are interacting with online

applications to create new content. This has created new methods in communication and

allowed for many opportunities to decentralize information and media distribution. Users

are now able to interact with applications from many locations, instead of being tied to a

specific workstation for their application environment.

Examples of dramatic transformation in communication and commerce led by web

development include e-commerce. Online auction sites such as eBay have changed the way

consumers consume and purchase goods and services. Online resellers such as Amazon.com

and Buy.com (among many, many others) have transformed the shopping and bargain

hunting experience for many consumers. Another good example of transformative

communication led by web development is the blog. Web applications such as Movable

Type and WordPress have created easily implemented blog environments for individual

Web sites. Open source content systems such as Alfresco, Typo3, Xoops, Joomla!, and

Drupal have extended web development into new modes of interaction and communication.

12
In addition, web development has moved to a new phase of Internet communication.

Computer web sites are no longer simply tools for work or commerce but used most for

communication. Websites such as Facebook and Twitter provide users a platform to freely

communicate. This new form of web communication is also changing e-commerce through

the number of hits and online advertisement.

2.1.6 Online Church Information System

Before the implementation of the system, the literature reviews have been done on topics

that are related to the Online Church Information System (OCIS). Most of the studied

information obtained from electronic and non-electronic data media. The review of previous

research studies and works gives more understanding and knowledge to develop this project.

The primary research was the implementation of online Church Record Management.

Previous studies reviewed included those for Presbyterian Church of Aotearoa, New

Zealand, The United Methodist Church, NJ, USA, Greenock Presbytarian Church, St.

Andrew’s, New Brunsnick, Canada and Churchwide Office Evangelical Lutheran Church

in America [6]. The reoccurring factors for using an online system were response rates,

quality, anonymity, and flexibility. These were important considerations for the

development of OCIS, especially with the intent of integrating the system into multiple

members.

Flexibility

For many churches, the days when the church secretary or pastor was able to keep track of

members and their vital statistics with a pencil and paper are long gone. And, with advances

13
in computers and software, it’s not likely anyone is missing those days too terribly ( Marc

S. Botts, 2003).

Church Information System (CIS) allows a congregation to keep tabs on information related

to activities of the church. It uses a database to store information and typically includes a

set of programs or modules to manipulate the stored data.

One of the main benefits, said Free Grafton, a customer service representative for Colorado

Springs, Colo-based Church Community Builder, is the systems allow the pastors to spend

time ministering rather than managing information.

"I think that is the goal of a Church Information System is to try and help you think through

and automate as many processes as you can," Grafton said.

Ease of use

CIS solutions, with graphical user interfaces, offer ease of use that other solutions, such as

internally developed spreadsheets, do not. They also provide a degree of stability because

they do not require a high level of technical expertise.

We see that all the time where a church was dependent on a computer guru or technical

expert," said Paul Schuster, president of Union, Ky.-based Helpmate. "It may have been a

volunteer or somebody on staff but they left and now they are in complete disarray. When

you depend internally on a product or some way of managing that system and that person is

no longer available to the organization that can be a real detriment. "

14
Several factors can play into the ease of use of the OCIS application, including the ability

to reuse information, the ability to add instructor-supplied news, and the ability to return

and make changes, to name a few. Paper-based CIS require more communication among

involved parties to add and reuse information’s, whereas online CIS provide an easy

interface for instructors to directly add the information or reuse others that exist in the

database. In creating that interface, [7] suggests keeping most Web pages limited to one

page in length, as many visitors will not scroll below the fold to see the additional

information. Additionally, if changes are necessary, the ability to change information’s on

the paper-based form again requires more communication among several people, as

compared to online CIS that save the settings for each instructor and are updateable until

they are sent out to be completed.

Quickness of Use

[7] states that Web sites that feel effortless are more usable than those that do not. Providing

a straightforward interface allows users to quickly find what they are looking for and

accomplish the task at hand. [8] contribute to this, stating that improved productivity

through speed and efficiency provides a more user-centered Web site. In moving towards a

more user-centered approach, comparing paper-based to online-based CIS, paper-based

results take days to process and return to the instructors, whereas, online CIS provide the

results in real-time. This puts the user at the center of the design, providing quick access to

necessary information.

Response Rate

In most cases, the response rate of members completed online request dropped when

compared to the existing traditional paper-based version. In the study conducted at The

15
United Methodist Church, NJ, USA, the response rate was 32.8% for online request and

60.6% for in-Church. It should be noted that this decrease in the response was not

necessarily attributed to the instrument used to complete the request; rather, online request

was usually completed outside of church whereas paper-based were completed in-church

[5]. The average response rate for in-church paper-based request ranged from 61–82

percent; for that reason, the desired response rate for online request was to be within this

range [6]. One approach to increase the response rate was to send reminder emails to non-

responders. At Greenock Presbyterian Church, St. Andrew’s, New Brunsnick, Canada,

three email reminders were sent and an increase in the response rate from 60 to 87 percent

was observed [9]. At Presbyterian Church of Aotearoa, New Zealand, the online system

was in place for three years and overall response rates increased reaching an average of 68.1

percent for all request [6].

Quality

Based on the literature reviewed, the quality of the responses between online and paper

request did not have a significant difference [10]. Other research noted that the quantity in

comments for open ended questions were greater for online systems versus paper versions.

A study calculated a ratio of 186 words per members using online versions compared to 25

words per members for paper versions [10].

Anonymity

A common concern expressed among members who used CIS was whether they remained

anonymous when completing request. To address this issue, OCIS needed a privacy

statement detailing anonymity and security concerns expressed. In some cases, paper-based

request compromised anonymity if hand written responses were not transcribed. Having the

16
comments typed initially using the online system prevented this issue and eliminated the

need to transcribe the responses.

Schuster said “Password protected areas make it easier to change information securely,

although privacy is a concern for many people.”

"The most common concern we hear, mostly from older people because they don't fully

understand the Internet, is that they are concerned about their name being 'out there,'" said

Church Community Builder's Grafton. "They don't know where out there is, but they know

their name is on someone's computer and that is not at the church."

To allay those concerns, his company uses secure servers and databases that are only

accessible by the server. As an added protection, passwords require at least one numeric

character and the system locks out a user after five failed logon attempts.

2.2 Training, Support

The Indianapolis Center for Congregations, an organization that helps congregations of

various sizes and denominational affiliation with computer and ministry issues, cautions

that not getting proper training is the most frequent mistake new CIS users make. Because

churches don’t take full advantage of training options, many of a package’s most helpful

features may go unused.

The center recommends churches include plans and a generous budget for training, which

providers may offer onsite, regionally, by telephone or over the Internet. Many providers

have online user groups that can be helpful for both new and experienced users. Support is

17
also a key consideration. The center recommends that congregations purchase and maintain

the support offered by a vendor. Dunlap agrees that support is something churches should

be able to rely on.

"It gets kind of frustrating when you are trying to load something up and you can’t

call somebody and say, ‘Hey, this error message came up,’" he said.

Some companies, such as People Driven Software, provide free upgrades as an incentive to

purchase annual support packages.

2.3 Outcome of the Review

Based on the reviewed, most of the studied information obtained from electronic and non-

electronic data media of the Church Information System were windows application. The

reoccurring factors for using an online system were response rates, quality, anonymity, and

flexibility. These were important considerations for the development of OCIS, especially

with the intent of integrating the system into multiple members.

18
 CHAPTER THREE

METHODOLOGY

3.0 Introduction

A software development methodology refers to the framework that is used to structure, plan,

and control the process of developing an information system. A wide variety of such

frameworks have evolved over the years, each with its own recognized strengths and

weaknesses. One system development methodology is not necessarily suitable for use by all

projects. Each of the available methodologies is best suited to specific kinds of projects,

based on various technical, organizational, project and team considerations. The framework

of a software development methodology consists of:

1. A software development philosophy, with the approach or approaches of the

software development process

2. Multiple tools, models and methods, to assist in the software development process.

These frameworks are often bound to some kind of organization, which further develops,

supports the use, and promotes the methodology.

Every software development methodology has more or less its own approach to software

development. There is a set of more general approaches, which are developed into several

specific methodologies. These approaches are.

1. Prototyping: iterative framework type

2. Spiral: combination of linear and iterative framework type

3. Waterfall: linear framework type

19
Fig. 3.1 Three software development patterns mashed together

3.1 Software prototyping

Software prototyping, is the framework of activities during software development of

creating prototypes, i.e., incomplete versions of the software program being developed.

A prototype typically simulates only a few aspects of the features of the eventual program,

and may be completely different from the eventual implementation.

The conventional purpose of a prototype is to allow users of the software to evaluate

developers' proposals for the design of the eventual product by actually trying them out,

rather than having to interpret and evaluate the design based on descriptions. Prototyping

can also be used by end users to describe and prove requirements that developers have not

considered, so "controlling the prototype" can be a key factor in the commercial relationship

between solution providers and their clients

20
The process of prototyping involves the following steps

1. Identify basic requirements: Determine basic requirements including the input and

output information desired. Details, such as security, can typically be ignored.

2. Develop Initial Prototype: The initial prototype is developed that includes only user

interfaces.

3. Review: The customers, including end-users, examine the prototype and provide

feedback on additions or changes.

4. Revise and Enhance the Prototype: Using the feedback both the specifications and

the prototype can be improved. Negotiation about what is within the scope of the

contract/product may be necessary. If changes are introduced then a repeat of steps

#3 and #4 may be needed.

Figure 3.2: Software Prototyping Process from Summerville, Software Engineering,

7th Edition

21
3.1.1: Types of Prototyping

Software prototyping has many variants. However, all the methods are in some way based

on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping

Throwaway prototyping

Also, called close ended prototyping. Throwaway or Rapid Prototyping refers to the creation

of a model that will eventually be discarded rather than becoming part of the final delivered

software. After preliminary requirements gathering is accomplished, a simple working

model of the system is constructed to visually show the users what their requirements may

look like when they are implemented into a finished system. In this approach the prototype

is constructed with the idea that it will be discarded and the final system will be built from

scratch. The steps in this approach are:

1. Write preliminary requirements

2. Design the prototype

3. User experiences/uses the prototype, specifies new requirements

4. Repeat if necessary

5. Write the final requirements

6. Develop the real products

The most obvious reason for using Throwaway Prototyping is that it can be done quickly.

If the users can get quick feedback on their requirements, they may be able to refine them

early in the development of the software. Making changes early in the development lifecycle

is extremely cost effective since there is nothing at that point to redo. If a project is changed

22
after a considerable work has been done then small changes could require large efforts to

implement since software systems have many dependencies. Speed is crucial in

implementing a throwaway prototype, since with a limited budget of time and money little

can be expended on a prototype that will be discarded. Another strength of Throwaway

Prototyping is its ability to construct interfaces that the users can test. The user interface is

what the user sees as the system, and by seeing it in front of them, it is much easier to grasp

how the system will work.

Prototypes can be classified according to the fidelity with which they resemble the actual

product in terms of appearance, interaction and timing. One method of creating a low

fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using

paper and pencil, and thus mimics the function of the actual product, but does not look at

all like it.

Evolutionary prototyping

Evolutionary Prototyping (also known as breadboard prototyping) is quite different from

Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a

very robust prototype in a structured manner and constantly refine it. "The reason for this is

that the Evolutionary prototype, when built, forms the heart of the new system, and the

improvements and further requirements will be built. When developing a system using

Evolutionary Prototyping, the system is continually refined and rebuilt.

This technique allows the development team to add features, or make changes that couldn't

be conceived during the requirements and design phase.

23
Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are

functional systems. Although they may not have all the features the users have planned, they

may be used on an interim basis until the final system is delivered. In Evolutionary

Prototyping, developers can focus themselves to develop parts of the system that they

understand instead of working on developing a whole system.

3.1.2 Advantages of prototyping

There are many advantages to using prototyping in software development – some tangible,

some abstract.

1. Reduced time and costs: Prototyping can improve the quality of requirements and

specifications provided to developers. Because changes cost exponentially more to

implement as they are detected later in development, the early determination of what

the user really wants can result in faster and less expensive software.

2. Improved and increased user involvement: Prototyping requires user involvement

and allows them to see and interact with a prototype allowing them to provide better

and more complete feedback and specifications. The presence of the prototype being

examined by the user prevents many misunderstandings and miscommunications

that occur when each side believe the other understands what they said. Since users

know the problem domain better than anyone on the development team does,

increased interaction can result in final product that has greater tangible and

intangible quality. The final product is more likely to satisfy the users desire for

look, feel and performance.

24
3.1.3 Disadvantages of prototyping

Using, or perhaps misusing, prototyping can also have disadvantages.

1. Insufficient analysis: The focus on a limited prototype can distract developers from

properly analyzing the complete project. This can lead to overlooking better

solutions, preparation of incomplete specifications or the conversion of limited

prototypes into poorly engineered final projects that are hard to maintain. Further,

since a prototype is limited in functionality it may not scale well if the prototype is

used as the basis of a final deliverable, which may not be noticed if developers are

too focused on building a prototype as a model.

2. User confusion of prototype and finished system: Users can begin to think that a

prototype, intended to be thrown away, is actually a final system that merely needs

to be finished or polished. (They are, for example, often unaware of the effort needed

to add error-checking and security features which a prototype may not have.) This

can lead them to expect the prototype to accurately model the performance of the

final system when this is not the intent of the developers. Users can also become

attached to features that were included in a prototype for consideration and then

removed from the specification for a final system. If users are able to require all

proposed features be included in the final system this can lead to conflict.

3. Developer misunderstanding of user objectives: Developers may assume that

users share their objectives (e.g. to deliver core functionality on time and within

budget), without understanding wider commercial issues. For example, user

representatives attending Enterprise software (e.g. PeopleSoft) events may have

25
 seen demonstrations of "transaction auditing" (where changes are logged and

displayed in a difference grid view) without being told that this feature demands

additional coding and often requires more hardware to handle extra database

accesses. Users might believe they can demand auditing on every field, whereas

developers might think this is feature creep because they have made assumptions

about the extent of user requirements. If the solution provider has committed

delivery before the user requirements were reviewed, developers are between a rock

and a hard place, particularly if user management derives some advantage from their

failure to implement requirements.

4. Developer attachment to prototype: Developers can also become attached to

prototypes they have spent a great deal of effort producing; this can lead to problems

like attempting to convert a limited prototype into a final system when it does not

have an appropriate underlying architecture. (This may suggest that throwaway

prototyping, rather than evolutionary prototyping, should be used.)

5. Excessive development time of the prototype: A key property to prototyping is the

fact that it is supposed to be done quickly. If the developers lose sight of this fact,

they very well may try to develop a prototype that is too complex. When the

prototype is thrown away the precisely developed requirements that it provides may

not yield a sufficient increase in productivity to make up for the time spent

developing the prototype. Users can become stuck in debates over details of the

prototype, holding up the development team and delaying the final product.

6. Expense of implementing prototyping: the start up costs for building a

development team focused on prototyping may be high. Many companies have

26
 development methodologies in place, and changing them can mean retraining,

retooling, or both. Many companies tend to just jump into the prototyping without

bothering to retrain their workers as much as they should.

3.1.4 Basic principles

Basic principles of prototyping are:

1. Not a standalone, complete development methodology, but rather an approach to

handling selected portions of a larger, more traditional development methodology

(i.e. Incremental, Spiral, or Rapid Application Development (RAD)).

2. Attempts to reduce inherent project risk by breaking a project into smaller segments

and providing more ease-of-change during the development process.

3. User is involved throughout the process, which increases the likelihood of user

acceptance of the final implementation.

4. Small-scale mock-ups of the system are developed following an iterative

modification process until the prototype evolves to meet the users’ requirements.

5. While most prototypes are developed with the expectation that they will be

discarded, it is possible in some cases to evolve from prototype to working system.

6. A basic understanding of the fundamental business problem is necessary to avoid

solving the wrong problem.

7. Mainframes have a lot to do with this sort of thing that consist of: PB&J

27
3.2 Spiral Model

The spiral model is a software development process combining elements of both design

and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up

concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems

development method (SDM) used in information technology (IT). This model of

development combines the features of the prototyping model and the waterfall model. The

spiral model is intended for large, expensive and complicated projects.

Steps

The steps in the spiral model iteration can be generalized as follows:

1. The system requirements are defined in as much detail as possible. This usually

involves interviewing a number of users representing all the external or internal

users and other aspects of the existing system.

2. A preliminary design is created for the new system. This phase is the most important

part of "Spiral Model". In this phase, all possible (and available) alternatives, which

can help in developing a cost-effective project are analyzed and strategies to use

them are decided. This phase has been added specially in order to identify and

resolve all the possible risks in the project development. If risks indicate any kind of

uncertainty in requirements, prototyping may be used to proceed with the available

data and find out possible solution in order to deal with the potential changes in the

requirements.

28
 3. A first prototype of the new system is constructed from the preliminary design. This

is usually a scaled-down system, and represents an approximation of the

characteristics of the final product.

4. A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weaknesses, and risks;

2. Defining the requirements of the second prototype;

3. Planning and designing the second prototype;

4. Constructing and testing the second prototype.

Figure. 3.3 Spiral Model Process from Summerville, Software Engineering, 7th Edition

Basic principles of Spiral model are:

29
 1. Focus is on risk assessment and on minimizing project risk by breaking a project

into smaller segments and providing more ease-of-change during the development

process, as well as providing the opportunity to evaluate risks and weigh

consideration of project continuation throughout the life cycle.

2. "Each cycle involves a progression through the same sequence of steps, for each

portion of the product and for each of its levels of elaboration, from an overall

concept-of-operation document down to the coding of each individual program."

3. Each trip around the spiral traverses four basic quadarants: (1) determine objectives,

alternatives, and constraints of the iteration; (2) Evaluate alternatives; Identify and

resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the

next iteration.

4. Begin each cycle with an identification of stakeholders and their win conditions, and

end each cycle with review and commitment.

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to

support software reuse, software quality can help as a special goal of integration into the

product development. However, the spiral model has some restrictive conditions, as follows:

1) spiral model emphasizes risk analysis, but require customers to accept and

believe that much of this analysis, and make the relevant response is not easy,

therefore, this model is often adapted to large-scale internal software

development.

30
 2) If the implementation of risk analysis will greatly affect the profits of the project,

then risk analysis is meaningless, therefore, spiral model is only suitable for

large-scale software projects.

3) Good software developers should look for possible risks, an accurate analysis of

risk, otherwise it will lead to greater risk.

First stage is to determine the stage of the goal of accomplishing these objectives, options

and constraints, and then from the perspective of risk analysis program, development

strategy, and strive to remove all potential risks, and sometimes necessary to achieve

through the construction of the prototype. If some risk can not be ruled out, the program to

end immediately, or else start the development of the next steps. Finally, evaluation results

of the stage, and the design of the next phase.

3.3 Waterfall model

The waterfall model is a sequential development process, in which development is seen as

flowing steadily downwards (like a waterfall) through the phases of requirements analysis,

design, implementation, testing (validation), integration, and maintenance. The first formal

description of the waterfall model is often cited to be an article published by Winston W.

Royce in 1970 although Royce did not use the term "waterfall" in this article.

The principal stages of the model map onto fundamental development activities:

1. Requirements analysis and definition: The system's services, constraints and

goals are, established by consultation with system users. They are then defined in

detail and serve as a system specification.

31
2. System and software design: The systems design process partitions the

requirements to either hardware or software systems. It establishes an overall

system architecture. Software design involves identifying and describing the

fundamental software system abstractions and their relationships.

3. Implementation and unit testing: During this stage, the software design is realised

as a set of programs or program units. Unit testing involves verifying that each unit

meets its specification.

4. Integration and system testing: The individual program units or programs are

integrated and tested as a complete system to ensure that the software requirements

have been met. After testing, the software system is delivered to the customer.

5. Operation and maintenance: Normally (although not necessarily) this is the

longest life-cycle phase. The system is installed and put into practical use.

Maintenance: involves correcting errors which were not discovered in earlier stages

of the life cycle, improving the implementation of system units and enhancing the

system’s services as new requirements are discovered.

32
Figure. 3.4 Waterfall Model Process From Somerville, Software Engineering, 7th
Edition

To follow the waterfall model, one proceeds from one phase to the next in a sequential

manner. For example, one first completes requirements specification, which after sign-off

are considered "set in stone." When the requirements are fully completed, one proceeds to

design. The software in question is designed and a blueprint is drawn for implementers

(coders) to follow — this design should be a plan for implementing the requirements given.

When the design is fully completed, an implementation of that design is made by coders.

Towards the later stages of this implementation phase, separate software components

produced are combined to introduce new functionality and reduced risk through the removal

of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding

phase is completed and perfected. However, there are various modified waterfall models

33
(including Royce's final model) that may include slight or major variations upon this

process.

3.3.1: Criticism

The waterfall model is argued by many to be a bad idea in practice. This is mainly because

of their belief that it is impossible for any non-trivial project to get one phase of a software

product's lifecycle perfected, before moving on to the next phases and learning from them.

Designers may not be aware of future implementation difficulties when writing a design for

an unimplemented software product. That is, it may become clear in the implementation

phase that a particular area of program functionality is extraordinarily difficult to

implement. If this is the case, it is better to revise the design than to persist in using a design

that was made based on faulty predictions and that does not account for the newly

discovered problem areas.

Even without such changing of the specification during implementation, there is the option

either to start a new project from scratch, "on a green field", or to continue some already

existing, "a brown field" (from construction again). The waterfall methodology can be used

for continuous enhancement, even for existing software, originally from another team. As

well as in the case when the system analyst fails to capture the customer requirements

correctly, the resulting impacts on the following phases (mainly the coding) still can be

tamed by this methodology, in practice.

The idea behind the waterfall model may be "measure twice; cut once", and those opposed

to the waterfall model argue that this idea tends to fall apart when the problem being

34
measured is constantly changing due to requirement modifications and new realizations

about the problem itself. A potential solution is for an experienced developer to spend time

up front on refactoring to prepare the software for the update. Another approach is to use a

design targeting modularity with interfaces, to increase the flexibility of the software with

respect to the design.

3.3.2 Supporting arguments

Time spent early in the software production cycle can lead to greater economy at later

stages. It has been shown that a bug found in the early stages (such as requirements

specification or design) is cheaper in terms of money, effort and time, to fix than the same

bug found later on in the process. To take an extreme example, if a program design turns

out to be impossible to implement, it is easier to fix the design at the design stage than to

realize months later, when program components are being integrated, that all the work done

so far has to be scrapped because of a broken design.

This is the central idea behind the waterfall model - time spent early on making sure that

requirements and design are absolutely correct will save you much time and effort later.

Thus, the thinking of those who follow the waterfall process goes, one should make sure

that each phase is 100% complete and absolutely correct before proceeding to the next phase

of program creation. Program requirements should be set in stone before design is started

(otherwise work put into a design based on incorrect requirements is wasted); the program's

design should be perfect before people begin work on implementing the design (otherwise

they are implementing the wrong design and their work is wasted), etc.

35
A further argument for the waterfall model is that it places emphasis on documentation (such

as requirements documents and design documents) as well as source code. In less designed

and documented methodologies, should team members leave, much knowledge is lost and

may be difficult for a project to recover from. Should a fully working design document be

present (as is the intent of the waterfall model) new team members or even entirely new

teams should be able to familiarize themselves by reading the documents.

As well as the above, some prefer the waterfall model for its simple approach and argue that

it is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall

model provides a structured approach; the model itself progresses linearly through discrete,

easily understandable and explainable phases and thus is easy to understand; it also provides

easily markable milestones in the development process. It is perhaps for this reason that is

why the waterfall model is used.

It is argued that the waterfall model in general can be suited to software projects which are

stable (especially those projects with unchanging requirements, such as with shrink wrap

software) and where it is possible and likely that designers will be able to fully predict

problem areas of the system and produce a correct design before implementation is started.

The waterfall model also requires that implementers follow the well-made, complete design

accurately, ensuring that the integration of the system proceeds smoothly.

36
 CHAPTER FOUR

SYSTEM SPECIFICATION

4.0 Introduction

The system specification of this project deals with the software specification and the

hardware specification required in the accomplishment of the final output of results which

is the overall project.

4.1 Hardware Application

Since there is advancement in technology to replace the existing system, there would be

some major hardware specification to enable the application to run very effectively and

efficiently since it is a computer base. Below are the standard hardware requirements for

the Church Information System .

Hardware Specification

Processor : 1.70 GHz and Above

Main Memory : 512 MB.

Hard Disk : 20 GB.

Disk Space : 100 MB.

Keyboard : ANY

Mouse : ANY

Monitor : ANY

CD ROM Drive : 52x Samsung CD ROM

37
4.2 Software Specification

Software Specification

Operating System : Windows, LINUX

Software : PHP, JAVASCRIPT, HTML, Apache

Data Base : MYSQL

4.3 System Architecture

The system we have developed is mainly a web based system. The three-tier architecture is

followed in the development of the system. A three-tier architecture has three separate

components: a client, an application server and a database server. In implementing a three-

tier architecture the number of choices is more than the traditional client server architecture.

The communication protocol used to communicate between the client and the application

server can be different from that used to communicate between the application server and

the database server. The workload distribution among the three components can vary widely

across applications.

Most web-enabled database relies on a three-tier model. Typically, an existing database

server is made available for web-based access. To make the database available, the server

must be accessible via an external network. To provide this network access, a second server

is commonly used as a firewall, restricting the kinds of commands that can be passed to the

database server. The application server can act as a firewall.

Request Command
APPLICATION DATABASE SERVER
SERVER
CLIENT
Reply Result

38
The above figure shows one possible configuration for a web enabled system. The client is

a computer with access to the Internet, running a browser. The client communicates with

the application server via the Hypertext Transfer Protocol (HTTP). The application server

in turn executes commands against the database, formats the result in Hypertext Markup

Language (HTML), and return the result to the client. In this configuration, the application

server provides authentication services (to make sure the client is allowed to initiate the

request), database connection service, and application processing service. The client’s role

is to initiate the request and display the result returned, while the database serves as the

repository for the data

4.4 Software description

4.4.1 PHP

Introduction:

PHP is a server-side scripting language for creating dynamic Web pages. You create pages

with PHP and HTML. When a visitor opens the page, the server processes the PHP

commands and then sends the results to the visitor's browser, just as with ASP or

ColdFusion. Unlike ASP or ColdFusion, however, PHP is Open Source and cross-platform.

PHP runs on Windows NT and many Unix versions, and it can be built as an Apache module

and as a binary that can run as a CGI. When built as an Apache module, PHP is especially

lightweight and speedy. Without any process creation overhead, it can return results quickly,

but it doesn't require the tuning of mod_perl to keep your server's memory image small.

In addition to manipulating the content of our pages, PHP can also send HTTP headers. We

can set cookies, manage authentication, and redirect users. It offers excellent connectivity

39
to many databases (and ODBC), and integration with various external libraries that let us

do everything from generating PDF documents to parsing XML.

We used the PHP in our Web pages to enable user information to kept in our database and

moreover to verify the database if you are the right person login into the system. This is a

block of PHP code:

<?php
if(isset($_GET['err'])){
if($_GET['err']==1){
echo "please either your name or password is wrong";
}elseif($_GET['err']==2) {
echo "Please you need to log in before having access to the page";
}elseif($_GET['err']==3){
echo "You have successfully logged out";
}elseif($_GET['err']==4){
echo "You have successfully Deleted your account";
}
}else{
echo "Please Login";
}
?>

which is checking if your username and password is correct. PHP's language syntax is

similar to C's and Perl's. You don't have to declare variables before you use them, and it's

easy to create arrays and hashes (associative arrays). PHP even has some rudimentary

object-oriented features, providing a helpful way to organize and encapsulate your code.

40
4.4.2 JavaScript

JavaScript Introduction

JavaScript is a technique for manipulating HTML documents in the browser. This is often

called client-side scripting. It allows the page author to incorporate facilities such as buttons

that change in appearance when you move the mouse over them and menus that expand. It

also provides facilities to manipulate the browser window in various interesting ways.

It is used by incorporating programmers in parts of HTML pages known as scripts.

Browsers must include JavaScript interpreters. It should be noted that JavaScript has

nothing whatsoever to do with the Java programming language. We used the JavaScript to

enable some of our menu and content to change their behavior on mouse hover and to restrict

user to provide the right information for instance, by not putting figures at place that require

alphabet and also we JavaScript to validate data before it is submitted to a server. This saves

the server from extra processing.

4.1.3 HTML

Introduction to HTML

HTML or Hyper Text Markup Language is designed to specify the logical organization of

a document, with important hypertext extensions. It is not designed to be the language of a

WYSIWYG [WHAT YOU SEE IS WHAT YOU GET] word processor such as Word or

WordPerfect. This choice was made because the same HTML document may be viewed by

many different "browsers", of very different abilities. Thus, for example, HTML allows you

to mark selections of text as titles or paragraphs, and then leaves the interpretation of these

41
marked elements up to the browser. For example, one browser may indent the beginning of

a paragraph, while another may only leave a blank line.

HTML instructions divide the text of a document into blocks called elements. These can

be divided into two broad categories -- those that define how the BODY of the document

is to be displayed by the browser and those that define information `about' the document,

such as the title or relationships to other documents. The vocabulary of these elements and

a description of the overall design of HTML documents are given in the rest of Section 2.

The Last part of the section also describes standard naming schemes for HTML

documents and related files.

The detailed rules for HTML (the names of the tags/elements, how they can be used) are

defined using another language known as the standard generalized markup language, or

SGML. SGML is wickedly difficult, and was designed for massive document collections,

such as repair manuals for F-16 fighters, or maintenance plans for nuclear submarines.

Fortunately, HTML is much simpler!

However, SGML has useful features that HTML lacks. For this reason, markup language

and software experts have developed a new language, called XML (the Extensible Markup

Language) which has most of the most useful features of HTML and SGML.

Moreover, our content interface in the web page, the Web presentations with synchronized

text, images, audio, video, and streaming media both timed and interactive we used

HTML.

42
These blocks of code enable us to create a form for Login interface:

<html>
<body>
<form>
<table align="center" width='200px'>
<tr>
<td>Username:</td>
<td><input type="text" name="username"></td>
</tr>
<tr>
<td>password:</td>
<td><input type="password" name='password'></td>
</tr>
<tr>
<td colspan="2" align='center'><input type="submit" value='submit'></td>
</tr>
</table>
</form>
</body>
</html>

4.4.4 MySQL

MySQL is a database system used on the web. Basically, a MySQL database allows you to

create a relational database structure on a web-server somewhere in order to store data or

automate procedures. If you think of it in comparison to Microsoft Access, MySQL is what

holds all of your tables, PHP acts as your queries (among other things), and your forms are

basically web pages with fields in them. With all of this combined, you can create truly

spectacular projects on the web.

43
MySQL is also open source in that it’s free and falls under the GNU General Public License

(GPL). Chances are, if you are getting your own web-page or already have one – your host

supports MySQL and PHP. They are generally associated with (though not limited to)

Unix/Linux based servers. If by chance you are considering getting your own page and want

MySQL and PHP support check out Dreamhost – I’ve been using them for years and they

absolutely can’t be beat.

Interacting with a MySQL database is a little weird as you don’t have the tried and true

WYSIWYG [WHAT YOU SEE IS WHAT YOU GET] interface that something as easy as

Microsoft Access affords. When creating tables, you’ll either have to create them by using

SQL Statements, or by using another open-source tool available online called

PHPMyAdmin. PHPMyAdmin gives you an easy-to-use interface that allows you to create

tables and run queries by filling in a little bit of information and then having the tables

created for you. This is good if you’re either lazy, or don’t feel like bothering with big and

complicated SQL Statements.

In our webpage, MySQL database was used as our database system where we keep record

of all members in church, other related information and also enabling us to update our

website easily.

4.5 Feasibility Study and System Analysis

4.5.1 Feasibility Study

Feasibility can be established sometimes using investment appraisal techniques so that a

detailed analysis of the existing system is conducted. Feasibility study is referred to as the

44
likelihood that the system would be useful to the organization or institution. This stage is

very important because it produces the results of all investigations which are determined by

the system. The feasibility study is assessed in three main ways. They are:

1. Economic feasibility

2. Technical feasibility

3. Operational feasibility

Economic Feasibility Study

This type of feasibility study deals with resources; some of which are time factor, cost

involved in terms of hardware, training employee and the cost of the software. All these are

considered during the development of the software application. A system that can be

developed technically and that would be used if installed must also be a good investment

for the organization. These financial benefits must equal or exceed the costs. Some questions

to be asked are:

1. Are there sufficient benefits in creating the system to make the cost acceptable?

2. Would the software be beneficial to speed up transactions and also reduce stationary for

record keeping?

A system financial benefit must exceed the cost of developing that system, i.e. a new system

being developed should be a good investment for the organization. Economic feasibility

considers the following:

i. The cost to conduct a full system investigation.

45
 ii. The cost of hardware and software for the class of application.

iii. The benefits in the form of reduced cost or fewer costly errors.

iv. The cost if nothing changes (i.e. the proposed system is not developed).

The proposed “Church Information System” is economically feasible because

i. The system requires very less time factors.

ii. The system will provide fast and efficient automated environment instead of slow

and error prone manual system, thus reducing both time and man power spent in

running the system.

iii. The system will have GUI interface and very less user-training is required to learn it.

iv. The system will provide service to view various information for proper managerial

decision making.

Technical Feasibility

The technical feasibility study is the large part which determines resources. Can the work

of the project be done with current equipment, existing software technology and available

personnel? If new technology is required, what is the likelihood that it can be developed?

These are some very important questions that need to be answered to ensure the technical

feasibility of a system.

The software demands no sophisticated equipment’s for its implementation. Users only

require slight training to use it effectively. Also, the development of the software application

was based on the current existing technology equipment. The technical resources are easy

and the user will not find it difficult in using them.

46
Technical feasibility centers around the existing computer system (Hardware and Software)

whether it can support the addition of proposed system, if not, to what extent it can support

and the organization’s capacity to acquire additional components.

Our proposed system is technically feasible because:

1. The hardware and software required are easy to install and handle (The necessary

hardware configuration and software platform is already there).

2. The system supports interactivity with the user through GUI.

3. Expandability will be maintained in the new system. New modules can be added

later on the application, if required in the future.

4. The application will have User-friendly Forms and Screens, all validation checks.

So, the new system guarantees accuracy, reliability, ease of access and data security.

Operational Feasibility

This type of feasibility study is dependent on the human resources that are available. It

mostly consists of how the projects are beneficial if only they are turned into information

systems that would be able to meet the organizations operations requirements. Behavioral

feasibility is tested with answers to questions like:

1. Will the system be used if it is developed and implemented?

2. Will there be resistance from users that will undermine the possible application

benefits?

3. Will the system to be produced receive maximum support from the management and

workers of the institution?

47
If the application is developed and implemented, there will be no resistance from the users

that will undermine the possible application benefits.

Behavioral feasibility determines how much effort will go in the proposed information

system, and in educating and training the employees on the new system, along with the new

ways of conducting the business. Behavioral study strives on ensuring that the equilibrium

of the organization and status quo in the organization are not disturbed and changes are

readily accepted by the users.

The proposed system is behaviorally feasible because of the following:

 The executives of the church will accept it because they are already acquainted with

computers.

 This system is also meant for the general user i.e. church members. Nowadays the

Internet is almost familiar to everyone. So, it is not difficult for the user to use the

system.

 Most of the members are familiar with the web browser and the process of browsing

the website will be simplified for the members. The organization is definitely ready

to welcome the computerized system.

4.5.2 System Analysis

System analysis is the process of gathering and interpreting facts, diagnosing problems and

using the information to recommend improvement to the analysis. The system analysis

specifies what the system should do at a particular time. Design states the process involved

in how to accomplish the objectives. System analysis is an activity that encompasses the

48
tasks. In terms of this project, it will be the system development life cycle. The process of

system analysis is conducted with the following objectives in mind:

 Identify the need of computerization of the church information system

 Evaluate the system concept for feasibility

 Reform economical and technical analysis

 Allocate function of hardware, software, database and other system elements

 Establish cost and schedule constraints

 Create a system definition that forms the foundation for all subsequent production

work

4.6 System Design

The design state involves how to accomplish the objectives of the project. This then includes

the architecture aspect of the system as well as the developing process of the software

application.

49
4.6.1 Design of the component

Figure. 4.1 Functional Decomposition Diagram

4.6.2 Database design

Table Design
1. Login

Table 4.1 information about the administrator who authorized to do the desired task

FIELD NAME FIELD TYPE REMARKS

username Text NOT NULL
password Text NOT NULL

50
2. Members

Table 4.2 information about the members of the church.

FIELD NAME FIELD TYPE NULL KEY DEFAULT EXTRA

memberid Int(5) No PRI None auto_increment
title Text No None
fname Text No None
mname Text Yes Null
lname Text No None
sex Text No None
dob Date No None
email Varchar(20) No None
raddr Varchar(15) No None
location Text No None
religion Text No None
cellphone Int(15) No None
pic Varchar(15) No None
session Text No None
wings Text No None

3. Request

Table 4.3 comments and request from members.

FIELD NAME FIELD TYPE NULL KEY DEFAULT EXTRA

forumid Int(5) No MUL None
text Varchar(200) No None

51
4. Forum

Table 4.4 information about the members registered to join forum.

FIELD TYPE FIELD TYPE NULL KEY DEFAULT EXTRA

forumid Int(5) No PRI None auto_increment
title text No None
fname text No None
mname text Yes Null
lname text No None
email Varchar(20) No None
username Varchar(10) No None
password Varchar(30) No None
cellphone Varchar(15) No None

4.7 User Interface of Church Information System Screen Design

The home page - is the central point of navigation to the various pages the site is made up

of. Authorized and unauthorized users have access to this page and the navigation links are

displayed based on access rights of the user. . Only users who are authenticated can get pass

this page to the other pages that are not listed when the site is first visited.

Login Panel

This form allows an authenticated user or an administrator to login with their respective

login credentials (Username and Password). Administrator can will add all the new user into

the application.

52
Figure 4.2 Login Panel

Figure 4.3 Admin Dashboard

53
Figure 4.4 Members Dashboard

Figure 4.5 Sunday School

54
4.8 Testing and implementation

4.8.1 Testing

Overview:

The aim of testing process is to identify all defects in a software product. Testing is any

activity aimed at evaluating the software for quality results it produces and the quality of

results it can handle. Testing is an operation to detect the differences between the expected

(required) result and the actual result.

Testing a program consists of subjecting the program to a test inputs or test cases and

observing if the program behaves as expected. If the program fails to behave as expected,

then the condition under which failures occurs are noted for later debugging and correction.

There are many stages of testing depending on the complexity of the software.

Levels of Testing:

The basic levels of testing are: -

1. Unit Testing.
2. Integration Testing.
3. System Testing
4. Acceptance Testing.
The levels of resting attempt to detect different types of faults. The relation of faults

introduces in different phases and the different levels of testing are shown.

Employee Needs Acceptance Testing

Requirements System Testing
Design Integration Testing
Code Unit Testing

55
Unit testing:

Unit testing has been under taken when a module has been coded and successfully reviewed.

Unit testing is the testing of different units or modules of system in isolation. It is

programmer’s responsibility to think of the advantage of doing unit testing before

integration testing is that it makes debugging easier. If an error is detected when a module

is being tested along with several modules, it would be difficult to determine which module

exactly has an error.

In the current system “Church Information System”, unit testing has been exclusively done

after finishing every module.

Integration testing:

Once a program or module has been unit tested, the programmer can then work with

integration it with other programs.

The primary objective of integration testing is to test the module interfaces in order to ensure

that there are no errors in the parameter passing, when one module involves another module.

During integration testing, different modules of the system are integrated in a planned

manner i.e. the order in which they are combined to realize the full system.

The various approaches of integration testing are:

1. Big Bang Approach.

2. Top-Down Approach.
3. Bottom-Up Approach.
4. Mixed Approach.

56
Out of the above four approaches Mixed Approach has been used for the proposed system.

A mixed approach integration testing follows a combination of top down and bottom up

testing approach. In the top-down approach, testing can start only after the top-level modules

have been coded and unit tested. Similarly, bottom up approach can start only after the

bottom level modules are ready. The mixed approach overcomes these shortcomings of the

top-down and bottom-up approaches. In the mixed testing approach, testing can start as a

when modules become available.

For the proposed we have also extensively used regression testing. Regression testing is the

practice of running an old test suite after change to the system or after each bug fix ensure

that no new bug has been introduced as a result of the change made or bug fixed.

System testing:

System testing is actually a series of different test whose primary purpose is to exercise the

computer based system, all work to verify that system elements have been properly

integrated and performed allocated function.

Its focus is to prove that the completed system does what it should. This test is conducted

in a formal manner. The testers use scenario-based system test scripts that have predicted

outputs. The test results are recorded in structured test logs. The structured test logs and

scripts drive the system testing process.

System testing activities are intended to prove that the system meets its objectives. Testing

proves that the system meets its requirements. This is not entirely true unless one considers

acceptance testing as a type of a system testing because the purpose of acceptance testing is

to demonstrate that the system meets the user requirement. Acceptance testing is validation

57
process. System testing in the strictest sense is a verification process. Regardless of whether

it represents verification or validation, system testing represents an external view of the

system.

This is true because requirements represent the eventual system users of the system (an

external view). Users do not understand nor do they care about how the system works as

long as it is usable. System testing should be approached from this perspective.

As far as the proposed “Church Information System” is concerned it meets this requirement.

Performance testing:

Some of the performance testing done for the proposed system are: -

1. Stress Testing: - Stress testing is done to evaluate system performance when it

is stressed for short periods of time. Providing a range of abnormal and even

illegal input condition so as to stress the capability of the software. Input data

volume, input data rate, processing time, utilization of memory etc are tested

beyond the designed capacity.

2. Volume Testing: - This testing is done to check whether the data structures have

been designed successfully for extraordinary situation.

4.8.2 System implementation

Once the system was tested, the implementation phase started. The term implementation

has different meanings, ranging from the conversion of a basic application to a complete

replacement of a computer system. Implementation is the process of converting a new or a

revised system design into an operational one.

58
Implementation includes the activities that take place to convert the older system to the

newer one. The new system may be totally new or replacing an existing system. In either

case, proper implementation is essential to provide a reliable system to meet organizational

requirements. System implementation describes how the different parts of the system are

interacting with each other to give us a feasible software solution.

Implementation of the system includes conversion process. Conversion is the process of

changing from the old system to the new system. The four methods of system conversion

are:

1. Parallel Approach: the old system is operated with the new system

2. Direct Method: the old system is replaced with the new system

3. Pilot Approach: the working version of the system is implemented in one part of the

organization and based on its feedback, changes are made and the system is installed

in the rest of the organization by one of the methods.

4. Phase-in Method: the phase-in method gradually implements the systems across all
users.

The proposed system “Church Information System” is not fully implemented as

development of some modules are not completed. It will be implemented after the

completion of other modules. The parallel approach will be used for the system conversion.

This is because the old version cannot be discarded right away since the users are novice in

computing.

59
 CHAPTER FIVE

CONCLUSIONS AND RECOMMENDATIONS

5.1 Summary

The web enabled system “Church Information System” on successful completion enables

the members of church to view the status of the records. It will also provide the facility to

the user so that they can send their request online. The Authority of the church will be also

benefited by the proposed system, as it will automate the whole registration procedures,

which will reduce the workload for the Authority.

Since every system has some limitations, so the proposed system is also not untouchable in

this regard. Although it includes many features but still it would not be sufficient as the user

requirements are not always same. The change in the requirements will need some changes

in the system to fulfill the requirements. The security of the system will be one of the prime

concerns once it will be made online.

This program would enhance the running of the church information. The existing system

will be used alongside the new system to ensure that the church does not loose valuable

information when switching to the new system.

5.2 Conclusion

The result of this project leads to the conclusion that if this software is introduced and

implemented, it would help the church achieve the objectives above and also help eradicate

the paper work from the system.

60
5.3 Recommendations

We recommend that any group or persons that wish to further improve upon this project

may incorporate:

1. Online facility for member and other users to donate to the church.

2. Provide facilities for members to communicate online.

3. Provide facility to signal members birthday and anniversaries.

61
 REFERENCES

[1]. System Analysis and Design—Elias M. Awad (Galgotia Publications—2004).

[2]. Java How to Program—Deitel & Deitel(PHI—2004).

[3]. Mastering SQL Server 2000—Mike Gunderly, Joseph L Jordan.

[4]. Database System Concepts—Silberschatz,Korth,Sudarshan (McGraw Hill—2002).

[5]. Software Engineering 7th Edition– Ian Sommerville 2004

[6]. The Complete Reference Java J2SE 5th Edition—Herbert Schildt (Tata McGraw Hill

2005).

[7]. "David Gonzalez (July 24, 1994)". "The Computer Age Bids Religious World to Enter".

The New York Times http://query.nytimes.com/gst/fullpage.html? res=940

DE6DB133EF937A15754C0A962958260. Retrieved 2017-04-04.

[8]. LaRue, J.C. Jr. (1999, Mar/Apr). The Wired Pastor. Your Church. Retrieved October

25, 2005 from http://www.christianitytoday.com/yc/9y2/9y2080.html.

[9]. Brown, V. (2005). Online Communities Connect Christians in Cyberspace. United

Methodist Communications. Retrieved January 25, 2017 from http://archives.umc.org

/interior_print.asp?ptid=20&mid=6476&pagemode=print

[10]. Fundamental of Software Engineering—Rajib Mall (PHI).

[11]."Software manages while pastors minister". Church

Central.http://www.churchcentral.com/nw/s/template/Article.html/id/16811. Retrieved

2017-04-11.

[12] "Software solutions for growing churches". Church Central. January 5,

2017.http://www.churchcentral.com/nw/s/template/Article.html/id/22325. Retrieved 2017-

04-04. "With more than 7,000 members and an office staff of 75, Asbury United Methodist

62
 Church of Tulsa, Okla., relies on church management software to help run the administrative

side of the church."

[13] "What can church management software do?". Church Central. 21 February

2005.http://www.churchcentral.com/nw/s/template/Article.html/id/22325. Retrieved 2017-

04-04.

[14]. United Methodism 101. (updated 10/14/05). United Methodist Communications.

Retrieved January 25, 2017 from http://www.umcom.org/pages/news.asp?class=1

&Type=2&ID=932&product_id=0.

[13]. Web as Ministry: Discipleship. (n.d.). United Methodist Communications. Retrieved

January 25, 2017 from http://archives.umc.org/interior.asp?ptid=1&mid=48.

[15]. www.php.net for complete reference of php.

[16]. HTML,DHTML,JAVASCRIPT,Perl CGI - IVAN BAYROSS.

[17]. Beginning Java Server Pages – Wiley Publicaton

[19]. Professional Java Server Programming J2EE 1.3 Edition-Apress

[20]."WebApplicationSecurity”.DocForge.http://docforge.com/wiki/Web_application/Sec

urity.Retrieved 17 January 2017.

63

View publication stats