Clearly the design process impacts on both the product artefacts and the group dynamics. So if discussing the process helps to clarify what was produced and why (report) that is fine.

Software design processes are to some extent about design itself (e.g. being clear what you want - requirements - before deciding how to do it - specification - and only then actually doing it - implementation) and so just as imp. for individual as group. However, one of the driving reasons for clear processes has been to enable development teams to work together. To this extent software design processes are similar to other large-scale complex design exercises (e.g. designing the millennium dome or a new car range).

The concerns of traditional software engineering are about the pragmatics of group working - how to ensure that the individual work of different people with different skills combine to produce a coherent product that works. Only a small amount of this involves actual collocated concurrent group activity - design meetings etc. - and these are precisely the parts SE processes say least about.

The complementary aspect is the finer details of group dynamics including interdisciplinary interactions - how one deals with the different concerns, styles of work etc.

In a traditional process many of the critical decisions that involve these aspects would be taken OUTSIDE the process (e.g. whether to use a formal process and if so which one to use) and others codified within a generic or specific process plan (e.g. usability consultants produce a user needs analysis document the gets passed to ...).

Given the short time frames and unclear and changing requirements of many 'hot' technologies - these two issues do get mixed more finely - deciding fine details of process as one is doing it, frequent intense design discussions simultaneously including many stages of analysis (user concerns, client brief, business objectives, implementation constraints). So the fine details of the development process (e.g. how you negotiated work division and how it worked) are particularly relevant for group issues as are observations about how these fine details differ at different stages of design.

Be careful in the essay not to end up with a general essay about group design that you could have written if you had never done any! Although I warned about being too personal in comments about one another, it is also critical to relate the literature to your experience in the CDP.

Each of you will have very different slants on both the design work and the group issues and we will therefore have quite flexible marking criteria. So, if, we find something in one that we would have expected in the other we WON'T say "hard luck, in the wrong place, no marks for that". We are not interested in finding out what you don't know or can't do, or whether you can follow formulaic rules, but wewant to see what you do know and how you think and write about it. If you produce a report and essay each with internal coherence and because of the structure of your argument something isn't exactly where we might have thought it would have gone, we won't complain.