Software and software system development is an inherently complex business. This complexity has grown as the scale of systems and the capability of existing infrastructure has increased.
There is a continual history of approaches to improve software and system development, and to help developers manage the complexity of system development. Many of these approaches - in recognition that software and system development are complicated, changeable, malleable, and error prone activities designed to develop complicated systems - have focused on improving the writing of software, and the processes associated with managing the outputs of analysis, design and programming.
While there are many well publicised and highly adopted methods, processes and techniques, there has been a parallel development of such activities that is less publicised and much less utilised This alternative approach has a different rationale and background, but there are many lessons to be learnt from these alternative approaches. This note gives a brief description of the various strands of development methods and forms the basis for subsequent comparison of the different strands, to identify the lessons each has to offer.
An article in Delphi Magazine by Richard Stevens gave a brief history of software development methods and processes. The article skipped through from Dijkstra's "GO TO Statement Considered Harmful", via Parnas' ideas on information hiding and modularity, into a description of the various structured methods, based on data flow diagrams and process modelling, such as Yourdon, Gane-Sarson etc. He mentioned that these methods adopted (to a greater or lesser degree) refinements such as entity life histories and entity relationship diagrams. He also mentioned techniques, from around the same time (the 70s) that gave more emphasis to the data modelling side of design, such as JSP (Jackson Structured Programming).
He describes methods at this point as based on the waterfall method of systems analysis, inflexible, generating huge amounts of paper, and not good at dealing with changes to requirements.
He goes on to describe the evolution of software development formalised processes such as the SEI Maturity Model and then onto the development of object orientated methods. These latter methods, typified by Gooch and Rumbaugh, "seemed to make it easier to build conceptual and coding models that more accurately their corresponding real-world entities." He also suggests that OO "seemed to afford much better opportunities for code reuse". He then describes people orientated factors in software development, arising from the work of Weinburg and Brookes.
Finally he describes the various agile methods, as incorporating the best elements of the past, discarding the worst, and building change of requirements into the software development process.
This history is a fair summary of the development of methods and certainly covers the main elements that have led to the modern mainstream view of software development methods. The outcome of these historic developments in exemplified by such things as:
1. Extreme programming and test driven development techniques designed to add flexibility to software development by incorporating change in requirements as a natural part of software development cycle; and to develop the software correctly.
2. Unified Modelling Language (UML) which has become the nearest thing in software development to a universal representation.
3. Borland's Development Studio, which incorporates (or can incorporate) UML modelling tools (Together), software configuration management tools (StarTeam), requirements management tools (Caliber), object persistence generation (ECO), as well as code editors and compilers with other elements to manage all the outputs from software development.
4. Detailed large scale software development methods such as Catalysis which is designed to build systems of made up of reusable components. It is perhaps the ultimate refinement of UML OO based development methods.
A comparable 80,000 feet altitude survey of what I am suggesting is an alternative historical strand of system development methods follows.
If Dijkstra's admonition to avoid goto (I understand that in the original paper by Dikjstra, his prohibition was on the uncontrolled, or unconstrained use of the goto statement - not an absolute prohibition) is taken as the inspirational spirit of what I have described as mainstream software development methods; then C.A.P. Hoares' work on communicating sequential processes was the inspirational spirit for what I am describing as the alternative stream of software development methods. This spirit fed into the work of Michael Jackson with JSP, and later into Jackson's System Development Method (JSD).
Developments were also being made with formal (provable) methods such as Z and VDM. These methods were intended to assist with the development of safety critical systems, which had extreme reliability requirements, such as the design of control software for nuclear reactors. The demands of the requirements are such that (portions of) the developed system have to be mathematically provable as meeting the requirements.
Subsequent method developments lead to KISS (Kristen Information & Software Services) Method, whose intent was to standardise the predictability of the software development process. The author was used to "evaluating, sizing and implementing projects based on energy analyses....The level of reliability and ease of implementation of these project was good....original expectation of an advanced computing environment was that this high level would be achieved. The reality was quite different." Further work was published by Michael Jackson on problem statements, and the need for system developers to have a toolbox of methods available.
The other major development on this strand was the Shlaer-Mellor method which was described as an object orientated method, but has a rather different feel and rationale than other object orientated software development methods. This has been extended and refined both by Mellor's own firm and by Kennedy-Carter in the UK. Also there were a number of independant developments that contirbuted to this alternative strand - most notably Naked Objects which advocated the direct manipulation of objects as a user interface, and to provide systems that were more suited to problem solving users, than users following a predetermined process.
References arising from the above will follow in a later blog.
No comments:
Post a Comment