contact us
about us
site map


SOA & UML course in Stockport
(near Manchester)

22nd September 2008

Web Usability Patterns Site

Web Usability Products & Services

A comprehensive tutorial on UML

your requirementscustom solutionsexpert helpwhitepapers

  development process

Changing requirements and rapid feedback

Any development process has to cope with ambiguity and change in the requirements.  The requirements are rarely clear at the start of a development, despite the best efforts of the analysts; the installation of a system or new features inevitably changes the users' working practices, and thereby their requirements; and in any case, the world changes and the consequently so do the requirements.

For this reason, all modern development processes are incremental. They all focus on a short loop between the end users and the developers. Users (or at worst, analysts representing them) should be part of the development process. The sooner we can put something before them and get their feedback, the sooner we can get a clearer picture of what they really need, and work on that.

This fundamental motivation has been the driving force behind the recent move towards agile methods.  In their wake have come a range of agile technologies, from testing tools to online project managers.

Feedback from working software

Where possible, we show the users actual working software at an early stage, and then improve on it using their feedback.. Tactics for minimising the loop time include:
  • Component based development, in which each usable software product is built from ready-made components plus a variable amount of 'glue'.
  • Minimise the amount of 'ceremony': analysis, documentation, and bureaucracy. Don't reduce QA, but integrate it intimately into the design process. These are among the practices of eXtreme Programming.
  • Deliver a 'vertical slice' first, chosen to get the maximum useful feedback from the users (by giving them functionality that they can minimally but realistically try out; or giving them something that enables them to experiment in the fuzzier areas). One of the benefits of object oriented programming is that it makes it easy to extend or restructure the slice later.

Feedback from model-building

It isn't always possible to build enough software early enough to get effective feedback. There may be no components available; the minimal useful slice may still require a great deal of programming and risk not giving an overall picture. (These conditions often apply when venturing into a new field; by contrast, where there are many similar programs available, the components and the understanding of what's required are all there.) In this situation, we need to build models, simulations and scenarios, and take the users through the requirements on paper or as a slide show. Using coherent modeling techniques like those of Catalysis™, we can generate many questions to the users that would not otherwise have been thought of.

Models and higher ceremony are also important in designing reusable components, since we don't know what other components any one othem will be coupled to in a working product.

Incremental development

Whether or not the earlier cycles involve building models or software, the idea of incremental development is that something tangible is produced every cycle. A cycle may be from three to six weeks; it's always the same within a particular project. A regular visible delivery is good for morale: it makes everyone --- developers, users, management --- feel that we're definitely getting somewhere, and gives a clear idea of how the project is progressing.

Cycle deadlines are never slipped in incremental development; neither is quality reduced. Instead, goals for a cycle are dropped if necessary. This technique is called 'timeboxing'.
In order to achieve this, each cycle has a prioritised list of goals. The list must be a mixture of 'Must haves', 'Should haves', 'Could haves', and 'Would like to, but probably never will haves'. Because there are always lower-priority goals in every cycle, it is possible to drop goals without compromising the main track of development.

Iterative working

The premise of iterative working is that you don't know enough initially to be able to plan the whole job in fine detail: part of the job is itself to discover that information. All design work, like scientific discovery, has something of this nature. Contrast it with steel manufacture or bread-making, in which the timings and detailed tasks of each stage in the process are known exactly in advance. Management techniques applicable to predictable processes are therefore not so successful with discovery processes. Software is usually somewhere along the spectrum from pure discovery to utter predictability.
The idea of iterative working is to manage the risks, and timeboxing is one of several risk management techniques.

DSDM  highlights four major activities. However, each of them may occupy several iterations. Each iteration begins with a choice of task: it may be the definition of an interface, the design of a feature of the system, or perhaps a mock-up demo for the users. A strong criterion for the choice of task in any iterative method is that it should give you useful feedback that will shed light on the plan for the future: so anything that clarifies or confirms the requirements is good to do early; so is anything that will help the designers understand any new technology. The last part of each cycle is occupied with extracting this information and using it to refine the plans for later cycles.

(All the points made in this article apply to all iterative methods, including the named ones used for illustration here, such as DSDM, XP, RUP, Catalysis.)

DSDM progresses from an initial business study through functional modeling (= requirements analysis and architecture), design and build (= design and coding), and implementation (=deployment, user training).  The whole process is itself iterative: earlier stages will be revisited and reworked. No task is signed off as set in concrete before we move on to the next. The assumption is that some reworking will be necessary, so we plan for it.

The RUP phase diagram illustrates how activities and phases are different. A phase is a period of elapsed time: within it, we may be executing different tasks.

Microprocess: techniques for modeling and design

This article summarises the overall running of an incremental development project, which is the day-to-day layer of process. At the more hourly scale of what you do to create a model and render it into design, see the articles on requirements, modeling, architecture, object oriented design, patterns, and testing.

Macroprocess: Reuse and Component based development

These basic processes are adapted where the aim is to work from components or other reusable assets. See the articles on reuse and components.

complete solutions for development process adoption
(consultancy, courses, workshops, mentoring, seminars, development)

email us  or  tel  UK:  01625 850 839  international:  +44 1625 850 839