Software crisis

INTRODUCTION:

Since last 20-25 years, there has been a rapid increase in the development of programs using a computer. Also, the difficulty level of software has increased to a greater extent. In other words, a drastic change has occurred in the development of computer programs. In order to make the programs more and more predictable, different types of patterns have been created. But the software industry is still many years away from becoming a mature engineering discipline. Even in today’s society, software is viewed with suspicion by many individuals, such as senior managers and customers, as something similar to black magic. The result is that software is one of the most difficult artifacts of the modern world to develop and build. Developers work on techniques that cannot be measured or reproduced. All this, lead to a new concept called ‘software crisis’. It has become the longest continuing crisis in the engineering world, and it continues unabated.

As the nature of software is that it is intangible, malleable, and intellectually intensive and has trivial replication. Our ultimate goal is to make quality software-on time and within budget which can be achieved through application of systematic, disciplined, quantifiable approach to the development, operation and maintenance of the software.

SOFTWARE CRISIS

The difficulty of writing the code for a computer program which is correct and understandable is referred to as software crisis. The term software crisis revolves around three concepts: complexity, change and the expectations. This term was given by F. L. Bauer at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. Current System design approach is exceedingly empirical. It is unable to cope with increasing systems complexity. A number of problems in software development were identified in 1960s, 1970s, and 1980s. The problems that software projects encountered were: the projects ran over-budget, caused damage to property even to life. Despite our rapid progress, the software industry is considered by many to be in a crisis. Some 40 years ago, the term “Software Crisis” emerged to describe the software industry’s inability to provide customers with high quality products on schedule.

In general it refers to poorly written, hard to read, error-prone software that often lacks good documentation.

Software crisis is also referred to the inability to hire enough qualified programmers. It has become the longest continuing “crisis” in the engineering world and it continues unabated. The most visible symptoms of the software crisis are late delivery, over budget; Product does not meet specified requirements, inadequate documentation. One of the most serious complaints against software failure is the inability to estimate with acceptable accuracy the cost, resources, and schedule necessary for a software project. Conventional assessment methods have always produced positive results which contribute to the too well-known cost infested and schedule slippage. As the world becomes more and more dependent on computers and as the complexity of software systems continues to rise, the crisis can only get worse. It is particularly severe in vital segments of the economy such as the health and financial services, and the transportation, manufacturing, communication, power generation, and defense industries.

Software Crisis in terms of statistics in 1990’s

* 31 % of projects canceled

* 52.7% cost an average of 189% over budget

* 84% are late or over budget (91% for large companies.)

* The average system is delivered without 58% of proposed functionalities

* $81 billion in 1995 for cancelled projects

* $51 billion in 1995 for over-budget projects

Only 16.2% of software projects are completed on-time and on-budget. In larger companies, a meager 9% of technology projects come in on-time and on-budget. In addition, about one third of all projects will be canceled before they ever get completed. Further results indicate 53% of projects will cost an average of 189% of their original estimates. In financial terms this analysis revealed that over $100 billion in cancellations and $60 billion in budget over runs occur in the Software Sector annually.

CAUSES

Software engineering today is in severe crisis. The situation is particularly grim because this crisis is not widely acknowledged by the software development industry. The causes of software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession. The main reason for the crisis is the lack of a sound software construction methodology with which to manage the high complexity of modern applications. The notion of a software crisis emerged at the end of the 1960s. An early use of the term is in Edsger Dijkstra’s ACM Turing Award Lecture, “The Humble Programmer” (EWD340), given in 1972 and published in the Communications of the ACM. Dijkstra says,

“The major cause 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 gigantic problem.” – Edsger Dijkstra

* The cost of owning and maintaining software in the 1980’s was twice as expensive as developing the software.

* During the 1990’s, the cost of ownership and maintenance increased by 30% over the 1980’s.

* In 1995, statistics showed that half of surveyed development projects were operational, but were not considered successful.

* The average software project overshoots its schedule by half.

* Three quarters of all large software products delivered to the customer are failures that are either not used at all, or do not meet the customer’s requirements.

To explain the present software crisis in simple words, consider the following. The expenses that organizations all around the world are incurring on software purchases compared to those on hardware purchases have been showing a worrying trend over the years.

Not only are the software products turning out to be more expensive than hardware, but they also present a host of other problems to the customers: software products are difficult to alter, debug, and enhance; use resources no optimally; often fail to meet the user requirements; are far from being reliable; frequently crash; and are often delivered late. Among these, the trend of increasing software costs is probably the most important symptom of the present software crisis.

Software crisis: The present scenario

The Software Crisis began 4 decades ago and continues today. In the 60s, we began to speak of a “software crisis”. A thirty year long “crisis” was beginning. A world-wide research effort also began.

Today, the situation is quite different. We have a Science of Programming. We know a great deal about how to design and document software, but the “Software Crisis” continues unabated!

The software crisis continues because the communication between Computer Scientists and those who write software, including the Engineers, has been very poor. Current software standards, are weak, superficial, and are not based on software science. Process oriented “standards” are empty because there are no product/document standards.

SOLUTION

Over the last twenty years many different paradigms have been created in attempt to make software development more predictable and controllable. While there is no single solution to the crisis, much has been learned that can directly benefit today’s software projects. One of the possible solutions to the software crisis is the study of software engineering. It is believed that the only satisfactory solution to the present software crisis can possibly come from a spread of software engineering practices among the engineers, coupled with further advancements in the software engineering discipline itself. Software engineering is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. As a solution to this software crisis, we must apply a disciplinary artistry; using tools that help us manage this complexity. The skilled systems engineer, can through the use of these techniques and by the application of systems engineering methods and project management skills, reduce the demands placed on software engineers, hence reducing the software engineering effort and also reducing the total development cost. But still, there is no single approach which will prevent all the consequences of software crisis in all cases. While there is no single solution to the crisis, much has been learned that can directly benefit today’s software projects. It is our human inability to deal with complexity that lies at the root of the software crisis. It has been noted frequently that we are experiencing a software crisis, characterized by our inability to produce correct, reliable software within budget and on time. No doubt, many of our failures are caused by the inherent complexity of the software development process, for which there often is no analytical description.

Through the use of computer-aided symbolic specification techniques and simulation, and with an understanding of the software development process, the skilled systems engineer can contribute to the resolution of the software crisis. The skilled systems engineer, can through the use of these techniques and by the application of systems engineering methods and project management skills, reduce the demands placed on software engineers, hence reducing the software engineering effort and also reducing the total development cost.

In software engineering, the possible solution to software metrics is the use of proper software metrics and the proper utilization of these metrics. For the implementation of this solution to the problem of software crisis some pre-requisites are there.

They are:

1. Knowledge of basic statistics and experimental design.

2. Basic understanding of commonly used software life cycle models, at least to the level covered in an introductory senior or graduate-level software engineering course.

3. Experience working as a team member on a software development project.

In addition, for maximum utility in analytic studies and statistical analyses, metrics should have data values that belong to appropriate measurement scales.

Software engineering is still a very young discipline. There are encouraging signs that we are beginning to understand some of the basic parameters that are most influential in the processes of software production.

ÃËœ For the projects which are delivered late must adopt the following methodology:

Project Planning & Scheduling

Project planning means creating work breakdown, and then allocate responsibilities to the developers over time. Project planning consists of construction of various tasks, timelines and essential pathways including Gantt charts and PERT charts and different written plans for various situations. It is quite usual in software development process to work backward from the project end date which results in complete software project failure. It is impossible that a project can be completed efficiently from the planning stage to the implementation stage. Allocation of roles and responsibilities has to be clearly defined. Proper scheduling is also required before the start of the project. It includes the time scheduling, teams scheduling.

ÃËœ For the projects running out of budget, cost estimation methodology must be applied:

Cost Estimation

Cost estimation is mainly involved the cost of effort to produce the software project. But it’s not limited to the effort only. It also includes the hardware and software cost, training the employees and customer, travelling to the customer, networking and communication costs. Cost estimation should be done as a part of the software process model. Cost estimation needs to be done well before the start of the project

development.

Failure of the budgeting for the cost of the project results in complete disaster. Development tools, cost and hardware cost also need to be estimated first.

ÃËœ In order to cope up with the increasing system complexity, risk management should be applied:

Risk Management

Risk management is an important factor towards software project failure if it’s not managed timely and effectively. As nothing can be predicted that what will happen in future so we have to take the necessary steps in the present to take any uncertain situation in the future. Risk management means dealing with a concern before it becomes a crisis. Project managers have to identify the areas where the risk can be and how it can affect the development of the project. Risk can be of technical nature or non technical. After the risk is identified there is a need to make the categories of that risk. Risk analysis is the process of examining the project results and deliverables after the risk analysis and applying the technique to lower the risk. After the risk is analyzed, the next step is to priorities the risk. At first focus on the most sever risk first; and les sever later. Managing the risk to achieve the desired results and deliverables is done through controlling the risk at its best.

Conclusion

Thus, we have discussed software crisis, its causes, the present status and the possible solution to this crisis. Software engineering appears to be one of the few options available to tackle software crisis. Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.

It is believed that the only satisfactory solution to the present software crisis can possibly come from a spread of software engineering practices among the engineers, coupled with further advancements to the software engineering discipline itself. The solution being advocated is to place a special emphasis on fault tolerance software engineering which would provide a set of methods, techniques, models and tools that would exactly fit application domains, fault assumptions and system requirements and support disciplined and rigorous fault tolerance throughout all phases of the life cycle. Also, the software must not be considered equivalent to a widget, i.e. a gadget.

REFERENCES:

Books referred:

Software engineering: concepts and techniques – Peter Naur

Software engineering- Richard H. Thayer

Websites and links:

en.wikipedia.org/wiki/Software_crisis

www.apl.jhu.edu/Classes/Notes/…/SoftwareEngineeringOverview.PDF

http://www.unt.edu/benchmarks/archives/1999/july99/