Table
of
Contents
SOFTWARE
PROJECT
ENGINEERING
.........................................................................................
2
INTRODUCTION
.............................................................................................................................................
2
REQUIREMENTS
............................................................................................................................................
2
DESIGN
DOCUMENT
....................................................................................................................................
4
TEST
PLAN
......................................................................................................................................................
6
Meeting
Minutes
...........................................................................................................................................
6
Back
and
Frond
End
Design
code
and
Graphical
User
Interface
.............................................
7

SOFTWARE
PROJECT
ENGINEERING
INTRODUCTION
For
this
project
module,
we
were
required
to
work
in
as
a
team
(students
from
Robert
Gordon
University,
Aberdeen
and
students
from
International
Institute
of
Information
Technology,
Bangalore)
to
design,
build,
test
and
evaluate
a
mobile
software
application
using
the
Agile
methodology.
The
aims
and
objectives
of
the
project
were
to
provide
students
with
the
opportunity
to:
• Gain
first-­‐hand
experience
of
the
principles
and
techniques
required
to
become
an
effective
member
of
a
software
development
team
• Use
selected
techniques
software
project
management
best
practices
• Undertake
software
development
activities
including,
project
planning,
requirements
gathering
and
analysis,
system
design,
software
implementation
and
testing
• Perform
object-­‐oriented
analysis
and
design
• Consider
the
broader
legal,
social,
ethical
and
professional
issues
associated
with
developing
software
applications
• Work with others to develop software in a collaborative project to satisfy a
customer demand
• Use
software
engineering
best
practices
in
the
course
of
the
project
• Use Internet hosted collaboration tools
• Learn about mobile device software development
REQUIREMENTS
The
requirement
models
are
classified
as
follows:
Software
Development
Tools
We
were
required
to
use
Android
Software
Developer’s
kit
(SDK),
which
includes
a
fully
configured
update
version
of
Eclipse
development
environment.
We
were
also
required
to
use
the
Android
Gingerbread
(V2.3)
release
as
mobile
phone
Operating
System
version
Software
Development
Process
We
were
required
to
use
a
combination
of
Scrum
(Schwaber
&
Beedle,
2001)
(Schwaber
2004)
and
Extreme
Programming
(Beck
&
Andres,
2004).
These
methods
requirement
process
role
definitions
in
scum
and
the
following
roles
were
defined:

• Product
owner:
The
customer's
representative
on
the
project.
Responsible
for
explaining
requirements
and
deciding
priorities.
Academic
staff
will
be
the
product
owners
on
the
project.
• Scrum
master:
The
scum
master
is
a
team
leader.
Responsible
for
ensuring
the
team
follows
the
scrum
method
correctly.
Also,
responsible
for
protecting
the
team
from
any
distractions
or
blockages
confronting
the
team.
The
scrum
master
will
make
resolve
disputes
within
the
team
and
make
the
final
decision
where
team
members
can't
reach
agreement.
• Team
members:
The
rest
of
the
development
team
are
team
members.
This
includes
(at
least)
designers,
requirements
analysts,
developers
and
testers.
a. Testers
work
with
developers
to
define
and
execute
test
plans.
Tests
scenarios
and
results
should
be
recorded
b. Requirements
analysts
liaise
with
the
product
owners
to
understand
and
elaborate
requirements.
They
may
prepare
storyboards,
use
cases
or
class
diagrams
(depending
on
the
types
of
product)
to
disseminate
details
to
team
members.
c. Developers
write
and
unit
test
code
d. Integrator
integrates
code
releases
to
maintain
a
working
repository
of
code
for
the
team.
Application
Requirements
(User
stories)
High-­‐Level
Requirement
Epics
1. As
a
survey
participant,
I
want
to
be
able
to
fill-­‐in
survey
questionnaires
while
I
am
on
the
move,
in
order
to
inform
and
influence
survey
owners.
2. As
a
survey
owner,
I
want
to
be
able
to
gather
qualitative
and
quantitative
information,
in
order
to
allow
evidence-­‐based
decision-­‐making.
3. As
an
administrator
I
want
to
be
able
to
create
and
test
surveys
in
order
to
meet
the
needs
of
survey
owners.
1. ,
I
want
to
see
the
collated
scores
of
my
survey
results,
in
order
to
understand
survey
participant
responses.
2. As
a
survey
participant,
I
want
to
complete
surveys
easily,
in
order
to
provide
information
quickly.
3. As
an
administrator,
I
want
to
create
a
survey
question
using
a
5
or
7
value
Likert
scale,
in
order
to
meet
the
needs
of
the
survey
owner.
User
Stories:
User
stories
were
defined
and
divided
into
three
sprints/iterations.
Below
is
a
list
of
all
the
User
stories.
I. As
a
survey
owner,
I
want
to
see
collated
survey
response
data
presented
clearly,
so
I
can
easily
understand
survey
participant
responses,
so
I
can
make
good
decisions.
II. As
an
administrator
a
I
want
to
define
the
question
text
on
Likert
scale
survey
questions,
in
order
to
meet
the
needs
of
the
survey
owner.
III. As
an
administrator
a
I
want
to
define
the
legend
text
on
Likert
scale
survey
questions,
in
order
to
meet
the
needs
of
the
survey
owner.

IV. As
an
administrator
a
I
want
to
define
the
legend
text
on
Likert
scale
survey
questions,
in
order
to
meet
the
needs
of
the
survey
owner.
V. As
a
survey
participant,
I
want
to
give
yes
or
no
answers
to
appropriate
questions
in
order
to
express
my
opinion
to
the
survey
owner.
VI. As
a
survey
participant,
I
want
to
type
written
responses
to
open
ended
questions
in
order
to
express
my
opinion
to
the
survey
owner.
VII. As
a
survey
participant,
I
want
to
navigate
forwards
and
backwards
between
survey
questions,
in
order
to
compare
and
refine
my
survey
responses.
VIII. As
a
survey
participant,
I
want
to
be
able
to
save
(and
later
resume)
a
partially
completed
survey
in
order
to
choose
convenient
times
to
respond
to
survey
questions.
IX. As
a
survey
participant,
I
want
feedback
that
my
survey
responses
have
been
received
in
order
to
express
my
opinion
to
the
survey
owner.
DESIGN
DOCUMENT
Fig
1(Class
Diagram)
Fig
(1)
shows
the
UML
class
diagram
for
the
survey
application.
It
contains
eight
classes
which
represent
the
different
activity
platforms
on
the
android
application.
This
includes;
• openEnded
activity:
creates
and
manages
an
open
ended
question.

• YesNoQue
activity:
creates
and
manages
yes
and
no
questions
with
the
functionality
of
having
the
survey
participant’s
responses
saved
so
that
when
he/she
navigates
back
and
forth,
data
is
not
lost.
• LikertScale
activity:
creates
and
manages
either
a
5
or
7
point
likert
scale
question.
Also
allows
the
survey
owner
flexibility
on
choosing
the
different
options
for
the
lickert
scale
question-­‐type
chosen.
• Survey
activity:
this
manages
the
survey
created
by
the
survey
owner
differentiating
it
from
other
surveys
and
allowing
the
survey
owner
to
receive
the
right
responses
for
the
survey
requested
by
means
of
the
survey
name.
• Question
activity:
This
activity
generates
the
different
types
of
questions
requested
by
the
survey
owner
to
be
included
in
the
survey.
It
uses
the
createQuestion
method
to
invoke
methods
from
the
different
classes
that
contain
the
question
templates.
• Admin
activity:
Concerned
with
the
creation
of
questions
for
a
new
survey,
deleting
questions
and
responses
from
the
database
and
displaying
the
data
from
the
database.
• SurveyOwner
activity:
Takes
care
of
data
from
the
survey
and
responses
from
the
survey
participant.
• DatabaseHandler
activity:
Handles
the
connection
of
the
different
activities
to
the
database
with
the
HTTPpost
parameters
method
using
PHP,
JSON
(JavaScript
Object
Notation)
Parser
and
then
JavaScript
and
Ajax
for
the
web
end.
Fig
2
(Use-­‐Case
Diagram)

Fig
(2)
illustrates
how
the
user
communicates
with
the
application
and
can
be
further
divided
into:
Main
scenario,
and
Extension.
This
is
briefly
explained
in
the
use
case
text
depicted
in
the
figure
below.
Mid-­‐Level
Requirements
As
a
survey
owner
TEST
PLAN
Our
test
plan
was
subject
to
the
each
task
set
within
each
iteration.
The
points
listed
below
form
the
core
of
our
test
plan
across
the
different
iterations
• Testing
was
done
across
the
Eclipse
and
Android
software
development
kit
(SDK)
platforms
on
different
Android
Virtual
Devices
(AVD’s)
• Unit
testing
was
done
after
implementation
of
every
functionality
• Database
connectivity
functionality
was
tested
within
local
environments
as
well
as
on
distant
live
server
• Final
integration
testing
was
done
to
ensure
the
application
runs
properly
on
a
real
mobile
device
Meeting
Minutes
• We
held
general
meetings
with
the
product
owners
twice
every
week
• Every
meeting
began
with
a
status
update
where
each
member
of
the
team
explained
what
he
or
she
had
been
working
on
since
the
previous
status
update.
We
were
also
expected
to
indicate
if
we
had
caused
or
experienced
any
blockers
during
these
status
updates.
• We
held
side
meetings
between
team
members
(without
the
product
owners)
at
least
once
every
week.
This
provided
us
with
opportunities
to
resolve
pending
issues
that
were
unattended
Use
Case
Level:
Sea
Level
Main
Scenario:
1. Survey
participant
launches
the
Application
2. System
Initializes
survey
and
welcomes
the
user
3. Survey
participant
begins
the
survey
4. Survey
participant
answers
survey
questions
5. Survey
participant
ends
the
survey
6. System
saves
responses
in
the
database
7. System
Initializes
the
survey
questions
Extensions:
4a:
Survey
participant
navigates
backwards
and
forward
.1:
Survey
participant
returns
to
change
a
previous
response
.2:
System
saves
responses
made
by
the
user
4b:
Survey
participant
returns
to
complete
a
partially
filled
survey
6a:
Survey
participant
receives
feedback
message
that
responses
have
been
received

• Team
members
were
also
expected
to
relay
any
challenge
or
difficulties
experienced
as
well
as
proposed
difficulties
and
this
helped
to
structure
our
project
development
for
futuristic
additions
and
modifications
Back
and
Frond
End
Design
code
and
Graphical
User
Interface
Fig
3:
.java
and
.XML
codes
from
back
end
used
on
Android
for
designing
the
mobile
GUI

Fig
4:
.java
and
PHP
scripts
used
to
send
and
receive
data
between
mobile
device
and
remote
Database
Fig5:
Front
end
webpage
design
where
surveys
are
created
by
the
survey
owner

Fig
6:
A
template
for
creating
a
7
likert
scale
question

REFERENCES
Beck,
K.
&
Andres,
C.
2004.
Extreme
Programming
Explained
2nd
ed.,
Addison
Wesley.
Schwaber,
K.
&
Beedle,
M.
2001.
Agile
Software
Development
with
Scrum
,
Upper
Saddle
River,
NJ,
USA:
Prentice
Hall.
Schwaber,
K.
2004.
Agile
Project
Management
With
Scrum
,
Redmond,
WA,
USA:
Microsoft
Press.