software development

The Computing & IT Project

Prepared by

Danail A Chtipliev

2016

Table of Contents

BUSINESS INTRODUCTION .............................................................................................. 4

PROJECT INTRODUCTION ............................................................................................... 4

1.1 Project Title ........................................................................................................................ 4

1.2 Problem Statement ............................................................................................................. 4

1.3 System Goals & Objectives ................................................................................................ 4

1.4 Project Goals & Objectives ................................................................................................. 4

1.5 System Scope .................................................................................................................... 5

1.6 Constraints ......................................................................................................................... 5

1.7 Assumptions & Dependencies ............................................................................................ 6

SYSTEM PLANNING ........................................................................................................... 6

1.8 Project Management Approach .......................................................................................... 6

1.9 System Architecture ........................................................................................................... 8

1.10 Requirements Specification .............................................................................................. 10

1.10.1 Requirements Phase ....................................................................................................... 10

1.10.2 Requirements Elicitation .................................................................................................. 12

1.10.3 Requirements Analysis.................................................................................................... 12

SYSTEM DESIGN ............................................................................................................. 13

1.11 Design Goals .................................................................................................................... 13

1.12 System Specification ........................................................................................................ 13

1.13 Current Software Architecture .......................................................................................... 17

1.14 Proposed Software Architecture ....................................................................................... 17

1.15 Conceptualising the System ............................................................................................. 17

BUSINESS INTRODUCTION ............................................................................................ 21

1.16 Releases .......................................................................................................................... 21

1.17 Sprints .............................................................................................................................. 22

TEST PLAN ....................................................................................................................... 24

1.18 Test Approach .................................................................................................................. 24

1.19 Test Schedule .................................................................................................................. 25

RISK MANAGEMENT ........................................................................................................ 26

1.20 Risks Assessment ............................................................................................................ 26

1.20.1 Risks Identification ........................................................................................................... 29

1.20.2 Risks Analysis .................................................................................................................. 29

1.20.3 Treating Risks .................................................................................................................. 30

1.20.4 Monitoring Risks .............................................................................................................. 32

1.20.5 Risks Conclusion ............................................................................................................. 32

PROJECT SUPPORT ........................................................................................................ 32

1.21 WordPress in Details ........................................................................................................ 32

1.22 Skills & Knowledge ........................................................................................................... 33

1.23 Project Resources ............................................................................................................ 34

REVIEW & REFLECTION ................................................................................................. 35

REFERENCES .................................................................................................................. 37

BIBLIOGRAPHY ................................................................................................................ 38

APPENDIX 1 – Use Case Diagrams ................................................................................. 39

APPENDIX 2 – Activity Diagrams ...................................................................................... 41

APPENDIX 3 – State Diagrams ......................................................................................... 47

APPENDIX 4 – Architecture Diagrams .............................................................................. 49

APPENDIX 5 – Volere Template – First Version (Draft) ................................................... 53

APPENDIX 6 – Volere Template – Final Version .............................................................. 57

APPENDIX 7 – FR & NFR with Fit Criterion ...................................................................... 63

APPENDIX 8 – Volere/Snow Cards .................................................................................. 68

APPENDIX 9 – Use Case Examples ................................................................................. 76

APPENDIX 10 – Tutor/Student Collaboration ................................................................... 80

APPENDIX 11 – Risk Register .......................................................................................... 80

APPENDIX 12 – Gantt Charts ........................................................................................... 85

APPENDIX 13 – Logbook Excerpt .................................................................................... 87

APPENDIX 14 – Quality Attributes Scenarios - examples ................................................ 91

APPENDIX 15 – SBS Quality / Acceptance Tests & Validations ...................................... 93

APPENDIX 16 – UI & Examples of Practical Work – NFR Implementing ....................... 106

APPENDIX 17 – Client / Developer collaboration example ............................................ 114

APPENDIX 18 – SBS’s Competitors activities compared ............................................... 116

APPENDIX 19 – White Board .......................................................................................... 117

Author: Danail Chtipliev Software Engineering Dissertation

Page 4 |117

BUSINESS INTRODUCTION

SportBody (SB) is a Personal Training company based in London, United

Kingdom. SB provides bespoke personal training to its clients as well as training

sessions in a One to One coaching, Fat & Weight Loss, Muscle stimulation, Body

transformation and Nutrition programs.

At the present time all the company's administration is carried out using a

traditional paper-based approach. The company intends to move from the existing

system to a new computerized system, to be called the SportBody System (SBS).

PROJECT INTRODUCTION

1.1 Project Title

Development of a web based system to support and manage an established

Personal Training business.

1.2 Problem Statement

SB – London’s Personal Training company needs an online business

transitioning in contrast to their current paper based business handling, because they

found it extremely difficult to keep abreast with their competitors. Also the owner is

planning to expand their services internationally through a computerised system, thus

increasing their business revenue.

1.3 System Goals & Objectives

The purpose of developing the new SBS is to allow the owner of SB to promote

their business and spread the word Worldwide, under controlled manner. Creating a

sustainable web oriented system, which will give instant and complete response to the

customer’s needs of the SB’s services and their online digital products. SBS shall

support the owner of SB with monitoring and controlling the flow of users.

1.4 Project Goals & Objectives

Providing the owner with a one to two-week framed frequency of working

software, provides the owner with a competitive advantage of using features of the

uncompleted system earlier, based on well-structured incremental releases.


Page 5 |117

1.5 System Scope

SBS will deal with all SB services available, all membership details and all

personal training lesson bookings. It will also deal with all the stakeholders (the owner

of the company, members and personal trainers) as well as users, browsing the SBS

who potentially may become members.

SBS is intended to target all people involved in sports and people who may simply

want to change their lifestyle by getting involved into physical activities.

SBS will operate via web browsers and PCs at the company’s premises and also

via browsers and PCs at the user’s abode. The business boundaries are depicted in a

more descriptive and efficient manner, in a form of a Use case diagram (see Figure1,

Appendix 1).

The SBS will not support selling commodities online, but digital products such as

services and others alike.

1.6 Constraints

At the initial stage of the negotiating phase of the project, the costs were agreed

between the system developer and the owner of SB. The approximate figures of the

outgoing costs were unclear and they will be an object of further refinements as the

business requirements may change throughout the development cycle of the system.

The SBS must be developed in a timely manner, with a fixed duration of six

months.

The SBS will be designed, developed, tested and implemented by a single

software developer (Danail).

The owner’s little prior knowledge of the WordPress platform restricts the system

to be developed in WordPress software platform, which is discussed later under the

section – WordPress in Details. Thus the owner could manage her business via an

effective and user friendly CMS (Content Management System).

The first proposition of using the PHP as the main programming language has

led the both owner and developer to a decision making point on a type of CMS platforms.

The main candidate was the WordPress Open source platform, but there were other


Page 6 |117

alternatives like Joomla and Drupal. They have different capabilities, strengths and

friendly CMS’s also, but we both agreed on WordPress, because of my solid knowledge

of a that particular technology.

1.7 Assumptions & Dependencies

As the suggested system will be a web based oriented, we assume that the

system will be platform independent, i.e. can be available on any browser in use. As the

owner’s personal preference of using WordPress, we can assume that the server, we

would incorporate into our project, supports PHP and also has predefined WordPress

package available for an instant installation and usage.

Another assumption will be made, based on the system’s performance profile i.e.

the internet connection’s speed that would affect the user’s interaction and experience

with the system. The performance state of the SBS will also be dependent on the

webhost provider’s availability.

SYSTEM PLANNING

1.8 Project Management Approach

Choosing the right Lifecycle model for developing the SBS, was one of the first

and one of the most important steps to the Software Engineering.

From my point of view in order to satisfy the customer’s needs in favour of the

customer’s competitive advantage, there were two main project management

approaches that I picked for consideration. These were the Waterfall & Scrum

methodologies. I had to make a decision on one of them, based on my knowledge,

understanding and also on my ability to be able to analyse the development process,

before using these frameworks.

The traditional Waterfall model, characterises with its linear, one way oriented,

sequential and non-adaptive approach. This would have been a good choice for a

system which would have had well-defined requirements upfront and frequent changes

were undesirable.


Page 7 |117

It would also suit a “… short (say six months to one-year maximum – a typical

student project length) so that the problem does not have time to evolve” (Dawson,

2005). In the Waterfall management, every single stage of the process carries out

specific tasks and each stage is repeated once only.

After analysing the description of the Waterfall model exhibited in the auxiliary

book, I have learnt that it would also allow some limited iterations to take place in

between individual stages, which were illustrated as ‘splashing back’ (Dawson, 2005),

(Figure 2, Appendix 1, adapted from Dawson, 2005).

One particular feature of the Waterfall approach has attracted my attention. In

my early stage of deciding on a software delivery model, I liked the idea of predictability.

That was the feature of the Waterfall that I decided to investigate further (see Appendix

13, Log.1).

Soon after the short investigation, I have changed my perspective in regards to

the predictability, previously considered as a possible feature for the project. I have

discovered that almost all of the modern software architectures, derive from adapting to

change and agility in process through incremental-irrational approach.

Based on my findings, I assumed that changes do not tolerate, and they are also

not compatible with predictions. Conclusively the Waterfall approach is preferred over

others when the outcome of the final product has to be predicted in advance.

Briefly, Ken Schwaber and Jeff Sutherland defined Scrum as ‘Scrum is a

framework (see Figure 2, Appendix 4) for developing and sustaining complex products.’

(Schwaber, K. & Sutherland, J. 2011). They are both pioneers and the founders of the

Scrum philosophy and both stand behind the Scrum Guide.

From the software perspective the preponderance of the Scrum over the

Waterfall framework is based on its qualities, such as internal and external high quality,

continuous collaboration. All this in combination with versatility in adapting to change in

requirements. That is why from a purely comparative perspective, Scrum would be the

best fit of making the customer better satisfied with the product even in the early stage

of the development process.


Page 8 |117

After following our initial meeting with the owner of the SB (see Log.2, Appendix

13), I have decided to incorporate something from the Waterfall methodology, i.e.

gathering the maximum requirements at the inception phase of the requirements

elicitation. That is because it gave me the chance to reach and analyse the business

from a wider perspective.

The client has bombarded me with a heavy load of information about the current

business operations and left me with no hesitation for considering Scrum as a Life cycle

for my project. Scrum as being the leading approach and the Waterfall as secondary–

supporting and also non-continuous approach.

Another important decision–making point when I had to pick up the appropriate

SDLC method, was driven by the client’s hesitancy - whether they were going to expand

beyond their digitally-sold services only, or they were planning to add an additional

shopping cart option to the system (see Log.3, Appendix 13,). That was also a clear

indication of involving Scrum because of the client’s intention of adding, removing or

adjusting business functionalities throughout the development process.

The graphic design features development of the SBS was also included in the

process. As a developer of the SBS I agreed with the owner on that. Producing the text

of the site would be the only mandatory requirement of the owner. I will guide her in

order to maintain legal issues as well as specifics of the business.

1.9 System Architecture

The architecture decision I had to make was influenced by the client’s

requirements and more precisely, the non-functional requirements, the core features,

the constraints and the application environment (OU, TM354, Unit 9, p. 13, 2016).

My initial choice was the two-layered structure MVC (Model View Controller)

architectural style. After analysing further, I had to extend the Model layer via the dual

links connecting to a new MySQL database (see Figure 3, Appendix 4). This change

was dictated by the architectural structure (the deployment model of SBS) of WordPress

(see Figure 4, Appendix 4).

For the purpose of keeping the customer engaged with the project work, I have

decided to create a prototype of the UI first (see Figure 1, Appendix 16). Thus, I can


Page 9 |117

maintain the vital for the project quality – continuous collaboration and receiving a

constant feedback from the client in real time. This approach has helped me to

constantly reflect back on the quality of the system in progress and also has helped me

with the manipulation and mitigation of the system’s risks in the early stages of

development (see Appendix 11).

The question that was standing in front of me was, how the type of architecture I

have chosen, will evolve as the project grows in size? The answer to that question was

hidden in the twin–peaks model (see Figure 5, Appendix 4, adapted from OU, TM354,

Unit 9, p. 11, 2016).

I have chosen this model, because it would greatly merge with my Lifecycle

model, applying the same principles of been light from beginning and at the same time

being developed in an incremental and iterative fashion. Other important benefits that

the model could forward towards my project was in a form of communication

enhancement and “… documenting assumptions about the system” (OU, TM354, Unit

9, p. 12, 2016).

Being led by “… in order to be useful, requirements must be testable, which

means that they must be measurable” (OU, TM354, Unit 9, p. 12, 2016) I have decided

to look for more details into the non-functional list of requirements first. That is because

there are dependencies that exist between the FR and NFR and also direct

dependencies between the architecture and the NFR.

I have chosen to test the non-functional requirements by attaching fit criteria to

each NFR. Further and more detailed investigation of the each NFR – Deciding on the

Quality attributes are analysed below.

Further, I created quality attribute scenarios (examples can be seen in Appendix

14), which helped me make creative decisions on the architectural style of SBS. Even

though I used a fit criterion for testing the NFR, I recalled from what I studied with TM354

that this approach was extremely useful and powerful for creating successful systems,

because it “… allows specification of non-functional requirements in a more precise and

detailed form” (OU, TM354, Unit 10, p. 71, 2016).


Page 10 |117

1.10 Requirements Specification

1.10.1 Requirements Phase

This phase of the project is concerned with the purpose of the system i.e. what

the system must do in order to satisfy the client’s needs. After the formal one to one

meeting with the owner of SB, I have managed to collect a quality information about

their business activities.

Throughout the interview I was also explained that all the current members for

the past two years had been collected and stored in an Excel (XSL) format. The first

problem that the owner was concerned with, was the way of how all the data can be

transferred into the system’s database safely.

An example of a one of our interview sessions can be seen in Appendix 17 and

it depicts my Scrum’ type of approach i.e. I accept changes to requirements adequately

as well as accepting new ones and deleting old once continuously.

Also, I was lucky enough to be offered the possibility to observe a day live of the

business in action. Thus, I did have a real chance to learn more about the business in

action and better understand the owner’s needs that have to be supported and covered

by the SBS.

I have decided to include the Volere template as a source of the requirements

elicitation phase, because it promotes more structured and systematic approach of

requirements handling.

The full version of my first attempt of the Volere (see Appendix 5, adapted from

OU, TM354, Unit 4, p. 11, 2016) template illustrates and tests my understanding and

implementing of my professional approach to the Software Engineering Project,

requested by the OU.

Following the template mentioned above, I have made some significant changes.

I have decided to elevate the FR and NFR of the Volere template and present them in

a great detail. This manoeuvre did help me further with the tests of each use case.

Decomposing the user requirements into smaller, more refined versions (Use

cases), was my next task of the Software Engineering. The letter indicators M, D, O and


Page 11 |117

‘?’ have been used for clarifying the level of importance of each requirement, which

would eventually be playing an important role in the grooming process of the Product

backlog.

Looking at the Volere template and after careful reviewing of my knowledge about

how to properly define the gathered requirements, I have realised that I had to revise

the material on TM354 before further proceeding take place. As a result of reviewing the

TM354 study material, I did have to amend almost all of the requirements stated by me

in the first place (see the Evolved version of the Volere template, Appendix 6)

The reason I decided to attach a fit criterion to each of them (see Appendix 7)

was because this way I could verify the results of the black box testing against the fit

criteria of these requirements. One little specific note that I wanted to point at was that

the NFR can be quantified and on the other hand the FR cannot be rated or measured

in terms of a specific scale.

The next question I had to decide on, was how much data (attributes) for the

separate Actors has to be collected and stored in the database? The following example

lights up the idea of how important it might be to go deeper into a more detailed

decomposition of requirements. Thus the gap between the business and the developers

closes up efficiently.

Actor: Member – ‘username’, ‘user_email’, ‘post_code’, ‘city’, ‘first_name’,

‘last_name’, ‘role’, ‘nickname’, ‘display_name’, ‘description’

Actor: Trainer – ‘trainername’, ‘trainer_email’, ‘post_code’, ‘city’, ‘first_name’,

‘last_name’, ‘role’, ‘nickname’, ‘display_name’, ‘qualifications’

Actor: Owner – ‘ownername’, ‘owner_email’, ‘first_name’, ‘last_name’, ‘role’

Event: Service – ‘Date’, ‘Start time’, ‘End time’, ‘Client name’, ‘role’

Based on TM354, identifying the systems quality attributes early have played a

critical role of describing the system as either being successful or not. That means that

I had to identify these non-functional requirements that are vital to the system’s ‘health’.


Page 12 |117

The technique of using Use case diagrams has provided me with better overview

and better understanding of how I can approach and construct my next best version of

the functional requirements. Further decomposing the user stories by their specific users

(Actors) has helped me with better organising and structuring them. For an example of

the new look of the tabulated results see Narrative modelling of the FR, see Appendix

6, p. 58.

I have applied the ISO/IEC 25010:2011 (ISO, 2016) standard, which was

concerned with the quality of the SBS. This supports the clarification and justification of

my choice of NFR for SBS through picking on the most critical once. Thus reassuring

an appropriate and measurable fit criterion is set up earlier in development.

1.10.2 Requirements Elicitation

Elicitation is an important task, which helps the system requester to define what

is required. The elicitation phase of the requirements is a complex process at which the

developers and stakeholders may face many problems such as - Is the business domain

properly defined and understand?... Is the business domain misinterpreted?... etc.

Those problems could be mitigated should the appropriate method of

requirements is applied. However, this is not an easy task and that is why I have chosen

the Volere template in order to increase my attention to detail, being more organised

and systematic when translating the client’s requirements into the real and useful user

stories. Then these stories would subsequently be decomposed into use cases, which

would finally be turned into a working software.

1.10.3 Requirements Analysis

Looking at the refined version of the Volere template it can be deduced that there

will be two major grouping of users, interacting with the system directly. On one site it

will be the System Operator (Owner, Admin, Developer) on the other site it will be the

company’s clients (existing and potential Members, Trainers).

After contemplation around the business domain, I decided to separate the

requirements based on the system’s active actors. Based on that we may assume that

the System Operator would gain access through either on-site browser or reaching the


Page 13 |117

system CMS through distance again via browser. For the client of the system we may

assume that the only access will be from a distance via their electronic device’s browser.

SYSTEM DESIGN

1.11 Design Goals

This phase of the project is concerned with my ability to satisfy the client, making

the system as good as possible without having a specific criterion for measuring the

acceptability. I strove to provide the client with a user friendly, efficient and lucrative

system at a minimum maintenance cost.

The system must be easy to operate with and easy to understand it. Also the

system must satisfy all the time-related requirements, which are considered in details

later in this discussion.

1.12 System Specification

The owner of the SBS had a particular list with examples containing system

domain names. I did a thorough research over the domain name vendors online. After

having the chance to see one of the suggested names available – sportbody domain

name (see Figure 6, Appendix 16) with three extensions were instantly bought and

reserved for the purpose of the system development.

Proposed domain name: sportbody – co.uk, net, org

After careful analysis of the competitor’s activities online (see Appendix 18), and

after subsequent conversation with the owner of SB, we both decided on the following

pages:

Home Page

Rationale: The aim of the home page was to make an introduction and also a

brief overview of the business activities. It also holds a major part, forming the users-

system engagement. The main role of the page was to support the owner’s first

impression and feel of the system at a very early stage of the development. It also played

an important role as supporting tool for the successful collaboration needed from the

owner on a daily basis. Thus, it resolved a dual type problem.


Page 14 |117

As a developer, I needed to have a live connection with the owner so I can make

sure that I have constant feedback which would help me avoiding misunderstandings

during development. On the other side the owner’s desire of having a content reach

opening page was satisfied early in development (see Appendix 16)

Tests: There were no other test types, but acceptance tests with the client. All of

the tests have passed without any advice or recommendations from the client.

About Page

Rationale: The about page was concerned with providing users with detailed

description of the business and services available to them and also what to be expected

further down on the line. The nature of the page is purely descriptive. From the designer

point of view only the acceptance tests were making sense here.

Tests: The conducted tests have passed successfully and the page was

accepted for further amendments.

Trainers Page

Rationale: This page will be focused on gallery view of all of the trainers hired by

SB. Users may freely explore trainers and the specific to each of their qualifications.

Thus the user’s desired choice of a particular trainer can be made easily when trainer

available.

This page solves the owner’s problem i.e. transparency and visibility of

professional trainers, which may potentially increase the value of the SB business. The

page should be publicly available without authentication required.

Tests: The conducted tests have passed successfully and the page was

accepted for further amendments (see Log 4, Appendix 13).

Services Page

Rationale: This page is comprised of four sub-pages each of which provides

users with detailed information about the nature of the services of SB, each supported

with a short video presentation. From the owners’ perspective that was the page with

one of the highest priorities in the development hierarchy.


Page 15 |117

Thus the owner can express in details what is on offer. The page had to be

accessible from all of the users, even without authentication.

Tests: Due to the non-secure requirement of the owner that the page should be

publicly available, I then had no other option, but fulfil the test required through

acceptance tests carried out together with the client. They have all passed as expected

(see Log 5, Appendix 13).

Members/Bookings Page

Rationale: Would allow the members to manage their bookings. It will also

contain three other sub-pages which will describe different membership levels with

different privileges to members. Silver, Golden and Platinum type of members, have to

be registered first in order of the members to be able to gain access to more specific

content of SBS, which will specifically be produced and embedded into these pages.

The owner wants to be able to collect the bookings under structured manner and

being able to keep the training schedule organised.

The page shall support the owner’s idea of having different membership levels.

Thus she can conduct and maintain clear distance between the different type of

members’ needs.

Tests: Acceptance tests conducted (see Log 6, Appendix 13)

Shop/Gifts

Rationale: Would allow users to purchase packages for personal training

sessions as a gift to a friend for instance, or using the SB digital services out of London.

All that stuff shall be sold over the SBS and will be either in a digital format or in a form

of a one on one services (provided in London area only).

Solving the problem of the owner’s desire to sell digital goods online the owner

and myself, we both agreed on this as being an opportunity for the SB to walk abreast

with their competitors.

Tests: feature has been cancelled by the owner

Contact Page


Page 16 |117

Rationale: This page shall provide the users of the SBS with a full set of useful

contact information about the SB’ business – address, mobile/land line phone numbers

as well as easy to understand and easy to fill in the contact form. All the above stated

must be accomplished in combination with the SB’s business specific Terms &

Conditions.

The compulsory Terms and Conditions must automatically be sent when users

submit their online requests to SB.

Tests: Validating tests against the plugin specifications were conducted. All the

tests have passed successfully (see Figure 6 & Figure 7, Appendix15)

Register page

Rationale: This page is concerned with the new users should they decide to

explore SB’s more specific content. Also the page supports members who are signed in

as a basic – Silver membership level and they would like to update their membership to

one of the more advanced, paid levels.

At first the page prompts the user/member for a membership level, after which

displays a simple to fill-in form. It supports the first stage of authenticating process, or

continuous link to the Login page, which solves the owners’ problem of controlling the

SB’ users’ (perspective members and current members) access to the SBS.

Tests: Black box testing, which was concerned with the component’s

specification were conducted (see Figure 2 & Figure 3, Appendix 15). The plugin was

compliant and regulated with the ability of writing the user’s data into the SBS database.

There was also an acceptance test carried out together with the owner and has been

accepted.

Login/Logout Page

Rationale: That is the place of single point of authentication of SBS, where the

users can gain access to the SBS. The Importance of the page was based on the

owner’s desire to control the system via user’s authentication.

Tests: The process of authentication that has been considered and discussed

with the owner, have met the threshold of the minimum security requirements of the


Page 17 |117

SBS. According to the plug in’ specifications and my thorough black box (see Log 7,

Appendix 13) testing of the system, the owner and myself, we were both satisfied with

the achieved level of security of the SBS.

1.13 Current Software Architecture

At one of the subsequent conversations with the owner, she admitted that they

had some kind of static website, but because the site was not functioning any longer,

the older version of the system remained unavailable for exploration. The only way they

maintained their clientele was via Excel spreadsheet containing the clients’ details in a

digital form.

1.14 Proposed Software Architecture

WordPress is purely based on components (plugins) and for that matter, I

projected my view of the proposed product into the following component diagram. It

represents the actual Deployment Model of the SBS.

Fig 1. Deployment Model of SBS

1.15 Conceptualising the System

The very first thing after the business analysis, I have begun to interpret,

prototype and model the business processes in a form of diagrams. In parallel with this


Page 18 |117

action, I have also started doing acceptance tests, in collaboration with the owner of the

SB.

A full set of activity diagrams was developed for the purpose of modelling the

SBS business process (see Appendix 2). The figures have addressed the majority of

the problems that had to be solved by the system i.e. the authentication of a user can

be addressed to system’s Security issues for instance.

It means that before the user is allowed to gain access to the restricted area, the

user firstly need to be logged in by using their username and password when entered

in the registration process. If the authentication is invalid, no further proceeding would

take place of user accessing the member’s area.

The next step of my strategy was to create a Use case diagrams (Figure 1 &

Figure 2, Appendix 1) which illustrates the concept of separation of concerns i.e. clearly

separating the Actors and the Events of the SBS. I have planned to use the use case

diagram to be able to construct the separate Use Cases. We need to bear in mind that

the system will evolve continuously and all the stages of the development process will

be repeated and refined as the project goes along.

From my point of view an excerpt of the entire Use Case Description of the

authentication, deserve to be exposed in the main report, because of its importance to

the SBS and also that would demonstrate my professional understanding of the

constructing a simple Use Case.

I have decomposed the Authentication process into small chunks. Thus the more

detailed and structured approach would clear all the ambiguities around the complexity

of how to build software-ready Use Cases. The example was divided into three parts:

Log in, Log out and Password Change. The example bellow shows just the Log in

attempt of creating a simple Use Case.

Before I have stepped and applied the Scrum methodology at its full potential, I

had to clarify with myself the way the Use Cases had to be developed. Coming from my

knowledge of TM354 material I have managed to recall that in an Agile manner the use

cases are developed as needed instead of trying to create all of them in a first place.


Page 19 |117

Simplicity of the Use Cases is the key factor of success with the agility of the

project as well as triggering a quality communication within the development team (even

though I am going to be the only one responsible for carrying out all the work, this

principle still applies).

Also the light weight blueprint of the UC’s in an Agile fashion, adjusts the

ambiguity to an accepted level. Gradually evolving the content of the UC’s also helps

with maximising the quality and efficiency of the documentation in Agile. See below a

small fragment of the Use Case approach. The following version was based on my

working experience as a Scrum Master:

UC# 01

Authentication

Use Case: Log In

Actors: Owner, Member, Trainer

Goal: To enter the SBS

Preconditions: Must be registered first

Post conditions: The user/operator shall gain access to the SBS

Main successful scenario:

Locating the Log in field

Enter User Name & Password

The system approves credentials & redirect user as requested

Proceed further

Exceptions:

Unrecognised Username

Wrong Password

User is blocked

Priority: Mandatory

When Available: Sprint 05 (see Gantt Chart, Figure 1, Appendix 12)

After careful analysis of the business epics, further use cases have been created

(see Appendix 9).


Page 20 |117

The next step of the development of the project was in a form of dynamic

modelling of the system. The State Machine modelling (as a dynamic-behavioural

model) was the one I was interested in. That is because the behavioural model indicates

of how the system will respond to external events or stimuli.

I decided on State modelling over sequence modelling as I do not know exactly

how all of the components’ (plug-ins) code work internally. The interesting thing about

state diagrams is that they represent the active states for classes and the events they

trigger. As authentication is one of the most interesting and strong requirements, I have

decided to display it in the main report Fig 2.

Fig 2. Example of a State Transition Diagram (Authentication)

The full set of state diagrams can be seen in Appendix 3


Page 21 |117

BUSINESS INTRODUCTION

SBS was delivered in a specifically defined time boxes. As agreed with the owner

of SB the system was delivered in 6 months, starting 16/03/2016 and scheduled for

completion 11/09/2016 (see Gantt Chart, Appendix 12). After careful preparation, the

project has been planned, outlined and agreed with the owner.

The project was divided into three main time boxes (Releases). Each release

comprised of a different amount of evenly distributed and relatively small time boxes,

called Sprints. Each Sprint had a different amount of User Stories and each story had a

very well defined Use cases (Tasks). Find below the detailed description of all of the

time boxes, which are specific for the Scrum methodology of project delivery.

1.16 Releases

Release I

The purpose of the first milestone was to prepare the core functionality of the

specified automated system. There were design decisions that I had to make in order

to pass all the planned acceptance tests with the client. All of the natural precedence

requirements (see Volere template, Appendix 6) were solved in the first Release.

Also the functional requirement – Log in / Log out, was delivered first because of

its highest priority status among the others FRs. I think that this FR falls into the non-

functional requirements register also. That is because the security (authentication) of

the system belongs to the group of the eight NFR’s classes according to TM354.”

Security requirements. The security and confidentiality of the product.” (OU, TM354,

Unit 2, p. 94, 2016) and at the same time I have described it as FR, because it was one

of the client’s clauses.

The Release I, was comprised of six Sprints. The number of sprints within was

dictated by the difficulty of each User Story, including their Tasks (Use Cases) within.

Release II

At this stage of the project I have focused on improving the authentication of SBS

that left from the previous Release I. Strengthening the security by adding more levels

of restrictions, and I also worked on the third party payment system linking. All these

concerns with adding a variety of security levels were implemented because of the


Page 22 |117

WordPress’s security leak. All that matter was discussed and agreed with the owner,

previously. At this level of the project, the business booking functionality was analysed

and implemented also.

At this level the client requested a new feature (see Log 8, Appendix 13) to be

embedded into the system. Extended testing of the embedded third party system were

carried out and all tests went as expected (see Figure 4, Appendix 15).

Release III

One of the owner’s biggest hesitation had been the shopping card system’s

enhancement. It did finally brake apart and the owner of SB has taken a decision to

cancel the rest of the project just in the middle of the planning of the Release III.

1.17 Sprints

At this level of the project I focused on delivering the pre-planned user stories for

specific Iteration. An iteration is a relatively small time box of two to three weeks in length.

For the purpose of my project I have chosen a length for my Iterations to be nine to ten

days. I have strategically used more granularity in my project, because it promotes

further improvements and enhancements over the risk control on SBS.

Initially I supported the iterations planning by using a White board, but I sooner

realised that I may handle the management through the Gantt Chart only with the same

success. Another important reason why I have left the use of the White board was that

its main purpose was to increase the visibility/transparency of the main product road as

well as increasing the level of communication within the development team.

According to the Gantt Chart (see Appendix 12) it can be seen that all of the Use

Cases developed are briefly expressed. I decided to further draw attention at the first

two sprints as examples, including their content (Use Cases) and the reason behind (the

rationale).

Sprint 01 Planning phase

The initial step of creating the Sprint_01 was the planning phase, which have

taken me an hour to complete (see Project Log????? July) This step was followed by

research as planned. I had to answer questions as follow: Does the domain name has


Page 23 |117

already been taken? Does the chosen hosting have the PHP capability and does it allow

MySQL database handling? Does the chosen hosting have the prebuild WordPress

package available? After all of the questions were positively answered, I have begun

following the Scrum framework dealing with the Sprint_01.

Sprint 01 Development phase

The first iteration was based on three NFR’s – US60, US25 and US26 (see

Appendix 8). Activating the domain name. Activating the hosting provider and

connecting the domain name to it. Installing the WordPress platform with all additional

assets needed for the correct functioning of the SBS online.

Sprint 01 Review

All the current achievements were introduced to the client in order to reassure

her that the system takes shape and all of the features are developing accordingly (see

Table 1, Appendix 13). Evidence of work done see Appendix 16.

Sprint 01 Retrospective

When reflecting on work done, I had noticed a significant delay in communication

with the owner as she reassured me that she would free up some more time for

communication and collaboration with me. I was happy with my performance, because

I did plan a possible delay upfront. Thus, I compensated that delay with more time

injected into the first Sprint.

At present, I could have not thought about anything that could have improved. All

the known current risks were caused by the owner. That is why I focused on this,

monitoring it in the next Sprint_02.

Sprint 02 Planning

That Sprint was concerned with the core functionality of the SBS and It plays a

key role from a communication perspective. That is because it provided me with the

ability to prototype the system early, thus I maintained a healthy communication with the

client and it opened the door for the so vital feedback from the acceptance tests.

At the planning stage of the Sprint_02 I decided to pack the Sprint_02 with further

three NFRs. I had to investigate the feel and look appearance of the competitors in that

branch (see Appendix 18) and I also had to decide on the pages through collaboration


Page 24 |117

with the client. The importance of the client’s first impression of the UI prototype of SBS

plaid vital role of getting the owner immersed in the project’s development.

Sprint 02 Development

On the straight line the Sprint comprised of three user stories – US27, US28 and

US51(see Appendix 8). Usability tests of the menu system were conducted and

successfully passed the client’s acceptance. I jotted down the pages of the system early,

because these pages were the fundamental must for the further evolving of the system.

The responsiveness of the SBS was of importance too, because of the ability of

the system to be opened from a handheld device (see Figure 8, Appendix 15). Thus, it

could support the owner’s live acceptance tests and make them feasible.

Sprint 02 Review

Because the Usability and Acceptance tests were introduced in this Sprint, I had

to spend additional time with the client to make sure that the basic of the SBS was as

expected. All tests have passed successfully (see table 1, Appendix 13).

Sprint 02 Retrospective

Reflecting back on my work done, I did not find any issues this time. Everything

was as expected, but I think that the only thing that may get improved for the next Sprint

was the performance speed.

Further detailed information about the Use Cases involved through the

development of SBS can be observed in the Appendix 9

TEST PLAN

1.18 Test Approach

Even though there are many testing categories and approaches (system testing,

requirement-based testing, usability testing, performance testing, etc.) that can be used

when testing a system, but for the purpose of the SBS testing, I have predominantly

used the black box testing technique. That is because all of the plugins (components)

of the WordPress platform encapsulates the data contained in themselves.

Verifying if the right product has been built will be carried out via testing of each

of the user stories against their fit criterion. I have concentrated myself at the Boundary


Page 25 |117

Testing, which is concerned with the data input, the expected output and the actual

results.

All of the extreme values (the input data space), I have picked up were random

and are entirely based on my own perceptions and understanding of the possible system

errors that may occur at any point in time.

I also used acceptance tests extensively in combination to satisfy the fit criteria

of the each of the requirements, because I wanted to gain instant feedback from the

owner. Thus, I can adjust and adapt to the client’s needs swiftly.

After adding and manipulating a new plug-in into the SBS, I have also tested the

entire system (regression tests) and have inspected all the functionality of the entire

system. The process of evaluating and testing the SBS has helped me to determine if

the SBS performs its functions correctly and complies with the company’s goals and

needs.

All plug-ins have been designed by DbC, which means that all the validation of

the inputted data was automatically met by its preconditions first before further

proceedings would have taken place.

All of the acceptance tests have been carried during each Sprint, before the

Review stage (my own preference). Examples of the tests can be seen here in Appendix

15. All the output results of the provided acceptance tests have been confirmed through

the expected data recorded into the SBS database.

Appendix 15 combines all specific acceptance tests of the SBS. The component

(plug-in) Login for instance, was fully compliant with the owner’s requirement of

Login/Register user’s functionality. Thus the validation had passed successfully.

1.19 Test Schedule

Below I listed an example of a systematic way of testing procedures. The

example reflects on the Security Access of the SBS. The tests have to prove that only

users who are logged in successfully, will be able to gain access to specific parts of the

system to which they have permission of doing so.

Authentication & Security Control Test


Page 26 |117

Test Objective

To verify that a user may access only these membership levels for which the

member type provides permissions.

Procedure

Identify, analyse and list each user type and all the permissions’ type it has.

Create tests for each membership type by setting up a specific user type and verify the

link between members and associated membership level.

Assumptions

The developer has full access to the main CMS of the SBS. The internet

connection is constantly running. The third party payment system is available 99% of

the time.

Test Cases

For the purpose of testing of the UC #01 (see p. 24) I had to consider a set of test

cases as follows:

One for the main success scenario

One starting with the main scenario, but enter credentials as non-registered

user

One starting with the main scenario, but member enters wrong credentials less

than three times

One starting with the main scenario, but member enters wrong credentials

more than three times

Member forgets their credentials and tries to retrieve them via email

Further test examples of the SBS can be observed in Appendix 13.

RISK MANAGEMENT

1.20 Risks Assessment

One of the most vital parts of a good project management process is the risk

management. As I discussed below, the Agile methodologies such as Scrum, in my


Page 27 |117

instance has been designed to minimize the risk naturally by producing small and

frequent working software increments. Its iterative process builds on well-defined steps,

which when performed in sequence, allow continual improvement in decision making.

Risk management, according to the AS/NZS 4360:1999 standard, is defined in a

very well-structured way. It comprises of seven stages Fig 3. It starts with establishing

the context and followed by identifying, analysing, evaluating and treating risks. All of

that comes in combination with the continuous communication & consulting, and

monitoring & review of risks.

Fig 3. ISO 31000 – Risk management process

The first step I have taken, before the analysis of the risks had was to use the

brainstorming techniques with the owner in order to spot the potential hazards, their

probability of occurring and the impact on the SBS.

There is a variety of existing and potential risks, that can be observed within a

project. They might be of an intrinsic or an extrinsic nature. An example is given bellow

“technical hazards: using the wrong technology…


Page 28 |117

planning hazards: the software being developed is too complex…

personnel hazards: some of the team members are not capable of delivering…

client hazards: the client is too busy or lacks interest in the project…” (Holcombe, 2008)

The User Stories, on the other hand may be considered as the main source of

assessing risks. Either of the functional or non-functional requirements or both, will

constantly change during the development process, because from the software

perspective, every little change in requirements may introduce new risks into the system.

One of the risks that I have identified was associated with the suggested above

risk category, under the ‘client hazards’. That was the result of my observation of the

one of the owner’s workdays. I soon realized that the owner was the only person who

was dealing with the SB.

It meant to me that the owner would spend most of her time dealing with the

training sessions at present. Thus, she would not be able to support the so important

for the project’s delivery success. More specifically the Scrum’s continuous

communication contributions. It would also affect the time spent for the acceptance tests.

I had a discussion with her in regards to this matter and she reassured me that

she was in a process of hiring personal trainers at the moment, thus her commitment

towards the project would increase gradually.

Throughout the planning stage of each individual Sprint of the system, I have

carefully analysed the potential risks (see Appendix 11), which have helped me to

appropriately prioritize my next User Stories based on these assessed risks.

As developing tool, WordPress has some limitations and more specifically from

a security perspective, which might introduce risks into the system. That is because

WordPress does not have a very good reputation of having a rigid authentication

mechanism in place.

After discussion with the owner, despite the disadvantage mentioned above, the

owner has accepted the WordPress as their preferred CMS developing tool for the SBS.

This discussion was based on my recommendation of adding extra security levels, thus

increasing the security of SBS.


Page 29 |117

The approach stated above was not a very structured way of dealing with project

risks. For that purpose, I have developed the following separated tasks of risk handling.

1.20.1 Risks Identification

Risks in a first place involve a scrutiny of the entire source at present. That is

something that might be at risk and any subsequent effect that it may drive to that source.

After identifying a risk, I had to ask myself a few questions in order to categorize

them. What may happen? How may it happen? What is the reason of it happening?

What will be the impact if it happens? For the purpose of the project I have used the

Risk Register (see Appendix 11) as my key method of identifying risks.

The register is a well-defined way of expressing and organizing many of the risks

that may occur at any time within the project development. There are many others like

Risk Data Sheets, reports etc., but I have stopped at the Risk Register method only,

because from my point of view when focusing at something, you can then deliver better

results.

1.20.2 Risks Analysis

At this level the identified risks are thoroughly checked against different risk

attributes like probability, severity and impact on the SBS. Calculating the values of

these attributes is an important manoeuver, because risks need to be measured in order

to be properly prioritized and ranked.

Why would we need prioritizing? That is because the risks with the highest rating

jeopardize the development of SBS the most. That is the reason why risks have to be

mitigated or eliminated early in development under controlled way. After analysis of the

Risk Register, I have discovered the risks with the highest rank.

I wanted to pay particular attention to these risks, because as I mentioned above,

they were the most critical risks from the development perspective for the SBS.

According to the Risk Register it is apparent that the requirement’s risks are one of the

most vulnerable spots within the project.


Page 30 |117

1.20.3 Treating Risks

Below are listed two risk examples with appropriate actions that can be done in

order to reduce, put on hold or eliminate them. Both cases were considered with the

highest risk rating, that is why they were investigated closely. An example is to follow

below.

#R1-Problem statement (follow Risk Register, Appendix 11)

From the owner’s perspective the change in requirements and adding, and/or

removing requirements were the main attitude towards the project’s evolution. From the

very beginning of the project they were not very clear about whether they were going to

need some features or of the system or not. We both negotiated the opportunities to

add new requirements and we both positively agreed to this clause in the agreement.

From the Developer’s perspective the probability of that risk to open was graded

to the maximum of 3, because it was quite common in nowadays the dynamic software

development was to involve continuous changes in requirements. Should the critical risk

begin to be ignored and not dealt with on time, the impact on the SBS would be

catastrophic. That is because from the software engineering point of view, every little

change in requirement would introduce a new change in the system (the Domino effect).

After I reconsidered my Risk Register, I thought that I was wrong when I stated

that the detection of the risk would be of a difficulty 3. When juxta positioning the old

version and the new version of the requirement, the change was apparent. Thus the

new amendment in the Register had to take place and being classified as a range of 1

and calculated ranking would be 9.

Quite often the requirements are associated with the actual software as an end

product of these requirements. That is the way I wanted to use one of the main risk

factors within the software, i.e. Malleability where “Every change introduces the

possibility of new errors.” (OU, TM354, Unit I, p. 10).

#R1-Contingency Plan

One of the main reasons for incorporating Scrum as SDLC for delivering SBS

was the opportunity to respond to changes in requirements efficiently without delay.


Page 31 |117

Another benefit of applying an Agile methodology, has helped me communicate the

problems with the client on the move.

Thus, all the potential negative consequences, based on changing requirements,

were explained clearly back to the client. The client was then in a position to either give

a green flag or a red flag to the requirement involved.

#R2-Problem statement

The wrongly elicited requirements are one of the biggest threats in the software

engineering. Even though the project was small and I had to deal with only the owner’s

requirements and no other stakeholders were involved, the probability of this risk to

happen was high, because there were still two parties involved (Developer & Owner).

The owner was obligated to provide me with the correct information about their

business needs as clear as possible. I was obligated to translate and transfer this

information into useful requirements (User Stories), correctly without skewing up the

embedded information carried in them.

Every little misconception from my site would have made my client unsatisfied

with my work. Being ignored, the impact on the SBS would have been critical, because

the final product would have differed significantly from what the client wanted from the

product in the first place. That is why I placed it into the range of the maximum possible

score of 3.

Detecting a wrong requirement is a difficult process, because it involves

additional investigation, which needs to clarify the synchronization phase between

different parties involved in the creation of that requirement. Thus, it makes it a perfect

candidate for falling into the category of 3. Overall ranking is equal to 27, which defined

the risk type as the most critical among other categories of risks.

#R2-Contingency Plan

I did rely on Scrum again when I did approach this risk factor. I leaned on the

fourth principle of the Scrum Guide “Business people and developers must work

together daily throughout the project.” (Agile Alliance, 2015). This principle is concerned

with the high quality, continuous communication delineated by the Scrum framework.


Page 32 |117

1.20.4 Monitoring Risks

The best practice when Scrum is involved, risks are addressed and reviewed

frequently at regular daily stand-ups (Scrum team meeting). Thus the old risks have

been addressed, reviewed and dealt with, and the new risks were added to the Risk

Register for subsequent analysis.

1.20.5 Risks Conclusion

Let us point at the notion that not always the risks are bad things. Often risks

have a positive influence on project management and over the developers’ team. Risks

drive the communication within the team. Also risks, create and maintain creativity within

the team.

There are many other benefits of having to deal with risks, like falling quick and

recovering from a failure. Long story short, having risks managed under controlled

manner are the main objectives when planning different phases throughout the project

development.

PROJECT SUPPORT

1.21 WordPress in Details

WordPress was released on May 27, 2003, by its founders, Matt Mullenweg and

Mike Little. WordPress is a PHP oriented free, open source software development

platform. It uses tabular Database to store all the dynamically passed information

between all existing architectural layers, which can later be observed, invoked and

manipulates accordingly.

Instead of being able to manipulate the flow of users in and out of the DB directly,

which would require additional knowledge, the stakeholders can maintain users directly

from the predefined admin console – CRM. WordPress introduces great flexibility with

its HTML direct edit as well as CSS capability, which will be providing me with the

freedom of designing and implementing the web system’s content as precisely as I

wanted.


Page 33 |117

WordPress can be used extensively for creating bespoke web based systems for

very little cost and it can be also used by big and small size business. The WordPress

framework elevates my intention of getting the client involved in the project.

The effectiveness of the CMS can be described like this: “Different aspects of the

overall process can be assigned to different users, each with their own role, and that

role will determine what they are allowed, and not allowed to do.” (Sabin-Wilson, 2013).

That means that the owner could edit the text for instance on a fly, simultaneously as

the project’s evolve.

WordPress framework features a plugin architecture and a template system. I

have considered building the system through Drupal framework, but my limited

knowledge and the Drupal’s back – end oriented nature, did not match my expectations

for completeness. That is why I have focused myself on WordPress.

Taking under consideration and analysing some of the WordPress’ drawbacks

can be a good time investment, which will subsequently prevent delays in development.

One of the most important issues worth further investigation is the security leak, which

will be discussed later under the Risk assessment section in more details.

1.22 Skills & Knowledge

In year 2009 I have gained proficiency in Adobe CS3 suite and since then I have

self-educated working with Photoshop, Illustrator, Dreamweaver etc. I have also gained

knowledge about CSS, HTML and object oriented PHP. All that combined with my

Professional Scrum Master (PSM I) accreditation, will appropriately be applied with all

the gained knowledge from TM354 Software engineering.

I was right about thinking that the TM354 will be enough to complete my project

without the need of multitasking by having to engage with another OU module. I have

overall increased my knowledge in regards to the project management matter. During

the project evolved, I also learned Agile a lot via online lectures and books.

A year ago I started working as a Junior Scrum Master for a small company. Two

months ago I have started a real job as a Scrum Master for a small project and from a

practical stance, I have now a real opportunity to apply what I learnt with the OU.


Page 34 |117

Guiding a small team of five people, I quickly had to adjust to their specifics and

finding new practical tools for visualising burn up/down charts, facilitating meetings,

reviews and retrospectives. I also dealt with the transparency of the project and I was

working closely with the Project Owner grooming the project backlog.

The OU taught me a lot about the technical side of the Software Engineering.

That made me confident when for the first time I stepped into the role as a Scrum Master.

I am planning in the near future to continually expand my knowledge about Agile

processes and methodologies and become an Agile expert/consultant.

1.23 Project Resources

So far, I have identified two major roles representing the owner (Vesi) of the

business who requested the system and the developer (Danail) who has accepted to

deliver a high quality system on time and on budget.

For the purpose of the project I will be using my home laptop, running windows

8.1 Professional. As the main system’s production tools I have decided on WordPress

standalone core installation package being provided via a third party hosting supplier.

As a supporting tool for the graphical design I have chosen the Photoshop CS6.

I have also used a third party domain name provider, which I have planned to

support the live collaboration events with the owner of SB. For the evidence supporting

the installation of the WordPress package, the domain name tuning procedure and the

Photoshop availability – Fig.5, Fig.6, Fig.7

I have also requested from the owner to be able to gain access to the testing site

via the internet. The connection should be made through her personal computer, from

a private network, because of the security control intended.

For the purpose of my project schedule, I am using Gantt chart free graph

visualisation software tool, which can be observed under the Evidence of Work section.

The main guidance of the way the owner wants the system to look like and

operate, includes three competitors’ (Appendix I)

In terms of standards I am using proven standards bodies are the W3C and ISO,

both accessible online and included in the reference section.


Page 35 |117

For the purpose of the project I have used the well-known standard bodies – W3C

and ISO. The abbreviation W3 stands for the triple W – World Wide Web and the letter

C stand for Consortium. That is the main international standards organization for the

World Wide Web.

The W3C has helped me with the Web Design decisions and more specifically

how to increase the accessibility of the web system. Unfortunately, due to a huge and

unexpected cancellation, I did not have the chance to apply these standards.

ISO is another important international standards body and its abbreviation stands

for International Organization for Standardization. I have incorporated a fragment of the

standards introduced by ISO (see p. 12, p. 33 of the Report).

Throughout the project I have used extensively the UML (Unified Modelling

Language) standard for producing all of the project diagrams. “Unified Modelling

Language (UML) is now accepted as the standard object oriented modelling language.

It is intended to be a general-purpose language for software development. It is not meant

to be a complete language for modelling all aspects of all systems.” (OU, TM354, Unit

1, p. 50, 2016).

REVIEW & REFLECTION

This project contained exactly what I wanted to learn, and I also expanded my

knowledge beyond my expectations. Through practicing and experimenting with my day

job as a Scrum Master and the project taught me about how to manage myself first

before I communicate my ideas with others.

I firstly attempted to use a White Board (see Figure 1, Appendix19) for my project,

but I realised later that it consumes a lot of time needed for the project report

preparation. Also, it is a must within a team of developers for transparency and

communication purposes. I had to cut it off, because the owner did not have spare time

to communicate with me through this tool. As a single project carrier I did not find it to

be very useful as I have managed all the user stories electronically (Gantt Chart, Volere

snow cards, logbook, etc.)

The very useful communication with my tutor (see Appendix 10) have helped me

to understand what was needed from me in order to produce an acceptable project


Page 36 |117

report. I have to admit that my tutor was quite right about my ambitions towards the

project features, but luckily due to unforeseen circumstances, one third of the project

was cancelled and I learned my lesson from it.

The project was difficult and I did not expect to spend so much time dealing with

all the variation around the management. I needed to revise quite often as I felt like I

could do better than this. In my humble opinion, I could have not done the project in a

better way, because I have stretched myself to my maximum.


Page 37 |117

REFERENCES

Dawson, C. (2005) Projects in computing and information systems. Harlow, England, Addison-Wesley.

Holcombe, W. (2008) Running an agile software development project. Hoboken, NJ, Addison-Wesley.

Sabin-Wilson, L. (2013) WordPress all-in-one for dummies, Hoboken, NJ, John Wiley & Sons.

Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software Development Process, Upper Saddle River, NJ, Addison Wesley.

Schwaber, K. and Sutherland, J. (2011) The Scrum Guid. [online]. Available at http://www.scrumguides.org/scrum-guide.html (Accessed 16 April 2016).

Wikipedia (2016) WordPress [online]. Available at https://en.wikipedia.org/wiki/WordPress (Accessed 28 Jun 2016).

Legislation.gov.uk (2016) Equality Act 2010 [online]. Available at http://www.legislation.gov.uk/ukpga/2010/15/contents (Accessed 12 Jun 2016).

Wikipedia (2016) Content management system [online]. Available at https://en.wikipedia.org/wiki/Content_management_system (Accessed 25 Jun 2016).

Wikipedia (2016) Model–view–controller [online]. Available at https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller (Accessed 1 July 2016).


Page 38 |117

BIBLIOGRAPHY

Pichler, R. (2010) Agile product management with Scrum. Upper Saddle River, NJ, Addison-Wesley.

Crispin, L. and Gregory, J. (2009) Agile testing. Upper Saddle River, NJ, Addison-Wesley.

ISO. (2016). ISO/IEC 25010:2011 - Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models [online]. Available at http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733 (Accessed 15 Jun. 2016).

Anon, (2016). Reasoning About Software Quality Attributes [online]. Available at http://www.sei.cmu.edu/architecture/start/reasoning.cfm (Accessed 1 August 2016).


Page 39 |117

APPENDIX 1 – Use Case Diagrams

Figure 1 Use Case Diagram of SBS – Final version


Page 40 |117

Figure 2 Use Case Diagram of SBS – First Draft


Page 41 |117

APPENDIX 2 – Activity Diagrams

Figure 1 Add User Activity Diagram


Page 42 |117

Figure 2 Delete User Activity Diagram


Page 43 |117

Figure 3 Edit User Activity Diagram


Page 44 |117

Figure 4 User Log in Activity Diagram


Page 45 |117

Figure 5 User Log out Activity Diagram


Page 46 |117

Figure 6 User Explore SBS Activity Diagram


Page 47 |117

APPENDIX 3 – State Diagrams

Figure1 DB State Diagram


Page 48 |117

Figure 2 Authentication State Diagram


Page 49 |117

APPENDIX 4 – Architecture Diagrams

Figure 1 The classical waterfall model


Page 50 |117

Figure 2 Sprint visual representation


Page 51 |117

Figure 3 Architectural view of SBS


Page 52 |117

Figure 4 Deployment Model of SBS

Figure 5 Tween-Peaks model


Page 53 |117

APPENDIX 5 – Volere Template – First Version (Draft)

VOLERE TEMPLETE

Using the Volere Template is a good idea. It acts as a checklist to ensure that you have covered all the areas required. (Tutor comments in blue colour)

Product constraints

The purpose of the project.

A small Personal training company runs its business in the origin of London area. The owner has decided to adopt a new computer system to manage personal training bookings and being able to accept online payments for their services. Currently the company has no computerised methods of their operations. The new software should be able to carry out bookings, payments and displaying appropriate information to each individual member. The company also wants to offer an individual online personal training and personalised nutrition planning option. Thus expanding their services internationally. The owner wants to be able to sell these services online. The owner wants to expand the London’s Personal training by hiring more personal trainers and their individual portfolio must be visible to the browsers (potential clients) on the website. The system should incorporate a post page, thus the owner can capture the clients’ feedback about the quality of the services provided. That will help the owner to increase the efficiency of the company. Only members of the Sportbody’s website should be able to comment and/or leave a feedback.

The new system should provide the owner with the ability to add/remove members and also being able to control the content of the produced online system via the appropriate UI. The system must be fully operational and compatible with all electronic devices available on the market.

All problems listed above should be resolved via the desired system. The purpose of the system is to automate all the processes within the business.

The stakeholders.

The main stakeholders are the owner, trainers and the exercisers. The users of the system are potential clients interested in making changes in their current lifestyle, the owner and the trainers. We can suggest that none of the users of the system have any technical background and are not familiar with the technologies used.


Page 54 |117

Mandated constraints.

The system should be fully functional within five months. The system will integrate with an external payment system (PayPal). The website will be accessible and usable for all types of browsers. As a student project, I would not expect you to actually develop a working interface with an external payment system. You just need to indicate where you would plug such a system into your software product and possibly simulate its actions by displaying messages. Of course if you choose to integrate with PayPal then that is fine – your choice.

Naming conventions and terminology. None at present.

Relevant facts and assumptions. None at present.

Functional requirements I do not see what these extra headings are adding to your structure in the Volere Template.

The scope of the work. The new system will be developed for a Personal Training company. The system must run on all electronic devices. The system will operate online and will be responsible for taking care of the business within its London’s life events as well as its virtual training and nutrition planning Worldwide.

Business data model and data dictionary. Not yet considered.

The scope of the product. The new system will deal with only the Personal training stated earlier. The system’s interface will deal with the following:

the owner and browsers of the site will be able to create an account and being able to handle bookings

anyone using a web browser to view information and make bookings

owner adding or removing personal trainer’s profile

displaying the available dates and time

owner manages users of the services (adding or removing)

an external payment system to handle payments

Functional requirements. These seem very general.


Page 55 |117

FR1: The system shall keep track of all members, trainers and sessions

FR2: The system shall handle all bookings, cancellations, and ‘no shows’

FR3: The system shall sign up/register new members

FR4: The system shall log in/out current members

FR5: The system shall keep track of all current and past guests

Non-functional requirements - (constraints)

Look-and-feel requirements

LF1: The system shall make use of a Parallax type of opening front page followed by the appropriate full screen appearance of the subsequent pages

LF2: The system shall have simple to understand forms

LF3: The start page must contain a video presentation of the business

Usability and humanity requirements

U1: The system shall be easy to use for the owner and the browsers using the internet

Good affordability. Did not understand this extra heading

Performance requirements

P1: The system shall be able to handle a concurrent bookings and payments

P2: The system shall respond to a simple user interaction within 2 seconds

P3: The system shall respond to a complex user request within 8 seconds

P4: The system shall have high availability (99%)

Operational and environmental requirements

O1: The system shall operate from the owner’s portable computer and connected to a single central server


Page 56 |117

Maintainability and support requirements (Completely wrong – inadvertently confused by me)

M1: The system shall be able to add support for several European languages

M2: The system shall be able to support visually impaired people

Security requirements

S1: Only the owner shall be able to perform management/administration operations

S2: Credit/debit card details shall be securely managed by adding SSL to the site before checking out.

S3: Browsers shall be able only to browse, create an account and make or cancel reservations

S4: Information on which guests have been checked in or out shall not be alterable

Cultural requirements

C1: The system shall reflect on a homosexual-friendly policy included in the terms and conditions of Sportbody’s Personal Training. Are you trying to make the point that the product should not discriminate by sexual orientation? If so then that is good, but what about other forms of discrimination?

Legal requirements

L1: The system shall operate in accordance with European and local law I will be looking for information on actual legislation.

Natural precedence requirements – initiating stage (Team stories)

NP1: Initiating the server site of the MVC design pattern – back end of the system

NP2: Installing the bare bone WordPress package

NP3: Building a menu bar – the view of the system – frond end

NP4: Initiating the main pages of the system


Page 57 |117

APPENDIX 6 – Volere Template – Final Version

VOLERE TEMPLATE

The purpose of the project.

A small Personal training company runs its business in the origin of London area. The owner has decided to adopt a new computerised system to help with the management of their personal training bookings. Also the system should be able to accept online payments for their digitally oriented services.

Currently the company has no computerised methods of their operations. The new software system should be able to carry out bookings, payments and being able to display an appropriate information to each individual member. The company also wants to offer a bespoke online personal training and a personalised nutrition planning option dedicated to a specific client.

The owner wants to be able to sell these services online. The owner wants to expand the London’s Personal training by hiring more personal trainers and their individual portfolio must be visible to the browsers (potential clients) on the website. The system should incorporate a post page. This way the owner can capture the clients’ feedback about the quality of the services provided.

This will help the owner to increase the efficiency of the company. Only members of the Sportbody’s website should be able to comment and/or leave a feedback. The new system should provide the owner with the ability to add/remove members and also being able to control the content of the produced online system via the appropriate UI. The system must be fully operational and compatible with all electronic devices available on the market.

All problems listed above should be resolved through the intended system. The purpose of the system is to automate all the business processes wherever possible.

The stakeholders.

The main stakeholders are the owner, trainers and the exercisers. The users of the system are potential clients interested in making changes in their current lifestyle, the owner and the trainers. We can suggest that none of the users of the system have any technical background and are not familiar with the technologies used.


Page 58 |117

Mandated constraints.

The system should be fully functional within five months. The system will integrate with an external payment system (PayPal). The website will be accessible and usable for all types of browsers.

Naming conventions and terminology.

SB – Sportbody’s company brand

SBS – SportBody System name

Relevant facts and assumptions.

Because of the flexibility of WordPress, we assume that the system will be fully functional and operable on any type of electronic device capable of working with browsers.

The scope of the work.

The new system will be developed for a Personal Training company. The system must run on all electronic devices. The system will operate online and will be responsible for taking care of the business within its London’s life events as well as its virtual training and nutrition planning Worldwide.

Business data model and data dictionary.

Tabular relational database structure in a form of MySQL resides in a single dedicated server.

The scope of the product.

The new system shall operate within the Personal training only, stated earlier. The system’s interface will deal with the following:

the owner and browsers of the site will be able to create accounts and will be able to handle bookings

anyone using a web browser can view information and make bookings (registration required)

owner can add or removing personal trainer’s profile


Page 59 |117

displaying the available dates and time to users

owner manages users of the services (adding or removing)

an external payment system to handle payments

Functional requirements – (System functionality)

FR1: The system shall enable the owner to view all of the users

FR2: Handling bookings, cancellations, and ‘no shows’

FR3: Sign up/register new members

FR4: Log in/out members

FR5: Tracking current and past guests

FR6: Displaying available dates and time

FR7: Owner adding or removing personal trainer’s profile

FR8: Owner manages users of the services (adding or removing)

FR9: Handling payments via external payment system

FR:10 Importing/Exporting user’s data in CSV format

Narrative modelling of the functional requirements

All my User Cases are drawn-out from the revised use case diagram shown above

Legend:

M: Mandatory (compulsory requirement)

D: Desirable (requirement that the system should do)

O: Optional (requirement that the system may do)

?: Not defined yet – under consideration

Owner


Page 60 |117

UC №

Requirement Level

1 Owner can login to the SB M

2 Owner can add User (new Trainer, new Member)

M

3 Owner can edit User (new Trainer, new Member)

M

4 Owner can delete User (new Trainer, new Member)

M

5 Owner can view Members List M

6 Owner can edit/delete new Post (post must exist)

M

7 Owner can edit old Posts D

8 Owner can edit members’ profile (member profile must exist)

D

9 Owner can view all bookings D

Member

UC №

Requirement Level

10 Member can login to the SB M

11 Member can view/search for Services M

12 Member can register different level of membership

M

13 Member can create posts D

14 Member can access online shop ?

15 Member can book sessions with a specific Trainer (Trainer must exist)

D

16 Member can view/edit their profile D


Page 61 |117

17 Member can view their bookings D

Trainer

UC №

Requirement Level

18 Trainer can login to the SB M

19 Trainer can view their current bookings M

20 Trainer can edit their profile O

Visitor/Browser

UC №

Requirement Level

21 Visitor can explore the SB freely M

22 Visitor can register M

Non-functional requirements - (System constraints)


LF1: The system shall use Dynamique Parallax type slider for the opening page

LF2: The system shall comply with the three-tone brand design


U1: The system shall be easy to use for the owner and the browsers using the internet

U2: The system shall have simple to understand forms

Performance requirements

P1: The system shall be able to handle a concurrent bookings and payments


Page 62 |117


P3: The system shall respond to a complex user request within 8 seconds

P4: The system shall have high availability (99%)



Maintainability and support requirements

M1: The system shall have easy and simple to understand, well-balanced documentation

M2: The system shall be able to support a quick diagnose-fix problem


S1: Only the owner shall be able to perform management/administration operations

S2: Credit/debit card details shall be securely managed by adding SSL to the site before checking out.

S3: Browsers shall be able only to browse, create an account and make or cancel reservations

S4: Information on which guests have been checked in or out shall not be alterable


C1: The system shall reflect on a homosexual-friendly policy included in the terms and conditions of Sportbody’s Personal Training.

Legal requirements

L1: The system shall operate in accordance with European and local law – following Brexit – legislation unknown yet

Natural precedence requirements

NP1: Initiating the server site of the MVC + design pattern – back end of the system

NP2: Installing the bare bone WordPress package

NP3: Building a menu bar – the view of the system – frond end


Page 63 |117

NP4: Initiating the main pages of the system

APPENDIX 7 – FR & NFR with Fit Criterion

FR

SFR1: The system shall allow the owner to import or export users in CSV format

Fit Criterion: The system should be able to accept and record CSV data into the DB and being able to produce CSV file format from the DB

SFR2: The system shall enable the owner to view all users of SBS

Fit Criterion: The system should produce a list of all users SBS

SFR3: The system shall enable the users to search a content of SBS

Fit Criterion: The system should return a list with results starting with the user’s search criteria

SFR4: The system shall allow members to select and book only available sessions

Fit Criterion: The system should hide the unavailable dates and times

SFR5: The system shall allow members to view available training dates and times for bookings

Fit Criterion: The system should return a list of specific dates and times available for bookings

SFR6: The system shall allow users to select different languages

Fit Criterion: The system should return a translated version of SBS

SFR7: The system shall allow new users to register thus become members


Page 64 |117

Fit Criterion: The system should record new user in DB and inform the user upon request for registration

SFR8: The system shall require payment from user for two levels from the member area of SBS

Fit Criterion: The system should be able to communicate with external payment system and being able to return confirmation upon successful checkout

SFR9: The system shall allow members to login

Fit Criterion: The system should look up the provided username and password against the DB record and return a message if login unsuccessful

SFR10: The system shall allow members to make bookings

Fit Criterion: The system should display a selection of available dates back to members

NFR


LF1: The system shall use Dynamic Parallax type of slider for the opening page in compliance with the owner’s requirements with the given examples of their competitor’s sites operating in the same business area (Appendix I)

Fit criteria: The system should output the required slider at the entrance page of the SBS

Applies: To the Home Page only

LF2: The system shall comply with the three tone brand design

Fit criteria: All the content of the system should be displayed in red, black and dark silver on a white background

Applies: To all Pages


U1: The system shall users of SBS to register with minimum effort


Page 65 |117

Fit criteria: User registration process should not take more than 2 minutes

Applies: SFR7

U2: The system shall allow users of SBS to login fast

Fit criteria: Users should be able to login (entering the right username and password) into SBS for less than 20 seconds

Applies: SFR9

U3: The system shall allow members to make bookings easily

Fit criteria: Members should be able to book training sessions for less than 3 minutes

Applies: SFR10

U4: The system’s CMS shall be easy for use

Fit criteria: The owner should be able to import a list of users into the SBS DB through the CSM for less than 5 minutes

Applies: SFR1

U5: The system shall allow the owner to operate with the CSM easily

Fit criteria: Owner should be able to learn how to operate with the system in 1 hour

Applies: SFR1

Performance requirements – dependent on the speed of the Client’s respectively user’s interned connection and the Web host capability to transfer data client-server


Fit criteria: The system should be able to respond to more than 80 percent of users input within 2 seconds

Applies: SFR2, SFR3, SFR5, SFR6, SFR9

P2: The system shall have high availability


Page 66 |117

Fit criteria: The system should be available 99 percent of the 90 percent of the days of the year

Applies: All use cases



Fit criteria: Self-contained

Maintainability and support requirements

M1: The system shall have easy and simple to understand, well-balanced documentation

Fit criteria: The system should have all the use cases available, which provides the documentation in Agile practices


M2: The system shall be able to support a quick diagnose-fix problem

Fit criteria: The system should support a good level of traceability



S1: Only the owner will have the ability to amend the content of the SBS

Fit criteria: Less than 1 percent breach allowed into the system

S2: Only registered users shall be able to access the member area

Fit criteria: No more than one breach per year should be allowed

S3: System shall allow bookings to be made only by members

Fit criteria: No more than one breach should be allowed per year


Page 67 |117


C1: The system shall reflect on a sexual orientation - friendly policy of the SBS

Fit criteria: A policy, in compliance with the Equality Act 2010 (Legislation.gov.uk, 2016) should be included in the Terms & Conditions of SBS

C1: The system shall reflect on a disability - friendly policy of the SBS

Fit criteria: A policy, in compliance with the Equality Act 2010 should be included in the Terms & Conditions of SBS


C1: The system shall reflect on an age classification policy of the SBS

Fit criteria: A policy, in compliance with the Equality Act 2010 should be included in the Terms & Conditions of SBS


Legal requirements

L1: A Privacy policy or data protection notice must be displayed on the website

Fit criteria: SBS should display a discrete and also easy to spot privacy policy in compliance with the Data Protection Act 1988


L1: SBS must inform users that the company does not accept any liability that may arise from using the content of the web system

Fit criteria: SBS must have a Disclaimer document


Natural precedence requirements

All as previously stated in the Volere template (Appendix 4)

Portability


Page 68 |117

P2: The system should operate equally acceptable on any device which support Browsers

Fit criteria: The system should allow users to login among different devices for less than 20 seconds


APPENDIX 8 – Volere/Snow Cards

Complete set including old and newly emerged requirements


Page 69 |117


Page 70 |117


Page 71 |117


Page 72 |117


Page 73 |117


Page 74 |117


Page 75 |117


Page 76 |117

APPENDIX 9 – Use Case Examples

Use Cases of SBS

Use Case: #01 – Log In

Actors: Owner

Goal: To enter the SBS

Preconditions: Must be registered first & have an internet connection

Post conditions: The user/operator shall gain access to the SBS

Trigger: Owner needs to log in the SBS

Main successful scenario:

Locating the Log in field

Enter User Name & Password

Proceed further

Exceptions:

Unrecognised Username

Wrong Password

User is blocked

Priority: Mandatory

When Available: Sprint 05

Use Case: #02 – Add User

Actors: Owner

Goal: To add a new user

Preconditions:


Page 77 |117

Owner must have an internet connection

Must be logged in as an Owner

Available database would record new user

Post conditions: A new user should be recorded into the database

Trigger: Owner needs to add a new user

Main success scenario:

Owner visits the Log in field

Owner Logs in and being transferred to the CMS

From the dashboard clicks on Users button

Enters the data of the new user and confirms changes

Proceed to the next activity

Exceptions:

Rejection as the requested user already exists in the database

Priority: Mandatory


Use Case: #03 – Edit User

Actors: Owner

Goal: To edit user’s data

Preconditions:


The system must have the ability to update user’s profile

The Owner must be logged in

Post conditions: The owner should successfully edit the user’s profile

Trigger: Owner needs to edit user




Page 78 |117



Owner selects the user for editing

Owner edits the user details and confirm changes

Proceed to the next activity

Exceptions:

Requested user does not exist in the database

Priority: Mandatory


Use Case: #04 – Delete User

Actors: Owner

Goal: Delete a user

Preconditions:


The system must have the ability to remove user in the database

The Owner must be logged in

Post conditions: The Owner should successfully delete user





Owner select the user to be removed

Owner clicking the delete button and confirm changes

Proceed to desired activity

Exceptions:

Request rejected as the user does not exist in the database


Page 79 |117

Priority: Mandatory


Use Case: #05 – View/Search Services

Actors: Member

Goal: To view/search for Services

Preconditions:

The Member must have an internet connection

The Member must have browser installed

The system has been programmed for viewing/searching services

Post conditions: The member should successfully explore SB services

Trigger: Member needs to reach SB Services


Member selects SBS’s domain name

Member landed on the Home page

Member navigates through the navigation bar

Member proceeds to the next activity

Exceptions:

Site unreachable should the wrong name selected

Internet connection fails

Priority: Mandatory



Page 80 |117

APPENDIX 10 – Tutor/Student Collaboration

APPENDIX 11 – Risk Register

Legend of the Risk Register


Page 81 |117

Table 1: Probability rating

Table 2: Impact Rating

level Rating Range Description

1 Rare 65% to 99% Rare, but it could happen

2 Occasionally 34% to 64% Reasonable probability of occurring at some point

3 Certain 1% to 33% Will definitely occur most of the time

level Rating Range

1 Minor Low impact

2 Moderate Moderate impact

3 Extreme impact

level Rating

1-9 Acceptable

10-18 Attention & control required

19-27 Unacceptable

level Detecting

1 Easy

2 Difficult

3 Extremely difficult

Table 3: Detecting Rating Table 3: Risk Rating

Danail Chtipliev EMA C6279856

Page 82 |117

SBS’s Risk Register

Risk Scope Risk ID Risk description and consequences

P I D Ranking

P x I x D

Mitigating or avoiding action

Action by:

Developer #D1 Current project skill set may not be adequate to complete all the project work. The developer has not enough knowledge about the technology used.

1 3 1 3 Before engaging with the project careful analysis of skills was undertaken.

Developer (Danail)

#D2 The developer may not have the necessary management skills in order to manage the project at an appropriate level.

2 2 2 8 Specific measurements were taken when learning new managements skills and were carefully

Developer (Danail)

#D3 Non-practical experience of the chosen tools used in the project.

1 3 2 6 The developer’s experience was communicated with the client. An adequate level of experience was d t t d b f

Developer (Danail)

#D4 Non-adequate and random breaks from work during the project work.

1 3 1 3 Unpredictability of an inadequate break of work was unmeasurable attribute of the type of risk. Contract

ti ti

Developer (Danail)


Page 83 |117

Complexity of the project

#C1 Progress of project not monitored & measured with inadequate transparency.

2 2 3 12 Continuous log book maintenance & increasing the transparency via visual radiators (White bards, b d h t d

Developer (Danail)

#C2 All resources needed for the project are inadequately

estimated.

1 3 3 9 Careful estimation off all of the resources needed for the particular project.

Developer (Danail)

#C3 Non-systematic project planning.

2 2 2 8 Revising the study material from TM354 in order to maintain healthy project planning.

Developer (Danail)

#C4 Low-quality communication internally and externally.

1 3 1 3 Well preplanned with the client externally. Internally the communication with only

Developer (Danail)

Owner

#C5 The goals are not clearly defined.

2 3 2 12 Reassuring that the communicated information is correct via echoing the information back to the client by questioning

Developer (Danail)

Requirements #R1 Requirements are changing frequently.

3 3 3 27 Respond to change quickly and accordingly. Talk out-loud the requirements

Developer (Danail)

#R2 Wrong requirements. 3 3 3 27 Paying special attention on Inception phase of the requirements

Developer (Danail)


Page 84 |117

#R3 Ambiguous requirements. 1 2 3 6 Clarifying ambiguity with the client via continuous collaboration.

Developer (Danail)

Owner #R4 Too ambitious requirements. 2 2 2 8 Advise the client to

reconsider all the ambitious requirements either way of changing or

Developer (Danail)

Owner

#R5 Too complex requirements. 1 2 2 4 Decomposing the complexity into a rudimentary (simple)

Developer (Danail)

Users (Owner,

Members, Trainers)

#U1 Luck of cooperation of users. 1 3 2 12 All communication levels were negotiated and agreed early in development.

Developer (Danail)

#U2 Negative attitude towards the project.

1 2 2 4 Delivering prototypes more frequently. Engaging the users more effectively in the project

Developer (Danail)

System Environment

#O1 Politics with negative impact on project (Brexit).

2 2 3 12 Unexpected politics were minimized as the system will be dealing digitally only. Thus no special legal & political issues

Developer (Danail)

#O2 Reorganization in organizational management

during the project.

2 2 3 12 Has to be eliminated via strong agreement from both sides.

Developer (Danail)

Owner

#O3 Physical change in system operation.

1 2 3 6 Increasing the system mobility by considering the choice of the hardware and choosing

Developer (Danail)


Page 85 |117

APPENDIX 12 – Gantt Charts

Figure 1 Gantt Chart – Final Version


Page 86 |117

Figure 2 Gantt Chart – The First Release – example


Page 87 |117

APPENDIX 13 – Logbook Excerpt

Table 1 - Project Logbook – Revised

DATE & TIME

DURATION OBJECTIVE OUTCOME LESSONS LEARNED SUGGESTED OBJECTIVE FOR NEXT SESSION

01/05/16 – 12:30pm

3h Planning and preparing for the implementation of the authentication part of the

system

Objective achieved I needed to revise my planning skills as I did not feel very confident that I follow a

structured way of planning

Investigating of all of the options and capabilities of WordPress’ plug ins in

regards with the Log in/out functionality of SBS

05/05/16 – 07:15pm

3h Designing and implementing the agreed plug in

Objective achieved. I spent more time than expected as the new plug in was

difficult to embed.

I had to revise the plug in’s code ad twist it appropriately

Setting up test cases for the authentication

11/05/16 – 02:30pm

4h Thorough tests of the chosen plugin. System tests and acceptance tests of SBS

Objective achieved. All tests passed all planned. The only problem I faced was the owner’s delay in acceptance

tests, but at the end all went well

NONE Preparation and preplanning of Release II

12/05/16 – 10:00am

3h Planning Release II Objective achieved NONE Planning Sprint_06

13/05/16 – 09:10am

1.5h Planning Sprint 06 Objective achieved NONE Implementing the restriction of the membership levels

29/05/16 – 03:00pm

3h Working with layers of security

Hit problem with the owner’s acceptance of dividing the levels of

security

Had to spend more time in live collaboration with the owner

Working on adding extra levels of security

20/07/16 – 05:30pm

1h Working on SBS’s accessibility features

Hit problem with the client. She wanted to remove those features from

the project

New negotiations were undertaken, which expanded

the length of the foreseen time box

Deployment

26/07/16 – 02:00pm

5h Planning Sprint_13 All the features till the end of the project were cancelled by the owner.

It helped me to withstand partial cancellations of the

system’s features

No further work needed from the client side and the developer’s side


Page 88 |117

Log 1 – Deciding on SDLC

Log 2 – Initial meeting with the owner

Log 3 – Shopping card decision making

N WHAT I DID PROBLEMS DATE TIME

1 Today I have started to create my own vision and choosing the right strategy for my project work.

I found it difficult finding the right path and concepts needed for the start of my project.

This part of the project journey I guess would be one of the most challenging parts of the entire project.

March 16 3h


9 Today I was working on preparing the business

requirements. I have chosen my wife to represent the

personal training business owner. We had a conversation

about her’ business needs and it took a little bit longer

than I have expected.

Again I could have spent less time interviewing her as

I need it less requirements in order for me to start on

the project.

March 23 2h


4 Today I had a conversation with the owner and it did ask

me for a little postpone as they are not so sure about the

incorporating of the shop system

NONE May 4 1h


Page 89 |117

Log 4 – Log in/out testing

Log 5 – Acceptance tests

Log 6 – Acceptance tests


8 Today I was testing the log in/out system NONE May 8 2h


4 Today I have managed to complete all the previous tasks

on time. I am planning to start tomorrow tests, which

would include black box tests as well as acceptance tests

NONE May 27 2h


5 All tests went as planned. I did thorough testing and

adjustments on the membership levels against all the

customer’s critical criteria’s.

NONE May 28 2h


Page 90 |117

Log 7 Log in/out tests

Log 8 PayPal new feature request

Log 9 PayPal tests and SBS tests


8 Today I carried out more work on the authentication’ part

of the system. Today I also spent some time talking with

the client. It was helpful conversation as I did some

acceptance tests and I needed some feedback from the

owner. I found out that I am on the right track with the

project.

What was not so great about was the slight negatives

about the look and feel of the Log in/out pages, but I

actually did not put loads of effort there

May 31 3h


9 Today I had an interesting conversation with the client.

They wanted a new functionality added to the system. NONE June 1 1h


14 Today I was predominantly testing the robustness of the

PayPal Integration and I have tested the entire system. All

went as planned.

NONE June 6 2h


Page 91 |117

APPENDIX 14 – Quality Attributes Scenarios - examples

Part of scenario Type of value Actual value

Source End Users Internet Browsers/Users

Stimulus User wats to – feel comfortable Avoid complexity & use easy to navigate UI design

Artefact System SBS

Environment Normal SBS and Internet connection working normally

Response Making the user Comfortable Clearly specified exit/back buttons

Response measure User Satisfaction Implementing a live chat window that would support direct feedback from the users

Table 1 Usability scenario – example


Page 92 |117

Part of scenario Type of value Actual value

Source End Users Internet Browsers/Users

Stimulus Stochastic event Registration request

Artefact System SBS

Environment Normal SBS and Internet connection working normally

Response Process stimuli Filling up credentials & system synchronizing the DB

Response measure Latency Registration completed and a message is displayed to the user within 2 minutes. (Human factor plays role in speed measurement)

Table 2 Performance scenario – example


Page 93 |117

APPENDIX 15 – SBS Quality / Acceptance Tests & Validations

Figure 1 Testing membership level registration – Shoot 1 - Passed successfully


Page 94 |117

Figure 2 Testing membership level registration – Shoot 2 - Passed successfully


Page 95 |117

Figure 3 Membership level registration form fields validation – Shoot 3 - Passed successfully


Page 96 |117

Figure 4 Testing Third party payment system - Passed successfully


Page 97 |117

Figure 5 Testing member’s booking check out – Shoot 1 – Passed successfully


Page 98 |117

Figure 6 Validating SBS’s Contact form – Non-successful scenario


Page 99 |117

Figure 7 Validating SBS’s Contact form – Successful scenario – Part 1


Page 100 |117

Figure 7 Validating SBS’s Contact form – Successful scenario – Part 2

User’s email confirmation of success

Figure 8 – Testing the responsiveness of SBS


Page 101 |117

Figure 9 – SBS DB Test for writing on


Page 102 |117

Figure 10 – SBS DB Test for writing on – successful


Page 103 |117

Figure 10 – SBS / EXPLORER Browser Compatibility test


Page 104 |117

Figure 11– SBS / OPERA Browser Compatibility test


Page 105 |117

Figure 12 – SBS / SAFARY Browser Compatibility test


Page 106 |117

APPENDIX 16 – UI & Examples of Practical Work – NFR Implementing

Figure1 The first prototype of SBS’s UI


Page 107 |117

Figure 2 SBS Logo design


Page 108 |117

Figure 3 Logo embedded


Page 109 |117

Figure 4 SBS opening front page – Acceptance test passed successfully


Page 110 |117

Figure 5 SBS Video representation – front page – Acceptance test passed successfully


Page 111 |117

Figure 6 SBS domain name registration


Page 112 |117

Figure 7 WordPress installation process


Page 113 |117

Figure 8 Using of Photoshop for the graphical design


Page 114 |117

APPENDIX 17 – Client / Developer collaboration example

EXAMPLE OF AN INTERVIEW / ELICITING REQUIREMENTS

Developer: Hello, Vesi. The developer of your web system is here.

Owner: Hi. How are you? Is everything going as planned?

Developer: Thanks Vesi, I am fine. Hope you are doing well too. Well, I am calling you, because I am doing some acceptance testing on the Log in/out system and I would need some feedback from you before the actual implementation would take place.

Owner: Sure! I am listening. How may I be of any help in this situation?

Developer: I have actually attempted to prototype the Log in functionality of the system in live. Would you please be able to open the site and have a little play with the log in system, which is attached to the menu under Log in/Register buttons?

Owner: Yes, I have some time right now and I will try it.

Developer: Prospective users will be able to register if they wish to become members. I would like to know how you would perceive the log in functionality from its look and feel perspective and from the usability perspective too.

More specifically, I would like to measure the usability of that bit of the system i.e. how easy is for you to understand how the Log in/Register operates. The rudimentary approach I have taken, while building the authentication functionality of the system, will help the users to fulfil tasks with ease.

From my tests the user should be able to create an account for up to 2 minutes. Retrieving lost password will be attainable for up to 2 minutes too. The buttons, log in/log out will operate within 5 seconds of pressing. Please let me know if that is the case with you.

Owner: Well, according to what you have requested it seems that that is exactly what I wanted. I wanted something simple, but at the same time functional.

Developer: Superb! I am glad that the requested business functionality has been achieved at a standard level. I would like to measure how you would also accept the colors and how you feel about the pages containing all the login operations.

Let’s set up a hypothetical scale that would help us measure that functionality. From 0 to 10 where 0 is an extreme dislike and the 10 is the maximum like. On that scale I would like to know where do you think roughly you are most likely to place your perceptions about the feel of the login system are.


Page 115 |117

Owner: Oo.. that is really kind of you asking me about the design of the pages too. I did look at the requested pages and I think I would like to discuss in more details that part of the development, because I would probably put myself at somewhere about 5 on the proposed scale.

Developer: Glad to hear from you Vesi and I will give you a ring soon again to discuss this matter. For now, good bye and thanks for your time.

Owner: Perfect! It was a pleasure seeing the progress of the product. Speak to you soon. Buy.


Page 116 |117

APPENDIX 18 – SBS’s Competitors activities compared

Figure 1 – Screenshots of SBS’s competitors in business


Page 117 |117

APPENDIX 19 – White Board

Figure 1 SBS White board – working example

software development

Documents