Any textbook on Software Engineering begins by quoting frightening figures about the increasing cost of software development and the unacceptable number of failed projects. But although the software engineering solution was proposed over 2 decades ago the "software crisis" remains, and "software engineering" is little more than an unrealised ideal Quote from a paper by Norman Fenton in a volume from the Workshops in Computing series entitles “Formal Aspects of Measurement” published 1992
Quote from a paper by Norman Fenton in a volume from the Workshops in Computing series entitles “Formal Aspects of Measurement” published 1992
For the last thirty years the field of programming and software development have been known as software engineering. This immediately implies the use of a traditional engineering approach to programming even though the reality of this process is often a long way from engineering. Before discussing the validity of this name we must first consider the characteristics and principals of traditional engineering.
Engineering has been described as an “intimate association of theory, and practical expertise where reproducible know-how coexists with standards and adapted tools.â€1. This description mentions several key components that identify engineering, the first of which is “theory”. A sphere of engineering must be soundly backed-up by scientific principals. These principals should be scientifically proven and must be the bases of any engineering design or process, for example Newtonian physics can be used to prove the top speed of a car, or that a new boat will float. Other important elements of engineering are those of “practical expertise” and “reproducible know-how”, which can be considered ability and experience. Finally engineering requires that “standards” and “adapted tools” can be applied to control methods, project interaction, quality and measurement. Each of these fundamental areas are in some small part applicable to software development; the extent to which this sphere constitutes engineering is discussed next.
The use of tools, standards, reproducible know-how and practice all have important applications in software development and are all used widely. The final and least supported of engineering characteristics is that of “theory”. The field of software development has no directly comparable scientific background such as Newtonian physics or atomic theory. The best candidate for providing a background theory is the operating system. The operating system is responsible for laying out the basic rules that apply to software and also provides software with the ability to behave dynamically, both with the user or other software. However the operating is software itself and must inherit its own theory from somewhere else, namely the hardware. The hardware provides rules but the only real limitations are the devices supported such as monitors, keyboards, speakers, microphones and mice. Within the constraints of the hardware the software running on the operating system is largely infinite in its scope because of the huge level of abstraction between them.
So is software really a sphere of engineering and is it applicable to approach a software development project in the same way as a physical engineering project. The only characteristic of traditional engineering which software development lacks is a basis in scientific theory. This is a very important factor and really excludes software and a sphere of engineering because without theory the entire process is based on experience, ability and experimentation; a mixture that certainly doesn”t sound like calculated engineering. This unlimited scope should be seen as one of software”s biggest benefits although controlling it is very difficult; highlighted by the crisis in software discussed later. This control takes the form of scientific theory in many engineering spheres but it may be more appropriate for software to remain flexible and adopt more relevant standards.
It has been seen in traditional engineering that the only sensible way of producing high quality products is by effectively controlling the creation process; a difficult task with software. There is certainly no indication that software would not also benefit from more rigidly controlled methods, as long as developers have a sufficient depth of knowledge to use proposed methodologies effectively. This leads me to believe that a great many engineering principals should be adopted by software development regardless of whether it can be strictly defined as engineering.
The software crisis has been in discussion for the last thirty years and while the semantics of the statement can be argued, very few people involved with software development would disagree that there a great many problems in the industry. The following problems are the most serious that effect software development: “schedule and cost estimates are often grossly inaccurate; the productivity of software people hasn’t kept pace with the demand for software; the quality of software is sometimes less than adequateâ€.2 These problems are discussed in greater detail below.
Software projects are renowned for going over both deadline and budget with good reason. A 1995 statistical report3 surveyed 365 companies, with a total of 8,380 different applications and found that only 16.2% of projects were successful, 52.7% were completed over deadline, over budget and with reduced functionality while the remaining 31.1% of projects were cancelled. A total of 61.1% of projects were between 21% and 100% over budget and 55.5% were found to be between 51% and 200% over time. These statistics were further broken down by company size and it was found that project success improved consistently the smaller the company, and logically therefore the project. So why are large software development projects such a problem, surely if small projects are easier to complete then the main problems must lie with project management and complexity. It is unavoidable that larger projects bring added complexity and that they must be managed more effectively but there are several reasons why software projects continue to fail.
There are many examples of failed projects, such as the 1987 California Department of Motor Vehicles (DMV) project to revitalize their driving license and registration application process. This project was not economically driven and did not have the full backing of executive management. In 1993 the project was cancelled after $45 million had been spent. In the words of the Standish Groups CHAOS report: “There are much harder applications than driver licenses and registrations. But because of internal state politics, unclear objectives, and poor planning, the project was doomed from the start.â€3.
Critical and continuous review is a practise much used in other industries, such as manufacturing, which allows industries to improve and perfect their techniques. This practise has not been sufficiently present in software development for the past thirty years and still remains underused. “We have not taken time to collect data on the software development process. With little historical data, estimation has been produced in haste with predictably poor results.â€2 This quote clearly outlines the cause of one of the major problem areas for the industry. Without keeping accurate details of both failed and successful projects the only reliable estimation comes from developers experience; in an industry that changes as frequently and radically as software development, very few people will be required to embark on many similar projects. This leaves experience as a poor tool for estimating time and budget requirements.
Those products that are delivered on budget and on deadline frequently do not provide the functionality originally specified. This problem is normally just an extension of poor estimation of time and budget requirements but it may occur if the problem domain is simply too complex. Software systems can easily become extremely complicated and frequently comprise of possible states several orders of magnitude greater than the most complicated of physical systems. As information systems are becoming more widely used and people are becoming more computer literate software development is increasing at a huge rate and program complexity is increasing in line with this. It is very difficult to find a good measure of software complexity but one statistic that is frequently used in number of lines of code. There are several good examples of increasing program complexity: Windows NT was well over 10,000,000 lines of code in 1997 and this figure has been increasing throughout the products life at 33.9% per year; The number of lines of code which drive Netscape navigator have been increasing at a staggering 221% per year.4 The inherent complexity of software makes it very hard to estimate development time and unforeseen problems are often encountered and therefore extra effort needs to be made in project management and structuring the development appropriately.
The level of complexity involved in software development is further aggravated by the relative lack of formal training in specifically software development. It has been the traditional path for new programmers to spend time maintaining large systems and modifying existing software as training before eventually becoming involved in new projects when they have enough experience. This approach is simply inappropriate for such a swiftly moving and expanding industry and often leads to unstructured and experimentation based methods of development.
The highly complex, specialised nature and history of failures in software development requires highly controlled management. Unfortunately the general opinion still seems to be “A manager can manage any projectâ€, a statement which is certainly true if quantified by the following statement: “if they are willing to learn the milestones that can be used to measure progress, apply effective methods of control, disregard mythology, and become conversant in a rapidly changing technologyâ€5. Far too frequently managers with no software development experience are placed in charge of projects that consequently fail.
The preceding paragraphs all addressed software”s single biggest problem: that of over spending and late delivery. At the beginning of this section two other important problems were identified, these were productivity and quality. The first of these is not an inherent problem within the field of software development but is a simple result of the rising demand for software. Business now revolve around computers, using them to communicate, trade, advertise and research as well as many other areas; there is a computer on nearly every desk in modern offices. Software quality is a much more critical problem to the industry, not least because the quality of software is very difficult to measure and even harder to ensure that it is present.
There is no definition of quality control with respect to software. The phrase “killer application†or “killer-app†has been coined to describe an application “so attractive to consumers that it fuels market forces and makes the underlying invention on which it depends all but indispensableâ€6. The product suite of Microsoft Office is often considered to be a killer-app but is it quality. Its development procedures may comply with ISO 9000 standard for quality control but this standard is fatally flawed when considering software development and only really applies to physical manufacturing. An application may be considered quality if it is “fit for purpose” and behaves as expected all of the time. If this definition is applied there may be very few quality software products available today, software such as Office occasionally behaves erratically. These “bugs” are commonplace in today”s software, some or tolerated while others are not. This is where a critical difference between physical and software products becomes apparent. The smallest flaw in a physical product usually makes the product unusable, or in many cases unsafe. Because of this there is very little tolerance for errors in physical products. For example when a train crashes a detailed investigation would be undertaken to establish the exact cause and the industry would learn from the mistake by modifying the design or improving safety precautions. This is comparable to a safety critical software system, such as air traffic control or railway signalling where structure approaches are taken and a high level of testing is done. The systems do still fail, although very infrequently, and when they do detailed investigations would take place; just like a physical product failure. It is the problems with non-safety critical systems such as stock market and financial systems that fail and are just covered up.
Mistakes in both the development process and in the final product are simply ignored for software systems and this is stopping the industry from learning from previous project failures and producing high quality, bug free software.
In addition to safety and bug free operation the software industry continuously makes mistakes by providing a system that does not perform to the specifications or expectations of the users. The primary reason for this shortfall is the lack of communication between the intended users (often not the people responsible for authorising the development) and the development team. Development projects often include a requirements specification or other such document which both parties must agree on before the development can proceed but this can be a lengthy process because of the complexity some systems require and because users rarely poses the technical level required to fully understand the system as the development team do. In addition to this specifications written in natural language will always contain some degree of ambiguity and so often diagramming tools and formal methods such as VDM are used. These techniques are often very complicated and long-winded (although accurate), representing a huge cost increase for the project and so are often only used on safety critical systems.
Despite the dire situation described in the preceding paragraphs there have been a great many innovations in software development to improve the management of quality, estimation, design and complexity. In my opinion however the most important of all progress is that of awareness. The amount of detailed information available concerning failed projects and ideas about software development practices is growing all of the time, which can only be a good thing.
One of the first improvements in software development practices was the adoption of a structured life cycle. Although there are several models available the simplest and most expressive is an iterative process which contains the following stage: feasibility study, system analysis, system design, implementation, review and maintenance. The technique is highly structured and tends to be inflexible although if properly applied can certainly address some of the major problems discussed. This method of developing systems was widely used until the 1980”s when it was largely replaced by similar but more advanced models, which allowed modifications and reviews to be conducted at given milestones or documents.
These new development methodologies bring with them sets of tools for specifying requirements, functionality, design and testing. An example methodology is SSADM, which describes tools specifically for analysis and designing systems by modelling data and logical entities. Another emerging methodology is UML, which is used to design and specify systems written in an object-oriented language, described below.
Another very important tool for modern software development are the 3rd generation languages available. Graphical languages such as Visual Basic have evolved to allow swift production of software which otherwise would become very complicated. Languages such as C++ provide Object oriented technology (OOP) which allows programs to be structured much more like physical systems than ever before; as well as encouraging modularity and encapsulation. While OOP systems more logically structured than procedural systems the benefits in complexity management are largely negated because its ads an extra design dimension to system development which was no originally present. In addition OOP techniques encourage inheritance, which creates tight coupling between independent structures. These dependencies then become increasingly complicated to maintain and often changes propagate unexpectedly through the system.
In addition to these 3rd generation languages 4th generation languages have become available. These languages and CASE (computer aided software engineering) tools are often integrated with existing languages and products. A good example of this is Microsoft Access is a small scale DBMS (database management system) which supports relational databases, SQL, 3rd generation Visual Basic for Applications as well as 4th generation tools for creating queries, graphical interfaces to the data and printable reports. This allows complex systems to be developed very quickly utilising a multitude of skills and techniques. This has both advantages such as productivity but disadvantages such as encouraging poorly designed and programmed systems.
One of the newest innovations in the software development lifecycle is that of prototyping or rapid application development (RAD). This as its name suggests involves rapidly creating a prototype system with limited scope and functionality then reviewing and amending the design and rebuilding a new prototype. This process continues until a final version is released, at which the new prototypes are considered updates and are released once they are completed. This technique couples naturally with the new development tools that allow fast development. The fast development times of this technique are obviously beneficial but unless it is managed correctly poor coding and untested systems can add to the poor code already around.
Will the new technologies and approaches described above swiftly rescue the software industry from its state of crisis? Probably not. All of new techniques and approaches have there own strengths and weaknesses but the fundamental problems of software development cannot be solved by new tools or new diagrams; the shift must come in the approach we take to managing these projects. We need clear and concise methods, which allow highly structured and rigid standards to be applied. These methods must, in contrast, be flexible enough to allow new ideas and new technologies to be embraced and productively utilised. This methodology must be a fine balance between structure and experimentation in the same way that physical engineering balances scientific theory with physical realities.
So, is the ideal referred to in the opening quote is, in fact, unrealistic? In my opinion it is quite realistic to predict vast improvements in software engineering over the next decade. We should not forget that this is one of the newest fields of human endeavour and as such is bound to experience problems.
1 & 5 “The Software Crisis From Craft to Engineering: An industrial outlookâ€, Michel Vanden Bossche-Marquette, Copyright © Mission Critical
2 The Software Crisisâ€, Copyright Elaine Ferneley, Department of Computing, MMU
3 “CHAOSâ€. Copyright 1995 The Standish Group International, Inc.
4 Nathan Myhrvold (Chief Technology Officer for Microsoft) at ACM 97
6 “The Road Aheadâ€, Bill Gates