Naked Objects
By Richard Pawson and Robert Matthews
A development process
The specification phase
During specification, the business requirements are formally specified and prioritized, releases planned, costs estimated, and infrastructural implications identified. It is also worth pointing out that it is not until the specification phase that the commitment is made to develop a system - the initial commitment is only to undertaking the exploration phase.
The specification stage starts with getting agreement on the business functionality required either for the complete system, or for the first of a series of planned releases. This will be followed by estimating the resources required to develop and test the new functionality, to integrate it with any existing systems, to provide whatever new infrastructure may be needed, to train the users, and so forth. Much of this sort of planning is conventional, if something of a black art, and we suggest that you use the planning methodology that works for you. However some practitioners have pointed out that Naked Objects does make estimation slightly easier - particularly once you have a couple of such projects under your belt - because all the development effort is focused on the business objects themselves. A sensible approach is to grade the various methods that need to be written in terms of the estimated effort involved, using feedback to translate this into the resources required. (This technique has much in common with 'the planning game' aspect of Extreme Programming).
You will find that the exploration phase eases the initial task of specifying the requirements. Business sponsors will have a much clearer idea of what they require. Some of it will have been simulated in the prototype, some just envisaged and recorded in textual form. And even at the high-level planning stage, it is possible to agree with the customer the capabilities required in terms of objects and responsibilities on those objects. This structure will help, if only a little, in the difficult task of estimating the development effort required.
Writing XP-style user stories
If you are keen on Extreme Programming (XP) then our specification stage can be run according to the principles of the XP 'planning game', wherein the business requirements are now captured as one- or two-sentence stories on index cards and then prioritized into releases. With the object-oriented prototype to hand it is quite straightforward for the users, with a little help from the modeller, to specify each of these stories in terms of specific operations on specific objects. Some examples are shown in the figure.
These XP-style stories were generated for the Executive Car Services system. |
We have arranged this group of seven stories so that they build (approximately) upon each other in terms of functionality and/or complexity. We have found that encouraging users to specify their requirements (for any given release) in order of increasing complexity helps them to avoid getting bogged down in the most complex exceptions early on. In fact it is useful to encourage the users to express their stories in this fashion from the outset: start with the simplest possible case, and then gradually add more complexity. (The stories won't typically follow a single thread of complexity - there might be several quite different such threads in a release.)
The official XP concept is that customers should prioritize the stories for any release, without any interference from developers. We think this is a case where a little guidance from the lead modeller will produce a better result for both parties. The progressive build-up in functionality, combined with the fact that all the stories are specified in terms of operations on an object model that has been tested against multiple scenarios during exploration, gives developers much more confidence to adopt the program-one-story-at-a-time discipline of XP. Refactoring between stories will then typically be at the level of methods, not at the boundaries between objects, which is much better news for the database administrators.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.