Documentation

66
SYSTEM ANALYSIS Introduction 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. FEASIBILITY STUDY 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

Transcript of Documentation

Page 1: Documentation

SYSTEM ANALYSIS

Introduction

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.

FEASIBILITY STUDY

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

Page 2: Documentation

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 won’t be an obstacle.

OVERVIEW OF SYSTEM REQUIREMENTS

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:

Inputs

Church Member Personal Details

Member Attendance records

Member Discipline records

Member Contributions

Church Activities

Processes

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

Page 3: Documentation

Outputs

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.

Page 4: Documentation

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.

Constraints:

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:

Page 5: Documentation

Interviews

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.

Observation

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.

Page 6: Documentation

SYSTEM DESIGN AND METHODOLOGY

Introduction

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 member’s records stored in the system.

Page 7: Documentation

Figure 1: Search Flow Process

Page 8: Documentation

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

Page 9: Documentation

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

Page 10: Documentation

Workflow for the Assign task activity

Page 11: Documentation

Figure 5: Assigning a task

Entering Members Contributions

At times members will be required to be contributing some money e.g. to build a pastor’s

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 member’s contributions

Page 12: Documentation

The budget process

Figure 7: Budget process workflow

A Church Budget Proposal for 2007

INCOME EXPENSES

TITHE 720000 0

OFFERING 200000 0

OTHERS 74000 0

TOTAL 994000 0

BUILDING COMMITTEE 24000

MINISTERS SUPPORT 20000

MISSIONS SUPPORT 9500

OFFICE MAINTAINANCE 15000

MONTHLY TOTAL 68500

ANNUAL TOTAL 822,000

ANNUAL SAVINGS 172000

Page 13: Documentation

TOTAL INCOME AND EXPENDITURE

EXPECTED IN 2006 KSH 994000 822000

Table 1: Church Budget proposal for 2007

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

INCOME EXPENSES

TITHE 720000 0

OFFERING 200000 0

OTHERS 580000 0

TOTAL 1,500,000 0

BUILDING COMMITTEE 80000

MINISTERS SUPPORT 30000

MISSIONS SUPPORT 14000

OFFICE MAINTAINANCE 17000

MONTHLY TOTAL 68500

ANNUAL TOTAL 822000

ANNUAL SAVINGS 172000

TOTAL INCOME AND EXPENDITURE

EXPECTED IN 2007 KSH 994000 822000

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:

Page 14: Documentation

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.

DATABASE DESIGN

Description of CMIS Tables

Entities

Table Description

Members Details regarding Members

Contribution Stores details pertaining to Member contributions

Activities Stores details of Activities assigned to Members

Attendance Stores details regarding attendance

Discipline Store details regarding discipline of members

Services Stores details of church services

Letters Stores details for composing letters

Table 3: Description of CMIS tables

Entities and attributes

Table Fields

Members IDIndividual, First Name, L_Name, MemberNo, FamilyMember, Birthdate,

Gender, Address, City, SpecialNeed, Phone, Status, Married, Emergency,

Occupation, MovedFrom, Note

Contribution ID(Auto Number), IDIndividual, Con_Date, Amount, Category, Note

Pledges ID(Auto Number), IDIndividual, Pledge_Date, Amount, Category, Note

Activities ID(Auto Number), IDIndividual, Act_Assigned, Attendance, Comment

Attendance TotalVisitors, AttendanceDate, AttendanceActivity, AttendanceDatePosition

Services ID(Auto Number),IDIndividual, Service_Type, Date

Letters ID(Auto Number), Letter, Salutation, Body, Closing, Signature

Page 15: Documentation

Table 4: CMIS entities and attributes

INTERFACE DESIGN

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

Page 16: Documentation

Financial module

Figure 9: CMIS Financial Module

CONCLUSION

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.

Page 17: Documentation

SYSTEM IMPLEMENTATION

Introduction

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 church’s 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.

Page 18: Documentation

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 Church’s 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.

Page 19: Documentation

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

Page 20: Documentation

Implementation of Views

1. ViewMemberDetails View

Code

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

Page 21: Documentation

How the view has been used in the system

Page 22: Documentation

2. ViewMemberPledges View

Code

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

Page 23: Documentation

How the view has been used in the system

Page 24: Documentation

Database structure

Page 25: Documentation
Page 26: Documentation

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.

Page 27: Documentation

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"))

Page 28: Documentation

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 SqlParameter("@FamilyMember",

System.Data.SqlDbType.VarChar, 20, "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)

Page 29: Documentation

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

"

Page 30: Documentation

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()

Page 31: Documentation

SqlConnection1.Dispose()

SqlSelectCommand1.Dispose()

SqlDataAdapter1.Dispose()

End Sub

Page 32: Documentation
Page 33: Documentation

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.

Page 34: Documentation

SYSTEM TESTING AND EVALUATION

Introduction

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 individual’s 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

Page 35: Documentation

Search by Member Status

Figure 15: Search Criteria: By member status

Search by Member First Name or Last Name

Page 36: Documentation

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").

Page 37: Documentation

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 ChecklistYes No

N/AComments

1Does every display begin with a title or header that

describes screen contents?yes  

2Is a single, selected icon clearly visible when

surrounded by unselected icons?yes

 Active links

have a different

color

3Is there some form of system feedback for every

operator action?Yes  

4

After the user completes an action (or group of

actions), does the feedback indicate that the next group

of actions can be started?

Yes  

Page 38: Documentation

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 ChecklistYes No

N/AComments

1When a user's task is complete, does the system wait

for a signal from the user before processing?no  

2Is there an "undo" function at the level of a single

action, a data entry, and a complete group of actions?N/A  

3 Can users cancel out of operations in progress? yes  

4Can users reduce data entry time by copying and

modifying existing data?yes  

5 Are character edits allowed in data entry fields? yes  

 

Consistency and Standards

Users should not have to wonder whether different words, situations, or actions mean the

same thing. Follow platform conventions.

# Review ChecklistYes No

N/AComments

1Has a heavy use of all uppercase letters on a screen

been avoided?Yes  

Page 39: Documentation

2Are there salient visual cues to identify the active

window?N/A  

3 Does each window have a title? N/A  

4Are vertical and horizontal scrolling possible in each

window?Yes  

5If "exit" or “log of” is a menu choice, does it always

appear at the bottom of the list?yes  

6Color: up to four (additional colors for occasional use

only)yes  

7

Are attention-getting techniques used only for

exceptional conditions or for time-dependent

information?

yes e.g. to confirm

login

8Are user actions named consistently across all

prompts in the system?yes  

Help Users Recognize, Diagnose, and Recover From Errors

Error messages should be expressed in plain language (NO CODES).

# Review ChecklistYes No

N/AComments

1 Is sound used to signal an error? No  

2Are prompts stated constructively, without overt or

implied criticism of the user?Yes  

Page 40: Documentation

3 Are prompts brief and unambiguous yes  

4Are error messages worded so that the system, not the

user, takes the blame?yes  

5 Do messages place users in control of the system? yes  

6 Do error messages suggest the cause of the problem? yes  

7Do error messages provide appropriate semantic

information?yes  

8Do error messages indicate what action the user needs

to take to correct the error?Yes  

 

Error Prevention

Even better than good error messages is a careful design which prevents a problem from

occurring in the first place.

# Review ChecklistYes No

N/AComments

1If the database includes groups of data, can users

enter more than one group on a single screen?yes

 Vacancies can

be added

repeatedly

2 Are data inputs case-blind whenever possible? yes  

3If the system displays multiple windows, is navigation

between windows simple and visible?N/A  

4Do fields in data entry screens and dialog boxes

contain default values when appropriate?yes  

Page 41: Documentation

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 ChecklistYes No

N/AComments

1Does the data display start in the upper-left corner of

the screen?yes  

2Are multiword field labels placed horizontally (not

stacked vertically)?yes  

3Are all data a user needs on display at each step in a

transaction sequence?yes  

4Are prompts, cues, and messages placed where the

eye is likely to be looking on the screen?yes  

5Is there an obvious visual distinction made between

"choose one" menu and "choose many" menus?N/A  

6 Are optional data entry fields clearly marked? yes  use of ‘*”

7

Are sizes, boldface, underlining, color, shading, or

typography used to show relative quantity or

importance of different screen items?

yes  

8 Are borders used to identify meaningful groups? yes  

9Has the same color been used to group related

elements?yes  

10 Is color coding consistent throughout the system? Yes  

Page 42: Documentation

11Is there good color and brightness contrast between

image and background colors?N/A  

Privacy

The system should help the user to protect personal or private information- belonging to the

user or his/her clients.

# Review ChecklistYes No

N/AComments

1 Are protected areas completely inaccessible? yes  

2Can protected or confidential areas be accessed with

certain passwords?yes  

3 Is this feature effective and successful? yes  

Summary

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.

Page 43: Documentation

CONCLUSION

Introduction

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.

Achievements

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

Constraints

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

Page 44: Documentation

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.

Page 45: Documentation

APPENDIX

APPENDIX A

Glossary

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

Page 46: Documentation

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

Page 47: Documentation

APPENDIX B

References

http://www.umsl.edu/~sauter/DSS/book/design.html

"Supporting Decision-Makers: An Expanded Framework”

http://dssresources.com/papers/supportingdm

"Creating an Effective Data-Driven Decision Support System", DSSResources.COM

"Using a GIS as a DSS Generator", DSSResources.COM

"Data, Data Everywhere", DSSResources.COM

en.wikipedia.org/wiki/Decision_support_system (Power (2002) Types of DSS)

http://citeseer.ist.psu.edu/379410.html "Chapter 7 Building Data-Driven Decision Support

Systems"

http://www-ksl.stanford.edu/KSL_Abstracts/KSL-91-45.html (Cost-Effectiveness of a

Medical Decision-Support System: A Pilot Study)

http://www.staff.livjm.ac.uk/bsnmyoll/DSS%20definition%20Summary.doc

http://www.ait.unl.edu/siau/1997/mgmt457/lecture1.ppt

Page 48: Documentation

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.

http://www.churchcentral.com/benefitdoc.html

http://www.churchbusiness.com/ministryresources

Page 49: Documentation

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, data-

driven 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.

Page 50: Documentation

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,. Model-

driven 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, . Web-

based Spatial DSS with data and document-driven decision support subsystems.