Final Release

Online Art Gallery | Cube Art Studios ©

Online
Art
Gallery
|
Cube
Art
Studios
©

CW2
Report
-‐
Final
Release

Version:
1.0

24th

April
2015

Darren
Martin
Leith

Final Release Document Page ii
Table
of
Contents

1.
Introduction
...................................................................................................................................
4

1.1
Purpose
...................................................................................................................................................
4

1.2
Definitions,
Acronyms,
and
Abbreviations
........................................................................................
4

1.3
References
..............................................................................................................................................
4

2.
Testing
.............................................................................................................................................
5

2.1
Developers
Choice
.................................................................................................................................
5

2.1.1
Codeception
–
a
brief
overview
................................................................................................................
5

2.2
Tests
.........................................................................................................................................................
8

2.2.1
Test#1
.................................................................................................................................................................
8

2.2.2
Test#2
...............................................................................................................................................................
11

2.2.3
Test#3
...............................................................................................................................................................
13

2.2.4
Test#4
...............................................................................................................................................................
14

2.2.5
Test#5
...............................................................................................................................................................
15

2.2.6
Test#6
...............................................................................................................................................................
17

2.2.7
Test#7
...............................................................................................................................................................
18

2.2.8
Test#8
...............................................................................................................................................................
22

2.2.9
Test#9
...............................................................................................................................................................
25

2.2.10
Test#10
..........................................................................................................................................................
27

2.2.11
Test#11
..........................................................................................................................................................
30

2.2.12
Test#12
..........................................................................................................................................................
32

2.2.13
Test#13
..........................................................................................................................................................
35

2.2.14
Test#14
..........................................................................................................................................................
38

2.2.15
Test#15
..........................................................................................................................................................
40

2.2.16
Test#16
..........................................................................................................................................................
43

2.2.17
Test#17
..........................................................................................................................................................
45

2.2.18
Test#18
..........................................................................................................................................................
47

2.2.19
Test#19
..........................................................................................................................................................
50

2.2.20
Test#20
..........................................................................................................................................................
52

2.2.21
Test#21
..........................................................................................................................................................
54

2.2.22
Test#22
..........................................................................................................................................................
57

2.2.23
Test#23
..........................................................................................................................................................
60

2.2.24
Test#24
..........................................................................................................................................................
62

2.2.25
Test#25
..........................................................................................................................................................
64

3.
Bugzilla
..........................................................................................................................................
66

3.1
Anatomy
of
a
bug
...............................................................................................................................
66

3.2
A
Bug’s
Life
...........................................................................................................................................
68

3.3
Searching
for
Bugs
..............................................................................................................................
69

3.4
Reporting
Bugs
....................................................................................................................................
72

4.
MVC
...............................................................................................................................................
75

4.1
Laravel
and
MVC
.................................................................................................................................
76

5.
Version
Control
System
..............................................................................................................
83

5.1
Git
–
a
brief
introduction
...................................................................................................................
83

5.1.1
Git
–
Key
Features
........................................................................................................................................
83

5.2
VCS
in
action
........................................................................................................................................
86

5.2.1
Selecting
the
Branch,
File
and
History
..................................................................................................
86

5.2.2
Viewing
the
differences
.............................................................................................................................
88

Final Release Document Page iii
6.
Post
Mortem
Analysis
.................................................................................................................
92

6.1
Achievements
......................................................................................................................................
92

6.2
Challenges,
Lessons
Learned
and
Recommendations
..................................................................
93

6.3
Planning
for
Future
Improvements
.................................................................................................
95

7.
Video
Analysis
..............................................................................................................................
98

A.
Appendices
...................................................................................................................................
99

A.1
Appendix
1:
Definitions,
Acronyms,
and
Abbreviations
..............................................................
99

A.2
Appendix
2:
References
..................................................................................................................
100

A.3
Appendix
3:
List
of
Functional
Tests
..............................................................................................
101

Final Release Document Page 4
1.
Introduction

This
Final
Release
Document
(henceforth
referred
to
as
FRD)
contains
an
overview
of
the
final

release
of
the
Online
Art
Gallery
|
Cube
Art
Studios
©
website
(henceforth
known
as
the

product).
This
document
should
be
read
in
conjunction
with
the
Detailed
System
Specification

(DSS)
as
referenced
in
Appendix
2.

1.1
Purpose

The
purpose
of
this
document
is
to
provide
an
overview
of
the
final
release
of
the
system.
It

shall
be
divided,
broadly
speaking,
into
4
main
topics:

1. Testing,
including:

• Information
Management
System
(IMS)
Testing.

• Content
Management
System
(CMS)
Testing.

• Bugzilla
Testing.

2. MVC,
including:

• Product
use
of
the
MVC
pattern.

3. Concurrent
Versioning
System,
including:

• Product
use
of
a
CVS.

4. Post
Mortem
Analysis,
including:

• Lessons
Learnt

• Planned
improvements.

1.2
Definitions,
Acronyms,
and
Abbreviations

Please
reference
Appendix
1
for
a
full
list
of
definition,
acronyms,
and
abbreviations
pertaining

to
this
FRD.

1.3
References

Please
reference
Appendix
2
for
a
full
list
of
references
pertaining
to
this
FRD.

2.
Testing

Testing
for
this
product
is
only
focused
on
the
IMS
and
CMS
modules.
Testing
is
divided
into

four
‘categories’,
as
defined
below:

1. Unit
Testing
–
isolated
testing
of
classes
and
methods.
Only
the
class
is
tested.
The

database
and/or
relevant
dependencies
are
not
tested.

2. Functional
(Controller)
Testing
–
for
this
product,
functional
testing
is
defined
as
the

process
of
testing
controllers
(technically
a
form
of
functional
testing).
More

traditionally,
while
unit
tests
verify
each
unit
of
a
class,
functional
testing
is
broader
in

scope
and
can
trigger
many
aspects
of
an
application.
These
tests
do
not
require
a

server
to
be
running.

3. Integration
Testing
–
similar
principle
to
acceptance
tests
(see
below),
but
are
not
run

on
a
server
–
hence,
these
tests
are
much
faster.
These
tests
flex
multiple
aspects
of
the

application,
and
require
a
test
database.

4. Acceptance
Testing
–
tests
the
product
from
the
outside
in,
and
run
in
an
environment

that
is
as
close
to
production
as
possible.
These
tests
will
hit
the
database,
query
real

web
services,
etc.

Testing
for
this
product
is
performed
against
a
list
(see
Appendix
3,
Table
30)
of
generalized

functional
requirements
as
defined
by
the
client.
For
each
requirement,
the
test(s)
will
confirm

whether
the
product
passes
the
relevant
acceptance
criteria
and/or
any
other
challenging
test

deemed
relevant
for
that
requirement.

2.1
Developers
Choice

This
development
team
used
the
following
testing
tools:

1. PHPUnit,
version
4.6
(PHPUnit,
2015).

2. Codeception,
version
2.0
(Codeception,
2015).

2.1.1
Codeception
–
a
brief
overview

Codeception
is
a
PHP
full-‐stack
testing
framework,
inspired
by
Behaviour
Driven
Development

(BDD).
It
provides
a
methodology
for
writing
acceptance,
functional
and
unit
tests.
Below
are

some
of
the
features
of
Codeception:

! Powered
by
PHPUnit
version
4.0.20.
Codeception
simply
extends
PHPUnit
to
include
its

own
BDD
architecture.

! Multiple
backends,
e.g.
Selenium,
PhpBrowser,
ZombieJS

! Elements
matched
by
name,
CSS,
XPath.

! Data
Cleanup
after
each
run.

! Integration
with
multiple
frameworks,
e.g.
Laravel,
Symfony2,
Zend
Framework,
etc.

! WebServices
testing
via
REST,SOAP,XML-‐RPC.

! Generates
HTML,
XML,
TAP,
JSON,
CodeCoverage
reports.

For
this
product
we
have
performed
all
functional
acceptance
tests
using
Codeception.
Figure

1,
for
example,
shows
a
code
snippet
for
how
we
would
use
Codeception
to
write
a
functional

acceptance
test
for
“logging
into
the
IMS
module”
of
this
product.
Note
how
this
code
requires

almost
no
explanation
due
to
its
behaviour
driven
syntax
correlating
almost
exactly
with
how

we
would
speak
the
required
action.

Figure
1:
Codeception
sample
code
for
“logging
into
the
IMS
module”

Running
the
test
code
shown
in
Figure
1
using
the
“debug”
feature
of
Codeception
allows
us
to

see
the
inner
working
of
the
test,
which
is
shown
in
Figure
2.
For
all
of
the
tests
detailed
in

section
2.2
of
this
FRD
the
output
is
displayed
using
the
shortened
“steps”
feature
of

Codeception,
which
lists
the
steps
of
the
test
and
whether
they
pass/fail.

Figure
2:
test
output
for
“logging
into
the
IMS
module”
using
debug
feature.

The
test
output
shown
in
Figure
2
equates
exactly
to
how
a
developer
or
tester
would
manually

perform
the
following
functions
(see
Figure
3
below):

! open
a
browser

! navigate
to
http://localhost:8888/admin

! enter
a
valid
username
and
password

! be
directed
to
http://localhost:8888/sessions
and
be
authenticated

! be
redirected
to
http://localhost:8888/ims/dashboard

! seeing
“welcome
back”
and
“logged
in”
messages.

Figure
3:
Codeception
circumvents
the
need
to
manually
perform
routine
acceptance
tests

from
within
the
browser.

2.2
Tests

Each
test
as
referenced
in
Appendix
3
is
detailed
in
this
section
of
the
FRD.

2.2.1
Test#1

Test#
User
Story
Id
User
Story
Tests

1
87311922
As
an
administrator
when
logging
into
the
IMS
I

should
be
shown
helpful
validation
messages
if
I

enter
in
the
wrong
password
or
if
the
username

is
left
out.

1. Login
with
incorrect
password.
See
validation
messages.

2. Login
without
filling
in
username/password.
Expect
to
see
validation

messages.

3. Login
with
correct
username,
leave
password
field
blank.
Expect
to

see
validation
messages.

4. Login
with
correct
password,
leave
username
field
blank.
Expect
to

see
validation
messages.

Table
1:
test#1
summary

Figure
4:
testing
code
for
“login
to
IMS
with
wrong
password”

Figure
5:
output
for
“login
to
IMS
with
wrong
password”


Figure
6:
testing
code
for
“login
with
blank
fields
for
username/password”

Figure
7:
output
for
“login
with
blank
fields
for
username/password”

Figure
8:
testing
code
for
“login
with
incorrect
username”


Figure
9:
output
for
“login
with
incorrect
username”

Figure
10:
testing
code
for
“login
without
filling
in
password
field”

Figure
11:
output
for
“login
without
filling
in
password
field”

2.2.2
Test#2

Test#
User
Story
Id
User
Story
Tests

2
87312366
As
an
administrator
I
am
presented
with
a
dashboard

for
the
IMS
system.
I
should
be
able
to
navigate
to

INVENTORY,
ARTISTS,
CUSTOMERS,
ORDERS,
STAFF,

EVENTS,
ART
GALLERY,
CAROUSEL,
REPORTS.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Try
to
input
ims
dashboard
url

(localhost:8000/ims/dashboard)
directly
into

browser
and
confirm
redirected
to
/admin
login

page.

Table
2:
test#2
summary

Figure
12:
testing
code
for
“see
navigational
links
on
IMS
Dashboard”


Figure
13:
output
for
“see
navigational
links
on
IMS
Dashboard”

2.2.3
Test#3

Test#
User
Story
Id
User
Story
Tests

3
88640736
As
an
administrator,
I
want
to
see
a
"you
are
logged

out"
message
when
I
log
out
of
the
IMS
portal.
A
pop

up
would
be
nice

1. Perform
functional
acceptance
test
based
on
user

story.

Table
3:
test#3
summary

Figure
14:
testing
code
for
“logout
of
IMS”

Figure
15:
test
output
for
“logout
of
IMS”

2.2.4
Test#4

Test#
User
Story
Id
User
Story
Tests

4
88640330
As
an
administrator,
I
want
to
see
a
welcome
pop
up

notice
when
I
log
into
the
IMS
portal.

1. Perform
functional
acceptance
test
based
on
user

story.
The
welcome
notice
equates
to
“Welcome

Back!”
and
“You
are
now
logged
in”.

Table
4:
test#4
summary

Figure
16:
testing
code
for
“log
into
IMS
and
see
a
welcome
message”

Figure
17:
output
for
“log
into
IMS
and
see
a
welcome
message”

2.2.5
Test#5

Test#
User
Story
Id
User
Story
Tests

5
87310436
As
an
administrator
I
should
be
presented
with
a
log

in
page
in
order
to
access
the
Information

Management
System.
The
log
in
page
should
be

accessible
from
something
like

http://www.yoursitename/admin

1. Perform
functional
acceptance
test
based
on
user

story.

2. Attempt
to
access
“ims/dashboard”
without

authentication.
Expect
to
be
redirected
back
to
login

page.

3. Attempt
to
access
“ims/arts”
without
authentication.

Expect
to
be
redirected
back
to
login
page.

4. Attempt
to
access
“ms/artists”
without
authentication.

Expect
to
be
redirected
back
to
login
page.

5. Attempt
to
access
“ims/orders”
without

authentication.
Expect
to
be
redirected
back
to
login

page.

6. Attempt
to
access
“ims/customers”
without

authentication.
Expect
to
be
redirected
back
to
login

page.

Table
5:
test#5
summary

Figure
18:
testing
code
for
“be
presented
with
an
IMS
login
screen”


Figure
19:
output
for
“be
presented
with
an
IMS
login
screen”

2.2.6
Test#6

Test#
User
Story
Id
User
Story
Tests

6
88767410
As
an
administrator,
I
would
like
to
see
my
username

on
the
IMS
dashboard.
I
would
like
to
see
it

positioned
on
the
right
hand
side,
similar
to

something
I
have
seen
on
wordpress,
etc.

1. Perform
functional
acceptance
test
based
on
user

story.

Table
6:
test#6
summary

Figure
20:
testing
code
for
“see
username
on
IMS
Dashboard”

Figure
21:
output
for
“see
username
on
IMS
Dashboard”

2.2.7
Test#7

Test#
User
Story
Id
User
Story
Tests

7
87318622
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
Artists
from
within
the
IMS.
For

CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
first
name,
surname,

address,
country,
about,
email,
social
site
URLs,
and

be
able
to
upload
a
picture
of
the
artist

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
without
any
fields
filled
in.
Expect
to
see

validation
messages.

3. Submit
form
with
incorrect
data
types.
Expect
to
see

validation
messages.

Table
7:
test#7
summary

Figure
22:
testing
code
for
“create
a
new
artist”


Figure
23:
test
output
for
“create
a
new
artist”


Figure
24:
testing
code
for
“create
a
new
artist
without
filling
in
any
form
details”

Figure
25:
test
output
for
“create
a
new
artist
without
filling
in
any
form
details”


Figure
26:
testing
code
for
“create
a
new
artist
using
incorrect
data
types”

Figure
27:
test
output
for
“create
a
new
artist
using
incorrect
data
types”

2.2.8
Test#8

Test#
User
Story
Id
User
Story
Tests

8
87318538
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
INVENTORY
from
within
the
IMS.
For

CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
artist
(via
drop
down

box),
title,
category,
price,
description,
subject,

medium
(dropdown),
and
be
able
to
upload
a

photograph
of
the
art
item.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
a
create
art
form
without
any
of
the
fields
filled

in.
Expect
to
see
field
validation
errors.

Table
8:
test#8
summary

Figure
28:
testing
code
for
“create
a
new
art
item”


Figure
29:
test
output
for
“create
a
new
art
item”


Figure
30:
testing
code
for
“create
a
new
art
item
without
filling
in
any
form
fields”

Figure
31:
test
output
for
“create
a
new
art
item”

2.2.9
Test#9

Test#
User
Story
Id
User
Story
Tests

9
89336840
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
Artists
from
within
the
IMS.
For

READ,
I
should
see
a
table
of
all
artists,
showing

details
related
to
name,
address,
country,
picture,

and
links
to
buttons
that
will
allow
me
to
view
the

artist
on
main
website,
edit
the
artist
in
IMS,
and

delete
the
artist
in
IMS.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
without
any
fields
filled
in.

3. Submit
form
with
incorrect
data
types

Table
9:
test#9
summary

Figure
32:
testing
code
for
“read
artists”


Figure
33:
test
output
for
“read
artists”

2.2.10
Test#10

Test#
User
Story
Id
User
Story
Tests

10
89336876
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
Artists
from
within
the
IMS.
For

UPDATE,
I
should
be
presented
with
a
form
and
be

able
to
edit
existing
fields
related
to
first
name,

surname,
address,
country,
about,
email,
social
site

URLs,
and
be
able
to
change
the
picture
of
the
artist.
I

should
also
be
able
to
see
all
art
items
related
to
the

artist

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
the
edited
form
with
incorrect
data
types.

Table
10:
test#10
summary

Figure
34:
testing
code
for
“edit
artists”


Figure
35:
test
output
for
“edit
artists”


Figure
36:
testing
code
for
“edit
artist
with
incorrect
data
types”

Figure
37:
test
output
for
“edit
artist
with
incorrect
data
types”

2.2.11
Test#11

Test#
User
Story
Id
User
Story
Tests

11
89336902
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
INVENTORY
from
within
the
IMS.
For

READ,
I
should
see
a
table
of
all
art
items,
showing

details
related
to
art
id,
title,
category,
price,
subject,

medium,
artist
(hyperlink
to
edit
artist),
picture,
date

added
and
links
to
buttons
that
will
allow
me
to
edit

the
art
item
in
IMS,
and
delete
the
art
item
in
IMS.

1. Perform
functional
acceptance
test
based
on
user

story.

Table
11:
test#11
summary

Figure
38:
testing
code
for
“read
inventory”


Figure
39:
test
output
for
“read
inventory”

2.2.12
Test#12

Test#
User
Story
Id
User
Story
Tests

12
89336910
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
INVENTORY
from
within
the
IMS.
For

UPDATE,
I
should
be
presented
with
a
form
and
be

able
to
edit
existing
fields
related
to
artist
(be
able
to

change
the
artist
if
required
via
dropdown),
title,

category,
price,
subject,
medium
and
be
able
to

change
the
picture
of
the
art
item.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
the
edited
form
with
incorrect
data
types.

Expect
field
validation
errors.

Table
12:
test#12
summary

Figure
40:
testing
code
for
“edit
art
item”


Figure
41:
test
output
for
“edit
art
item”

Figure
42:
testing
code
for
“edit
art
item
with
incorrect
data
types”

Figure
43:
test
output
for
“edit
art
item
with
incorrect
data
types”

2.2.13
Test#13

Test#
User
Story
Id
User
Story
Tests

13
87318726
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
STAFF
from
within
the
IMS.
For

UPDATE,
I
should
be
presented
with
a
form
and
be

able
to
edit
existing
fields
related
to
the
staff

member.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
the
edited
form
with
incorrect
data
types.

Expect
field
validation
errors.

Table
13:
test#13
summary

Figure
44:
testing
code
for
“edit
a
staff
member”


Figure
45:
test
output
for
“edit
a
staff
member”


Figure
46:
testing
code
for
“edit
a
staff
member
with
incorrect
data
types”

Figure
47:
test
output
for
“edit
a
staff
member
with
incorrect
data
types”

2.2.14
Test#14

Test#
User
Story
Id
User
Story
Tests

14
89340604
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
STAFF
from
within
the
IMS.
For

READ,
I
should
see
a
table
of
all
staff,
showing
details

related
employee
number,
name,
address,
country,

date
added,
picture,
and
links
to
buttons
that
will

allow
me
to
edit/delete
the
staff
member
in
IMS

1. Perform
functional
acceptance
test
based
on
user

story.

Table
14:
test#14
summary

Figure
48:
testing
code
for
“read
all
staff
members”


Figure
49:
test
output
for
“read
all
staff
members”

2.2.15
Test#15

Test#
User
Story
Id
User
Story
Tests

15
89340656
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
STAFF
from
within
the
IMS.
For

CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
name,
address,
country,

email,
and
be
able
to
upload
a
photograph
of
the
staff

member

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
without
any
fields
filled
in.
Expect

validation
errors.

Table
15:
test#15
summary

Figure
50:
testing
code
for
“create
a
new
staff
member”


Figure
51:
test
output
for
“create
a
new
staff
member”

Figure
52:
testing
code
for
“create
a
new
staff
member
without
filling
in
any
form
fields”

Figure
53:
test
output
for
“create
a
new
staff
member
without
filling
in
any
form
fields”

2.2.16
Test#16

Test#
User
Story
Id
User
Story
Tests

16
87318644
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
EVENTS
from
within
the
IMS.
For

READ,
I
should
see
a
table
of
all
events,
showing

details
related
to
TITLE,
DATE
OF
EVENT,

DESCRIPTION,
PICTURE
and
links
to
buttons
that
will

allow
me
to
edit/delete
the
event
in
IMS

1. Perform
functional
acceptance
test
based
on
user

story.

Table
16:
test#16
summary

Figure
54:
testing
code
for
“read
events”


Figure
55:
test
output
for
“read
events”

2.2.17
Test#17

Test#
User
Story
Id
User
Story
Tests

17
90177490
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
EVENTS
from
within
the
IMS.
For

UPDATE,
I
should
be
presented
with
a
form
and
be

able
to
edit
existing
fields
related
to
the
event,

including
changing
the
date
and
time.

1. Perform
functional
acceptance
test
based
on
user

story.

Table
17:
test#17
summary

Figure
56:
testing
code
for
“edit
an
event”


Figure
57:
test
output
for
“edit
an
event”

2.2.18
Test#18

Test#
User
Story
Id
User
Story
Tests

18
90177958
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
EVENTS
from
within
the
IMS.
For

CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
TITLE,
DATE/TIME
OF

EVENT,
DESCRIPTION,
and
be
able
to
upload
a

photograph
of
the
event

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
with
incorrect
data
types.
Expect
to
see

validation
errors.

Table
18:
test#18
summary

Figure
58:
testing
code
for
“create
an
event”


Figure
59:
test
output
for
“create
an
event”

Figure
60:
testing
code
for
“creating
an
event
with
incorrect
data
types”


Figure
61:
test
output
for
“creating
an
event
with
incorrect
data
types”

2.2.19
Test#19

Test#
User
Story
Id
User
Story
Tests

19
87318672
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
CUSTOMERS
from
within
the
IMS.

For
READ,
I
should
see
a
table
of
customers,
showing

details
related
to
NAME,
ADDRESS,
COUNTRY,
EMAIL

and
links
to
buttons
that
will
allow
me
to
edit/delete

the
customer
in
IMS.

1. Perform
functional
acceptance
test
based
on
user

story.

Table
19:
test#19
summary

Figure
62:
testing
code
for
“read
customers”


Figure
63:
test
output
for
“read
customers”

2.2.20
Test#20

Test#
User
Story
Id
User
Story
Tests

20
90178228
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
CUSTOMERS
from
within
the
IMS.

For
UPDATE,
I
should
be
presented
with
a
form
and

be
able
to
edit
existing
fields
related
to
the
customer.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
without
any
fields
filled
in.

3. Submit
form
with
incorrect
data
types

Table
20:
test#20
summary

Figure
64:
testing
code
for
“editing
a
customer”

Figure
65:
test
output
for
“editing
a
customer”

2.2.21
Test#21

Test#
User
Story
Id
User
Story
Tests

21
90177828
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
CUSTOMERS
from
within
the
IMS.

For
CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
name,
address,
country,

email.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
without
any
fields
filled
in.

Table
21:
test#21
summary

Figure
66:
testing
code
for
“creating
a
customer”


Figure
67:
test
output
for
“creating
a
customer”


Figure
68:
testing
code
for
“creating
a
customer
without
filling
out
form”

Figure
69:
test
output
for
“creating
a
customer
without
filling
out
form”

2.2.22
Test#22

Test#
User
Story
Id
User
Story
Tests

22
87318700
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
ORDERS
from
within
the
IMS.
For

CREATE,
I
should
be
presented
with
a
form
and
be

able
to
enter
fields
related
to
selected
art
item

(maybe
drop
down?),
customer
name
(drop
down).

This
should
be
discussed
further
in
SCRUM
MEETING

but
functional
prototype
required
to
begin
with.

1. Perform
functional
acceptance
test
based
on
user

story.

2. Submit
form
with
incorrect
data
types.
Expect
field

validation
errors.

Table
22:
test#22
summary

Figure
70:
testing
code
for
“creating
an
order”


Figure
71:
test
output
for
“creating
an
order”

Figure
72:
testing
code
for
“creating
an
order
with
incorrect
data
types”

Figure
73:
test
output
for
“creating
an
order
with
incorrect
data
types”

2.2.23
Test#23

Test#
User
Story
Id
User
Story
Tests

23
90180950
As
an
administrator
I
must
be
able
to
perform
CRUD

functionality
for
ORDERS
from
within
the
IMS.
For

READ,
I
should
be
presented
with
a
table
showing
a

list
of
orders
by
order
number.
Table
should
detail

customer,
date
of
purchase
and
button
links
to

details/delete

1. Perform
functional
acceptance
test
based
on
user

story.

Table
23:
test#23
summary

Figure
74:
testing
code
for
“read
orders”


Figure
75:
test
output
for
“read
orders”

2.2.24
Test#24

Test#
User
Story
Id
User
Story
Tests

24
87319662
As
an
administrator
I
can
pick
and
choose
what
12
art

items

I
want
to
display
on
the
home
page
of
the

website
-‐
from
within
the
CMS.
This
will
serve
as
an

art-‐gallery
on
the
main
page.
I
should
be
able
to

search
through
all
art
items
in
database
and
pick
and

choose
any
12
art
items

1. Perform
functional
acceptance
test
based
on
user

story.

Table
24:
test#24
summary

Figure
76:
testing
code
for
“read
orders”
–
snippet.


Figure
77:
test
output
for
“read
orders”

2.2.25
Test#25

Test#
User
Story
Id
User
Story
Tests

25
90181752
As
an
administrator,
I
would
like
to
be
able
to
change

the
3
slider
carousel
photographs
that
appear
on
the

home
page.
This
should
be
managed
via
the
CMS.
As

discussed
in
the
SCRUM
MEETINGS,
this
would
be
a

nice
optional
extra
if
time
permits

1. Perform
functional
acceptance
test
based
on
user

story.

Table
25:
test#25
summary

Figure
78:
testing
code
for
“changing
carousel
images”


Figure
79:
test
output
for
“changing
carousel
images”

3.
Bugzilla

In
this
section
of
the
FRD,
we
will
make
use
of
Bugzilla(ref.
Bugzilla
2015)
to
keep
track
of
all

bugs
related
to
the
IMS
module
(see
Figure
80).

Figure
80:
snapshot
list
of
bugs
related
to
the
IMS

3.1
Anatomy
of
a
bug

A
bug
is
classified
primarily
by
Product
and
Component,
with
any
given
product
being

subdivided
into
a
number
of
components.
For
this
project
the
Product
is,
naturally
enough,
the

product
i.e.
the
CubeArt
online
art
gallery,
and
the
component(s)
consist
of
the
three

fundamental
modules,
i.e.:

a) Module
1:
Main
website

b) Module
2:
Information
Management
System.

c) Module
3:
Content
Management
System.

Figure
81
provides
a
summary
overview
of
a
typical
bug
found
in
the
IMS
component.

Figure
81:
“Bug
13:
welcome
back
pop
up
not
showing
when
logging
in”.
This
bug
was

completed
in
1
hour,
QA/QC
then
verified
it
as
fixed,
and
now
it
can
be
classified
as
closed.

Some
of
the
key
components
that
define
this
bug
include:

1. Status:
defines
the
status
of
the
bug
e.g.
unconfirmed,
confirmed,
resolved,
verified,

etc.
These
can
be
customized
and
redefined
for
each
individual
product.

2. Assigned
To:
the
person
responsible
for
fixing
the
bug.
For
this
product
we
have
three

responsible
person(s):
Vinod,
Joey,
and
Doug.

3. URL:
a
URL
associated
with
the
bug,
if
any.

4. Summary:
a
brief
summary
of
the
bug
–
short
and
succint
is
best.

5. Tags:
these
are
keywords
used
to
categorise
bugs
-‐
e.g.
ims,
mainpage,
login,
etc.

6. Hardware:

indicates
the
platform
and
operation
system
where
the
bug
was
identified.

7. Version:
defines
the
component
version
that
the
bug
report
is
about.
For
this
product
all

bugs
are
identified
on
the
Git
master
branch.

8. Importance:
used
to
prioritise
the
bug
e.g.
lowest,
normal,
highest,
etc.

9. Reported:
the
person
who
filed
the
bug.

10. Dependencies:
if
the
bug
cannot
be
fixed
unless
other
bugs
are
fixed
or
the
bug
stops

other
bugs
being
fixed
their
id’s
are
recorded
here.

3.2
A
Bug’s
Life

Figure
82
shows
a
summary
overview
of
the
lifecycle
of
a
bug.

Bug
13
detailed
in
figure
81

originally
started
as
an
unconfirmed
bug.
It
was
then
resolved
as
“fixed”
by
developer
Vinod

Ramon,
QA/QC
verified
as
fixed,
and
finally
closed.

Figure
82:
Lifecycle
of
a
bug1

1
Figure 82 is a reproduction of “Bugzilla 3.0 Bug Life Cycle” available at BugzillaWiki (2015)

Figure
83
illustrates
the
email
notifications
that
took
place
during
the
life
cycle
of
the
bug

detailed
in
figure
82.

Figure
83:
email
notifications
for
Bug
13.

3.3
Searching
for
Bugs

Figure
84
shows
one
example
of
how
we
can
use
the
search
functionality
of
Bugzilla
to
search

for
bugs
that
have
not
yet
been
completed.
Figure
85
then
shows
a
more
detailed
view
for
each

of
the
five
bugs
shown
in
Figure
84.
Bugzilla
refers
to
this
detailed
view
as
the
long
format.


Figure
84:
Searching
for
bugs.
The
search
returns
five
bugs
that
have
yet
to
be
fixed
for
the
IMS

module.
Note
that
the
bug
of
ID
#30
has
been
highlighted
in
red.
The
red
signifies
that
this
bug

is
of
the
highest
importance
and
is
classified
as
a
“blocker”
i.e.
it
is
blocking
further

development
and/or
testing
work.

.

Figure
85:
Long
format
view
of
bugs
identified
in
figure
84.

Figure
86
shows
another
example
of
how
we
can
use
advanced
search
functionality
in
Bugzilla

to
search
for
bugs
in
the
IMS
module
that
have
been
verified
between
a
certain
time-‐frame.

Figure
86:
advanced
search
functionality
using
time-‐frame(s)

Figure
87:
fixed
and
QA/QC
IMS
approved
bugs
between
the
17th

-‐
18th

April.

3.4
Reporting
Bugs

Figure
88
provides
an
overview
of
how
we
can
use
the
reports
functionality
of
Bugzilla
to

graphically
chart
bugs.
It
also
illustrates
the
use
of
bar,
pie,
and
summary
table
charts
to
show

the
status
of
all
of
the
bugs
found
in
the
IMS
module.


Figure
88:
Bar,
Pie,
and
Table
Charts
showing
the
status
of
all
bugs
in
the
IMS.

Figure
89
provides
another
example
of
graphically
charting
bugs.
Here
we
make
use
of
a
bar

chart
to
show
the
severity
quantity
of
all
of
open
bugs
found
in
the
IMS
module.

Figure
89:
Bar
Chart
showing
the
severity
of
all
open
bugs
in
the
IMS.

4.
MVC

The
framework
used
for
this
project
is
Laravel
(ref.
Laravel
2015)
which
is
a
full-‐stack

framework
designed
for
the
development
of
model-‐view-‐controller
(MVC)
web
applications.

Laravel
imposes
rigid
constraints
on
how
to
structure
web
applications,
with
a
strong

preference
for
“convention
over
configuration”.
Whereas
some
Java,
Python
or
PHP

frameworks
often
require
lots
of
XML
configuration,
Laravel
requires
almost
none
(or
perhaps

only
a
few
lines
of
PHP)
to
get
started.
This
aversion
to
configuration
files
makes
for
a
very

distinctive
and
recognizable
code
structure
that
is
the
same
across
all
Laravel
apps
(see
Figure

90).
As
such,
all
Laravel
projects
have
essentially
the
same
directory
structure
in
which
every

file
has
its
designated
place.
By
enforcing
this
directory
structure,
Laravel
ensures
that
all

projects
are
automatically
organized
the
“Laravel
way”.

Figure
90:
Laravel
directory
structure
for
product.

4.1
Laravel
and
MVC

There
are
three
components
to
the
MVC
architectural
pattern:

• “The
Model”
–
which
represents
the
domain
around
which
the
software
is
built.
Models

are
based
on
tangible
items
such
as
a
Person,
Bank
Account,
or
a
Product.
For
this

particular
product
models
include
e.g.
an
Artist,
Customer,
Gallery
Item,
Order
(see

Figure
91),
etc.
Models
are
typically
permanent
and
will
be
stored
outside
the

application,
often
in
a
database.
A
model
is
more
than
just
data;
it
enforces
all
the

business
rules
that
apply
to
that
data.
For
example,
if
a
discount
should
be
applied
to

orders
greater
than
a
certain
amount,
the
model
will
enforce
the
constraint.
By
placing

the
implementation
of
these
business
rules
in
the
model,
we
ensure
that
nothing
else
in

the
application
can
make
our
data
invalid.
The
model
acts
as
both
a
gatekeeper
and
a

data
store.
In
Laravel,
all
models
are
located
in
the
app/models
subdirectory.

Figure
91:
Order
Model.


Figure
92:
Art
Model.

• “The
View”
–
which
represents
the
visual
representation
of
a
model.
It’s
usually
the

resulting
mark-‐up
that
the
framework
renders
to
the
browser,
such
as
the
HTML

representing
an
art
item,
or
an
artist,
for
example
(see
Figure
93).
The
view
layer
is

responsible
for
generating
a
user
interface,
normally
based
on
data
in
the
model.
For

this
particular
product,
for
example,
a
list
of
art
gallery
art
items
will
be
displayed
on
the

home
page.
This
list
will
be
accessible
via
a
Gallery
model,
but
it
will
be
the
“home
view”

that
accesses
the
list
from
the
model
and
formats
it
for
the
end
user.
Although
the
view

may
present
the
user
with
various
ways
of
inputting
data,
the
view
itself
never
handles

incoming
data.
The
view’s
work
is
done
once
the
data
is
displayed.
All
views
are
located

in
the
app/views
subdirectory.

Figure
93:

the
“ims/artists/edit”
View.


Figure
94:

a
snippet
of
the
“Photography”
detailed
View
page

• “The
Controller”
–
which
represents
the
coordinator
providing
the
link
between
the
view

and
the
model.
The
controller
is
responsible
for
processing
input,
acting
upon
the

model,
and
deciding
what
action
should
be
performed,
such
as
rendering
a
view
or

redirecting
to
another
page.
For
this
particular
product,
for
example,
the

“OrderController”
might
look
up
all
the
currently
registered
Orders
(from
the
model)

and
pass
them
to
the
“ims/orders/index”
view
for
rendering
in
the
IMS.
All
controllers

are
located
in
the
app/controllers
subdirectory.


Figure
95:

“OrderController”
snippet.
Rather
than
employ
a
strict

“fat
model,
skinny
controller”
design
pattern,
the
development
team
included
business

logicwithin
many
of
the
controllers,
e.g.
the
“create”
method
shown
above.


Figure
96:

“PagesController”
snippet.

We
can
best
illustrate
the
MVC
workflow
by
examining
Figure
97,
which
provides
an
overview

of
the
workings
of
a
typical
Laravel
application
using
MVC
components.

Figure
97:
MVC
in
action
-‐
an
overview

When
interacting
with
a
Laravel
application,
a
browser
sends
a
request,
which
is
received
by
a

web
server
and
passed
on
to
the
Laravel
routing
engine.
The
Laravel
router
receives
the

request
and
redirects
to
the
appropriate
controller
class
method
based
on
the
routing
URL

pattern.
The
controller
class
then
takes
over.
In
some
cases,
the
controller
will
immediately

render
a
view,
which
is
a
template
that
gets
converted
to
HTML
and
sent
back
to
the
browser.

More
commonly
for
dynamic
sites,
the
controller
interacts
with
a
model,
which
is
a
PHP
object

that
represents
an
element
of
the
application
(such
as
an
artist,
art
item,
etc.)
and
is
in
charge

of
communicating
with
the
database.
After
invoking
the
model,
the
controller
then
renders
the

final
view
(HTML,
CSS,
and
images)
and
returns
the
complete
web
page
to
the
user’s
browser.

Laravel
promotes
the
concept
that
models,
views,
and
controllers
should
be
kept
separate
by

storing
the
code
for
each
of
these
elements
as
separate
files,
in
separate
directories.

5.
Version
Control
System

The
following
Version
Control
Systems
(VCS)
were
used
in
the
development
of
this
project:

1. Git,
version
1.9.5
(Git,
2015).

2. GitHub,
private
repository
for
CubeArt
(GitHub,
2015).

3. PhpStorm
IDE,
version
8.0.3,
with
in-‐built
VCS
functionality
(JetBrains,
2015).

5.1
Git
–
a
brief
introduction

Git
is
a
VCS
tool
that
was
designed
by
Linus
Torvalds
in
2005
“with
a
bit
of
creative
destruction

and
fiery
controversy”
(Chacon
and
Straub,
2014:31).
It
was
developed
in
reaction
to
the

perceived
poor
performance
of
VCS
at
that
time.
Torvalds
wanted
to
develop
a
VCS
with

enhanced
speed,
simplicity
of
design,
strong
support
for
extensive
parallel
branches,
and
the

ability
to
efficiently
handle
large
projects.
Whilst
not
exhaustive,
below
is
a
list
of
some
of
the

key
features
of
Git
along
with
some
of
the
advantages
of
using
Git
over
existing
versioning

control
technologies.

5.1.1
Git
–
Key
Features

a) “Distributed
Snapshots,
not
files”

Git
perceives
and
stores
data
differently
to
other
VCS
such
as
Concurrent
Versioning
System

(CVS),
Subversion,
Perforce,
Bazaar,
et
al.
With
Git,
clients
do
not
simply
check
out
the
latest

version
of
a
given
file:
they
fully
mirror
the
entire
repository.
This
circumvents
“single
point
of

failure”
issues
if
a
server
dies,
since
any
of
the
client’s
repositories
can
be
copied
back
up
to
the

server
to
restore
it.
Every
clone
is
in
essence
a
full
backup
of
all
the
data
–
hence
the
term

distributed.
Likewise,
every
time
you
commit
or
save
the
state
of
a
project
in
Git,
a
snapshot
of

all
the
files
at
that
point
in
time
is
taken,
and
a
reference
to
that
snapshot
is
stored.

b) “Support
for
non-‐linear
branch
development”

Git
allows
and
encourages
the
use
of
multiple
local
branches
that
can
be
entirely
independent

of
each
other.
Git
includes
specific
tools
for
visualizing
and
navigating
a
non-‐linear

development
history,
and
the
creation,
deletion
and
merging
of
individual
branches
with
any

other
branches
in
Git
are
very
lightweight:
A
branch
in
Git
is
only
a
reference
to
a
single

commit,
see
Figure
98.


Figure
98:
List
of
6
branches,
as
viewed
on
the
product’s
private
GitHub
repository.

c)
“Integrity”

Git
performs
a
checksum
(via
a
SHA-‐1
hash
composed
of
a
40-‐character
hexadecimal
string)
on

any
committed
file
before
it
is
stored,
and
it
is
then
referred
to
by
that
checksum.
In
essence
it

is
impossible
to
change
any
aspect
of
a
file
or
directory
without
Git
knowing
about
it,
and
Git

detects
all
information
loss
or
file
corruption.

d) “Compatibility
with
existing
protocols,
and
IDE’s”

Repositories
are
usually
published
remotely
via
HTTPS,
but
can
also
be
published
via
HTTP,
FTP,

rsync,
SSH,
etc.
Git
also
has
a
CVS
server
emulation,
which
enables
the
use
of
existing
CVS

clients
and
IDE
plugins
to
access
Git
repositories.
In
developing
this
product
the
development

team
made
use
of
PhpStorm’s
excellent
VCS
plug-‐in
allowing
for
full
Git
command
line

integration
from
within
the
IDE
itself
(see
Figure
99).


Figure
99:
Git
checksum,
as
viewed
on
the
product’s
GitHub
repository.

e) “Local,
and
web”

Git
is
primarily
a
local
versioning
system
–
generally
speaking
no
information
is
needed
from
a

network.
The
entire
history
of
a
given
project
is
stored
on
the
clients
local
disk,
meaning
Git

does
not
need
to
go
out
to
any
particular
server
to
get
that
information.
All
work
can
be

performed
offline,
and
later
committed
to,
for
example,
GitHub
once
connected
to
a
network.

GitHub
is
a
web-‐based
Git
repository
hosting
service
offering
all
of
the
functionality
of
Git
along

with
a
graphical
interface,
desktop
and
mobile
integration
and
several
collaborative
tools
such

as
wikis,
task
management,
bug
tracking,
graphs,
etc.


Figure
100:
PhpStorm
and
Git
functionality.

5.2
VCS
in
action

In
this
section
we
will
illustrate
the
use
of
Git
by
retrieving
the
diverse
versions
of
a
file
at

various
stages
during
the
course
of
the
product
life
cycle.
The
file
that
will
be
chosen
will
be
the

homepage
of
the
main
website,
i.e.
app/views/home.blade.php.

5.2.1
Selecting
the
Branch,
File
and
History

Using
PhpStorm’s
Git
functionality
we
can
easily
select
the
relevant
branch,
file,
and
file

committal
history
(see
Figure
101).


Figure
101:
Retrieving
the
commit
history
of
a
file.

5.2.2
Viewing
the
differences

Viewing
the
differences
between
various
versions
of
any
given
file
is
also
easily
performed

using
PhpStorm’s
IDE
“compare”
function
(see
Figure
102,
103,
104
and
105).

Figure
102:
viewing
the
differences
between
two
versions
of
the
same

“app/views/home.blade.php”
file
using
PhpStorm/Git.

Figure
103:
viewing
the
differences
between
versions
of
file

using
PhpStorm/Git,
example
Two.

Figure
104:
viewing
the
differences
between
versions
of
file

using
the
product’s
online
GitHub
repository.


Figure
105:
viewing
the
differences
between
versions
of
file

using
the
terminal
and
the
‘git
diff’
command.

6.
Post
Mortem
Analysis

The
purpose
of
this
section
of
the
FRD
is
to
provide
an
analysis
and
reflection
of
the
overall

development
process,
detailing:

! Achievements
–
section
6.1

! Challenges,
Lessons
learned,
and
Recommendations
–
section
6.2

! Planning
for
future
improvements
–
section
6.3

The
knowledge
and
experience
shared
from
working
on
this
product
will
allow
future
projects

to
repeat
the
desirable,
and
avoid
the
more
undesirable
outcomes
detailed
below.

6.1
Achievements

Table
26
provides
a
summary
overview
of
some
of
the
key
achievements
during
the

implementation
of
this
product.

#
Achievement
Description
Factors
that
promoted
this
success

1
Out
of
a
total
count
of
68
user
stories,
63

were
completed
and
verified
as
successfully

completed
by
the
client,
representing
a
92.6%

success
rate
for
user
story
completion.

• A
robust
and
agile
development
framework.

• Innovative
project
management
software

development
tools.

• A
diligent
scrum
master.

• Staggered
shifts,
with
the
team
prepared
to
do

whatever
it
takes
to
succeed.

2
All
three
critical-‐path
deadlines
were

achieved
on
time
i.e.
Prototype
(16th

February

2015),
CW1
Beta-‐Launch
(13th

March
2015),

Full
Production
Launch
(24th

April
2015).

• An
agile
development
framework.

• Innovative
project
management
software
tools.

• A
diligent
scrum
master
and
development
team,

using
staggered
shifts
where
necessary.

• Excellent
communication
with
the
client
via
weekly

scrum
meetings,
and
online
user
story
creation

tools.

3
Scrum
Master
support
and
coordination

always
present.

• Presence
of
scrum
master
ensured
that
the
team

was
focused
and
could
channel
all

issues/concerns.

4
Committed,
active,
vocal
and
dedicated
cross-‐
functional
development
team.

• Aligned
with
the
development
framework,
the

team
were
given
a
lot
of
freedom.
The
team

became
self-‐organizing,
and
self-‐managing.

• Each
team
member
was
fully
vetted
for
relevant

experience
and
qualities
prior
to
being
accepted

onto
the
project.

5
Commitment
to
quality.
• The
development
team
did
not
hide
issues,
and

team
members
were
vocal
on
all
matters
related

to
quality.

• A
substantial
Testing
document
was
bundled
with

the
final
product.

#
Achievement
Description
Factors
that
promoted
this
success

6
Client
Satisfaction.
The
client
accepted,
and

signed-‐off
the
final
product.
The
client
also

expressed
an
interest
in
using
this

development
team
for
future
works.
The

primary
applications
for
this
product
were

realised:

(1)
a
modern
visually
appealing
website
that

enhances
the
experience
of
buying
art.

(2)
providing
a
core
management
tool
for

client
employees
to
run
the
day-‐to-‐day

operations
of
the
business.

• Extensive
requirements
gathering
via
user-‐stories

from
the
outset.
The
client
was
actively
engaged

in
this
process
throughout
the
entire
project.

• Team
members
with
the
right
mix
of
motivation,

ability,
and
attitude.

Table
26:
Achievements

6.2
Challenges,
Lessons
Learned
and
Recommendations

Table
27
provides
a
summary
overview
of
the
primary
challenges
faced
during
the

implementation
of
this
product,
along
with
lessons
learned
and
recommendations.

#
Challenge
Lesson
learned
and
recommendations

1
Delays
in
test
database
readiness
impacted

Full
Production
Launch
timeline.

The
development
team
underestimated
the

complexity
of
the
test
database
required
in
order
to

perform
valid
testing.
This
took
longer
to
create
than

allocated
in
the
original
schedule.
The
development

team
had
to
quickly
learn
new
skills
related
to

mocking
a
medium-‐to-‐large
sized
test
database
using

the
chosen
development
framework.

The
development
team
now
has
documentation
and

a
template
for
how
to
perform
this.

2
Delays
in
completing
acceptance
testing
due

to
partial
test
driven
development.

Not
all
team
members
employed
test-‐driven

development.
This
meant
that
only
approx.

50%
of
the
application
was
functionally
tested

with
only
2
weeks
to
Full
Production
Launch.

A
lot
of
man-‐hours
were
diverted
to
testing

activities
in
the
last
two
weeks
of
the
project

life
cycle,
which
were
not
forecast.

The
entire
team
needs
to
be
engaged
in
test
driven

development
from
the
outset,
if
that
is
the
chosen

testing
methodology.
Partial
testing
can
lead
to

certain
modules
being
overlooked.
For
this
product,

the
team
should
have
realized
that
there
would
be
a

shortfall
on
tested
modules
much
earlier
than
two

weeks
prior
to
the
final
deadline.
The
project
could

have
benefitted
from
better
scheduling
and
planning

with
regards
to
testing.

3
Incorrectly
assigned
points
to
user
stories.

The
development
team
fully
embraced
an

online
project
management
user-‐story

tracking
tool.
While
the
overall
experience
of

using
this
tool
was
rated
4.7/5
(i.e.
94%

It
took
approximately
3
weeks
for
a
baseline
to
be

established,
with
many
over
and
under
estimations

made
during
that
time
frame.

The
development
team
now
has
documentation
and

a
template
for
how
to
accurately
assign
points
to

#
Challenge
Lesson
learned
and
recommendations

approval
rating)
after
surveying
all
team

members,
there
were
challenges
in

implementing
it.
One
of
the
major
issues
was

defining
how
many
“points”
to
assign
to
a

user
story,
whereby
1
point
roughly
equated

to
1
day
of
development
time.

user
stories.

4
Team
members
did
not
unanimously
agree

upon
the
bug-‐tracking
tool
of
choice
i.e.

Bugzilla.

This
was
a
source
of
friction
between

development
team
members.
Setting
up
the

tracking
tool
on
each
developer’s
workstation

proved
to
be
laborious,
and
time-‐consuming.

The
team
estimated
an
average
of
3-‐4
days
to

configure
and
install
Bugzilla.
Once
installed,

the
latest
updates
to
Bugzilla
(which
were

rolled
out
approximately
a
month
prior
to

product
release)
were
not
installed
due
to

concerns
that
the
updates
may
break
existing

installations.

Approximately
half
the
team
members
would
have

preferred
to
use
the
bug
tracking
tool
that
came
out

of
the
box
with
the
online
project
management
user-‐
story
tracking
tool.
However,
as
Bugzilla
is
the
de-‐
facto
industry
standard,
the
scrum
master
required

the
team
to
use
it.
The
amount
of
time
required
to

install
and
configure
the
software
was
not
factored

into
the
budgeted
man-‐hours,
as
it
was
assumed
the

install
would
be
straightforward.

The
development
team
now
has
documentation
and

a
template
for
configuring
and
installing
Bugzilla
on

OS
X.
However,
it
should
be
noted
that
there
are

many
other
bug
tracking
tools
besides
Bugzilla
that

provide
a
comparable
if
not
better
level
of
quality,

are
open
source
and
free,
and
are
much
easier
to

configure/install.
This
should
be
a
serious

consideration
for
future
projects.

5
Problems
with
client
milestones
and
feature

changes.

The
development
team
had
serious
problems

in
completing
all
user
stories
due
to
ever

changing
targets.
The
client
was
submitting

new
user
stories
right
up
to
the
very
last
week

of
the
project,
forcing
the
development
team

to
cut
corners
in
order
to
make
the
final

delivery
milestone.

It
was
agreed
with
the
client
from
the
outset
that
the

agile
scrum
development
framework
would
allow
for,

and
embrace
changing
requirements.
However,
the

client
somewhat
abused
this
interpretation
of
the

contract,
or
at
least
the
terms
of
the
contract
were

not
properly
defined
to
the
client.
Project

management
have
learned
that
much
closer
working

relations
are
required
with
the
client
regarding

contracts.
Terms
and
conditions
must
be
explicit,
not

open
to
interpretation.
Project
management
must

learn
how
to
control
customer
changes
within
this

environment,
so
that
quality
is
not
compromised.

6
Underestimation
of
man-‐hours
to
complete

documentation.

While
all
documentation
was
fully
completed

for
the
final
release,
it
required
a
major
team

effort
in
order
to
get
it
over
the
finishing
line.

Testing
documentation
in
particular
proved
to

be
troublesome,
with
functional
acceptance

testing
requiring
much
more
documentation

than
anticipated.

As
mentioned
in
point
2,
the
project
could
have

benefitted
from
better
scheduling
and
planning
with

regards
to
testing.
Specification
documents
were

completed
on
schedule;
however
testing

documentation
required
an
injection
of
additional

man-‐hours.

Assuming
it
can
be
budgeted,
future
projects
would

greatly
benefit
from
a
stand-‐along
testing
team.
For

this
particular
product
the
budget
and
resources

were
unfortunately
not
available.

Table
27:
Challenges,
lessons
learned,
and
recommendations

Final Release

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (7)

Similar to Final Release

Similar to Final Release (20)

Recently uploaded

Recently uploaded (20)

Final Release