Software Crisis

Oct.22, 2008

Introduction
The software crisis was a term used in the early days of software engineering, before it was a well-established subject. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems which could be tackled. In essence, it refers to the difficulty of writing correct, understandable, and verifiable computer programs.
The crisis manifested itself in several ways:

·Unmanageable.
·Projects running over-budget.
·Projects running over-time.
·Software was of low quality.
·Software often did not meet requirements.

Causes
Basic roots: complexity, expectations, and changes.

· The causes linked to the overall complexity of the software process.
· Conflicting requirements have always hindered the software development process. Users demand a large number of features, but want to minimize the pay amount and the development time. (Details in AP?)
· The causes linked to the relative immaturity of software engineering as a profession. Software development is seen as a craft, rather than an engineering discipline. The approach to education taken by most higher education institutions encourages that "craft" mentality. (Details in AP? Immature?)

Solutions
Various processes and (Lightweight) methodologies have been developed over the last few decades to "tame" the software crisis, with varying degrees of success.

· Careful planning and actual design.
· Modern IDE tools. Generate code automatically.
· Agile software development. The use of rapid-prototyping evolved to entire lightweight methodologies, such as Extreme Programming (XP), which attempted to simplify many areas of software engineering, including requirements gathering and reliability testing for the growing, vast number of small software systems.
· High level abstraction programming languages. (Lead to new uncontrollable crisis? )
However, it is widely agreed that there is no "silver bullet"(Really?), that is, no single approach which will prevent project overruns and failures in all cases. In general, software projects which are large, complicated, poorly-specified, and involve unfamiliar aspects, are still particularly vulnerable to large, unanticipated problems.

Future
Multi-core crisis? (Really a crisis?)
Multi-core designs are forcing us to face an ugly truth, namely that we cannot continue to hide parallelism from the software designer. A compiler or runtime system will not transform sequential software, be it Windows or Linux operating system code or research or commercial application code to execute efficiently with hundred-way parallelism. This ugly truth must be faced squarely and directly.

Embedded software crisis? (Really a crisis?)
The lack of abstraction that we have in embedded software engineering makes more than 50% of all embedded software projects being later, over budget or not deliver on expectations. Adding code is easy, but removing dead code (without breaking the actually used parts of the code) is hard.

New solutions? (new methodologies & new tools &new languages?)