LHB Project Plan V1

LHB Project Version: 1.
0
Project Plan Date: 02.11.2012
LHB Project
Project Plan
Version 1.0
Page 1
LHB Project Version: 1.0
Revision History
Date Version Description Author
28.10.2012 0.1 initial draft Hrvoje Novak
29.10.2012 0.2 document review Robert Pofuk
02.11.2012 1.0 release version Aleksandar Nikodinovski, Petar
Stojanac, Hrvoje Novak, Danijel
Jambrecina
Page 2
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
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 Definitions
ABB CRC 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 Definitions

LHB Let’s Help Bo
SVN Subversion
FER Faculty of Electrical Engineering and Computing
MDH Mälardalen University
SDK Software Development Kit
Page 4
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
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
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
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
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
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
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
5. Deliverables
Planned Promised Late Delivered
To Output Remarks
week week +/- week
All stakeholders Project plan (v.1) w43 w43 - w43 -
All stakeholders GUI Mockups w44 w44 - - -

Requirement definition
All stakeholders w44 w44 - - -
(v.1)
All stakeholders Design Description 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
All stakeholders w3 w3 - - -
documents
All stakeholders Final product w3 w3 - - -
All stakeholders Summary Week Report - - - - R_01
All stakeholders Minutes of Meeting - - - - R_02

Technical documents,
All stakeholders - - - - R_03
project policies
5.1.1 Remarks
Remarks ID Description
R_01 Needs to be delivered every Monday at 23.59 during the whole course of the project
R_02 Needs to be delivered after every team meeting and after the meetings with the
customers during the whole course of the project
R_03 To be determined during the project, susceptible to changes
Page 12
6. Inputs
Required Planned Promised Delivered
From Late +/- Rem
item week week week
Steering group Virtual w45 - - - -
(DSD) machine
Customers Database w46 - - - -
inputs
Test group Application - - - - -
usability
testers
7. Project risks
Possibility Risk Preventive action
Members have other courses to Divide work according to

high
attend member possibility's
Internal deadlines earlier than

Members being late with their
medium official. Redistribution of work not
work and missing deadlines
done to other members.
Have more working hours or

medium Impossible to meet schedules
exclude some features
Some members have no

Members with experience
medium experience with some
provide assistance and tutorials
technology
Have many communication
low Members are not reachable
channels.
Discuss and write all things that
low Misunderstandings
could lead to misunderstanding
low Conflicts Try to resolve on meetings
low Losing database Backup of database
Database manager should fix

low Corrupt database
corruptions, backups
low Hardware malfunctions Regular SVN commits
Page 13
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
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
Milestone Responsible Planned Promised Late Delivered

ID Metr Rem
description dept./initials week week +/- week
M0 Project vision 43 43 43
M1 Project plan 44
M2 Requirements 45
Definition and
System
Architecture
M3 Alpha prototype 48
M4 Beta prototype 51
M5 Final project 3
Page 15
10.2 Plan
ID Predecessor Activity Days Mdays Rem.

1 - Requirement gathering 25 50 R_01
and analysis
2 - GUI prototype 20 40
development
3 - Architecture Design 20 40
4 - Alpha Prototype 20 40
Implementation
5 - System and Alpha Testing 15 30
6 4,5 Beta Prototype 15 30

Implementation
7 4,5 System and Beta Testing 15 30
8 6,7 Final product version 15 30

implementation
9 6,7 System Testing 15 30
10 1,2,3 System Integration 30 60
11 - Documentation 70 140
Planned effort (days) Planned effort (man-days)
70 520
10.2.1 Remarks
Remarks ID Description
R_01 1 man-day is 4 man-hours
Page 16

LHB Project Plan V1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LHB Project Plan V1

Uploaded by

Copyright:

Available Formats

LHB Project Version: 1.

1. Introduction.................................................4 4.3.6 User interface manager.................10

1.2 Intended Audience

1.4 Definitions and acronyms

1.4.2 Acronyms and abbreviations

Acronym or abbreviation Definitions

2. Background and Objectives

General milestones are:

Final product with final project report should be delivered on 20.01.2013.

3.1 Project group

Name Initials Responsibility (roles)

Aleksandar Nikodinovski AN Project leader

Hrvoje Novak HN Team Leader

Nives Bučić NB Requirement manager

Rasul Niyazimbetov RN User interface manager

Petar Stojanac PS Meeting manager

Danijel Jambrečina DJ Database manager

Niklas Gilström NG Design manager

Robert Pofuk RP Implementation manager

3.2 Steering group

4.2 Project phases

4.2.1 Requirements gathering phase

4.2.4 Integration and Testing

4.3 Roles description

4.3.2 Team leader

4.3.3 Requirements manager

4.3.4 Design manager

4.3.6 User interface manager

4.3.7 Usability manager

4.3.8 Documentation manager

4.3.9 SVN manager

4.3.10 Testing manager

4.3.11 Meeting manager

4.3.12 Implementation manager

4.4 Quality assurance

4.4.3 Software Quality

All stakeholders Project plan (v.1) w43 w43 - w43 -

All stakeholders GUI Mockups 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 - - -

All stakeholders Summary Week Report - - - - R_01

All stakeholders Minutes of Meeting - - - - R_02

Members have other courses to Divide work according to

Internal deadlines earlier than

Have more working hours or

Some members have no

low Conflicts Try to resolve on meetings

low Losing database Backup of database

Database manager should fix

low Hardware malfunctions Regular SVN commits

8.1.1 Regular team meetings

8.1.2 Local team meetings

8.1.3 Meetings with the customers

8.2 Google Groups

9.1 Tools and technologies