Overview On The Software Crisis Information Technology Essay

The term software crisis has been used since the late 1960s to describe those recurring system development problems in which software development problems cause the entire system to be late, over budget, not responsive to the user and/or customer requirements, and difficult to use, maintain, and enhance. The software development level is lower than the hardware manufacturing level because the hardware are manufactured fast and the software development takes more time. The construction of new software that is both pleasing to the user/buyer and without latent errors is an unexpectedly hard problem. It is perhaps the most difficult problem in engineering today, and has been recognized as such for more than 15 years. It is often referred to as the software crisis. It has become the longest continuing crisis in the engineering world, and it continues unabated. Software is the set of instructions that govern the actions of a programmable machine. Software includes application programs, system software, utility software, and firmware. Software does not include data, procedures, people, and documentation. In this tutorial, software is synonymous with computer programs. Because software is invisible, it is difficult to be certain of development progress or of product completeness and quality.

Index terms software crisis, Reasons, impact.

1. INTRODUCTION:-

Poorly functioning computer software is nowadays probably the largest source of annoyance after traffic jams and bad weather. The most often heard complaints about software are that it is buggy, that it does not function adequately, that it is too expensive,

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

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. 

software is not manufactured like hardware; it does not have a production phase nor manufactured spare parts like hardware; it is typically custom-built, not assembled from existing components like hardware. Even in today’s society, software is viewed with suspicion by many individuals, such as senior managers and customers, as somewhat akin to black magic. The result is that software is one of the most difficult

artifacts of the modern world to develop and

build.

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 notoriously 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. Perhaps the first mention of the software crisis in the secondary literature on the history of computing came in Michael S. Mahoney’s landmark 1988 paper “The History of Computing in the History of Technology.” This was Mahoney’s first published paper on computing, though by this point his interest in the topic had been growing for some years and he had already educated himself by auditing the core series of undergraduate computer science classes at Princeton. 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. Because software development depends on an educated workforce and good communications rather than on a fixed plant of any kind, software is inherently a

suitable export product for developing countries. Although the US is still strong in software design and project management, the article notes that third world

countries-notably India and Far Eastern countries-are capable of producing many more lines of code “per dollar”.

Today software engineering is fairly popular academic field of study, with conferences, journals, and degree programs. However historians have noted with some frequency that basic debates over its identity were never really resolved and that the rhetoric of a crisis in software development has likewise endured for many decades.

Nothing in the broad outline of this established narrative is altogether false. Yet the increasingly entrenched position of the software crisis and the 1968 NATO Conference in the historical literature has gradually led to the distortion of their actual nature, historical significance, and context. At the same time, surprisingly little attention has been paid to the actual background, experiences and intellectual interests of the conference attendees or to the spread of the “software crisis” concept after the conference itself.

I begin with a review of the software crisis concept and 1968 NATO Conference in the secondary historical literature, from their first appearance in 1988 to the present day. Over time the implied scope of the software crisis has grown, as has the implied importance of software engineering as a new identity for programming practice. In the rest of the paper I go back to the original sources to try to reconstruct the actual significance of the meeting and its associated crisis, and to sketch some neglected aspects of the broader history of software and programming in order to better contextualize them.

Term “software” has led to widespread misinterpretation of the scope of the crisis, which was initially understood to afflict only operating systems and programming languages. This leads to an analysis of the backgrounds and affiliations of the participants, from which I conclude that almost all were oriented toward research rather than development, and to systems software rather than applications. Among the groups not represented at the conference were data processing managers (responsible for administrative computing program development within computer using organizations), business school experts on computer use, the managers of large industrial software development projects, specialists in data base management systems, and representatives of software product companies. From the perspectives of these other groups, particularly data processing, neither the NATO Conference nor software engineering nor does the “software crisis” loom very large. Instead I document a range of computer related crises and chronic complains from the 1950s onward, most of which are constructed as failure to meet the goals of the broader organization rather than being seen narrowly as failures of software.

2. Reasons

The reasons for software crisis are as follows:

2.1 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.

2.2 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.

2.3 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.

2.4 Non-engineering approach:-If the development is lacking the engineering approach.

2.5 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.

2.6 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.

2.7 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.

2.8 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.

2.9 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.

3.IMPACT

The following are the impacts of the software crisis.

3.1 The software will be not up to the mark of hardware. The manufacturing speed of the hardware is faster then the development of the software which results the software crisis. so, the impact of this is that the level of the hardware produces is not matched with the software.

3.2 Incompetence between the hardware and the software.

4.REFRENCES:

4.1http://www.wordiq.com/definition/Software_crisis

4.2. Springer – An Integrated Approach to Software Engineering, 3rd Edition.[14/571].

4.3. SE-Pressman-SE-A-PRACTITIONERS-APPROACH [ 39 ].