The major reason of the software crisis is that the machines have become several orders of magnitude more powerful. To put it quite bluntly; as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally big problem.
Poor software is a growing problem. The most often heard complaints about software are that it is buggy, that it does not function adequately, that it is very expensive, and that it is delivered late. Of course, one can wonder whether these grievances are really very consequential; judging from the large amount of money spent on software, apparently it is worth it. However, it is clear that the public expects better achievement from the software industry. Many software engineering experts believe the development of software is a hard to control process for which there are no methods and techniques available .This state of affairs is often referred to as the software crisis. Software crisis is a term used in the early days of software engineering. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems which could be tackled. This was with regards to the difficulty in writing correct, understandable and verifiable computer programs.
It is quite tough to analyze scientifically why it is so difficult to produce adequate
software. The underlying mechanisms are hard to observe and it is not feasible to
study the process in a laboratory. The reasons given in the literature are, at best,
educated gueses. McDermid (1991) identifies five problems inherent in software
development which I think many experts will agree with:
Software is often too complex to be entirely understood by a single individual. We can try to manage complexity by dividing the system into subsystems, but, as systems grow, the interaction between subsystems increases non-linearly.
It is notoriusly difficult to establish an adequate and stable set of requirements for a software system. Often there are hidden assumptions, there is no analytic procedure for determining when the users have told the developers everything they need to know, and developers and users do not have a common understanding of terms used.
The interaction between the different parts of a system makes change difficult.
Software is essentially thought stuff (that is, the result of a thought process) and much of what is important about software is not manifest in the programs themselves (such as the reasons for making design decisions).
A requirements specification for a system contains, perhaps implicitly, an application domain model (for example, describing the rules of air traffic). Development of application domain theories is very difficult.
Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s, which identified many of the problems of software development. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. Some used the term software crisis to refer to their inability to hire qualified programmers. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality.
Cost and Budget Overruns : The OS/360 operating system was a classic example. This decade-long project from the 1960s and 1970s eventually produced one of the most complex software systems ever created. OS/360 was one of the first large (1000 programmer) software projects. Fred Brooks claims in Mythical Man Month that he made a multi-million dollar mistake by not developing a coherentarchitecture before starting development.
Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money, and reputations. An expensive European Ariane rocket exploded because of software.
Life and Death: Software defects can kill. Some embedded systems used in radiotherapy machines failed so catastrophically that they administered lethal doses of radiation to patients.
Peter G. Neumann keeps a contemporary list of software problems and disasters at Computer Risks.
The software crisis has been slowly fizzling out, because it is unrealistic to remain in crisis mode for more than 20 years. SEs are accepting that the problems of SE are truly difficult and only hard work over many decades can solve them.
Conclusion
The reasons for software crisis are as follows and how we can deal them :
a)Poor/inadequate planning:-It is necessary to plan before what we are going to develop so, if the proper planning is not done then it results in poor software.
b)Lose control and review:-Formal and technical reviews ensures the software quality and helps in error finding so, if reviews are not done there will be not proper development.
c)Technical incompetence:-Good Technical support is very important because this include the function and the code which results the output. So, technical incompetence results in software crisis.
d)Non-engineering approach:-If the development is lacking the engineering approach.
e)Projects running over-budget:-Any project requires an amount in developing the project to meet the resources, human resource or machines. So if there will be less budget then the project development will be affected.
f)Projects running over-time:-It is very important that the project should be delivered at the right time. So the project running over time will result to software crisis.
g)Software was of low quality:-Software should be of good quality means that the output should be proper and the graphics should be user friendly.
h)Software often did not meet requirements:-The software should meet the requirements of user. In software validation this is checked that is the software
is meeting the requirements of the user or not.
i)Projects were unmanageable and code difficult to maintain:-The unmanageable code results in difficulty in maintenance of the project .
There are a number of reasons why software construction is an inherently hard process to master. Specification plays a central role here; therefore, better means of specification improve productivity. One way of achieving this may be the use of formal specification languages.
Future Scope
Various processes and methodologies have been developed over the last few decades to "tame" the software crisis, with varying degrees of success. However, it is widely agreed that there is no "silver bullet", 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.
