Workaround

Lucardie

Knowledge within text shows parallels with the hi-eroglyphs of the ancient Egyptians. Writing down is time-consuming and the result is often difficult to un-

derstand. However, specifications which are mainly recorded in text still form the base of software engineering. As requested functions become more complex on a daily basis, the switchover to knowledge-based working within the process of software development is almost inevitable.IT departments are stuck between sales, marketing and busi-ness analysts on the one hand and developers, programmers and testers on the other. Software specifications form the translation method from business to software. However, speci-fications are seldom formulated in such manner that they are at once clear and understandable to these target groups. When the software makers are situated abroad (offshore), commu-nication and consultation become challenging activities - as in India they obviously do not always know what should be done with the specifications provided. Sometimes the develop-ers come to The Netherlands (onsite) or they may just be part of the internal IT organisation, and on those occasions a lot of talking is also required. Communication is obviously like oil in a machine; however, unclear specifications result in an enormous detour.

The impact of ambiguities, inconsistencies and incompletions within specifications on the total chain of software develop-ment is substantial. It influences the technical design, the software and the testing, and eventually also the functioning of software in operation. ‘Maintenance’ then often becomes ‘rede-sign’ on code level! As follows, entire armies of ‘stake holders’ continue their work within the software engineering process. With their descriptions of work processes, procedures, scripts, work instructions and functions they create an immense vol-ume of documents all referring to one another - thus leading to large numbers of workarounds. This can categorically be done differently. Better, faster and cheaper.

Written text is often not the best method to record knowledge. In particular where it concerns the comprehensible represen-tation of complex relations between variables, a point where

benchmarking of completeness, consistency and correctness is vital. From a certain level of complexity, the transparency of text is simply too slight. In those cases (more) formal tech-niques are required; such as graphs, finite-state machines, state transition diagrams, Petri nets and flowcharts. And the requirements we set for this purpose must be well considered. The popular flowcharts for example lack a mathematical basis: the ‘traceability’ is poor and altering a flowchart is labour intensive.

What is needed is a knowledge-based paradigm: knowing which requirements must be set in order to reach an adequate choice of techniques for software specification. Goal-orien-tation, transparency, direct usability and changeability of the specifications should be of paramount importance within this frame. This is the only way we can prevent that the business, the testers and the programmers have to possess the decipher-ing skills of Champollion in order to grasp the specifications.The IT function is relatively costly, passing on of these costs to consumers will cease and the move of IT towards the busi-ness is imperative. Besides consolidation, standardisation and streamlining of the IT infrastructure - data centres, networks and software tools - IT has a task in orchestrating the hetero-geneous collection of IT applications within the architecture. Apart from optimal security and disclosure of data and infor-mation, staged phasing out of legacy and clever outsourcing of management tasks, the Cloud, SaaS and web services also play an important role. The business is requiring new applications in increasingly shorter cycles: more and more online, fluent, faultless and flexible.

IK, ninth volume, number 5, 2010 7

Prof. dr. Larry Lucardie is CEO ofKnowledge Values(Larry.Lucardie@knowledge-values.com)