DesignFest

Managing Enrollment Policies for Insurance Plans

OOPSLA 2001 DesignFest^® Problem

The DesignFest Team

Jay Coskey
Ralf Reissing - moderator
Leif Rilbe - recorder
Sanjay Shitole
Judy Zeitler

The Result

The models we produced are here.

The Process

We introduced ourselves briefly. Each participant received a copy of the problem statement. We proceeded to read the problem statement individually. One participant wrote down candidate classes on sticky notes during the reading.

Evolving the Analysis Model

After the reading, we proceeded by spreading out the candidate classes (the sticky notes) on a large sheet of paper. We talked briefly aobut each candidate class so as to make sure everyone in the group had the same understanding of what they represented.

The initial list of candidate classes look something like this (I didn't think of recording this list at that point in time, so it might be not completely accurate):

Insurance Plan
Type of Insurance Coverage
Participant
Employee
Customer
Level of Coverage
Work/Life Event
Change Rule
Payment Rule
Option
Cost per Option

At this stage we talked with the domain expert (i.e. the author of the problem statement). We then found some additional candidates, and changed the names of some candidates in order to reflect the terminology used by the domain expert.

After this the list of candidates looked something like this:

Benefit Plan (=Insurance Plan)
Benefit (=Type of Insurance Coverage)
Participant (=Participan, and also =Employee)
Customer
Option (=Option, and also =Level of Coverage)
Work/Life Event
Change Rule
Payment Rule
Cost per Option
Election (which is each participant's choice of benefits/options)

At some point we also introduced a few new classes not directly present in the problem statement:

Insuree, to represent "the beneficiary" of a chosen benefit, since beneficiaries need not be the same as the actual participant. They can also be the participant's spouse or dependents.
Participant Profile (basically an attribute list for Participant attributes)
Insuree Profile (ditto for Insuree)

The rationale for the Profile classes had mostly to do with the cost calculations for different benefits. In order to support new costing schemes, with possibly new bases for calculations, there must be a specific place in the model where such new calculation bases can be introduced wihtout too much disruption. The Profile classes provide this specific place.

Now we played around a little bit with our candidate classes trying to figure out what this problem was really all about. Basically we did this by trying to figure out how the classes related to eachother, association names and cardinalities. There were two main sets of issues:

how to represent the possible choices that could be made by different participants (i.e. the agreement between the customer and the insrurance company)
how to represent the choices actually made by each participant (i.e. the agreement between the participant and the insurance company)

At this point it seemed that we had some problems with the Benefit and Option classes. When they were used for representing the participant choices, they had a cardinality of one or more per participant. When they were used for representing the possible choices, they really should only exist once, regardless of the number of participants (since the Benefits and Options are agreed upon between the insurance company and the customer, well before the first participant ever enters into the system.). We resolved this by dividing each of these classes into two separate ones¹. We also did this for the Work/Life Event class. Thus:

Benefit was split into Benefit (the choice made by the participant) and Benefit Type (the possible choices)
Option was split into Option (the choice made by the participant), and Option Type (the possible choices)
Work/Life Event became Work/Life Event (actual events that have taken place), and Work/Life Event Type (the possible types of events, used for managing Change Rules)

After this we were rather confident about our class associations and proceeded to draw a these on out large sheet of paper. We only considered the names and cardinalities of the associations (much like the conceptual perspective mentioned in "UML Distilled", by Martin Fowler).

We now went on to think about how the different use cases could be implemented with our identified classes. Each team member was assigned two use cases. We took some time to read through the assigned use cases and think identify how the main responsibilities could be divided among our identified classes. Then we presented this to the other team members verbally. This worked out without any major holes being identified and so we felt pretty content that our analysis-level model was ok.

Getting to Design

Having reached a pretty stable analysis model, we started to look more closely into the more central issues on a more detailed level. We did this by examining use cases 3-9 which all deal with participants managing their elections. The most complex problem here was the rules that govern how participants may change their election after different work/life events occurr. This also opens issues to with how and when to enforce these rules.

Here we made a few general decisions/observations:

users (participants) will not be able to edit election properties that are not valid for change (as interpreted by the Change Rules)
user entries still need to be post-validated (since work/life event updates may occur during user sessions)
validation of available credits will only be done at post-validation
only complete elections will be saved (i.e. post-validation only needs to consider complete elections, not different subsets)

Team Experiences

At the end of the session, we made a short reflection brainstorm. Issues that came up:

Meta-modeling, types modeled out in the analysis model, was a new experience for some team members
The ego-less teamwork was enjoyed
Early planning of package dependencies was a new experience for some team members
Team members got an oppurtunity to brush up on UML
Working closely in a team brings up many different perspectives
Requirements understanding takes a long time (almost all the time was spent in what should probably be called analysis rather than design)
Reaching consensus and mutual understanding takes time

Recorder's Reflections

We would have done well in having a more in-depth discussion about how to proceed with the use case realizations. We ended up doing this pretty sloppy. Maybe this was good enough for validating the kind of analysis-level model that we had, but we missed out on the opportunity to discover more design-level classes which could probably have been one beneficial outcome of a more serious attempt at realizing the use cases.
In hindsight, it might have been useful to have more of an up-front discussion about the overall process. As it were, we kind of just ran off in a certain direction without very clear objectives. More discussion would probably have meant that each team member would have learnt more from the others.