III YEAR

Term paper of principle of

software engineering

Topic: software crisis

S U B M I T T E D T O : TA RA C H A N D S I R

ACKNOWLEDGEMENT

I ARADHANA GROVER of (RE1801A1,10802442)under the guidance of our teacher Mr. TARA CHAND SIR have searched a lot on the given topic “”.

The main achievement I attained from the term paper and my respected sir is that what is the concept of topic and for what purposes, it is basically used. Our concerned subject teacher joined with us and gave us the relative information about my topic.

I would be very thankful to my respective teacher who made this job successful.

CONTENTS

INTRODUCTION OF CRISIS DEFINITION OF CRISIS WELL KNOWN FAILURE CASES TYPES OF CRISIS REASONS FOR SOFTWARE CRISIS WORKPLACE VIOLENCE FIGURE SHOWING SOFTWARE CRISIS CURRENT TRENDS IN SOFTWARE ENGINEERING WHAT IS CHRONIC SOFTWARE CRISIS SOFTWARE DEVELOPMENT COMPUTER SCIENCE AND THE PRODUCT

ORIENTATION MATURE SOFTWARE MANAGING SOFTWARE CRISIS

INTRODUCTION OF CRISIS

In mental health terms, a crisis refers not necessarily to a traumatic situation or event, but to a person’s reaction to an event. One person might be deeply affected by an event, while another individual suffers little or no ill effects. The Chinese word for crisis presents a good depiction of the components of a crisis. The word crisis in Chinese is formed with the characters for danger and opportunity. A crisis presents an obstacle, trauma, or threat, but it also presents an opportunity for either growth or decline.

We often think of a crisis as a sudden unexpected disaster, such as a car accident, natural disaster, or other cataclysmic event. However, crises can range substantially in type and severity. Sometimes a crisis is a predictable part of the life cycle, such as the crises described in Erikson’s Stages of Psychosocial Development. Situational crises are sudden and unexpected, such as accidents and natural disasters. Existential crises are inner conflicts related to things such as life purpose, direction, and spirituality.

The purpose of crisis counseling is to deal with the current status of the individual dealing with a crisis. Chronic exposure to stress or trauma can lead to mental illness, so it is important that crisis counselors have the skills and knowledge to help clients cope with current stressors and trauma. Crisis counseling is not intended to provide psychotherapy, but instead to offer short-term intervention to help clients receive assistance, support, resources, and stabilization.

DEFINITION OF CRISIS

“People are in a state of crisis when they face an obstacle to important life goals—and obstacle that is, for a time, insurmountable by the use of customary methods of problem solving.” --

“…an upset in equilibrium at the failure of one’s traditional problem-solving approach which results in disorganization, hopelessness, sadness, confusion, and panic.”

Well Know Failure Cases

Problems with software:

Often delivered too late Did not behave as user expects Rarely adaptable to changed circumstances Many errors detected after delivery Communication between stakeholders!

TYPES OF CRISIS

It is categorized into seven types of crises

1. Natural disaster2. Technological crises

3. Confrontation crises

4. Malevolence

5. Crisis of organization misdeeds

6. Crisis of skewed management value

7. Crisis of deception

8. Crisis of management misconduct

Natural crises

Natural crises, typically natural disasters considered as' acts of God,' are such environmental phenomena as earthquakes, volcanic eruptions, tornadoes and hurricanes, floods, landslides, tidal waves, storms, and droughts that threaten life, property, and the environment itself.

Technological crises

Technological crises are caused by human application of science and technology. Technological accidents inevitably occur when technology becomes complex and coupled and something goes wrong in the system as a whole (Technological breakdowns). Some technological crises occur when human error causes disruptions (Human breakdowns). People tend to assign blame for a technological disaster because technology is subject to human manipulation whereas they do not hold anyone responsible for natural disaster. When an accident creates significant environmental damage, the crisis is categorized as mega damage. Samples include software failures, industrial accidents, and oil spills.

Confrontation crises

Confrontation crises occur when discontented individuals and/or groups fight businesses, government, and various interest groups to win acceptance of their demands and expectations. The common type of confrontation crises is boycotts, and other types are picketing, sit-ins, ultimatums to those in authority, blockade or occupation of buildings, and resisting or disobeying police.

Crises of malevolence

An organization faces a crisis of malevolence when opponents or miscreant individuals use criminal means or other extreme tactics for the purpose of expressing hostility or anger toward, or seeking gain from, a company, country, or economic system, perhaps with the aim of

destabilizing or destroying it. Sample crises include product tampering, kidnapping, malicious rumors, terrorism, and espionage.

Crises of organizational misdeeds

Crises occur when management takes actions it knows will harm or place stakeholders at risk for harm without adequate precautions. Lerbinger specified three different types of crises of organizational misdeeds: crises of skewed management values, crises of deception, and crises of management misconduct.

Crises of skewed management values

Crises of skewed management values are caused when managers favor short-term economic gain and neglect broader social values and stakeholders other than investors. This state of lopsided values is rooted in the classical business creed that focuses on the interests of stockholders and tends to view the interests of its other stakeholders such as customers, employees, and the community.

Crises of deception

Crises of deception occur when management conceals or misrepresents information about itself and its products in its dealing with consumers and others.

Crises of management misconduct

Some crises are caused not only by skewed values and deception but deliberate amorality and illegality.

Reasons for the software crisis

o Rolling baseline o Failure to manage risk

o Software complexity

Rolling Baseline Shorter development cycles are business requirements Initial requirements usually poorly defined

Software Complexity Business software demands are increasing No one understands the entire system Legacy systems must be maintained, but the original developers are gone

Failure to Manage Risk The waterfall lifecycle can delay problem identification There is no proof that the system will run until late in the lifecycle The result is maximum risk

Workplace violence

Crises occur when an employee or former employee commits violence against other employees on organizational grounds.

Rumors

False information about an organization or its products creates crises hurting the organization’s reputation. Sample is linking the organization to radical groups or stories that their products are contaminated.

Sudden crises

Sudden crises are circumstances that occur without warning and beyond an institution’s control. Consequently, sudden crises are most often situations for which the institution and its leadership are not blamed.

Smoldering crises

Smoldering crises differ from sudden crises in that they begin as minor internal issues that, due to manager’s negligence, develop to crisis status. These are situations when leaders are blamed for the crisis and its subsequent effect on the institution in question.

James categorizes five phases of crisis that require specific crisis leadership competencies. Each phase contains an obstacle that a leader must overcome to improve the structure and operations of an organization. James’s case study on crisis in the financial services sector, for example, explores why crisis events erode public trust in leadership. James's research demonstrates how leadership competencies of integrity, positive intent, capability, mutual respect, and transparency impact the trust-building process.

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. 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. All these aspects are directly related to written communication. Managing complexity depends on an ability to document the interfaces (parameters and functionality of the modules involved. Requirements are an important reference for the whole process and should, therefore, be unambiguously and accessibly described for everyone.To keep track of changes it is important to document what exactly has been changed. Software can be made more visible by describing non-material artifacts, such as the overall design of a program. Domain models should, just like the requirements, be well documented. Thus, software engineering can benefit from good techniques to describe systems (programs, subsystems, etc.).

For communication purposes, one is usually not interested in the internal details of a system. A specification is an abstract description of a system which focuses on what it does (or should do) rather than how it does it. The notion of “specification” is a relative one; it only indicates that it is used as an abstract description of something.

FIGURE SHOWING SOFTWARE CRISIS

Software crisis

Software crisis was a term used in the early days of computing science. 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 roots of the software crisis are complexity, expectations, and change.

The term "software crisis" was coined by F. L. Bauer at the first NATO Software Engineering Conference in 1968 at Garmisch , Germany. An early use of the term is in Edsger Dijkstra's 1972 ACM Turing Award Lecture:

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.

The causes of the software crisis were linked to the overall complexity of hardware and the software development process. The crisis manifested itself in several ways:

Projects running over-budget. Projects running over-time.

Software was very inefficient.

Software was of low quality.

Software often did not meet requirements.

Projects were unmanageable and code difficult to maintain.

Software was never delivered.

Many of the software problems were caused by increasingly complex hardware. In his essay, Dijkstra noted that the newer computers in his day "embodied such serious flaws that [he] felt that with a single stroke the progress of computing science had been retarded by at least ten years". He also believed that the influence of hardware on software was too frequently overlooked.

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.

Current trends in software engineering

Software engineering is a young discipline, and is still developing. The directions in which software engineering is developing include:

Aspects

Aspects help software engineers deal with quality attributes by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates.

Agile

Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of this method believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes. Related concepts include Extreme Programming, Scrum, and Lean software development.

Experimenta l

Experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from the experiments, and in devising laws and theories from this data. Proponents of this method advocate that the nature of software is such that we can advance the knowledge on software through experiments only.

Model-driven

Model Driven Design develops textual and graphical models as primary design artifacts. Development tools are available that use model transformation and code generation to generate well-organized code fragments that serve as a basis for producing complete applications.

Software Product Lines

Software Product Lines is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process

What is the Chronic Software Crisis?

Is there a crisis at all? As you stroll through the aisles of neatly packaged software in your favorite computer discount store, it wouldn’t occur to you that there’s a problem. You may be surprised to learn that those familiar aisles of software represent only a small share of the software market--of the $90 Billion software market, a mere 10% of software products are "shrink wrapped" packages for personal computers. The remaining 90% of the market is comprised of large software products developed to specific customer specifications.

By today’s definition, a "large" software system is a system that contains more than 50,000 lines of high-level language code. It’s those large systems that bring the software crisis to light. If you’re familiar with large software development projects, you know that the work is done in teams consisting of project managers, requirements analysts, software engineers, documentation experts, and programmers. With so many professionals collaborating in an organized manner on a project, what’s the problem? Why is it that the team produces fewer than 10 lines of code per day over the average lifetime of the project? And why are sixty errors found per every thousand lines of code? Why is one of every three large projects scrapped before ever being completed? And why is only 1 in 8 finished software projects considered "successful?"

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.

Software projects are notoriously behind schedule and over budget. 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. It appears that the Software Crisis can be boiled down to two basic sources:

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.

Software Development: Craft, or Science?

Software development today is more of a craft than a science. Developers are certainly talented and skilled, but work like craftsmen, relying on their talents and skills and using techniques that cannot be measured or reproduced. On the other hand, software engineers place emphasis on reproducible, quantifiable techniques–the marks of science. The software industry is still many years away from becoming a mature engineering discipline. Formal software engineering processes exist, but their use is not widespread. A crisis similar to the software crisis is not seen in the hardware industry, where well documented, formal processes are tried and true, and ad hoc hardware development is unheard of.

To make matters worse, software technology is constrained by hardware technology. Since hardware develops at a much faster pace than software, software developers are constantly trying to catch up and take advantage of hardware improvements. Management often encourages ad hoc software development in an attempt to get products out on time for the new hardware architectures. Design, documentation, and evaluation are of secondary importance and are omitted or completed after the fact. However, as the statistics show, the ad hoc approach just doesn’t work. Software developers have classically accepted a certain number of errors in their work as inevitable and part of the job. That mindset becomes increasingly unacceptable as software becomes embedded in more and more consumer electronics. Sixty errors per thousand lines of code is unacceptable when the code is embedded in a toaster, automobile, ATM machine or razor (let your imagination run free for a moment).

Computer Science and the Product Orientation

Software developers pick up the ad hoc approach to software development early in their computer science education, where they are taught a "product orientation" approach to software development. In the many undergraduate computer science courses I took, the existence of software engineering processes was never even mentioned. Computer science education does not provide students with the necessary skills to become effective software engineers. They are taught in a way that encourages them to be concerned only with the final outcome of their assignments–whether or not the program runs, or whether or not it runs efficiently, or whether or not they used the best possible algorithm. Those concerns in themselves are not bad. But on the other hand, they should not be the focus of a project. The focus should be on the complete process from beginning to end and beyond. Product orientation also leads to problems when the student enters the work force–not having seen how processes affect the final outcome, individual programmers tend to think their work from day to day is too "small" to warrant the application of formal methods. To become effective software engineers, students must be taught how the process and product interact. They need to see how a good process repeatedly results in a good product. Software process engineering, is, unfortunately, not taught until very late in a computer

science student’s academic career (usually in graduate school), or in company sponsored classes on the job.

Mature Software

As we have seen, most software projects do not follow a formal process. The result is a product that is poorly designed and documented. Maintenance becomes problematic because without a design and documentation, it’s difficult or impossible to predict what sort of effect a simple change might have on other parts of the system.

Fortunately there is an awareness of the software crisis, and it has inspired a worldwide movement towards process improvement. Software industry leaders are beginning to see that following a formal software process consistently leads to better quality products, more efficient teams and individuals, reduced costs, and better morale.

The SEI uses a Capability Maturity Model (CMM) to assess the state of an organization’s development process. Such models are nothing new–they’ve been routinely applied to industrial engineering disciplines. What’s new is the application to software development. The SEI Software CMM has become a de facto standard for assessing and improving software processes. Ratings range from Maturity Level 1, which is characterized by ad hoc development and lack of a formal software development process, up to Maturity Level 5, at which an organization not only has a formal process, but also continually refines and improves it. Each maturity level is further broken down into key process areas that indicate the areas an organization should focus on to improve its software process (e.g. requirement analysis, defect prevention, or change control).

Level 5 is very difficult to attain. In early 1995, only two projects, one at Motorola and another at Loral (the on-board space shuttle software project), had earned Maturity Level 5. Another study showed that only 2% of reviewed projects rated in the top two Maturity Levels, in spite of many of those projects placing an extreme emphasis on software process improvement. Customers contracting large projects will naturally seek organizations with high CMM ratings, and that has prompted increasingly more organizations to investigate software process improvement.

Mature software is also reusable software. Artisans are not cen t. Managing the Software Crisis

Three dimensions to manage:

Multiple programmers Application complexity Maintenance

BIBLIOGRAPHY

1. Pankaj Jalote. Introduction and Software Process. An Integrated Approach to Software Engineering, pages 1-43, 2009

2. K.K. Aggarwal and Yogesh Singh. Introduction to Software Engineering and Software Life Cycle Models. Software Engineering (Third Edition), pages 1-27, 2008

3. www.google.com

4. www.wikipedia.com

5. www. answer .com