LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
LHB Project
Project Plan
Version 1.0
Page 1
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
Revision History
Date
28.10.2012
29.10.2012
02.11.2012
Version
0.1
0.2
1.0
Description
initial draft
document review
release version
Author
Hrvoje Novak
Robert Pofuk
Aleksandar Nikodinovski, Petar
Stojanac, Hrvoje Novak, Danijel
Jambrecina
Page 2
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
Table of Contents
1. Introduction ................................................. 4
4.3.6 User interface manager ................ 10
1.1 Purpose of this document ...................... 4
4.3.7 Usability manager ......................... 10
1.2 Intended Audience................................. 4
4.3.8 Documentation manager ............... 10
1.3 Scope..................................................... 4
4.3.9 SVN manager................................ 10
1.4 Definitions and acronyms ...................... 4
4.3.10 Testing manager ......................... 10
1.4.1 Definitions ....................................... 4
4.3.11 Meeting manager ........................ 10
1.4.2 Acronyms and abbreviations .......... 4
4.3.12 Implementation manager ............ 10
SDK ............................................................. 4
4.4 Quality assurance ................................ 11
Software Development Kit ........................... 4
4.4.1 Organization .................................. 11
2. Background and Objectives ........................ 5
4.4.2 Planning ........................................ 11
3. Organization ................................................ 7
4.4.3 Software Quality ............................ 11
3.1 Project group ......................................... 7
5. Deliverables ............................................... 12
3.2 Steering group ....................................... 7
5.1.1 Remarks ........................................ 12
3.3 Customer ............................................... 7
6. Inputs ......................................................... 13
3.4 Supervisor ............................................. 7
7. Project risks ............................................... 13
4. Development process ................................. 8
8. Communication ......................................... 14
4.1 Description ............................................. 8
8.1 Meetings .............................................. 14
4.2 Project phases ....................................... 9
8.1.1 Regular team meetings ................. 14
4.2.1 Requirements gathering phase ....... 9
8.1.2 Local team meetings ..................... 14
4.2.2 Design ............................................. 9
8.1.3 Meetings with the customers ........ 14
4.2.3 Implementation ............................... 9
8.2 Google Groups .................................... 14
4.2.4 Integration and Testing ................... 9
9. Configuration management ....................... 15
4.2.5 Verification ...................................... 9
9.1 Tools and technologies ........................ 15
4.3 Roles description ................................... 9
9.2 Coordination ........................................ 15
4.3.1 Project leader .................................. 9
10. Project plan ............................................. 15
4.3.2 Team leader .................................... 9
10.1 Time schedule ................................... 15
4.3.3 Requirements manager ................ 10
10.2 Plan .................................................... 16
4.3.4 Design manager............................ 10
10.2.1 Remarks ...................................... 16
4.3.5 Database manager ....................... 10
Page 3
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
1. Introduction
1.1 Purpose of this document
● Introduction of the project
● Initial project plan
● Introducing parties involved in the project
● Presenting the scope and goals of the project
● Defining risks and configuration management
● Project timetables
1.2 Intended Audience
This document is intended for the project supervisor, the steering group and the development team in
order to be able to follow the progress of the project. It is also used by the customer as an overview of
the intended flow of the project, which creates a feedback system between the customer and the team.
This way, if the project strays from the intended path, it can be quickly returned. This version of the
document is reviewed in the initial state of the project.
1.3 Scope
This document discusses the preliminary setup of the project and the intended goals and plans. It
gives answers to such questions like:
● Who is it for
● How is the organization and hierarchy of the development team formed
● How does the project need to be realized
● What is the implementation methodology
● What are the risks
● How are the steps of the project distributed over time
This document does not specify the detailed requirements specification and implementation
architecture nor does it define the technologies in which the product will be implemented.
1.4 Definitions and acronyms
1.4.1 Definitions
Keyword
ABB CRC
Definitions
The Corporate research center of ABB, a multinational corporation
operating in robotics and mainly in the power and automation
technology areas
1.4.2 Acronyms and abbreviations
Acronym or abbreviation
LHB
SVN
FER
MDH
SDK
Definitions
Let’s Help Bo
Subversion
Faculty of Electrical Engineering and Computing
Mälardalen University
Software Development Kit
Page 4
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
2. Background and Objectives
The main subject of the project is to develop an inventory support system for future mines. The main
goal is to help machine operators in their everyday work. Since the machines and equipment used in
the mine are subjected to malfunction, spare parts need to be acquired from warehouses. In normal
circumstances, this uses up quite some time from the workers. This project resolves that issue by
automating the whole process. Machine operators can now access the central booking system via an
application to order the necessary spare parts. They also get a notification upon completion of the
order and directions to the location where to pick it up. Part of this project is also the feature to
manage the working schedule that needs to be changed during the pickup of the spare parts.
The project offers extra functionalities that aim to help in the daily activities of some people that work in
the mine. These features include more people working in the mine other than the machine operator.
Below are the components that will be part of the system, and the actors that will interact with them.
Page 5
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
One of the main requirements is to develop a software that is easy to use considering the environment
in which it will be used. Detailed description of all requirements is defined in the requirements definition
document.
General milestones are:
● Project vision 23.10.2012
● Project plan 30.10.2012
● Requirements Definition and System Architecture 6.11.2012
● Milestone - Alpha prototype 27.11.2012
● Milestone - Beta prototype 18.12.2012
● Final product 20.01.2012
Deliverables include:
● Project plan document
● Requirements Definition document
● Design Description document
● Summary Week Reports, happiness polls
● Minutes of Meeting
● Mobile GUI design
● Wed design
● Database design
● Logic layer design
● Technical documents, project policies etc
● Acceptance test plan
● Test report
● Final Project Report
● Final Product
Testing needs to be performed on the individual components as well as on the whole system after
integration.
Final product with final project report should be delivered on 20.01.2013.
Page 6
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
3. Organization
3.1 Project group
Name
Initials
Responsibility (roles)
Aleksandar Nikodinovski
AN
Project leader
Hrvoje Novak
HN
Team Leader
Nives Bučić
NB
Requirement manager
Documentation manager
Rasul Niyazimbetov
RN
User interface manager
Usability manager
Petar Stojanac
PS
Meeting manager
SVN manager
Antonio Gallucci
AG
Requirement manager
Documentation manager
Gonçalo Filipe Silva
GS
Testing manager
Danijel Jambrečina
DJ
Database manager
Niklas Gilström
NG
Design manager
Implementation manager
Robert Pofuk
RP
Implementation manager
3.2 Steering group
The steering group is consisted of professor Ivica Crnković from MDH and professor Mario Žagar from
FER which hold the DSD course and monitor how the teams are progressing, and Aneta Vulgarakis,
the project supervisor.
3.3 Customer
Our external customers are the ABB Corporate Research Center represented by
● Isak Savo
● Petra Björndal
● Aneta Vulgarakis
Aneta is also the project supervisor. The part of the team that is based in MDH in Sweden can talk to
her personally, while the rest of the team uses Skype to hold the meetings and gather the information.
With Isak Savo and Petra Björndal we communicate through Aneta and also via email. From them we
can learn a lot about the functionalities and behaviour of the application.
3.4 Supervisor
Aneta Vulgarakis is the project supervisor but she also has the roles of a customer and a steering
group member.
Page 7
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
4. Development process
4.1 Description
The methodology we chose to adapt on this project is an iterative waterfall model with a mix of agile
methodology. In the early stages of the project we will use the waterfall methodology and in the later
stages of the development, such as implementation and testing, we will switch to agile. The main
reason for this is that our team is a fairly large team, it has 10 members and they are located in two
different countries. Because of that obstacle, the communication is not as good as it would be if the
team were working locally and the pure agile approach wouldn’t be as efficient.
Another important reason is that our customers insist on user centered design and high usability. In
order to achieve that, requirements need to be gathered carefully and they need to be well
documented. Waterfall model allows the customers to clearly state their requirements and it allows the
designers to design a solid architecture that will respond to them.
Finally, the documentation we need to produce and deliver during this course matches pretty well with
the documentation that is made during the initial phases of the waterfall methodology and the later
agile approach to implementation is well suited for developing a component based system.
Page 8
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
4.2 Project phases
4.2.1 Requirements gathering phase
During this phase there is a lot of communication inside the project team as well as with the supervisor
and with the customers. The goal is to crystallize well defined requirements, to document them
extensively and to understand them so every team member gets the general idea of what the
application is going to be about.
4.2.2 Design
The project team focuses on designing the architecture and the graphical user interface of the
application so it can meet all the requirements. Meeting the requirements is the most important part
but there is also a matter of extensibility and scalability. It’s important to design the architecture in such
a way that sometime in the future extra features can be introduced on top of the existing ones and that
is what our team will strive to.
4.2.3 Implementation
The implementation phase consists mainly of coding and unit testing. It’s an iterative model so the
product of the phase will be a working and tested component of the system. During this phase the
managing skills of the managers are tested, especially in a big team of 10 people. Every team member
has different skills and it’s up to the managers to use them most efficiently. This is where we will
implement code sharing via Subversion repository to speed up the development.
4.2.4 Integration and Testing
In this phase the components that were developed by separate team members are integrated together
to make the system whole. Testing must be done to ensure the success of the integration phase which
means that the system has no errors or failures and can be started. In the meantime, individual
components are also tested before integration with the system is done. The product of this phase is
the core of the application together with some of the components tested and ensured that they all work
as a whole.
4.2.5 Verification
This is the last phase of project development. When the system integration is complete, before it can
be delivered to the customer, it must be verified that it meets all the defined requirements. Also, in this
phase, the system is tested for eventual bugs so they can be removed.
4.3 Roles description
Our project team consists of 10 members. This is considered to be a big team and to properly manage
it we have assigned manager roles that alleviates and speeds up the development process. The
managers are responsible for coordination specific aspects of the development process.
4.3.1 Project leader
Distributes tasks amongst the team members. Constant communication with all the team members as
well as with the project supervisor and customers. Managing and minimizing risk. Follow the work
progress of each team member and assign help if needed. Urging team members to meet their
deadlines. Gathering week reports from everyone and summarizing them in a summary week report.
4.3.2 Team leader
Communicating intensely with the project leader and local team members. Distributing tasks amongst
the local team. Keep track of the work progress of the local team. Arranging local team meetings and
preparing topics for them.
Page 9
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
4.3.3 Requirements manager
In charge of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then
controlling change and communicating to relevant stakeholders.
4.3.4 Design manager
Design manager coordinates work on application design and further divides the tasks given by the
project leader and team leader into sub tasks and distributes them to the rest of the team members.
He will also advise the rest of the team on the proper practices when designing the architecture of the
application and resolve any arising questions and problems.
4.3.5 Database manager
In charge of setting up the virtual machine for the database server. Coordinate team members and
give advice on how to build a correctly designed database. Implement the designed database and fill
in the initial data. Responsible for regular maintenance of the database.
4.3.6 User interface manager
Responsible for organizing and distributing tasks when it comes to implementation of the user
interface. Needs to coordinate with the usability manager.
4.3.7 Usability manager
Specific role created because of the requirement for user centered design. The task of the manager is
to keep track of the graphical interface design and make sure that it is in accordance to the principles
of user centered design. It is also to give advice to the designers on the right approach to designing
such interface.
4.3.8 Documentation manager
Writing the main content of the software documentation. Review all the documents before delivery.
4.3.9 SVN manager
Needs to keep a regular backup of all the files that are on SVN. Uploads the final version of deliverable
documents to SVN. When a conflict appears he works together with the team member that is in conflict
to resolve it.
4.3.10 Testing manager
Manages the testing of the code during the implementation and coordinates the writing of the test
report document?
4.3.11 Meeting manager
Writes Minutes of meeting document where he summarizes everything that was said on the meeting
including who needs to do what and when. Uploads the document to the DSD course website.
4.3.12 Implementation manager
Coordinates the activities related with the implementation. Responsible for the integration of the code.
Needs to be in close contact with user interface manager and usability manager. He is responsible for
determining the code policy to prevent the conflicts that could arise from distributed development.
Page 10
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
4.4 Quality assurance
Ensures that the final product meets the requirements of customers and passes validation. Manages
the quality of software and of its development process.
4.4.1 Organization
Aiming to create a quality culture in the team by encouraging the team members to meet the
deadlines. Improving quality by using a well-known software development methodology that produces
documentation for each phase of the development process and using templates for those documents.
The work products are sent for confirmation to the project supervisor and the customers.
4.4.2 Planning
Improving quality by identifying the potential risks and by planning appropriate counter measures.
4.4.3 Software Quality
Team members with more experience mentor other on how to produce well-defined documents. After
a document is finished it needs to pass a review done by other team members. Writing documents like
code policy and SVN policy that establish a set of rules and guidelines on how to code and use
Subversion.
Page 11
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
5. Deliverables
To
Planned
week
Output
Promised
week
Late
+/-
Delivered
week
Remarks
All stakeholders Project plan (v.1)
w43
w43
-
w43
-
All stakeholders GUI Mockups
w44
w44
-
-
-
Requirement definition
w44
(v.1)
w44
-
-
-
w44
w44
-
-
-
All stakeholders Extra features definition w45
w45
-
-
-
All stakeholders Mobile GUI design
w46
w46
-
-
-
All stakeholders Web site design
w46
w46
-
-
-
All stakeholders Database design
w46
w46
-
-
-
All stakeholders Logic layer design
w46
w46
-
-
-
All stakeholders Alpha prototype
w48
w48
-
-
-
All stakeholders Beta prototype
w51
w51
-
-
-
All stakeholders Acceptance test plan
w3
w3
-
-
-
All stakeholders Test report
w3
w3
-
-
-
All stakeholders Final project report
w3
w3
-
-
-
Final versions of all the
w3
documents
w3
-
-
-
w3
-
-
-
All stakeholders Summary Week Report -
-
-
-
R_01
All stakeholders Minutes of Meeting
-
-
-
-
R_02
-
-
-
-
R_03
All stakeholders
All stakeholders Design Description
All stakeholders
All stakeholders Final product
All stakeholders
Technical documents,
project policies
w3
5.1.1 Remarks
Remarks ID
R_01
R_02
R_03
Description
Needs to be delivered every Monday at 23.59 during the whole course of the project
Needs to be delivered after every team meeting and after the meetings with the
customers during the whole course of the project
To be determined during the project, susceptible to changes
Page 12
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
6. Inputs
Required
item
From
Steering group Virtual
(DSD)
machine
Customers
Database
inputs
Test group
Application
usability
testers
Planned
week
Promised
week
Delivered
week
Late +/-
Rem
w45
-
-
-
-
w46
-
-
-
-
-
-
-
-
-
7. Project risks
Possibility
high
Risk
Preventive action
Members have other courses to Divide work according to
attend
member possibility's
medium
Members being late with their
work and missing deadlines
Internal deadlines earlier than
official. Redistribution of work not
done to other members.
medium
Impossible to meet schedules
Have more working hours or
exclude some features
medium
Some members have no
experience with some
technology
Members with experience
provide assistance and tutorials
low
Members are not reachable
Have many communication
channels.
low
Misunderstandings
Discuss and write all things that
could lead to misunderstanding
low
Conflicts
Try to resolve on meetings
low
Losing database
Backup of database
low
Corrupt database
Database manager should fix
corruptions, backups
low
Hardware malfunctions
Regular SVN commits
Page 13
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
8. Communication
For this project we use several different types of communication tools....
8.1 Meetings
Our team is in constant communication. We use several communication tools and organize regular
and local meetings. Most of the time, each team member is connected at his own post to the group
chat. Minutes of meeting documents are written for every regular meeting and for meetings with the
customer.
8.1.1 Regular team meetings
Regular team meetings are scheduled on Wednesdays at 18:00. Each side of the team (Croatian and
Swedish) meets together locally and then a communication channel is established. The
communication tool that we use for these meetings is Skype. We use Skype because it allows us to
communicate in real-time with audio conferences.
8.1.2 Local team meetings
Beside the regular team meetings on which all the team members participate, we also have local
meeting for the 2 teams on the different universities. Those meetings usually take place before the
regular team meetings but can also be arranged in other times if needed.
8.1.3 Meetings with the customers
The Swedish part of the team has regular meetings with the supervisor and customers more often
because the customers are in Sweden. The Croatian part of the team will also sometimes be included
on the meetings through Skype to get a better understanding of the current tasks.
8.2 Google Groups
We use Google Groups for news broadcast about the project, to do lists, tutorials, discussions
regarding the work being done etc. Everyone is monitoring the groups closely and receives
notifications on every update and new topics.
Page 14
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
9. Configuration management
Tools and methods for keeping track and controlling the changes done in software.
9.1 Tools and technologies
For the purpose of this project, we will get access to a virtual machine at FER. On that virtual machine
will be installed Windows Server 2008 R2 With SP1. Windows Server 2008 R2 With SP1 is a server
operating system with Service Pack 1 which brings bug fixes and some additional functionalities.
For the database administration we will use Microsoft SQL Server 2008 Express Edition. Microsoft
SQL Server 2008 Express Edition is a relational database management system which enables
database creation, usage and administration.
Visual Studio will be used for application programming. Visual Studio is an integrated development
environment which supports different programming languages and includes code editor, debugger,
forms designer and other useful tools.
For the code management we will use SVN. We have been given SVN repository access by FER.
Every team member got user name and password to access repository. Repository is located on the
following URL: svn://lapis.rasip.fer.hr/svn/dsd12/Inventory.
For mockups drawing we used tool named Pencil. It is a very simple and effective tool for drawing user
interface mockups.
Android SDK is a comprehensive set of tools used for Android applications development so we will use
it for development of our mobile application.
9.2 Coordination
Team members in charge for coordination are, first and foremost, the project leader and team leader.
They are the ones who keep track of the changes in the software and the development process and
distribute general tasks. The one responsible for coordination on a lower level, like during the
implementation process, are the managers. No specific tool is used to assign task to team members,
instead we use Google groups where we put a detailed task description for each member along with
some document templates or examples of how the end result should look like.
10. Project plan
10.1 Time schedule
ID
Milestone
description
M0 Project vision
M1 Project plan
M2 Requirements
Definition and
System
Architecture
M3 Alpha prototype
M4 Beta prototype
M5 Final project
Responsible
dept./initials
Planned
week
Promised
week
43
44
45
43
Late
+/-
Delivered
week
Metr
Rem
43
48
51
3
Page 15
LHB Project
Project Plan
Version: 1.0
Date: 02.11.2012
10.2 Plan
ID
Predecessor
Activity
Days
Mdays
Rem.
1
-
25
50
R_01
2
-
20
40
3
-
Requirement gathering
and analysis
GUI prototype
development
Architecture Design
20
40
4
-
20
40
5
-
Alpha Prototype
Implementation
System and Alpha Testing
15
30
6
4,5
Beta Prototype
Implementation
15
30
7
4,5
System and Beta Testing
15
30
8
6,7
15
30
9
10
11
6,7
1,2,3
-
Final product version
implementation
System Testing
System Integration
Documentation
15
30
70
30
60
140
Planned effort (days)
70
Planned effort (man-days)
520
10.2.1 Remarks
Remarks ID
Description
R_01
1 man-day is 4 man-hours
Page 16