ManagementReport.doc - Informatics Group Pages Server ...

assistantashamedData Management

Nov 29, 2012 (4 years and 11 months ago)

379 views





System Design Project 2009

Team 5


Vinnie










Management Report









School of Informatics, University of Edinburgh

eusdpteam5@googlegroups.com





































22
/03/09

Rough Ver. 0.5


Stuart Beard

Andrew Diack

Kevin Dor
rian

Thomas Graham

David Kordac

David Moffat

Gavin Potter

Christopher Thompson

John Wilson
-
Kanamori

Table of Contents





1.

Introduction




05

2.

Basic Tenets




07

3.

Methodology




09

-

Group Organisation


1
2





-

Project Planning


1
4





-

Workload Ma
nagement

16

4.

Evolution




18

-

Forming



1
9





-

Storming



20





-

Norming



21





-

Performing



2
4

5.

Conclusion




2
5

6.

References




2
6

7.

Appendix: Minutes



2
8



























"Break it up. Break it up. Okay, tough guys. You want to
box, then get out of my
stadium. Or otherwise, get on with the game. All right? That goes for the rest of ya.
Now get on and play some real football.”


~ Vinnie Jones

1.

Introduction



RoboCup™ is an international programme aiming to foster artificial intelligence and
robotics research by providing a standard problem that is understood universally and
to which a wide range of technologies can be applied. The official ultimate goal of the

RoboCup programme is:


“By 2050, develop a team of fully autonomous humanoid robots that can win against
the human world champion team in soccer.” [1]


To this purpose, the RoboCup programme emphasises the incorporation and fusion of
various informatics t
echnologies including autonomous agents, multi
-
agent
collaboration, strategy acquisition, real
-
time reasoning, robotics, and sensory
processing. There are three different sponsored leagues depending on the size of the
robot; the interest of this particular

project is in the small
-
size league (F
-
180), albeit
with some minor variations in rules and regulations [2].


The most important revision of the regulations for the league in question is that teams
will consist of only one robot, with a corresponding redu
ction in the size of the field
of play and the length of matches. The size of the robot is increased in order to
account for the fact that it will be constructed from Lego NXT Mindstorm bricks.
Regulations regarding the autonomy of the robot, design of the

locomotive and
gameplay
-
related parts, and the rules of play themselves will remain as described in
the Laws of the F180 League 2009 [3],

unless otherwise amended.


The aim of this project team is to design and create a robot capable of competing in
the m
odified RoboCup as specified above. This document is a report indicating how
the team was organised, how the project was planned, how the activities were
scheduled and the workload was managed, and how the system evolved over the
project timeframe. A recor
d of important team meetings at which problems were
discussed and discussions taken has been added as an appendix.


This document follows on from the specification describing the preliminary system
specifications for an entry to this competition [4], and t
he detailed overall description
of the intended system [5]. It is the companion document to the implementation report
[
7
] that describes the particulars of the system itself and what happened during the
construction period.

2.

Basic Tenets



When working i
n a group on a significant technological project, organisation and
management of high quality are vital precursors to success. No matter how
intellectually gifted the individual members of the team, or how excellent their ideas,
if the organizational and m
anagement aspects of the project lack quality then the team
will collectively under
-
perform.


Team building is the process of enabling members of a project to work together
towards a common goal, through their selection, development, and collective
motivat
ion. Project teams are formed for a particular purpose; the mission they share
of completing the project binds them together as a single collective group rather than
a disparate cluster of individuals.


In an efficiently functioning team, all its members w
ork for consensus on decisions
and are vitally involved in the decision
-
making process through the candid sharing of
ideas within the group. The subtext inherent in the sharing of ideas in an efficiently
working team is that all are willing to listen to th
e thoughts of others, and are
respectful and tolerant of individual differences. Efficient team members are those
who are open to criticism and feedback and are willing to take responsibility for their
own work. Dependability, honesty, integrity, and trust

are also all essential traits in
the members of an efficient project team.


There are a number of ways of approaching leadership within the group; using
personal qualities or traits (although this is not objective, since no two people in a
group are goin
g to agree on what are the best or most important qualities, let alone
who has them) [
8
], using the situation (for example, picking a leader based on their
expertise relating to either management or an area relating to the project) [
9
], and
adopting the Fu
nctional Leadership Model, in which there is no single leader, but the
needs of the project tasks are met by members of the team (including but not limited
to the formal leader) [10].


Regardless of the approach taken, the leader of the group is likely to
need to adopt a
democratic style of leadership if the project is to be a success. Partly due to a leader
emerging from a group of peers (rather than being selected by a higher authority),
other types of leadership are likely to fail: a laissez faire leader
ship style is likely to
result in unrest when problems occur, and an authoritarian leadership style is likely to
result in unrest most of the time from other group members who do not feel that the
manager has a mandate or do not feel that the manager is mo
re qualified to make
management decisions than they are. Even if a democratic decision were to be taken
about the leadership of a group, with only nine or ten members, it is highly likely that
the credibility of the leader will be questioned at some point
unless general consensus
is sought on important decisions.


The way in which the team deals with conflict makes a sizeable contribution to
productivity. If teams discourage conflicting views and their expression, and members
develop a reluctance to disrupt

the group harmony, there will be a commensurate
suppression in creativity and innovation. At the other extreme, however, if both
parties in a disagreement are unwilling to make concessions, project work will grind
to a halt. The most efficient and product
ive teams are those that can walk a fine line,
working through any differences even while appreciating the impetus conflicts
provide.


At the other end of the spectrum are teams that find themselves mired in conflict or
are altogether dysfunctional. Weak l
eadership, a culture of blame, rigid processes and
policies, and individual patterns of behaviour can all contribute. The underlying
problem (and the root cause of it, if at all possible) must be identified quickly and
confronted by the group as a

whole, p
referably through the intervention of somebody
in a leadership role. Through ensuring that team members develop an atmosphere of
mutual trust and fluency in healthy debate, and by encouraging personal and team
honesty and integrity, the leader must take re
sponsibility for the team dynamic and
make every effort to improve it. If an individual on the team is viewed as responsible
for causing the problem, then the leader must meet with that individual and attempt to
resolve the situation by identifying the exp
licit problem, exploring options,
reconciling divergent interests, and rebuilding relationships; only in rare cases should
the individual need to be removed from the team.



Project managers must also be on the alert for members who do exceptional work, an
d
must recognise it appropriately. A team whose members are aligned with its purpose,
who relish the challenge of their task, who take personal responsibility for a
successful outcome, and who have a strong sense of camaraderie will tend to sustain
motivat
ion for the project over time and tribulation, and these are crucial components
of success.


There are several approaches that can be taken to project management; regardless of
the approach, careful consideration needs to be given by such management in
ens
uring that project objectives and goals are unambiguous, and that the roles and
responsibilities of all participants and stakeholders are similarly clearly defined. In
addition to traditional waterfall development, other approaches include extreme and
agil
e process
-
based management methodologies, and the Rational Unified Process.


The traditional approach identifies a defined sequence of steps


initiation, design,
production, monitoring, and completion. This rigid structure is ineffective for projects
wher
e requirements are largely undefined or subject to change, and this
ineffectiveness has led to the development of more flexible and iterative processes
that revisit earlier phases throughout the term of the project.


All projects have elements of risk asso
ciated with them, largely because they involve
new activities and innovative work. Projects need to be executed and delivered under
certain constraints, which can largely be divided into project scope, time, and cost.
Most negative risks, or potential fail
ures, can be overcome provided there is enough
planning capability, time, and resources committed. As instances, various tools and
techniques can help to identify all the tasks necessary within the project and to
schedule them within the project time frame
, including the creation of a Work
Breakdown Structure and the use of Gantt Charts, or perhaps even the employment of
a dedicated software package such as Microsoft Project. These methods can also help
to ensure the appropriate allocation of human resource
s during the project. A useful
axiom in such circumstances is to underestimate deliverable deadlines (allowing for
contingency by “padding” them), and to over
-
deliver on the final product.


Once implementation of the project has been initiated, its progres
s must be regularly
monitored to ensure that it does not deviate significantly from plan. Various staff
management or supervisory approaches may be adopted, and intermediate reports
may be produced as part of this process. Group meetings may also be used t
o keep the
members of the project team current on progress and outstanding issues, although
excessive use of meetings that involve non
-
essential personnel often act contrary to
the interests of the project. In every instance, good team communication and pr
oject
manager attentiveness are required.


With projects initiated along these lines, all elements of the lifecycle


specification,
design, testing, and implementation


combined with efficient project management
must of necessity collaborate to produce a

workable end result on time and on budget.



3.

Methodology



The team a
d
opte
d

a

divide
-
and
-
conquer approach to achieve the goals outlined in the
specification document [4]. The project
was

broken down into four
separate

sub
-
projects, with related tasks g
rouped together, so that team resources
could

be
proportionally

assigned
accor
d
ing to priority
and the workload clearly delegated. This
approach
wa
s highly beneficial in terms of management, monitoring and giving team
members responsibility for their work.

On the other han
d
, it
require
d

good
communication between all the sub
-
teams,
at the risk of jeopar
d
ising

the integration
of the completed sub
-
projects d
ue to simple lack of consensus.


At
the first group meeting, team members were divided into relevant su
b
-
teams based
on prior expertise and individual preference, so that they would be able to concentrate
their efforts effectively. Each sub
-
team was given their own specification for their
component, discussed and agreed upon by the
group as a whole

beforeha
nd.
Important
decisions, for example the interfaces between the individual components
, were
established by the entire team; if the considerations were minor, the sub
-
project teams
involved met to resolve the problems themselves.


The sub
-
teams
were inten
d
e
d

to be

large enough such that they
woul
d

be

able to
accomplish their tasks within a reasonable timeframe. On the other hand, they
we
re
also
flexible enough so that people
woul
d

be

able to move between groups as and
when the necessity
arose
. For example, i
f one team finishe
d

earlier than another, or if
a specific sub
-
project f
ell

behind the others to the extent that it
could

no longer
reasonably achieve its set milestones, it
woul
d

be

possible for team members to
transfer

between sub
-
teams in order that tar
gets
we
re met.


During the first few weeks of the project, the majority of the team effort
would

be
targeted towards the hardware and simulation components, with smaller sub
-
teams
looking into vision and strategy. This ensure
d that

the simulation
would be

ready to
be used in testing at an early stage, and that the overall robot design
would remain

fairly static throughout the
majority of the
development cycle. Both of these facts
would

be beneficial to the strategy component, which
could

then absorb some of

the
manpower that concentrated on the first two
components

in the early stages of the
project. Due to its importance

to the project
, the vision component
would

be
concentrate
d

upon

by team members with experience in the field, and
would

be
improved and pe
rfected in an iterative fashion throughout the project timeframe.


Deadlines were set in advance f
or each sub
-
project, so that the team
wa
s aware of
when they need
ed

to finish by. With each deadline, at least a week
was

allowed
before
the work

actually nee
d
ed

to be completed, in order that the project schedule
retain
ed

some flexibility and resilience to unforeseen circumstances. Detailed below
is a Gantt chart of these projected milestones and the lifetime of each sub
-
project.


Figure
3
.1
-

Gantt chart det
ailing the

proposed

development cycle of the project.



The Gantt chart details the major deadlines and workloads for the four major
components in the project. A preliminary design for the actual robot
wa
s expected by
11th February, with all the major mech
anisms and sensors in place. Simultaneously,
programming of the control brick
would

commence, allowing the robot to perform
basic actions such as "goto" and "kick". The simulation code
had

a hard deadline of
the 25th of February, with a short report due in

at the same time; integration of
various components
was

also

a priority for this deadline.


A basic strategy component
was expected to
be ready in time to integrate with the
simulation component, but this
would

be expanded upon and enhanced during the
fin
al stages of the project as well. The same applie
d

to the vision component, as it
would be unrealistic to expect a refined version within a short period of time.


The week between the 25th of February and the 4th of March
was expected to

be
largely dedicat
ed to integrating the various basic components of the system such that
they work
ed

together seamlessly in time for the first round of friendly matches. The
phase marked as for testing on the Gantt chart refer
red

to the testing of the system as a
whole and
wa
s not indicative of a lack of unit and integration testing during earlier
phases of the project; this stage
would

also include enhancement of the strategies and
refinement of the vision component.


The project
would

follow a
n

agile iterative pattern, bas
ed on Boehm's spiral model.
After defining the system requirements in as much detail as possible (the specification
document) and creating a preliminary design (in this document), the project
would

concentrate on producing successive prototypes of the syst
em, gradually closing in
upon the final product whilst simultaneously updating and refining the specification
and design documentation. The project henceforth
would

concentrate upon the
provision of actual working code as milestones, thus creating a visibl
e, tangible
indicator of the amount of progress that the project team has made. This
would

also
grant the project enough flexibility to deal with issues and problems
destined to

arise
during the latter stages of the project, as the team
would be forced to

work to a strict
immutable deadline.


A number of issues
were
foreseen; for example, one of the members of the team
working upon the vision component
would

be unable to concentrate on the project
around the end of February and the beginning of March due to

prior engagements,
thus pushing the deadline for the aforementioned component to a week earlier than
might have

be
en id
eal. Many of the team members
were forced to

balance job
commitments with the project, effectively constraining their productivity, and
all
involved were also faced with concentrated deadlines from other academic courses
around weeks five and ten of the semester. The Gantt chart above incorporated these
concerns into the timeline described, but the project manager
was briefed to

be aware
o
f them at all times, and

to

be ready to adapt the development cycle to the
circumstances as necessary.

3.1

Group Organisation



How the project team was organised and how the members interacted was identified
very early in the project as a crucial factor
to the motivation and efficiency of the
team, and its subsequent ability to deliver the system on time and as specified. This
included the definition of roles and responsibilities and the planning of
communication approaches and strategies.


A
s stated abov
e,

a
divide
-
and
-
conquer approach was
to the project, breaking down the
task at hand into four smaller sub
-
projects with related tasks grouped together. This
allowe
d

team resources to be clearly assigned to in
d
ivi
d
ual tasks and the workload
clearly delegate
d, with team members of similar individual strengths allowed to
concentrate upon the areas of the project in which they could contribute the most. On
the other hand, the need for constant an
d

substantial communication between the sub
-
teams was identified v
ery early in the planning process, such that the integration of
the completed components would be hazard
-
free.


The very first action that was taken by the newly assembled project team was to elect
a project manager, who would be responsible for coordinati
ng the efforts of the team
members, overseeing the general progress of the project, and liaising with the higher
authorities as necessary. After some deliberation concerning the qualities necessary
for the role and the experience of the various members wil
ling to take on the
responsibility, Andrew Diack was elected as the team manager. It was felt that his
prior work experience with similar tasks, combined with his enthusiasm for the
position, made him the ideal candidate.


The remaining team members were a
ssigned to one of four subgroups, largely
according to their respective strengths. Thomas Graham and David Moffat, who had
both taken the Introduction to Vision and Robotics course in the first semester, were
assigned to the vision component, responsible f
or processing the input from the video
feed and interpreting it to a form usable by the system. Christopher Thompson was
identified as the best candidate for the construction of a simulator to emulate the
behaviour due to his background in physics, with Ga
vin Potter and John Wilson
-
Kanamori assisting. Stuart Beard, Kevin Dorrian, and Andrew Diack would
concentrate on the construction and development of the robot itself, while David
Kordac would forge ahead on the creation of strategies to govern the robot’s

overall
behaviour.


The subgroups were intended to be flexible enough to allow for people to switch
between them as required, but by ensuring that multiple team members would be
working on any one crucial part of the project at a given time, they also ret
ained the
robustness necessary to deal with situations such as unexpected personal
circumstances. For example, upon completion of the preliminary robot design,
Andrew and Kevin were designated the task of applying the knowledge gained
through the construct
ion to the creation of software to be base
d

on the robot; Stuart,
on the other hand, was asked to concentrate on refining and upgrading the robot
design as it was placed through a series of tests to determine its suitability upon the
field of play. The com
pletion of the simulation component allowed those team
members involved in its construction to direct their efforts towards less advanced
areas of the project; for example, Gavin (who had also taken the IVR course the
previous semester) offered his service
s in aiding the development of the vision
component, which had fallen slightly behind schedule due to
d
ifficulties in testing for
the various threshol
d
s inherent to the process.


At the same time, it was expected that the calculated subdivision of tasks wo
uld allow
individuals to dedicate time to the various documents expected from the team
throughout the project lifetime. For example, individuals within the appropriate
subgroups were responsible for their own sections of the design document;
presentation a
nd documentation of the simulation component was similarly handled.


A further benefit of the subgroup structure was that a comprehensive picture of the
system as a whole could be obtained from the presence only three or four members of
the team. This allo
wed the integration of the system, originally identified as a major
risk to the success of the project, to proceed continuously and regularly throughout the
timeframe, rather than (for example) in a single hectic session at the end.


The final two weeks of

the project saw a major shift in focus from development and
construction of the system to its refinement and testing. In preparation for the
concluding presentation and documentation of the prototype, particular members of
the team were asked to focus on
presentation ideas and materials


in essence, how
best to market the system to the industrial guests who would be present. The
flexibility of our subgroups, however, meant that this could be done without
sacrificing the necessary testing and refinement of

existing code, as at least one
dedicated team member would remain focused on each component.


Throughout the project, constant communication was maintained between the sub
-
teams via the Google group set up on the very first day, as well as via the various

other electronic resources and aids (team wiki, version control system, etc.) placed at
the team’s disposal. The team met as a whole on a weekly basis during the
specification and initial design stages of the project, with additional meetings
scheduled as

required. Members also maintained a near
-
constant presence in the work
laboratory, and it was extremely rare that fewer than two individuals from the team
were working on the project at any given time.


We believe that this task
-
oriented divide
-
and
-
conque
r approach to the project was
extremely effective in organising the group and dealing with the many unforeseen
circumstances that were encountered throughout the project lifecycle.


3.2

Project Planning



Project planning relates to the use of schedules to

plan and subsequently report
progress within the project environment. After defining the project scope and the
appropriate methods for completing the project, the durations for the various tasks
necessary to complete the work are listed and the logical de
pendencies between tasks
identified. The project plan is then optimised to achieve the appropriate balance
between resource usage and project duration to form a baseline, against which
progress is measured throughout the life of the project.


Much thought
was also given to how the project would be carried out over the strict
time constraints inherent. In addition to the divide
-
and
-
conquer approach described
above, the project was loosely divided into four stages


the specification phase in
which the fundam
ental aspects and functionalities of the system were defined and
established, the preliminary design and construction phase which laid the groundwork
for the project by coding basic functionality and establishing the major parts of the
system, the focal co
nstruction phase which concentrated on actual implementation of
the vast majority of the system functionality, and the refinement and conclusion phase
in preparation for the final presentation.


The four subgroups were each given their own milestone object
ives to achieve within
a preset timeframe, loosely described in the Gantt chart above. A delicate balance was
sought between asking for too much work to be completed in too short a time span
and the necessity of concluding the project within the scheduled
timeframe; the trade
-
off between a rigid definition of the deadlines and the flexibility necessary to adapt to
changing project conditions was also taken into account.


The initial specification phase lasted for a week, at the end of which a Specification
Document [4] was submitted to describe the preliminary system specifications for the
project. The preliminary design and construction phase lasted for a further three
weeks, and resulted in the Design Document [5], detailing an overall description of
the i
ntended system, its component parts, and how they would interrelate.


The focal construction phase could be roughly subdivided into two distinct parts.
During the first two weeks, the majority of the team effort was targeted towards the
hardware and simula
tion components, in order to provide a solid basis for the rest of
the system (ensuring that the simulation was ready to be used in testing at an early
stage, and that the overall robot design remained fairly static for the benefit of the
strategy and visi
on components) and to meet the specified deadline for the Simulation
Document [6] and presentation. Once this functionality was achieved, focus was
shifted to the vision, strategy, and robot software components of the project, in an
attempt to integrate th
ese fully into the system by the date of the first friendly, and to
polish and refine them by the second. The functionality was revisited iteratively and
an emphasis placed on delivering working software components, with testing and
development conducted h
and
-
in
-
hand throughout the entirety of the project.


The final refinement phase lasted for just over two weeks leading up to the final
presentation day, and included such tasks as optimising the vision component and
enhancing the different strategies emplo
yed by the robot to better reflect its
capabilities and the hazards upon the field of play. This phase also saw
commencement of preparations for the presentations by a newly established subgroup
dedicated to the task.


In every phase, deadlines were set in

advance for each sub
-
team such that it was clear
when pieces of functionality were expected by. Each deadline was also flexible
enough such that there was at least a week of leeway before the functionality was
actually required, in order that the project
schedule retained resilience to unforeseen
circumstances. This also allowed for ease of management of task dependencies and
other system constraints.


Given the size an
d

scope of the project, it was perhaps inevitable that there woul
d

be
d
elays in the
d
eve
lopment an
d

d
elivery of certain components. For example, the
implementation of the software
d
esigne
d

for the robot itself overran its sche
d
ule
d

milestone by over a week
d
ue to illness an
d

technical
d
ifficulties. If anything, perhaps
the project sche
d
ules h
a
d

un
d
erestimate
d

the impact that the cumulative effects of
many seemingly minor factors coul
d

have upon the
d
eliverables. On the other han
d
,
given the strict time constraints un
d
er which the project was force
d

to operate, it was
extremely
d
ifficult to bu
d
get more than a week for such issues, an
d

we believe that
the team was able to recover well from a potentially project
-
threatening setback.



3.3

Workload Management



The objective of workload management is to have team members themselves manage
the day
-
t
o
-
day activities required to deliver features at the end of each iteration. Each
individual and the team as a whole are accountable to deliver the results that have
been committed to in the project plan, but how they accomplish the goal was left to
team me
mbers collectively to decide. Within each subgroup, team members were
expected to determine the tasks required to deliver planned features, as well as to
monitor the progress of the tasks and make necessary adjustments.


For example, the initial design pha
se for the hardware component was required to
have produced a prototype robot by the 11
th

of February, followed by the creation of
basic control software by the 25
th
. The three
-
man team was able to achieve their
preliminary goal on schedule, after which St
uart Beard was assigned to continually
upgrading and maintaining the robot itself, while Andrew Diack and Kevin Dorrian
were tasked with designing and implementing the software.


At the same time, Christopher Thompson, Gavin Potter, and John Wilson
-
Kanamor
i
had made significant progress in the implementation of the simulation component; a
basic visualisation unit was complete half a week before schedule on the 13
th
, and the
discovery and incorporation of the JBox2D physics engine resulted in the completion
of a functional simulator by the 19
th
. Testing of the finished product, along with
integration of basic strategies as provided by David Kordac, proved slightly more
troublesome, but a final product was ready in time for the demonstration on the 27
th
.


By t
his stage, a functional vision server infrastructure had been enacted by Thomas
Graham, but David Moffat’s image processing code had hit difficulties regarding
input of the video stream and determination of threshold variables. The timely
intervention of G
avin and Christopher was crucial in establishing a working vision
system by the first friendly on the 4
th

of March. Thankfully, major integration issues
were not encountere
d
,
d
ue to the work of Thomas an
d

John in establishing the
interfaces between the vis
ion an
d

strategy components very early on.


Simultaneously, however, the robot software had also encountered problems,
particularly involving the Bluetooth communication link, the uploading of software to
the Mindstorms NXT brick, and the calibration and u
se of the compass sensor. John’s
support of the sub
-
team was insufficient to counteract illness to both Andrew and
Kevin, and the software that was uploaded to the robot prior to the first friendly had
neither been fully implemented nor thoroughly tested.
Integration issues were also
more prominent between the robot software an
d

the strategy component, as it was
d
iscovere
d

that the character
-
base
d

mechanism originally envisage
d unavoidably

ha
d

to be replaced in favour of an integer
-
base
d

protocol.


Recognis
ing the severity of the issue, a crash programme was initiated to upgrade the
robot software, with assistance from Gavin an
d

Stuart as well. Within the week, in
time for the second friendly, many of the problems had been solved (particularly in
regards to
the communication and upload issues), and the robot was functional on the
pitch. Technical issues with the hardware prevented the team from progressing
beyond the semi
-
finals, but it was felt by all that a much improved performance had
been produced.


Othe
r members of the team had dedicated their efforts to continuous refinements of
their individual components, and the improved strategy (David Kordac and John) and
vision (Gavin), along with functional upgrades to the robot itself (Stuart), contributed
great
ly to a finals appearance in the third friendly. By this time, a dedicated subgroup
had also been formed to prepare for the presentation aspect of the project, headed by
Thomas and with Kevin working on the team website and wiki.


Throughout the project, d
ocumentation of the system was overseen by John, with
individual components written up by the appropriate subgroup members before being
collated into a final document.


We believe that our approach to workloa
d

management allowe
d

a great amount of
functiona
lity to be implemente
d

without the
d
angers inherent in over
-
micromanagement. In
d
ivi
d
ual team members coul
d

i
d
entify areas of priority an
d

request help from others when necessary, an
d

were not constraine
d

by the i
d
eas of
ownership of co
d
e or zealously guar
d
e
d

areas of responsibility. The emphasis on
achieving milestones via
functional d
eliverables also helpe
d

in this approach, as it
allowe
d

team members to i
d
entify an
d

prioritise tasks in a
d
vance.



4.

Evolution



As a project progresses, the group dynamic o
f the project team evolves in tandem. A
number of theoretical models have been developed to explain how a team of people
working together evolves over time. Some, such as Fisher’s theory of decision
emergence [1
1
], view group change as a regular movement t
hrough a series of stages.
Others, such as Poole’s multiple sequences model [1
2
], view them as phases that
groups may or may not pass through and that may occur in asynchronous order.
Perhaps the most famous model of group development is Tuckman’s Stages o
f
“forming, storming, norming, and performing”, which was first proposed in 1965 and
became the basis for subsequent models of team dynamics
[
1
3
].


Forming is the “polite” stage where the team is first formed and tasks and objectives
are identified and ini
tially tackled. The forming stage is an opportunity to meet other
team members and to judge their abilities, an
d

often lasts for only a single meeting.


The storming stage is required for team members to present their ideas about how the
project should be
approached, and about their role within the team. Relationships in
the team, good or bad, are formed at this stage. The storming process is important to
ensure that the team does not simply aim for consensus, or the decisions taken may
not be in the best i
nterests of the team. In a stable project team, the storming process
may last for as many as three meetings, but others may fin
d

it extremely
d
ifficult to
break out of the phase
d
ue to contention an
d

d
issent.


In the norming stage, the team adopts organize
d working practices and team cohesion
improves as implementation is initiated and the project proceeds onwards. Care must
be taken to avoid the stifling of initiative and innovation in favour of group
consensus. This is the stage at which the team first be
gins to settle into an established
work routine and produce actual deliverables, albeit perhaps not as efficiently as
possible.


The final working stage of Tuckman’s model is performing, where all issues have
been resolved, the team has adopted flexible st
ructure, and all effort can be focused on
the task at hand. Hard work leads directly to progress towards the shared vision of the
team’s goal, supported by the structures and processes that have been set up.


Tuckman later added a fifth stage, mourning or
adjourning, to his model, which is the
process of disbanding the team after the completion of the project. This has less
impact than the other stages, and in the context of this group project has little
implication due to the fact that the team does not go

on to do further projects.


The Tuckman model is well backed
-
up by experimental and observational evidence,
and it was worthwhile ensuring that the team and the individuals within it were aware
of the model. This helped to guarantee that the team fully de
veloped to a functional
stage, and that pitfalls such as an inability to break out from the storming stage were
avoided.


The following section of the report will examine the project team as it evolved
through the lifecycle, and attempt to provide analysis

of how the system evolved and
how the members of the group worked together during the semester.

4.1

Forming



The “forming” stage occurred

when the team was
first
assembled
to
confront
the

particular problem
,

by agreeing upon goals and initiating attempts

on individual tasks.
Members of the team tend
ed

to be independent and self
-
focused while they
familiar
ised themselves

with one

another. At this stage,
individuals
exhibit
ed

distinct
behaviours and tendencies, which
would

eventually lead to their continued

contribution to the team in one of many roles.


As stated previously, the very first action that was taken by the newly assembled
project team was to elect a project manager. Team members were then polled for their
respective skill
-
sets, mainly relating t
o the courses they had taken in the previous
semester, in order to determine in which area they could best contribute to the project.
For example, students who had taken Introduction to Vision and Robotics were
deemed to be best suited to develop a working

vision system; similarly, experience in
Software Engineering with Objects and Components was an essential prerequisite for
the person who would oversee the documentation required for the project.


The team then attempted to identify the various technologi
es they would be expected
to work with, whilst categorising and compartmentalising the different aspects of the
project. Another important issue dealt with almost immediately was the question of
how communication would be established and maintained between

the team
members; a Google group was set up for this purpose, and email addresses shared for
facilitating exchange of ideas.


Some of the members of the team had worked together before on smaller projects, but
for many it was the first time that they had
cooperated on a project of this size. Given
the time constraints inherent to the project, however, it was essential that the team
move on to the storming stage as soon as was possible.



4.2

Storming



The team next enter
ed

the “storming” stage, in which d
ifferent ideas compete
d

for
consideration, with the team members attempting to address issues such as definition
of the precise extent of the tasks they face
d

and how they
would

find solutions. This
had the potential to

be an extremely contentious period,
in which

members confront
ed

each other’s ideas and perspectives
. Due to the risk of
out
-
of
-
control storming
destroy
ing

the effectiveness of the team, it was crucial that
this stage be managed as
best possible.


By the end of the first meeting, the project
team had been divided into sub
-
teams
dedicated to individual components of the system, and had initiated discussion of the
various specifications and requirements necessary to successfully complete the
project. A second meeting was scheduled for two days l
ater in order to formalise the
final specifications and to establish various action points that would form the
functional basis for the project (setting up a version control system and a team wiki,
deciding on team name, etc.)


When the team met up for the

third time the next week, the time was ripe for a
concentrated brainstorming session. Priorities were identified


initially, the robot and
the simulation would take precedence, while smaller teams would work on the vision
and strategy components. Interfa
ces between the primary components were debated at
length, as well as the data that would be passed between them; other items discussed
included the overall structure of the system, the programming languages to be
employed, and the desirable features and f
unctionalities of the robot.


In retrospect, the third team meeting was perhaps the most productive in terms of
results, in that much groundwork was laid for the future in a relatively short amount
of time. Although the discussions were lively and many ide
as were bounced around
the table, there was no lack of constructiveness to the debate. Many of the system
diagrams and functional requirements identified and established at this meeting can
still be seen as integral to the final prototype.


The transition
between the storming and norming phases, however, was to be less
smooth.


4.3

Norming



As team members adjust
ed

their interpersonal relationships, teamwork bec
a
me more
natural and fluid, and the team enter
ed

the “norming” stage.

The project team began
to
develop a strong commitment towards the goal, able to ask each other for help and
provide constructive criticism.

The danger here was

if these norming behaviours
took

precedence in team interactions,
stifling
healthy discussion in favour of groupthink


co
nsensus and minimal conflict at the expense of critical testing, analysis, and
evaluation.


The fourth team meeting on the 28
th

of January saw project work begin in earnest as
individual deadlines were dealt with momentarily. The objective of the meeting w
as
to establish the basics of the project design and the outline of the workflow necessary
to meet deadlines throughout the project lifecycle. This was crucial to the future of the
project, as an agreed
-
upon framework upon which workload planning could be
based
would be essential to future project management.


The debate that ensued was vigorous and lively, as opinions clashed as to the
prioritisation of different components, as well as the methodologies used to establish
said priorities. In the end, a comm
on consensus was achieved through negotiation and
compromise, as well as sensible examination of available resources and deadline
constraints. Although strain had been placed upon the integrity of the team, it had
survived unscathed from its first major ch
allenge. It was also clear that groupthink
was unlikely to be an issue, with certain members not afraid to express their opinions
without reservation, and others willing to amalgamate all ideas into an agreeable
accord.


The following weeks saw great progr
ess, as system functionality was implemented
and initial milestones met. The fifth group meeting was held a fortnight later on the
11
th

of February, and served to confirm the progress of the team as a whole towards
the various functional deadlines as well
as a final verification of the Design Document
to be handed in later that day. At this time, the observation was made that both the
robot hardware and the simulation components were making significant progress
towards their proposed goals, and that basic f
unctionality regarding the vision and
strategy components was also in place, such that integration between the components
was already on
-
going. The fifth group meeting ended by setting preliminary
milestones for the next meeting, to be held the next week


initial conceptualisation
for the software to be placed on the robot, completion and integration of the
simulation component, and further extension of the basic functionality of the strategy
and vision components.


By the time of the next meeting on the 1
8
th
, however, it was clear that unforeseen
circumstances had taken their toll on the project. Illnesses to team members had
delayed the robot software component by a significant margin, and unexpected
deadlocks in the vision component, along with the fores
een commencement of the
election campaign of one of the members of the vision subgroup, meant that it too was
struggling to meet its deadline. Even the basic functionality of the strategy
component, thought to have been near completion the week before, had

not been
improved upon


largely due to the individual deadlines that had clustered around the
end of the previous week. Furthermore, with the deadline for the simulation
component looming, it would be difficult to divert resources from other parts of the

project to those most in need.


The response of the remaining team members was to buckle down and concentrate on
attempting to prioritise the workload that had to be accomplished. The project plans
had allowed for such circumstances by providing a week or

so of slack for every
milestone, but even this was pushed to the limit by a combination of further illness
amongst team members, personal non
-
project workloads, and unfortunate
misinformation that caused the team to prioritise some elements of the simulat
ion
component at the expense of other, more critical parts.


Due to the hard work and dedication of the simulation subgroup, potential disaster
was avoided and a successful simulation of the final system was completed and
demonstrated. An important factor
in this was identifying the need to talk to the
relevant course organisers and tutors regarding the situation and to ask for a short
extension (within the constraints of the original deadlines) to ensure that any time lost
could be successfully recovered.
The team also were able to rehearse the
demonstration multiple times in order to gain confidence in describing the simulation
and answering potential questions.


The remainder of the project, however, was also experiencing difficulties, and only
the effici
ent and decisive redeployment of resources prevented the day of the first
friendly from turning into a complete disaster. The simulation subgroup was swiftly
reorganized to support the other sections, with two members assisting the ailing vision
component
and the third moving over to develop the robot software and integrate it
with the rest of the system.


On the evening of the first friendly, it looked as if the situation had been successfully
salvaged; the vision component had made a breakthrough and was
functioning
correctly, while the robot software was nearing a basic level of completion bar a few
minor problems. Disaster struck the next morning, though, when an essential member
of the robot software subgroup was unable to attend due to sudden sickness,

and a
botched SVN commit meant that the working version of the robot software was not
available to those members of the team preparing for the match. Repeated desperate
attempts at recovery failed, and the team was forced to field an incomplete version of

the robot to the field. Unsurprisingly, it failed to win any accolades on the pitch.


Recognising the need for urgent action, a crash programme was initiated to redevelop
and refactor the robot software. Tensions flared briefly between those who wished to

continue developing the existing software and those who advocated a complete
overhaul, but in the end a consensus was reached and a working version of the code
uploaded to the robot in time for the second friendly in the following week. This
resulted in n
oticeably better performance, albeit cut short by technical issues caused
by the innate instability in the beta
-
version LeJOS software used to program the robot.


By the week of the third friendly, the team was back to its full complement of
members once a
gain, and many outstanding issues had been resolved. Constructive
debates regarding extension of the system functionality versus consolidation of
existing implementation resulted in an agreed
-
upon endpoint, and the third friendly
showcased a much
-
improved
performance of all components that combined to result
in a finals appearance. The team had also been reorganised in preparation for the
presentations to be held at the end of the final week, and the focus of the individual
members underwent a fundamental s
hift from the implementation of new code to the
consolidation and testing of existing functionality.


During the final week of construction and consolidation, the team held daily meetings
to ensure that all were aware of the progress being made towards the

final deliverable,
and that any problem areas could be quickly identified and counteracted. Extremely
productive brainstorming sessions were held to determine the content of the
presentations and to finalise technical details.



4.4


Performing



By the f
inal week of the project, the team was showing extremely promising signs of
reaching the stage of “performing”. However, even at the end, it was difficult to say
that the

team was able to function as a cohesive unit to complete the specified task
smoothly
and resourcefully without inappropriate conflict or external supervision.

This is not intended as a
criticism of those involved, as even with experienced
professionals such a transition may take upwards of six months to a year. However,
there were certainl
y a number of factors during the course of the project that, could
they have been improved upon or taken advantage of, would have increased the
team’s chances of attaining this ideal stage. The lessons thus learnt are discussed in
greater detail in the fol
lowing conclusion.




5.

Conclusion



Defining a project as an activity that achieves specific objectives through a set of
defining tasks and the effective use of resources, and by identifying the members of
the project team as an integral part of said res
ources, it can be deduced that both the
development and motivation of result
-
oriented teams and the disciplined planning and
management of goals and objectives are necessary for an efficient and successful
completion of the project. Many of the issues and
methodologies inherent in this
problem have been addressed
in this document
.


We believe that our project team was successful in dealing effectively with many of
the issues that arose during the project lifecycle. Most importantly, the team did not
self
-
de
struct during the “storming” phase of development, and was able to work
effectively towards their goal during the latter stages. Our team was well organised
and the finite resources available channelled capably towards the final product. The
issue identifi
ed at the beginning of the project with the most potential for danger, that
of system integration, was dealt with in a comprehensive and professional manner
resulting in very little problems. Although the team did not quite attain the heights of
“performin
g” seamlessly as a single entity, we believe that we were able to cope with
the vast majority of issues we encountered in order to bring about the successful
completion of project goals and objectives.


On the other hand, we realise that there were many ar
eas in which we could have
improved the performance of the team with regards to such concerns. For example,
although our project plan allowed for a week’s leeway with regards to the majority of
the project deadlines, we had underestimated the destructive e
ffects that one or two
seemingly minor circumstances could have in combination upon the project.
Communication within the group was also often an issue, with many members
choosing to remain silent and non
-
responsive when asked for their opinion upon
matter
s; greater determination in chasing people down via face
-
to
-
face contact or
phone would probably be desired.


The scope and scale of the project perhaps made it inevitable that problems would
occur. However, the team carefully considered the various projec
t management
aspects related to the system beforehand, and planned for them as best possible.
Contingency plans were laid and called into action, and the schedule retained enough
flexibility and resilience that problems could be safely handled without grea
tly
adverse effect on the delivery of final functionality. It is our hope that this document
successfully conveys our confidence in this particular aspect of the project.

6.

References



[1]

RoboCup Official Site,
The RoboCup Federation, 2009 (Retrieved fr
om
http://www.robocup.org/
, 21/02/09).


[2]

System Design Project 2009
, John Butler, Garry Ellard, and Philip Wadler,
School of Informatics, University of Edinburgh, January 2009 (Retrieved from
http://www.inf.ed.ac.uk/teaching/courses/sdp.pdf
, 21/02/09).


[3]

Laws of the F180 League 2009
, The RoboCup Federation, 2009 (Retrieved
from
http://www.r
obocup.org/regulations/4.html
, 21/02/09).


[4]

System Design Project 2009 Team 5 Specification Document
, Stuart Beard,
et.al., School of Informatics, University of Edinburgh, January 2009.


[5]

System Design Project 2009 Team 5 Design Document
, Stuart Be
ard, et.al.,
School of Informatics, University of Edinburgh, February 2009.


[6]

System Design Project 2009 Team 5 Simulation Document,

Stuart Beard,
et.al., School of Informatics, University of Edinburgh, February 2009.


[
7
]

System Design Project 2009 Tea
m 5 Implementation Report,
Stuart Beard,
et.al, School of Informatics, University of Edinburgh, March 2009.


[8]

Leadership: Do traits matter?
, Shelley A. Kirkpatrick, Edwin A. Locke, The
Executive, May, Vol.5 No.2, ABI/INFORM Global pg. 48, 1991.


[9]

Sit
uational Factors in Leadership
, John K. Hemphill, Columbus, Ohio State
University Bureau of Educational Research, 1949.


[10]

Functional Leadership Model,
Leadership 501, 2006 (Retrieved from
http://www.leadership501.com/functional
-
leadership
-
model/20/
, 19/3/09)


[11]

Decision Emergence: Phases in Group Decision Making,

B.A. Fisher, Speech
Monographs, 37, 53
-
66, 1970.


[12]

Decision Development in Small Groups III: A Multiple Seque
nce Model of
Group Decision Development,

M.S. Poole, Communication Monographs, 50, 321
-
341, 1983.


[13]

Development Sequence in Small Groups
, B. Tuckman, Psychological Bulletin
63(6): 384
-
99, 2001.


[14]

System Design Project 2009 Team 5 Wiki,
Stuart Beard
, et.al, School of
Informatics, University of Edinburgh, 2009 (Retrieved from
http://vinnie.kicks
-
ass.org/wiki/index.php
, 19/03/09)


[15]

System Design Project 2009 Team 5 Website,
Stuart Beard, et.
al, School of
Informatics, University of Edinburgh, 2009 (Retrieved from

http://vinnie.kicks
-
ass.org/,

19/03/09)


[16]

System Design Project 2009 Team 5 Google Group,

Stuart Beard, et.al.,
School of

Informatics, University of Edinburgh, 2009 (Retrieved from
http://groups.google.co.uk/eusdpgroup5
, 20/03/09)

Appendix A: Minutes



1.

SDP First Meeting:


14/1/09



Team leader:

Andrew Diack (Project
manager)


experience.



Skillsets:

Stuart Beard


SEOC




CD




Kevin Dorrian


SEOC




Thomas Graham



IVR




David Kordac


SEOC


IVR




David Moffat




IVR




Gavin Potter




IVR




Chris Thompson





CD




John Wilson


SEOC



Tools:

Mindstorms, SVN, Apac
he, Postgresql, Google calendar?



Contact details: Email to be sent out asap to uni addresses.



Specs brainstorm:

Basic specs


hardware, software.





Score


kicking ability





Speed


dribbling





Toughness, size limits





Fine control, turning cir
cle





Recognition


ball, opponents, goal





Retrieve ball in all situations





Future prediction of locations





Split functionality between chip and computer to allow

for unexpected events

Strategy modules


covering instructions for many
situation
s

Redundancy


reconnection protocols, camera problems



Action points:

Thomas


SVN setup, web server machine, wiki.




Andy


Google groups setup, key




Specs


initial final copy for morning next Wednesday






Rough draft by Friday, 10.00 meeting



Fu
rther brainstorming:



Vision:


location of robots, balls, other opponent


Strategy:

literature search for different viable strategies



multiple plug and play strategies depending on situation



dynamic strategies, change between matches?


Robot needs to
communicate with referee, respond.

Robot needs to communicate with Bluetooth server, video images.

Robot needs to maintain a game stae.

Protocol for strategies? Modular components, easily modifiable.


Research into strategies.

Utilise IVR experience


grad
ient map to determine location, strategy.


Simulation for testing strategies


more information, research required.





testing against visual input?





testing against self





testing multiples to find the best.


Robot: multiple speeds?


control the bal
l, convex shape 20%


backspin on ball

dribbling acceptable distance

five minutes power.

obey referee decisions.




Website



Documentation




Team name


logo, motto, etc. Use as much as possible.

Decide on Friday?



2.

SDP Second Meeting:


16/1/09



Actio
n points



webspace up, machine working,

wiki being niggly but there





SVN working





basic spec document up, transfer to GoogleDoc





update over weekend, collate and Latex on Tuesday.



Decision required about programming language.



Vision


gettin
g direction right is difficult. Compass sensor?


Team name Vinnie, robot name Mean Machine.



Next meeting:

Wed 10.00, specification doc complete.

Start thinking about design doc.



3.

SDP Third Meeting:


21/1/09



SVN for document, not GoogleDoc, now it’
s set up.


Specs are fine…?



Backups:

home directories other than desktop are backed up.




regular backups to various locations.



Hardware:

Stuart, Andy, Kevin.


Vision:


Thomas, David M.


Strategy:

David K.


Simulation:

Chris, Gav, John.



Design:

des
ign document by 4
th

February.




hand
-
in by 11
th

February.



Robot and strategy in C or Java?


Simulation in Java (used in physics simulations).


Vision


whatever is necessary (Matlab? Java?)



Vision
-
> PC <
-
> Robot
-
> Action


Simulation models all the a
bove.



Vision:

x,y coordinates of 3 objects, direction of robots

correction for distortion


Simulation:

vision simulation, computer
-
side strategy




robot
-
side strategy, basic actions.




physics code, graphics code, documentation.



Robot sensors:

touch

sensor on each side, light sensor for ball.




compass for direction?



Ensuring consistency: angle (x) vs. vectors, com protocol with robot.

4.

SDP Fourth Meeting:


28/1/09



Component milestones


need exact dates, email Andy.


Gantt chart for design do
cument.



Basic outline of design document up, will start fleshing out ASAP.



Need to get simulation done by 25
th



dependencies!


Work flow clunked out


lively debate… ><


5.

SDP Fifth Meeting:


11/2/09



Gantt chart: milestones for next week.



Andy +
Kevin
-
> hardware programming basics.



John + Dave K.
-
> strategy component basics by next week.



Chris + Gavin
-
> simulation integration.



Dave M.
-
> perhaps slightly behind, Thomas help.

6.

SDP Sixth Meeting:


18/2/09



Missing members: Thomas (presid
ential campaign), both Davids, Kevin.



Simulation:

minor implementations, strategy integration, bug fixing.


Strategy:

logic within classes, integration with hardware.




GUI done, interface with vision up and running.


Vision:


normalisation / threshol
d / identification


25/2?


Hardware:

robot is ready, programming needs to be done!


25/2



Simulation report:

Game plans (John)





Description of classes (Gavin, Chris)





Features list (John)





How it works (Gavin, Chris)





Key problems, fixes (Ga
vin, Chris)


Simulation demo:

Introduce interface, features, run through scenarios



Robot commands:

goTo, turn, kick, getSensor, doDefault.





Set current locations, initialise ends



Rough simulation report: 22/2


Demo runthrough / report check: 14.00 2
3/2

7.

SDP Seventh Meeting:

16/3/09



Implementation, documentation, presentation, consolidation.



Management report:

how group was organised and managed





how project was planned





who did what and when





how the system evolved over semester





In
troduction





Basic Tenets





Forming, Storming, Norming, Performing





Conclusion





Appendix


Minutes



Implementation report:

describe what you did






all information required to understand, modify,

develop prototype






describe system vs. ini
tial specification






what works, what doesn’t, what remains






describe what happened during construction






what went as planned, what didn’t?






Introduction






System Overview






Hardware






Brains






Vision






Strategy






Simulatio
n






Conclusion






Appendices


Blueprints, Javadoc APIs


Overview, Functional and Class Details, Relevant Specification, Testing,


Encountered Issues, Unresolved Problems.




Vision:


Image processing


blobbing



Gavin




Orientation of T




Thomas




Optimisation


on demand vs. broadcast

Thomas




Speed
-
up





David M.


Strategy / Simulation:


Refinement



David K.






GUI update, interface


John






Simulation



Chris


Vinnie:

Light sensor, default behaviours


John




Plate mounting, tweaks



St
uart


BY FRIDAY!



Implementation


delegate to appropriate people


Sunday


Management







Sunday


Presentation


technical, marketing




End of week.



Unofficial friendlies against other teams… over weekend / early next week.

8.

SDP Eighth Meeting:

23
/3/09



Plan for next three days:




Tuesday

-

Implementation:

Vision polishing (Chris)








Strategy testing (David, Gavin)








Simulation (John)





17.00 Meeting:

Presentation brainstorming








Reports check.





Try to get a practice match in.



Wednesday

-

Implementation Report parts
-

17.00






Vision Server (Dave M.)






Image Processing (Chris, Gavin)






Strategy (Dave K., John)






Interface Infrastructure (John)






Robot (Stuart)






Brains (John)





Management Report






John






Thomas, Andy
-

look over





Presentations rough draft.





Code commenting.



Thursday

-

Run around like headless chickens.

9.

SDP Ninth Meeting:

24/3/09



Reports:

Implementation Report


priority, tomorrow evening deadline.








many parts co
mplete.




Management Report


largely complete, update / reread.



Code:


Functionality complete. Only minor tweaks


threshold values,



strategy changes.



JavaDoc:

Only if people have time, not priority.




Large amounts done already.



Presentations:

Technical


boards, brochure. Show that it works!

Boards


Lego brick render, full surrounded by components.



Component diagram, surrounded by class diagrams.



Logo, name, photograph


emphasise brand.

Brochure


work from images, small captions, refer
ence others.





Marketing


key features, brand identity.




Hardware features
-
> brand, extensibility, involving others.




Much productive brainstorming done, outline established!


Write to Gaya regarding:

afternoon use of the G.07 room, clarification
on length

of presentations.