Term paper of

principle of
software
engineering
Topic: software crisis

III YEAR

SUBMITTED TO: TARACHAND SIR

 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 disaster
2. 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.

Experimental
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