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.

4User 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

6User can save and print out the

resultuser can keep record of the test. Not completed

7This Webb-app can be used in

mobile deviceExtend 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

documentationtest form & database

BEG

INN

ING

WEE

KSP

RIN

T 1

test form

Create webserver, database &

connect to user interfacetest 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 &

chartcode interactivity test chart & track interactive

commit all source code to

repository

SPR

INT

2SP

RIN

T 3

FIN

ISH

design file format for front-

endcreate 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 System Implement 0.5

9.0 System Test 0.25

10.0 System Evaluation 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




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




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

Sco

pe

Ris

k

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-



Sch

ed

ule

Ris

k

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.

Re

sou

rces

ri

sks

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-



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.

Tech

no

logy

Ris

ks

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

Sco

pe

Ris

k

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

Sch

ed

ule

Ris

k 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

Re

sou

rces

ris

ks

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

Tech

no

logy

Ris

ks

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/

https://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/keplersr2

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.

http://localhost:8080/GroupD


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

Documents