OOPSLA 2001 DesignFest®

The Viking

Task

The Viking is the name of a Direct Marketing system. The requirements to this system are available as (written) scenarios or simple stories, each assigned with a priority. You can find the full material here.
In brief: The Viking system supports campaigns to sell products to customers. The customers are contacted via letters. The letters are personalized for each customer based on a template for a particular campaign. The customers have sets of interests w.r.t. the products. The previous sellings are used both for selecting and addressing cutomers. Criteria for selecting and personalizing are required to be very flexible.
The task of the DesingFest team is to develop a design documentation as a prerequisite for the CodeFest team that wants to implement the system during the following days.

The Viking DesignFest Team

Jill M. Aden; Eagan, MN, U.S.
Timothy R. Platt; Tampa, FL, U.S.
Hein Saris; Hasselt, Belgium - Moderator
Matthias Riebisch; Ilmenau, Germany - Recorder

Experience

All of our team brought in a strong experience in object-oriented design and development. Additional skills were such as eXtreme Programming, teaching OO methods, Client/Server systems, project management, Design Patterns and different OO modeling methods.

Expectations

To introduce our team to you, we tell you something about our own expectations to this DesignFest event:
We expected to get to know each other, to work as a team and to develop a nice design solution together. During this work we expected to learn more about the design ideas and the design process of others. And, of course, we expected to have fun during this day.		 Our team - Part 1
Our team: Jill, Tim, Matt ....
Our team - Part 2
.... and Hein

Our 'Process'

After the short introduction and a discussion about our expectations we defined our procedure:
1. Analysis of the classes
2. Design of the static structure
3. Design of the behaviour of the system
4. Documentation of results
Due to the limited time (we had the whole Sunday from 9 am to 5 pm) we decided to keep the design (and the system) as simple as possible. We agreed to consider the priorities of the requirements - eventually we would cut some things off.

Our 'Method'

After beeing acquainted with the requirements we defined our 'methodology' for designing and documenting. We made a mixture out of CRC, the popular Class Responibility Collaboration Scheme, and of the UML class diagram. We used CRC for analizing and for expressing behavioural aspects. The UML notation was used for expressing the static structure, and especially the relations and multiplicities between entities - with the Entity Relationsship Modeling ERM in mind.

Results

Our major design decisions: Because of uncomplete requirements we had to make some assumptions: Have a look at our products:

Conclusion

Looking back, we worked in a quite concentrated way and produced results in a form our CodeFest team could work with - hopefully. We had very interesting discussions. Even if we tried to prevent discussions about 'philosophy'  - in the end this was the most interesting aspect for us: to get to know other's way of thinking, other's mixture of design methods.

Our Lessons Learned list:

  • Requirements are inconsistent
  • we should have a customer to talk to
  • the use of CRC was a good decision
  • mixing methodologies works well - enabling adaptation to specifics of the project and to team skills
  • we should have had a stronger contact to the CodeFest implementation team
Our team during documentation.
Finding the right expression.

We had a lot of fun during DesignFest, and we stayed in contact during the rest of OOPSLA 2001. Our advice to you: Try it out yourself!

last changed Dec 6th, 2001, Matt