You are on page 1of 50


This analysis has been carefully done to find out the applicability of management and security in a Church Management System. It consist of two main areas; an overview of the overall system requirements and a description of the decision support capabilities of the system. Decision Support has been integrated with the system through a budgeting module, work or task allocation module and a module to analyze historical trends such as developments.

Problem Specification
Church Management decision making has become a challenge to many churches. Their way of keeping records is prone to misrepresenting facts and not helpful in church management decision-making. In particular their record keeping has become non-existent or a confused mess. Some of the church activities calling for decision making are Tithe and Offering records, administration of members, Missions as the main focus, among others.

Technical Feasibility
The church in the case study as it is currently, it has no personal computers. The aim then is to first computerize the church and then introduce the system to be used. The system requires only a modern personal computer to run. The system is simple enough to the administration with no technical difficulties.

Operational Organizational Feasibility

The Church in the case study is automating its operations and this is one of its current goals. The system will serve the church management in church management and to some extent in decision making concerning various issues affecting the church and its entire congregation. As well as this, the system is going to enhance good security of its records by use of the system.

Economical Feasibility
The major resource needed is a personal computer which must be bought in which case the church is capable of buying based on its current economic status. Other costs include

development and maintenance costs, which are affordable. The software to be used are readily available in the market, though the church will make effort to meet the costs thereof. Because the church is ready to do so, then this wont be an obstacle.


This Section describes the principal functional and performance/non-functional requirements of the Church Management System. It shows what the system is going to do to achieve its goals and objectives. For each key issue or requirement, an attempt has been made to construct a strategy that satisfies overall project goals while considering best practices, available and emerging technology, and local vs. state needs, time to implement and overall cost. The specifications (functional and non functional requirements) of the system are also listed.

Functional Requirements
These refers to the necessary tasks, action or activities that the system must accomplish, or enable the user to do. The system should provide effective, efficient and easy to use search functionality with the following features:

Church Member Personal Details Member Attendance records Member Discipline records Member Contributions Church Activities

User input validation Adding a member Keying in Member contributions Searching for a member using a specific criteria Querying the database to retrieve useful data Budget preparation Activities undertaken by members

Search results: Member Details, Members Attendance records, Member Activities records A budget proposal Useful Information for use to help in allocating Members tasks and duties (Leadership). Useful Information for use to help in promotion of Members.

Categorized information for easy search:

The information within the database shall be categorized as under: Member Number. Member ID

Results Display.
Results should be displayed in the user interface Only Relevant Results are displayed.

Search functionality operation

Accept query Look in index for words that match Extract field that match all criteria

Application Programming Interface

This application interacts with the server.

Hardware Interfaces
This application will use a Personal Computer

Non functional Requirements

1. Usability: The system should be easy use providing the user with support. The system should be intuitive to the user i.e. it should not require any expertise for use. The system should build upon the existing interaction techniques used by the users. This approach avoids the need for the user to learn new actions.

2. Availability: The system should be up and running whenever needed especially during office/working hours. 3. Security: The system should provide controlled access to various types of information. Only authorized users should access and modify data in the system. This is implemented by the use of database views. 4. Extensibility: The system functionality should be easy to extend to include features that will unfold in the future. 5. Adaptability and evolution: The system should provide flexibility and production of new versions suited for new environments and changing needs. 6. Performance Requirements: The application should not interfere with the general performance of the computer in use. When the system is running, other applications should be able to function in a normal manner, e.g. it should not slow down the computer or hinder the performance of other applications.

a) Cost: limited financial support provided by the university towards the project b) Hardware: one PC has been dedicated for the project. The problems and unreliability of mobile networks have direct effects on the speeds of connections. c) Time: Development time from analysis to design, coding testing software validation and documentation is limited to a short duration. d) Development effort: the entire development process is limited to only one developer, who my not be in position to deliver a perfect system with all the necessary factors put into consideration.

Data Sources
Prospective users of the system e.g. students who will be checking their results using Short Message Service. JKUAT. E.g. Information on how results are Stored from JKUAT System administrator.

Data collection Methods

The following methods have been used to collect all the necessary data that is needed for analysis purposes and also for the system development and testing purposes:

This is whereby the client is interviewed to establish exactly what is needed. The client in this case is the church management as well as the personnel who will be using the system.

The church management is observed as the clergy and the elders carry out their day to day activities. What is observed is analyzed to establish the user requirements.

Document review
The church records are analyzed to see how information concerning church members and other activities is stored and in which format they are kept. This is done so as to determine how the system is going to be structured.


This chapter gives an overview of the top-level design and processes used in the development of the software. This phase in the development involves translation of the system specifications in the analysis phase into a technical specification for implementation. The primary purpose of this system design phase is to specify various components of the system and their relationships and interaction in a format that can easily be mapped into programming codes to produce the required system. Methodology System analysis began by specifying requirements and constraints that resulted in a conceptual model representing system components and their interaction. This enabled creation of physical models, software architecture and integration of components at design level. The various aspects of the designs specified therefore are: 1) Search Flow Process 2) UML diagrams a. Use case diagram for the CMIS Church Management Information System. (CMIS) b. Sequence Diagrams for the CMIS c. Activity Diagrams for the CMIS 3) Database design Table and data descriptions

Search Flow Process

A church might be having an enormous number of members and the records for each and every member need to be stored. When the information pertaining to any of the members is needed, it should be easy to get. The flow diagram below shows the design searching for a particular members records stored in the system.

Figure 1: Search Flow Process

Use Case diagram

These describe the interaction of the users in the system. That is the role of the users in the system. They are sometimes referred to as function requirements.The use case below shows the basic functionality of the church management system as an overview. The various tasks carried out by the actors are shown. The actors in this case include the system administrators or the personnel who are to work with the system.

Figure 2: System Basic Functionality

Activity Sequence
Usually used to model use cases by describing the way groups of the objects interact to complete a task. The sequence diagram shown here below clearly shows how the various activities in a church scenario flow and follow each other.

Figure 3: Activity Sequence

Adding a Member
Below is a diagram that shows what happens when information concerning a new member needs to be added so as to be stored in the system.

Figure 4: An Activity Diagram showing how to add a new member

Workflow for the Assign task activity

Figure 5: Assigning a task

Entering Members Contributions

At times members will be required to be contributing some money e.g. to build a pastors house or for any other use. This information needs to be entered accurately and to be stored securely for evaluation and assessment purposes. The activity diagram below shows how this information is entered.

Figure 6: Entering members contributions

The budget process

Figure 7: Budget process workflow

A Church Budget Proposal for 2007

TITHE OFFERING OTHERS TOTAL INCOME 720000 200000 74000 994000 EXPENSES 0 0 0 0 24000 20000 9500 15000 68500 822,000 172000 822000


Total Income generated was Ksh. 994,000. Notice in the budget the building committee is allocated an amount of 24,000 per month. The amount they are allocated depends on the

income generated as we shall see below. From this amount the building committee can answer the question: Do we proceed and build the proposed store facility? A Church Budget Proposal for 2008 TITHE OFFERING OTHERS TOTAL BUILDING COMMITTEE MINISTERS SUPPORT MISSIONS SUPPORT OFFICE MAINTAINANCE MONTHLY TOTAL ANNUAL TOTAL ANNUAL SAVINGS INCOME 720000 200000 580000 1,500,000 EXPENSES 0 0 0 0 80000 30000 14000 17000 68500 822000 172000

TOTAL INCOME AND EXPENDITURE EXPECTED IN 2007 KSH 994000 Table 2: Church Budget proposal for 2008


Total Income generated was Kshs 1,500,000. Notice in the budget the building committee is now allocated an amount of 80,000 per month. The amount they are allocated depends on the income generated. From this amount the building committee can answer the question: Do we now proceed and build the proposed store facility based on the amount allocated to the committee? Note that the income levels are higher than the previous budget so more funds are allocated to the building committee which will help them to base their decisions on whether to build the proposed store facility.

Description of CMIS Tables
Table Members Description Details regarding Members

Contribution Activities Attendance Discipline Services Letters

Stores details pertaining to Member contributions Stores details of Activities assigned to Members Stores details regarding attendance Store details regarding discipline of members Stores details of church services Stores details for composing letters Table 3: Description of CMIS tables

Entities and attributes

Table Members Fields IDIndividual, First Name, L_Name, MemberNo, FamilyMember, Birthdate, Gender, Address, City, SpecialNeed, Phone, Status, Married, Emergency, Contribution Pledges Activities Attendance Services Letters Occupation, MovedFrom, Note ID(Auto Number), IDIndividual, Con_Date, Amount, Category, Note ID(Auto Number), IDIndividual, Pledge_Date, Amount, Category, Note ID(Auto Number), IDIndividual, Act_Assigned, Attendance, Comment TotalVisitors, AttendanceDate, AttendanceActivity, AttendanceDatePosition ID(Auto Number),IDIndividual, Service_Type, Date ID(Auto Number), Letter, Salutation, Body, Closing, Signature Table 4: CMIS entities and attributes

Here, an example of the overall structure of two modules is given. These two modules are the members module and the financial module.

Members module

Figure 8: Members Module

Financial module

Figure 9: CMIS Financial Module

In this chapter, Analysis and the design of the system has been looked at: the problem specifications, the functional and non functional requirements of the system in the analysis phase and overall conceptual structure of the system, UML diagram describing the design and functionality of the system, the database design and the interface. Final review and endorsement of the strategies presented by this document enable the developer to continue the implementation of the CMIS System.

This stage involves demonstrating clearly how the various aspects of the system function in co-relation with each other in order to achieve the outlined objectives. It involves mapping the design into a programming language the aim is to come up with a functional, an efficient, effective and easy to use Church system tailored for use in a mobile device in the access of Student Exam results for University students. In the JKUAT SMS Results System, the mobile device SMS Functionality at the front-end is the main means by which the user can access the system at the backend. At the back-end, the system is supported by an SQL database that feeds the front-end with the required data and information. This is the stage in the development process that deals with demonstrating clearly how the various aspects of the system function in co-relation with each other in order to achieve the given and/or outlined objectives. In other words, it involves translating the design into a particular programming language i.e. the actual coding of the system. The aim is to come up with a functional, an efficient, effective and easy to use system tailored for use in a church scenario to provide a good management system and secure system for the churchs records and any other information regarding the day to day operations of the church. System Implementation involves mapping the design to a programming language to show how the various aspects of the system co-relate with each other in the bid to achieve the stated objectives. The system contains a front end implemented using VB.NET and a backend implemented using Microsoft SQL

Implementation Justification
With its release for the .NET platform, the Visual Basic language has undergone the following dramatic changes: The language itself is now fully object-oriented.

Applications and components written in Visual Basic .NET have full access to the .NET Framework, an extensive class library that provides system and application services.

All applications developed using Visual Basic .NET run within a managed runtime environment, the .NET common language runtime.

.NET platform is one of the most popular and easy-to-learn language provided by the .NET framework. Particularly, the language has been used because it is easier to learn with programming knowledge of earlier versions of Visual Basic. The developer also has the knowledge of developing applications using the earlier versions of Visual Basic such as Visual basic 6.0. Microsoft SQL Server works efficiently as a backend when used with the .NET framework. It provides robust database capabilities. It is capable of handling a large number of users or very extensive databases.

Actual Implementation
There are six sections in this application: Membership,View, Financial, Tools, Setup and Help. MEMBERSHIP - is designed to help manage the Churchs members and their activities. VIEW is designed to enable restricted access of information to the user of the system i.e. the user can only view fields they are allowed to.e.g. details about age,special needs are ommited. FINANCIAL - is designed to keep track of all contributions or pledges that the Church receives from its members. TOOLS - is a collection of special tools that help aid in the operations of the Church. SETUP - is where initial information about the application and the Church is entered and unique functionality is performed. HELP - provides an extensive help documentation guide about the operation and features of the application.

Front-End Implementation
This is the part that allows the user to interact with the system in a user-friendly way and it contains the general information about the church of our concern.

It is at this point that the authorization of the user is done i.e. if the user is new to the system, he or she must register first, and if he has the permission to use the system, then s/he logs into the system. A screenshot of this form is as shown below.

Figure 10: CMIS front-end screenshot

Implementation of Views 1. ViewMemberDetails View

Create view ViewMemberDetails SELECT DISTINCT dbo.TableIndividual.FirstName,dbo.TableIndividual.LastName, dbo.TableIndividual.MemberNo AS Members_Number, dbo.TableIndividual.Gender, dbo.TableContributions.ConDate,dbo.TableContributions.Amount,dbo.Tab leContributions.Note FROM dbo.TableIndividualINNERJOINdbo.TableContributionsON dbo.TableIndividual.IDIndividual = dbo.TableContributions.IDIndividual CROSS JOIN dbo.TableActivityList

How the view has been used in the system

2. ViewMemberPledges View

Create view ViewMemberPledges SELECT dbo.TableIndividual.MemberNo, dbo.TableIndividual.FirstName, dbo.TableIndividual.LastName, dbo.TableIndividual.Gender, dbo.TablePledges.PledgeDate, dbo.TablePledges.Category, dbo.TablePledges.Amount, dbo.TablePledges.Note FROM dbo.TableIndividual INNER JOIN dbo.TablePledges ON dbo.TableIndividual.IDIndividual = dbo.TablePledges.IDIndividual

How the view has been used in the system

Database structure

Individual Overview
The purpose of the Individual section is to provide detail information about each individual/member in the Church. Note that the combination of the first and last name is the primary key for the individual. Each individual must have a unique primary key. Duplicate primary keys are not allowed. The individual maintenance form maintains the list of all individuals. It also contains the search button that allows one to search for individual members. Below is a screenshot of this form.

Figure 11: Members Maintenance List

Sample classes in VB.NET Code used in DataGridView

Imports System Imports System.Data Imports System.Data.SqlClient Imports System.Windows.Forms

Sample VB.NET Code to add a new Individual to the database

Given below is a screenshot showing how to add information pertaining to a particular individual that needs to be added to be a member. Following this is a sample code for the same.

Figure 12: Screenshot showing how to add a new member

Private Sub CmdOk_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CmdOk.Click StrQuery = "INSERT INTO TableIndividual(IDFamily,FirstName,LastName,MemberNo,FamilyMember,Gender,Birthdate,MaritalStatus,M arried,Occupation,MovedFrom,Status,SpecialNeed,Notes,IDIndividual)values (@IDFamily,@FirstName,@LastName,@MemberNo,@FamilyMember,@Gender,@Birthdate,@MaritalStatus, @Married,@Occupation,@MovedFrom,@Status,@SpecialNeed,@Notes,@IDIndividual)" Dim sqlad As New SqlDataAdapter(StrQuery, conn) Dim CmdString As New SqlCommand(StrQuery, conn) sqlad.InsertCommand = CmdString sqlad.InsertCommand.Connection = conn sqlad.InsertCommand.Parameters.Add(New SqlParameter("@IDFamily", System.Data.SqlDbType.VarChar, 20, "Family ID")) sqlad.InsertCommand.Parameters(0).Value = ComboFamily.Text sqlad.InsertCommand.Parameters.Add(New SqlParameter("@FirstName", System.Data.SqlDbType.VarChar, 20, "First Name")) sqlad.InsertCommand.Parameters(1).Value = TextFN.Text.Trim sqlad.InsertCommand.Parameters.Add(New SqlParameter("LastName", System.Data.SqlDbType.VarChar, 15, "Last Name"))

sqlad.InsertCommand.Parameters(2).Value = TextLN.Text.Trim sqlad.InsertCommand.Parameters.Add(New SqlParameter("@MemberNo", System.Data.SqlDbType.VarChar, 20, "Member #")) sqlad.InsertCommand.Parameters(3).Value = TextMNO.Text.Trim sqlad.InsertCommand.Parameters.Add(New System.Data.SqlDbType.VarChar, 20, "FamilyMember")) SqlParameter("@FamilyMember",

Searching a Member
Below is a screen shot showing how to search information relating to a particular member. Following it is the sample code.

Figure 13: Screenshot showing how to search a member

Private Sub CmdSearch_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CmdSearch.Click Dim DsDataSet As DataSet Dim DrRowPicker As DataRow Dim StrBrowseBy As String Dim StrQuery As String Dim Result As Integer Dim BSearchStrEmpty As Boolean Dim SqlConnection1 As New SqlConnection(strconnection)

Dim SqlDataAdapter1 As New SqlDataAdapter() Dim SqlSelectCommand1 As New SqlCommand() BSearchStrEmpty = False If TxtSearch.Text.Trim = "" Then BSearchStrEmpty = True End If StrBrowseBy = CmbBrowseBy.Text If (Compare(StrBrowseBy, "Member Name", True) = 0) Then Result = 0 StrQuery = "SELECT DISTINCT MemberNo,FirstName,LastName,IDFamily,Status from TableIndividual " If Not BSearchStrEmpty Then StrQuery += "WHERE FirstName = '" StrQuery += TxtSearch.Text & "'" StrQuery += "or LastName = '" StrQuery += TxtSearch.Text & "'" End If ElseIf (Compare(StrBrowseBy, "Member No", True) = 0) Then Result = 1 StrQuery = "SELECT DISTINCT MemberNo,FirstName,LastName,IDFamily,Status from TableIndividual " If Not BSearchStrEmpty Then StrQuery += " WHERE MemberNo = '" StrQuery += TxtSearch.Text & "'" End If ElseIf (Compare(StrBrowseBy, "Member Status", True) = 0) Then Result = 2 StrQuery = "SELECT DISTINCT MemberNo,FirstName,LastName,IDFamily,Status from TableIndividual " If Not BSearchStrEmpty Then StrQuery += "WHERE Status = '" & TxtSearch.Text & "'" End If ElseIf (Compare(StrBrowseBy, "Family", True) = 0) Then Result = 3 StrQuery = "SELECT DISTINCT MemberNo,FirstName,LastName,IDFamily,Status from TableIndividual "

If Not BSearchStrEmpty Then StrQuery += "WHERE IDFamily = '" StrQuery += TxtSearch.Text & "'" End If Else Result = -1 StrQuery = "" End If DsDataSet = New DataSet() SqlDataAdapter1.SelectCommand = SqlSelectCommand1 SqlDataAdapter1.SelectCommand.CommandText = StrQuery SqlDataAdapter1.SelectCommand.Connection = SqlConnection1 SqlDataAdapter1.Fill(DsDataSet, "SearchResults") LvwSearchResult.Items.Clear() Dim IntRowCount As Integer IntRowCount = 0 For Each DrRowPicker In DsDataSet.Tables("SearchResults").Rows Dim StrSearchRow As String() = {DrRowPicker(0), DrRowPicker(1), DrRowPicker(2), DrRowPicker(3), DrRowPicker(4)} LvwSearchResult.Items.Add(New ListViewItem(StrSearchRow)) IntRowCount += 1 Next If IntRowCount = 0 Then If (IntRes = 0) Then MessageBox.Show("Couldn't find any Individual of this Member Number.") ElseIf (IntRes = 1) Then MessageBox.Show("Couldn't find any Individual of this Member Name.") ElseIf (IntRes = 2) Then MessageBox.Show("Couldn't find any Individual of this Status.") ElseIf (IntRes = 3) Then MessageBox.Show("Couldn't find any Individual of this Family.") ElseIf (IntRes = 3) Then MessageBox.Show("Couldn't find any Individual with this activity.") End If End If SqlConnection1.Close()

SqlConnection1.Dispose() SqlSelectCommand1.Dispose() SqlDataAdapter1.Dispose() End Sub

Back-End Implementation
Microsoft SQL Server works efficiently as a backend when used with the .NET framework. It provides robust database capabilities. It is capable of handling a large number of users or very extensive databases. Implementation of the backend for CMIS has been done using MSQL server whereby a database comprising the various tables (as shown in the database design section) has been created.


In the testing phase, various tests and validations are carried out on the various modules, and their integration functionality is checked. In the case of CMIS, all the forms are tested. Logic errors are detected by testing the program manually or automatically and verifying that the output is the required one.

User Testing
This involves testing the system manually using sample data and then viewing its output. Various users were called upon to test the system using sample data.

Individual Overview
To search for an individual, type in the search criteria in the text box called Search Text such as an individuals name. Then from the results, select a particular member and check attendance record or discipline record. Search by Member Number

Figure 14: Search Criteria: By member number

Search by Member Status

Figure 15: Search Criteria: By member status Search by Member First Name or Last Name

Figure 16: Search Criteria: By member name

Financial Overview
The Financial section is designed to keep track of all contributions and pledges that the Church receives from its members.

Contributions Overview
The purpose of the Contribution section is to provide a linkage of contributions to individuals. It also allows for the categorization of all contributions. The Contributions Maintenance window provides a listing of all selected contributions dates, amounts and individuals.

Figure 17: Members contributions

Introduction Evaluation and testing is an important part of your Mobile Web development process. Usability and accessibility tests gather data about the usability of your site by a group of users performing specific tasks. Heuristic Evaluation (originally proposed by Nielsen and Molich, 1990) is a discount method for quick, cheap, and easy evaluation of the user interface. The process requires that a small set of testers (or "evaluators") examine the interface, and judge its compliance with recognized usability principles (the "heuristics").

The goal is the identification of any usability issues so that they can be addressed as part of an iterative design process. Heuristic Evaluation is popular in Mobile Web development circles because it requires few resources in terms of money, time or expertise. So any developer can enjoy the benefits of usability testing - not just those with thousands to spend on a professional assessment. Heuristic Evaluation is characterized by:

Small test scenarios that use paper mock-ups or screen shots, which can easily be changed from one test situation to the next An informal basis for assessment that doesn't require psychologists A high success rate - so only a handful of testers are needed A few key guidelines.

Heuristic Evaluation System Checklist Visibility of System Status

The system should always keep user informed about what is going on, through appropriate feedback within reasonable time. # Review Checklist Does every display begin with a title or header that describes screen contents? Is a single, selected icon clearly visible when surrounded by unselected icons? Is there some form of system feedback for every operator action? After the user completes an action (or group of actions), 4 does the feedback indicate that the next group of actions can be started? Yes Yes No N/A yes Active links yes have a different color Yes Comments

User Control and Freedom

Users should be free to select and sequence tasks (when appropriate), rather than having the system do this for them. Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Users should make their own decisions (with clear information) regarding the costs of exiting current work. The system should support undo and redo. # Review Checklist When a user's task is complete, does the system wait for a signal from the user before processing? Is there an "undo" function at the level of a single action, a data entry, and a complete group of actions? Can users cancel out of operations in progress? Can users reduce data entry time by copying and modifying existing data? Are character edits allowed in data entry fields? Yes No N/A no Comments

2 3 4 5

N/A yes yes yes

Consistency and Standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. # Review Checklist Has a heavy use of all uppercase letters on a screen been avoided? Are there salient visual cues to identify the active window? Yes No N/A Yes Comments


3 4

Does each window have a title? Are vertical and horizontal scrolling possible in each window? If "exit" or log of is a menu choice, does it always appear at the bottom of the list? Color: up to four (additional colors for occasional use only) Are attention-getting techniques used only for

N/A Yes



exceptional conditions or for time-dependent information?


e.g. to confirm login

Are user actions named consistently across all prompts in the system?


Help Users Recognize, Diagnose, and Recover From Errors

Error messages should be expressed in plain language (NO CODES). # 1 2 3 4 5 6 Review Checklist Is sound used to signal an error? Are prompts stated constructively, without overt or implied criticism of the user? Are prompts brief and unambiguous Are error messages worded so that the system, not the user, takes the blame? Do messages place users in control of the system? Do error messages suggest the cause of the problem? Yes No N/A No Yes yes yes yes yes Comments

Do error messages provide appropriate semantic information? Do error messages indicate what action the user needs to take to correct the error?



Error Prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. # Review Checklist If the database includes groups of data, can users enter more than one group on a single screen? Are data inputs case-blind whenever possible? If the system displays multiple windows, is navigation between windows simple and visible? Do fields in data entry screens and dialog boxes contain default values when appropriate? Yes No N/A yes yes N/A Comments Vacancies can be added repeatedly

1 2 3


Recognition Rather Than Recall

Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. # Review Checklist Does the data display start in the upper-left corner of the screen? Are multiword field labels placed horizontally (not Yes No N/A yes yes Comments

1 2

stacked vertically)? 3 Are all data a user needs on display at each step in a transaction sequence? Are prompts, cues, and messages placed where the eye is likely to be looking on the screen? Is there an obvious visual distinction made between "choose one" menu and "choose many" menus? Are optional data entry fields clearly marked? Are sizes, boldface, underlining, color, shading, or 7 typography used to show relative quantity or importance of different screen items? 8 9 10 11 Are borders used to identify meaningful groups? Has the same color been used to group related elements? Is color coding consistent throughout the system? Is there good color and brightness contrast between image and background colors? yes yes Yes N/A yes yes


5 6

N/A yes use of *

The system should help the user to protect personal or private information- belonging to the user or his/her clients. # 1 2 Review Checklist Are protected areas completely inaccessible? Can protected or confidential areas be accessed with certain passwords? Yes No N/A yes yes Comments

Is this feature effective and successful?


System testing and evaluation of the system is an integral part of system development. It ensures that the system delivers the output required by the user as specified in the implementation. It also helps to detect logic errors during implementation. The system was tested using search interface which retrieves members particulars based on the criteria used. The results are then used to know the specifics of the member such as member attendance record.

The most important aspect of any management system is that it supplies users with alternate information that may be useful to them ensuring that the system is secure and safe at the same time. This information helps the users to make informed decisions that are necessary for the progress of the organization or institution. We have dealt with specification of the system, defining its scope, requirement specification, analysis of requirements, and implementation of the system and finally testing the system. All this stages have been efficiently covered to ensure a reliable and good performance system is developed. The system has the most important sections in operation.

The following are the objectives achieved during Implementation: 1) Analysis, Specification and Development of a Church Management Information System (MIS) 2) Analysis, Specification and Development of a data management component used for Querying Member Details using certain criteria i.e. To determine who to make a church leader Extracting information to determine the growth progress e.g. Attendance Record

The following are the difficulties that were faced during the development and actual implementation of the system: 1. Time Barrier To come up with a complex system like this required a lot of time to be invested in it. This lead to many sacrifices being made in other fields. 2. Knowledge of the extensive codes required to create the system proved so demanding and called for more time.

The Way Forward

Significant advances in computer technology have increased interest in computer aided tools to improve the effectiveness of the management decisions. Generally human investigate into the decision making process and during this investigation the computer supports the process

by furnishing pertinent information, thus creating human computer decision making system. This means better performance and reliability in administration of activities. The future means systems that can not only manage data and make decisions rather than help in the process of decision making. These are expert systems.


1. Automation - performing tasks electronically using computers and other electronic devices, instead of manually. 2. Communications-driven DSS - Its purpose are to help conduct a meeting, or for users to collaborate. 3. Data Mining - Finds hidden patterns and relationships in large databases to infer rules 4. Data Warehouse It is an integrated, subject-oriented, time invariant and non volatile collection of data for making some important decisions. 5. Data-Driven DSS - Allows users to extract and analyze useful information from large databases 6. Decision A decision is a choice between alternatives based on estimates of the values of those alternatives. 7. Decision Support System (DSS) - computer-based support systems which help decision makers utilize data and models to solve semi-structured or unstructured problems 8. Document-Driven DSS - The purpose of such a DSS is to search web pages and find documents on a specific set of keywords or search terms. DSS Development Tools Enable the generation of Fourth generation operating systems and special purpose languages that can create DSS generators and specific DSS. 9. DSS Generator - This is a package that enables specific DSS aids to be created 10. Executive Support Systems (ESS) integrates the activities of: report generation, report preparation, inquiring capability, modeling language, graphic display commands, and financial and statistical analysis subroutines. 11. Feasibility Study To determine whether the proposed system is cost effective from a business point of view 12. Geographic Information Systems (GIS) - Software for analyzing and displaying data using digitized maps 13. Graphical User Interface (GUI) Used for interaction with users

14. Group Decision Support Systems (GDSS) - Interactive computer-based system that facilitates solution to unstructured problems 15. Information Data that is processed 16. Information System - It is a collection of hardware, software, data, people and procedures that are designed to generate information that supports the day-to-day, short-range, and long-range activities of users in an organization. 17. Knowledge Base - It is essentially used to provide management advice or to choose products/services. 18. Model-Driven DSS - Uses model to perform what-if and other kinds of analysis 19. Semi-structured Decisions - A decision process which has both elements of structured and unstructured decision process 20. Sensitivity Analysis -- Asks what-if questions repeatedly to determine the impact of change 21. Spatial DSS - SDSS has been associated with the need to expand the GISystem capabilities for tackling complex, ill-defined, spatial decision problems 22. Specific DSS - a stand alone systems connected or not connected to an organizational MIS 23. Structured Decisions - Unambiguous and operational, and are non-conflicting decisions 24. Unstructured Decisions - Ambiguous and non-operational, or relatively operational but numerous and conflicting decisions 25. Web-Based DSS - Support decision-making process of an existing or potential customer 26. What-If Analysis - Asks what-if questions repeatedly to determine the impact of change

APPENDIX B References "Supporting Decision-Makers: An Expanded Framework

"Creating an Effective Data-Driven Decision Support System", DSSResources.COM "Using a GIS as a DSS Generator", DSSResources.COM "Data, Data Everywhere", DSSResources.COM (Power (2002) Types of DSS) "Chapter 7 Building Data-Driven Decision Support Systems" (Cost-Effectiveness of a Medical Decision-Support System: A Pilot Study)

APPENDIX C Classified Bibliography

Jessani, R., "Creating an Effective Data-Driven Decision Support System", DSSResources.COM, 12/05/2003. Brobst, S. and J. Rarey, "Five Stages of Data Warehouse Decision Support Evolution", DSSResources.COM, 01/06/2003. Dunnigan, J. F., "The Operations Research Revolution Rolls On, To Where?", DSSResources.COM, 05/28/2004. Herlihy, J., "Simulation Software: A Powerful Way to Improve Organizational Decision Making", DSSResources.COM, 06/01/2002. Pendse, N., "What is OLAP?", DSSResources.COM, 04/07/2002.

APPENDIX D Conventions
We've used a number of different styles of text and layout in this document to help differentiate between the different kinds of information. Here are examples of the styles we used and an explanation of what they mean. Try It Outs How Do They Work? The word CMIS has been used throughout this proposal to mean Church Management Information System References appear in text like this.(Italicized) Bullets appear indented, with each new bullet marked as in this text Important words are in a bold type font Figures are represented by the abbreviation (fig) Code has several fonts and colors. VB.NET classes and keywords are written in blue.

APPENDIX E Current Cases in DSS

1. Databeacon Staff, "East of England Observatory adopts hosted services decision support solution", posted at DSSResources.COM May 14, 2004, Web-based, datadriven DSS. 2. Fair Isaac Staff, "Business rules drive modernization of legacy transaction systems at the California Department of Motor Vehicles", September 8, 2006Enterprise-wide decision automation. 3. Forrest, J., "The Space Shuttle Challenger Disaster: A failure in decision support system and human factors management", posted at DSSResources.COM October 7, 2005, Communications-driven DSS. 4. Huntington, D., "From Information to Answers: Transferring Expertise at the SBA", November 3, 2006, Web-based, Knowledge-driven DSS in the Public sector.

5. McCall, D. and J. Young, "Bringing Strategic Planning Online at Electrogrid", June 16, 2006, Web-based, model-driven group DSS. 6. MySQL Staff, "Cox Communications powers massive data warehouse with MySQL", March 23, 2007, Open source data-driven DSS for real-time operational support and management control. 7. Power, D., "Transforming GE Real Estate with Innovative Data-driven Decision Support", January 12, 2007 Web-based, Data-driven DSS and risk management decision support application. 8. Power, D. J. and C. L. Fletcher, "University of Northern Iowa Dining Services uses FoodPro", posted at DSSResources.COM June 3, 2005,. Integrated Information System with transaction processing and model-driven decision support subsystem. 9. SAS Staff, "Briggs & Stratton harnesses operational data", posted at DSSResources.COM December 2, 2005,. Global data-driven executive management system with scorecards. 10. Schwartz, K. D., "Decisions at the touch of a button", posted at DSSResources.COM August 19, 2005,. Information system with remote data collection, data warehouse and data-driven DSS. 11. Stellent Staff, "University of Alberta increases timely access to policies and procedures", posted at DSSResources.COM September 17, 2004,. Document-driven DSS and document management system. 12. Stevens, A., "Implementing the Redland Genstar Data Mart", posted at DSSResources.COM July 2, 2004,. Development of a data-driven DSS. 13. Stottler Henke Associates Staff, "PADAL helps US Navy aircraft land aboard carriers", posted at DSSResources.COM January 15, 2005,. Model-driven DSS prototype. 14. Tomaszewski, B., "Erie County Emergency Response and Planning Application Performs Plume Modeling", posted at DSSResources.COM March 6, 2005,. Modeldriven DSS integrated with a Geographic Information System (GIS), also called a model-driven, spatial DSS. 15. Tully, M., "E-Docs Asset GIS: Washington County, Iowa", March 6, 2006, . Webbased Spatial DSS with data and document-driven decision support subsystems.