Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
Project plan
Revision history
Version Date
0.1
2005-02-08
Editor
Fredrik Hellman
Remarks
Summary
This document is produced as the project plan for the 2005 IT Project, Ringhorne, at Uppsala
University. The goal of the project is to construct a robot system consisting of two robots
designed to, as a team, enter an unknown, partially damaged building. When inside the
building the robots will generate a map of the structure of the building and the location of any
human victims. The robots will function autonomously.
Distribution
This document will be distributed to the customer, the course homepage, the official
documents folder, and inserted into the project CVS.
- 1 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
Project Identity
Project
Construction of Robocup Rescue Robot League robots
Project members
Torkel Danielson
Markus Elving
Fredrik Hellman
Henrik Hofling
Robert Koskinen
Mikael Laaksoharju
Kaveh Mehrabi
Carl-Johan Otterheim
Dan Pettersson
Per Svensson
Stefan Varnelid
Erik Winter
toda9439@student.uu.se
mael7487@student.uu.se
frhe1845@student.uu.se
heho5769@student.uu.se
roko3379@student.uu.se
mila3061@student.uu.se
kame2637@student.uu.se
caot4969@student.uu.se
dape8305@student.uu.se
pesv6835@student.uu.se
stva0799@student.uu.se
erwi1845@student.uu.se
Homepage
http://www.robocup.it.uu.se/ringhorne
Responsible for
the course
Jakob Carlström
- 2 (15) -
jakob.carlstrom@it.uu.se
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
Table of Contents
1
2
3
4
5
6
7
8
Project Description ............................................................................................................. 4
1.1
Background ................................................................................................................ 4
1.2
Goals........................................................................................................................... 4
Deliverables ........................................................................................................................ 5
2.1
Team Description Paper ............................................................................................. 5
2.2
Robot System ............................................................................................................. 5
2.3
Final Report ................................................................................................................ 5
Document Plan ................................................................................................................... 6
3.1
Document Responsibilities ......................................................................................... 6
3.2
Documents .................................................................................................................. 6
Time Plan ........................................................................................................................... 7
4.1
Week Plan .................................................................................................................. 7
4.2
Milestones .................................................................................................................. 7
4.3
Deadlines .................................................................................................................... 7
Organization Plan ............................................................................................................... 8
5.1
Responsible Persons ................................................................................................... 8
5.2
Responsibilities .......................................................................................................... 8
Risk Analysis.................................................................................................................... 11
6.1
Risk Surveillance...................................................................................................... 11
6.2
Identified Risks ........................................................................................................ 11
6.3
Handling Risks ......................................................................................................... 12
Communication Plan ........................................................................................................ 13
7.1
Meetings ................................................................................................................... 13
7.2
Webpage ................................................................................................................... 13
7.3
E-mail ....................................................................................................................... 13
7.4
Telephone ................................................................................................................. 13
Test Plan ........................................................................................................................... 14
8.1
Overview .................................................................................................................. 14
8.2
Test Phases ............................................................................................................... 14
8.3
Documentation ......................................................................................................... 15
- 3 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
1 Project Description
1.1 Background
Our project complies with the rules of the RoboCup Rescue Robot League in Japan 2005. The
robots should be capable of entering an unknown, partially damaged building, build a map of
its structure and map the location of human victims. The robots should work as a team and
work autonomously.
A simulation environment (USARSim) will be used to test algorithms for searching the
buildings as a team.
1.2 Goals
Our goal is to successfully deliver robots according to the requirement specification and to
win the RoboCup Rescue Robot League in Osaka, Japan in July 2005.
- 4 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
2 Deliverables
2.1 Team Description Paper
The team description paper should be delivered to the RoboCupRescue Robot League
organization before February 15 2005. The paper should be in the format specified by the
RoboCupRescue Robot League.
2.2 Robot System
The robot system should be delivered and demonstrated to the customer on May 31 2005. The
robots should follow all specifications from the requirement specification approved by the
customer.
2.3 Final Report
A final report on the project should be delivered to the customer on June 3 2005.
- 5 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
3 Document Plan
3.1 Document Responsibilities
3.1.1 Editor
The editor bears the main responsibility for the document. This means that the editor is
responsible:
 for finishing the document before the deadline
 that the work between the co-writers is coordinated
 that the text does not contain errors
 that the document is distributed to the parties concerned
 that the document is maintained
3.1.2 Co-writers
The co-writers are also writing the document. This means that they are responsible for:
 writing the sections in the document agreed upon with the editor.
The co-writers are appointed by the editor.
3.2 Documents
3.2.1 Project Plan
Includes organization, time plan, test plan, document and project information.
Editor: Project manager
3.2.2 Requirement Specification
Specification of the requirements.
Editor: Project manager
3.2.3 Design Specification
Specification of the system design.
Editor: Robert Koskinen
- 6 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
4 Time Plan
4.1 Week Plan
Week
Feasibility study
Definition
Design
Implementation
Test
Project completion
4
5
6 7
8 9
10 11 12 13 14 15 16 17 18 19 20 21 22
4.2 Milestones
3/2
Requirement’s specification and other administrative work done
3/3
Working robot, project plan and design specifications done
4.3 Deadlines
15/2
Delivery of team description papers to RoboCup.
29/3
All tests specified for functionality to demonstrate in review I.
31/3
Review I. Demonstration of functionality negotiated with customer.
30/4
All tests specified for functionality to demonstrate in review II.
19/5
Review II. Demonstration of functionality negotiated with customer.
27/5
All tests specified for functionality described in requirement specification.
31/5
Final presentation and delivery of robots according to requirement specification.
- 7 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
5 Organization Plan
5.1 Responsible Persons
Position
Project manager
Technical coordinator
Simulator group leader
Document manager
OpGUI group leader
HW group leader
Design manager
Customer contact
Webmaster
Software support
Information and PR
System administrator
Member
Fredrik Hellman
Torkel Danielsson
Torkel Danielsson
Dan Pettersson
Kaveh Mehrabi
Per Svensson
Robert Koskinen
Fredrik Hellman
Henrik Hofling
Different for each software application
Dan Pettersson
Per Svensson
5.2 Responsibilities
5.2.1 Project manager
The areas of responsibility of the project manager are
 to briefly plan and continually follow up the work
 to divide the workload properly between the team members
 to establish and conduct weekly meetings
 to inform the instructor of the status of the project
 to ensure that information flow within the group
 to follow up the risks in the project
 to produce a project plan
5.2.2 Technical coordinator
The areas of responsibility of the technical coordinator are
 to have knowledge about the technical solutions in all parts of the project
 to assist the project manager with administrative help when needed
- 8 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
5.2.3 Simulator group leader
The areas of responsibility of the simulator group leader are
 to have knowledge of what is going on in the simulation part
 to inform the project leader of the status of the simulation part
 to have the delegated responsibility from the project leader to plan the work for the
simulator group and to divide the workload within the group
5.2.4 Document Manager
The areas of responsibility of the document manager are
 to produce a template for the documents published
 to produce a document plan
 to educate the team members in using the CVS
 to ensure that the structure in the CVS is maintained
 to educate the team members in version management of documents
 to regularly make sure that backups of files is done
5.2.5 OpGUI group leader
The areas of responsibility of the OpGUI group leader are
 to lead the work of constructing an Operator Graphical User Interface
5.2.6 HW group leader
The areas of responsibility of the platform group leader are
 to have knowledge of what is going on in the platform part
 to inform the project leader of the status of the platform part
 to have the delegated responsibility from the project leader to plan the work for the
platform group and to divide the workload within the group
5.2.7 Design Manager - Platform
The areas of responsibility of the design manager are
 to lead the design work for the robot system
 to produce a design specifications document for the entire system, together with the
simulator design manager
5.2.8 Customer Contact
The areas of responsibility of the customer contact are
 to manage the communication between the project group and the customer
 to keep the customer (instructor) informed about the status of the project
- 9 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
5.2.9 Webmasters
The area of responsibility of the webmasters is
 to keep the team page up to date
5.2.10 Software Support
The area of responsibility of the software support is
 to have sufficient knowledge of the software
5.2.11 Information and PR Manager
The areas of responsibility of the information and PR manager are
 to handle external information and PR
 to form a group for this area
 to produce text to the homepage
5.2.12 System Administrator
The areas of responsibility of the system administrator for the platform are
 to handle contacts with external computer administration
 to administrate local computers
- 10 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
6 Risk Analysis
This chapter describes different risks that can appear in the project and how these will be
handled and also actions to minimize risks.
6.1 Risk Surveillance
The project leader has the over all responsibility to watch over known risks and search for
newly arisen risks. All project members shall, when a new risk is noticed, report this to the
project leader. If needed a crisis meeting can be summoned when a new risk is discovered.
6.2 Identified Risks
This chapter describes identified risks. These will be graded according to the probability that
they occur and how serious they are.
6.2.1 Degree of Probability
The degree of probability (P) describes how likely it is for a certain risk to occur. The
different levels are:
1. Small risk: The problem occurs not more than one time, but probably not at all.
2. Medium risk: The problem will most likely occur, but only a few times.
3. Great risk: The problem will occur some time and probably more than 5 times.
6.2.2 Degree of Consequence
The degree of consequence (C) describes how much damage a risk causes. The damage is
measured in hours it takes to correct it and is graded according to the following:
1.
2.
3.
4.
Small damage: Less than 3h delay.
Medium damage: Between 3 and 15h delay.
Great damage: Between 15 and 30h delay.
Extreme damage: More than 30h delay. Could seriously damage the project.
6.2.3 Risk Table
Below is a table showing identified risks, how they will be handled and how they affect the
project.
P
3
2
2
C
1
2
1
Description of Risk
Short absence of group member
Long absence of group member
Absence of supervisor
1
2
2-3
3
1
1
2
3
Damaged hardware
Underestimating the complexity of the
final product
Not implementable demands
Not implementable design
- 11 (15) -
Measure Taken
Replaced if needed
Replaced
Talk to another person in course
management
Early testing
Re-negotiate demands
Re-negotiate demands
Re-design
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
2
2
1
3
Absence of customer
Delayed delivery of HW
See absence of supervisor
Alternative supplier
6.3 Handling Risks
This chapter describes how we work to prevail risks, and measures taken if they occur.
6.3.1 Group Related Risks
Shorter absence of project members is impossible to avoid. In the case of planned absence the
project leader shall be informed. The project leader then takes this into account in the
planning. In the case of absence the project leader or the group decides whether a replacement
is necessary or not and who will replace the absent member.
Absence in different forms may require re-planning of the projects resources or time plan.
6.3.2 Course Related Risks
The problem with an absent supervisor is avoided by continuous contact with that person. If a
supervisor is unavailable we try to find another person to answer our questions.
6.3.3 Resource Related Risks
If damaged hardware is found it is either replaced, a way to work around it is found or design
is re-done.
6.3.4 Product Related Risks
To prevent underestimation of the complexity of the final product and that the design and/or
demands are not possible to implement, people responsible for design, implementation and
testing has to cooperate and communicate and take part of each others respective area of
responsibility. If the complexity is estimated wrongly we may have to re-negotiate the
demands.
If ordered hardware is not delivered on time we must consider using other suppliers.
6.3.5 Customer Related Risks
The absence of the customer is present in this project and is dealt with by an on-going
communication between the customer responsible and the customer. This prevents major
difficulties in the dialogue and in the event of re-specified demands. Customer responsible
reports to the project leader and the project group during meetings.
- 12 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
7 Communication Plan
This chapter describes the project group’s channels for communication and reporting.
7.1 Meetings
The project group will have meetings every Monday at 10 AM to discuss what has been
accomplished the last week, and what need to be accomplished the forthcoming week. These
meetings take place in room number 1029 at Polacksbacken, Uppsala. Time and place may
change slightly if needed.
There are mainly four types of meetings
- Project meetings, formal meetings with all the project such as the weekly meeting
- Group meetings, formal meetings with a subgroup
- Customer meetings, formal meetings with the customer
- Informal meetings, all other meetings
For the formal meetings a protocol should be written and put in the meetings folder. If any
decisions are made that affect other documents the changes should be performed according to
the change plan found in the quality plan.
7.2 Webpage
General information about the project can be found at the external webpage at address
http://www.robocup.it.uu.se. On that page a link to the internal web site is found.
7.3 E-mail
The project members are expected to read their e-mail daily. The e-mail addresses of all group
members can be find in the Project identity. All project members can be addressed by emailing to ringhorne@list.it.uu.se.
7.4 Telephone
Telephone numbers of project members can be found on the contact list available both in the
arena room and the project room.
- 13 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
8 Test Plan
This chapter describes the applicable guidelines for module tests, integration tests, system
tests and acceptance tests. Also, descriptions of routines and methods to be used during the
different test phases are described.
8.1 Overview
Well-functioning testing is an integral building block for any successful project. These are
some of the basic ideas that make testing successful:
 Tests are supposed to find errors, not verify correctness.
 Testing possibilities should be considered already at the system design phase. This
simplifies the testing, and reduces the risk for errors.
 The implementer of a module should not design test cases for his/her own unit, since
this can lead to design misunderstandings passing unnoticed.
 The implementer of a module should not test his/her own modules without the
presence of an independent observer.
 Before the test cases are run on the module, expected test results should be calculated.
After the testing the calculated results and the measured results are compared.
 All tests should be properly documented. These documents are used to evaluate the
quality of the system.
 All tests should be reproducible.
All tests should be performed according to the following plan:
1. Select a target for the test
2. Decide how the tests should be accomplished.
3. Construct the test cases.
4. Calculate the expected test results.
5. Perform the test.
6. Document and evaluate the outcome of the test.
7. Decide whether or not new test needs be performed once discovered errors have been
corrected.
8.2 Test Phases
Implementation and testing shall be performed in parallel to as large an extent as possible.
Tests shall be performed in the following four phases:
8.2.1 Module Tests
Every module shall be tested as soon as it is implemented. The test cases can be constructed
as soon as the module design has been established, which will condense the testing time.
8.2.2 Integration Tests
The individual modules shall be tested against each other, to evaluate whether the interfaces
work as expected.
- 14 (15) -
Uppsala Universitet
Department of Information Technology
Ringhorne 2005
Project plan
Editor: Fredrik Hellman
8.2.3 System Tests
When all integration tests are finished, the system test begins. The system is tested as a whole.
8.2.4 Acceptance Tests
These tests are performed together with the customer, to verify that the finished system
complies with the original specification.
8.3 Documentation
Each test shall be documented in a test protocol. Apart from a clear specification of what is
being tested, and for what purpose, each test protocol shall contain two sections:
1. Test plans and test case specifications.
2. Test report with short discussion.
- 15 (15) -