Page 84 -

3.3 Extreme programming 67

Prescribing Medication
Kate is a doctor who wishes to prescribe medication for a patient attending a clinic.
The patient record is already displayed on her computer so she clicks on the
medication field and can select current medication’, ‘new medication’ or ‘formulary’.
If she selects ‘current medication’, the system asks her to check the dose. If she
wants to change the dose, she enters the dose and then confirms the prescription.

If she chooses ‘new medication’, the system assumes that she knows which
medication to prescribe. She types the first few letters of the drug name. The system
displays a list of possible drugs starting with these letters. She chooses the required
medication and the system responds by asking her to check that the medication
selected is correct. She enters the dose and then confirms the prescription.

If she chooses ‘formulary’, the system displays a search box for the approved
formulary. She can then search for the drug required. She selects a drug and is asked
to check that the medication is correct. She enters the dose and then confirms the
prescription.
The system always checks that the dose is within the approved range. If it isn’t, Kate
is asked to change the dose.
After Kate has confirmed the prescription, it will be displayed for checking. She either
Figure 3.5 A clicks ‘OK’ or ‘Change’. If she clicks ‘OK’, the prescription is recorded on the audit
‘prescribing medication’ database. If she clicks on ‘Change’, she reenters the ‘Prescribing medication’ process.
story.
Sometimes, during the planning game, questions that cannot be easily answered
come to light and additional work is required to explore possible solutions. The team
may carry out some prototyping or trial development to understand the problem and
solution. In XP terms, this is a ‘spike’, an increment where no programming is done.
There may also be ‘spikes’ to design the system architecture or to develop system
documentation.
Extreme programming takes an ‘extreme’ approach to incremental development.
New versions of the software may be built several times per day and releases are
delivered to customers roughly every two weeks. Release deadlines are never
slipped; if there are development problems, the customer is consulted and function-
ality is removed from the planned release.
When a programmer builds the system to create a new version, he or she must run
all existing automated tests as well as the tests for the new functionality. The new
build of the software is accepted only if all tests execute successfully. This then
becomes the basis for the next iteration of the system.
A fundamental precept of traditional software engineering is that you should
design for change. That is, you should anticipate future changes to the software and
design it so that these changes can be easily implemented. Extreme programming,
however, has discarded this principle on the basis that designing for change is often
wasted effort. It isn’t worth taking time to add generality to a program to cope with
change. The changes anticipated often never materialize and completely different
change requests may actually be made. Therefore, the XP approach accepts that
changes will happen and reorganize the software when these changes actually occur.