Today's goals
=============

1) Look at the generic aspects of the project.
2) Review common misconceptions about groupwork in SDCS.
3) Consider general group processes
4) Address ways to assist the progress of the group. 

1) Look at the generic aspects of the project.

Project to produce a largish piece of software in groups of 7 over a
year. 

Naive view: if the system compiles then we pass!

Problem: the project is too large to "wing it". 

This is like turning up for a footrace without 

 - training, 
 - a coach, 
 - diet plan or 
 - sports psychologist.

The difference is that in software development you won't even finish
the race (more like the Sydney-to-Hobart Yacht Race).

Poor process is a major cause of failure in software projects.  This
project has been designed to test your abilities to manage the
software development process. We will also assess your: specification
and design, testing, documentation, quality assurance.

2) Review common misconceptions about groupwork in SDCS.

Naive view: I only want to work with people like me.

Problems: 

	The project requires a range of production skills:
understanding the theory, good design, interfaces, coding, designing
tests.
	The project requires a range of process/group skills:
leadership, management, archiving, documentation, organising, etc.
	

Naive view: I can avoid group issues by 

 - Only working with friends. 
 - Minimising involvement with the group by:
	working hard on artefacts
	not working at all
	only doing what I'm told (avoiding responsibility)
 - Get the teacher to protect me. 

Problems with these approaches.

 - Only working with friends. 

		Conflict is a natural part of group work. Working with
	friends reduces personal conflicts but doesn't resolve
	intellectual conflicts. You have to be able to handle these
	without losing your friends. You may not get the right mix of
	skills. Your first job is unlikely to be with your friends.

	Make friends of your group - not a group of your friends. 

 - Minimise involvement with the group by:
	working hard in isolation

		You may be ignored/disliked. Poor contribution to the
	group will produce a lower mark than product alone would
	warrant.

	not working at all

		Death. 

	only doing what you're told (avoiding responsibility)

		This hurts the group at minimum risk to the
	individual. In its worst form it means not pointing out flaws
	in the design so as to avoid conflict.

 - Get the teacher to protect me. 

		Doesn't work. 

Naive view: We'll sort out the mark division later.

Problem: This gets harder as time passes. Team members need to
allocate their time productively, to maximise their marks.  The group
needs to get all the tasks done to maximise its mark. There's a lot to
do, and it should be done early.



Fact: problems with group organisation are most likely to become
visible when allocating marks for the first submission. 

 - everyone is tired and stressed.

 - no mechanism for sorting out differences.

	"I've put in more hours than you!"
	"Your work sucks!"
	"You didn't help with integration!"

Whenever we see these disputes it is invariably the case that not one
of the assertions made can be substantiated by evidence. Even if the
facts can be established there is the problem of 

	"That's not what we agreed!"

A consequence of confusion here is that everyone tends to get the more
or less the same mark, so as to keep the peace. This disadvantages the
hard workers, and rewards the soft workers, who may not know that they
are underperforming compared to the rest of the group.

Solution: establish a PROCESS for allocating marks. It should include
elements of 

 - attendance at meetings
 - contribution of ideas, concensus building
 - maintaining records
 - individual time spent on group activities
 - artefacts produced
 - meeting deadlines