group project report

Web App – Model of a Driving Course test using Four Stroke IC Engine | Group D
Page | 0
WEB APP – MODEL OF
A DRIVING COURSE
TEST USING FOUR
STROKE IC ENGINE
GROUP SOFTWARE
DEVELOPMENT PROJECT
UFCFED-30-M
WEB APP - MODEL OF A
DRIVING COURSE TEST
USING FOUR STROKE IC
ENGINE
Andrew Breeze, Abbas Hamza, An Huynh,
Francis Fafowora, Marcus Griffiths & Vy
Quoc Tran.
Group D

Page | 1
Acknowledgement
This project consumed huge amount of work, research and dedication. Still, implementation would
not have been possible if we did not have a support of our two module leaders: Dr Emmanuel
Ogunshile and Benedict Gaster. Therefore we would like to extend our sincere gratitude to them.
First of all we are thankful to Dr Emmanuel Ogunshile for his suggestion of the project idea, as well
as all the necessary guidance and feedback concerning the projects implementation.
We are also grateful to Benedict Gaster for his expertise, and technical support in the
implementation. Without his knowledge and experience, the Project would be lower in quality of
outcomes, and thus his support has been essential.
We would like to express our sincere thanks towards volunteer users who devoted their time and
knowledge in the implementation of this project.
Nevertheless, we express our gratitude toward our families and colleagues for their kind co-
operation and encouragement which help us in completion of this project.

Page | 2
Contents
Acknowledgement...................................................................................................................................1
Tables......................................................................................................................................................4
1. Introduction .....................................................................................................................................5
Background...................................................................................................................................................... 5
The Problem .................................................................................................................................................... 5
The Solution..................................................................................................................................................... 5
Our product ................................................................................................................................................. 5
Objective...................................................................................................................................................... 5
Aim............................................................................................................................................................... 5
2. Product Backlog................................................................................................................................6
2.1 Product Backlog......................................................................................................................................... 6
2.2 Evidence of Management.......................................................................................................................... 7
Sprint 1 – Design week ................................................................................................................................ 7
Sprint 2 – Coding week................................................................................................................................ 7
Sprint 3 – Final touch................................................................................................................................... 7
3. Iteration Plan.....................................................................................................................................8
3.1 Scrum Agile Method.................................................................................................................................. 8
3.2 Work Breakdown Structure – Activities List............................................................................................... 8
3.3 Precedence Diagram................................................................................................................................ 10
3.4 Gantt chart............................................................................................................................................... 11
3.5 Tasks Distribution..................................................................................................................................... 12
3.6 Quality Control Plan................................................................................................................................. 13
3.7 Quality Assurance Plan............................................................................................................................. 14
4. Risk Register................................................................................................................................... 15
4.1 Risk Register Table................................................................................................................................... 15
4.2 Risk Control Record ................................................................................................................................. 18
4.3 Comment on Risk Management.............................................................................................................. 19
5. Design Documentation ................................................................................................................... 20
5.1 Introduction............................................................................................................................................. 20
a. Purpose.................................................................................................................................................. 20
b. Scope ..................................................................................................................................................... 20
5.2 Definitions and Abbreviations................................................................................................................. 20
5.3 Overview.................................................................................................................................................. 20
5.4 Technologies Used................................................................................................................................... 21
5.5 AmChart................................................................................................................................................... 21
5.6 Application Overview .............................................................................................................................. 21

Page | 3
5.7 Architectural Representation.................................................................................................................. 22
5.8 Architectural Goal and Constraints. ........................................................................................................ 22
5.9 System Input Description ........................................................................................................................ 22
a. Track details........................................................................................................................................... 22
b. Driver Details......................................................................................................................................... 23
c. Vehicle detail.......................................................................................................................................... 23
d. Vehicle acceleration details................................................................................................................... 23
5.10 Front End Modules................................................................................................................................ 24
a. App..................................................................................................................................................... 24
b. Form .................................................................................................................................................. 24
c. Result................................................................................................................................................. 24
6. Source Code ................................................................................................................................... 24
7. Run Book........................................................................................................................................ 25
7.1 Technical Details...................................................................................................................................... 25
d. Front End ........................................................................................................................................... 25
e. Back End ............................................................................................................................................ 25
7.2 Build and Run........................................................................................................................................... 25
8. Limitation and Enhancement .......................................................................................................... 29
8.1 The algorithm for calculation .................................................................................................................. 29
8.2 Coding...................................................................................................................................................... 29
8.3 Security.................................................................................................................................................... 30
8.4 Database.................................................................................................................................................. 30
8.5 User Interface.......................................................................................................................................... 30
9. Group Assessment.......................................................................................................................... 31
9.1 Strength................................................................................................................................................... 31
a. Team members with a wide combination of IT technical skills and experiences: ................................ 31
b. The use of PbWorks and Bitbucket: ...................................................................................................... 31
9.2 Weakness................................................................................................................................................. 31
a. Team members cannot provide full commitment to the project plan: ................................................ 31
b. The lack of direct communication......................................................................................................... 32
c. Difficulty in combine team member’s skills........................................................................................... 32
9.3 Solution for improvement....................................................................................................................... 32
a. Carefully planning of time and project objective: ................................................................................. 32
b. Encourage further communication outside team meetings: ................................................................ 32
c. Testing the combination of the team member’s skills: ......................................................................... 33
9.4 The Development Process....................................................................................................................... 33
a. Time issues............................................................................................................................................. 33
b. High Requirement objective.................................................................................................................. 33

Page | 4
c. The need of a team leader..................................................................................................................... 33
d. Lacking of Learning and Training time................................................................................................... 33
9.5 Recommendation .................................................................................................................................... 34
a. Agile Vs Waterfall .................................................................................................................................. 34
b. Using of Bitbucket, PbWorks or others free project management/group-work tools. ........................ 34
Reference .............................................................................................................................................. 35
Tables
Table 1.Product Backlog...................................................................................................................................... 6
Table 2.Product Backlog - Evidence of Management.......................................................................................... 7
Table 3. Activities List.......................................................................................................................................... 9
Table 4. Gantt chart........................................................................................................................................... 11
Table 5. Tasks Distribution ................................................................................................................................ 13
Table 6. Quality Control Plan............................................................................................................................. 13
Table 7. Quality Assurance Plan ........................................................................................................................ 14
Table 8. Test Deployment.................................................................................................................................. 14
Table 9. Risk Register......................................................................................................................................... 17
Table10. Risk Control Record ............................................................................................................................ 18
Table 11. Agile Vs Waterfall............................................................................................................................... 34

Page | 5
1. Introduction
Background
Vehicle production is becoming increasingly more complex. This is especially true with premium vehicles as
they become heavily customized to meet the demands of customers. Reducing the production time and the
need to build costly prototypes in the initial stages of design is increasingly of concern to manufacturers
(Petter, 2013; Savail et al., 2002; Kulkarni et al., 2011).
Digital processes can assist the manufacturing of vehicles, one way is through modelling and simulation.
Design and analysis of vehicles and their properties can be done through modelling the aspects of a vehicle
and simulating them in virtual test environments (Kulkarni et al., 2011). This means that the specifications of
the vehicle can be tested and adjusted virtually before it is built (Son et al., 2001; McLeod, 2001).
The Problem
Due to the inherent complexity in designing and manufacturing a modern vehicle the manufacturing process
needs to be re-evaluated. Time and costs are becoming more important to cut down during this process, so
getting things right the first time is important (Savail et al., 2002).
On top of this the amount of greenhouse gases a vehicle produces during its operation should be monitored
and mitigated. This helps vehicle manufacturers to do their part in reducing the amount of harmful chemicals
they release into the atmosphere as well as keep within strict government legislation (European Commission,
2015).
Testing vehicles through prototyping is costly and takes time. A way of making this process partially digital
would mean that all these factors would be greatly reduced.
The Solution
Our product
Web App - Model of a Driving Course Test using Four Stroke IC Engine
Objective
 Produce a platform independent program that will compute various outputs of a vehicle to enable the
user to analyse and adjust factors that will lead to reducing engine emissions.
 Design a track with 2 types of tiles: one is longitudinal and the other is curved to represent the track
for our vehicle.
 Create an algorithm based on fuel use, speed, acceleration and deceleration of a vehicle at different
RPM in different gears. Include a virtual driver of the vehicle and their characteristics.
 Create a web app that will take input to be used in the algorithm.
 Create a database to be used to store data entered through the web app user interface (form).
 Produce graphs that will show CO2 consumption and various other relevant data for a vehicle at
various locations of the track as well as cumulatively.
Aim
The aim is to analyse and control the CO2 emissions produced by a vehicle under certain circumstances such
as whether the road surface is longitudinal or curved, the vehicle engine RPM, the speed of the vehicle, the
location of the vehicle at any point on the track and the driver’s behaviour i.e. gear change and braking.
This contributes to the manufacturing and modelling of a vehicle in the early stages, which can increase
efficiency, save time and cost during the manufacturing process.

Page | 6
2. Product Backlog
2.1 Product Backlog
The priorities are marked from No.1 to No.7 with No.1 is the most important feature and No.9 is the least
important one.
In this product backlog, the first three features are the core value of this web-app. The team expected to spend
most of the effort to working in these three features. The remaining features will be expand if the team has
enough time.
However, by the end of the project, we had not completed features No.5, No.6 and No.7.
Priority Feature Why Comment
1
User can see the results of the
test: emission, fuel use, gear,
rpm, speed, time and position
The user can see the result of their input.
This is the objective of this
product: showing the
calculation result of the users
testing's input.
2
User can customize the testing.
The inputs are divides into
three groups: Track type,
Vehicle type and Driver habit.
This feature allows the users to customize and
test in many different situation.
This is the mos importeant
feature: it allows the users the
freedom to customize their test
as required.
3
User can see a graph and
animation that describe the
position, and output result as a
specific testing time.
The user can visualize the movement of the
car as well as the changing in theoutput over
time
The users can really see what
happens what is changed over
time: the car's position, the
emission, fuel use, spedd,
rpm,… in a specific time.
4
User can put multiple input
form as they want
User can test as many as they want and reduce
the time of reload the web-app.
All the input of one the tester
will be saved in the data base
and used for the calculation
output for.
5
User can compare the different
of the testing output in the
same page.
User can compare different result with each
different input and improve the analysis
performance.
For tester's analysis purpose,
not completed
6
User can save and print out the
result
user can keep record of the test. Not completed
7
This Webb-app can be used in
mobile device
Extend the ability of using the app Not completed
PRODCT BACKLOG
Table 1.Product Backlog

Page | 7
2.2 Evidence of Management
Sprint 1 – Design week
In Sprint 1, the team focus mainly on the design of the input form, the algorithm for calculation and the
database. We decided the language that will be used for the coding part as well as how to link all the coding
part together. Plus, we also begin the designing of the user interface. A wireframe of the web-app has been
selected. The wireframe was divided into two main parts: the input form page and the result’s output page.
Sprint 2 – Coding week
These three weeks are coding weeks. Sprint 2 required the most working effort of our team. Both front-end
and back-end team focused on coding their parts. While the front-end team began to coding for the input
forms using HTML and CSS, the back-end team worked on the coding of database and algorithm. Moreover,
the team began to teste the coding for the graph and animation engine for the output result page.
Sprint 3 – Final touch
In this final sprint, both front-end and back-end team begin to combine their coding parts together. The first
task is to test the how the web-app runs from the input forms, to the database and through the algorithm to
calculate the result. The second important task of this sprint is to begin the coding of the output result page
using the results that were calculated by the algorithm code. We also try to work on the others minor
features of the product.
Description Sprint 1 2 3
70 95 90
1 25 35 20 80
2 25 30 10 65
3 10 10 40 60
4 10 20 0 30
5 0 0 10 10
6 0 0 5 5
7 0 0 5 5
255
Product Backlog - Evidence of management
Working hours
Priority
User can customize the testing. The inputs are divides
into three groups: Track type, Vehicle type and Driver
habit.
User can see the results of the test: emission, fuel use,
gear, rpm, speed, time and position
Total
User can compare the different of the testing output in
the same page.
User can save and print out the result
This Webb-app can be used in mobile device
Total
hours
User can see a graph and animation that describe the
position, and output result as a specific testing time.
User can put multiple input form as they want
Table 2.Product Backlog - Evidence of Management

Page | 8
3. Iteration Plan
3.1 Scrum Agile Method
The project management technique we have chosen to use is Scrum. As the most common agile approach,
Scrum has a proven track record of success (Scrum Alliance, 2013). An iterative, agile approach has been
shown to improve the likelihood of success in a project, and Scrum is ideal for highly collaborative small teams
such as this (Goldstein, 2013).
An agile approach welcomes changes to requirements and reduces the risks that are inherent in volatile
situations as the final approach is likely to change throughout the project life cycle so using this approach will
mitigate the risks involved. (The Standish Group, 2014)
The team will work though collaboration online and meet at least twice weekly to discuss each person’s
progress and keep track of the project. Sprints will last 2 weeks and will contain enough work for each team
member to contribute 20hrs.
Each sprint will consist of a design phase, an implementation phase and a testing phase. These will also be
divided between the front end and back-end teams. In the beginning of each sprint, both teams will commence
at the same time. Then the work of each team will be combined together for testing. For each task, we will
have team member to take charge and report the process weekly. Finally, at the end of the sprint we will
evaluate the whole process and request feedback from project owner before beginning for a new sprint.
We will use MoSCoW to ensure that priorities are being identified and met, and the use of scrum meetings
will facilitate as any problems should be identified early by the scrum master.
3.2 Work Breakdown Structure – Activities List
Note:
• UI: User interface
• P&B: Program & Database
• S: System
Sprint No Serial Task Description Dependency
Duration
(W)
Beginning
week
1
RE Design
Requirement,
Project proposal
& Project plan
Decide on the topic
Design Requirement
Design Project plan
Project proposal
None 2
1
2
S1.UI.D UI Design • Create design documentation
• Create initial user interface
structure
• Create selection of UI wireframes
• Choose wireframe to continue
forward
RE 0.5
3 S1.UI.I UI Implement • Code static app pages with forms S1.UI.D 1
4 S1.UI.T UI Test • Test forms S1.UI.I 0.5
5
S1.PD.D P&D Design • Create design documentation
• Design database schema
• Design algorithm
RE 0.5
6
S1.PD.I P&D Implement • Create database
• Connect database to UI
S1.PD.D 1
7
S1.PD.T P&D Test • Test database
• Test algorithm
S1.PD.I 0.5

Page | 9
8
S1.S.I System
Implement
• Commit the UI and Database S1.PD.T
S1.UI.T
0.5
9 S1.S.T System Test • Test Form and database S1.S.I 0.25
10
S1.S.E System
Evaluation
• Check progress
• Changes to next sprint
• Update all documentation
S1.S.T 0.25
2
11
S2.UI.D UI Design • Design form validation plan
• Design track visuals
• Design charts
S1.S.E 0.5
12
S2.UI.I UI Implement • Implement validation to form
• Implement track visuals and
interaction with form
• Create charts
S2.UI.D 1
13
S3.UI.T UI test • Test validation of forms
• Test track creation
• Test charts with files
S2.UI.I 0.5
14 S2.PD.D P&D Design Finalise database model S1.S.E 0.5
15
S2.PD.I P&D Implement • Code algorithm
• Connect algorithm and database
• Connect UI to program
S2.PD.D 1
16 S2.PD.T P&D Test Test algorithm S2.PD.I 0.5
17
S2.S.I System
Implement
Commit UI, database and program S2.UI.T
S2.PD.T
0.5
18
S2.S.T System test • Test UI and database
• Test database and program
S2.S.I 0.25
19
S2.S.E System
Evaluation
• Check progress
• Changes to next sprint
• Update all documentation
S2.S.T 0.25
3
20
S3.UI.D UI design Interactivity between track and
charts
S2.S.E 0.5
21 S3.UI.I UI implement Code interactivity S3.UI.D 1
22 S3.UI.T UI test Test chart and track interaction S3.UI.I 0.5
23 S3.PD.D P&D design Design file format for front end S2.S.E 0.5
24 S3.PD.I P&D implement Create file builder S3.PD.D 1
25 S3.PD.T P&D test Test file builder S3.UI.I 0.5
26
S3.S.I System
implement
Commit all source code to
repository
S3.UI.T
S3.PD.T
0.5
27
S3.S.T System test • Test file with UI
• Test entire app
S3.S.I 0.25
28
S3.S.E System
evaluation
• Group evaluation of entire
project
• Changes and Limitations
S3.S.T 0.25
FINISH 29
F4 DELIVER
PRODUCT
Finish group report
Finish individual report
S3.S.E 2
Table 3. Activities List

Page | 10
3.3 Precedence Diagram
1 RE
2
2 S1.UI.D 3 S1.UI.I 4 S1.UI.T
0.5 1 0.5 8 S1.S.I
5 S1.PD.D 6 S1.PD.I 7 S1.PD.T 0.5
0.5 1 0.5
10 S1.S.E 9 S1.S.T
0.25 0.25
11 S2.UI.D 12 S2.UI.I 13 S2.UI.T
0.5 1 0.5 17 S2.S.I
14 S2.PD.D 15 S2.PD.I 16 S2.PD.T 0.5
0.5 1 0.5
19 S2.S.E 18 S2.S.T
0.25 0.25
20 S3.UI.D 21 S3.UI.I 22 S3.UI.T
0.5 1 0.5 26 S3.S.I
23 S3.PD.D 24 S3.PD.I 25 S3.PD.T 0.5
0.5 1 0.5
28 S3.S.E 27 S3.S.T
0.25 0.25
29 F4
2
design project requirement,
project proposal & project
plan
check progress & update
documentation
test form & database
BEGINNINGWEEKSPRINT1
test form
Create webserver, database &
connect to user interface
test database & algorithm
Commit user interface &
database
Design user interface
structure, wireframe &
documentation
Design database, algorithm &
documentation
Code static app pages with
forms
test vaidation, track visual &
chart
commit user interface,
database & program
finalize database model
code algorithm, connect
algorithm to database & user
interface to program
test algorithm and database
test file builder
group evaluation of the whole
project, update all
documentation, change &
limitation
test file with user interface &
tes the entire web app
Finish group & individual
report
check progess & update
documentation
test user interface, daabase &
program
interactive between track &
chart
code interactivity test chart & track interactive
commit all source code to
repository
SPRINT2SPRINT3FINISH
design file format for front-
end
create file builder
design form validation plan,
track visual & chart
implement validation & track
visual to form, create chart
Figure 1. Precedence Diagram

Web App – Model of a Driving Course test using Four Stroke IC Engine
Page | 11
3.4 Gantt chart
Task Name Duration Start End
Begin 1.0 Design Requirement, Project Proposal& project plan 2 W1 W2
2.0 User Interface Design 0.5
3.0 User Interface Implement 1
4.0 User Interface Test 0.5
5.0 P&G Design 0.5
6.0 P&G Implement 1
7.0 P&G Test 0.5
8.0 SystemImplement 0.5
9.0 SystemTest 0.25
10.0 SystemEvaluation 0.25
11.0 UI Design 0.5
12.0 UI Implement 1
13.0 UI Test 0.5
14.0 P&D Design 0.5
15.0 P&G Implement 1
16.0 P&D Test 0.5
18.0 SystemTest 0.25
20.0 UI Design 0.5
21.0 UI Implement 1
22.0 UI Test 0.5
23.0 P&D Design 0.5
24.0 P&D Implement 1
25.0 P&D Test 0.5
27.0 SystemTest 0.25
Finish 29.0 Delivery Project 2 W12 W13
W8 W8
W5 W5
Week 8
SPRINT 2
SPRINT 3
Week 1 Week 2 Week 3
W6 W7
Week 11 Week 12 Week 13Week 4 Week 5 Week 6 Week 7
W9 W10
W11 W11
Project plan - Gantt Chart
Week 10Week 9
SPRINT 1
W3 W4
Table 4. Gantt chart

Page | 12
3.5 Tasks Distribution
Sprint
Week
(date)
Task
no.
Task Description
Time
(hr)
Tasks Distribution
Back-end Front-end Res
Andy Abba An Marc Fran Vy
Begin
3 Feb – 15
Feb
0 Design Requirement,
Project proposal &
Project plan
Decide on the topic
Design Requirement
Design Project plan
Project proposal
20
X X X X X
1
16 Feb - 8
Mar
1 Complete business
case and project plan
Finish project plan and produce in depth documentation to
feed back to supervisor
20
X X
2 Create database and
tables with test data
Database to be developed based on class diagrams and test
data included
15
X X
3 Confirm graphical
output method and
user interface
User interface open source technologies investigation to be
completed and a recommended to which open source chart
library is to be used
10
X X X
4 Create algorithm Create the algorithm as a flow chart that can be followed by
programmers. To be manually tested to ensure logical flow is
correct
10
X X
5 Develop local
production
environment
Create source controlled collaborative environment to enable
effective working
5
X
6 Create web server To host user interface (additional time added due to lack of
expertise)
10
X X
2
9 Mar - 29
Mar
7 Create user interface Create a user interface and link to the database. Testing against
WAI-ARIA standards
20
X X X
8 Create algorithm Algorithm to be converted from a specification to code. To be
tested against manually produced output created in first sprint
20
X X
9 Create graphical
outputs
Source chart library to be incorporated. Testing against WAI-
ARIA standards
15
X X X
10 Respond to supervisor
feedback
Project plans to have been shown to supervisor – feedback to
be incorporated at this stage
10
X
11 Host on web server Place user interface and graphical outputs on web server 15 X X

Page | 13
Sprint
Week
(date)
Task
no.
Task Description
Time
(hr)
Tasks Distribution
Back-end Front-end Res
Andy Abba An Marc Fran Vy
3
30 Mar - 19
April
12 Develop user manual Develop user manual to describe in detail the algorithm, the
user interface and possible direct access (avoiding the GUI)
15
X X X X X
13 Systems testing Ensure all entities communicate fully. Test against quality
standards.
20
X X X X X
14 User testing Get feedback from user uninvolved in production. Incorporate
suggested changes where practicable
20
X
15 Supervisor feedback Get feedback from supervisor 20 X X X X X X
4
20 April -
1 May
(Deadline)
16 Incorporate supervisor
feedback
Incorporate supervisor feedback on the entire system. Seek
additional feedback until no further iterations are possible.
Finish the project report.
30
X X X X X X
17 Delivery of the project X X X X X X
TOTAL WORKING HOUR 275
Table 5. Tasks Distribution
3.6 Quality Control Plan
Features Description
Product Web app
Deliverability 1 May 2015
Compatibility Will ensure compatibility on these web browser: IE, Firefox, Chrome, Safari
running Mac OS, MS Windows.
Accessibility Correct accessibility guidelines according to WAI-ARIA.
User interface Navigation will be done in a consistent fashion through the Web app
Connecting Internet connection required
Connection speed Will load in under 3s for 10 users on a 1mb/s connection
User Security No user security consideration
Table 6. Quality Control Plan

Page | 14
3.7 Quality Assurance Plan
No.
Testing
object
Tester Activities Duration Cycle
1. Supervisor
feedback
Emmanuel -
owners
Receive feedback and direction from
Emmanuel.
Analysis and modify the development
process
1 day Once
every 3
weeks
2. Technical
test
Team
member
Presentation
Process report
Unit testing
Feedback from others members.
Detect and fix bug or program error.
Analysis, and conduct a solution/upgrade if
possible.
1 day weekly
3. Process
combination
analysis
Team
member
Combination from different tasks.
Unit testing
System testing
Testing, analysis and receive feedback from
every team members.
Gain a mutual approve between members
before process the next sprint.
2 day At the end
of each
Sprint
4. Reserve
week
Team
member
Using this week to solve any problem/error
or make any upgrade/further development
for the product,
1 week For each
sprint
5. Product test Team
member
System testing.
Final team sign off for the product again
quality requirement.
1 day At the end
of Sprint 3
6. User test Random
users
Choosing random user for testing
Take feedback
Analysis, fixing or upgrade
1 week Two week
before
deadline
7. Final
product test
Emmanuel
&
Team
members
Delivery the final product for the project
owner.
Final check for the final product.
Writing analysis and final report.
1 week Two week
before
deadline
Table 7. Quality Assurance Plan
During the project, due to the problem created by the schedule risk and the scope risk, we could
deploy the testing process within the team only.
Deployed Test Non-deployed Test
 Technical test
 Process combination analysis
 Reverse week
 Product test
 Supervisor feedback
 User test
 Final product test
Table 8. Test Deployment

Page | 15
4. Risk Register
4.1 Risk Register Table
Type of
risk
ID Risk
Prob
(Low-
Med-Hi)
Impact
(Low-
Med-Hi)
Effect on project Risk reduction Actions
If it happens: Triggers and
Actions
ScopeRisk
1 Requirement change High Med Change in the project’s
objective and process.
The software must be
reprogrammed.
Have a Clear initial phase at the
beginning of the project.
The common understanding of
requirements including the project
boundaries must be set-up clearly
between the owner and the
project development team.
Feedback from users/supervisors
must be conducted after each
project’s sprint.
All the process must be held
and waiting for the set-up of
the new requirement.
Consider a fixing-plan if
possible.
Extra-time, cost and effort will
be used for the changing of
requirement.
2 Quality of the
product change
High Med The final product may
not meet expectation.
The input-output
process final product
may not work as
planned.
Follow strictly the development
plan and the core-features of the
product using MoSCow
Control the output target of each
sprint.
A full report must be submitted
to the supervisor.
A new definition and
description of the final product
must be represented to the
users.
3 Reputation risk/User
risk
Med Med The users will not use
the product again.
Quality control will be developed.
Develop a friendly interface for
end users
A Clear definition and description
of the product’s feature will be
represent to the end users to
control user’s expectation.
Testing, quality control and
feedback plan will be developed
Apologize and feedback
conducted.
A feedback report must be held
at the end of the project.
An updated, fixing plan for the
product after the deadline may
be developed.

Page | 16
Type of
risk
ID Risk
Prob
(Low-
Med-Hi)
Impact
(Low-
Med-Hi)
Actions
ScheduleRisk
4 Schedule delay High High The final product may
not meet the deadline
requirement
Have a clear project schedule,
tasks distribution and target
requirement in each sprint.
Using Work-breakdown-structure.
Allows time for changing,
feedback and delay in the
project’s schedule.
Having a reserve week after each
sprint.
Using reserve weeks.
Unimportant task, extra, non-
core feature of the product will
be decide and cut-off.
5 Communication
delay/ team member
absent.
High Low Delay in work process. Checking mail daily is required for
each members.
Using all means of
communication: sms, social
media, email, phone-call.
Any expected-delay must be
reported immediately to the
scrum master.
Group meeting is held every
weeks. Each member will report
his/her work process as well as
contribute ideas, feedback on the
whole project.
The delay must be investigated
and a solution must be
developed.
The delay must be report to the
module leader and the
supervisor.
Resources
risks
6 Team member
change
Low Med The task assigned in the
member will be
uncompleted.
Delay on the whole
process
Each task will be take charge by a
group of two members.
Every document, process record
will be save and store on Pbworks,
a group project management
website.
Report immediately to the
module leader and supervisor.
A member-replacement plan
may be developed.
Task distribution plan must be
re-organised.

Page | 17
Type of
risk
ID Risk
Prob
(Low-
Med-Hi)
Impact
(Low-
Med-Hi)
Actions
7 Data/
Document/Record
Loss
Low Med Project time extend Every document will be saved,
shared and stored in the project
management website (pbwork).
Each member will have a copy of
document in their personal
devices (laptop, CPU, Mobile or
tablet)
Document will be printed out in
hard-copy.
Report to module leader and
supervisor.
A technical-recovery plan must
be conducted.
An urgent meeting must be
held to recovery the resources
base on every member’s
memory.
TechnologyRisks
8 Server shut-down Low Med Delay in time Keep backup copies of project
source code. Have backup
versions of SQL database
Group to be informed. Backup
version activated
9 Personal device
breakdown
Low Low Data, document loss Save in Pbworks Saving in PBworks will allow
restore to personal device once
fixed
10 Incompatible
software
Med High Product stop working
as planned.
Ensuring communication between
components first stage task.
Verification of components inter-
communication to be done early
in project
Will be project main effort until
fixed
11 Missing library Med High The software doesn’t
work
Install on multiple platforms in
testing stage. Insure installer
contains all required components
Install the missing library
Table 9. Risk Register

Page | 18
4.2 Risk Control Record
Risk Control Record
Type
of
risk
Risk
ID
Risk Prob Impact
Occurred
(Y/N)
Time of
occurred
Sprint
Trigger
action
Comment
1 2 3
ScopeRisk
1
Requirement
change
High Med Y 2 0 0 2 Y
The requirement
of the output
result changed
2
Quality of the
product change
High Med Y 3 0 0 3 Y
The user interfae
of the output
page changed
3
Reputation
risk/User risk
Med Med N 0 0 0 0 N
ScheduleRisk
4 Schedule delay High High Y 5 1 2 2 Y
All the reserved
week has been
used a the
upmost. These
schedule delay
lead to the
changing in
quality and
requirement of
the product at
the end
5
Communication
delay/ team
member absent.
High Low Y 7 3 3 1 Y
This risk is the
main cause laed
to the delay in
the schedule plan
Resourcesrisks
6
Team member
change
Low Med N 0 0 0 0 N
7
Data/
Document/Record
Loss
Low Med N 0 0 0 0 N
TechnologyRisks
8 Server shut-down Low Med N 0 0 0 0 N
9
Personal device
breakdown
Low Low Y 1 0 0 1 Y
10
Incompatible
software
Med High N 0 0 0 0 N
11 Missing library Med High N 0 0 0 0 N
Table10. Risk Control Record

Page | 19
4.3 Comment on Risk Management
All the risk with high probability occurred during the project management lifecycle: Communication
delay, schedule delay, product quality change and product requirement change. It reflected clearly
the two types of risk that normally happens in a project: Schedule risk and Scope risk.
We learned that these risks do not occur separately. Instead, they occur as a chain of events that lead
to the one risk triggering another. In our case, it all began with the communication. The inaccurate in
schedule planning of the project was the root of the problem. In the planning phase of the project, we
misjudged the ability level of each member to follow the project schedule. Due to personal reasons,
every member on the team could not commit 100% of the time following the project plan.
Communication delay and the member absences on team meetings are strong evidence of this. It also
explained why the communication delay happened with the highest counted occurrences (7 times).
Consequently it led to the delay in the schedule and the delay of the whole project (schedule risk).
The occurrence of schedule risk was the main trigger of the scope risk. With a delay in time and
process, it created a huge stress on the whole team. Therefore, to be able to deliver the product on
time, the team decided to reduce the requirement level and the quality level of the product. It means
that the team did not produce the product as planned.

Page | 20
5. Design Documentation
Web App- Model of a Driving Course using Four Stroke IC Engine
This document contains the system design information for the web app of a driving course and four-
stroke IC engine. This document is prepared in partial fulfilment to the requirement of the Group
Software Development Project.
This design documentation provides a complete description of all the system design and views of the
web app for the driving course and four-stroke IC engine project.
The first section of this document includes the purpose, scope, overview, and definitions and
abbreviations in the project.
The second chapter of this document will include an overview of the functionality of the application.
The third chapter of this document will give the user a description of each function of the system.
The fourth chapter of this document will contain a general overview of what the user interface will
look like.
5.1 Introduction
a. Purpose
This document describes the conceptual design of the web app model of a driving course and four-
stroke IC engine that will be a guideline to users of the system.
The software design description (SDD) shows how the software system will be structured to satisfy
the requirements identified in the software requirements specification. This is a translation of
requirements into a description of the software structure, software components, interfaces and data
necessary for the implementation phase. In essence, the SDD is a detailed blueprint for the
implementation activity. In a detailed SDD, each requirement must be traced to more design
entities.
b. Scope
This project will be a web application and this system will help the owner to do the following:
 Analyse and control the CO2 emissions produced by a vehicle under certain circumstances
whether the road surface is longitudinal or curved.
 The vehicle RPM.
 The speed of the vehicle.
5.2 Definitions and Abbreviations
This is the comprehensive list of all the terms used in this vision document.
 JSON (JavaScript Object Notation)-This is an open standard format that is primarily used to
transmit data between a server and web application.
 PostgreSQL- This is a database server that allows data to be stored securely and also to
allow for retrieval at the request of other software applications.
 HTML (Hyper Text Markup Language)- This is a standard mark-up language that is used to
create web pages.
5.3 Overview
The purpose of this document is to produce an independent program that will compute various
outputs of a vehicle to enable user to analyse and adjust factors that will lead to reducing engine

Page | 21
emission. Also to help produce graph that will show the CO2 consumption and various relevant data
for a vehicle at various location of the track.
5.4 Technologies Used.
There are different ways the data that feeds into this project could be stored. The project
requirements state that it must be storable, so this suggests files are required to be generated
outside the interfaces. These files could be stored as plain text files, for example as XML. The
advantages of these storage methods are that they are truly platform independent, as they can be
opened in a simple text parser. XML allows for a hierarchal data structure to be developed and is
easily followed by the eye. In terms of the database, an RDMS would seems to be most sensible
approach to take as it will allow us to store our data in normalized tables and is easily query-able.
These are usually built around the SQL standard and some of the group members have some
experience in the area. But due to budget, we will avoid using products such as Oracle or Microsoft
SQL server due to the cost, we decided to use an open source DBMS such as PostgreSQL.
5.5 AmChart
We have used a free version of Amcharts for the following reasons
 It accommodate large chunk of data similar to the one we are projecting
 Within the charts itself you can zoom in and zoom out function.
The theme we have used is standard theme as it is a free version we are not sure if we will be able to
add other themes.
The Code:
 The data send through java servlet which have a calculation method.
 Upon success the processed data goes into a variable in the angular js called rootScope,
which is the top scope where the variable will be available for all angular js controllers and it
will be consumed within the result controller.
 A local method variable will be created to calculate our object x and y coordinate for each
graph-object.
 For each object in our array we received if it divide by 10 we put in a new object in the x and
y coordinates.
 X is always time, while y is either speed, fuel use, RPM or emissions depending on the graph
produced.
In the angular JS a directive has been created:
 To get the charts data into directive then instantiate the chart within the directives.
 A new instance of the chart will be created to create a new chart.
 Data will be retrieved through the directives then passed to Amcharts to create new charts.
 The x’s and y’s are read from a JSON file.
The Amcharts was a last minute dash to resolve handling large amount of data. We could only use
the free version as the commercial one will incur cost. Therefore themes and other features are not
available and it may help us to plot data more efficiently.
The other option is to use free charts library such as D3 which is an open source, but the limitation
to that will be the learning curve from our end and may take a while to master the library then will
come the issue of integrating it with angular JS directives.
5.6 Application Overview
In this section we outline the software project in detail. We will start by defining key features that
will be implemented. Next, we will discuss the constraints that will be imposed upon the software
and the quality ranges in terms of the robustness, fault tolerance and the usability of the product.

Page | 22
Above all, the main goal of the project is to enable user to independently analyse and adjust factors
that will help reduce engine emission. The final product of this project will be a web application that
will be compatible with different browsers: IE, Firefox, Chrome as well as running on Mac OS and MS
Windows.
5.7 Architectural Representation
5.8 Architectural Goal and Constraints.
 The web app will run on a dedicated platform with access to a PostgreSQL database.
 It will receive input about the vehicle attributes from the GUI interface.
 The database will store all the information provided.
5.9 System Input Description
a. Track details
This contains information about the track:
Straight Track
This has two options:
 Length- this will be the length, in meters of this section
 MaxSpeed - This will be the maximum speed of the track in meters per second and will also
allow simulation of various driving environment i.e. in order to simulate a motorway

Page | 23
environment, a higher speed must be entered and also in urban environment, lower speed
should be used.
Curved Track
This has two options as well:
 Radius – The curve is modelled as a segment of a circle, which specifies the radius of the
circle in meters.
 Direction – this will either be ‘L’ or ‘R’ for left or right
b. Driver Details
This specifies the driver’s characteristics and is specified by the gear the driver is in:
 Gear – Gear the driver is in
 ChangeupRPM – The RPM at which the driver changes up a gear
 ChangeDownRPM – The RPM at which the driver changes down
 MaxAccn – The maximum acceleration in meter per second per second, which the driver is
willing to do
 MaxDecelleration – The maximum deceleration, in metres per second, which the driver
feels comfortable with
 MaxStraightSpeed – The percentage of the allowed speed the driver is willing to do. For
example a boy racer may sped at 110% every whereas a granny may only do 75% of the
allowed speed.
 MaxCornerSpeed – Similar to above, but for corners (Check if it’s included?)
 PeferredRPM – the preferred RPM at which the driver likes to have the car engine running
at for prolonged periods. This is to simulate for example the effect of accelerate in an area,
before changing up a gear for fuel efficiency (Not included yet)
 Decision time – The amount of time in seconds a driver needs to be travelling at a constant
speed before they decide to change gear to be closest to their preferred RPM
c. Vehicle detail
This specifies the characteristics of the vehicle at different RPM and different gears
 Gear - the gear for which the characteristics are being entered
 RPM –The rpm for which the characteristics are being considered
 maxAccn-The maximum acceleration in metres per second per second that the vehicle is
capable of at this speed
 maxBreak- The maximum rate at which the car can break at the specified gear and RPM
 VehicleSpeed-The speed of the vehicle, in metres per second at the specified gear and RPM
 FuelUse – The fuel use, at a constant speed, for the specified gear and RPM
d. Vehicle acceleration details
This allows details of the additional fuel use or saving occurred during the acceleration or breaking of
the vehicle. A user enters a range of gears, RPM and breaking and acceleration rates, and the effect
these will have on fuel use
 Gear-The gear for which the fuel use is being considered
 RPM – The PRM of the engine for which the fuel use is being considered
 Accn-The acceleration for the fuel use being considered. For breaking, enter a negative
number
 Fueluse-The additional fuel use occurring

Page | 24
5.10 Front End Modules
Descriptions of the various Angular modules for the app.
a. App
Description of the Angular app module.
app.js - This file is the main hub of the app, all the other Angular modules are injected as
dependencies here. All the main views for the app are routed through the ui-router module for
different URLs
b. Form
Description of the modules controlling the forms.
form-contollers.js – Contains a controller. This controller contains a single JSON Object
called ‘formDetails’. The functions in the controller contain functionality to add objects and arrays to
the formDetails object, which in turn use the form-directives.js file to add new form elements.
form-directives.js – Directives give Angular the ability to inject HTML into the app by tagging
existing HTML elements or creating new ones. 8 directives exist in this file and they all add form
elements to the page except the last which controls the animation of the form when it is submitted.
form-services.js – This file contains functions that are reused in the form-directives.js file
and result-directives.js file so they aren’t repeated over and over. It also contains a factory with a
single function which sends the data from the form to the servlet and algorithm and handles the
data returned.
c. Result
Description of the modules controlling the resulting data.
result-controllers.js – Simply takes in the data and uses some simple functions to split it into
the various groupings of x and y positions for the graphs
result-directives.js – contains a directive for the charts to display the data. Also contains
directive to call the track.
6. Source Code
Please download the file “GroupD.war” in the submissions attachment and
follow all the guiding step in the Run Book part below.

Page | 25
7. Run Book
7.1 Technical Details
d. Front End
Tools Needed:
1. Operating System: As the app is designed to run on a web browser, the operating system in
this case is up to the user
2. Web Browser: It is assumed that the user has an up to date web browser with JavaScript
enabled
Languages:
1. HTML5 & CSS3: For markup and presentation
2. JavaScript: Used to add functionality to the front end code
Libraries
1. AngularJS 1.3.15: Used to add modular framework and run the front end as a single page
application
2. jQuery 2.1.3/jQLite: Used to manipulate the DOM only
3. AmCharts(free): To create the charts
4. Angular UI Router: Third party plugin for Angular routing
e. Back End
Tools Needed:
1. pgAdmin 1.2: To manage and set up the database
2. Eclipse Java EE IDE for Web Developers – Kepler Version 2: To create and run Java code with
front-end code
3. Tomcat 7: To run Java code on a server
Languages:
1. PostgreSQL 9.4.1: To store all data passed from the front-end
2. Java 8 SE: Latest Java release for building the algorithm
Libraries:
1. Apache Commons Lang 3.4: To add simpler functionality to the algorithm
2. JSON Simple 1.1: To parse JSON coming from and going to the front-end
7.2 Build and Run
The following steps will show how to build and run the application. It is expected that in the future
the web app will be deployed on a server that will be accessed via HTTP, thus eliminating the need for
these steps.
These steps assume you have the JDK installed and running successfully on your machine.
1. Download and Install Eclipse Java EE IDE for Web Developers at:
https://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/keplersr2
2. Download Apache Tomcat v7.0: https://tomcat.apache.org/download-70.cgi
3. Download and Install PostgreSQL and pgAdmin: http://www.postgresql.org/ &
http://www.pgadmin.org/

Page | 26
4. With pgAdmin and PostgreSQL installed go to pgAdmin and set up a new database ‘postgres’ with
the password ‘Bris2014!’
5. Open Eclipse and follow:
a. Navigate to Eclipse preferences
b. Go into Server -> Runtime Environments, add the Apache Tomcat directory to the list.

Page | 27
c. Go to the servers tab at the bottom of the main screen and click the link to add a new
Tomcat server. Select Tomcat v7.0 and click finish
d. Go to File -> Import and Import the GroupD.war file. Select Tomcat v7.0 as the dtarget
runtime and click finish

Page | 28
e. Right click on the imported project, and go to Run As -> Run on Server
f. Navigate to: http://localhost:8080/GroupD.
You should have the App up and running.

Page | 29
8. Limitation and Enhancement
8.1 The algorithm for calculation
Limitation Enhancement
Algorithm
The algorithm does not take into account
the start angle
Use of more data to decrease space
between data points, and increase the
numbers of points on the track calculated.
Alternatively, incorporate use of
mathematical functions rather than data
points to provide description of
characteristics. If needed, we need to have a
specialist in the car testing field to provide
advice and support.
The algorithm treats curves as a series of
small straight lines – if the radius of the
curve is too small with regards to the
distance separation between each point
calculated, odd results will occur.
Effects of acceleration and breaking have
not been considered on fuel use.
Individual data points are used to describe
the vehicle characteristics. The algorithm
interpolates between these points when
necessary, and assumes a linear function
between them.
No consideration of height change has
been developed. This could be done by
incorporating the effects of acceleration /
breaking (this functionality is in the
compute section) and then using the angle
of the slope and the force of gravity to find
the acceleration change and therefore the
change in fuel use and emissions.
8.2 Coding
Coding
Chart used hard code data Use a free open source chart library like D3
which have different themes we could have
used.
Not using PHP
Use PHP to improve interaction
Use HTML game engine library instead of
drawing library
There is multiple duplication of code within
the algorithm due to the current
developmental nature of the work.
Remove the code's duplication in the
algorithm in order to improve
maintainability and robustness

Page | 30
8.3 Security
Security
No validation requirement for the input
form
Create validation for the input form
No Access control system Provide limit access to authorized personnel
8.4 Database
Databa
Database
se
The user cannot rerun saved runs,
although the data is available for access in
the Postgres database
Implement a REST web API which will allow
interaction between our backend database
and the front end which could be developed
by designated organisation and hosted on
their servers.
Currently the front-end does not allow the
user to load in saved files, although there is
a JSON file for storage of data
If the user refreshes the page the data
gets lost and they have to start again
8.5 User Interface
User
interface
No welcome page and guide page to help
users with the using of the web app
Add an welcome page as well as guide page
for the user
Low level of web app design Use CSS to improve visualise.
No animation Use Maya or Unity to create animation
no visual image of the test track Use Flash player to stimulate the test track
The “Add curved tile”, “Add linear tile”,
“Add rpm range”, and “Add gear”
directives are not currently removed from
all but the last card of each form Improve the input form coding part
There are no preset form inputs which
would add more value to the software and
speed up the process

Page | 31
9. Group Assessment
The project’s idea of the software is decided by the team and we have three months to deliver the
product as planned. Our team’s project is based on the suggestion of the module leader idea. The idea
is about developing software that will allows a car manufacturer to simulate a car design in a computer
to test their energy consumption and emission before producing a real prototype. It will allow firms
to save times and producing cost of the car design phase. Our team had six members and we decided
to choose the Agile SCRUM approach to manage our project.
9.1 Strength
a. Team members with a wide combination of IT technical skills and experiences:
In our team of six members, four of us are already have a background in information technology,
although all of us are on the MSc IT and had done no formal programming as part of this course. Two
of the members are part-time students and have worked in IT fields for several years. Furthermore,
our team encompasses a wide combination of different technical skills. These include: HTML, CSS,
Java, JavaScript PHP, ASP.NET, MySQL and animation engine. This combination allows the team to
construct a broad based technical approach to the project; it also provides confidence we could find
solutions to any problem occurring during the project. Hence, considering technical strength, we were
confident that we had a strong team.
b. The use of PbWorks and Bitbucket:
To improve our software development process, we have decided to use PbWorks and Bitbucket. These
two tools are proven to be very useful for the management of the project.
 PbWorks: PBworks (formerly PBwiki) is a commercial real-time collaborative editing
(RTCE) system created. It was operated on a freemium basis, offering basic features free
of charge and more advanced features for a fee. For our project, we used PBworks as a
private document management system where all our documents will be saved, uploaded
and shared to all team members.
 Bitbucket: Bitbucket is a web-based hosting service for projects that use either the
Mercurial or Git revision control systems. Bitbucket offers both commercial plans and free
accounts with an unlimited number of private repositories. For a software development
project, this web-based hosting is crucial useful. It allows team member to share their
coding job together in one tool. Bitbucket save both the old and new codes, as well as
allows users to leave comment for any changing. Hence every member can work in the
same code and contribute directly to the development of the software.
These two tools provide many advantages for the project management:
 Reduce team meeting times.
 Allows members to take work home. Thus increase productivity and motivation.
 All team members can share and keep track of the work process.
 Greatly reduce the risk of losing data create by the damage of personal working device.
9.2 Weakness
During the project the team recognized three main problems:
a. Team members cannot provide full commitment to the project plan:
Our team is a combination of both full-times and part-time students. Therefore, it created many
difficulties for the members trying to follow the project plan:

Page | 32
 Organize team meeting schedule: because part-time student still have an official job to fulfil
and full-time student have others modules to attend, it is hard to organize a daily meeting
following SCRUM method. Consequently, our team can only have 1-2 meetings in a week.
 The time stress: while the stressing from other modules are always a problem of a full-time
student, for a part-time student member, it is hard to manage between the job and the
project responsibility. In most case, the priority level of the job is higher than the project
responsibility of a university course. Therefore, the commitment standard of every member
to the project plan is not guarantee.
b. The lack of direct communication
We had team meeting every week. However, outside of the meeting, we did not maintain a
sufficient level of communication. The lacking of direct communication between each member
created a delay to the information exchange, even though we had shared the contact detail together
with every member in the team. Email and text message were the mostly widely used throughout
the whole project. Others more effective communicate methods such as: phone, skype or video call
were not used regularly. Team members preferred using email or text message so they can fully
express their idea and communication content can be saved and tracked in email and text. Although
a reasonable reason, , it clearly restrict the communication abilities of the whole team.
c. Difficulty in combine team member’s skills
As mentioned above, our team is a combination of a wide set of technical skills. Although useful it
also generates problems. Each member of our team has a different skills set, both technical and non-
technical. The difficulty occurred because we are gathered as a totally new team and had trouble
understanding each other’s strengths and weaknesses. Plus, the time for the project is limited to just
few months. Each member tended to focus only on the part to which they were assigned, based on
their strong points. As a result, the project work became localized and discrete. Thus, to combine
and use every member’s potential in the most efficient way was a big challenge.
9.3 Solution for improvement
a. Carefully planning of time and project objective:
Learning from the first problem, we now recognise the crucial role of the planning phase in a project.
Instead of only required team members to commit their effort to the project plan, carefully planning
of the project time and objective at the very beginning of the project is key.
 Planning project time: depending on the nature and the requirements of the project, as
well as the level of commitment of each member in the team, a reasonable time schedule
must be decided. During the project if the member cannot follow the plan, a backup
schedule needs to be arranged where the project allows the member to have plenty of
extra times to catch up with the project.
 Planning project objective: In the case that the time requirement is fixed and there may
have a high probability that the project’s objective cannot be achieved, a plan for lowering
the project objective must be prepared and get the permission from the project owner.
With that, a project can still provide an acceptable product and fulfil the requirement.
b. Encourage further communication outside team meetings:
Relying only on group meeting, emails and text was not enough for a team project. Aside from team
meeting for all members, small and quick meetings between 2-3 members should occur. Face-to-
face, or direct communicate, proved to be the most effective way of working in a team. By
encouraging this we can strengthen all the links in the chain. This method also provides an
environment in which each member, based on each person needs, can focus and communicate to a
specific member at a specific time. With that, instead of waiting for the next meeting to present any

Page | 33
issue or problem to the whole team, a member can actively seek help from another member and
solve the problem before the common group meeting.
c. Testing the combination of the team member’s skills:
Not only noting down the skills of all members, the testing phase of how these skills can combine
together and contribute to the project is a crucial job. Knowing the skills of each member is just the
first thing to do, selecting the skills set and testing the combination is more important. Ideally, we
can begin the testing with small project with an easy objective or a sprint with easy tasks. With that,
even if the job is not finished, we quickly understand the ability of the whole team and changing the
way of the combination of skills.
9.4 The Development Process
We applied the SCRUM agile method throughout the whole project. However, at the end, we learned
that the using of SCRUM is not suitable for this software development project. The reasons are
described below:
a. Time issues
Scrum Agile method is suitable for a project where the time is not strictly controlled. In a project where
the team members have many different priorities and cannot commit to the process, Scrum is not a
good choice for the team. The Scrum method contains many sprints. The tasks of the team in each
sprint are repeated and the product will be expanded or upgraded after each sprint. Thus, each
member needs to be able to dedicate time over a prolonged period to allow more sprints and the
product objectives being achieved. Therefore, applying the Scrum method into this project was not an
excellent choice.
b. High Requirement objective
Scrum is proved to be suitable for a project with an unclear objective. In such condition, it allows a
scrum team to develop the product in the most creative way. However, in our project’s condition, first
of all, we decided to choose the project topic as the suggestion of the module leader and to meet his
requirement as near as possible. It means that our objective is fixed and clear. Secondly, the project
had a high requirement standard and the time allows for the project is short. Therefore, under such
situation, A Waterfall approach may be a better choice than the Scrum agile.
c. The need of a team leader
In this project, we have a Scrum master, but not a team leader or project leader. Plus, the right to
decide the requirement and the product backlog belongs to the product owner, who did not get
involved in the development process of the product. Hence, in our scrum team, we do not have any
one to take the lead, take responsibility and give decision for the whole team. This issue created an
unstable situation in the group. Without a team leader, the decision-making process of the team will
take longer time than normal. It made the team less united and less stable in performance.
d. Lacking of Learning and Training time
During the project, we ignored the time needed for learning and training. Even though the team had
a wide combination of skills from all the members, the process required an extra time for the
member to learn and train new skill to fix with the whole team. For example, a database
administrator needed to study more about the web design language and the ways to connect the
web-app to the database. Similarly, a web design member must understand how the database works
so he can design a reasonable input form. A Scrum project with long time and many sprint circles can
solve this problem. However in our case where the schedule was strict and contented only three
sprints, it created more pressing into the time stress.

Page | 34
9.5 Recommendation
a. Agile Vs Waterfall
Depending on the nature and objective of your project, between Agile and Waterfall, both project
management methods have their own strengths and weaknesses. At the beginning of the project, a
team must analyse the situation before decide which method will be applied. This table below
suggest some basic consideration for choosing between Agile and Waterfall.
Agile Waterfall
Time
 Long-term project
 Have plenty of time
 Schedule is not fixed
 Short-term project
 Time is limited
 Schedule is fix
Objective
 Objective not clear
 Allows creative
 Low standard requirement
 DO RIGHT THING
 MAKE THE BEST PRODUCT
 Objective is clear and well
identified
 fulfil objective as planned
 High standard requirement
 DO THING RIGHT
 MAKE THE RIGHT PRODUCT
Human
 Small team
 Encourage extra learning,
training and skills exchange.
 Encourage cross function and
contribute of idea from the
whole team
 Big team
 Require stable/fix skill
standard
 Each person/team act as
planned – wait for right input
and produce the right output
for the next phase.
Table 11. Agile Vs Waterfall
b. Using of Bitbucket, PbWorks or others free project management/group-work tools.
There are many tools other than Bitbucket and PBWorks that help improve the performance of a
project team or group work. The advantages of using these tools were:
 Reduce team meeting times.
 Reduce time for travelling.
 Allows members to bring work homes. Thus increase productivity and motivation.
 All team members can sharing and keep checking of the work process.
 Greatly reduce the risk of losing data create by the damage of personal working device.
 Most of the tool can be opened in a web browser anytime, anywhere (internet connection
required).
 Reduce paper record.
 Many tool provide support feature for analyse team performance over a project.

Page | 35
Reference
European Commission (2015) Reducing CO2 emissions from passenger cars. Available at:
http://ec.europa.eu/clima/policies/transport/vehicles/cars/index_en.htm [Accessed 6 February
2015].
Goldstein, I (2013) Scrum shortcuts without cutting corners. Addison-Wesley Professional.
Kulkarni, A., Kapoor, A., Iyer, M. and Kosse, V. (2011) Virtual prototyping used as a validation
tool in automotive design. In: Chan, F., Marinova, D. and Anderssen, R.S., eds. 19th International
Congress on Modeling and Simulation. Perth, 12 – 16 December 2011. Modeling and Simulation
Society of Australia and New Zealand, pp. 419 – 425.
McLeod, P. (2001) Availability and capability of ‘low-end’ virtual modeling (prototype)
products to enable designers and engineers to prove concept early in the design cycle [online].
Loughborough: PRIME Faraday Partnership. Available from:
http://www.lboro.ac.uk/microsites/mechman/research/ipm-ktn/pdf/Technology_review/virtual-
prototyping-early-in-the-design-cycle.pdf [Accessed 6 February 2015].
Petter, J. (2013) Jaguar Land Rover shows how British manufacturing is leaping into the 21st
century. New Statesman [online]. 17 September. Available from:
http://www.newstatesman.com/business/2013/09/jaguar-land-rover-shows-how-british-
manufacturing-leaping-21st-century [Accessed 6 February 2015].
Savail, J., Borro, D., Gil, J. and Matey, L. (2002) Description of a Haptic System for Virtual
Maintainability in Aeronautics. International Conference on Intelligent Robots and Systems.
Lausanne, 30 September – 4 October 2002. IEEE, pp. 2887 – 2892.
Son, K., Choi, K. and Eom, S. (2001) Virtual Prototyping Simulation for a Passenger Vehicle.
KSME International Journal. 15 (4), pp. 448-458.
The Scrum Alliance (2013) The State of Scrum Report. Indianapolis: The Scrum Alliance.
The Standish Group (2014) Chaos manifesto. Boston: The Standish Group.

group project report

More Related Content

Featured

group project report