sms messaging from the computer desktop - university … · sms messaging from the computer desktop...
TRANSCRIPT
SMS Messaging from the Computer DesktopPeter Coleman
Computing BSc2003 / 2004
The candidate confirms that the work submitted is their own and the appropriate credit has been givenwhere reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be consideredas plagiarism.
(Signature of student)
Summary
The project was about communicating from the computer desktop, to the mobile phone through the use
of text messages, and vice versa. The initial concept behind the project was to provide a flexible andalmost instant tool for communication, when other forms are not as suitable as SMS.
The project was developed under the supervision of Cy-Nap. The main deliverable for the projectwas an application that could send and receive messages, amongst other features.
i
Acknowledgements
Thanks to Andy McCall, Ben Moxon and Steve McCann from Cy-Nap for the continued patience and
help.
Thanks to the folks for the support over the last four years.
I would also like to give a big vote of thanks to my supervisor Karim Djemame who was a massive
help in getting the project off the ground.
Finally, I would like to offer my thanks to everyone who helped plan and test the application, par-
ticularly to Stuart Roberts, and Charlie Brown, without whom, the final product would not be what itis.
ii
Contents
1 Introduction 11.1 Aim of project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 SMS Report 32.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Introduction to GSM network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Network overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Components involved in sending and receiving messages . . . . . . . . . . . . . . . . 5
2.3.1 SMS mobile orientated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.2 SMS mobile terminated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Components of SMS message frames . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Modelling the system 83.1 Z Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Requirements Capture 114.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Fact finding techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Techniques to use for the SMS application . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Interview techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.5.2 Requirements report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
iii
5 Usability 185.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Page layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.1 Simplification and reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2 Contrast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.3 Repetition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1 What should navigation do? . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3.2 Navigation styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4 Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.1 Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4.2 Colour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4.3 Style sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Design of Application 236.1 Component hierarchy of system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.1 Original design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.1.2 Updated design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Individual components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3.1 Java API vs XML API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3.2 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3.3 Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3.4 JDBC vs OJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.5 Class diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3.6 Flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.6.1 Sending a message . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3.6.2 Receiving a message . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.7 Server database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.8 Mapping existing information system to application . . . . . . . . . . . . . . . 32
7 Implementation of application 347.1 Differences in current implementation from original design . . . . . . . . . . . . . . . 34
7.1.1 Database connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.2 Sending XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1.3 Managing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.1.4 External recipients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.5 User groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.6 Other methods of sending messages . . . . . . . . . . . . . . . . . . . . . . . 36
iv
7.1.7 String parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 Problems encountered during implementation . . . . . . . . . . . . . . . . . . . . . . 37
7.2.1 XMLHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.2.2 SMSStatusThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.3 Other issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3 The client interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8 Evaluation 418.1 Evaluation criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.2 Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.1.3 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2 Reasons for selecting criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.3 Comparison with other applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.3.1 EduTxt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.3.2 Ipipi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.4 Evaluation of the produced solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4.1 Stuart Roberts’ evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.4.2 Simon Stevens’ evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4.3 Other points to consider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Bibliography 53
v
Chapter 1
Introduction
1.1 Aim of project
The project shall be undertaken on behalf of an external company, Cy-Nap. This company is a smallsoftware development business, whose head office is in the centre of Leeds. Much of their work is
centred around SMS technology being available from the computer desktop.
The aim of the project is to plan, design and implement an application that sends and receives SMS
messages to and from the computer desktop. The project shall model each of the key stages of the soft-ware development life-cycle, from early planning to program testing and verification.
The project is of particular interest due to the way mobile telephones have become a permanent fix-ture within society, and the way modern communication has changed because of it. Most people own a
mobile telephone, and this is their closest point of contact. Creating an application that interfaces with
this popular hand held device could provoke some interesting features. The distributed nature of theproject is of great personal interest.
1.2 Objectives
1. Developing an understanding of SMS technology.
2. Investigate current SMS solutions and provide a critical response.
3. Gain experience of how a system is built in each stage of the software life-cycle.
1
4. Produce a fully working application.
5. Gain experience on how desktop applications can interact with mobile technology.
1.3 Minimum Requirements
1. Research and create list of user requirements for proposed application.
2. Critically consider existing SMS messaging solutions, with the intent to apply findings to the finalapplication.
3. Depending on research; design formal software design plans.
4. Create an application that sends and receives SMS messages.
5. Create test plans, and apply them to application; record results of test plans.
2
Chapter 2
SMS Report
2.1 Introduction
SMS, or Short Message Service is a service available to users of wireless networks, GSM, Global System
of Mobile Communications is the main one. These networks are accessed via PCS Personal Communica-
tion Service [15]. Typically this method of communication originates from a user of a mobile telephone,
and is sent to another user of a mobile telephone.
SMS messages tend to be on a point-to-point basis. Although broadcast SMS messages are becom-ing increasingly popular, this method is still favoured. The short part of the acronym relates to the
relatively small amount of characters permitted in an SMS message frame - 160 [15]. SMS messages
are ideal to those whom need to communicate with another party, intending to send a very small amountof communication, e.g. I’ll meet you at 8:30 tonight at the White Lion.
SMS was never expected to have the impact upon personal communications as it does now. The fisrtSMS message was sent in 1992, through the Vodafone network. In just over ten years from its inception,
SMS has become one of the more popular ways to communicate. 50 billion text messages were sent inthe first quarter of 2001 [6], and has continued to increase.
The cost of sending an SMS message is comparatively cheaper than that of a traditional voice call.SMS is also popular due to the fact it is a form of asynchronous communication. This form of commu-
nication poses several advantages over synchronous communication, subject to the particular situation.
Messages may be picked up by the recipient when it is convenient for them. Should the user be oth-
3
erwise engaged (in a meeting, already in a voice call etc), or the network coverage is such that they
are unavailable, they may look at the message at a more appropriate time. This kind of facility is not
possible through synchronous communication. SMS messages may be stored in the message servicecentre, so if a user was to become unavailable due to network coverage, it may be forwarded to them
when they are within range.
2.2 Introduction to GSM network
2.2.1 History
The massive success of mobile communications has been particularly apparent for the last ten years.Mobile technology, particularly the use of radio for mobile communication is not as new a concept.
Some of the first work began in 1971 by the Bell Telephone Company [21]. This work introducedthe concept that we use today. The GSM network that is used worldwide first became standardised
in the 1980’s. The standardisation body “Groupe Speciale Mobile” were selected to develop a radio
communication system for Europe [9]. The fist GSM network was launched in 1991 [19, 21].
2.2.2 Network overview
There are three key components to the GSM network [19].
1. Radio Subsystem
2. Network and Switching Subsystem
3. Operation Subsystem
For the purpose of understanding GSM on the physical level, I shall concentrate on the radio subsystem.This subsystem contains two key elements - the mobile station and the Base Station Subsystem (BSS)
[19]. The BSS is comprised of two major entities. The Base Transceiver Station and the Base Station
Controller. Each BTS has its own radio cell - the entire BSS can be seen as a network of radio cells [19].
The BTS is the device that communicates with all mobile stations (wireless items using the GSM net-work - often mobile telephones). When the GSM started, each radio cell occupied a greater area [19].
However with the increase of people using GSM, the size of the cells has had to be reduced. Conse-
quently there is a larger chance a user will stray out of one cell into another. As such they will have tobe ”handed over” to another. The communication ceases with the original BTS and is switched to the
cell the user has moved to [6]. This function, amongst others, is handled by the Base Station Controller.The BSC can be seen as a gateway between the radio subsystem and the network subsystem [21]. This
is similar to the datalink layer on the OSI 7 layer stack - connecting the physical layer to the network
layer.
4
2.3 Components involved in sending and receiving messages
In order to communicate using SMS, there needs to be several key network components. Without any
of these it becomes impossible to communicate in this manner. There is a significant difference in theflow of control between sending messages, and receiving them. Figure 2.1 demonstrates the difference
between sending and receiving.
Mobile−Orientated
MSC
SMS−IWSMC
ServiceCentre
Mobile Terminated
ServiceCentre
SMS−GMSC
HLR
VLR
MSCBSS
Figure 2.1: Network Components
2.3.1 SMS mobile orientated
This method of communication refers to the sending of an SMS message. The following models thecontrol path of this method, and the appropriate network components used in order to do so.
The message must first be written to the mobile device. Most mobile communications devices thatsupport SMS have facilities to do this. Modern mobile telephones all contain software to create a mes-
sage on the actual device. It is also possible to connect the device to a personal computer, and have the
5
computer create the message.
The message is first sent to the Mobile Switching Centre (MSC). This component of the SMS archi-tecture is similar to a traditional PSTN telephone exchange. It is able to, using other components, gather
information on all subscribers within its area.
From the MSC the message is sent to the Short Message-Interworking Mobile Services Switching Centre
(SMS-IWSMC). In this context we can think of the SMS-IWSMC as a gateway between the MSC andthe Service Centre (SC).
The SMS-IWMSC forwards the message onto the SC. The SC then takes full responsibility of themessage. As far as the sender of the message is concerned, the message has been sent [21].
2.3.2 SMS mobile terminated
Mobile terminated communication relates to receiving a message. It takes place where the mobile ori-entated model finishes.
The message begins in the SC. This network component is similar to a router in a wired digital LAN. Itwill forward the message to the appropriate party. It has the extra functionality in being able to store the
message until intended recipient of the message becomes available, or the specified time period expires.
The message is then forwarded to the Short Message Service-Gateway Mobile Services Switching Cen-
tre (SMS-GMSC). Similar to the SMS-IWSMC, this component acts as an interface between the SCand the MSC. To check the appropriate MSC for the recipient of the message, the SMS-GMSC checks
the Home Location Register. The HLR is a database containing information on all subscribers’ handsets
[19]. The HLR will also have information on the availability of the intended handset. Should the recip-ient be marked as unavailable, an appropriate flag is marked, and the message is sent back to the SC to
wait until the recipient is available.
If the user is roaming (i.e. not in their home area) [21], the Visiting Location Register (VLR) is contacted
to try and locate the appropriate MSC for the recipient. Once the correct MSC for the recipient has beenidentified (called the visiting MSC [15]) the VLR is contacted. This is a similar component to the HLR,
containing information on all the subscribers within the visiting MSC [16]. The VLR returns the exact
information on where the recipient is in. The message is then sent to the Base Station Sub-System (BSS),which will send the message to the intended recipient using the GSM [19].
6
2.4 Components of SMS message frames
As the way of sending and receiving SMS messages is different, it is no surprise that the contents of
the SMS message frames are also different. Both types of message frame appear similar to that of anIP packet; the first part of the frame encapsulates all the information required to send the frame in the
desired format. The second part is significantly larger than that of the first, and contains the contents the
sender of the message wishes the recipient to receive.
SMS message frames are composed of octets (8 bits). The amount of octets depends on the lengthof the message to be transmitted. The first 18 octets are devoted to the message header - all the informa-
tion required for the message to reach its destination, and in the correct format. The remainder comprise
the text of the message. Up to 140 octets can be used to create the actual message.
There are several key flags within the frame. The most fundamental of these are the status flag, and
the reply flag, included in both SMS-MO and SMS-MT. The status flag tells the service centre whethera status report is required. The reply flag tells the service centre whether the sender has paid for the
receiver to reply to the message. The receiver will not pay for a message if this flag has been set.
2.5 MMS
MMS stands for Multimedia Messaging Service. It is one of the technologies available to consumersthrough the 3G network. It allows messages to be filled with rich content, such as sound, and images.
MMS has the potential to make an impressive move on the mobile market. The ability to send picturesis novel, and simple enough to sway people from standard SMS. However, the idea of MMS is virtually
the same, little useful functionality, in terms of communication. If people wish to arrange meetings etc,
they will still be forced into using the text part of this system.
It would be theoretically possible to use MMS for this project, but the nature of the project is a commu-
nication tool. MMS is used for sending images and other multimedia content. SMS provides a simplertext-based communication, which is more relevant to the project than MMS.
7
Chapter 3
Modelling the system
It has been suggested that software development is an engineering process [4]. In traditional engineeringdisciplines, people would not begin a project without having done prior planning, and formalised these
plans. When a house is built, an architect is hired to draw a rigid plan so the builders may implement
it. If software can be seen as a form of engineering, then we should be using similar forms of planningbefore implementation is begun [17].
Booch et al coin the term “model” when discussing formalising implementation plans [17]. A modelis said to be a “simplification of reality” [17]. How is this useful to software engineering? Software
applications are significantly larger and more complex than their humble beginnings [4]. As such, whena software application is to be implemented, it can seem dauting, as much as telling somebody to build a
car would be. The notion of the model serves as a simpler abstraction of the intended application. Once
we reduce the application into simpler, understandable components, then we may begin to implement it[17].
3.1 Z Specification
The Z language is significantly different from visual modelling languages such as UML. It is a par-
ticularly strict notation. The idea behind this is to represent software design using rigid mathematicalnotation [20]. There is no ambiguity in mathematics - 2 + 2 equals 4 - it is impossible to be confused by
this statement. Therefore placing software design in to such a rigid format should alleviate issues suchas ambiguity, incompleteness, vagueness and contradiction [20].
8
The Z specification is similar to set theory in mathematics. Objects are simply sets. Functions can
be applied to the sets to create new sets. Specialised objects are merely subsets of the original object.
Z is a particularly efficient way of showing the data-flow of applications [20]. The rigid notation of Zis an advantage, but can also be seen to be a disadvantage. Z would be well suited to certain types of
applications, particularly information driven applications. But what of other forms of application, such
as computer games? I would not like to be responsible to design such an application in Z.
Similarly, Z has no concept of external barriers. Many software applications are distributed, yet Zhas no real way of representing this. Whilst I appreciate the mathematical notation for its strict rules,
and lack of ambiguity, it is not something I feel completely comfortable modelling an entire system on.
I feel that a great deal of time would be spent trying to decompose the application into Z, which is notsomething I can easily afford to do. As such, I will be choosing to model the application in UML, both
in terms of requirements and design.
3.2 UML
The Unified Modelling Language arose due to a need to bring together various forms of object-orientatedtechniques under a single process [17]. Before UML, there were over 50 separate techniques for mod-
elling object-orientated applications [17]. There are obvious issues with having so many separate tech-niques. With such a large amount, how does one pick the appropriate method to use? Similarly, there
could be occasions where one part of the development team use a modelling technique not used, or un-
derstood by another team. UML has been created with object-orientated systems in mind [17]. This willprove useful to me - I only have experience with object-orientated languages, and will hopefully imple-
ment the software in object-orientated manner. A modelling language created bearing this paradigm in
mind should make it easier to phrase my design ideas.
One of the fundamental parts to UML was the “use-case” diagram [17]. Previous modelling techniquesdid not cater for modelling user requirements in quite the same way as use-cases do [17]. Booch et al
tell us that a technique named “scenarios” was available, but did not present the requirements in the
simple effective way that use cases do [1]. Use case diagrams focus on what the external objects (i.e.those objects interacting with the system, but not actually part of the system [1]) would like to do. The
external object, called actors [17], are only concerned with what the system does, and not how. This
difference is important, if we are to concentrate solely on what an actor requires the system to do, weare more likely to be catering for them, rather than what we think the system should do [1].
This brings us to one of UML’s core advantages - it can model many aspects of a system, from high-level
requirements specification to detailed algorithm specification. This is a key advantage - software devel-
opment is not as linear as going from idea to program code. There are many stages in between inception
9
and completion, and all should be looked at to help produce a successful application [1]. Using UML,
we are able to document each stage in the software life-cycle. Not only this, but the application may be
modelled using high-level, low-level or a combination of the two styles. Rigid formalised methods suchas Z do not permit such flexibility.
Another of UML’s advantages is its visual element. Each method for modelling a system is expressedvisually. This results in the models being fairly easy to comprehend [1]. A member of the development
team can take a UML design model, and interpret it with relative ease [1]. This is an important ad-vantage, the sooner design ideas are realised, and accepted, the sooner implementation can begin. The
simplicity of UML does suggest it is a successful modelling language. As discussed before, the purpose
of a model is to decompose a complex notion into a simpler abstraction. The mathematical nature offormal methods such as Z is generally harder to understand than the graphical methods in UML.
Perhaps one of UML’s greatest assets is its extensibility. There is a generic framework that each docu-
ment of a certain type will share with others of the same style. However, designers may employ several
techniques to shape the model into something more appropriate for their system [17]. This means UMLis not a particularly rigid language. Systems will all have a unique element to them [1], if we can ex-
tend the modelling language to represent the system to a higher degree of accuracy, then this is of clear
benefit to the designer.
10
Chapter 4
Requirements Capture
4.1 Introduction
Determining requirements is often described as the first stage in developing software [8, 5]. Withoutadequate requirements on which to base a system around, we are not fully catering for the users, which
defeats the point in developing the system.
Senn describes requirements as the process whereby current business processes are analysed, and where
improvements could be made [18]. Senn defines a requirement as a feature that must be included in thesystem [18].
Many sources identify discovering the business processes within the organisation as paramount to therequirements capturing process. It is less important to focus on what the user wants to do. Senn suggests
that users of a system rarely provide enough accurate information of what functions the system should
perform, without any organisational context [18]. It is better to focus on the business processes andexisting systems for executing these processes. These are what the system should be modelling.
There are different forms of requirements. Bennet identifies three key types of requirement [5]:
Functional requirements allude to exactly what the system should do. Functional requirements formthe basis of the proposed system’s functionality. This type of requirement can be seen as a verb - i.e. “I
want the system to...”.
11
Bennet suggests that non-functional requirements describe aspects of the system, in terms of how well it
provides the functional requirements [5]. If functional requirements can be seen as verbs, non-functional
requirements can be viewed in turn as adjectives. For example “The system should perform (functionalrequirement) quickly.”
The International Standards Organisation describes usability as the “degree to which specific users canachieve specific goals within a particular environment; effectively, efficiently, comfortably and in an
acceptable manner” [5]. Usability requirements are often associated with Human Computer Interactioni.e. how easy it is to perform a specific task.
4.2 Fact finding techniques
There are many fact finding techniques that help acquire requirements for a system. Mason identifies
six types of fact finding techniques [22]:
� Interviews
� Questionnaires
� Focus Groups
� Record Inspection
� Telephone surveys
� Observation
Mason attributes each method with various advantages and disadvantages. Each technique is relevant
to a specific situation [22], and as such there is no generic “right answer” to choosing the appropriatetechnique. We must analyse the situation and choose the relevant technique.
There are four main reasons for conducting an interview according to Mason. He suggests that in-terviews provide the following benefits to the systems designer [22]:
� Achieving information from people that may not be otherwise available.
� Communication between designer and stakeholders is initiated - thus gaining their support and
knowledge.
� Information from other sources may be verified.
� Unexpected information can arise through the course of the interview, especially through the use
of unstructured interviews.
12
Other advantages concerned with interviews are [18]:
� Personal contact allows the interviewer to be responsive and adapt to what the interviewee says.This is harder to replicate in other forms, especially questionnaires and record inspection.
� The interviewer can gain a stronger grasp of the personss work than through other methods.
It is suggested that interviews are particularly good at eliciting “use case” requirements [8]. Use cases
are textual descriptions of how the proposed system should operate, according to the customers [8]. Thisis obviously of great use to the developers of the software. They gain an idea of what functionality the
system should encapsulate.
Interviews are also of great use as they are performed in a one-to-one situation. This eliminates a
problem with focus-groups; getting a group of people within an organisation to meet at an agreed timeand place. This can prove difficult within a busy organisation.
4.3 Techniques to use for the SMS application
Ideally I would like to gain information on how various people communicate within the school of Com-
puting, with respect to their respective organisational role. Furthermore I would like to gain an under-standing of the short-comings of their existing systems of communication (if any). I would hope to
identify whether the proposed SMS system could solve these problems.
Creating an application that solves problems requires close scrutiny of existing processes and systems in
order to find these problems. Also, as the proposed application will be created for these users in mind, Iwould like to discuss how they feel the application should work.
Due to the need to gain a full understanding of the processes and roles within the school of Com-puting, certain fact-finding methods are inappropriate. Neither questionnaires or analysis of documents
will provide enough accurate information on which to build an application. They do not produce the
same kind of unexpected information that we get from face-to-face meetings.
The nature of the project imposes strict time limits, which precludes observation as the primary fact-finding technique. Focus groups would be a useful method - as it allows the stakeholders to bounce
thoughts and ideas off of one another. One person’s response may provoke a response from others that
may not have been found through a standard interview. The main reason for not using focus-groups isthe difficulty in trying to get representatives from the various roles in the same room at the same time.
Once again time restrictions come into place - it is simply not feasible to wait for a week until everybody
becomes free.
13
It is for these reasons that I have decided to perform interviews as the primary fact-finding technique.
Most of the sources I have read, Bennet in particular, identify interviews as the key technique for re-
quirements capture.
4.4 Interview techniques
Mason provides us with a comprehensive list of good interview techniques. These opinions are shared
by several other sources. I have outlined the key ideas on how to hold a good interview based on Mason’s
thoughts [22].
1. Preparation
2. Use appropriate language and style
3. Avoid using yes/no questions
4. Don’t express own opinions
5. Try to distinguish between fact and opinion; need and desire
6. Confirm the data collected
7. Always conduct yourself appropriately
8. Be polite.
9. Turn up on time.
10. Avoid interrupting people.
11. Ensure interview does not go on past the agreed time.
12. Provide follow-up information
4.5 Requirements specification
Early on in the project, I met with Cy-Nap, the company I am doing the project for. I spoke with Steve
McCann and Andy McCall, the managing director, and head of the development team respectively. My
main reason for going, apart from introducing myself was to investigate what they wanted the intendedapplication to do. I assumed that as they had offered the project to the University, they had some idea
of the intended application. However, neither Steve nor Andy put down any ideas of how they saw the
final application. They wanted to see what form of application I came up with, with no input from them.They felt that as a university student, I would develop interesting ideas they had not thought of, and did
not want to prejudice my design decisions.
14
This then put me in an unfamiliar position. I had assumed the requirements, or at least the main re-
quirements of the application would have been put forward by Cy-Nap. It meant that I would have toform the requirements of the project myself. I was unsure about who to ask at this point - as it was a
project, and not a software application, there were no people that needed or wanted the application de-
veloped. I decided to look at the project as if it was a software application that the school of Computinghad called to be developed. As such, I needed to speak with potential users within the school, and these
people would form the bulk of my requirements analysis. I decided to speak with Stuart Roberts, CharlieBrown, Maureen Hopkinson and Shaheen Bibi. I felt these people represented a suitable cross-section of
the roles within the school of Computing. I interviewed these people, and their responses helped me to
draw up an official requirements list, represented by a use case diagram, and a requirements document.
from app.messagesReceive
Sendmessages toapplication
Retrieverecipientinformation
Receivemessages
Send messages
View messagessent
Check thestatus of messages
Creategroups of users
View messagesreceived
Send messages by
group
Removeunwanteddata
User ofsystem
Recipients
<<extends>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
Figure 4.1: Usecase diagram
4.5.1 Use case diagram
Figure 3.1 shows the use case diagram I have constructed based on the interviews and conversationswith potential stakeholders of the system. The only actors within the system will be those using the
application to communicate, whether they be sending or receiving from the application. Each user of
the system I spoke to wished to perform the same functions as the other, and as such, I did not break up
15
the users into their respective school of Computing roles.
4.5.2 Requirements report
Req no. Requirement Req. Type Textual description
1 Retrieve recipi-ent information
Functional The users must be able to use the application to retrievethe telephone number of the intended recipients.
2 Send messages Functional The users must be able to use the application to send SMS
messages. This is the primary function of the intended
application. NB This requirement has an includes rela-tionship with requirement 1. The users only want to send
messages after the desired recipients have been found.
3 View messagessent
Functional The users must be able to maintain which messages theyhave sent, and to whom. This is to prove communication
has taken place. NB Messages must be sent before they
can be viewed - hence the includes relationship with re-quirement 2.
4 Check message
status
Functional Users must be able to check the message has arrived. SMS
is not a robust technology. NB Messages must be sent be-fore they may be checked, hence the includes relationship
with requirement 2.
5. Create groups of
recipients
Functional The users feel that the same messages could be sent to
people in the same role. As such, they must be able tocreate groups containing recipients sharing the same role.
6. Send messages
by group
Functional The users wish to the same message to several recipients
by the use of groups. Recipients are to be placed into log-ical groups holding people of the same / similar role. The
message will then be sent to that group. NB This is a
specialised form of sending a message, hence the extends
relationship of requirement 2.
7. Receive mes-
sages
Functional The users want the recipients to be able to communicate
with them using the same medium. As such, the applica-
tion must be able to receive messages from recipients.
8 View messages
received
Functional The users must be able to check on messages received
by recipients, so they may refer back to them when
needed. NB Messages must be received before they maybe checked. This case includes requirement 7.
16
9 Remove un-
wanted data
Functional The users want the application to hold data (see require-
ments 3, 5, 8). They also want to be able to remove thisdata should it become redundant.
10 Integrate with
SIS
Functional The users have specified that the only way the system will
be of use, is for the application to use the existing infor-mation system used within the school of Computing - SIS,
to store recipient details.
11 Available on any
machine
Non-
functional
The users need the application to be accessible through
any computer. They want to use the application in excep-tional circumstances, and therefore cannot rely upon their
whereabouts.
12 Provide check-boxes to aid
with removing
data
Non-functional
The users have specified that using HTML form check-boxes would be the preferred way to select unwanted data
17
Chapter 5
Usability
5.1 Introduction
As being accessible through the web is a new requirement of the application, I must consider the userinterface. Usability is a fundamental part of any interface; there is little point in the application if users
struggle, or find it impossible, to use it. I feel that the SMS application must consider the user interface
as it is performing complex actions through a simple medium (HTML). It is therefore important toensure users can perform these actions with the expected simplicity of a web interface.
5.2 Page layout
The physical aesthetics of a web page are the first things a user sees, way before any content is realised
[14]. As such, the aesthetic qualities of a web page can have a direct impact on how the user feels aboutthe site in general. If the physical characteristics leave the web page awkward to navigate and unattrac-
tive to look at, they will be less inclined to use it [14]. Nielsen suggests that the amount of choice usershave over which sites they use leaves them in a position to not use sites that are difficult to operate [14].
Brinck et al suggest several key issues when considering the page layout. Each of these issues aidsthe designer in reducing the site’s complexity, and drawing users’ attentions to important parts of the
site; thus making it easier to navigate and comprehend [23].
18
5.2.1 Simplification and reduction
A page’s physical complexity may be analysed in terms of the number of vertical lines down the page
[23]. The elements in a page are rectangular, whether it is alignment through tables and margins, or
image boundaries. Each element should have a vertical line drawn down from its left hand vertical axis,providing the vertical line exists on a different x-axis to other elements.
It is suggested that there should be four or less vertical lines on a page exhibiting good page layout
[23]. The reasons given for this are that elements using different x-axis will grab a user’s attention -
they are noticeably different from other elements. Therefore the more elements grabbing a user’s at-tention, the more confusing it will be to the user [23] - what are they supposed to look at? It is also
suggested that the fewer elements that should stand out from the others allows the user to focus upon
the more important page elements [23].
5.2.2 Contrast
Contrast is similar to simplification and reduction, as it is once again a trade-off between drawing the
user’s attention to an element, and over-confusing them. Contrast in this context is about how differentpage elements are from each other. There are many variables that can lead elements to contrast each
other, for example, shape, colour and size [23]. If a particular element has a sufficiently different
variable from other page elements, it will draw a user’s attention to it. For example, imagine a web pagecontaining a title in size 30 text, and then a lot of black text in size 11. The title will immediately stand
out - it is significantly different from the other page elements.
5.2.3 Repetition
Consistency is suggested to be an important part of good design [23]. This aspect is not limited to sin-
gle pages, but more on the site as a whole. Consistent elements give the website a sense of unity and
make it easier to traverse [14]. If users can identify elements from page to page (for example title andhyperlinks) due to consistent page layout, they will be able to find this required information quicker [23].
Consistency breeds familiarity, similar conceptual groupings in the site will allow the user to becomemore familiar with the site as a whole [24]. It is suggested that the more familiar users are with a site,
the more likely they are to return to it. This is because there is no new learning involved [24]. Nielsenstates that his usability findings show that similarities are beneficial as they allow a measure of transfer
of skill from one site to the next [14].
19
5.3 Navigation
It is rare for any web site to be restricted to a single page. Certainly for the intended application, if it
is going to exhibit any sense of simplicity, it will have to be spread over several pages. This then raisesthe question of how we allow users to access other areas of the site in a simple, yet effective manner. If
the navigation technique employed is not effective, users will not be able to access parts of the site they
wish to, or not be able to return to a specific part of the site.
5.3.1 What should navigation do?
Nielsen suggests that the purpose of navigation is to provide the user with three key pieces of informa-
tion. The first part states that each page should clearly label itself differently from previous parts of thesite. The user should not have to spend time deciphering the page. Nielsen also suggests that pages
should not only be identifiable relative to the site’s structure, but to the web as a whole [14]. There are
several techniques that can be used to ensure this - site logos, consistent design, colouring etc [14].
Users should also be able to tell where they’ve been within a site. Nielsen draws upon the importance
of standard HTML colouring for hyperlinks [14]. When a link has been followed, it changes colour to asoft purple. In this manner, it is clear to users which pages they have visited. This is of obvious benefit
to people using sites that have a large number of pages. However, in the context of the SMS application,I do not feel this is a primary concern. The purpose of the site is functions over content. That is users
are not using the site to find informatic content, but to perform functions. It is likely users will wish to
perform functions more than once, whereas content, or information, is often only looked at once [24].As such, I can see no benefit in telling users they have performed a function one or more times. It would
break the consistent colour scheme, and offers no real help towards navigation.
The final part of the required information means that users should be clear on both what is actually
a link, and where the link will take them [14]. Identifying links is an important feature of any site. Toooften have I been clicking on graphics or underlined text to no effect, hoping it will move me to the area
that it depicts. Nielsen once again draws upon the standard colouring of HTML links - blue when the
page has not been visited before. If users see underlined blue text, they are immediately aware that partof the site is a hyperlink [14].
5.3.2 Navigation styles
Links may be placed anywhere in a page. However, they are a key element to the site’s overall structureand usability. As such, intelligent placing of navigation options is going to have a direct effect on how
easy it is to use.
There are many different styles of navigation, each one posing different advantages and disadvantages
20
depending on the situation. Nielsen identifies two key styles. The first of these, breadth-emphasising,
is becoming more and more popular [14]. This method has the site’s full list of links as a stripe down
the left hand side of the page [14]. This method is suggested to have two key advantages. Firstly usersare constantly aware of the site’s structure - the full list of hyperlinks is always available [14]. Nielsen
does however suggest this method is costly on space, roughly about 20% of the page is dedicated to
navigation [14]. He feels the entire point in a web site is to show users its content. However, the point ofthe SMS application is functions rather than information, and as such, dedicating this amount of space
to navigation is unlikely to have a detrimental effect on the site.
The second style is that of “breadcrumbs [14]”. This form of linking is a subtler form than the breadth
style. It gives the site a hierarchical nature. Links are placed in a tree-like structure [23]. Each originallink has a subset of links, which each in turn contain a further subset of links, and so on. Consider it
to be similar to a directory structure on Unix. Nielsen feels that this style has the benefit of minimisingspace [14], thus allowing more content. He also suggests that this method is more useful to sites that
have a large number of pages - as it reduces the complexity into a familiar and tidier hierarchical struc-
ture [14]. The SMS application will not have a large number of separate pages however. It will have aseparate page for each function, but this will not be a high amount.
5.4 Style
5.4.1 Fonts
Brinck et al identify the choice of typeface as being a problem for many sites. HTML is platform inde-
pendent, and as such does not have a standardised set of fonts. Some may be available on Linux, butnot on Windows, and vice versa. As such, Brinck et al promote the use of common-fonts [23]. These
typefaces tend to look similar, and are supported by most platforms [23]. The following typefaces are
suggested for use with web pages [23]: Geneva, Vendana, Arial and Helvetica.
These fonts have been selected as they tend to look similar across platforms and browsers. It is alsosuggested that many websites use these fonts, and as such, if I was to use them, it would give the site
a more homogenous feel, in terms of other sites on the web [23]. Brinck et al also suggest that using
popular typefaces not listed above can cause problems. They give the example of Futura, although itis a popular typeface, there are twelve different versions of it [23]. Therefore this typeface cannot be
guaranteed to look the same, irrelevant of platform, browser etc. There is a significant difference be-
tween text on a web page, and text on a document, in terms of legibility. Typefaces that look attractiveon paper do not necessarily translate well to web pages [23].
Choosing the correct font size can be an awkward task. Larger fonts can be easier to read, but the
smaller fonts give the site a more pleasing aesthetic feel [23]. It is stressed that designers should use
21
relative font sizes as opposed to absolute sizes. This is so users may increase, or reduce the font size
through their browser. Once again, the SMS application has little text within it, and as such I will use a
smaller font size. I want the site to look attractive to encourage its use. As there is not much pure text, Ido not feel the small size will detract from the legibility.
5.4.2 Colour
The web uses a graphical interface and as such can be made more exciting through the use of colours.Colours can improve the aesthetic qualities of a web site, but poor use can lead to an unattractive and
confusing design [24].
Brinck et al suggest that choosing correct pairs of colours is imperative for good design. They offer
the view that specific pairs of colour can have a detrimental effect on the overall look of a website [23].
Pairs such as red and green, blue and violet, red and blue; can give the impression of the edge vibrating[23].
The colouring of text is a powerful technique employed by designers to capture users’ attention [24].
Nielsen suggests this technique should be used in a reserved manner. The text should have a high
contrast with the background it is written on[14]. This ensures the content stands out, and thereforepromotes legibility. Black and white text / backgrounds are widely used, and as such help promote the
site’s appearance as being “part of” the web[14]. Sites that regularly change text and background colour
look disjointed and confusing - so colour change should be kept to a minimum[14].
5.4.3 Style sheets
Nielsen welcomes the use of cascading style sheets, as they give each page a more unified look [14]. As
each element refers to an entry in the style sheet, a greater sense of homogeneity becomes apparent. Asdiscussed before, consistency is a good asset to have on a web page.
Nielsen does however put forward the same rules when using style-sheets as with page elements. Themost imperative of these being to ensure the page looks decent if style sheets are disabled or not sup-
ported [14]. Older browsers do not support style-sheets, and some users actually disable them [14]. Theweb is a public community, and as such we cannot make any inferences about the people who visit the
site [14]. The notions of keeping contiguous typefaces, and ensuring font sizes are specified relatively,
are reinforced by Brinck et al [23]. Style sheets can be a useful tool, particularly for ensuring the website has a uniform look. Consistency is an attribute that I would like the SMS application to exhibit. As
such, I will use style sheets to aid me in this endeavour.
22
Chapter 6
Design of Application
6.1 Component hierarchy of system
The system I am planning to implement is fully distributed. It is therefore worth noting the variouscomponents, what they do, and why I have selected them as part of the SMS system. The current
methodology is different from the one I originally started with, for reasons that I will go into earlier.
Below are the descriptions of each component hierarchy; the reasons for selecting this hierarchy, andwhy they have changed.
6.1.1 Original design
The only difference between the original design and the current one is the use of a phone company’sservice centre. The original design was to connect directly to a service centre. The idea behind this was
the SMS message frame would be constructed in the application server, using details passed down from
the client(s). The SMS frame would then be sent to the server, probably through the use of a simplesocket. Figure 6.1 demonstrates the original design of the system.
I decided upon this architecture with no prior knowledge of the difficulty and financial cost of connectingdirectly to a telephone company’s service centre. At the time, I felt there was not much point in using
external API’s to do this - as the net result was the same. It would be simpler to go straight to the source- the service centre. Using less machines in the system design would speed up the process, which is
of obvious benefit to the users. Another advantage to connecting straight to the service centre, is the
ability to manually construct the SMS-frame. This gives us the advantage of being able to include thevarious flags that may be of use to the users. For example, as part of the requirements capture, the ability
23
Client
Applicationserver
Applicationdatabase
Existing informationsystem (SIS)
Service centre
Figure 6.1: Original hierarchy design
Client
Existing informationsystem (SIS)
Applicationdatabase
Applicationserver
Cy−Napserver
Service centres.
OrangeVodafone
O2 T−Mobile
<<smsb>>
Figure 6.2: Current hierarchy design
24
to include a reply for free flag on the message frame was seen as being a useful function; students are
often cited as being financially limited, and such a function would encourage message recipients to send
messages back. Perhaps a small part of wanting to connect to the service centre was to add an extradimension to the project. Interfacing directly with the telephone companies’ systems would prove to be
a lot harder than using a simplified API. I felt that this would be an interesting task.
6.1.2 Updated design
After speaking to Andy McCall from Cy-Nap about this, it soon became obvious this architecture would
simply not be feasible. Andy said firstly the telephone companies did not allow people to directly con-
nect and create a message frame. They merely allowed people to use their API. Secondly, initiallysetting up a user on their system, so they could use the API, would cost in excess of £2000. In addition
to this, further costs would be to establish a point of contact - a telephone number for people to mes-
sage to. Apparently a long number, e.g. 07777123456, would cost around £200 a month, and a shortnumber, e.g. 81333 would cost around £500 a month. This has obviously had a massive impact on the
architectural design.
As such, I will be using Cy-Nap’s message API. It adds a further machine into the system, but it does
not cost anything to use. Unfortunately, it does not allow us to create a message frame. Thereforevarious features may not be used. Primarily these are the reply-to flag, and the TTL (time to live) flag.
Status requests are available through the Cy-Nap API. Figure 6.2 shows the current design in a little
more detail. Once a call to the Cy-Nap API has been made, it will use a system they have created calledSMSB. Essentially this system manages all the messages dealt with through the Cy-Nap API. They have
around 25 different users making use of their API. This deals with many aspects of the SMS systems,including queuing, filtering etc. Cy-Nap’s system then chooses the appropriate service centre for the
message, and the message is sent.
6.2 Individual components
The application server is the component that connects all other elements of the system. The server will
service message requests from the client; send the message to the Cy-Nap server (and onto the service
centres); communicate with its own database and the remote information system. There are too manytasks to allow the client application to deal with it. Without the application server, all processing would
be performed on the client machine. Considering the requirements of the application, I feel that thiswould put too much of a burden on the client machine. It is advisable to use a server to increase security
- it is normally the client that is the victim of an attack. The client code would be monstrously untidy if
an application server is not implemented.
25
One of the persistent ideas that came through the requirements process, was storing sent and received
messages much like the e-mail client Microsoft Outlook does. There may be a high volume of mes-
sages sent and received from the total amount of users. The main way to efficiently store information isthrough a database.
All the potential users I spoke to were quite definite about their refusal to use the system, if it meantthem manually having to enter recipient details into the system themselves. This is fully understandable;
considering the amount of students within the school of Computing. There is also the annoyance of hav-ing to enter student details each year, and remove a similar amount. As such, I have had to ensure the
application can integrate itself with the current information system - SIS. This method has an important
advantage, the information in the application will be fully consistent with the school’s information.
6.3 Implementation
6.3.1 Java API vs XML API
The API to send and receive messages that Cy-Nap offer are either java-based or XML based. I will
be using the XML API. The XML API has several advantages over the java based API. The principal
reason for choosing XML over java is down to Cy-Nap not having updated the java API for some time.When speaking with Andy McCall, he said this API had not been changed since 2002, and was up for re-
newing. This could have a detrimental effect on my application - if I was to create the server code usingthe java API, this code may become obsolete if Cy-Nap make dramatic changes to the API. It is unlikely
the code would need severe amendments, however it is significant enough to warrant choosing the XML.
Another advantage to using XML over the java API is if Cy-Nap decide to completely change their
system. XML is completely platform and language dependent. In the unlikely situation of Cy-Nap re-
writing their system in C++, we would still be able to use the existing XML API. Obviously this wouldnot be able to happen if we were to use the java API. Similarly, if Cy-Nap changed the implementation
of the API, it is unlikely to affect our system. The XML API is very simple, and is unlikely to changedramatically. This means if Cy-Nap performed a complete overhaul, the XML interface is likely to
remain the same.
My final reason for choosing XML over the java is the tidiness of XML. We do not need to down-
load .jar files, and write the client interface to the API. We simply need to construct an XML document,
send it to the server, and parse the return document. It is a very neat way of performing complex actions.
26
6.3.2 Servlets
One of the requirements of the system was for it to be accessible independent of computer and location.
This essentially means the system must be available on the web. This posed the problem of how to
perform complex actions through a simple interface such as a web browser. Java servlets allow us toconstruct normal java code within an HTML document. As such, we can perform complex actions such
as querying databases, creating and using remote objects etc. It is very simple to combine the standardjava code, and the HTML.
6.3.3 Java RMI
As stated before, there are several reasons for moving the majority of the processing to the server. Once
we have done this, there is the problem of how to enact those processes on the server. There are again
several methods in which to do this, some depending on the language the code is written in. I havedecided to use java’s remote method invocation. RMI is one of the neater ways in which to connect to a
server, and invoke some form of processing.
RMI hides most of the processing from the client code. All the client sees is method names and pa-
rameters. The implementation of those methods is completely hidden. In addition to this, RMI hidesthe lower level network layer from the client. If we compare RMI with sockets, the advantages of RMI
are clear. If we were to use sockets, a lot more of the processing application would be visible. Sockets
must explicitly define what they are sending the server, as it is simply the transferring of messages downa logical pipe.
There are other options available. One example of these would be to use web-services and SOAP.
Web-services allow the client and the server to be completely independent from each other, through the
use of standard internet protocols such as HTTP, and platform/language independent languages such asXML. The client makes calls to the server through sending the server an XML document containing the
methods and the parameters it wishes to call.
However, the application needs to perform several different actions - querying the server database for
sent and received messages; send a message; receive a message; query the remote database for pre-defined groups; create a logical group of recipients etc. This would involve a massive amount of XML
flowing around the system, which could complicate matters.
RMI predictably adheres more to the object-orientated paradigm than lower level methods such as sock-
ets. We simply create our remote object, and call the desired methods upon it. The client has little
27
knowledge of the network part of the application, and similarly, the implementation of the processing.
All the client sees is methods, parameters and returns. This will make the client code a lot simpler, and
again hides much of the details of the system from potential attackers.
Sockets are not the only alternative to running processes upon servers, and java RMI is not the only
remote method invocation technology. One example of other remote method technology is CORBA.This method has the advantage that it is a lot more portable than java RMI. CORBA allows the client
and the server to be written in different languages. For the purposes of this application however, this isnot a requirement. It is going to be a lot more of a simpler implementation if I write both the server and
the client using java based technologies.
6.3.4 JDBC vs OJB
The proposed application is required to communicate directly with two databases. As such we mustfind appropriate middleware to facilitate this. OJB (Object Relational Bridge) is middleware written by
Apache. This particular piece of middleware is different from standard techniques such as JDBC as it isplatform independent. That is, we do not need to know anything about the DBMS to get the application
to communicate with the database. At its most basic level OJB maps java objects to relational database
tables. It does not require specific pieces of SQL to insert objects into tables. OJB relies on XML tomap the objects to the tables. As discussed before, using XML can be highly advantageous should we
wish to ensure the application is platform independent.
JDBC is a slightly older technology to OJB. It works in a very different way to the mapping con-
cept that OJB provides. JDBC is generally meant to mean Java Database Connectivity, despite Sun’sprotestations about it not being an acronym. Essentially JDBC provides us with a connection to the
database that allows us to communicate with the database using SQL. We simply create the connection,
and send the database the required SQL, and collect the results in an object similar to a database cursor.
I will be using JDBC to communicate with the databases. The main reason for this is JDBC allows
us to directly create our own SQL statements whereas OJB does not. Mapping the existing informationsystem to the SMS application will require some specific SQL, we will not simply be transferring ob-
jects to databases and vice versa. When users create their own groups of message recipients, the systemwill need to format a specific SQL query. Details of this can be found in section 6.3.7. This is far easier
to achieve using JDBC.
28
6.3.5 Class diagrams
Figure 6.3 shows the current class diagram design.
6.3.6 Flow control
6.3.6.1 Sending a message
Figure 6.4 depicts the flow of control when sending a message.
6.3.6.2 Receiving a message
Receiving a message is far simpler, as it will be an autonomous process. When the server is started,it will create a thread - SMSRetrieveThread. This thread will continuously poll the Cy-Nap server to
see the existence of new messages. The thread will poll the server once a minute - regularly enoughto ensure users are likely to receive new messages when they are using the application, but without
swamping the Cy-Nap server with too many requests.
We must use Cy-Nap’s communication point - a short number they have got from the telephone compa-
nies. This number is 88020. Cy-Nap have a database of users for their system. The recipient must typein ‘LSMS’ to ensure the message is sent to my application. To distinguish between the various users
of this application, the recipient must also select which user of our system they wish the message to be
sent to. For example, if I wished to send a text message to Stuart Roberts, cancelling a meeting, I wouldneed to type the following:
LSMS stuart Hi Stuart, I cannot make today’s meeting. Apologies, Pete.
When the phone prompts for the number, I would type in 88020.
The run method of the SMSRetrieveThread will be in a constant while loop - while(true) - so it is
always polling the server. If any messages have been received by the Cy-Nap server, it will send themback to the SMS application. These messages will be encapsulated in XML. The SMS application will
parse the XML, retrieve the messages, and store them in the database for the user they were destined
for.
6.3.7 Server database design
The server must store information connected with the application. We must know the following:
� Messages received - T MESSAGE INBOX
� Outstanding status on messages sent - T STATUS REPORT
29
SMSReceiveThread− databaseAddress: String− dbUser: SMSUser
+ run()+ SMSReceiveThread(String, SMSUser)
− storeMessage(Message[]):String− getDatabaseAddress(): String− getUser: SMSUser
+ parseResults(String, XMLHandler)
MessageRecipient− id: String− name: String− number: String
+ MessageRecipient(String, String, String)+ getId(): String+ getName(): String+ getNumber(): String
MessageStatus− id: int
− status: int
+ MessageStatus(int, String, int)+ getId(): int+ getRecipient(): String+ getStatus(): int
− recipient: String
MessageFactory− databaseAddress: String− remoteAddress: String− databaseUser: SMSUser
+ MessageFactory()+ login(SMSUser): boolean+ getRecipients(String): MessageRecipient[]+ checkStatus(): MessageStatus[]+ createGroup(MessageRecipient[])+ sendMessage(MessageRecipient[]): String
+ parseResults(String, XMLHandler)+ viewMessages():Message[]
SMSUser− username: String− password: String
+ SMSUser(String, String)+ getUsername(): String+ getPassword(): String
SMSStatusThread− databaseAddress: String− dbUser: SMSUser
+ SMSStatusThread(String, SMSUser)+ run()+ parseResults(String, XMLHandler)
− getUser(): SMSUser
− storeStatus(MessageStatus[]):String− getDatabaseAddress(): String
Message− messageID: String− messageBody: String− statis: int− dateSent: Date+ Message(String, String, int, Date)+ getID(): String+ getBody(): String+ getStatus: int+ getDateSent(): Date+ setID(String)+ setStatus(int)
XMLHandler
+ XMLHandler()+ startElement(String, String, String, Attributes)+ endElement(String, String, String)+ characters(char[], int, int)
UnicastRemoteObject
Thread
DefaultHandler
HttpURLConnection
Figure 6.3: Class diagram
30
are delivered, or have failed.
Until messages
Start
Action external tomain program
Relative order in which object.method is called
number:
Loop until condition is met
End state
User enters their systemlogin details through browser
1: MessageFactory.login(u)
User selects the appropriate
2: mRec = messageFactory.getRecipients()
User enters desired message textin browser, and sends.
3: res = messageFactory.sendMessage(mRec)
group of recipients throughbrowser
4: messageFactory.parseResults(res, XMLHandler)
Problems, if any, are returned to the browser.
5: SMSStatusThread.run()
Diagram representing the flow control when a user wishes to send a message, or group of messages.
Figure 6.4: Flow control diagram
31
� Messages sent that have failed to reach their target - T FAILED SMS
� A list of registered users - T REGISTERED USERS
� The SQL to communicate with the remote database - T GROUP QUERIES being an acronym.Essentially JDBC provides us with a connection to the
As such, I will represent all of these in five separate database tables. These tables exist purely to hold
data. There will be no joins on the tables, and as such no foreign keys will be built. As the tables will besmall, with no joins, there is little need to document them using techniques such as an ER diagram. In
each table all the columns will be defined as not null, since they are simply holding information whichwill be present at all times.
Aside from the information they are holding, each of the tables will have a column referring to theparticular user of the application. Each user of the system should only see their information, and public
information. As such, the tables will have the user as part of the primary key. The table holding the SQL
for the internal information system will have a user attribute also. This attribute can either be public,or set to a user value. The public value will allow all users of the system to see the group it refers to,
whereas the user value will be only visible to that user.
6.3.8 Mapping existing information system to application
This was one of the most persistent requirements from potential users. At no point was anybody pre-
pared to manually enter the information into the system. As such, I had to ensure the system wascompatible with existing information systems. In the real world, the application may be used by several
different organisations, all who would be running copies of the server code. It would therefore not be agood idea to hardcode details about a particular information system into the server code.
I spoke with the one of the support team, Jonathon Ainsworth, about this. My original plan was tocreate views on the information system that the application would interface with. However, Jonathon
pointed out that could mean thousands of uncontrolled database objects polluting an otherwise cleansystem, depending on the amount of groups created. When thinking about the problem, and the original
idea, I saw that views were no different from select queries; they are simply more handy for re-use. As
such, Jonathon and I decided it may be more pragmatic to store the queries for the database as fields ina table. So when a user wanted to select a particular group of recipients, they selected the group name.
The application server would query its database for this group name, and find the relevant SQL. This
would then be sent to the remote database and the results sent back to the user.
This method is not autonomous. It requires some support from the administrators of the existing in-formation system. They must insert the relevant SQL into the T GROUP QUERIES table. They must
also find out what the main, or public groups should be. There are two constraints on inserting SQL into
32
the table used by the application server. Firstly, the select statement must alias the columns it returns as
ID; Name; Number. For example:
select col1 as ID, col2 as Name, col3 as Number
This is to ensure the JDBC component may reference the columns returned accurately. Each time,independent of the particular group requested, the column names will be ID, name and number. The
second constraint is that there must be a generic group set up, that will bring back all potential recipientsof messages. In the school of Computing, this group would contain all students, all post-grads, all staff,
all admin and clerical etc. This is because when the user selects their own group, the server will search
through this entire group, and find the individual users through it. It will append a little SQL to findthese people. For example, a lecturer wishes to create a group JimAndBob. This group contains just
these two students. The SQL contained in T GROUP QUERIES for the group JimAndBob will be:
(The original SQL to find generic group) and ID in (‘Jim’, ‘Bob’).
Without this generic query, it will prove rather difficult for users to create their own groups.
Jonathon did say this was a fairly unorthodox way of getting round the problem, but not especiallydifferent from existing methods. He gave an example of a timetabling program which used the existing
information system. To retrieve the required information, Jonathon had to spool this information intofiles, using the correct select queries, which would then be used by the program. Whilst my method has
the disadvantage of the administration people being able to see more of how the application works, it
does have a strong advantage over the method Jonathon described. My application will always have themost up-to-date information. If a student changes module, that will be reflected in my application as
soon as it changes on SIS.
33
Chapter 7
Implementation of application
7.1 Differences in current implementation from original design
Once I began to code the solution, certain aspects began to differ from the original design. The applica-tion in its current state is certainly different in terms of both functionality and overall design. Particularly
the class MessageFactoryImpl - I did not expect the amount of private methods required to run the mes-
sage server to be nearly as vast as they finally ended up. There was no singular reason for the changes,but changes had to be implemented as problems, or extra functionality, needed to be resolved.
7.1.1 Database connectivity
When first designing the application, I did not realise the full extent to how database connections wouldbe central to the application. The original design specified that some database work would be required,
but did not begin to show how key the database work would be within the application. As such, when I
began to code the application, if some database work was required, I would instantiate Connection,Statement and ResultSet objects for each function that used a database. The further I got with
the application, the more I realised that this method was inappropriate. The MessageFactoryImpl class
contains forty-six separate methods. The majority of these use a connection to a database. As such, it isextremely wasteful to repeat the code for connecting to a database in each of these methods.
If a method was required to use a database, it would call one of the connecting private methods. As sev-
eral different datatypes would be required to be retrieved, I decided to have a separate method for each
datatype. The connecting method would return the desired datatype. This was obviously only requiredfor the select queries. Each method (including the update method) accepted a string containing the de-
34
sired SQL query as a parameter, and returned either void for the update method, or the required datatype
(as an array) specified in the name of the method - e.g. RunMessageStatusSelectSQLQuery
would return an array of MessageStatus objects. The update / insert / delete commands could all beperformed using one method, since datatypes were not an issue - it was merely executing a query that
did not need to return anything.
7.1.2 Sending XML
Similar to the database issue, when I first began to code the application, I placed the connection to Cy-
Nap’s web server in each method that required it. There are far less XML connections than there are
database connections, however, code re-use is an important part of the object-orientated paradigm. Whyhave several methods performing the same action, when one would suffice? The resolution was similar
to the database method. I would create a private method - sendXML, which would accept a string -
the XML to send, as a parameter, and return the XML sent back by Cy-Nap. This meant that threeextra private methods were required - to create the three separate XML strings used by the application.
However, the difference between the sendMessage method now, and the one before the changes issignificant. This method is far smaller, and a lot easier to see what it is actually doing within.
7.1.3 Managing data
The original design planned for users to simply see the inbox for the application. At that point I was
not sure I would have the time to implement a fully working SMS management system. I included theviewMessagesmethod in the design, since one of the minimum requirements specified for the appli-
cation was for it to receive messages. To ensure this requirement was met, it was important to include a
way of checking the inbox.
Once having implemented the bare functions of the application; sending, receiving, status checkingand viewing received messages, I realised that as an application, it was bare. The coding for these base
functions had not taken nearly as much time as anticipated. Therefore I went back to the user require-
ments, and looked at what features had been wanted by potential users. Stuart Roberts had identifiedthe need for an outbox, in order to prove to message recipients that certain messages had been sent. I
implemented this method, and realised that any tables containing user information should be availableto the user of the system. This includes inbox, outbox, status reports, user groups etc. From this point
onwards, if any new functions were implemented, and they appended information in one of the tables
used by the MessageFactory object, I gave the users the options to view it. However, the applicationwould become ultimately redundant if users did not have the ability to discard unwanted information.
As such, I added the functionality that if a table contained user information, the users could both view
and remove the data. This allows the application to become a lot more use to the users.
35
7.1.4 External recipients
The major focus of the application was its integration with existing information systems. This allowed
users to select message recipients without having to enter them into the database. This satisfied one of
the major requirements. However, upon completing this requirement, I began to think that this was notenough. It was all very well having the system being able to send messages to all people concerned with
the application, but people often wish to contact others outside of the organisation.
7.1.5 User groups
The ability to send user groups was another important requirement of the application. The people whom
I spoke to as part of the requirements analysis felt this was an important feature, certainly considering
that many people would require separate personal groups - for example tutor groups, project supervisees,admin groups etc. Whilst I planned for this requirement in the original design - the createGroup
method, I did not specify how the MessageRecipient array required as a parameter would be filled.
As such, I had to find a sensible way of searching for message recipients through the client interface.
Speaking with Stuart Roberts, I found that that the easiest way, in terms of the user, was to search for auser through their id. In the school of Computing context, this would be username. I defined a public
method, sendMessageByID that would accept a user ID as a parameter, and return a MessageRecip-
ient array, after searching the database for a user who had that unique identification.
An extra method had to be defined for this function - getIdColumnName. The table names of the
internal database were never to be hardcoded into the application. The way I wanted to create a usergroup was to take the SQL string required for the “All” group, and append an id search on to it. This
method would not work however - the id column name was not known. The application knew no detailsabout the internal database other than the queries stored in T GROUP QUERIES. To get this function
to work properly, I had to parse the original SQL for the “All” group, and grab the second word of that
query. The second word would always be the name of the column containing the ids of the recipients.
7.1.6 Other methods of sending messages
When I first came to write the application, the major focus was upon its integration with an existing
information system. This was a key requirement of the application - both Charlie Brown, and StuartRoberts expressed that the application would be of little use without this functionality. As such, when
I began to first implement the solution, the only way it was possible for users to send a message was
through the user groups.
To improve usability, I introduced two new methods to the client application: sending by recipient
ID, and sending by the recipient number. The recipient number section required no extra code to the
36
MessageFactory - all I simply did was pass the number down from the client to a MessageRecipient
array of size 1. The MessageRecipient array had nulls set for its other attributes. This array was then
sent as a parameter to the sendMessagemethod.
The second method was again especially easy to implement. I had defined a method for searching for
user information via their ID because of the need to create user groups. I simply used the same methodto return MessageRecipient information, and send that array down to the sendMesagemethod. How-
ever, this was not sufficient - the application at that time held both internal and external recipients. Thesearch by ID function would only search for internal recipients. To ensure the application was as useful
as it could be, I defined a new method that would search for external users via their ID. I did not want
to differentiate between the searching for external and internal users through the client interface - it wasthe same function as far as the user is concerned.
7.1.7 String parsing
Most of the other extra methods included in the design are due to the need to parse strings. For example,in the design section, I described how students had to send messages - by sending two keywords before
any text. When I first ran the message server, and received a message, these keywords were inserted
into the database. This was not a major issue, but did not seem particularly professional when lookingat the message inbox. As such, I devised a method to remove the keywords before the text was entered
into the database. Several of the extra private methods were included to parse strings in situations such
as this.
7.2 Problems encountered during implementation
7.2.1 XMLHandler
I found two major issues with this class during the early stages of implementation. The first issue con-
cerned itself with datatypes. The XMLHandler was the class responsible for handling how to parse
the XML sent from Cy-Nap. The handler needed to be able to communicate with the MessageFactoryobject - once the XML string had been parsed, how did the results get returned to the calling object? I
decided to place a private variable within the XMLHandler to store the results. However the datatypesholding the parsed XML could be either MessageStatus objects, or Message objects. I did not want to
have a separate handler for either instance.
This problem was overcome using the java.util.Vector class. Vectors have the ability to store
objects of varying class. I used this class to store the results. I included a method returnResults()that would return the vector to the calling procedure. Vectors have a method named toArray() [13].
This method will return the contents as an Object array. If the objects are all the same, we can cast them
37
to an array of the required object. This way, the object returned would always be the same - a Vector,
but the contents could be cast to Message or MessageStatus objects by the calling procedure, using the
toArray()method.
The second issue I found with the XMLHandler was difficult to ascertain to begin with. When I built up
a simple prototype attempting to test the MessageFactory’s ability to send a message, the prototype keptthrowing an exception - Unexpected EOF from server. At first I assumed this was a problem
with the address specified for Cy-Nap’s webserver, as this would explain why nothing seemed to beingreturned from that address. I began to try and output each character from the byte stream to the screen.
This meant looking up the ASCII values for the codes returned.
Each element had about 20 characters of whitespace preceding and proceeding it. I wondered whether
this had a direct effect on the SAXParser to efficiently parse the string. To test this, I created a programthat parsed the original string, which had been pasted in from the terminal, after I output it. The results
were the same - an exception. I then modified the program, and removed all the whitespace between
elements. The string was parsed successfully. To ensure this did not crash the application again, I cre-ated a new method for the XMLHandler class - removeInvalidWhitespace. This method looped
through the string, searching for whitespace that was not part of the text sent back, and removed it.
7.2.2 SMSStatusThread
Originally I felt this class would be simple to execute. The job of this thread was to poll the Cy-Napserver asking for status requests on messages sent. The thread would stop executing when the mes-
sage status for each message sent was resolved, either failed or delivered. However, one issue with thismethod persisted - when a message has been sent upstream - to one of the phone companies service
centres, the status is 1. Occasionally this status does not change - that message has a status of 1 perma-
nently attributed to it. I did not want to remove all messages that had a status of 1 (i.e. assume they havebeen delivered), as they may subsequently fail. I contacted Andy McCall about this issue. He suggested
that messages that have a status of 1 after ten minutes can be considered to have been delivered.
The major issue with a subsequent implementation was the assumption that all messages were attributed
with a 1 status almost immediately, and all messages achieved the 1 status at the same time. Neither ofthese assumptions were true. To resolve this problem, I had to map the array of MessageStatus objects
to an array of times. I created a Calendar array of the same size as the messageStatus array. Then if the
status was 0, for a MessageStatus[] of index i, the Calendar array at index i was set to the current time.If the status was found to be 1, nothing would happen. This meant that the time when a MessageStatus
object had a status of 1 was recorded. I then compared the times associated with the MessageStatusobject with the current time. If the difference was greater than ten minutes, the MessageStatus could be
removed.
38
7.2.3 Other issues
The other kinds of issues I dealt with were mostly memory referencing issues. These were extremely
confusing at first, and took several manifestations during the application’s course. The most noticeable
instances were comparisons, normally performed on ints or strings. There were several functions thatwould contain a string, or int as a parameter, and be required to perform some kind of comparison. When
I performed comparisons using the == operator, the result was never found to be true. This confusedme, especially when printing out the value would be visually the same as what I was comparing it to.
Most of my previous programming experience has been with C++. Strings and ints are normally passedby value in the functions I had written - I had used very few pointers before. Java takes care of memory
issues for us, so when I was passing in a string or an int to the function, it would compare the memory
references of the string passed to the literal I had set down in the if statement. Looking back on it now,it is understandable why the two would not compare properly. This issue was easily solved - using the
compareTomethods of the String and Integer classes [10, 12].
Another referencing error occurred when filling arrays. Thankfully this issue was quickly resolved.
Much of the information passing in the application is done through arrays, and these need populatingin most of the functions. Originally I had temporary variables as instances of the class that was held
in arrays. I would then simply pass the value to the part of the array, using the equals operator. This
produced some strange results; the array would be populated to the correct size, and the last elementwas what it should be, but all the preceding elements had the same value as the last element. This was a
simple mistake on my part - I should have been using the new operator to assign the value, rather thanusing the = operator.
7.3 The client interface
The focus of my design was on the server side code. My plan for the client code was to simply connect
to the RMI server, and execute one line functions. I did not feel that the client application would takemuch time to implement. On the surface, I was right. Performing the message functions was extremely
simple, all that was involved in the client interface was filling up the arrays to pass to the remote meth-
ods. However, there were still issues I had to overcome.
When speaking to Stuart Roberts about the application, he suggested using checkboxes to select specific
messages, when they were to be deleted. This seemed a reasonable request, and would provide a simpleinterface for the users. This was something I wanted to achieve. However, with the checkboxes, I could
never know how many HTML variables were sent. I also could not specify what the variable nameswere in the HTML form.
39
These issues were fairly easily resolved. I looped through the array of objects that could be removed, and
assigned the HTML checkbox values to that of the ID they were representing. This way, I could be sure
that no two variables would be called the same. The next issue was how to get hold of these values inthe servlet. The HttpServletRequest extends the class ServletRequest [11]. This class contains a method
called getParamaterNameswhich stores the names of variables in a java.util.Enumeration
object. All I had to do was loop through the Enumeration object, and getting the names of the param-eters, since their name was the value of the ID they were representing. Then I needed to compare the
IDs, with the variable names held in the Enumeration object. If the IDs matched, I would execute thecorrect function.
The biggest problem I found with the client code however, was the HTML. I wanted to ensure thatthe layout was exactly the same across pages, other than the immediate content. I decided to place the
entire site into tables. The immediate content would be a single entry in a large table. This allowed meto keep the same structure, by placing most of the site in a header. If the action changed, only the centre
part of the site would become different.
The physical layout of the site was constructed using tables. It is inadvisable to use frames [14]. This
part of the implementation caused me problems because of my lack of familiarity with HTML. I had
to look at the attributes of the table tag to create the page. The W3C schools page helped me out a lotwith this aspect. I noticed important attributes that really aided me - particularly: valign, height,
width, colspan and rowspan [2]. I certainly did not expect this aspect of the project to havebecome as much of a difficulty as it ended up.
7.4 Testing
I used a combination of both black-box and white-box testing. These methods had been taught in SO11.
I decided to use these methods of testing since I was already accustomed to using them. I felt it nec-essary to use both black-box and white-box testing. Certainly for the MessageFactory class - there are
forty-six separate methods. These needed to be individually tested - to try and test these methods just
using black-box methods would be a fairly exhausting process. However, the project is an application,and once the methods were confirmed to be working properly, it was not sufficient to stop the testing
there. I needed to ensure that the application worked as a whole. A driver program was created for each
private method used. For examples of test plans, see appendix C.
40
Chapter 8
Evaluation
8.1 Evaluation criteria
8.1.1 Functionality� Does the application send messages?
� Does the application receive messages?
� Does the application demonstrate status checking?
� Does the application support several users?
� Does it integrate with other forms of communication?
� Does the application allow users to send multiple messages?
8.1.2 Data Management� Can recipients be organised into logical groups?
� Can recipients be organised into personal groups?
� Are the facilities to remove them?
� Is there support to integrate the application with some form of information system?
� Can users enter recipients into the system, and store them?
41
� Can users remove this kind of data?
� Is there the ability to check inbox, outbox, status?
� Can users remove this kind of data?
8.1.3 Usability� Does the application look professional?
� Do the colours, fonts and layout appear simple and attractive?
� How simple is it to traverse through the site?
� How easy is it to perform functions, such as send a message?
� Does the navigation style appear sensible and easy to use?
� Are users always aware of which pages they are visiting?
� How simple is it to enter user input into the application?
� When prompted for user input, is it clear which kind of information the application requires?
� Do the site pages download quickly?
� How long does it take to send a message?
� How long does it take to send thirty messages?
� How long does it take to view user data (such as inbox)?
� How long does it take to remove user data?
8.2 Reasons for selecting criteria
The first section of the evaluation criteria is functionality. Clearly this is a fundamental section. The
functionality of an application is what defines its use. Other elements of an application are secondary
to its functionality - a site may look as attractive as possible, displaying every characteristic of goodusability, but if it does not perform what users wish it to do, it is defunct as an application.
All the applications to be considered are SMS applications. Their abilities to send, receive and checkstatus of messages are key to their success as communication systems. Without any of these functions,
the application is severely limiting usefulness. Communication systems need to be able to send andreceive communication. As such, both sending and receiving messages are key functions of any of the
42
applications. SMS technology is not as robust as other forms such as e-mail. The data is sent through
radio waves, and is more likely to be lost, or corrupted than in other forms such as e-mail [16]. There-
fore it is important that users may check if their messages have been sent.
Most communication systems offer some support for data to facilitate the communication process,
whether it be a mobile telephone - with its phone book, or an email client with its contact list, or evena standard telephone is often supported with features such as storing important numbers. As such I am
considering the level of support for data to facilitate with the application an important feature. Peoplecannot be expected to hold all possible recipient contact information in their head. There are two ways
to hold such data, through integrating the application with an information system, or through allowing
users to manually input this information. Many communication systems offer the latter option - such asthe mobile telephone. Either method is of use, but in the context of an SMS application, it will be far
more useful for the application to be used in conjunction with an existing information system - as thepotential volume of information could prove too much for users.
The requirements process identified one key form of data management - grouping of recipients. Thepotential users suggested that messages sent from the application would be going to several recipients.
They suggested that grouping would make this process a lot easier. This form of logical grouping is
found in other forms of communication systems, where the method of communication allows the userto send data to more than one person. Whilst this functionality is not key to any communication system,
those systems that support communication with multiple recipients would be a lot easier to use.
All of the applications to be considered use a graphical user interface, and all use web pages as the
medium. Any application that uses an interface must also be evaluated in terms of the effectiveness ofthis interface. If the interface is impossible to understand, the application is defunct. I shall be consider-
ing the aesthetic qualities of each application as this can often have a direct impact on whether they are
used or not. If either the look, or the layout of the interface is sufficiently poor, it could effect both howwilling users are to use the application, and how capable users are to use the application. Similarly, the
user’s ability to navigate through the different sections of the interface is important. Interfaces that usethe web must certainly consider this factor - as hyperlinking is one of the main features of web pages.
8.3 Comparison with other applications
8.3.1 EduTxt
EduTxt [3] seemed a good application to start the evaluation on. It is an application developed by Cy-
Nap. The application was first developed to aid with communication between schools and students, or
43
parents of students. The application is inevitably similar to the one I have developed, it uses the same
XML API to perform message functions, and its purpose is similar - to provide an SMS based commu-
nication tool for use within the education sector.
There are two methods in which to add recipients to the application. The main source is through the
application itself. Users are provided with a screen in which to fill in recipient details. The recipientsare then added to the list, providing the fields are correct. EduTxt is an application made specifically for
educational institutes, and as such recipients must be placed into a specific “class”. Similarly, there isthe option to link a student with an appropriate parent or carer. This method is similar to the function to
add external users in the application I have developed, the difference being the extra fields to add, and
the necessity to label a recipient into a specific class and associate them with a parent / carer.
The secondary method of adding recipients is a half-way measure to integrate the application with anexternal information system. Users may upload XML, or comma/tab separated value files to the appli-
cation. Providing the files uploaded to the application are suitably formed, the application will store all
the uploaded recipients. This function is certainly an improvement on manually entering information,and allows the application to reside on one webserver, supporting several educational institutes. How-
ever, this manner of integration does not allow for slight changes. Imagine a student changing a module
halfway through the course, to ensure consistency, we would have to upload a new XML file containingthe updated SIS records. In an organisation as large as the school of Computing, where changes can be
frequent, this would become an annoying issue.
Users may create personalised groups within the application. Recipients are placed in a logical group
by getting the user to manually select which recipients should be in the group, from a complete list ofrecipients. For smaller organisations this method is fine. However, imagine attempting to do this in the
school of Computing. There will be many entries for staff, students, clerical etc. It is simply not feasible
to scroll through a few thousand entries looking for students that belong to the required group. Usersmay remove both the logical and user groups.
Cy-Nap’s application provides facilities for inbox and outbox, any message sent is placed in the outbox
folder, messages received are placed in the inbox. Users have the ability to remove messages at will.
The application uses a similar system to my application, through checkboxes. Again, similar to myapplication, once a message is removed, it is impossible to retrieve.
From all the applications reviewed, EduTxt is the best for data management. I would suggest it meetsall of the evaluation criteria, apart from its ability to integrate with a current information system, despite
a valiant effort. The ability to upload XML containing recipient information is a particularly usefulfeature - and is far quicker than manually entering the recipient information by hand. The support for
44
groups is again very good, apart from the usability issue at potentially having to search through thou-
sands of rows of data, to locate the required recipients. To migrate the SIS information, we would need
to define a new XML file for each module. Each time a change occurred, we would need to send thechanged XML files again. I feel this would create a large amount of work for the admin team, and may
put people off from using it as a communication tool.
As far as functionality goes, EduTxt is again a very good application. It employs the core function-
alities: sending, receiving and status checking. Each of these works adequately, it is very difficult todifferentiate these functions between this application and the one I have written. The inbox feature
makes use of keywords to identify the particular user of the system, similar to the way I have imple-
mented my application. EduTxt does support different users, but in a different manner to the way I have.As the application is designed to support many academic institutes, it takes the view that there will be
a singular user for each institute. This would mean there would be one solitary user for the school ofComputing.
This feature has several disadvantages. All user groups defined would be visible, despite the major-ity of them not being applicable to the various people that used the application. There would be similar
issues with the outbox and inbox features. With an organisation such as the school of Computing, there
could potentially be many messages sent in the course of a day. This would flood the outbox, makingit an almost obsolete feature, due to its unmanageable size. People would find it difficult to remove
messages - as they could not guarantee these messages would not be required by another member ofstaff. These limitations are reciprocated with the inbox feature. There is of course a way round this,
and by having a separate user for each member of staff. However, for each member of staff to be regis-
tered would require having to upload the SIS information as many times as there are members of staff.Assume there are fifty separate modules, and one hundred members of staff - XML would have to be
initially uploaded five thousand times. For each singular change to the data, the new XML would have
to be uploaded for each staff member. Clearly this option is also not a valid alternative.
EduTxt once more does well against the evaluation criteria for functionality. It does not have any methodof integrating the application with other forms of communication tool, but this is not a fundamental flaw.
The application only falls down in terms of functionality due to its method of users. I feel that if the
application were to support an institution such as the university, it would have to support separate userswithin the organisation. Apart from only having to specify a singular keyword when sending messages
to the application, the application’s core functionalities are no different to that of the application I have
developed. EduTxt does offer extra functionality to my application - that of scheduling messages, andtemplate messages. When a user wishes to send a message, they must specify a time and date for the
message to be sent, thus allowing messages to be created long before they are sent. This is a nice feature,but hardly fundamental - I cannot think of a situation within the school of Computing where this feature
45
would be greatly useful to the situation.
The aesthetics of the site are suitable for an application such as this. The appearance appears pro-fessional in nature. I feel the background colour is a little odd in choice - a green / brown, but this is
more personal preference. The colouring is mostly consistent throughout the site, and there are very
few clashes. However when outputting volumes of stored data, each even-numbered line (assuming theline count starts at 1) has a light blue background. The reason for this is to differentiate between the
lines. I find it has the opposite effect - there is a significant clash between the light blue and the brownbackground. Each list has links within the information (for example, a recipient list will have each re-
cipient’s name as a link so users may examine the recipient more closely). The designer has chosen to
place the links as the standard blue, which is a good attribute, however, the blue strongly clashes withthe light blue background on even numbered lines.
The fonts are used sensibly within the application. The typeface is made from a selection of the most
suitable fonts identified in chapter 4 - Helvetica, Arial and Sans Serif. There are only two typefaces
used - one for the title, and large links, and the normal typeface. There is no confusion within the siteat all. The different typeface helps identify sections as links, which is helpful to the user. Similarly, size
is well used throughout the application. I find the text a little larger than I personally prefer, but this is
of little matter. The larger size will make the site easier to read, particularly for older users. The pagelayout is consistent throughout the site, and appears simple for the majority of the time. The page is
written using tables, as I have done with mine.
To ensure that resolution is not an issue using the site, the main table is centred on the screen. This
leaves large white margins either side of the content. On my screen (using 1024 x 768 on a 19 inchscreen) the margins are about two and half inches wide. This does leaves the site appearing to waste
space - the margins are noticeable because of their lack of colour, and the centring. The only time a page
looks remotely confusing is on the send message screen. Using the technique of counting vertical linesdiscussed in chapter 4, there are eight separate lines. The page is not overly confusing, but does appear
rather full. Some of the form boxes could be made a little more symmetrical to improve the aesthetics.
The main way the site falls down in terms of usability is its navigation. When attempting to set up
a class manually, the application asks to specify a class name, and stores the input name. The user isthen presented with a screen showing the class names. In order to fill that class, the user must look at
the navigation bar, and select address book, and use the new class name to classify the student. I feel
this is a poor choice - when I clicked on the new class link, I got the impression that I would be fillingin the class on this screen. The screen showing the class names did not give any instructions as to how
to populate the newly created class. As such, I was very unsure of what to do next. There were otherinstances within the site where I was not sure how to perform the action that I wished - for example
46
status requests. There was no specific link to the status, I had to select the outbox, then the particular
message to get its current status.
The main issue with the general usability of the application is that of not being able to modify recipient
groups before message sending. The user is presented with a choice of message recipients - by year; by
class; by user-group or by individual person. There are two disadvantages with this method - the usermay not select multiple years or classes to send by. This could prove annoying to a user. Imagine a
scenario where a lecturer wishes to communicate a careers lecture on all things Internet related. Thereare several modules that could be of use, but the lecturer would have to send the message once for each
module. The second disadvantage to this method is the user may not modify a current recipient list. If
I wished to send a message to half a class (e.g. all those who got above a 2-1 in the last coursework) Iwould either have to send the message to individuals each time, or create a user group containing these
recipients. Neither method is ideal.
Overall the EduTxt site is an attractive application, which looks professional. Apart from the occa-
sional odd colour choice, and the issues discussed above, it is a well constructed application. Despitethe lack of full integration with information systems, the support for data management is the most com-
prehensive I have seen with applications of this type. I would suggest the navigation and inflexibility
of selecting recipients are significant flaws as opposed to the colours. However, they are two flaws inan other wise usable web-site. The speed of the application both in terms of sending messages and
downloading pages is acceptable. The sending messages is slightly quicker than my application.
8.3.2 Ipipi
The other application to be looked at is Ipipi [7]. This application is significantly different from Cy-
Nap’s EduTxt. There is not the strict sense of purpose that EduTxt demonstrates. The application’s
focus is upon the integration of SMS technology and e-mail, as a single communication tool. The ap-plication performs two of the core functions: sending messages and receiving, but there is nothing in
the way of status checking. Users may send multiple messages, either by typing explicit numbers sepa-
rated by commas, or using the site’s address book feature. The receiving functionality uses a differentmethodology to that of both my application and Cy-Nap’s application. When a recipient is sent a mes-
sage, they may reply to that message without having to specify a keyword. The original sender of themessage
The application does attempt to integrate itself with existing communication tools, e-mail in this in-stance. When messages are sent or received, they can be forwarded to an e-mail address. This is an
interesting development - users may use this application as their primary source for text-based commu-nication. There is no need to use separate SMS and e-mail clients. Whilst this is a good feature, the
potential users of the project suggested that SMS communication would only be used in situations where
47
other, more flexible, methods were inappropriate due to not being able to ensure users have received a
message. There may be some instances where this feature will be useful, but it is not enough to support
the application on its own.
The application’s main deficiency is the lack of support for external information systems. The applica-
tion does manage to offer users the ability to enter recipient information in a utility similar to Outlook’saddress book. Users may search within the address book, edit and remove entries. However, the lack
of integration means the application is essentially unusable for large organisations. Even if one persondid take the time to add information to the application, if any more users from within the organisation
wished to use the application, they would have to enter the same information again. The application
is of more use for personal communication, not in any organisational context. Users may remove bothinbox and outbox entries.
The lack of support for data management is the application’s main downfall. It is an extremely use-
able site. The layout is highly attractive and professional - using very simple colours and fonts. Links
are clearly labelled, and each page has a header informing users where they are. All the forms within thesite are clearly labelled, and there is no ambiguity as to what information to place in each box. Speed is
not an issue with this application, for either page loading or sending individual messages.
8.4 Evaluation of the produced solution
The application developed is centred around how useful it is to potential users. As such, I have enlistedpossible users to evaluate it, rather than do it all myself, to get the opinions of those who will use it,
rather than the opinion of those who wrote it. Originally I was going to demonstrate the application to
Cy-Nap, and record their thoughts. However, before the day of the demonstration, Steve McCann hadto leave the office for the remainder of the week, and was out of the office the proceeding week. Cy-Nap
did not want anybody else to evaluate the final product. As such, I employed the help of Stuart Robertsand Simon Stevens to assist with evaluating the product.
8.4.1 Stuart Roberts’ evaluation
Stuart Roberts is a senior lecturer within the School of Computing. I spoke with Stuart regarding the
requirements of the application. As such, I thought he would be a good person to help evaluate the finalproduct - to see whether the requirements of the application were actually met. As far as the core func-
tionality of the application was concerned, Stuart felt that these were performed adequately. He felt themessage system should be able to send, receive and status check, and as the application demonstrated
these abilities, this was sufficient.
Stuart raised an interesting point about the possibility of integrating the application with more com-
48
monly used communication tools. He felt that merging the application with an e-mail system would
prove useful. I questioned the usefulness of this feature - I feel the SMS system should be used when
other forms of communication are simply not sufficient. However Stuart pointed out that in these sit-uations, all forms of communication should be explored. We cannot guarantee that the recipient of the
message will be able to view their message even if the status report claims the message has been de-
livered to the handset. The recipient may not have their phone, it may be damaged, or have run out ofbattery power. As such, the facility to send a message down two separate channels can only improve the
recipient’s likelihood of getting a message.
When a user selects a group within the application, they have the ability to modify the recipients within
that specific group, through the use of checkboxes. Stuart found this feature to be particularly useful.He said there could be many instances where only a section of a particular group would need messages
sent to them, and this feature saved a lot of trouble.
Stuart made a point of identifying there was a standard recipient list for all users. This meant that users
did not have to specify their own user groups for modules, as these were a generic group. This leavesthe user only having to create groups specifically for themselves, in instances such as tutor groups, final
year project groups etc.
The only functionality that Stuart did not approve of was that of the ability to add external recipients to
the application. He did not see the use in such functionality, and suggested that this function suggesteda use of the tool that it was not intentionally designed for - communicating with family and friends. I
do not feel the external recipients function explicitly suggests this. The external recipient function was
integrated in case of situations where people need to be contacted, but are not part of the internal infor-mation system. For example, a lecturer could need to meet with a lecturer from the school of Medicine,
and find they are running late. The lecturer from the school of Medicine would not be part of the school
of Computing’s information system, but the tool could still be used to contact that person.
Stuart was particularly impressed by the way the application integrated itself with SIS. Especially con-sidering that no table or column names were hard coded into the server application. Stuart felt that all
the recipient information returned to the application was sufficient.
The application should allow users to control any information they directly, or indirectly (such as out-
box) add to the system. As such, I gave the users the power to remove and view anything that they have
added. However, I did not include the ability to view messages that had failed. The error rate for sentmessages was negligible - not one message failed in during the testing phase. I felt this issue would be
something the administration department would be more interested in. Stuart however did not agree. Hefelt that it was imperative that users could see any messages that had failed, and the application provide
49
a facility to remove them. In the current model, users cannot see if an error has occurred. Users want
to use the system in times where messages must be sent with a sense of urgency. As such, if a message
fails, it is important that the user be notified.
Stuart’s only other complaint with the data management of the application was the lack of legend on the
status check. This unfortunately came down to time constraints. The status of a message ranges from0 - 6, each different number identifies a different status result. Whilst I understand what each number
stands for, users do not. Without a legend, the status is not particularly useful.
The application contains two forms of message recipient - internal recipients (those contained within
the information system) and external (those manually entered via the application). I wanted to treat bothtypes of recipient as similar as possible. To do this, I allowed users to create message recipient lists
containing both internal and external recipients through the select group screen. Stuart found this levelof integration useful, and suggested it shows a level of transparency that was important for this kind of
application.
Overall Stuart found the level of information support within the application very helpful. He suggested
apart from the status checking legend, and the ability to view failed message, there was nothing else he
would expect or want the application to do, in terms of data management. He was pleased his suggestionof placing messages to be removed via checkboxes was implemented. He felt this was the most user
friendly way of performing such actions.
Stuart found that the usability of the application was the area which let it down. He felt that the overall
aesthetics were adequate, and was pleased it exhibited a sense of professionalism. The colouring wasnot to Stuart’s taste, but he maintained that despite not liking the colours, they did not seem inappropri-
ate, in terms of contrast, and confusing the site as a whole. The font size was a little too small, a larger
size would have been more appropriate. He emphasised the point that older users may find it difficult tocomfortably see all the information on the screen.
Stuart found the user input of the application fairly difficult to get to grips with it. He had two main
complaints - the physical layout of the various buttons, and secondly the labelling of the buttons. He
gave the example of the select group screen. When selecting a group, there is a drop down list, and thebutton next to it says “Add to group”. Stuart suggested that this is a fairly ambiguous label, it was not
clear what clicking on the button would do. He expressed a similar concern on the add external recipi-
ent page - there was a button with the same label, but with a different function. Clicking on this buttonwould add the external recipient to a message recipient group that would be added to the application.
The physical layout of the various buttons within the application caused some annoyance. The amount
50
of mouse movements required to perform certain functions seemed too many. Stuart gave the example
of modifying the recipients before sending a message. On the right hand side there were all the check-
boxes to select which recipients the message should go to. At the bottom on the left was the button toconfirm the new list. On the right was the button to go back to the main screen. This meant that a user
modifying a recipient list had to move the mouse from the right, to the left, and back to the right again.
To ensure users could send messages as they pleased, I placed three separate methods of sending mes-
sages within the application - via a group, a fixed telephone number, or by the recipient’s ID. Stuart saidthat whilst this extra functionality was useful, the ID search was maybe a little too obscure to be of real
use. Within the school of Computing, students and lecturers are identified by their username, unique to
the person. The username is a semantically significant title. However, in many organisations the ID ofa person is unlikely carry quite the same meaning. IDs are normally employee numbers, long strings of
characters that do not mean much. As such, a facility to send by name, or search for recipients by namewould be more use, and certainly more user friendly.
Overall, Stuart found the application to be useful, and functional. Sending multiple messages did takea long time, and Stuart would have preferred it to have been quicker. He also added that this was not
something he would normally monitor, and as such, was not too much of a problem. The user interface
was attractive, but did have some usability issues to be rectified. None of the issues raised would stopStuart from using the application as a secondary communication tool. He felt that the application’s
strengths were its data management, especially in terms of trying to simplify the selection process.
8.4.2 Simon Stevens’ evaluation
Simon Stevens is a bassist in a popular band in Leeds, Kenosha. Stuart was a good choice as explained
before, but is technically experienced. Simon does not have any technical background whatsoever, and
as such represents users without Stuart’s level of knowledge and experience. I wanted to demonstratethe application in a different way to Stuart, to see if the application could be moved to a different organ-
isational context. Simon’s band attracts a fair amount of attention, and they are performing many gigs
locally. People want to know when they are playing. We used the application to inform Simon’s friendsand family when the next performance was.
Simon’s main issues were the same as Stuart’s, usability. When first introduced to the application,
he was not sure exactly how he was to send messages. He found the dynamic nature of the forms a little
confusing. Especially as the font sizes heading the forms were small. When a form changed, it was notimmediately obvious to him that the form was requiring slightly different information. Similar to Stuart,
Simon found the labelling of certain form fields confusing. He did not like the label “Add to group”on the external recipient side, and suggested this did not convey accurate enough meaning to what the
function actually did.
51
Simon suggested one important change to the application. User groups are an important part of this
application, but can only be defined within the user group link. Simon wanted to have a button on themodify recipient list to create a personal group containing the newly modified recipients. This then
prevented the need to spend time entering in recipient IDs to create these groups.
The aesthetics of the application were found to be adequate, but they did not seem as professional
to him as other websites. He pointed out the title of the screen was simply text, and seemed poor incomparison with other headings of professional pages. He appreciated the colouring, and font sizes, as
they made the application appear a lot more attractive. Simon’s main problem was the speed of sending
messages. We defined a list containing people who were interested in Kenosha’s gigs. This list wasabout a hundred people. The application took over a minute to complete this task. In that time, we were
presented with a blank screen, and did not appear the application was doing anything. Simon suggestedsome form of status bar would let users know that the application was actually doing something, and
had not crashed.
8.4.3 Other points to consider
The evaluation criteria was set out based on what users had wanted from the application. The crite-ria is in no way complete for a full application, it merely represents the users’ wishes. Even if the
application was changed to meet all of the criteria, it would still have deficiencies. The main one is
security. There are no provisions to make the application secure. For example, when sending XML,a HttpURLConnection object is used. As the username and password is passed to this XML, a
better way would be to use HTTPS to send the XML, as opposed to standard HTTP. Similarly, theapplication uses RMI to perform the complex message functions. There was no instantiation of an
RMISecurityManager to make this part of the application secure. Much of the work is performed
on a database. There are no provisions to ensure this part of the application is secure, apart from remov-ing apostrophes from any queries.
52
Bibliography
[1] Grady Booch. Object Orientated Analysis and Design. Addison Wesley, 1994.
[2] World Wide Web Consortium. Html tutorial. http://www.w3schools.com/html/default.asp, 2003.
[3] Cy-Nap. Edutxt - school to parent communication using sms text messages.
http://www.edutxt.co.uk/index.jsp, 2004.
[4] Alan M. Davis. Software Requirements Analysis and Specification. Prentice Hall, 1990.
[5] Simon Bennet—Steve McRob—Ray Farmer. Object Orientated Systems Analysis and Design
using UML. McGraw Hill, 2002.
[6] Friedhelm Hilleband. GSM and VMTS. Wiley, 2002.
[7] Ipipi. Send sms text message international texting service. http://www.ipipi.com/index.jsp, 2003.
[8] Leszek A. Maciaszek. Requirements Analysis and Systems Design Developing Information Sys-
tems Using UML. Addison and Wesley, 1998.
[9] Timo Halonen—Javier Romero—Juan Melero. GSM, GPRS, and Edge Performance. Wiley, 2002.
[10] Sun Microsystems. Integer (java 2 platform se v1.42).
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Integer.html, 2003.
[11] Sun Microsystems. Java 2 platform ee v1.3: Interface servletrequest.http://java.sun.com/j2ee/sdk1.3/techdocs/api/javax/servlet/ServletRequest.html, 2003.
[12] Sun Microsystems. String (java 2 platform se v1.42).
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html, 2003.
[13] Sun Microsystems. Vector (java 2 platform se v1.42).
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Vector.html, 2003.
[14] Jakob A. Nielsen. Designing Web Usability. New Riders Publishing, 2000.
[15] Siegmund Redl—Matthias Weber—Malcolm Oliphant. GSM and Personal Communications
Handbook. Artech House, 1998.
53
[16] Kun II Park. Personal and WirelessCommunications. Kluwer Academic Publishers, 1996.
[17] Ivar Jacobson—Grady Booch—James Rumbaugh. The Unified Software Development Process.Addison Wesley, 1999.
[18] James A Senn. Analysis and Design of Information Systems. McGraw Hill, 1989.
[19] Peter Studa. GSM Evolution. Wiley, 2003.
[20] Ben Potter—Jane Sinclair—David Till. An Introduction to Formal Specification and Z. Prentice
Hall, 1996.
[21] Joachim Tisal. GSM Network. Wiley, 2003.
[22] David Mason—Leslie Willcocks. Systems Analysis, System Design. Alfred Walker, 1994.
[23] Tom Brinck—Darren Gergle—Scott D. Wood. Usability for the Web. Morgan Kaufman, 2002.
[24] Richard Vidgen—David Avison—Bob Wood—Trevor Wood-Harper. Developing Web Information
Systems. Butterworth Heinemen, 2002.
54
Appendix A
The project experience has been an interesting learning experience, and has presented me with an op-portunity to develop a complete application. I had never attempted anything with this degree of size and
complexity before. I was initially very unsure about how I was ever going to complete the task.
I would suggest the main lesson I have learnt during the course of the project is to start work early.
Certainly with a piece of work this size, it is imperative to begin as soon as is possible. I split my creditsthis year so I did seventy in the first term, and fifty in the second. As there was less work spread out in
the second term, I was a little slow in getting started on the project. This had a knock-on effect on the
amount of work I had to do at the beginning of the second term.
I would strongly advise all undergraduates undertaking projects within the school of Computing tothink strongly about their minimum requirements. These may be changed at a date far later than they
need to be handed in. I would recomend the minimum requirements are constantly reviewed to ensure
they still represent the project’s direction.
Documentation is an important part of project work. I have now learned the hard way, that every-
thing must be accurately documented. Before I undertook the project, I did not consider the importanceof ensuring each source of information was officially reported on before the project began, as it was not
some I had to do before. Similarly factors that affected the final outcome of the application needed tobe offically recorded.
Requirements was an area that I had little experience in, and no interest in before the start of the project.I feel this phase has taught me the most. Before I began work on the requirements phase, I had no idea
of what the application should do, let alone how. As soon as I had completed the first full interview, I
had a good idea of what the application would turn out like. To the point that the application is not so
55
different now to how I imagined it at that moment.
In terms of applicability to future professional ventures, I have learned that implementation is far fromthe be-all and end-all of software development. Implementation was, and still is, the phase of software
development that I enjoyed the most. However, I am far more aware of the importance of other phases.
For example, if the application is solidly designed, implementation is far simpler. I have realised thateach stage in the cycle is fundamental to the successful completion of an application within an allocated
timeslot.
Finally, I have learned the write-up of the project is not a task to be under-estimated. It is not sim-
ply writing up the work, but the various issues connected with it. This is especially important whenlearning a new word-processing package. Proof-reading and error checking are not processes that can
be taken lightly. These must be completed to as high a degree as is possible, and as such cannot be leftuntil the last few hours.
56
Appendix B
These are questions, and the results from the requirements interviews.
Process interview questions
1. What are the main business processes involving communication with other parties?
2. What is the purpose of each process involving communication?
3. How is each process carried out?
4. What data is exchanged between each party?
5. Where does the communication take place?
6. How long does it take each instance of communication to take place?
7. Of those processes identified, which of those normally needs to communicate with two or moreparties?
8. Who are the various parties involved in each process?
9. Do you feel for any process, the current method of communication is inappropriate, either in termsof time, efficiency, or measuring the communication has taken place?
10. What processes require two-way communication, i.e. you initiate communication and require aresponse?
11. For each process identified, how is it run?
57
12. How is the communication point indentified - i.e. how do you find out the contact information for
each party?
13. In two-way communication, how is the return communication stored, if at all?
14. What is done with the stored communication?
15. How would you contact 100 students to meet in the Conference Auditorium?
16. How long would this take?
17. Do you feel this is efficient?
18. Are there any processes that require one-way communication of a specific message at regular
intervals?
19. Which software platforms do you use?
Discussion of actual application
1. When selecting the recipients of the message, would it be appropriate to manually enter the num-
bers?
2. Ideally how would you select the potential recipients of the message?
3. Are there any groups of people whose numbers ought not to be known by everyone who uses the
system?
4. Are there instances where it would be useful for a recipient to reply back? What are they?
5. Should messages sent back to you be stored in the application itself?
6. Would you wish to be notified should a message fail to be sent? Nonfunctional requirements
7. When messages are sent back, would you like them stored indefinitely until you delete them, or
should they be removed after a certain time?
8. Would a feature allowing recipients to reply for free be of any use?
9. Would a list of all potential recipients be sufficient?
10. Are certain processes carried out with enough regularity to warrant a template message feature?
11. Assuming the application held details about all potential recipients, would you consider having to
manually enter / remove recipient details into the system?
58
12. Would a group function be useful?
13. Would the ability to create groups be useful?
14. Would a record of messages you have sent be of any use?
15. What features would you expect of the application?
Interview with Chalie Brown Common examples of communication
1. Communication with students re: careers centre
Communication involved
� Charlie receives information from the careers centre. This information often needs to be
passed on to students.
Purpose of communication
� One particular example of this was Wednesday the 11th February 2004. The careers centremailed Charlie with the intention of holding a careers meeting. Charlie had to gather enough
interest from students by Friday 13th February 2004, to warrant the meeting being held
Data exchanged between parties
� The data exchanged is merely notification of an event. It tends to be one-way communica-tion; Charlie needs to inform the students that the careers event is being held. If students
require more information, then they may ask for it, but it is not an essential part of the com-
munication.
How long it takes to communicate with said party
� This depends on the kind of meeting required, and Charlie’s preferred method. The exampleon Wednesday 11th Februrary 2004 required Charlie to attempt to contact all Computing
and Computer Science students in their final year. Charlie chose the newsgroups as the pre-
ferred method, and as such did not take long. Had he chosen mail, which he said he hasdone in the past, it would have taken a significantly longer amount of time.
What is the preferred method of communication?
59
� This tends to be situation dependent. Charlie says that he tends to use the newsgroups over
e-mail, simply because of the amount of time it takes to send group e-mails for all those who
may be interested. E-mail aliases for groups are often unhelpful in this situation, as the ca-reers meetings are not simply programme dependent, but often module dependent. He says
that some careers meetings may only be appropriate for those studying particular modules,
for example Secure Computing
Does the interviewee feel the method of communication used is appropriate?� As stated above, Charlie tends to use either mail or newsgroups. However, in this situation
he feels that both are inappropriate. Going back to the example on February 11th 2004, the
careers meeting had to be cancelled as Charlie could not contact enough students within the
time given to warrant the meeting being held. He feels that the newsgroups used withinthe school are not sufficient. It is impossible to guarantee students will read the message,
or if they are subscribed to the particular newsgroup. In the example of mail, had Charlie
decided to mail every single finalist reading a Computing or Computer Science degree, itwould have taken a significant part of his day to do this. Charlie also feels that because it is
impossible to guarantee mail has been read, with regards to events such as this, this methodof communication is also inappropriate.
Does the message sent tend to be to two or more parties?
� Always. There is never a situation where a careers meeting is held just for one person.
2. Communication with students re: payroll
Communication involved
� Students can be employed by the university, and Charlie is responsible for those who are
employed by the school of Computing.
Purpose of communication
� There is a wide range of reasons as to why Charlie wants to get in touch with students re-garding the payroll. The main reasons given for this are to confirm student’s bank details,
national insurance number etc; to notify students that if they are to get the money for thecurrent tax year, they must fill in a claim form. Charlie says that claim forms must be filled
in by December, if they are to be considered for the current tax year.
60
Data exchanged between parties
� The data exchanged depends on the situation. If Charlie is requesting finance details, he
will send a message to those students, and expects this information sent back to him. When
Charlie notifies students that the claim form must be in, this tends to be one-way communi-cation.
How long it takes to communicate with said party
� It can be a time consuming activity, depending on the information given. If there are six
students, and he is only given their names, he must manually get their user IDs from theschool’s information system, and mail each one. There are rarely many people this informa-
tion needs to get to - Charlie suggests around six or seven each time. If this number were to
grow, it would substantially increase the amount of time to communicate with each student.
What is the preferred method of communication?
� E-mail.
Does the interviewee feel the method of communication used is appropriate?
� Charlie suggests that in the case of trying to get student’s claim forms in so they can be
considered for the current tax year, it is inappropriate. The deadline is mid December, andmany students are back home for the Christmas break. Students often do not check their
mail over this period. There have been cases where Charlie has had to check the school’sinformation system to get their home address, in order to post them a letter. In this particular
instance, it is inappropriate. Charlie feels that when mailing students to request financial
information, manually checking each student’s user-id can be a time-consuming excercise.He also returns to the point that it is impossible to check the student has received the mail.
Does the message have to be sent to two or more parties?
� The message tends to be sent to several people, but not always. The majority of communi-
cation under these circumstances is to more than one person.
61
3. Communication with students re: marking sessions
Communication involved
� As stated before, students can work for the school of Computing. One of the main jobs they
have is to help the SE11 and SE12 teams mark first year coursework. These are program-ming modules, and the computer program must be marked face-to-face with the student. As
such, it is necessary to employ extra help, as it would be too time-consuming for the lecturerto under-take by themselves.
Purpose of communication
� To organise marking times, meetings before the markings.
Data exchanged between parties
� Again, this tends to be short notification messages. Charlie will mail the students informingthem of meeting times, or marking times.
How long it takes to communicate with said party
� Charlie has to get in contact with each member of the team, sending them the appropriatemessage. He says he uses e-mail aliases for the groups, but these may often be flawed.
What is the preferred method of communication?
Does the interviewee feel the method of communication used is appropriate?
� Charlie is satisfied with the current method of communication. However, he suggests thatstudents do not always check their mail in time for the message to bear any significance
to them. He also suggests that the mail aliases are not always particularly useful - some
students may not be available for the marking session; some may have decided they do notwant to do it any more, and therefore will not want to receive mail about it.
Does the message have to be sent to two or more parties?
62
� Always.
4. Communication with students re: fire drills
Communication involved
� Charlie helps in organising fire drills, and sometimes would like feedback from the students.
Purpose of communication
� Very occasionally, there will be large fire-drill based on an entire building - for example theE.C. Stoner building. Charlie feels it is useful to gain feedback on how well this was done.
He wishes to contact all students asking for their opinions.
Data exchanged between parties
� A small message to the students. If the students wish to reply, they will send their opinionsback to Charlie. Typically this will be in the same form as he sent them.
How long it takes to communicate with said party
� This is completely dependent on the preferred method. Charlie tends to use newsgroups over
e-mail. This does not take a long time. If he felt he had to use mail, he suggests it would bea very time consuming excercise - sending a blanket email to each student within the school.
What is the preferred method of communication?
� Newsgroups
Does the interviewee feel the method of communication used is appropriate?
� Once again, Charlie suggests that the fact students cannot be guaranteed to check the news-groups means they are not completely reliable. However, it is a rare occurance that he
contacts students regardin this issue, and does not require 350 seperate replies.
Does the message have to be sent to two or more parties?
63
� Always
5. Communication with staff re: health and safety
Communication involved
� Charlie has an important role concerned with health and safety. He must get in contact withvarious people concerned with this
Purpose of communication
� There is not a single specific instance as to why, it is situation dependent. Examples could
include feedback; request for forms; organising events.
Data exchanged between parties
� It depends on the situation, but it tends to be fairly short notifications.
How long it takes to communicate with said party
� This depends on the people that Charlie needs to communicate with. He says that occasion-
ally he will have to contact people in the faculty of Engineering with regards to health andsafety issues. This can be a time-consuming event, since these people will not be stored
under the school’s information system.
What is the preferred method of communication?
� E-mail.
Does the interviewee feel the method of communication used is appropriate?
� Mail is appropriate for these instances. Charlie does suggest that in an urgent case it would
not be appropriate - people often overlook mail sent to them, especially if they receive a lot.Staff receive a lot more mail than the majority of students. It is also awkward to find the
e-mail addresses of those within the faculty of engineering.
64
Does the message have to be sent to two or more parties?
� Usually
6. Various other reasons for communication
� To staff - re: committee work� To staff - re: minutes� To postgrads - re: meeting times� To postgrads - re: work available� To students re: bank statements
These types of communication are more general than the ones listed above. There are rarelyspecific situations for him to comment on. However, the re-occuring themes that mailing people
often can be time-consuming as he must select each recipient in turn; he cannot guarantee mailis read - he says he would like a system similar to that within the labs - where Mark Conmy
may check whether users have logged on or not - only for mail; students cannot be guaranteed
to read newsgroups. Whilst students are encouraged to use the newsgroups, it is impossible tomake them, and such are not always the best methods of communication. Charlie also feels for
messages that must be received quickly, both these methods are often inappropriate.
7. Thoughts on the proposed application
� It would be inappropriate to manually enter each mobile telephone number of each recipientof the message.
� It would be highly advantageous to send the same message to a group of people simultane-ously.
� Recipients should be placed into logical groups - by module code; student payroll; healthand safety etc.
� From these groups it would be useful to select individual recipient, by a method similar toa tick-box. He gives the example of the payroll. He has sixty students on the payroll, and
wishes to contact four of them. He would like to select the group “payroll”, and tick the
appropriate students to send to.� Charlie feels that the information held by the application should be shared by all users. He
originally did not feel that confidentiality would be an issue here. However, when giventhe situation that students may have access to staff mobile numbers, fire personnel mobile
numbers etc, he said he would have to “come back” to this point.
65
� Message recipients should be accessed via two communication end-points, their real name,
and their username. Charlie says that he recieves instructions to contact certain people, and
is given either usernames or full names. The system should cater for both end-points.� The application should definitely be able to receive messages back from recipients. He gives
the situation of the payroll student on holiday; they may not have access to a computer, and
it would be useful for them to send messages back to the application, in order for Charlie toget the information he needs back quickly.
� The application should tell users if a message to any recipient has failed. Charlie feels that
he must know if the communication is not succesful, so he may try and contact them again.� Messages should be stored on the application until they are manually deleted. Charlie at first
suggested an automatic clear out at the end of the academic year, but rescinded this point, assome information (such as the payroll information) should be stored for three years.
� To encourage recipients to send messages back, an option of a “reply-flag” should be avail-
able.� Template message is not a feature Charlie would consider to be of much use. He admitted
he did sent similar messages, but at such irregular intervals, and with a character limit of
160 characters, it would not be a feature he would use.� The application would have to hold generic data on potential recipients. Charlie did not feel
that entering recipient numbers into the application would be a valuable use of his time. He
did not want to have to manually change this information each academic year.� The application should also offer it’s users the ability to create their own groups of recipients.
In Charlie’s case, students on the payroll would be a group relevant only to him; his post-
grad group would be only relevant to him. He suggested that the application should havelists of generic groups (such as module codes etc), and users are then free to create their own
groups.� The application should store sent messages, in much the same way outlook, pine and other
e-mail clients store sent e-mails� Charlie suggested that it would be a nice feature if the application could bring up all groups,
private or otherwise a student belongs to. He suggested that at times companies will mail
him regarding applicants, to see what extra-curriculur activities they did. If the application
returned all the various groups, it would be easier to see.� As a purely non-functional requirement, Charlie felt that the it would be good if the appli-
cation had a picture of each recipient associated with them, so he could see who he was
messaging. In much the same way that the school’s SIS system stores photographs of stu-dents and staff
Interview with Stuart Roberts Common examples of communication
66
1. Communication with students re: classes
Communication involved
� Stuart regularly has to communicate with classes he lectures to.
Purpose of communication
� There are various reasons for Stuart to communicate with his classes. These are: notifying
a class that there is a change of venue - for either a lecture, or an in-class test; there may be
an error on a coursework sheet / worksheet which needs to be corrected; reminding studentsabout a venue change, or an in-class test; reminding students there is an important deadline,
normally courswork.
Data exchanged between parties
� Simple messages, very short in size e.g. “Please be aware that DB31 on Tuesday is now inLT24”
How long it takes to communicate with said party
� This depends on the communication method. E-mail can be costly, if e-mail aliases are not
defined. Using the school’s newsgroups does not take a long time.
What is the preferred method of communication?
� Stuart says in these instances, he prefers to use the newsgroups, but if the situation warranted
it, he may use e-mail.
Does the interviewee feel the method of communication used is appropriate?
� Stuart feels that not enough students regularly check postings on the newsgroups. As such,they may miss important information. He gives the example of a student missing a lecture
- where they were notifed of a change of venue for the in-class test, and does not check thenewsgroups that week. This would be disastrous for said student.
Does the message sent tend to be to two or more parties?
67
� Always
2. Communication with students re: tuteesCommunication involved
� Stuart is a tutor, and takes care of a small number of students.
Purpose of communication
� Again, this is situation dependent. Stuart says normally to arrange meetings with his tutees,
or to chase up a tutee who has not responded to him for a while.
Data exchanged between parties
� Short messages, alluding either to a meeting time, or a short messae asking where the stu-
dent is and why they have not responded.
How long it takes to communicate with said party
� Not long. Stuart uses e-mail aliases for his tutees, and therefore it is a matter of clicking onthe appropriate group.
What is the preferred method of communication?
� E-mail.
Does the interviewee feel the method of communication used is appropriate?
� Stuart feels that e-mail is not appropriate for contacting tutees who have been out of contactfor a while. E-mail is not close enough an access point to the student. If they are ill, the
chances are, they will not have access to their SoC account. Stuart also suggests that e-mail
is often inappropriate if the meeting is to be set-up within a couple of days of sending themail. Students do not always check their mail as regularly as they should, and as such, com-
munication such as this is often missed.
68
Does the message sent tend to be to two or more parties?
� Depends on the situation. If Stuart is intending to meet his entire group, then he will need to
communicate with every one within that group. However, Stuart suggests that normally this
type of communication will be on a one-to-one basis.
3. Communication with students re: Final Year Project
Communication involved
� Stuart is also a final year project supervisor, and often needs to contact those who he is su-
pervising.
Purpose of communication
� Stuart is required to hold meeting with those he is supervising, and normally the reason he
will contact his project students is to arrange meetings. Stuart will often mail his projectstudents to comment on work they have submitted to him to check over.
Data exchanged between parties
� This depends on the situation. If Stuart is organising a meeting with a project student, it will
be a small sentence suggesting a time and a place. However, if he is commenting on worksubmitted as part of the project, then it will be a substantial critique of said work.
How long it takes to communicate with said party
� Not long - Stuart will simply enter the student’s e-mail address, type his message and send it.
What is the preferred method of communication?
� Always e-mail.
Does the interviewee feel the method of communication used is appropriate?
69
� Stuart feels that when organising meetings, the problem of students not checking their mail
can be a problem, especially if the meeting is urgent. Occasionally students will not get the
message in time, and miss meetings. However, in terms of commenting upon work, Stuartfeels that e-mail is suitable. He suggests that the ability to send as many characters as neces-
sary to the student is useful, so they may get a greater understanding of what he feels about
the work. Also, it is not as important the e-mail is checked by the student soon after it is sent.
Does the message sent tend to be to two or more parties?
� Normally to one student.
4. Communication with students re: ad-hoc queries
Communication involved
� Stuart lectures on most things concerned with databases, and as such answers a lot of
database related queries.
Purpose of communication
� Students will often ask Stuart for information, particularly regarding databases. He will at-tempt to answer these questions in order to help the student mailing him.
Data exchanged between parties
� Stuart will send back the answer to the question. Often this is a comparatively lengthy re-
sponse.
How long it takes to communicate with said party
� A short time. Stuart will simply reply to the mail sent, or follow up a question posed onnewsgroups.
What is the preferred method of communication?
� It depends on the situation. Queries regarding specific modules e.g. DB21, are often posed
on the school’s newsgroups. Stuart will use the newsgroups to respond. However, if Stuart
70
is mailed, he tends to use e-mail to reply. Usually, Stuart will respond to the student in
question using the same method of communication they used.
Does the interviewee feel the method of communication used is appropriate?
� Stuart feels that both e-mail and newsgroups are appropriate forms of communication for
ad-hoc queries. They are seldom urgent, and he feels if these queries are urgent, the studentwill be checking e-mail / news regularly to see if he has responded.
Does the message sent tend to be to two or more parties?
� Not normally. Newsgroups are public, and could be seen as communication to more than
one party, however, Stuart will post a message in direct reply to another.
5. Communication with students re: missing a meetingCommunication involved
� Stuart will communicate with a student or set of students regarding meetings.
Purpose of communication
� Stuart will be out of the school of Computing for various reasons at points in the academic
year. If these appointments go on for too long, he needs to contact students or staff in order
to tell them he will not be able to make the meeting / he will be late.
Data exchanged between parties
� A short message explaining he will not be able to make the meeting.
How long it takes to communicate with said party
� Usually not long. Although if Stuart is communicating with a group of people, it will takelonger as he must find their mail addresses if an alias has not been created.
What is the preferred method of communication?
71
� E-mail. Does the interviewee feel the method of communication used is appropriate?
� Not normally. If Stuart is running late, then it will be a short time period between the mes-sage sent and the meeting. As such, e-mail will not be sufficient, as the recipients cannot be
guaranteed to check their mail.
Does the message sent tend to be to two or more parties?
� Depends on the meeting involved.
6. Thoughts on the proposed application
� It would be highly inappropriate for Stuart to manually enter the numbers to the application.He uses the example of telling an entire class their lecture has moved. It would take him
a significant amount of time. He specifies that if he was communicating with more than
one person, then he would not consider using the application if he had to enter each numberindividually.
� The application needs to be able to send the same message to multiple recipients in the same
process.� Stuart would require potential recipients of the message to be set up into logical groups,
to facilitate with the communication process. He suggests that a system much like e-mail
aliases would be ideal.� The application should hide recipient information from some users of the system. Stuart
gives the situation that certain people would not be happy if their personal contact details
were available to all who use the system. For example, if there was a case where a stu-dent used the system, it would not be a good idea to allow them to have full access to all
recipient’s information.� The application must allow recipients to message back to the application. Stuart gives the
example that he may message a student to find out why they have not turned up to an ar-
ranged meeting, he would want the student to be able to reply.� The application must allow messages to be created within itself and not be forced to use
external sources - e.g. files, mail� The application must store more information than the recipient’s number. Stuart suggests
that he would want to know the name; username and mobile number of the recipient as the
minimum amount of information he would require.
72
� The application must store the messages within itself. Stuart does suggest that a facility to
combine the application with current systems could be useful. For example, an option to
have the message forwarded to his e-mail address.� The application must notify the user should a message fail.� Stuart would not want automatic deletion of the messages held in the application. He says
that there may be occasions when he must refer to a message as evidence that the recipientwas contacted. However, he suggests an option to autmatically delete specific messages
would be a good feature - as his e-mail inbox often ends up very full and unmanageable, andfeels this application may present a similar situation.
� A template message feature would not be a feature that Stuart would use.� Stuart would not consider having to enter all recipient details into the system as a viable
option. i.e. The logical groups he suggested he would like to use would have to be created
by someone other than him. He certainly would not appreciate having to enter these detailsyear after year. He suggests that generic groups would be a useful tool - e.g. module groups,
staff etc.� Stuart however, would like the ability to create his own logical groups. He suggests this
would be useful for contacting his tutor and project students.� An option to record messages sent would be useful, like an outbox facility in Outlook.� An option to request message delivery reports would be useful. He does however specify
that it would not be essential.
Interview with Shaheen Bibi and Maureen HopkinsonCommon examples of communication
1. Communication with potential studentsCommunication involved
� Shaheen is often contacted by potential students, either under-graduates or post-graduates
with specific questions.
Purpose of communication
� Shaheen must respond to the questions posed, or help them as much as she can.
Data exchanged between parties
� Usually a reply to a question, or forwarding the required information.
73
How long it takes to communicate with said party
� Not long - as it is a reply, it takes as long as it takes to write down / say what is needed.
There is no time taken trying to find the communication end-point.
What is the preferred method of communication?
� Often situation dependent. Usually e-mail, but Shaheen states that she also uses the tele-
phone and face-to-face meetings.
Does the interviewee feel the method of communication used is appropriate?
� Yes.
Does the message sent tend to be to two or more parties?
� Not normally.
2. Communication with external companies
Communication involved
� Shaheen is contacted by external companies offering work placements to students.
Purpose of communication
� Shaheen must respond to the questions posed, or help them as much as she can.
Data exchanged between parties
� Usually a reply to a question, or forwarding the required information.
How long it takes to communicate with said party
� Not long - as it is a reply, it takes as long as it takes to write down / say what is needed.
There is no time taken trying to find the communication end-point.
74
What is the preferred method of communication?
� Often situation dependent. Usually e-mail, but Shaheen states that she also uses the tele-
phone and face-to-face meetings.
Does the interviewee feel the method of communication used is appropriate?
� Yes.
Does the message sent tend to be to two or more parties?
� Not normally.
3. Communication with external examiners
Communication involved
� Maureen helps with the communication between lecturers and external examiners.
Purpose of communication
� When exam papers are written by the lecturers, they must be sent off to external examin-
ers to ensure they are OK. Maureen will send these documents to the external examiners
through mail. If there are comments on the paper, Maureen must forward these to the lec-turer responsible.
Data exchanged between parties
� The exam papers themselves, and forwarding the comments on the papers to the appropriate
lecturer.
How long it takes to communicate with said party
� Not long.
75
What is the preferred method of communication?
� E-mail.
Does the interviewee feel the method of communication used is appropriate?
� Yes.
Does the message sent tend to be to two or more parties?
� Not normally.
4. Other processes.
� Processing holiday requests from staff.� Sickness reports, both students and staff.� Dealing with e-mails from companies regarding applicants who have / are studying at the
university.� Forwarding e-mail� Room bookings
Both Shaheen and Maureen both feel that the current system for all communication processes
for their role are sufficient. Neither of them see any need to have an SMS solution to aid themwith their daily work. However, both Shaheen and Maureen felt that they may use the application
at certain points if it was made, but could not identify a definite process they would use it for
- it would be more ad-hoc. They give the example that on the day of the interview, Tuesday10th February 2004, a lecturer called in sick, and asked them to put a message on the module
newsgroups saying so. Both agreed that the proposed application would have been useful on that
particular instance, but maintained that it would only ever aid them in unusual instances such asthis - there would be no specific processes aided by the development of the application.
Interview with Yasmeen AzizCommon examples of communication
1. Communication with potential post-grads
Communication involved
76
� Yasmin receives inquiries from potential post-graduates.
Purpose of communication
� Yasmin must respond to the questions posed, or help them as much as she can.
Data exchanged between parties
� Usually a reply to a question, or forwarding the required information.
How long it takes to communicate with said party
� Not long - as it is a reply, it takes as long as it takes to write down / say what is needed.There is no time taken trying to find the communication end-point.
What is the preferred method of communication?
� Usually e-mail.
Does the interviewee feel the method of communication used is appropriate?
� Yes.
Does the message sent tend to be to two or more parties?
� Not normally.
2. Communication with first year post-grads
Communication involved
� Yasmin takes the responsibility of looking after the first year post-graduates. Purpose of communication
� On the 8th of each month, Yasmin will organise meetings with the first year post-graduates
- “development meetings”.
Data exchanged between parties
77
� The time, and the meeting place.
How long it takes to communicate with said party
� Not long. Yasmin says she uses e-mail aliases if she needs to meet as a group. If the meeting
is on a one-to-one basis, she will simply enter the recipients mail address.
What is the preferred method of communication?
� E-mail. Does the interviewee feel the method of communication used is appropriate?
� Yes. Does the message sent tend to be to two or more parties?
� Not normally.
� Yasmin will send other people e-mails they may be suited to. Purpose of communication
� Often Yasmin will receive information that may be of interest to other people. One example
she gives is social events for post-graduates. She will forward the mail she receives to thosewhom it may be kiof interest to.
Data exchanged between parties
� The original mail.
How long it takes to communicate with said party
� Not long - Yasmin has e-mail aliases defined, such as “staff”.
What is the preferred method of communication?
� E-mail. Does the interviewee feel the method of communication used is appropriate?
� Yes. Does the message sent tend to be to two or more parties?
� Not normally.
78
Yasmin says that there are no situations in her line of work where the SMS application would
prove particularly useful. She feels the existing system is fine, and has no issues with it. As such,
she says the SMS application would not be of any great use to her. However, Yasmin feels thatif such an application were developed, she may end up using it, especially if it was not limited
to certain workstations. In terms of her current processes however, they could not be improved
using the SMS tool. The communication she tends to indulge in carries too much information forher to use it in her daily routines.
Interview with Jonathon Ainsworth
On interviewing Stuart and Charlie, the need for admin support was clear. Users wanted logical groupsin which to select the recipients of the message from. They were not however, prepared to create this
information themselves. Both Stewart and Charlie required the application to integrate with the current
information system (SIS, in the case of the school of Computing. Jonathon helps to maintain the SIS.
The interview with Jonathon was unstructured, I did not have any specific questions about the appli-cation with regards to the admin side, other than how he felt the application should integrate itself with
the current information system. As far as the application was concerned, for it to be much use, I feel it
must be portable - that is, it must be able to be used by various systems, and as such, it cannot have theSIS information hardcoded inside itself.
Jonathon felt that he did not need to interface directly with the application itself. As far as he wasconcerned, it did not make any difference whether the information the application was required was
retrieved through the application, or directly through the database containing SIS.
Both Jonathon and I agreed on two key concepts. The application must use the live copy of SIS for
it to be useful. Replicated copies of databases are only as useful as often as they are updated. We bothfelt that a replicated copy of the database may end up containing redundant information. Not only this,
but the complications of exporting, FTP’ing and importing tables did not justify this step.
The other concept that Jonathon and I agreed on was that of the application not storing any database ob-
jects on the school’s information system. The system should use it’s own database should objects needto be stored. SIS is a complicated system as it is, we did not need extra databse objects to be created on it.
This lead on to two requirements from the admin side of the application: the data must be retrieveddirectly from SIS; the application must store it’s information in another place, not SIS.
This presented a problem - if we must use the SIS information (i.e. use live not replicated data), but must
tailor the application for it to be portable, how do we retrieve the information. Jonathon suggested that
79
the application should use a central table. This table would store the names of the groups (DB31; staff;
IS34 etc), and the query required to find those groups within SIS. When the application is required to
find out those belonging to a group, it will use the query stored in the central table, and the informationis returned from SIS.
As stated above, Jonathon could not see the need for the application to assist the admin side of theoperation. My original thoughts were that we should provide a simple interface, where the admin per-
son would enter the database address, and the name of the table, and a small “select” string. Jonathonpointed out that this did not make his job any easier, and the queries used in SIS, and presumably many
more information systems were too complex to simply write down the table name, and the information
would be returned.
Jonathon said that the idea of integrating applications with existing information systems was a commonone. He also stated that requiring admin help was also standard. He gave the example of a time tabling
application. The application requires information from SIS. As such, Jonathon selects the required in-
formation, and the application stores it in files. These files are then directly used by the application.Johnathon did comment that having the queries stored in a central table was uncommon in the applica-
tion world, but did go on to say that the notion of storing actual queries in tables was a common practice.
I was concerned that the level of work required to set up this central table would make the application
unwieldy for the admin people. Jonathon disagreed, and said in the example above, with the timetablingsystem, the only difference between the two methods of integration was that in the timetabling system
he had to use select queries, whereas in the proposed design of the SMS system, he had to use insert
queries. He also mentioned that for the SMS application, there were not going to be that many groups,realistically between 30 and 40, and as such, he would only be required to enter that many rows, which
is not much work. He also said that this would be the only work required, unless new “generic” groups
were required.
I asked Jonathon about the DBMS software SIS was built on. At the school of Computing, PostGresis used. Jonathon said that this piece of software fully supported every standard SQL command. I also
enquired about security - if we are to access SIS through the application, then it must have access to the
a username and password for SIS. I wondered whether the password should be encrypted. Jonathon saidas long as the information required is held securely, he did not feel any special efforts were required.
His main concern was that the password may be available through the title bar of the web page - as
a parameter. e.g. “http://www.comp.leeds.ac.uk/SMSApp?user=ctxpjc&pass=ctxpjcpass”. Obviouslythis is not acceptable. He also suggested that if I was to use PHP - I had to be careful, as occasionally
if a bracket is not closed off, the database connectivity of the application may be visible through theweb-front end.
80
Appendix C
These are examples of the test plans applied the application.Method Driver ProgramformatQuery TestFormatQuery
Number Test Input Expected result Pass / Fail
1 hello it’s a nice day hello it’’s a nice day Pass
2 hello its a nice day hello its a nice day Pass
3 ’’ ’’ Pass4 ’hello ’’hello Pass
5 hello’ hello’’ Pass
Method Driver ProgramcorrectedNumber TestCorrectNumber
Number Test Input Expected result Pass / Fail
1 07222333333 %2b7222333333 Pass
2 +447222333333 +447222333333 Pass3 00447222333333 00447222333333 Pass
4 01222333333 01222333333 Pass
5 07ABCDEFGHI %2b7ABCDEFGHI Pass6 07 %2b7 Pass
81
Method Driver ProgramsendMessageByID TestByID
Number Test Input Expected result Pass / Fail
1 me me, Pete Coleman,
07*********
Pass
2 kate kate, Kate Barrass,
07*********
Pass
3 leon leon, Leon Savidis,
07*********
Pass
4 Me Exception Pass
5 "me " Exception Pass
Method Driver ProgramparseMesasgeBodyTestFormatBody
Number Test Input Expected result Pass / Fail
1 LSMS ctxpjc hello hello Pass2 Pass
3 LSMS Pass
82
Method Driver ProgramcheckParms TestCheckParms
Number Test Input Expected result Pass / Fail
1 "" "Pete Coleman"
07*********
Exception Pass
2 a "Pete Coleman"
07*********
Exception Pass
3 pete "Pete Coleman"
07**********
Pass
4 pete "Pete Coleman" Exception Pass
5 "Pete Coleman"
07***********
Exception Pass
6 pete 07********** Exception Pass
7 pet "Pete Coleman"
07*********
Pass
8 Ineednineteenchars!
"Pete Coleman"
07*********"
Pass
9 12345678901234567890
"Pete Coleman"
07*********"
Pass
10 123456789012345678901
"Pete Coleman"
07*********"
Exception Pass
11 (65 chars) "Pete
Coleman" 07*********
Exception Pass
12 me "" 07********* Exception Pass13 me me 07********* Exception Pass
14 me bob 07********* Pass
15 me gary 07********* Pass16 me (49 chars)
07*********
Pass
17 me (50 chars)
07*********
Pass
18 me (51 chars)
07*********
Exception Pass
83
Method Driver ProgramcheckParms TestCheckParms
Number Test Input Expected result Pass / Fail
19 me "Pete Coleman" "" Exception Pass20 me "Pete Coleman"
0712345678
Exception Pass
21 me "Pete Coleman"
07123456789
Pass
22 me "Pete Coleman"
007123456789
Pass
23 me "Pete Coleman"
00447123456789
Pass
24 me "Pete Coleman"
004471234567890
Exception Pass
25 me "Pete Coleman" (27
0’s)
Exception Pass
26 me "Pete Coleman"
071234a6789
Exception Pass
27 me "Pete Coleman"
07!23456789
Exception Pass
28 me "Pete Coleman"
071234UIIO9
Exception Pass
29 me "Pete Coleman"
07123456789
Pass
84
Appendix D
These are the questions posed to the users evaluating the prouct.
Functionality1. Do you feel the application’s core functions (sending, receiving, status checking) are sufficient?
2. What functions do you feel are missing from the application, functions that would make it more
useful?
3. How well do you feel the application performs the core functions?
4. Does the application’s ability to support many users seem of use to you?
5. Can you see any circumstances where linking the application to other forms of communication(e.g. e-mail) would be useful? Do you feel the application suffers from a lack of integration with
other communication systems?
85
6. Do you feel the application’s methods of sending messages are sufficient? Can you think of any
other forms of message sending that you would like to see included?
Data Management1. To what extent do you feel the application has succesfully merged with the internal information
system?
2. Do you feel any information is missing from the recipient list?
3. Do you feel there are any features missing from the group listing (internal only)?
4. How easy do you feel it is to send messages to a) a single recipient, and b) multiple recipients
(internal only)
5. Do you feel the application gives you an adequate amount of information about the communica-
tion process (in terms of inbox, outbox, status etc)?
6. Do you feel the application gives you an adequate amount of control over information (in termsof adding / deleting information)?
7. Is there any information that the application may have, that you would like to be able to see?
8. How well do you feel the application allows you to create personalised groups?
9. How well do you feel the application allows you to create external users?
86
10. Are there any changes you would feel should or could be made, to either the personalised groups,
or external users, or an emalgamation of them both?
11. Do you feel there is enough interaction within the application between external recipients, andinternal recipients? Do you think there is too much? I.E. Do you feel the way the application
differentiates between these groups is sufficent?
12. Do you feel you have sufficient control over these features - in terms of adding / deleting infor-
mation? Are there any features that you would prefer to be included / excluded?
UsabilityAesthetics
1. Does the application appear sufficiently professional in appearance?
2. To what extent do you feel the application uses sensible and attractive colouring?
3. To what extent do you feel the application uses sensible and attractive fonts (in terms of typefaceand size)?
4. To what extent do you feel the application employs a sensible and attractive page layouy?
5. From the listed features, are there any changes or preferences you would want employed (colour-ing, font, physical layout)?
6. From the listed features can you list what you particularly dislike, and what you particularly like?
87
7. How simple do you feel the page looks? Bear in mind LOOKS, and not IS!
Navigation and use
1. To what extent do you feel the application provides you with key information in terms ofnavigation (where am I, where have I been, where can I go)?
2. Do you feel the omission of coloured links for visited pages is a good one?
3. How simple do you feel it is to perform a specific function - e.g. create a group?
4. Do you feel the method of modifying recipients / deleting messages is appropriate? Whatchanges would you like to see?
5. Do you feel the forms used for sending messages / adding user information - are easy tounderstand?
6. Do you feel that the dynamic nature of the forms is a good attribute (e.g. sending bynumber, the text form will not appear until a number has been selected)
7. Do you agree with the navigation style of the links permanently stuck to the left of thepage? How would you prefer them?
8. If you are re-directed in the application to a different page, do you feel that it is obvious?What would you change?
88
9. How do you feel about the error checking - is it succesful? In terms of a) are the rightkind of errors caught, b) are the errors handled accurately, c) Does the application revertadequately after an error has been found?
Speed
1. Does each page on the site load in an appropriate time?
2. How do you feel about the length of time it takes to send a) a single message b) multiple mes-
sages?
3. If the speed was not improved, would you still consider using the application?
4. How do you feel about the speed of the managing your data (viewing, adding, removing - inbox,outbox, status, usergroups, external).
89