WATER AND SANITATION SERVICES MANAGEMENT BILLING

SYSTEM

BY
LEONARD MBURU KIMOTHO
BIT-016-0007/2009

THIS PROJECT PROPOSAL IS SUBMITTED IN PARTIAL

FULFILLMENT FOR THE AWARD OF DEGREE OF BACHELOR
OF SCIENCE IN INFORMATION TECHNOLOGY OF JOMO
KENYATTA UNIVERSITY OF AGRICULTURE AND
TECHNOLOGY (JKUAT)

KAREN CAMPUS

AUGUST 2010

DECLARATION
This is my original work and has not been submitted in any other institution
of higher learning for academic or any other purpose.

.
LEONARD MBURU KIMOTHO

DATE:

The Project proposal is presented to the university for examination with the
approval of the
supervisor.

.
SAMUEL ADHOLA
JKUAT KAREN CAMPUS
NAIROBI
KENYA

DATE:

Abstract
The Water and Sanitation Services Management Billing System (WSSMBS) is
meant to provide affordable and efficient billing facilities for Water Services
Boards.
The need for this system has been brought about by the delinking of
secondary WSBs from primary WSBs, giving them the lee way to manage
their own operations.
WSSMBS is meant to enable WSBs to effectively manage their operations
and provide cheap billing services.
This can provide considerable savings for the WSBs compared to what they
used to pay to primary WSBs for printing of bills. Previously it used to cost
KShs 15.00 to print a single bill. This system will enable the preparation and
printing of bills at less than KShs 7.00 a bill thus providing a savings of KShs
8.00 per bill a saving of 54%.

Table of Contents
DECLARATION............................................................................................................. ii
Abstract..................................................................................................................... iii
Diagrams of Importance......................................................................................... vi
1

CHAPTER ONE: Introduction................................................................................. 1

1.1

Problem Statement........................................................................................ 1

1.2

Objectives...................................................................................................... 1

1.3

Justification of the Study................................................................................2

1.4

Significance of the Study............................................................................... 2

1.5

Assumptions.................................................................................................. 2

1.6

Limitations of the Study.................................................................................2

CHAPTER TWO: Literature Review........................................................................3

2.1

Management.................................................................................................. 3

2.2

Object Oriented Programming.......................................................................3

2.2.1

Overview................................................................................................. 3

2.2.2

History..................................................................................................... 5

2.2.3

Fundamental Concepts and Features.......................................................8

2.2.4

Main Features........................................................................................ 13

2.3

The .NET Framework.................................................................................... 14

2.3.1

Principal Design Features......................................................................15

2.3.2

Architecture of .NET Framework...........................................................19

CHAPTER THREE: Methodology..........................................................................24

3.1

Project Methodology.................................................................................... 24

3.1.1

Waterfall Model...................................................................................... 24

3.1.2

Spiral Model........................................................................................... 28

3.1.3

The Agile Methodology..........................................................................30

3.2

Research Methodology.................................................................................34

3.2.1

Requirement Specification.....................................................................34

3.2.2

Requirement Investigation.....................................................................34

3.2.3

Data Collection Techniques....................................................................35

3.2.4

Data Analysis......................................................................................... 37

3.2.5
4

CHAPTER FOUR: Analysis................................................................................... 38

4.1

Strengths of the Current System...........................................................38

4.1.2

Weaknesses of Current System.............................................................38

4.1.3

Flow Chart of the Current System..........................................................39

Proposed System......................................................................................... 39

4.2.1

Strengths of the Proposed System.........................................................40

4.2.2

Weaknesses of the Proposed System....................................................40

4.2.3

Flowcharts of the Proposed System.......................................................41

CHAPTER FIVE: Design....................................................................................... 42

5.1

Architectural Design.................................................................................... 42

5.1.1

Definition............................................................................................... 42

5.1.2

The Unified Modeling Language (UML)..................................................42

5.2

Database Design.......................................................................................... 47

5.2.1

Normalization........................................................................................ 48

5.2.2

Tables used in the System Database.....................................................54

5.2.3

Entity Relationship Diagram..................................................................60

5.3

Current System............................................................................................ 38

4.1.1

4.2

Data Presentation..................................................................................37

Interface Design........................................................................................... 60

5.3.1

Bad Interface design..............................................................................61

5.3.2

Good Interface design...........................................................................61

5.3.3

Proposed Interface design.....................................................................62

CHAPTER SIX: Implementation & Testing............................................................64

6.1

Implementation............................................................................................ 64

6.2

Coding.......................................................................................................... 64

6.3

Screenshots of the system...........................................................................65

6.4

System testing............................................................................................. 70

6.4.1

The Testing Process...............................................................................71

6.4.2

Phases of System Testing......................................................................71

6.4.3

The Testing Strategy.............................................................................. 77

6.4.4

Test Data................................................................................................ 78

6.4.5

Testing Schedule....................................................................................79

6.5

Implementation Strategy............................................................................. 79

6.5.1

Phased Changeover............................................................................... 79

6.5.2

Pilot Changeover................................................................................... 80

6.5.3

Parallel Changeover...............................................................................80

6.5.4

Direct Changeover................................................................................. 80

6.5.5

Chosen Strategy.................................................................................... 81

6.5.6

Major Tasks in Implementation..............................................................81

6.5.7

Error Handling........................................................................................ 82

6.6

Conclusion................................................................................................... 84

References................................................................................................................ 87
Appendix.................................................................................................................. 90
Budget................................................................................................................... 90
GANTT chart.......................................................................................................... 90

Diagrams of Importance
Figure 1: Visual overview of the Common Language Infrastructure.........................17
Figure 2: The .NET Framework stack.........................................................................18
Figure 3: The Waterfall Model...................................................................................25
Figure 4: The Spiral Model........................................................................................ 28
Figure 5: Flowchart of the Current system................................................................39
Figure 6: Flowchart of the proposed system.............................................................41
Figure 7: WSMS Use Case Diagram...........................................................................44
Figure 8: WSMS Activity Diagram............................................................................. 45
Figure 9: WSMS Class Diagram................................................................................. 46
Figure 10: WSMS Sequence Diagram........................................................................47
Figure 11: WSMS Database Model............................................................................60
Figure 12: Login form for the Water Services Management System.........................65
Figure 13: The Water & Sanitation Services Billing System Main Window................65
Figure 14: The Customer Information Management Module window........................66
Figure 15: : Consumption Information Management Module....................................67
Figure 16: The Billing Management Module..............................................................67
Figure 17: Sample Bill generated by the Water and Sanitation Services system......68
Figure 18: Installation Services Management Module...............................................69

Figure 19: Meter Inventory Management Module.....................................................69

Figure 20: Payments Management Module...............................................................70
Figure 21: The WSMS Login window ready to receive login information...................72
Figure 22: Dialog displayed after an invalid login.....................................................73
Figure 23: The WSMS after a successful login..........................................................74
Figure 24: The Customer Management module displaying 939 records generated
using a data generation tool.....................................................................................75

1 CHAPTER ONE: Introduction

Gatundu South Water & Sanitation Company Limited (GSWSCL) is a Water
and Sanitation Services firm dealing exclusively with the Gatundu South
region of Kiambu. Currently, the company possesses a few computers
which are used in the collection of consumption data from customers.
The data is then formatted and delivered to the Athi Water Services
(AWS) for the preparation and printing of bills. GSWSCL has over 15,000
customers and it costs KShs 15.00 to prepare and print a single bill
therefore the company spends a minimum of KShs 225,000.00 a month
on bills alone. This has been found to be too expensive for the company
and there has now been a feeling that this cannot be sustained in the
long run resulting in the need to find a cheaper alternative.

1.1 Problem Statement

Gatundu South Water and Sanitation Company Limited (GSWSCL) has
for a long time been using Athi Water Services for its water billing
services. This has resulted in high costs associated with preparing and
printing water bills for its customers at 15 KShs/bill. Recently Gatundu
South

Water

and

Sanitation

Company

Limited

have

received

authorization to seek its own printing services at any agreed price.

1.2 Objectives

To design and deliver a system that enables preparation and printing of bills

at a cost less than 7 shillings.

To design and deliver a system which enables the firm to maintain an

inventory of their installed gadgets.

To design a system that enables tracking of customers and their usage of
services.

1.3 Justification of the Study

This project is being undertaken in order to be able to design and
implement a software system that will enable WSB to manage their
operations especially the preparation and printing bills at a cost
significantly lower than what they used to pay previously.

1.4 Significance of the Study

The implementation of this project is meant to provide a reprieve to
WSBs by providing them with an efficient and affordable system to
manage their operations especially preparation and printing of bills.

1.5 Assumptions
Some of the assumptions made in the study are:

That staff at the WSB have been exposed to computers and basic

operations.
That WSB already owns a number of computer systems.

1.6 Limitations of the Study

This study encountered a number of limitations. These include:
2

Reluctance by some staff key staff to be interviewed.

Limited funds to finance the study especially commuting to the WSB to
establish requirements.

2 CHAPTER TWO: Literature Review

2.1 Management
This is the process of getting activities completed efficiently and effectively
with and through other people. It focuses on the entire organization from
both a short and long term perspective. Management from another
perspective can be said to be managerial process of forming a strategic
vision setting objectives, crafting a strategy and then implementing and
executing the strategy. Development of this system is possible in regard to
paperwork they do today of which will be transferred into an automated
system that will be more accurate, easy to manage records and increase
operations and efficiency.

2.2 Object Oriented Programming

Object-oriented programming (OOP) is a programming paradigm that uses
"objects" data structures consisting of data fields and methods together
with their interactions to design applications and computer programs.
Programming techniques may include features such as information hiding,
data abstraction, encapsulation, modularity, polymorphism, and inheritance.
It was not commonly used in mainstream software application development
until the early 1990s.

2.2.1 Overview

Object-oriented programming has roots that can be traced to the 1960s. As

hardware and software became increasingly complex, quality was often
compromised. Researchers studied ways to maintain software quality and
developed

object-oriented

programming

in

part

to

address

common

problems by strongly emphasizing discrete, reusable units of programming

logic. The methodology focuses on data rather than processes, with
programs composed of self-sufficient modules (objects) each containing all
the information needed to manipulate its own data structure. This is in
contrast to the existing modular programming which had been dominant for
many years that focused on the function of a module, rather than specifically
the data, but equally provided for code reuse, and self-sufficient reusable
units of programming logic, enabling collaboration through the use of linked
modules (subroutines). This more conventional approach, which still persists,
tends to consider data and behavior separately.
An object-oriented program may thus be viewed as a collection of interacting
objects, as opposed to the conventional model, in which a program is seen as
a list of tasks (subroutines) to perform. In OOP, each object is capable of
receiving messages, processing data, and sending messages to other objects
and can be viewed as an independent 'machine' with a distinct role or
responsibility. The actions (or "operators") on these objects are closely
associated with the object. For example, the data structures tend to 'carry

their own operators around with them' (or at least "inherit" them from a
similar object or class).
The Simula programming language was the first to introduce the concepts
underlying object-oriented programming (objects, classes, subclasses, virtual
methods, co routines, and discrete event simulation) as a superset of Algol.
Simula also used automatic garbage collection which had been invented
earlier for the functional programming language Lisp. Simula was used for
physical modeling, such as models to study and improve the movement of
ships and their content through cargo ports. Smalltalk was the first
programming language to be called "object-oriented".
2.2.2 History

The concept of objects and instances in computing had its first major
breakthrough with the PDP-1 system at MIT which was probably the earliest
example of 'capability based' architecture. Another early example was
Sketchpad created by Ivan Sutherland in 1963; however, this was an
application and not a programming paradigm. Objects as programming
entities were introduced in the 1960s in Simula 67, a programming language
designed for performing simulations, created by Ole-Johan Dahl and Kristen
Nygaard of the Norwegian Computing Center in Oslo. (They were working on
ship simulations, and were confounded by the combinatorial explosion of
how the different attributes from different ships could affect one another. The
idea occurred to them of grouping the different types of ships into different

classes of objects; each class of objects being responsible for defining its
own data and behavior.) Such an approach was a simple extrapolation of
concepts earlier used in analog programming. On analog computers,
mapping from real-world phenomena/objects, to analog phenomena/objects
(and conversely), was (and is) called 'simulation'. Simula not only introduced
the notion of classes, but also of instances of classes, which is probably the
first explicit use of those notions. The ideas of Simula 67 influenced many
later languages, especially Smalltalk and derivatives of Lisp and Pascal.
The Smalltalk language, which was developed at Xerox PARC (by Alan Kay
and others) in the 1970s, introduced the term object-oriented programming
to represent the pervasive use of objects and messages as the basis for
computation. Smalltalk creators were influenced by the ideas introduced in
Simula 67, but Smalltalk was designed to be a fully dynamic system in which
classes could be created and modified dynamically rather than statically as
in Simula 67. Smalltalk and with it OOP were introduced to a wider audience
by the August 1981 issue of Byte magazine.
In the 1970s, Kay's Smalltalk work had influenced the Lisp community to
incorporate object-based techniques which were introduced to developers
via the Lisp machine. Experimentation with various extensions to Lisp (like
LOOPS and Flavors introducing multiple inheritance and mixins), eventually
led to the Common Lisp Object System (CLOS, a part of the first standardized
object-oriented

programming

language,

ANSI

Common

Lisp),

which

integrates functional programming and object-oriented programming and

allows extension via a Meta-object protocol. In the 1980s, there were a few
attempts to design processor architectures which included hardware support
for objects in memory but these were not successful. Examples include the
Intel iAPX 432 and the Linn Smart Rekursiv.
Object-oriented programming developed as the dominant programming
methodology during the mid-1990s, largely due to the influence of C++. Its
dominance was further enhanced by the rising popularity of graphical user
interfaces, for which object-oriented programming seems to be well-suited.
An example of a closely related dynamic GUI library and OOP language can
be found in the Cocoa frameworks on Mac OS X, written in Objective-C, an
object-oriented, dynamic messaging extension to C based on Smalltalk. OOP
toolkits also enhanced the popularity of event-driven programming (although
this concept is not limited to OOP). Some feel that association with GUIs (real
or perceived) was what propelled OOP into the programming mainstream.
At ETH Zrich, Niklaus Wirth and his colleagues had also been investigating
such topics as data abstraction and modular programming. Modula-2
included both, and their succeeding design, Oberon, included a distinctive
approach to object orientation, classes, and such. The approach is unlike
Smalltalk, and very unlike C++.
Object-oriented features have been added to many existing languages
during that time, including Ada, BASIC, Fortran, Pascal, and others. Adding
8

these features to languages that were not initially designed for them often
led to problems with compatibility and maintainability of code.
More recently, a number of languages have emerged that are primarily
object-oriented yet compatible with procedural methodology, such as Python
and Ruby. Probably the most commercially important recent object-oriented
languages are Visual Basic .NET (VB.NET) and C#, both designed for
Microsoft's .NET platform, and Java, developed by Sun Microsystems. VB.NET
and C# both support cross-language inheritance, allowing classes defined in
one language to subclass classes defined in the other language.
Just as procedural programming led to refinements of techniques such as
structured programming, modern object-oriented software design methods
include refinements such as the use of design patterns, design by contract,
and modeling languages (such as UML).
The term OOPS, which refers to an object-oriented programming system, was
common in early development of object-oriented programming.
2.2.3 Fundamental Concepts and Features

A survey by Deborah J. Armstrong of nearly 40 years of computing literature

identified a number of "quarks", or fundamental concepts, found in the
strong majority of definitions of OOP. They are the following:

2.2.3.1Class

Defines the abstract characteristics of a thing (object), including the thing's

characteristics (its attributes, fields or properties) and the thing's behaviors
(the things it can do, or methods, operations or features). One might say that
a class is a blueprint or factory that describes the nature of something. For
example, the class Dog would consist of traits shared by all Dogs, such as
breed and fur color (characteristics), and the ability to bark and sit
(behaviors). Classes provide modularity and structure in an object-oriented
computer program. A class should typically be recognizable to a nonprogrammer

familiar

with

the

problem

domain,

meaning

that

the

characteristics of the class should make sense in context. Also, the code for a
class should be relatively self-contained (generally using encapsulation).
Collectively, the properties and methods defined by a class are called
members.
2.2.3.2Object

A pattern (exemplar) of a class. The class of Dog defines all possible Dogs by
listing the characteristics and behaviors they can have; the object Lassie is
one particular Dog, with particular versions of the characteristics. A Dog has
fur; Lassie has brown-and-white fur.
2.2.3.3Instance

One can have an instance of a class or a particular object. The instance is the
actual object created at runtime. In programmer jargon, the Lassie object is

10

an instance of the Dog class. The set of values of the attributes of a

particular object is called its state. The object consists of state and the
behavior that's defined in the object's class.
2.2.3.4Method

An object's abilities, In language, methods (sometimes referred to as

"functions") are verbs. Lassie, being a Dog, has the ability to bark. So bark()
is one of Lassie's methods. She may have other methods as well, for
example sit() or eat() or walk() or save_Timmy(). Within the program, using a
method usually affects only one particular object; all Dogs can bark, but you
need only one particular Dog to do the barking.
2.2.3.5Message Passing

"The process by which an object sends data to another object or asks the
other object to invoke a method". Also known to some programming
languages as interfacing. For example, the object called Breeder may tell the
Lassie object to sit by passing a "sit" message which invokes Lassie's "sit"
method. The syntax varies between languages, for example: [Lassie sit] in
Objective-C. In Java, code-level message passing corresponds to "method
calling". Some dynamic languages use double-dispatch or multi-dispatch to
find and pass messages.
2.2.3.6Inheritance

"Subclasses" are more specialized versions of a class, which inherit attributes

and behaviors from their parent classes, and can introduce their own. For
11

example, the class Dog might have sub-classes called Collie, Chihuahua, and
GoldenRetriever. In this case, Lassie would be an instance of the Collie
subclass. Suppose the Dog class defines a method called bark() and a
property called furColor. Each of its sub-classes (Collie, Chihuahua, and
GoldenRetriever) will inherit these members, meaning that the programmer
only needs to write the code for them once.
Each subclass can alter its inherited traits. For example, the Collie class
might specify that the default furColor for a Collie is brown-and-white. The
Chihuahua subclass might specify that the bark() method produces a high
pitch by default. Subclasses can also add new members. The Chihuahua
subclass could add a method called tremble(). So an individual Chihuahua
instance would use a high-pitched bark() from the Chihuahua subclass, which
in turn inherited the usual bark() from Dog. The Chihuahua object would also
have the tremble() method, but Lassie would not, because she is a Collie, not
a Chihuahua. In fact, inheritance is an "a... is a" relationship between
classes, while instantiation is an "is a" relationship between an object and a
class: a Collie is a Dog ("a... is a"), but Lassie is a Collie ("is a"). Thus, the
object named Lassie has the methods from both classes Collie and Dog.
Multiple inheritance is inheritance from more than one ancestor class,
neither of these ancestors being an ancestor of the other. For example,
independent classes could define Dogs and Cats, and a Chimera object could
be created from these two which inherits all the (multiple) behavior of cats

12

and Dogs. This is not always supported, as it can be hard both to implement
and to use well.
2.2.3.7Abstraction

Abstraction is simplifying complex reality by modeling classes appropriate to

the problem, and working at the most appropriate level of inheritance for a
given aspect of the problem. For example, Lassie the Dog may be treated as
a Dog much of the time, a Collie when necessary to access Collie-specific
attributes or behaviors, and as an Animal (perhaps the parent class of Dog)
when counting Timmy's pets.
Abstraction is also achieved through Composition. For example, a class Car
would be made up of an Engine, Gearbox, Steering objects, and many more
components. To build the Car class, one does not need to know how the
different components work internally, but only how to interface with them,
i.e., send messages to them, receive messages from them, and perhaps
make the different objects composing the class interact with each other.
2.2.3.8Encapsulation

Encapsulation conceals the functional details of a class from objects that

send messages to it. For example, the Dog class has a bark() method. The
code for the bark() method defines exactly how a bark happens (e.g., by
inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie's
friend,

however,

does

not

need

to

know

exactly

how

she

barks.

Encapsulation is achieved by specifying which classes may use the members

13

of an object. The result is that each object exposes to any class a certain
interface those members accessible to that class. The reason for
encapsulation is to prevent clients of an interface from depending on those
parts of the implementation that are likely to change in the future, thereby
allowing those changes to be made more easily, that is, without changes to
clients. For example, an interface can ensure that puppies can only be added
to an object of the class Dog by code in that class. Members are often
specified as public, protected or private, determining whether they are
available to all classes, sub-classes or only the defining class. Some
languages go further: Java uses the default access modifier to restrict access
also to classes in the same package, C# and VB.NET reserve some members
to classes in the same assembly using keywords internal (C#) or Friend
(VB.NET), and Eiffel and C++ allow one to specify which classes may access
any member.
2.2.3.9(Subtype) polymorphism

Polymorphism allows the programmer to treat derived class members just

like their parent class' members. More precisely, Polymorphism in objectoriented programming is the ability of objects belonging to different data
types to respond to method calls of methods of the same name, each one
according to an appropriate type-specific behavior. One method, or an
operator such as +, -, or *, can be abstractly applied in many different
situations. If a Dog is commanded to speak(), this may elicit a bark().
However, if a Pig is commanded to speak(), this may elicit an oink(). They
14

both inherit speak() from Animal, but their derived class methods override
the methods

of the

parent

class;

this is

Overriding Polymorphism.

Overloading Polymorphism is the use of one method signature, or one

operator such as "+", to perform several different functions depending on
the implementation. The "+" operator, for example, may be used to perform
integer addition, float addition, list concatenation, or string concatenation.
Any two subclasses of Number, such as Integer and Double, are expected to
add together properly in an OOP language. The language must therefore
overload the addition operator, "+", to work this way. This helps improve
code readability. How this is implemented varies from language to language,
but most OOP languages support at least some level of overloading
polymorphism. Many OOP languages also support parametric polymorphism,
where code is written without mention of any specific type and thus can be
used transparently with any number of new types. Pointers are an example
of a simple polymorphic routine that can be used with many different types
of objects.
2.2.3.10

Decoupling

Decoupling allows for the separation of object interactions from classes and
inheritance into distinct layers of abstraction. A common use of decoupling is
to polymorphically decouple the encapsulation, which is the practice of using
reusable code to prevent discrete code modules from interacting with each
other. However, in practice decoupling often involves trade-offs with regard

15

to which patterns of change to favor. The science of measuring these tradeoffs in respect to actual change in an objective way is still in its infancy.
Not all of the above concepts are to be found in all object-oriented
programming languages, and so object-oriented programming that uses
classes

is

called

sometimes

class-based

programming.

In

particular,

prototype-based programming does not typically use classes. As a result, a

significantly different yet analogous terminology is used to define the
concepts of object and instance.
2.2.4 Main Features

The attempt to distill OOP to a minimal set of features is considered futile by

programming language researcher Benjamin Cuire Pierce. Nevertheless, he
identifies the following as fundamental features that are found in most
object-oriented

languages

and

that,

in

concert,

support

the

OOP

programming style:

Dynamic dispatch: when a method is invoked on an object, the object itself

determines what code gets executed by looking up the method at run time in
a table associated with the object. This feature distinguishes an object from
an abstract data type (or module), which has a fixed (static) implementation
of the operations for all instances. It is a programming methodology that
gives modular component development while at the same time being very

efficient.
Encapsulation: or multi-methods, in which case the state is kept separate.
Subtype polymorphism
Object Inheritance (or delegation)
16

Open recursion: a special variable (syntactically it may be a keyword),

usually called this or self, that allows a method body to invoke another
method body of the same object. This variable is late-bound; it allows a
method defined in one class to invoke another method that is defined later, in
some subclass thereof.

Similarly, in his 2003 book, Concepts in programming languages, John C.

Mitchell identifies four main features: dynamic dispatch, abstraction, subtype
polymorphism, and inheritance. Michael Lee Scott in Programming Language
Pragmatics considers only encapsulation, inheritance and dynamic dispatch.

2.3 The .NET Framework

The Microsoft .NET Framework is a software framework that can be installed
on computers running Microsoft Windows operating systems. It includes a
large library of coded solutions to common programming problems and a
virtual machine that manages the execution of programs written specifically
for the framework. The .NET Framework is a Microsoft offering and is
intended to be used by most new applications created for the Windows
platform.
The framework's Base Class Library provides a large range of features
including user interface, data and data access, database connectivity,
cryptography, web application development, numeric algorithms, and
network communications. The class library is used by programmers, who
combine it with their own code to produce applications.

17

Programs written for the .NET Framework execute in a software environment

that manages the program's runtime requirements. Also part of the .NET
Framework, this runtime environment is known as the Common Language
Runtime (CLR). The CLR provides the appearance of an application virtual
machine so that programmers need not consider the capabilities of the
specific CPU that will execute the program. The CLR also provides other
important services such as security, memory management, and exception
handling. The class library and the CLR together constitute the .NET
Framework.
Version 3.0 of the .NET Framework is included with Windows Server 2008 and
Windows Vista. The current version of the framework can also be installed on
Windows XP and the Windows Server 2003 family of operating systems. A
reduced version of the .NET Framework, the .NET Compact Framework, is
also available on Windows Mobile platforms, including smartphones. Version
4.0 of the framework was released as a public Beta on 20 May 2009.
2.3.1 Principal Design Features
2.3.1.1Interoperability

Because interaction between new and older applications is commonly

required, the .NET Framework provides means to access functionality that is
implemented in programs that execute outside the .NET environment. Access
to COM components is provided in the System.Runtime.InteropServices and
System.EnterpriseServices namespaces of the framework; access to other
functionality is provided using the P/Invoke feature.
18

2.3.1.2Common Runtime Engine

The Common Language Runtime (CLR) is the virtual machine component of

the .NET framework. All .NET programs execute under the supervision of the
CLR, guaranteeing certain properties and behaviors in the areas of memory
management, security, and exception handling.
2.3.1.3Language Independence

The .NET Framework introduces a Common Type System, or CTS. The CTS
specification defines all possible datatypes and programming constructs
supported by the CLR and how they may or may not interact with each other.
Because of this feature, the .NET Framework supports the exchange of
instances of types between programs written in any of the .NET languages.
This is discussed in more detail in Microsoft .NET Languages.
2.3.1.4Base Class Library

The Base Class Library (BCL), part of the Framework Class Library (FCL), is a
library of functionality available to all languages using the .NET Framework.
The BCL provides classes which encapsulate a number of common functions,
including file reading and writing, graphic rendering, database interaction
and XML document manipulation.
2.3.1.5Simplified Deployment

The .NET framework includes design features and tools that help manage the
installation of computer software to ensure that it does not interfere with
previously installed software, and that it conforms to security requirements.
19

2.3.1.6Security

The design is meant to address some of the vulnerabilities, such as buffer

overflows, that have been exploited by malicious software. Additionally, .NET
provides a common security model for all applications.

Figure 1: Visual overview of the Common Language Infrastructure.

2.3.1.7Portability

The design of the .NET Framework allows it to theoretically be platform

agnostic, and thus cross-platform compatible. That is, a program written to
use the framework should run without change on any type of system for
which

the

framework

is

implemented.

Microsoft's

commercial
20

implementations of the framework cover Windows, Windows CE, and the

Xbox 360. In addition, Microsoft submits the specifications for the Common
Language Infrastructure (which includes the core class libraries, Common
Type System, and the Common Intermediate Language), the C# language,
and the C++/CLI language to both ECMA and the ISO, making them available
as open standards. This makes it possible for third parties to create
compatible implementations of the framework and its languages on other
platforms.

Figure 2: The .NET Framework stack.

21

2.3.2 Architecture of .NET Framework

2.3.2.1Common Language Infrastructure (CLI)

The purpose of the Common Language Infrastructure, or CLI, is to provide a

language-neutral platform for application development and execution,
including functions for exception handling, garbage collection, security, and
interoperability. By implementing the core aspects of the .NET Framework
within the scope of the CLI, this functionality will not be tied to a single
language but will be available across the many languages supported by the
framework. Microsoft's implementation of the CLI is called the Common
Language Runtime, or CLR.
2.3.2.2Assemblies

The CIL code is housed in .NET assemblies. As mandated by specification,

assemblies are stored in the Portable Executable (PE) format, common on the
Windows platform for all DLL and EXE files. The assembly consists of one or
more files, one of which must contain the manifest, which has the metadata
for the assembly. The complete name of an assembly (not to be confused
with the filename on disk) contains its simple text name, version number,
culture, and public key token. The public key token is a unique hash
generated when the assembly is compiled, thus two assemblies with the
same public key token are guaranteed to be identical from the point of view
of the framework. A private key can also be specified known only to the
creator of the assembly and can be used for strong naming and to guarantee
that the assembly is from the same author when a new version of the
22

assembly is compiled (required to add an assembly to the Global Assembly

Cache).
2.3.2.3Metadata

All CIL is self-describing through .NET metadata. The CLR checks the
metadata to ensure that the correct method is called. Metadata is usually
generated by language compilers but developers can create their own
metadata through custom attributes. Metadata contains information about
the assembly, and is also used to implement the reflective programming
capabilities of .NET Framework.
2.3.2.4Security

.NET has its own security mechanism with two general features: Code Access
Security (CAS), and validation and verification. Code Access Security is based
on evidence that is associated with a specific assembly. Typically the
evidence is the source of the assembly (whether it is installed on the local
machine or has been downloaded from the intranet or Internet). Code Access
Security uses evidence to determine the permissions granted to the code.
Other code can demand that calling code is granted a specified permission.
The demand causes the CLR to perform a call stack walk: every assembly of
each method in the call stack is checked for the required permission; if any
assembly is not granted the permission a security exception is thrown.
When an assembly is loaded the CLR performs various tests. Two such tests
are validation and verification. During validation the CLR checks that the
23

assembly contains valid metadata and CIL, and whether the internal tables
are correct. Verification is not so exact. The verification mechanism checks to
see if the code does anything that is 'unsafe'. The algorithm used is quite
conservative; hence occasionally code that is 'safe' does not pass. Unsafe
code will only be executed if the assembly has the 'skip verification'
permission, which generally means code that is installed on the local
machine.
.NET Framework uses appdomains as a mechanism for isolating code running
in a process. Appdomains can be created and code loaded into or unloaded
from them independent of other appdomains. This helps increase the fault
tolerance of the application, as faults or crashes in one appdomain do not
affect

rest

of

the

application.

Appdomains

can

also

be

configured

independently with different security privileges. This can help increase the
security of the application by isolating potentially unsafe code. The
developer, however, has to split the application into subdomains; it is not
done by the CLR.
2.3.2.5Class Library

The .NET Framework includes a set of standard class libraries. The class
library is organized in a hierarchy of namespaces. Most of the built in APIs
are part of either System.* or Microsoft.* namespaces. These class libraries
implement a large number of common functions, such as file reading and
writing, graphic rendering, database interaction, and XML document

24

manipulation, among others. The .NET class libraries are available to all .NET
languages. The .NET Framework class library is divided into two parts: the
Base Class Library and the Framework Class Library.
The Base Class Library (BCL) includes a small subset of the entire class
library and is the core set of classes that serve as the basic API of the
Common Language Runtime. The classes in mscorlib.dll and some of the
classes in System.dll and System.core.dll are considered to be a part of the
BCL. The BCL classes are available in both .NET Framework as well as its
alternative implementations including .NET Compact Framework, Microsoft
Silverlight and Mono.
The Framework Class Library (FCL) is a superset of the BCL classes and
refers to the entire class library that ships with .NET Framework. It includes
an expanded set of libraries, including WinForms, ADO.NET, ASP.NET,
Language Integrated Query, Windows Presentation Foundation, Windows
Communication Foundation among others. The FCL is much larger in scope
than standard libraries for languages like C++, and comparable in scope to
the standard libraries of Java.
2.3.2.6Memory Management

The .NET Framework CLR frees the developer from the burden of managing
memory (allocating and freeing up when done); instead it does the memory
management itself. To this end, the memory allocated to instantiations of
.NET types (objects) is done contiguously from the managed heap, a pool of
25

memory managed by the CLR. As long as there exists a reference to an

object, which might be either a direct reference to an object or via a graph of
objects, the object is considered to be in use by the CLR. When there is no
reference to an object, and it cannot be reached or used, it becomes
garbage. However, it still holds on to the memory allocated to it. .NET
Framework includes a garbage collector which runs periodically, on a
separate thread from the application's thread, that enumerates all the
unusable objects and reclaims the memory allocated to them.
The .NET Garbage Collector (GC) is a non-deterministic, compacting, markand-sweep garbage collector. The GC runs only when a certain amount of
memory has been used or there is enough pressure for memory on the
system. Since it is not guaranteed when the conditions to reclaim memory
are reached, the GC runs are non-deterministic. Each .NET application has a
set of roots, which are pointers to objects on the managed heap (managed
objects). These include references to static objects and objects defined as
local variables or method parameters currently in scope, as well as objects
referred to by CPU registers. When the GC runs, it pauses the application,
and for each object referred to in the root, it recursively enumerates all the
objects reachable from the root objects and marks them as reachable. It uses
.NET metadata and reflection to discover the objects encapsulated by an
object, and then recursively walk them. It then enumerates all the objects on
the heap (which were initially allocated contiguously) using reflection. All
objects not marked as reachable are garbage. This is the mark phase. Since
26

the memory held by garbage is not of any consequence, it is considered free

space. However, this leaves chunks of free space between objects which
were initially contiguous. The objects are then compacted together, by using
memcpy to copy them over to the free space to make them contiguous
again. Any reference to an object invalidated by moving the object is
updated to reflect the new location by the GC. The application is resumed
after the garbage collection is over.
The GC used by .NET Framework is actually generational. Objects are
assigned a generation; newly created objects belong to Generation 0. The
objects that survive a garbage collection are tagged as Generation 1, and the
Generation 1 objects that survive another collection are Generation 2
objects. The .NET Framework uses up to Generation 2 objects. Higher
generation objects are garbage collected less frequently than lower
generation objects. This helps increase the efficiency of garbage collection,
as older objects tend to have a larger lifetime than newer objects. Thus, by
removing older (and thus more likely to survive a collection) objects from the
scope of a collection run, fewer objects need to be checked and compacted.

27

3 CHAPTER THREE: Methodology

A methodology is a framework that is used to structure, plan, and control the
process of developing an information system - this includes the pre-definition
of specific deliverables and artifacts that are created and completed by a
project team to develop or maintain an application.
A wide variety of such frameworks have evolved over the years, each with its
own recognized strengths and weaknesses. One software development
methodology framework is not necessarily suitable for use by all projects.
Each of the available methodology frameworks are best suited to specific
kinds of projects, based on various technical, organizational, project and
team considerations.

3.1 Project Methodology

The three basic approaches applied to software development methodology
frameworks are:
1. Waterfall Model
2. Spiral Model
3. Agile Model
3.1.1 Waterfall Model

The waterfall approach is a sequential development approach, 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
28

waterfall approach 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.
Basic principles of the waterfall approach are:

Project is divided into sequential phases, with some overlap and

splashback acceptable between phases.

Emphasis is on planning, time schedules, target dates, budgets and

implementation of an entire system at one time.

Tight control is maintained over the life of the project through the use
of extensive written documentation, as well as through formal reviews
and

approval/signoff

by

the

user

and

information

technology

management occurring at the end of most phases before beginning the

next phase.

Figure 3: The Waterfall Model.

29

a) Requirement Analysis & Definition: All possible requirements of

the system to be developed are captured in this phase. Requirements
are set of functionalities and constraints that the end-user (who will be
using the system) expects from the system. The requirements are
gathered from the end-user by consultation, these requirements are
analyzed for their validity and the possibility of incorporating the
requirements in the system to be development is also studied. Finally,
a Requirement Specification document is created which serves the
purpose of guideline for the next phase of the model.
b) System & Software Design: Before starting the actual coding, it is
highly recommended to understand what we are going to create and
what it should look like. The requirement specifications from the first
phase are studied in this phase and system design commences.
System Design helps in specifying hardware and system requirements
and also helps in defining overall system architecture. The system
design specifications serve as input for the next phase of the model.
c) Implementation & Unit Testing: On receiving system design
documents, the work is divided in modules/units and actual coding is
started. The system is first developed in small programs called units,
which are integrated in the next phase. Each unit is developed and
tested for its functionality; this is referred to as Unit Testing. Unit
testing mainly verifies if the modules/units meet their specifications.
d) Integration & System Testing: The units are integrated into a
complete system during Integration phase and tested to check if all
modules/units coordinate with each other, and the system behaves as
30

per the specifications. After successfully testing the software, it is

delivered to the customer.

e) Operations

&

Maintenance:

This

phase

is

virtually

endless.

Generally, problems with the system (which were not found during the
development life cycle) show up after its practical use begins, so the
issues related to the system are solved after deployment of the
system. Not all the problems show up immediately but some show up
with time and measures have to be taken to solve; hence this process
is referred as Maintenance.
3.1.1.1Advantages of Waterfall Life Cycle Models

a)
b)
c)
d)

Easy to explain to the user.

Stages and activities are well defined.
Helps to plan and schedule the project.
Verification at each stage ensures early detection of errors /
misunderstanding.

3.1.1.2Disadvantages of Waterfall Life Cycle Models

a) Not all requirements are received at once, the requirements from a

client may continure to change even after the end of "Requirement
Gathering and Analysis" phase, this affects the system development
process and its success in negative aspects.
b) The problems with one phase are never solved completely during that
phase and in fact many problems regarding a particular phase arise
after the phase is signed off, this result in badly structured system as
31

not all the problems (related to a phase) are solved during the same
phase.
c) The project is not partitioned in phases in flexible way.
d) As the requirements of the customer goes on getting added to the list,
not all the requirements are fulfilled, this results in development of
almost unusable system. These requirements are then met in newer
version of the system; this increases the cost of system development.

32

3.1.2 Spiral Model

33

The spiral model is a software development process combining which

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

34

and

complicated

projects.

35

Figure 4: The Spiral Model.

3.1.2.1Steps in the Spiral Model

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

a) 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.
b) 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
36

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.
c) 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.
d) A second prototype is evolved by a fourfold procedure:
i)
Evaluating the first prototype in terms of its strengths,
ii)
iii)
iv)

weaknesses, and risks.

Defining the requirements of the second prototype.
Planning and designing the second prototype.
Constructing and testing the second prototype.

3.1.2.2Advantages of the Spiral Model

a) The spiral model is a realistic approach to the development of largescale software products because the software evolves as the process
progresses. In addition, the developer and the client better understand
and react to risks at each evolutionary level.
b) The model uses prototyping as a risk reduction mechanism and allows
for the development of prototypes at any stage of the evolutionary
development.
c) It maintains a systematic stepwise approach, like the classic life cycle
model, but incorporates it into an iterative framework that more reflect
the real world.
37

d) If employed correctly, this model should reduce risks before they

become problematic, as consideration of technical risks are considered
at all stages
3.1.2.3Disadvantages of the Spiral Model

a) Demands considerable risk-assessment expertise.

b) It has not been employed as other much proven models (e.g. the WF
model) and hence may prove difficult to sell to the client (esp. where
a contract is involved) that this model is controllable and efficient.
3.1.3 The Agile Methodology

It refers to a group of software development methodologies based on

iterative development, where requirements and solutions evolve through
collaboration between self-organizing cross-functional teams. The term
was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management
process that encourages frequent inspection and adaptation, a leadership
philosophy

that

encourages

teamwork,

self-organization

and

accountability, a set of engineering best practices that allow for rapid

delivery of high-quality software, and a business approach that aligns
development with customer needs and company goals. Conceptual
foundations of this framework are found in modern approaches to
operations management and analysis, such as:

Lean manufacturing.
Soft systems methodology.
38

Speech act theory (network of conversations approach)

Six sigma.

3.1.3.1 The Agile Manifesto

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items
on the left more.
3.1.3.2Principles behind the Agile Manifesto:

Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile
processes

harness

change

for

the

customer's

competitive

advantage.
Deliver working software frequently, from a couple of weeks to a

couple of months, with a preference to the shorter timescale.

Business people and developers must work together

throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need, and trust them

to get the job done.

The most efficient and effective method of conveying information

to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a

daily

constant pace indefinitely.

39

Continuous attention to technical excellence and good design

enhances agility.
Simplicity--the art of maximizing the amount of work not done--is

essential.
The best architectures, requirements, and designs emerge from

self-organizing teams.
At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

This is the preferred model to build the system. The decision is guided
by:
a) Agile methods, produce completely developed and tested
features (but a very small subset of the whole) every few weeks.
The emphasis is on obtaining the smallest workable piece of
functionality to deliver business value early and continually
improving it and/or adding further functionality throughout the
life of the project. If a project being delivered under Waterfall is
cancelled at any point up to the end, there is often nothing to
show for it beyond a huge resources bill. With Agile, being
cancelled at any point will still leave the customer with some
worthwhile code that has likely already been put into live
operation.
b) In contrast to waterfall methods, agile development methods
deliver frequent "releases" to production. These releases can
occur as often as several times per week or month. Waterfall
40

development efforts typically have far fewer releases, such as

several times per year. The increasing number of releases and
collaborative nature of the business to development relationship
has

driven

improvements

in

the

relationship

between

development and operations teams. This trend of closer

collaboration between Development and Operations teams is
termed DevOps.
c) The Agile approach allows for frequent re-evaluation of plans,
emphasises on face-to-face communication, and relatively
sparse use of documentation
d) Agile controls offer stronger levels of accountability.

3.2 Research Methodology

To solve this problem there is a need to develop a reliable and secure
system. The preferred technology is Visual C++ .NET a component of
Visual Studio .NET 2005 for the front-end, together with a database
backend using MySQL Server. This will enable all entries and operations
to be done on a user friendly Graphical User Interface (GUI).
3.2.1 Requirement Specification

The main goal of coming up with the requirement specification document for
this system is:

To establish the major requirements necessary to develop the system.

41

Identify Roles and Responsibilities of those involved in managing and

using the system for the purpose its intended for to achieve the firms

objectives.
Identify the scope of what is managed by the system.
Identify the tools to be used during requirements elicitation process.

Water Services Boards are faced with the daunting prospects of capturing,
storing, processing, organizing, disseminating and managing huge quantities
of mission-critical information such as customer information, consumption
details and payment information.
3.2.2 Requirement Investigation

The system developer used sampling methods, consultations, interviews and

observation to collect data used in the development. The system in place is
manual based thus the best way to go about was to use interviews to gain a
better understanding. The other two methods were used based on
experience and to have additional information. The interview method
enabled the developer to get a quick response from the client on the
problems facing the firm and thus establish requirements of the system. It
enabled the developer to ask more detailed questions about the system and
get clear answers on exactly what the users wanted as far as the system is
concerned. Because of the personal contact with the user, the developer was
able to get clarification on any vague requirements.
3.2.3 Data Collection Techniques

Data for this study was collected by using the following techniques:
42

3.2.3.1Interviews

An interview is a conversation between two or more people (the

interviewer and the interviewee) where questions are asked by the
interviewer to obtain information from the interviewee. There are
several types of interviews such as:

Job interview
Case interview
Informational Interview
Exit interview

The type of interview that would be used in this case is a Case

Interview.
3.2.3.2Case Interview

This is a type of job interview in which the applicant is given a question /

situation / problem / challenge and asked to resolve the situation. The
case problem is often a business situation or a business case that the
interviewer has worked on in real life. After the applicant is given
information about the case, the applicant is expected to ask the
interviewer logical and sequential questions that will enable the
applicant to understand the situation, probe deeper into relevant areas,
gather pertinent information and arrive at a solution or recommendation
for the question or situation at hand.
Case interviews are mostly used in hiring for management consulting
and investment banking jobs. Firms use case interviews to evaluate
43

analytical ability and problem-solving skills; they are looking not for a
"correct" answer but for an understanding of how the applicant thinks
and how the applicant approaches problems.
During case interviews, interviewers are generally looking for the
following skills:

Numerical and verbal reasoning skills.

Communication and presentation skills.
Business skills and commercial awareness.

Candidates are often asked to estimate a specific number, often a

commercial figure (such as market size or profitability). Candidates are
expected to demonstrate reasoning rather produce the exact answer.
Short interviews will be carried out with staff from the various WSB in
the course of this study. The information they provide will be valuable
and will provide the basic requirements for this system.
3.2.3.3Sampling Method

The researcher will use simple random sample technique due to the fact
that Water Services Boards operate in various parts of the country and
only a few were selected for investigation. The researcher will only
investigate 4 of the Water Services Boards. In order to select the
appropriate sample size, this study will employ stratified sampling to
pick samples from the population. In order to stratify the study, the
population will be divided into subgroups or strata and each has to be
44

homogenous as possible to ensure easier sampling. The stratified

sampling design is important to this study because it might be the only
practical way to conclude the study.
3.2.3.4Study Population

According to S.G.Gupta, (1994) study population is a sample or a

representative group of a population. The study population is the
aggregate of all the study units. The researcher will deal with the target
population that has the potential for giving the information that is
required for this study.
3.2.4 Data Analysis

The available sample data will be organized into a tabular format that is
easy to import into a MySQL database schema with the help of a
spreadsheet application i.e. Microsoft Excel. No in-depth analysis of data
will be required as emphasis is only on sample representative data.
3.2.5 Data Presentation

Data will be organized and presented in tabular format i.e. in rows and
columns and stored in a database i.e. MySQL. This tabular format is the
formal

method

of

data

representation

in

Relational

Database

Management Systems (RDBMS) such as MySQL database server.

45

4 CHAPTER FOUR: Analysis

4.1 Current System
The current system is mostly manual. It involves entering customer
consumption data in a spreadsheet. This spread sheet is then copied into
storage medium such as a flash disk and transported 40km away for
generation and printing of bills.
4.1.1 Strengths of the Current System

a) It is very familiar to the staff.

4.1.2 Weaknesses of Current System

a) Majority of the data is paper based.

b) It is difficult to query for specific data.
c) Inadequate security of data, since anyone with access to the
computer could view and access the file.
d) It does not provide printing facilities.
e) Frequent erroneous billing data.
f) Does not have the ability to inventory gadgets belonging to the
firm.

46

4.1.3 Flow Chart of the Current System

Figure 5: Flowchart of the Current system.

4.2 Proposed System

The Water and Sanitation Services Management Billing System (WSSMBS) is
meant to provide affordable and efficient billing facilities for Water Services
Boards.
WSSMBS is meant to enable WSBs to effectively manage their operations
and provide cheap billing services.
This can provide considerable savings for the WSBs compared to what they
used to pay to primary WSBs for printing of bills. Previously it used to cost
47

KShs 15.00 to print a single bill. This system will enable the preparation and
printing of bills at less than KShs 7.00 a bill thus providing a savings of KShs
8.00 per bill a saving of 54%.
4.2.1 Strengths of the Proposed System

The proposed system will:

a)
b)
c)
d)

Enable various pieces of data to be stored on a database system.

Provide detailed query facilities including filtering of data.
Provide efficient printing facilities for bills.
Implement enterprise level security such as ssl, password

protection of data, access control lists etc.

e) Implement data verification and validation routines for data to
prevent erroneous billing.
f) Provide a facility to inventory gadgets belonging to the firm eg
water meters.
g) Provide diverse means for checking usage bills such as post office
for paper bills, Email, SMS for electronic bills
h) Provide diverse means of payment for services such as cash,
cheque, direct bank deposit, M-PESA, ZAP etc.
4.2.2 Weaknesses of the Proposed System

a) Users require to be trained.

b) It requires some investment on hardware such as heavy duty
printers for printing of bills.

48

4.2.3 Flowcharts of the Proposed System

Figure 6: Flowchart of the proposed system.

49

5 CHAPTER FIVE: Design

5.1 Architectural Design
5.1.1 Definition

The architecture of a program or computing system is the structure or

structures of the system, which comprise software components, the
externally visible properties of those components, and the relationships
between them. The term also refers to documentation of a system's software
architecture. Documenting software architecture facilitates communication
between stakeholders, documents early decisions about high-level design,
and allows reuse of design components and patterns between projects.
The Architectural Design has been modeled using UML.
5.1.2 The Unified Modeling Language (UML)

It is a standardized general-purpose modeling language in the field of

software engineering. The standard is managed, and was created by, the
Object Management Group.
UML includes a set of graphic notation techniques to create visual models of
software-intensive systems.
The Unified Modeling Language (UML) is used to specify, visualize, modify,
construct and document the artifacts of an object-oriented software intensive
system under development. UML offers a standard way to visualize a
system's architectural blueprints, including elements such as:
50

Actors
Business Processes
(Logical) Components
Activities
Programming Language Statements
Database Schemas
Reusable Software Components.

UML combines techniques from data modeling (entity relationship diagrams),

business modeling (work flows), object modeling, and component modeling.
It can be used with all processes, throughout the software development life
cycle,

and

across

different

implementation

technologies.

UML

has

synthesized the notations of the Booch method, the Object-modeling

technique (OMT) and Object-oriented software engineering (OOSE) by fusing
them into a single, common and widely usable modeling language. UML aims
to be a standard modeling language which can model concurrent and
distributed systems. UML is a de facto industry standard, and is evolving
under the auspices of the Object Management Group (OMG).
UML models may be automatically transformed to other representations (e.g.
Java) by means of QVT-like transformation languages, supported by the OMG.
UML is extensible, offering the following mechanisms for customization:
profiles and stereotype.
5.1.2.1Use Cases Diagrams

A use case diagram in the Unified Modeling Language (UML) is a type of

behavioral diagram defined by and created from a Use-case analysis. Its
purpose is to present a graphical overview of the functionality provided by a
51

system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases.

Figure 7: WSMS Use Case Diagram.

52

The main purpose of a use case diagram is to show what system functions
are performed for which actor. Roles of the actors in the system can be
depicted.
5.1.2.2Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and concurrency. In
the Unified Modeling Language, activity diagrams can be used to describe
the business and operational step-by-step workflows of components in a
system. An activity diagram shows the overall flow of control.

Figure 8: WSMS Activity Diagram.

53

5.1.2.3Class Diagram

In software engineering, a class diagram in the Unified Modeling Language

(UML) is a type of static structure diagram that describes the structure of a
system by showing the system's

classes, their attributes, and the

relationships between the classes.

Figure 9: WSMS Class Diagram.

5.1.2.4Sequence Diagram

A sequence diagram in Unified Modeling Language (UML) is a kind of

interaction diagram that shows how processes operate with one another and
in what order. It is a construct of a Message Sequence Chart.

54

Figure 10: WSMS Sequence Diagram.

Sequence diagrams are sometimes called event diagrams, event scenarios,

and timing diagrams.

5.2 Database Design

Database design is the process of producing a detailed data model of a
database. This logical data model contains all the needed logical and
physical design choices and physical storage parameters needed to generate
a design in a Data Definition Language, which can then be used to create a
55

database. A fully attributed data model contains detailed attributes for each
entity.
The preferred model for the database to be used with the system is Rational
Model which organizes the base structures used to store data as tables and
views linked together using relationships.
5.2.1 Normalization

The process of applying the rules to the database design is called

normalizing the database, or just normalization. It is most useful after having
represented all of the information items and have arrived at a preliminary
design. The idea is to help ensure that information items have been divided
into the appropriate tables. Normalization rules are applied in succession, at
each step ensuring that the design arrives at one of what is known as the
"normal forms."
5.2.1.1First Normal Form

First Normal Form states that at every row and column intersection in the
table there exists a single value, and never a list of values. For example, we
cannot have a field named Telephone in which you place more than one
telephone number. If you think of each intersection of rows and columns as a
cell, each cell can hold only one value.
CUSTOMERID

FIRSTNAME

SURNAME

TELEPHONE

123

John

Wafula

0712 587098

456

Sue

Njambi

0722 423856
56

0752 631934
789

William

Kioko

0735 752061

Table 1: Table violating 1st Normal Form.

To represent the above in 1st Normal Form, we use two tables, as illustrated below:

CUSTOMERID

FIRSTNAME

SURNAME

123

John

Wafula

456

Sue

Njambi

789

William

Kioko

Table 2: Customers' Table.

CUSTOMERID

TELEPHONE

123

0712 587098

456

0722 423856

456

0752 631934

789

0735 752061

Table 3: Customer Telephone Numbers

5.2.1.2Second Normal Form

Second Normal Form requires that a table first be in the 1 st Normal Form and
also that each non-key column be fully dependent on the entire primary key,
not on just part of the key. This rule applies when you have a primary key
that consists of more than one column. For example, suppose you have a
table containing the following columns, where Employee, Skill and Current
Work Location:
57

EMPLOYEE

SKILL

CURRENT

WORK

LOCATION
Juma

Typing

River Road

Juma

Shorthand

River Road

Juma

Binding

River Road

Kamau

Light Cleaning

City Centre

Wanjiru

Chemistry

City Centre

Wanjiru

Flying

City Centre

Odhiambo

Light Cleaning

City Centre

Table 4: Employee Skills table that violates 2nd Normal Form.

Neither {Employee} nor {Skill} is a candidate key for the table. This is
because a given Employee might need to appear more than once (he might
have multiple Skills), and a given Skill might need to appear more than once
(it might be possessed by multiple Employees). Only the composite key
{Employee, Skill} qualifies as a candidate key for the table.
The remaining attribute, Current Work Location, is dependent on only part of
the candidate key, namely Employee. Therefore the table is not in 2NF.
A 2NF alternative to this design would represent the same information in two
tables: an "Employees" table with candidate key {Employee}, and an
"Employees' Skills" table with candidate key {Employee, Skill}:
EMPLOYEE

CURRENT

WORK

LOCATION
Juma

River Road
58

Kamau

City Centre

Wanjiru

City Centre

Odhiambo

City Centre
Table 5: Employees' Table.

EMPLOYEE

SKILL

Juma

Typing

Juma

Shorthand

Juma

Binding

Kamau

Light Cleaning

Wanjiru

Chemistry

Wanjiru

Flying

Odhiambo

Light Cleaning
Table 6: Skills table

This design violates second normal form, because Product Name is

dependent on Product ID, but not on Order ID, so it is not dependent on the
entire primary key. You must remove Product Name from the table. It belongs
in a different table (Products).
5.2.1.3Third Normal Form

Third Normal Form requires that the table not only satisfy the 2 nd Normal
Form ie every non-key column be dependent on the entire primary key, but
also that non-key columns be independent of each other. Another way of
saying this is that each non-key column must be dependent on the primary
59

key and nothing but the primary key. For example, suppose you have a table
containing the following columns:
TOURNAMENT
Chomoka

YEAR

na 2008

WINNER

DATE OF BIRTH

Jack Odhiambo

21 July 1976

Pickup
1 Million A Day

2010

Simon Kimani

17 April 1984

Shinda na Roiko

2009

Salome Macharia

5 May 1986

Concours

2009

Paul Morton

16

September

1958
Table 7: Tournament Winners table that violates 3rd Normal Form.

Because each row in the table needs to tell us who won a particular
Tournament in a particular Year, the composite key {Tournament, Year} is a
minimal set of attributes guaranteed to uniquely identify a row. That is,
{Tournament, Year} is a candidate key for the table.
The breach of 3NF occurs because the non-prime attribute Winner Date of
Birth is transitively dependent on the candidate key {Tournament, Year} via
the non-prime attribute Winner. The fact that Winner Date of Birth is
functionally dependent on Winner makes the table vulnerable to logical
inconsistencies, as there is nothing to stop the same person from being
shown with different dates of birth on different records.
In order to express the same facts without violating 3NF, it is necessary to
split the table into two:

60

TOURNAMENT
Chomoka

YEAR

WINNER

na 2008

Jack Odhiambo

Pickup
1 Million A Day

2010

Simon Kimani

Shinda na Roiko

2009

Salome Macharia

Concours

2009

Paul Morton

Table 8: Tournament Winners table.

WINNER

DATE OF BIRTH

Jack Odhiambo

21 July 1976

Simon Kimani

17 April 1984

Salome Macharia

5 May 1986

Paul Morton

16

September

1958
Table 9: Player's Dates of Birth table.

5.2.2 Tables used in the System Database

5.2.2.1Customers table

This is used to manage customer information its design is illustrated below.

FIELD NAME
customerID
lastName

DATATYPE

REQUIRED

PRIMARY KEY

LONG

CHAR(20)
61

otherNames

CHAR(20)

gender

CHAR(10)

postalAddress

CHAR(100)

physicalAddress

CHAR(100)

ID_Passport

CHAR(10)

PIN_Num

CHAR(10)

homePhone

CHAR(10)

officePhone

CHAR(10)

mobile

CHAR(10)

fax

CHAR(10)

email

CHAR(20)

deposit

CURRENCY

zoneCode

INTEGER

plotNum

CHAR(20)

tariffID

INTEGER

dateApplied

DATE

waterUseID

INTEGER

dateGrantedServi

DATE

ce
amountCharged

CURRENCY

dateOfPayment

DATE

modeOfPayment

INTEGER

bankDepositSlipN

CHAR(10)

um
recieptNum

CHAR(10)
62

5.2.2.2Service Installation table

This is used to manage service installation at the customers premises, its

design is illustrated below.
FIELD NAME

DATATYPE

REQUIRED

PRIMARY KEY

jobTicketNum

LONG

customerID

LONG

premises

CHAR(50)

longitude

CHAR(10)

long_min

CHAR(5)

meterSerialNum

CHAR(20)

initReading

LONG

dateInstalled

DATE

installedBy

CHAR(20)

jobStatusID

INT

5.2.2.3Consumption table

This is used to manage service consumption information eg number of units

of water used in a month, gathered data is used to generate billing
information, its design is illustrated below.
FIELD NAME
customerID
month
year

DATATYPE

REQUIRED

PRIMARY KEY

LONG

SHORT

SMALLINT

Y
63

currentReading

LONG

dateOfReading

DATE

previousReading

LONG

avgConsumption

INT

5.2.2.4Billing table

This is used to compile data on pending bills for later printing. This
information is included in the customers bill. Its design is illustrated below.
FIELD NAME
customerID
month
year

DATATYPE

REQUIRED

PRIMARY KEY

LONG

SHORT

SMALLINT

INT

unitsConsumed
otherCharges

CURRENCY

isBillPaid

BIT

5.2.2.5Balances table

This is used to compile data on outstanding balances. This information is

added to the consumption data to generate the final bill to be paid. Its
design is illustrated below.
FIELD NAME
customerID
month
year

DATATYPE

REQUIRED

PRIMARY KEY

LONG

SHORT

SMALLINT

Y
64

isBalanceFor

INT

5.2.2.6Inventory

This is used to manage data on the firms resources such as water meters. Its
design is illustrated below.
FIELD NAME

DATATYPE

REQUIRED

PRIMARY KEY

meterSerialNum

CHAR(20)

datePurchased
cost
descr
size
isAllocated

DATE
CURRENCY
TEXT
SINGLE

BIT

5.2.2.7Payments

This is used to compile data on payments made for services rendered to

customers. Its design is illustrated below.
FIELD NAME

DATATYPE

REQUIRED

PRIMARY KEY

paymentNum

LONG

customerID

LONG

SHORT

SMALLINT

isPaymentFor

INT

amountOwed

CURRENCY

amountPaid

CURRENCY

month
year

65

modeOfPayment
datePaid
bankDepositSlipN

INT

DATE
CHAR(10)

um
recieptNum

CHAR(10)

5.2.3 Entity Relationship Diagram

66

Figure 11: WSMS Database Model.

5.3 Interface Design

User interface design or user interface engineering is the design of
computers, appliances, machines, mobile communication devices, software
applications, and websites with the focus on the user's experience and
interaction.

67

5.3.1 Bad Interface design

This is one that is not friendly or efficient for the user to use. It makes it
difficult to achieve goals or complete operations thus impeding usability of
the system.
5.3.2 Good Interface design

The goal of user interface design is to make the user's interaction as simple
and efficient as possible, in terms of accomplishing user goalswhat is often
called user-centered design. Good user interface design facilitates finishing
the task at hand without drawing unnecessary attention to itself. Graphic
design may be utilized to support its usability. The design process must
balance technical functionality and visual elements (e.g., mental model) to
create a system that is not only operational but also usable and adaptable to
changing user needs.
An example of a good interface design is:
5.3.2.1Graphical User Interfaces (GUI)

These accept input via devices such as computer keyboard and mouse and
provide articulated graphical output on the computer monitor.
5.3.2.2Web-based user interfaces or web user interfaces (WUI)

These accept input and provide output by generating web pages which are
transmitted via the Internet and viewed by the user using a web browser
program. Newer implementations utilize Java, AJAX, Adobe Flex, Microsoft
.NET, or similar technologies to provide real-time control in a separate
68

program, eliminating the need to refresh a traditional HTML based web

browser.

Administrative

web

interfaces

for

web-servers,

servers

and

networked computers are often called Control panels.

5.3.3 Proposed Interface design

The system will be implemented using Graphical User Interface (GUI). GUIs,
offer a consistent visual language to represent information stored in
computers. This will make it easier for people with little computer skills to
work with and use computer software. Further to this, the system will be
designed as a Multiple Document Interface (MDI).
Multiple Document Interface (MDI) are those whose windows reside under a
single parent window (usually except for modal windows), as opposed to all
windows being separate from each other (single document interface). Such
systems often allow child windows to embed other windows inside them as
well, creating complex nested hierarchies. This enables the user to focus on
the application tasks at hand.
5.3.3.1Advantages of proposed interface

With MDI (and also TDI), a single menu bar and/or toolbar is shared between
all child windows, reducing clutter and increasing efficient use of screen

space.
An application's child windows can be hidden/shown/minimized/maximized as

a whole.
Features such as "Tile" and "Cascade" can be implemented for the child
windows.

69

Possibly faster and more memory efficient, since the application is shared,
and only the document changes, the speed of switching between the internal
windows being usually faster than having the OS switch between external

windows.
If the windowing environment and OS lacks good window management, the

application author can implement it themselves.

Without an MDI frame window, floating toolbars from one application can
clutter the workspace of other applications, potentially confusing users with
the jumble of interfaces.

70

6 CHAPTER SIX: Implementation & Testing

6.1 Implementation
This involves making the new system available to a prepared set of users i.e.
the deployment, and positioning on-going support and maintenance of the
system within the Performing Organization i.e. the transition.
Deploying the system consists of executing all steps necessary to educate
the Consumers on the use of the new system, placing the newly developed
system into production, confirming that all data required at the start of
operations is available and accurate, and validating that business functions
that interact with the system are functioning properly. Transitioning the
system

support

responsibilities

involves

changing

from

system

development to a system support and maintenance mode of operation, with

ownership of the new system moving from the Project Team to the
Performing Organization.

6.2 Coding
The system was developed and coded using the Microsoft Visual C++ .NET
2005 which implements a managed form of C++ language operating under
the Object Oriented Programming paradigm. Due to the immense size of the
system source code going upwards of 1000+ lines of code per module, it was
deemed necessary to include the source code on CD and a few code snippets
in the Appendix section.

71

The backend to the system is implemented using MySQL 5.0 database server
interfacing with the system through a MySQL .Net Connector.

6.3 Screenshots of the system

6.3.1.1Login Screen

Before the user can operate the system, he/she needs to login into the
system by inputting a valid username and password and clicking the Ok
button. To cancel the whole operation click Cancel. This username and
password provides access to the system and its configuration information.
This form controls access to the system features. To successfully login, a user
must

enter

valid

username

and
password.

Figure 12: Login form for the Water Services Management

System.

6.3.1.2The Water Services Management System Main Module

The water and sanitation services billing system is a suite of modules that
enable water and sanitation companies to carry out their routine activities.

72

These activities may involve customer management, service installation,

consumption information and monitoring, meter inventory and finally billing
Figure 13: The Water & Sanitation Services Billing System Main Window

management.
This system therefore provides facilities that go far beyond merely billing
clients for service consumption.
6.3.1.3The Customer Information Management Module

73

This module is used to manage many aspects of the customers. It enables

you to enter, modify, delete and even locate customer information based on
a unique customer number. The customer number also serves as the account
number and is used in all areas that refer to customer information such as
when dealing with consumption information.
The figure above represents the actual customer information management
module window with sample data. The top part of the window is known as
the navigation bar and it enables you to:
1. Navigate your way among records using the arrows.
2. Add, Delete and Save changes made to the data.
3. Search for customer information based on the customer number.

Figure 14: The Customer Information Management Module window.

74

6.3.1.4The Consumption Management Module

Figure 15: : Consumption Information Management Module.

This module enables you to manage consumption information for customers.

It provides the user with the ability to add a record based on the information
gathered by the data collection personnel from the field after visiting the
customers premises.
6.3.1.5The Billing Management Module

This module enables the user to view the available bills and print them to an
available printer.
This module lists information on all payable bills ordering them by customer
number, month and year.

A sample of the generated bills available for printing or exporting is

displayed below:

Figure 16: The Billing Management Module

75

Figure 17: Sample Bill generated by the Water and Sanitation Services system

6.3.1.6The Service Installation Module

This module deals with the installation of services in the customers

premises. The premises could be the customers home, business premises or
any other place.
The co-ordinates of the premises are also entered. These will later be used to
map the coverage region under the companys control.

76

Installation of the Water & Sanitation service for a customer may require that
a meter be available. Meter management is carried out in the Meter
Inventory Management module where the module gives information on all
meters indicating which ones are available for allocation.

Figure 18: Installation Services Management Module.

6.3.1.7The Meter Inventory Management Module

This module used to manage the firms meter inventory collection. It collects

Figure 19: Meter Inventory Management Module.

meter information

77

based on the serial number and other relevant details including size and
condition.
6.3.1.8The Rate Payment Management Module

This module handles all payments for services in this system and displays
them on a list.

Figure 20: Payments Management Module.

78

6.4 System testing

System testing involves integrating two or more components that implement
system functions or features and then testing this integrated system. In an
iterative development process, system testing is concerned with testing an
increment to be delivered to the customer; in a waterfall process, system
testing is concerned with testing the entire system. For most complex
systems, there are two distinct phases to system testing
6.4.1 The Testing Process

This describes the various stages undertaken to ensure that the system
performs as desired. The stages involved are:
6.4.1.1Agile or Extreme development model

In counterpoint, some emerging software disciplines such as extreme

programming and the agile software development movement, adhere to a
"test-driven software development" model. In this process, unit tests are
written first, by the software engineers (often with pair programming in the
extreme programming methodology). Of course these tests fail initially; as
they are expected to. Then as code is written it passes incrementally larger
portions of the test suites. The test suites are continuously updated as new
failure conditions and corner cases are discovered, and they are integrated
with any regression tests that are developed. Unit tests are maintained along
with the rest of the software source code and generally integrated into the
build process (with inherently interactive tests being relegated to a partially

79

manual build acceptance process). The ultimate goal of this test process is to
achieve continuous deployment where software updates can be published to
the public frequently.
6.4.2 Phases of System Testing
6.4.2.1Functional Testing

This refers to tests that verify a specific action or function of the code. These
are usually found in the code requirements documentation, although some
development methodologies work from use cases or user stories. Functional
tests tend to answer the question of "can the user do this" or "does this
particular feature work".
Functional tests were carried out on the system to verify that some critical
features

had

been

implemented

on

the

system.

For

instance,

the

management of customers required that the system have the ability to filter
customers based on specific customer information such as address or
gender. Together with this the customers management module should be
able to display all existing customers in a grid form. These features and
additional functionality were however implemented and integrated into the
system successfully.
6.4.2.2Non-Functional Testing

This refers to aspects of the software that may not be related to a specific
function or user action, such as scalability or security. Non-functional testing

80

tends to answer such questions as "how many people can log in at once", or
"how easy is it to hack this software".

Figure 21: The WSMS Login window ready to receive login information.

The non functional testing was specifically focused on the security features
of the system. Tests were carried out to ensure that unauthorized use of the
system is curtailed. The security features implemented in the system are
multi leveled. They implement security in several levels:

Figure 22: Dialog displayed after an invalid login.

Only a valid existing and authenticated user can access the system

using a password.
All passwords are encrypted.
Authenticated users are also assigned privileges over database
objects, for instance, a date reader is only restricted to reading specific

81

types of data such as customer consumption information and cannot

make changes. A Billing master is also restricted to perform database

operations that pertain to generating and printing customer bills.

Connections between the system and database are also encrypted to
prevent data sniffing.

6.4.2.3Integration Testing

This is where the test team has access to the source code of the system.
When a problem is discovered, the integration team tries to find the source
of the problem and identify the components that have to be debugged.
Integration testing is mostly concerned with finding defects in the system.
Integration testing for the system was carried out to determine how the
system would perform in the operational environment. Modules were tested
one at a time, and then as a grouping of related modules to identify any
bugs. As with most software projects, a few bugs were discovered, but were
gradually sorted out an example was the zones management of the
configuration module, which had some relevant zone definitions missing.

Figure 23: The WSMS after a successful login.

6.4.2.4Performance Testing

In the computer industry, software performance testing is used to determine

the speed or effectiveness of a computer, network, software program or
82

device. This process can involve quantitative tests done in a lab, such as
measuring the response time or the number of MIPS (millions of instructions
per second) at which a system functions. Qualitative attributes such as
reliability,

scalability

and

interoperability

may

also

be

evaluated.

Performance testing is often done in conjunction with stress testing.

Performance testing was performed on the system to establish how reliably it
would operate under heavy use. This was carried out by making an attempt
to generate and print 1000 bills. The response time of the computer system
was found to be satisfactory as it took only 10 minutes to generate the bills
from customer consumption data. The only constraint identified was the
speed of the printer to produce hard copies of the bills, but this will be
mitigated once high speed printers are introduced.

83

Figure 24: The Customer Management module displaying 939 records generated using a
data generation tool.

6.4.2.5Regression Testing

This is any type of software testing that seeks to uncover software errors by
partially retesting a modified program. The intent of regression testing is to
assure that a bug fix has been successfully corrected based on the error that
was found, while providing a general assurance that no other errors were
introduced in the process of fixing the original problem. Regression is
commonly used to efficiently test bug fixes by systematically selecting the
appropriate minimum test suite needed to adequately cover the affected
software code/requirements change. Common methods of regression testing

84

include rerunning previously run tests and checking whether previously fixed
faults have re-emerged.
Some of the bugs identified in the system included a rejection of negative
balances ie a case in which a customer made an over payment for service. In
this situation, the system had been programmed to only accept positive
values. After careful study, it was finally agreed that indeed customers
overpay in some situations and the bug was fixed. The fix was confirmed by
carrying out a regression test.
6.4.2.6Release Testing

This is where a version of the system that could be released to users is

tested. Here, the test team is concerned with validating that the system
meets its requirements and with ensuring that the system is dependable.
Release testing is usually 'black-box' testing where the test team is simply
concerned with demonstrating that the system does or does not work
properly. Problems are reported to the development team whose job is to
debug the program. Where customers are involved in release testing, this is
sometimes called acceptance testing. If the release is good enough, the
customer may then accept it for use.
The system is underwent release testing and has been found to provide a
satisfactory state of performance.

85

6.4.2.7Acceptance Testing

In engineering and its various sub disciplines, acceptance testing is blackbox testing performed on a system (e.g. software, lots of manufactured
mechanical parts, or batches of chemical products) prior to its delivery. It is
also known as functional testing, black-box testing, release acceptance, QA
testing, application testing, confidence testing, final testing, validation
testing, or factory acceptance testing.
In software development, acceptance testing by the system provider is often
distinguished from acceptance testing by the customer (the user or client)
prior to accepting transfer of ownership. In such environments, acceptance
testing performed by the customer is known as user acceptance testing
(UAT). This is also known as end-user testing, site (acceptance) testing, or
field (acceptance) testing.
The system was put through a testing process to determine its suitability. It
was found to exceed the clients expectations since it provided more
functionality which the user had overlooked in the requirements elicitation.
6.4.2.8Acceptance testing

This is black-box testing performed on a system (e.g. software) prior to its

delivery. It is also known as functional testing, black-box testing, release
acceptance, QA testing, application testing, confidence testing, final testing,
validation testing, or factory acceptance testing.

86

6.4.3 The Testing Strategy

This is an outline that describes the testing portion of the software

development cycle. It is created to inform project managers, testers, and
developers about some key issues of the testing process. This includes the
testing objective, methods of testing new functions, total time and resources
required for the project, and the testing environment.
The test strategy describes how the product risks of the stakeholders are
mitigated at the test-level, which types of test are to be performed, and
which entry and exit criteria apply.
The preferred testing strategy for the system was bottom-up testing.
6.4.3.1Bottom-up testing

This is a technique of integration testing. A test engineer creates and uses

test drivers for components that have not yet been developed, because, with
bottom-up testing, low-level components are tested first. The objective of
bottom-up testing is to call low-level components first, for testing purposes.
Common issues to be tested for included:

Incorrect data formats such as numbers instead of names.

Null entries in fields that should not be null such as amount of money

charged for service.

Values that fall out of range of acceptable boundaries such as dates.
Invalid combinations.

Common causes of issues included:

87

Inadequate understanding of requirements.

Deviations from the original approved design.
Poor programming skills.

6.4.4 Test Data

The data used was composed of both real data obtained from the previous
system and simulated data that was generated using a data generator.
6.4.5 Testing Schedule

The table below shows activities that will occur during the testing stage of
the system development and their specific durations.
ACTIVITY

DURATION

TIME (HOURS)

UNIT LEVEL TESTS

1 WEEK

56

MODULE LEVEL TESTS

1 WEEK

56

INTEGRATION TESTS

1 WEEK

56

SYSTEM TESTING

1 WEEK

56

6.5 Implementation Strategy

This outlines the how and when the system is going to be installed in an
operational environment. The deliverable of the implementation phase is the
operational system. The main purpose of the implementation plan is to
clearly map out how the new system will be integrated and interfaced in the
organization to optimize its business functions. The implementation plan also
outlines the system changeover plan and actual implementation of the plan
and why the approach was taken. A reliable approach must therefore be

88

carefully chosen in regard to the operational environment and nature of the

organization.
Some of the changeover approaches favored by the system include:
6.5.1 Phased Changeover

The phased operation changeover method involves implementing the new

system in stages, or modules. We can implement each subsystem by using
any of the other three changeover methods. In this approach risk of errors or
failures is limited to the implemented module only as well as it is less
expensive than the full parallel operation.
6.5.2 Pilot Changeover

The pilot changeover method involves implementing the complete new

system at a selected location of a company. It involves a direct cutover
method and operating both systems for only the pilot site. The group that
uses the new system first is called the pilot site. By restricting the
implementation to a pilot site reduces the risk of system failure as compared
with is less expensive than a parallel system.
6.5.3 Parallel Changeover

The parallel operation changeover method requires that both the old and the
new information systems operate fully for a specified period. Data is input to
both systems and output generated by the new system is compared with the
equivalent output from the old system. When users, management, and IT
group are satisfied that the new system operates correctly then the old
89

system is terminated. It is the most costly changeover method and involves

lower risks.
6.5.4 Direct Changeover

The direct cutover approach causes the changeover from the old system to
the new system to occur immediately when the new system becomes
operational. It is the least expensive but involves more risks than other
changeover methods.
6.5.5 Chosen Strategy
6.5.5.1Parallel Changeover

The parallel changeover method is used whereby the new system will be
operated side by side with the existing system for a brief period of time. The
staff will be entering data on both the new and old systems and comparing
the output from both systems to ensure that the sew system is operating as
intended. After a specified duration of time, the new system will be put into
full operation and the old one will cease to be used.
6.5.5.1.1 Justification

This approach possesses low failure risk since it is more likely to catch any
major bugs in the intended system thus preventing the organization from
suffering major problems. If serious problems are discovered, the new
system is simply deactivated and the problem is fixed. It also allows users
adequate time to learn the new system and identify areas that need
attention.

90

6.5.6 Major Tasks in Implementation

6.5.6.1Installation

This involves the installation of both the hardware and software components
of the system and will be carried out by the developer.
6.5.6.2Training

The implementation of the training phase will involve introducing the users
to the system, its potential and functionality at a deep level.
6.5.6.3Execution

This will involve the actual operation of the new system in parallel with the
existing system.
6.5.6.4Review

In this phase, results will be compared between both the old and new
systems and conclusions drawn.
6.5.7 Error Handling

Error handling refers to the anticipation, detection, and resolution of

programming,

application,

and

communications

errors.

Specialized

programs, called error handlers, are available for some applications. The best
programs of this type forestall errors if possible, recover from them when
they occur without terminating the application, or (if all else fails) gracefully
terminate an affected application and save the error information to a log file.
Error handling in the system has been implemented in several levels.

91

6.5.7.1Validation of Data

This is the process of ensuring that a program operates on clean, correct and
useful data. It uses routines, often called "validation rules" or "check
routines", that check for correctness, meaningfulness, and security of data
that are input to the system. The rules are implemented through the
automated facilities of a data dictionary, or by the inclusion of explicit
application program validation logic.
Some examples of validation methods are:
6.5.7.1.1 Format or picture check

Checks that the data is in a specified format (template), e.g., dates have to
be in the format DD/MM/YYYY. Regular expressions should be considered for
this type of validation.
6.5.7.1.2 Data type checks

Checks the data type of the input and give an error message if the input data
does not match with the chosen data type, e.g., In an input box accepting
numeric data, if the letter 'O' was typed instead of the number zero, an error
message would appear.
6.5.7.1.3 Range check

Checks that the data lie within a specified range of values, e.g., the month of
a person's date of birth should lie between 1 and 12.

92

6.5.7.1.4 Limit check

Unlike range checks, data is checked for one limit only, upper OR lower, e.g.,
data should not be greater than 2 (>2).
6.5.7.1.5 Presence check

Checks that important data are actually present and have not been missed
out, e.g., customers may be required to have their telephone numbers listed.
6.5.7.1.6 Consistency Checks

Checks fields to ensure data in these fields corresponds, e.g., If Title = "Mr.",
then Gender = "M".
6.5.7.1.7 File existence check

Checks that a file with a specified name exists. This check is essential for
programs that use file handling.
6.5.7.1.8

Logic check

Checks that an input does not yield a logical error, e.g., an input value should
not be 0 when there will be a number that divides it somewhere in a
program.
6.5.7.1.9

Uniqueness check

Checks that each value is unique. This can be applied to several fields (i.e.
Address, First Name, Last Name).

93

6.5.7.1.10

Referential Integrity

In modern Relational database values in two tables can be linked through

foreign key and primary key. If values in the primary key field are not
constrained by database internal mechanism, then they should be validated.
Validation of the foreign key field checks that referencing table must always
refer to a valid row in the referenced table.
6.5.7.2Error Handlers

These are also known as Exception Handlers. They programming language

constructs or computer hardware mechanisms designed to handle the
occurrence of exceptions, special conditions that change the normal flow of
program execution.
Error handlers have been implemented in all major code segments in the
system to ensure that the system handlers all occurrences of errors or
exceptions.

6.6 Conclusion
The success of the system has enabled the Water Services Board to
significantly cut down on billing charges. This has enabled them to dedicate
more funds to other aspects of their operations such as buying more meters,
improving customer service etc.
Development of this system has been a great motivation for me to venture
into the software development field. I would like to further improve this

94

project so as to be able to use it to market my skills to potential clients in my

IT career.
Some issues however required special attention in order to fully utilize the
potential of the system. These include:

The purchase of new more powerful desktop computers and servers.

The purchase of powerful Heavy Duty printers.
Introduction of internet facilities to network various Water Service

Board branches.
Changing
requirements:

the

management

changed

the

requirements a number of times (3 times) causing a complete redesign

of some modules.
Erratic power: led to loss of data and work done on the project.
Virus infections: There were several infestations on the project
development computer due to the use of infected flash disks.

Some solutions undertaken to solve the above problems included:

Discussing with the management the implications of frequent changes

to the requirements in terms of time & money.

Ensuring that UPSs are installed for each computer used to run the

system to avoid loss of data due to erratic power.

Ensuring that all removable media is scanned for malware prior to
inserting them into the computers running the system.

95

References
1) Agile Alliance: http://www.agilealliance.com/
2) Agile Manifesto Principles:
http://www.agilemanifesto.org/principles.html
3) Agile Processes Workshop II Managing Multiple Concurrent Agile
Projects. Washington: OOPSLA 2002
4) Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide
for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5.
5) Kay, Alan. "The Early History of Smalltalk".
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html.
Retrieved 2007-09-13.
6) Armstrong, The Quarks of Object-Oriented Development. In
descending order of popularity, the "quarks" are: Inheritance, Object,
Class, Encapsulation, Method, Message Passing, Polymorphism,
Abstraction
7) B. Stroustrup, The C++ Programming Language, 3rd-ed., p. 158
8) Pierce, Benjamin (2002). Types and Programming Languages. MIT
Press. ISBN 0-262-16209-1. , section 18.1 "What is Object-Oriented
Programming?"
9) John C. Mitchell, Concepts in programming languages, Cambridge
University Press, 2003, ISBN 0521780985, p.278
10)
Michael Lee Scott, Programming language pragmatics, Edition 2,
Morgan Kaufmann, 2006, ISBN 0126339511, p. 470
11)
A Theory of Objects, Martin Abadi and Luca Cardelli
12)
Meyer, Second Edition, p. 230
13)
M.Trofimov, OOOP - The Third "O" Solution: Open OOP. First Class,
OMG, 1993, Vol. 3, issue 3, p.14.
14)
"Mode inheritance, cloning, hooks & OOP (Google Groups
Discussion)".
96

http://groups.google.com/group/comp.emacs.xemacs/browse_thread/t
hread/d0af257a2837640c/37f251537fafbb03?lnk=st&q=
%22Richard+Stallman%22+oop&rnum=5&hl=en#37f251537fafbb03 .
15)
Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004).
An Agile Information Systems Development Method in use. Turk J Elec
Engin, 12(2), 127-138.
16)
Scott Guthrie. "Releasing the Source Code for the NET
Framework".
http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-thesource-code-for-the-net-framework-libraries.aspx. Retrieved 2008-0601 .
17)
Microsoft. "Microsoft .NET Framework 3.5 Administrator
Deployment Guide". http://msdn.microsoft.com/library/cc160717.aspx.
Retrieved 2008-06-26.
18)
S. Somasegar. "Visual Studio 2010 and .NET FX 4 Beta 1 ships!".
Archived from the original on 2009-05-27.
http://www.webcitation.org/5h5lV7362. Retrieved 2009-05-25.
19)
"ECMA 335 - Standard ECMA-335 Common Language
Infrastructure (CLI)". ECMA. 2006-06-01. http://www.ecmainternational.org/publications/standards/Ecma-335.htm. Retrieved
2008-06-01.
20)
ISO/IEC 23271:2006
21)
"Technical Report TR/84 Common Language Infrastructure (CLI) Information Derived from Partition IV XML File". ECMA. 2006-06-01.
http://www.ecma-international.org/publications/techreports/E-TR084.htm.

97

22)

"ECMA-334 C# Language Specification". ECMA. 2006-06-01.

http://www.ecma-international.org/publications/standards/Ecma334.htm.
23)
"Standard ECMA-372 C++/CLI Language Specification". ECMA.
2005-12-01. http://www.ecmainternational.org/publications/standards/Ecma-372.htm.
24)
"Base Class Library".
http://msdn.microsoft.com/netframework/aa569603.aspx. Retrieved
2008-06-01.
25)
"Garbage Collection: Automatic Memory Management in the
Microsoft .NET Framework".
26)
"Garbage CollectionPart 2: Automatic Memory Management in
the Microsoft .NET Framework". Archived from the original on 2007-0626. http://web.archive.org/web/20070626080134/,
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx .
Retrieved 2008-06-01.

98

Appendix
Budget
The project will be self-sponsored and the budget formulated from the
actual expenditure expected during the development of the system.
UNIT

NUM OF

ITEM

COST

UNITS

Computer
(Laptop)
Printer
Printing Papers
Biro
Pens/Pencils
Flash disks
(1GB)
Meals
Transport
CD/DVDs
TOTAL

SUB TOTAL

(KSHS)

75,000.00

75,000.00

1
10

7,500.00
350.00

7,500.00
3,500.00

12

20.00

240.00

1,250.00

3,750.00

6000
20

5,000.00

5,000.00
6,000.00
600.00
101,590.00

30.00

GANTT chart
The project schedule for development is summarized in the Gantt chart
below:

TIME IN WEEKS
ACTIVITIES

1
0

1
1

1
2

1
3

1
4

Proposal
Feasibility Study
System analysis
System design
Testing &
Implementation
Documentation
99

Report writing
Presentation

100