DESIGN AND IMPLEMENTATION OF A MOBILE BASKETBALL

SCOREBOARD

BY

KWIZERA ADELARD

BCS/421211911DF

AND

LAMONI GAD WILSON

BCS/40350/91/DU

A PROJECT REPORT SUBMITTED TO THE COLLEGE OF APPLIED

SCIENCES AND TECHNOLOGY IN PARTIAL FULLFILMENT OF

THE REQUIREMENT FOR THE AWARD OF DEGREE OF

BACHELOR OF COMPUTER SCIENCE

OF KAMPALA INTERNATIONAL

UNIVERSITY

JUNE 2012

DECLARATION

WE Kwizera Adelard, BCS/42121/91/DF and Larnoni Gad Wilson,

BCS/40350/91/DU declare that this report was OUR original work and has not

been presented for examination in any other University.

KWIZERA ADELARD BCS/42121/91/DF

Signature..E)~~.- Date

LAMONI GAD WILSON BCS/40350/91/DU

Signature Date~

APPROVAL

This is to certify that this research report entitled “DESIGN AND

IMPLEMENATION OF A MOBILE BASKETBALL SCORE BOARD.” was

conducted under my supervision and guidance and is now ready for submitted to

the college of applied sciences and technology with my approval.

Signature/:y’ L~

Supervisor: Mr. KASAWULI F~ K 1 ~ JUL 2~1Z

DATE ‘.~.. ~ ~

Table of Contents

DECLARATION i

APPROVAL II

ACKNOWLEDGEMENT viii

CHAPTER 1 1

INTRODUCTION 1

1.1 GENERAL INTRODUCTION

1.2 BACKGROUND OF THE PROJECT 1

1.3 STATEMENT OF THE PROBLEM 2

1.4 OBJECTIVES OF THE STUDY 2

1.4.1 Main objective 2

1.4.2 Specific objectives of the study 2

1.5 SCOPE OF THE PROJECT 3

1.6 SIGNIFICANCE OF THE STUDY 3

1.7 JUSTIFICATION OF THE STUDY 4

CHAPTER TWO

LITERATURE REVIEW 5

2.0 INTRODUCTION s

2.1 POINTING SYSTEM IN BASKETBALL RULES 5

2.1.1 Free Throw s

2.1.2 Two-Point Shot s

111

2.1.3 Three-Point Shot .6

2.1.5 COMMONLY DESKTOP VERSION OF SCOREBOARD USED FOR THE

POINTING SYSTEM 6

Desktop version 6

Features~ 6

2.2 MOBILE BASKETBALL SCOREBOOK (MOBSCOB) 7

2.3 TECHNOLOGIES NEEDED TO DEVELOP SUCH APPLICATION 7

2.3.1 JME 7

2.3.2 Overview of Java ME 8

2.3.3 Mobile Phone Applications with J2ME and its Advantages 9

2.3.4 Advantages of J2ME Applications 10

2.3.5 J2ME technology Minuses 11

2.4 LWUIT 11

2.4.1 WHAT IS LWUIT~ 11

2.4.2 Brief History 12

2.4.3 KEY FEATURES OF LWUIT 12

2.5 OVERVIEW OF THE MOBSCOB 13

PHYSICAL DESIGN 14

CHAPTER 3 16

RESEARCH METHODOLOGY 16

3.1 REQUIREMENTS ELICITATION METHODS 16

3.1.1 Prototyping 16

3.1.2 Storyboard 16

3.1.3 Benefits 17

3.1.4 Advantages 17

iv

3.1.5 Disadvantages .18

3.2 SYSTEM DESIGN TECHNIQUES 18

3.2.1 UML 18

3.2.2 Structured diagrams 18

3.2.3 Behaviors diagrams 19

3.2.4 Implementation techniques 19

3.2.5 Stagel: Feasibility Study 20

3.2.6 Stage 2: Functional Model Iteration 21

3.2.7 Stage 3: Design and Build Iteration 22

3.2.8 Stage 4: Implementation 23

3.3 TESTING TECHNIQUES 23

3.3.1 White-box testing 23

3.3.2 Black-box testing 24

3.3.3 Comparison of white box testing and black box testing 26

3.3.4 Usability Testing 26

5.0 Introduction 28

5.1 Form input and Interface Design 28

5.3 Shortcomings with the Tool 33

5.4 Tool Security 33

5.5 Testing and validation 33

5.5.1 Results of Validation 33

DISCUSSION, RECOMMENDATIONS AND CONCLUSION 36

6.0 Discussion 36

6.2 Project Accomplishments 36

6.3 Limitations 36

v

6.4 Recommendations .37

6.5 Conclusion 37

REFERENCES 38

vi

ABBREVIATIONS AND ACCRONYMS

K.J.U Kampala International University

SDLC System Development Life Cycle

JME Java Micro Edition

LWUIT Light Weight user interface Toolkit

RMS Record Management system

IDE Integrated Development Environment

DSDM Dynamic System Development Methodology

vii

ACKNOWLEDGEMENT

First and foremost, we would like to thank our supervisor Mr. Kasawuli Faik for

the wealth of knowledge and advice I acquired through this project. His

willingness to motivate me contributed tremendously a lot to my project. I would

also like to thank him for his kindness and commitment which inspired me to when

I had started this project.

Secondly, I would like to thank the management of Kampala International

University (KIU) for providing us a good environment and facilities to complete

this project. I would also like to take this opportunity to thank the College of

Applied Science and Technology (MU).

viii

ABSTRACTA

Mobile Scorebook is a mobile application for Java enabled handsets that will

enable Basketball lovers to record scores during the game, count points and keep

track of game.

This application is developed to help basketball lovers to feel closer to their

passion of basketball as it even records fouls and keeps these records for future

reference by the user.

ix

CHAPTER 1

INTRODUCTION

Li GENERAL INTRODUCTION

This chapter focuses on the background to the project under study, statement of the

problem, purpose of the study, objectives of the study, scope, and significance of

the study and frame work of the study

L2 BACKGROUND OF THE PROJECT

This concept of mobile basketball score book has been used in the study as a

solution that is going to be used to solve problems faced by basketball fans and

mostly coaches of basketball teams.

Nevco Scoreboards is the manufacturer of the current scoreboard system in place

in Brubaker Auditorium. It is controlled by a microprocessor-based keypad that

has special switches to start two separate timers. In its current state, it has a

memory to guard against accidental power outages without losing scoreboard

information. It does not keep track of individual statistics beyond that which is

displayed on the scoreboard itself. Information concerning the Nevco 2550-D

scoreboard found in Brubaker Auditorium can be found both in the user’s manual

as well as the company website (www.nevcoscoreboards.com.)

This project describes the design approach and solution techniques developed for

coaches and basketball fans. This application is used to help coaches to be close to

their players and fans also to be involved in the game.

The system requirements have been collected from coaches and basketball fans

because this application is made for them. Once this project is implemented

coaches to record the score during trainings. Basketball fans on the other side will

be also involved in the game just using the mobile basketball scorebook.

L3 STATEMENT OF THE PROBLEM

During trainings sometimes the score is kept because of the lacks of scoreboards

on the court. That was a barrier for a good training session.

So there was need of a mobile basketball scorebook application that helps coaches

to keep track of the score during trainings. Also basketball fans need to keep on

their own the score when they are playing for fan.

14 OBJECTIVES OF THE STUDY

1.4.1 Ma in objective

The objective of this project was to design and implement a mobile basketball

scorebook with an outline of the fundamental concepts, theories and principles of a

mobile application development.

1.4.2 Sp ecific objectives of the study

The specific objectives are as follow:

• To study the current scoreboard recording methods used by FIBA, and

improvise for ways of making it better.

• Analyze the requirements for designing a Mobile Basket Ball scoreboard.

• To design a Mobile Basket Ball scoreboard to be used by Basket Ball teams,

and help coaches, players and fans to be involved in the game

2

• To develop, and test the mobile Basket Ball scoreboard.

1.5 SCOPE OF THE PROJECT

The scope of our project is based on the tools, and technologies that have been

used while implementing our application (MOBSCOB).

Among those tools are NETBEANS 7.0.1 which is the IDE that we used,

LWUIT1 1.4 resource editor for designing and customizing the user interface. The

technologies to be used are JME and LWUIT which are discussed in detail in the

next chapter. Implementing the MOB SCOB has given us a hard time because this

above technologies were new to us, and we just tried to get ourselves acquainted

with all these new technologies.

Others are just constraints of the project such as:

> Microsoft PowerPoint during presentation

> Money for internet during research

> Time

1.6 SIGNIFICANCE OF THE STUDY

After the objectives of this research project are achieved, the users will benefit in

terms of accuracy, time saving, cost reducing:

• Accnracy: the user will be able to keep the score and the time in in real time

during the course of the game. She no longer need to calculate for him self

the score

The application will provide numeric outputs values of all the above.

• Time: instead of taking time to write down the score with a pen, or taking

time to calculate by yourself the score, the mobile basketball scorebook will

do it for you in reasonable time.

• Cost reduction: Instead of buying papers, pens, and carrying them to each

training session and games you will just need to carry your mobile phone

and use it as a basketball scorebook.

• In the other hand, since this is an academic final research project, it will be

used a reference for designing and implementing mobile applications using

JME.

1.7 JUSTIFICATION OF THE STUDY

Coaches are now able to record the score during trainings using their mobile

phone. They no longer need help of somebody else to keep the score.

4

CHAPTER TWO

LITERATURE REVIEW

2.0 INTRODUCTION

This chapter takes focus on the literature review, introducing the pointing system

in basketball (rules); the scope of the literature review, the commonly desktop

versions of basketball scoreboard used, the technology that have been used to

develop the mobile basketball scoreboard, data collection techniques and finally

take a look at the application itself

2,1 POINTING SYSTEM IN BASKETBALL RULES

2.1.1 Free Throw

Each free throw made counts as one point. The free-throw line is located 15 feet

from the backboard in the center of the floor. For you to receive a free throw, the

opposing team will have to commit a foul on you as you shoot or commit more

than five personal fouls over the course of one quarter. If you are fouled as you

sink a basket during game play, you will receive one bonus free throw. If you miss

the shot, you will receive two or three free throws, depending on the location

where the shot originated.

2.1.2 Two-Point Shot

Any basket from a shot taken from inside the three-point line during game play

counts for two points. The three-point line is located 23 feet 9 inches from the

center of the backboard. If a player steps on the three-point line before releasing

the ball, the shot will count for only two points.

5

2.1.3 Three-Point Shot

Any basket from a shot taken from outside the three-point line counts for three

points. The shooting player can step on or cross the three-point line after releasing

the ball; the shot will still count for three points. The shooter must have at least one

foot on the floor outside of the line before taking the shot.

2,1.5 COMMONLY DESKTOP VERSION OF SCOREBOARD USED FOR THE

POINTING SYSTEM

Desktop version

In gyms, arenas, or school facilities you can use this software to display a

basketball scoreboard. Normally, physical scoreboards are expensive and difficult

to be established. This software provides a simple but useful scoreboard display.

Just install it to your laptop and establish a connection between your laptop and a

projector. On internet you can find similar software to this tool but we claim that

this tool is more effective. You can use for non-commercial purposes.

Features:

* It is very cheap (Only -$9-)

* No-Setup: Runs from just a file (.exe) (It does not require to be installed)

* You can enter score and foul on each player.

* Customizable font, team names and colors

* Separate panels: You can control scoreboard from separate control panel and

audience does not see mouse gestures.

* No-windows border and toolbar. Just seen display that you want. It provides

more realistic view like a physical scoreboard.

6

* Includes new FIBA rules. (14 see)

* And more... Just download and use.

Other commonly used are:

V Basketball Scoreboard CustomPro 3.1.2

V Basketball Scoreboard DualPro 2.0.1

Nevco Scoreboards is the manufacturer of the current scoreboard system in place

in Brubaker Auditorium. It is controlled by a microprocessor-based keypad that

has special switches to start two separate timers. In its current state, it has a

memory to guard against accidental power outages without losing scoreboard

information. It does not keep track of individual statistics beyond that which is

displayed on the scoreboard itself. Information concerning the Nevco 2550-D

scoreboard found in Brubaker Auditorium can be found both in the user’s manual

as well as the company website (www.nevcoscoreboards.com.)

2.2 MOBILE BASKETBALL SCOREBOOK (MOBSCOB)

In this section we will be explaining the main technologies and tools that I will

need for developing the MOBSCOB.

MOBSCOB is the name of the application.

2.3 TECHNOLOGIES NEEDED TO DEVELOP SUCH APPLICATION

2.3.1 J ME

What is J2ME or Java ME?

According to (James Keogh, 2003), J2ME made its debut at the JavaOne

Developers Conference in mid-1999 and is targeted to developers of intelligent

wireless devices and small computing devices who need to incorporate cross-

platform functionality in their products.

7

Consumers of mobile and small computing devices have high performance

expectations for these devices. They demand quick response time, compatibility

with companion services, and full-featured applications in a small computing

device.

Consumers expect the same software and capabilities found on their desktop and

laptop computers to be available on their cell phones and personal digital

assistants.

To meet these expectations, developers have to rethink the way they build

computer systems. Developers need to harness the power of existing front-end and

back-end.

Software found on business computers and transfers this power onto small, mobile,

and wireless computing devices. J2ME enables this transformation to occur with

minimal modifications, assuming that applications are scalable in design so that an

application can be custom-fitted to resources available on a small computing

device.

Java ME technology was originally created in order to deal with the constraints

associated with building applications for small devices. For this purpose Oracle

defined the basics for Java ME technology to fit such a limited environment and

make it possible to create Java applications running on small devices with limited

memory, display and power capacity.

2.3.2 Oven, ~ew of Java ME

Unlike Java SE, Java ME is not a piece of software, nor is it a single specification.

This difference can be confusing, even for developers who are already familiar

with Java SE. Instead, Java ME is a platform, a collection of technologies and

specifications that are designed for different parts of the small device market.

8

Because Java ME spans such a variety of devices, it wouldn’t make sense to try to

create a one-size-fits-all solution.

Java ME, therefore, is divided into configurations, profiles, and optional packages.

Configurations are specifications that detail a virtual machine and a base set of

APIs that can be used with a certain class of device. A configuration, for example,

might be designed for devices that have less than 512 KB of memory and an

intermittent network connection. The virtual machine is either a full Java Virtual

Machine (as described in the specification) or some subset of the full JVM. The set

of APIs is customarily a subset of the Java SE APIs.

A profile builds on a configuration but adds more specific APIs to make a

complete environment for building applications. While a configuration describes a

JVM and a basic set of APIs, it does not by itself specify enough detail to enable

you to build complete applications. Profiles usually include APIs for application

life cycle, user interface, and persistent storage.

An optional package provides functionality that may not be associated with a

specific configuration or profile. One example of an optional package is the

Bluetooth API (JSR 82), which provides a standardized API for using Bluetooth

networking. This optional package could be implemented alongside virtually any

combination of configurations and profiles.

2.3.3 M obNe Phone AppNcat~ons with J2ME and its Advantages

Java Platform, Micro Edition, or JAVA ME, is a JAVA Platform designed for

Mobile Devices and embedded systems. Target devices range from industrial

controls to mobile phones and set up boxes. JAVA ME was formerly known as

JAVA 2 Platform, Micro Edition (Java ME).

9

If your mobile phone supports J2ME application development then you would be

able to access to an ample of information through it. Now imagine the usage of

mobile phones, it’s not only limited to sending messages or calling, its benefits are

beyond your imagination.

J2ME applications keep the users engaged in a very playful and interesting manner

and try focusing to hold users’ interest and faith thorough eye-catching and

invigorating concepts.

2.3.4 A dvantages of J2ME AppNcations

1. J2ME applications are very powerful and are able to access large quantity of

data in such small device.

2. J2ME applications developments are replacement of personal computers

because windows operating system are installed in mobile to support J2ME.

3. J2ME application are best source of fun, you can play games, poke your

friends and make your favorite playlist.

4. J2ME applications are the door to information; you can simply be benefit

through its traveling and mapping facilities.

5. J2ME applications also support medical related issues; you can make a diet

chart on your mobile which keeps you updated with your calories.

As everyone knows, in handset development, J2ME, BREW, Symbian, Android,

Windows Mobile, and other development mode, and compared these development

methods, the use of J2ME technology is a relatively common technology, to talk

about some of these technologies simple comparison.

10

2.3.5 J2 ME techno~ogy Minuses

In order to achieve limited function of the transplanted J2ME technology, J2ME

technology can not achieve the function of the system, such as reading a telephone

directory, messaging systems content. Not on the development of the mobile

phone system software.

The relatively slow speed running on the JVM J2ME technology on the basis of,

coupled with the restrictions on cell phone hardware, operating speed is relatively

slow, but the speed users can still accept ah.

Procedures in the limited size of cell phones, J2ME technology development

program procedures size under great restrictions, such as Nokia S40 series of

procedures limit the size of 64 KB general within the J2ME greatly limit the

functionality.

What is the problem, we can actively correct it.

2.4 LWUIT

2.4.1 WHAT ~S LWU~T?

Lightweight User Interface Toolkit (LWUIT) is a Widget toolkit developed by Sun

Microsystems to enable easier Java ME user interface development for existing

devices. LWUIT is inspired by Swing and supports many of its features including

pluggable look and feel, layout managers, etc.

11

2.4.2 Brief H~ story

LWUIT was created by Chen Fishbein of Sun Microsystems Israel development

center (SIDC) who started developing LWUIT for an internal project. The project

grew at which point Shai Almog joined the project which was announced at Java

One 2008, following the announcement the project was made open source by Sun

under the GPL with ClassPath_Exception license and gained wide acceptance

within the community. LWUIT is known as the Lightweight UI Toolkit, where the

word lightweight is used as it is used in Swing to indicate a component model that

performs all of its own rendering/event handling.

2.4.3 KEY FE ATURES OF LWUIT

o UI Controls - Components such as Tree, Table, Buttons, List, etc. inspired

by Swing

o XHTML and HTML4 support - LWUIT’s HTML component allows

rendering of HTML documents that conform to the XHTML Mobile Profile

1.0 standard and HTML4

o Layouts Manager - A very flexible and powerful feature, particularly if the

application runs on different screen sizes

o Pluggable Look and Feel & Themes - The toolkit lets you create a CSS

like file that can be loaded or changed at runtime, controlling the look and

feel of the application

o Fonts - The library features bitmap fonts and a tool that lets you create fonts

on your desktop

o Touch Screen - All LWUIT components support touch events. No special

coding is needed for a LWUIT application to run on a touch-enabled device

12

Virtual keyboard support - This functionality enhances the touch screen

support through LWUIT by enabling customizable user input through the

virtual keyboard on the device display

Animations & Transitions - Various visual effects available out-of-the-box

through the library add life to applications

3D and SVG Graphics Integration - Optional features for advanced

devices.

o Tools - LWUIT provides a Theme Creator tool for editing and creating

themes and resources. This is a sta ndalone application for creating and

viewing background painting, obj ects, and other theme elements

o Bi-directional text support - Support for right to lefi text.

2~5 OVERVIEW OF THE MOBSCOB

This section presents the story board of the MOBSCOB

13

PHYSICAL DESIGN

Horne~ Away

I Qi I

_____I Q2 _____I

I I Q3 I I

I Q4 _____

___ OTI I~

I I 0T2 I I

I FS I_____

o~p

This is how the user interface will look like:

Qi up to Q4: are representing the quarters in the game

OT1 and 0T2: are representing the overtimes in case it happens

FS: final score (showing the score at the end of the game).

As the above physical design shows the user interface of the MOBSCOB is

comprised of cells.

14

Incase home and away teams have equal scores you will choose in the options to

go to overtime (0T1) & (0T2) then afier the game ends the final score (FS) will be

displayed.

15

CHAPTER 3

RESEARCH METHODOLOGY

3.1 REQUIREMENTS ELICITATION METHODS

3.1.1 Prototyping

A prototyping methodology is a software development process which allows

developers to create portions of the solution to demonstrate functionality and make

needed refinements before developing the final solution.

Some of the prototypes will be presented to the supervisor and our fellow students

for their critique to be noted down as we try to refine the app to meet their

requirements.

3.1.2 Storyboard

A storyboard is a technique for illustrating an interaction between a person and a

product (or multiple people and multiple products) in narrative format, which

includes a series of drawings, sketches, or pictures and sometimes words that tell a

story.

Designers can create storyboards to specify how a user interface changes in

reaction to userst actions and to show things that are external to the system. Good

storyboards allow design teams to get a feel for the flow of users’ experiences.

They are generally not very detailed and use the minimum amount of detail

required to get key points about the big picture across.

16

3.1.3 Bene fits

The main benefit of storyboarding is that it illustrates what the interface would do

or how it will behave in response to user input, as opposed to a detailed user

interface design that shows what the interface would look like (Landay & Myers,

1996). Additional benefits of storyboarding are understanding how technology

reshapes human activity and influencing the understanding of the reaction to a

system (Troung, Hayes & Abowd, 2006).

Storyboards are also a good way to help members of the project team visualize

how an experience will work.

3.1,4 A dvantages

• Is more meaningful than flowcharts and other more technical diagrams for

conveying the user experience.

• Is vague enough that the audience will pose questions that are useful for

requirements gathering, functional design, and the impact of the

environment on product use.

Is a way to gain early-stage design feedback

• Does not require programming skills

• Does not require artistic skills

• Provides a quick way to sketch design ideas

• Complements verbal scenarios

• Provides support for personas and scenarios

• Provides a way to organize use cases into a coherent description of users~

actions

• Helps stakeholders to visualize an experience

17

3.1.5 Disa dvantages

• Interaction between the storyboard and a user is limited (Landay & Myers,

1996).

• Project team members may be reluctant to hand-draw if they feel that they

are bad at it.

• While the storyboard method has face validity, there are few data on the

effectiveness of storyboards for user interface design.

• Traditional storyboarding as done for movies is a linear process. Since

computer products and Web sites can be non-linear, interactive storyboards

(Wodtke, 2003) are more desirable, but take more time to design and

program.

Not practical for detailed design or covering all use cases.

3.2 SYSTEM DESIGN TECHNIQUES

3.2.1 UML

UML is a general purpose notational language for specifying and visualizing

complex software, especially large object-oriented projects. UML has emerged as

the software language for analysts, designers, and programmers alike, because

gives everyone from business analyst to designer to programmer a common

vocabulary to talk about software design.

3.2.2 Struct ured diagrams

Class Diagram: a diagram that shows a collection of declarative (Static) model

elements, such as classes, types, and their contents and relationships. Other types

of UML structure diagrams are:

• Component Diagram

18

• Object Diagram

• Deployment Diagram

• Package Diagram

Composite Structure Diagram

3.2.3 Behaviors diagrams

Use Case Diagram: a diagram that shows the relationships among actors and the

subject (system), and use cases.

Other types of UML behavior diagrams are:

Activity Diagram

State Machine Diagram

Sequence Diagram

Interaction Overview Diagram

Collaboration Diagram

Timing Diagram

3.2.4 ~mp~ementation techniques

During this research we will be using DSDM (Dynamic system development

methodology) which is one of the different AGILE software development

methodology. The DSDM methodology is comprised of 3 main phases:

Pre-project phase, project life-cycle phase, and post-project phase.

For us we will be interested by the project-life cycle. And this phase is comprised

by 4 different stages:

V Feasibility study

V Functional Model Iteration

V Design and build Iteration

19

V Delivery

3.2.5 Stagel: Feasibility Study

1. Desirability Analysis of the Available Options:

a. The following table delineates the available technologies and tools

used for developing this application.

Option Description

JME It is a Java Platform, Micro Edition (Java ME) that

provides a robust, flexible environment for applications

running on mobile and embedded devices: mobile

phones, set-top boxes, Blu-ray Disc players, digital

media devices, M2M modules, printers and more.

LWUIT Lightweight User Interface Toolkit (LWUIT) is a

Widget toolkit developed by Sun Microsystems to

enable easier Java ME user interface development for

existing devices. LWUIT is inspired by Swing and

supports many of its features including pluggable look

and feel, layout managers, etc.

NETBEANS NetBeans IDE and NetBeans Platform are based on

software from netbeans.org, which has been dual

licensed under the Common Development and

Distribution License (CDDL) and the GNU General

Public License version 2 with Class path exception.

MACF11NES PCS that we are going to use —_____

20

2, Feasibility Analysis of Options by Order of Desirability:

a. The following table delineates the driving requirements for the

application to be developed.

Driving Description

Requirement

Displaying the Application should be displaying the running

running score score in a game.

Displaying the Application should be displaying the running

running score per score in a game for each quarter

quarter

Good looking user The user should interact with the application

interface through a good looking user interface

Ease of use The application should be easy to use

b. The following table delineates the known constraints for the

application developers.

Constraint Description

Time Reporting deadline

Cost(money) Money for internet, airtime for communication

3.2.6 Stage 2: Functional Model Iteration

In this stage we will convert the requirements that have been identified in the

previous stages in a functional model. This model consists of both a functioning

prototype and models. Prototyping is one of the key project techniques within this

stage that helps to realize good user involvement throughout the project. This

prototype is reviewed by our guide in order to assure quality, testing is

21

implemented throughout every iteration of DSDM. This stage will be having four

sub-stages:

Identification Functional Prototype: here we will determine the

functionalities to be implemented in the prototype that results from this

iteration.

Agree Schedule: Agree on how and when to develop these functionalities.

Creation of the Functional Prototype: in this sub-stage we will develop the

prototype

o Review of the Prototype: Check the coffectness of the developed prototype.

This will be done via testing by our project guide.

3.2.7 Stage 3: Design and Build Iteration

The main focus of this stage will be to integrate the functional components from

the previous phase into one system that match with the requirements. It will also

address the non-functional requirements that have been set for the project. Again

testing will be an important ongoing activity in this stage.

This stage will also be subdivided into four sub-stages:

o Identification of the Design Prototype: Identification of functional and non

functional requirements that need to be in the tested application.

o Agree Schedule: Agree on how and when to realize these requirements.

o Creation of Design Prototype: a full prototype of the application will be

created at this sub-stage

o Review Design Prototype: Check the correctness of the designed system and

again tested and reviewed by the project guide.

22

3.2.8 Stage 4: Implementation

In this stage, the tested application including its documentation is delivered to the

project guide and the project report will be handed in to the college of applied

science and technology.

3.3 TESTING TECHNIQUES

3.3.1 White-box testing

White-box testing (also known as clear box testing, glass box testing, transparent

box testing, and structural testing) is a method of testing software that tests internal

structures or workings of an application, as opposed to its functionality (i.e. black-

box testing). In white-box testing an internal perspective of the system, as well as

programming skills, are used to design test cases. The tester chooses inputs to

exercise paths through the code and determine the appropriate outputs.

While white-box testing can be applied at the unit, integration and system levels of

the software testing process, it is usually done at the unit level. It can test paths

within a unit, paths between units during integration, and between subsystems

during a system—level test. Though this method of test design can uncover many

errors or problems, it might not detect unimplemented parts of the specification or

missing requirements.

White-box test design techniques include:

Control flow testing

Data flow testing

Branch testing

Path testing

23

According to (http ://en.m.wikipedia. org/wiki/Black-box_testing).

3.3,2 Black-box testing

Black box diagram

B lack-box testing is a method of software testing that tests the functionality of an

application as opposed to its internal structures or workings (see white-box

testing). Specific knowledge of the application’s code/internal structure and

programming knowledge in general is not required. The tester is only aware of

what the software is supposed to do, but not how i.e. when he enters a certain

input, he gets a certain output; without being aware of how the output was

produced in the first place. Test cases are built around specifications and

requirements, i.e., what the application is supposed to do. It uses external

descriptions of the software, including specifications, requirements, and designs to

derive test cases. These tests can be functional or non-functional, though usually

functional. The test designer selects valid and invalid inputs and determines the

correct output. There is no knowledge of the test object’s internal structure.

This method of test can be applied to all levels of software testing: unit,

integration, system and acceptance. It typically comprises most if not all testing at

higher levels, but can also dominate unit testing as well.

According to (http ://sqa. fyicenter. corn/FAQ/Testing

Techniques!Whatjs_thepurpose_of_black_box_testing_.html)

Black-box testing checks that the user interface and user inputs and outputs all

work correctly. Part of this is that error handling must work correctly. It’s used in

24

functional and system testing.

“We do everything in white box testing: - we check each module’s function in the

unit testing”.

Who is “we”? Are you programmers or quality assurance testers? Usually, unit

testing is done by programmers, and white-box testing would be how they’d do it.

“- once unit test result is ok, means that modules work correctly (according to the

requirement documents)”.

Not quite. It means that on a stand-alone basis, each module is okay. White box

testing only tests the internal structure of the program, the code paths. Functional

testing is needed to test how the individual components work together, and this is

best done from an external perspective, meaning by using the software the way an

end user would, without reference to the code (which is what black-box testing is).

if we doing testing again in black box will we lose time and money?”

No, the opposite: You’ll lose money from having to repair errors you didn’t catch

with the white-box testing if you don’t do some black-box testing. It’s far more

expensive to fix errors after release than to test for them and fix them early on.

But again, who is “we”? The black box testers should not be the people who did

the programming; they should be the QA team -- also some end users for the

usability testing.

Now that I’ve said that, good programmers will run some basic black-box tests

before handing the application to QA for testing. This isn’t a substitute for having

QA do the tests, but it’s a lot quicker for the programmer to find and fix an error

right away than to have to go through the whole process of reporting a bug, then

fixing and releasing a new build, then retesting.

25

(http ://www.www.sofiwaretestingfundarnentals .com!diffrences-between-black

box-testing-and-white-box-testing) gives a comparison of the two testing

techniques.

3.3.3 Comparison of white box testing and black box testing:

Criteria Black Box Testing White Box Testing

Black Box Testing is a software White Box Testing is a sofiware

testing method in which the internal testing method in which the

Definition structure! design! implementation of internal structure! design!

the item being tested is NOT known implementation of the item being

to the tester tested is known to the tester.

Mainly applicable to higher levels Mainly applicable to lower levels

Levels of testing: Acceptance Testing of testing: Unit Testing

Applicable ToSystem Testing Integration Testing

Generally, independent SofiwareResponsibility Generally, Software Developers

Testers

ProgrammingNot Required Required

Knowledge

ImplementationNot Required Required

Knowledge

Basis for Test —

Requirement Specifications Detail DesignCases

3.3.4 Usability Testing

According to (http :!!en.m.wikipedia.org!wiki!Usability testing)

26

Usability testing is a technique used in user-centered interaction design to evaluate

a product by testing it on users. This can be seen as an irreplaceable usability

practice, since it gives direct input on how real users use the system. This is in

contrast with usability inspection methods where experts use different methods to

evaluate a user interface without involving users.

Usability testing focuses on measuring a human-made product’s capacity to meet

its intended purpose. Examples of products that commonly benefit from usability

testing are foods, consumer products, web sites or web applications, computer

interfaces, documents, and devices. Usability testing measures the usability, or

ease of use, of a specific object or set of objects, whereas general human-computer

interaction studies attempt to formulate universal principles.

27

CHAPTER 5

IMPLEMENTATION OF THE TOOL

5.0 Introduction

This chapter gives an overview of the implementation and explains how users can

navigate through the newly developed application in order to use it easily.

5.1 Form input and Interface Design

The tool was developed as an interactive mechanism between the user at the

interface and the Mobile device. This tool enables a user through a given interface

to enter and view the points entered. These activities were achieved using Java 2

Mobile Edition (JME) example shown in Appendix.

Light Weight User Interface (LWUIT) provides a very attractive user interface

design capability that would captivate the user’s attention. The interfaces were also

kept as basic and simple as possible for easy public use of the tool; some of the

interfaces created include the following:

28

).. suP - ..~.. ri_ti

.~r.l.. .Lwst ~i. r’ 1e1 b s.~ It ~.

, :c ..‘: ‘t rrj4.. tic- t...- .x:

-4-- C)

1 ebhCU*flfteaoere

~SiWeW S4QSflCCW ‘Wet aaz ‘I

a hew

-—3

C

flgure 1: Opening screen

Thisiswhereanewuserstarts(inthefigureabove);theindividualisrequiredto

select the play button on the application. When this button is pressed the

application then makes a transition to the next interface where a menu is given.

Allthiswhiletheuserisgiventhefreedomtoexitatanypointduringtherunning

ofthe application as the exit button exits on all the interfaces.

If the individual selects the exit button, the application will exit without asking the

user for any more details.

29

If the user selects the play button then the application proceeds to provide a screen

(fig. 5.2) where the user is required to make a choice from a drop down list which

consists of

• Game summary

Begin

• Exit

Game summary is used to display help on how to use the application

Begin enters you to the main application menu where you can now start the actual

functions of the application that is recording the points.

The exit button destroys the application.

—J — •— t -- : -- r,-r I

—— [~—I,

Figure 2: ~enu list

30

~UIt ~—h~i~c1

~pplic~ticn Dc. ice Edit vIe’~ Help

Dc’ ‘cc ID: 6 Phone number: 123456739

a

___________________________________________________________________ I

31

Figure 3: application transition after selecting begin

The next page is the real applications page where the user can now record the

poims as the game proceeds.

• ~ r;._ Edit

:i$ure nd Screen

32

5.3 Shortcomings with the Tool

The application implemented is hindered by the following factors:

1. There are limited phones with this JME API to fully implement the

application as most people have switched to the android platform.

2. It does not have a backed database where users can refer to previous records

between two teams that have met before.

3. It is not possible to edit the scores like subtracting points incase points have

to be deducted because of too many team fouls accumulated.

5.4 Tool Security

The Java API’s used in the development of this application already have

predefined security measures embedded in their development.

5.5 Testing and validation

Traditional software testing procedures were used for MOBSCOB where testing

takes place throughout the development process.

5.5,1 Res ults of VaNdation

Selecting the Subject: two (2) of respondents were selected from college of

business studies three (3) from school of social sciences, two (2) from school of

engineering. Distributing subjects among colleges was done to get a general

opinion from a wider area.

33

Analysis of results from respondents: Table 5.1 is an analysis of response from

respondents to particular questions on the questionnaire, the final result is a

comparison of positive response in percentage compared to that of negative

response.

I Qn No, +ve -ye Implication of response

2 10/10 0/10 All respondents agree that

they have ever watched a

basket ball game

3 10/10 0/10 All respondents agree that

there are weaknesses in the

current system of voter

registration

4 9/10 1/10 A good number recommends

standard mobile pointing

system

5 8/10 2/10 The bigger number think the

MOBSCOB ~41l reduce

weaknesses in the current

pointing system process

6 8/10 2/10 The bigger number

recommend that the

MOB SCOB is easy to use

34

Conclusion: Response from 95% of the respondent shows the tool being a good

idea to solve current pointing problems, easy and cheaper to use for recording

points.

CHAPTER SIX

DISCUSSION, RECOMMENDATIONS AND CONCLUSION

6.0 DiscussIon

The newly developed Mobile Basketball Scoreboard application will be used to

reduce or even solve problems experienced while using the paper based point

recording system as it helps in quick generation of reports referees and fans these

reports can be used for monitoring the game in play and decision-making.

In this project researcher created a mobile application called MOBSCOB for

umpiring a basketball game. The game is developed for Java Enabled devices and

is a standalone application. The objectives of this project was to develop a feature

that will enable the fans, umpires, players and coaches to record points in a

basketball game.

62 ProJect Accomplishments

Researcher has been able to accomplish all the objectives of the projects. More

evidence on the accomplishments will be shown in the Appendix A.

6.3 LImitations

Despite the accomplishments of the project; there are a number of limitations with

regard to the implemented system that have been highlighted during the course of

the application design and Development:

• Lack of enough online support for liaison with different forums on Mobile

Technologies.

• Application development is very tedious and requires logia

36

• Lack of enough material.

• Lack of books and other materials that have the necessary information about

mobile gaming.

• Lack of enough time to conduct more researches in relevant and related

projects.

6.4 Recommendations

• There is need to port this application to other mobile platforms as most hand

held devices are using android Os.

• There is also need to develop a backend database for the application so that

it can keep results of previous encounters which can be used to do

comparisons and generate statistics.

• A keypad edition of the application will also be needed to penetrate the

general market because the application is currently only for touch screen

enabled devices.

6.5 Conclusion

Despite the setbacks encountered during the development of the application, the

researchers feel that the project has been successful. Researcher looks forward to

the day when the game will available in ovi market place for people to download

and use in their handheld devices.

37

REFERENCES

http://sqa.fyicenter.corn/FAQ/Testing-Techniques/What is the purpose of black box testing .html.

(n.d.). What is the_purpose of black box testing html. Retrieved march 31, 2012, from

www. sqa. fyicenter. corn: http://sqa.fyicenter.com

http://www.l inkedin.com/jobs/jobs-Software-Engineer--2426884? rnSplash=1. (n.d.). jobs-Software

Engineer—2426884?mSplash=J. Retrieved march 31, 2012, from www.linkedin.com:

http://www.linkedin.com/jobs/j obs-Software-Engineer—2426884? rnSplash= 1

http://www.www.softwaretestingfundarnentals.com/di ffrences-between-black-box-testing-and-white-box

testing. (n.d.). dzffrences-belween-black-box-testing-and-white-box-testing. Retrieved march 31,

2012, from www.softwaretestingfundarnentals.com:

http://www. www. softwaretestingfundarnentals.com/diffrences-between-black-box-testing-and

white-box-testing

James Keogh. (2003). The Complete Reference. In J. Keogh, J2ME (p. 9). Chicago: McGraw-Hill.

prototyping-methodology. html. (n . d.). Retrieved march 31, 2012, from www. information-management

architect.com: http ://www. information-management-architect.corn/prototyping

methodology.html

prototyping-methodology.himl. (nd.). Retrieved march 31, 2012, from information-management-

architect: http://i nformation-management-architect/prototyping-methodology. html

Heiko Bock. (2011). TheDefinitive Guide to the NetBeans Platform 7. In H.Beiko, (p. 223). Apress,USA

Steve McConnel. (2008). A Practical Handbook of Software Construction. In S. McConnel, SE (p. 150).

Chicago: McGraw-Hill.

38

APPENDIX A

Sample of questionnaire used for gathering data

QUSTIONAIRE

Surname

Other Names~

College~

I. Are you a basketball fan? Yes No

2. Have you ever watched a basketball game?

Please explain if other Yes No

3. If yes, did you understand the pointing system?

Yes E~ No

Please explain if other

4. Did you feel a need to try and have a better point

recording system? Yes No

5, Did you feel a need to try and have a better point Yes No

recording system?

Please explain if other

39

6. Would you feel closer to the game if you could help Yes ~ No

count the point for your team during the game using

a mobile device?

If Yes please explain why it would help you?

If No please explain why it would help you?

40