The problem

Early experience in building large software systems showed that existing methods of software
development were not good enough.

Techniques applicable to small systems could not be scaled up.

Hardware costs were tumbling while software costs were rising rapidly.

The term "software crisis" has been used since the late 1960s to describe recurring system
development problems. The crisis manifested itself in several ways:

 Projects running over-budget.

 Projects running over-time.
 Software was of low quality, performed poorly, ans was unreliable
 code was difficult to maintain
 Software often did not meet requirements and / or difficult to use.
 Projects were unmanageable

The causes of the software crisis can be linked to the relative immaturity of software engineering
as a profession as well as the dramatic growth in size and complexity of the software being
demanded to run on increasingly powerful computer hardware.
The complexity of the software product is made so by its unique characteristics.

Software Characteristics

Software is logical rather than physical system elements. Therefore software has characteristics
that are considerably different than those of hardware:

1. Software is developed or engineered, it is not manufactured in the classical sense.

Because software is intangible, it is difficult to be certain of development progress or of
product completeness and quality

2. Although the industry is moving towards component based assembly, most software
continues to be custom built.

3. Software does not ware out. It can however deteriorate due to the introduction of defects
during maintenance.

Combined with the fact that it is notoriously difficult to establish an adequate and stable set of
requirements for a software system, the result is that software is one of the most difficult artifacts
of the modern world to develop and build.

New processes and methods were needed to control the complexity inherent in large software
system development projects.

Software Engineering

Definition: The application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software; that is, the application of engineering to
software. It is the practice of using selected process techniques to improve the quality of a
software development effort. 

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.

The study guide’s approach (4Ps)

1. Processes: The methodological processes which people will follow in order to move from an
idea or problem, through to a completed piece of software e.g. waterfall model, prototyping,
spiral model etc.

2. People: Persons involved in the software engineering project which includes users,
customers and developers.
3. Practices: specific activities a developer takes in order to develop a system e.g. requirements
capture via interviews.

4. Paradigms: A set of practices that are linked together around a set of beliefs about the way
software should be developed, namely OO vs structured approaches

How do they fit together?

Different people will be involved throughout the project. A process(s) is selected, and
depending on the preferred paradigm, a set of practices is employed during the development
process

There are a large number of software development approaches / processes available. It is

however important to realize that all represent idealized views of software engineering.

It is very unlikely that a project will follow one of the methods precisely. Some large
development projects may use several approaches before completed.