From D3 Magazine, a sister publication.
Formal methods of design are still being touted as the best approach to delivering software and yet very few packaged applications are developed with such methods. So, what use are formal methods? Either they are of no benefit to the average programmer using modern, visual tools, or a number of large software companies have got things exceedingly wrong. The roots of formal design methodology are buried in the computer boom of the 1960s, when the increasing cost of large software projects prompted a re-evaluation of the largely ad hoc design approaches taken before. In their initial forms, structured analysis and design methods were simply ways to document and formalize the software development process, from requirements through to implementation and delivery. In order to ensure good communication of the development cycle, graphical models were used to communicate an intelligible representation of the design. The first widely-used method – Yourdon Structured Methodology – did not appear until some years later. Although Yourdon has been updated recently, it still adopts a process-driven viewpoint, where state diagrams show the flow of control and data between individual tasks. Yourdon covers the main lifecycle components – from feasibility study through to implementation – and was seen as a flexible approach. Today you’ll still find elements of Yourdon being used in most software development projects, even if it’s just a case of ‘back of the envelope’ data-flow design. But such techniques do not model modern object-oriented development processes very well. Objects have interactions which might be methods or data transactions – data flows are very rarely foremost in the designer’s mind.
By Mark Stephens
During the 1980s in the UK, much effort was expended on formalizing the governmental approach to software design, culminating in the SSADM Structured Systems Analysis and Design Methodology. SSADM is now widely used in both government and industry, although it is a considerably more demanding methodology than most others. It specifically does not cover implementation, although attempts have been made to accommodate this task within the method. Any development project might be governed by different methodologies in different areas. It sounds complicated and, not surprisingly, it is. The use of a single methodology can help to focus ideas, to play a part in your quality program and to aid communication, but muddying the development waters with three or four of the things just seems to be asking for trouble. Of much greater interest to developers of small systems are the object methodologies formulated in the 1990s. Two pioneers are Grady Booch and Jim Rumbaugh, the latter being the driving force behind the OMT Object Modeling Technique. The parallel development of object programming tools such as C++ has ensured continued interest in these methods. Object methods do have significant advantages, particularly when developing systems quickly, since they are better suited to the iterative and prototyping techniques of software development. The current move is towards a UML ‘Unified Modeling Language’, a unification of Booch and OMT, with input from a wide range of other methodologies. When Grady Booch and Jim Rumbaugh joined forces in 1994, they established the goals of modelling systems in a method usable by both humans and machines. UML promotes an incremental and iterative software development approach, but crucially does not yet define a standard process; this enables a reasonable measure of flexibility to account for differences in implementation. The main limitation of all formal design methods is so obvious that you can easily overlook it. All methods depend on your being able to express the design problem in some fashion – all design methods have concrete goals, by definition. Of course, object methods are better at handling changing requirements, thanks to their support for iterative processes, but this does not change the underlying ‘goal driven’ assum
ption. By their very nature, the most successful computer programs have been those which were ‘invented’. In fact there is a serious argument which suggests that formal methods should never be used to produce packaged software, since they stifle creativity. And hopefully, creativity comes throughout the development lifecycle, not just in the requirements-specification phase. It is also interesting to look at formal methods from another viewpoint: are they actually of any benefit during a typical software development lifecycle? Experience suggests that there tends to be three distinct approaches to development: those which adhere rigorously to a single design method; those which draw on various methods in a generalized design methodology; and those which use no formal design method at all. Into the first camp fall most major financial and governmental projects, where deliverables are rigorously defined. Within the second two camps are commercial, packaged software and internal company projects. For projects where formal methods are applied rigidly, the main benefit is normally one of communication. Using a formal method forces you to focus on a stated goal which everyone can understand. Consequently, it prevents you building something the customer doesn’t want. The trouble is, of course, that most customers don’t know what they want! They may not understand their own requirements, nor what might be possible. It’s a sweeping statement, but largely true in small systems development. Numerous approaches have been formulated to make the most of user input to the design process; most obviously the DSDM Dynamic Systems Development Method.
Specifying requirements
DSDM turns the software development process on its head and admits that people are not good at specifying requirements, and so gets people in front of a prototype as fast as possible. The developers can then quickly make changes and present them to the users. This approach is used not only to capture requirements at the start of the development cycle, but right the way through the project. DSDM gives the user base a much closer association with the developed product and creates something they actually want. The most obvious disadvantage to DSDM is the difficulty in getting users to spend time at the prototyping stages. For any developer, getting user input is difficult and getting a full review of a prototype can be near impossible without serious management pressure. Another problem with DSDM is that it gives users early sight of the part-finished product. This may not be a bad thing in itself, but the pressures to release something incomplete can be increased by the appearance of a half- functional system. As DSDM has only really been used in anger for a short period of time, evidence of its efficacy is only just appearing. However, even if it may not decrease the overall project time or spend, the end result is much closer to the requirements. No formal method will make any difference unless everyone involved is willing to commit to change. We’ve come a long way from back-bedroom programmers and small teams developing killer applications; whatever standards are adopted, it is important not to let that spark of creativity die.
