Temporal and Logical Groupings of Work

Figure 11.2 A Waterfall Model with a simple iteration 

11.1  Temporal and Logical Groupings of Work 

As the design science method may look very much like a sequential design process, see figure 4.1, it could be argued that it suffers from the same weaknesses as the waterfall model. In other words, it could be claimed that the design science method does not cater for vague requirements, changing environments, shifting stakeholder interests, unclear problem situations, etc. If this were true, the method would clearly not be of much interest. However, the method does not pre‐

scribe a sequential way of working. The activities are not to be seen as temporal groupings of work to be performed in sequence, but instead as logical groupings of work. Thus, the arrows in figure 4.1 should not be interpreted as temporal orderings but as input‐output relationships. These interpretations can be made clearer by placing them in the context of the RUP (Rational Unified Process) frame‐

work.

RUP is structured in two dimensions, phases and disciplines, that capture the serial and iterative aspects of software development, respectively, see figure 11.3. The phases represent the sequential stages that a project traverses over time, while the disciplines corre‐

spond to the logical activities that are carried out during a project.

RUP identifies four phases: inception, elaboration, construction, and transition. The inception phase aims at achieving consensus among the stakeholders about the objectives of the project; the elaboration

phase specifies requirements in detail and outlines an architecture for the system to be built; the construction phase focuses on devel‐

oping the system so that it is ready for deployment; and the transi‐

tion phase delivers the system into production.

  Figure 11.3 Disciplines and phases in RUP 

While the phases capture the serial aspects of a project in RUP, the disciplines address the iterative aspects. During each phase, the software developers will alternate between (almost) all of the disci‐

plines. For example, during the inception phase the developers will typically address a subset of the requirements, carry out some busi‐

ness modeling, return to the requirements and revise them, suggest an initial design, once again revise the requirements, do some coding and preliminary tests, and then improve the design. Furthermore, the inception phase can be broken down into several iterations, each of which only addresses a small portion of the system to be built, thereby making RUP even more iterative. thereby making RUP even more iterative. Similarly, all the other phases will also include sever‐

al disciplines.

The relationships between phases and disciplines are shown in figure 11.3, which is sometimes called a “hump chart”. The humps

for each discipline display how much effort that is spent on that dis‐

cipline in the various phases. For example, the diagram shows that most of the work on requirements is carried out in the inception and elaboration phases, but it continues all the way into the transition phase. The sizes and placements of the humps may certainly vary from project to project and can be tailored as required.

Figure 11.4 shows a version of the hump chart, which is close to a waterfall model requiring that, for example, all work on business modeling and requirements be completed before any work on design can be started.

Figure 11.4 A Waterfall version of RUP 

Another version of the hump chart is given in figure 11.5, requiring that all disciplines are given equal attention in all phases. This kind of diagram would reflect an extremely agile development process.

  Figure 11.5 An Agile version of RUP 

Returning to the design science method, its activities are analogous to the disciplines of RUP, not the phases. In other words, the activi‐

ties are not to be sequentially ordered in time but can be performed in parallel and in any order. The activities only tell what tasks need to be done in the method, what input they consume, and what output they produce. The activities are logical groupings, not temporal ones.

Design and Appropriation 

People often adapt and use artefacts in ways that their designers never  intended.  For  example,  email  was  designed  to  support  communication  between  people,  but  it  is  nowadays  regularly  used  by  people  to  send  reminders  to  themselves  or  to  store  safety  copies  of  documents.  Dix  (2007) describes this process of technology adaptation as follows: 

“These  improvisations  and  adaptations  around  technology  are  not  a  sign of failure, things the designer forgot, but show that the technology  has been domesticated, that the users understand and are comfortable  enough with the technology to use it in their own ways. At this point we 

know  the  technology  has  become  the  users'  own  not  simply  what  the  designer gave to them. This is appropriation.“ 

Designers should be aware that the artefacts they create may be ap‐

propriated in unanticipated ways. They could even try to design in order  to  facilitate  appropriation.  Dix  (2007)  suggests  a  number  of  guidelines  for this, three of which are: 

Allow interpretation – “Don’t make everything in the system or prod‐

uct  have  a  fixed  meaning,  but  include  elements  where  users  can  add  their own meanings.” 

Provide  visibility  –  ”Make  the  functioning  of  the  system  obvious  to  the users so that they can know the likely effects of actions and so make  the system do what they would like.” 

Support not  control – ”As a designer you want to do things right, to  make  them  as  efficient  and  optimal  as  possible.  However,  if  you  opti‐

mise for one task you typically make others more difficult. In some situ‐

ations,  such  as  very  repetitive  tasks,  then  designing  explicitly  for  the  task  may  be  the  correct  thing  to  do,  perhaps  taking  the  user  step  by  step through the activities. However, more often the tasks description is  incomplete and approximate, in particular ignoring  exceptions.  Instead  of designing a system to do the task you can instead design a system so  that the task can be done.”