Results Of 20072008

Project results

The following is an overview of the deliverables of some of the teams participating in the course edition of 2007/2008. For each deliverable I have included the considerations I have made to come to a judgement. Note that these remarks are limited to essential characteristics only. These remarks are not to be meant to be an extensive review; this has already been partially covered by peer reviews.

In general a good connection between technical solutions/choices and their consequences for quality aspects is lacking. Sometimes teams even have focussed solely on technical aspects and have not made explicit their insights on quality aspects. This is also the case for cost computations. Although left open how to deal with this, a computation of cost should be derived from the architecture artefacts. This relationship is mostly unclear.

Team 1

• Architecture document
  • Extensive use of open source. However, rudimentary OO model only. Extensive quality discussion, but no clear choice. No connection between models & quality aspects.
• presentation
  • More clear choice of chosen qualities in relationship to technicalities. Nice pictures, but the content if the presentation consequently only is communicated orally. Thorough technical knowledge, but implicit bias towards open source inhibits detachment from it, and covers up implicit quality choices.
• review of team 4
  • Covered all (quality + impact + risk analysis), but slides are highlevel.

Team 3

• Architecture document
  • A quality discussion is included, that's good. Extensive use cases. Good OO/logical model. Overall seems well thoughtout.
• presentation
  • Dicsussion of all (or many) quality aspects, but no choice, no connection with technicalities. Also short presentation, hence did not convince.
• review of team 7
  • Good critical reading done (stakeholder viewpoint, cost). Did use impact+risk analysis.

Team 5

• Architecture document
  • No quality discussion. OO model ok, not extensive. Use cases worked out well. No connection between 4+1 elements for argumentation.
• presentation
  • Clearly thought about tradeoff related to conflicting quality aspects, connected this with technicalities, made choices. Well done.
• review of team 6
  • Technical issues noted, quality discussion implicit. Impact+risk analysis done.

Team 6

• Architecture document
  • OO model: no chunk/file modeling, very/too much highlevel. Overall minimally worked out, minimal diagrams etc.
• presentation
  • Focus on plugins, but not worked out thorough enough, no API, not enough technicalities to relate to quality aspects. Apparent choice of quality aspects, but many still without insights in tradeoffs.
• review of team 1
  • Too short/vague, not really dealing with quality aspects nor technicalities. Bias towards personal opinions without proper argumentation. Presentation a bit hindered by use of English.

Team 9

• Architecture document
  • Copied material from IEEE 1471 + Kruchten, not very useful. Poor OO diagram. Scenarios ok, but not split up for roles. No quality model etc. Inclusion of cost model.
• presentation
  • Many diagrams, but too highlevel to be of use in argumentation, not contributing to the connection between technicalities and quality aspects. Use of stakeholders, but unclear how this works out for quality aspects. Technical aspects not worked out far enough to be usable for discussion tradeoffs.
• review of team 2
  • Strong critic on document but completely lacking technical discussion: out of balance. Did not use any assesment technique.

-- AtzeDijkstra - 6 Feb 2008