0% found this document useful (0 votes)
65 views60 pages

5@introduction To Software Engineering

The document discusses the software crisis and issues in software engineering. It provides statistics showing many software projects are cancelled, over budget, or late. Reasons for this include lack of adequate training, increasing complexity of software, and low productivity improvements. The document also discusses various software failures and myths in software development.

Uploaded by

aaaaaaaa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
65 views60 pages

5@introduction To Software Engineering

The document discusses the software crisis and issues in software engineering. It provides statistics showing many software projects are cancelled, over budget, or late. Reasons for this include lack of adequate training, increasing complexity of software, and low productivity improvements. The document also discusses various software failures and myths in software development.

Uploaded by

aaaaaaaa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 60

1

Why Software Engineering ?

 Change in nature & complexity of software

 Concept of one “guru” is over

 We all want improvement

Ready for change

2
Software Crisis

 Software industry is in Crisis!

success
failure 16%
31%

over budget
53%

Source: The Standish Group International, Inc. (CHAOS research) 3


Software Crisis

This is the Completed


Successful –
28%
SORRY state Late, over
budget, and/or

of Software with features


missing – 49%

Engineering
Cancelled –
Today! 23%

• Data on 28,000 projects


completed in 2000
4
Software Crisis

As per the IBM report, “31%of the project get


cancelled before they are completed, 53% over-
run their cost estimates by an average of 189%
and for every 100 projects, there are 94 restarts”.

5
Software Crisis

Hw cost
Sw cost

1960 Year
1999
Relative Cost of Hardware and Software
6
Software Crisis

• Unlike Hardware
– Moore’s law: processor speed/memory capacity doubles
every two years

7
Software Crisis

Managers and Technical Persons are asked:

 Why does it take so long to get the program finished?

 Why are costs so high?

 Why can not we find all errors before release?

 Why do we have difficulty in measuring progress of software


development?

8
Factors Contributing to the Software
Crisis

• Larger problems,
• Lack of adequate training in software
engineering,
• Increasing skill shortage,
• Low productivity improvements.
9
Some Software failures
Ariane 5
It took the European Space Agency 10
years and $7 billion to produce Ariane 5,
a giant rocket capable of hurling a pair of
three-ton satellites into orbit with each
launch and intended to give Europe
overwhelming supremacy in the
commercial space business.

The rocket was destroyed after 39 seconds


of its launch, at an altitude of two and a
half miles along with its payload of four
expensive and uninsured scientific
satellites. 10
Some Software failures
When the guidance system’s own
computer tried to convert one
piece of data the sideways velocity
of the rocket from a 64 bit format
to a 16 bit format; the number was
too big, and an overflow error
resulted after 36.7 seconds. When
the guidance system shutdown, it
passed control to an identical,
redundant unit, which was there to
provide backup in case of just such
a failure. Unfortunately, the
second unit , which had failed in
the identical manner a few
11
milliseconds before.
Some Software failures

Y2K problem:

It was simply the ignorance about the


adequacy or otherwise of using only
last two digits of the year.

The 4 digit date format, like 1964,


was shortened to 2 digit format, like
64.

12
Some Software failures
The Patriot Missile
o First time used in Gulf war
o Used as a defence from Iraqi Scud
missiles
o Failed several times including one that
killed 28 US soldiers in Dhahran,
Saudi Arabia
Reasons:
A small timing error in the system’s clock
accumulated to the point that after 14
hours, the tracking system was no longer
accurate. In the Dhahran attack, the
system had been operating for more than
13
100 hours.
Some Software failures
The Space Shuttle
Part of an abort scenario for the
Shuttle requires fuel dumps to
lighten the spacecraft. It was
during the second of these
dumps that a (software) crash
occurred.
...the fuel management module,
which had performed one
dump and successfully exited,
restarted when recalled for the
second fuel dump...
14
Some Software failures

A simple fix took care of the problem…but the


programmers decided to see if they could come up with a
systematic way to eliminate these generic sorts of bugs in
the future. A random group of programmers applied this
system to the fuel dump module and other modules.
Seventeen additional, previously unknown problems
surfaced!

This is Software Engineering.

15
“No Silver Bullet”

The hardware cost continues to decline


drastically.
However, there are desperate cries for a
silver bullet something to make software
costs drop as rapidly as computer hardware
costs do.
But as we look to the horizon of a decade,
we see no silver bullet. There is no single
development, either in technology or in
management technique, that by itself
promises even one order of magnitude
improvement in productivity, in reliability
and in simplicity. 16
“No Silver Bullet”

The hard part of building software is the specification, design and


testing of this conceptual construct, not the labour of representing it
and testing the correctness of representation.
We still make syntax errors, to be sure, but they are trivial as
compared to the conceptual errors (logic errors) in most systems.
That is why, building software is always hard and there is inherently
no silver bullet.
While there is no royal road, there is a path forward.
Is reusability (and open source) the new silver bullet?

17
Software Myths (Management
Perspectives)
As long as there are good standards and clear procedures in my
company, I shouldn’t be too concerned.

But the proof of the pudding


is in the eating;
not in the Recipe !
Software Myths (Management
Perspectives)
As long as my software engineers(!) have
access to the fastest and the most sophisticated
computer environments and state-of-the-art
software tools, I shouldn’t be too concerned.

The environment is
only one of the several factors
that determine the quality
of the end software product!
Software Myths (Management
Perspectives)
When my schedule slips, what I have to do is to start a
fire-fighting operation: add more software specialists,
those with higher skills and longer experience - they
will bring the schedule back on the rails!

Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!
Software Myths (Management
Perspectives)

Software is easy to change

The reality is totally different.

21
Software Myths (Management
Perspectives)

Computers provide greater reliability than


the devices they replace

This is not always true.

22
Software Myths (Customer
Perspectives)
• A general statement of objectives is sufficient to get started
with the development of software. Missing/vague requirements
can easily be incorporated/detailed out as they get concretized.

If we do so, we are heading


towards a disaster.
Software Myths (Customer
Perspectives)
Software with more features is better
software

Software can work right the first time

Both are only myths!

24
Software Myths (Developer
Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!


Software Myths (Developer
Perspectives)
Until the software is coded and is available for
testing, there is no way for assessing its quality.

Usually, there are too many


tiny bugs inserted at every stage
that grow in size and complexity
as they progress thru further stages!
Software Myths (Developer
Perspectives)
The only deliverable for a software
development project is the tested code.

The code is only


the externally visible component
of the entire software complement!
Software Myths (Developer
Perspectives)

Aim is to develop working programs

The time is over. Objective is to


develop good quality maintainable
programs!

28
What is software?

• Computer programs and associated


documentation

29
What is software?

Programs

Documentatio Operating
n Procedures

Software=Program+Documentation+Operating Procedures
Components of software
30
Documentation consists of different types of
manuals are Formal Specification
Analysis Context-
/Specification Diagram
Data Flow
Diagrams
Flow Charts
Design
Entity-Relationship
Documentation Diagram
Manuals
Source Code Listings
Implementation Cross-Reference
Listing
Test Data
Testing
Test Results

31
List of documentation manuals
Documentation consists of different types of
manuals are System Overview
User Beginner’s Guide
Manuals Tutorial
Reference Guide

Operating
Procedures

Installation Guide
Operationa
l Manuals
System
Administration Guide

List of operating procedure manuals. 32


Software Product

• Software products may be developed for a particular


customer or may be developed for a general market

• Software products may be


–Generic - developed to be sold to a range of different
customers
–Bespoke (custom) - developed for a single customer according
to their specification

33
Software Product
is a product designated for delivery to the user

source
source documents
documents
codes
codes reports
reports

manuals
manuals
object
object plans
plans
codes
codes
data
data

test test
testresults
results
testsuites
suites prototypes
prototypes
What is software engineering?

Software engineering is an engineering discipline which


is concerned with all aspects of software production
Software engineers should
– adopt a systematic and organised approach to their
work
– use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and

– the resources available 35


What is software engineering?
At the first conference on software engineering in 1968, Fritz Bauer
defined software engineering as “The establishment and use of
sound engineering principles in order to obtain economically
developed software that is reliable and works efficiently on real
machines”.

Stephen Schach defined the same as “A discipline whose aim is the


production of quality software, software that is delivered on time,
within budget, and that satisfies its requirements”.

Both the definitions are popular and acceptable to majority.


However, due to increase in cost of maintaining software, objective
is now shifting to produce quality software that is maintainable,
delivered on time, within budget, and also satisfies its requirements.
36
Software Process

The software process is the way in which we produce


software.

Why is it difficult to improve software process ?

• Not enough time

• Lack of knowledge

37
Software Process

• Wrong motivations
• Insufficient commitment
Improved future state
Process improvement
begins
Initial state
state

Productivity

Do not quit here!

Learning curve

Time

38
Software Characteristics:

It does not wear out.

39
Software Characteristics:

 Software is not manufactured


 Reusability of components
 Software is flexible

40
Software Characteristics:
Comparison of constructing a bridge vis-à-vis writing a program.
Sr. Constructing a bridge Writing a program
No
1. Only some parts of the problem are
The problem is well understood
understood, others are not
2. Every program is different and designed for
There are many existing bridges
special applications.
3. The requirement for a bridge typically do Requirements typically change during all
not change much during construction phases of development.
4. The strength and stability of a bridge can be Not possible to calculate correctness of a
calculated with reasonable precision program with existing methods.
5. When a bridge collapses, there is a When a program fails, the reasons are often
detailed investigation and report unavailable or even deliberately concealed.
6. Engineers have been constructing bridges Developers have been writing programs
for thousands of years for 50 years or so.
7. Materials (wood, stone,iron, steel) and Hardware and software changes rapidly.
techniques (making joints in wood, carving
stone, casting iron) change slowly.
41
Some Terminologies

 Deliverables and Milestones

Different deliverables are generated during software development.


The examples are source code, user manuals, operating procedure
manuals etc.

The milestones are the events that are used to ascertain the status of
the project. Finalisation of specification is a milestone. Completion of
design documentation is another milestone. The milestones are
essential for project planning and management.

42
Some Terminologies
 Product and Process
Product: What is delivered to the customer, is called a product. It
may include source code, specification document, manuals,
documentation etc. Basically, it is nothing but a set of deliverables
only.

Process: Process is the way in which we produce software. It is the


collection of activities that leads to (a part of) a product. An efficient
process is required to produce good quality products.

If the process is weak, the end product will undoubtedly suffer, but
an obsessive over reliance on process is also dangerous.
43
Some Terminologies

 Measures, Metrics and Measurement

A measure provides a quantitative indication of the extent,


dimension, size, capacity, efficiency, productivity or reliability of
some attributes of a product or process.

Measurement is the act of evaluating a measure.

A metrics is a quantitative measure of the degree to which a system,


component or process possesses a given attribute.

44
Some Terminologies

 Software Process and Product Metrics

Process metrics quantify the attributes of software development


process and environment;

whereas product metrics are measures for the software product.

45
Some Terminologies

 Productivity and Effort

Productivity is defined as the rate of output, or production per unit of


effort, i.e. the output achieved with regard to the time taken but
irrespective of the cost incurred.

Hence most appropriate unit of effort is Person Months (PMs),


meaning thereby number of persons involved for specified months.
So, productivity may be measured as LOC/PM (lines of code
produced/person month)

46
Some Terminologies

 Module and Software Components

There are many definitions of the term module. They range from “a
module is a FORTRAN subroutine” to “a module is an Ada
Package”, to “Procedures and functions of PASCAL and C”, to “C+
+ Java classes” to “Java packages” to “a module is a work
assignment for an individual developer”. All these definition are
correct. The term subprogram is also used sometimes in place of
module.

47
Some Terminologies

“An independently deliverable piece of functionality providing


access to its services through interfaces”.

“A component represents a modular, deployable, and replaceable


part of a system that encapsulates implementation and exposes a
set of interfaces”.

48
Some Terminologies

 Generic and Customized Software Products

Generic products are developed for anonymous customers. The target


is generally the entire world and many copies are expected to be sold.
Infrastructure software like operating system, compilers, analysers,
word processors, CASE tools etc. are covered in this category.

The customised products are developed for particular customers.


The specific product is designed and developed as per customer
requirements. Most of the development projects (say about
80%)come under this category.

49
Software Applications

System Real
Software Time
Software

Engineering Embedded
and Scientific Software
Software

Web based Business


Software Software
Artificial
Intelligence Personal
Software Computer
Software

50
Role of Management in Software
Development

Factors

People Project

Product Process

51
Role of Management in Software
Development
People

Project Dependency
4 2 Product
Order

Process 52
Multiple Choice Questions
Note: Select most appropriate answer of the following questions:
1.1 Software is
(a) Superset of programs (b) subset of programs
(c) Set of programs (d) none of the above
1.2 Which is NOT the part of operating procedure manuals?
(a) User manuals (b) Operational manuals
(c) Documentation manuals (d) Installation manuals
1.3 Which is NOT a software characteristic?
(a) Software does not wear out (b) Software is flexible
(c) Software is not manufactured (d) none of the above
1.4 Product is
(a) Deliverables (b) User expectations
(c) Organisation’s effort in development (d) none of the above
1.5 To produce a good quality product, process should be
(a) Complex (b) Efficient
(c) Rigorous (d) none of the above 53
Multiple Choice Questions
Note: Select most appropriate answer of the following questions:
1.6 Which is not a product metric?
(a) Size (b) Reliability
(c) Productivity (d) Functionality
1.7 Which is NOT a process metric?
(a) Productivity (b) Functionality
(c) Quality (d) Efficiency
1.8 Effort is measured in terms of:
(a) Person-months (b) Rupees
(c) Persons (d) Months
1.9 UML stands for
(a) Uniform modeling language (b) Unified modeling language
(c) Unit modeling language (d) Universal modeling
language
1.10 An independently deliverable piece of functionality providing access to its
services through interface is called
(a) Software measurement (b) Software composition
54
(c) Software measure (d) Software component
Multiple Choice Questions
Note: Select most appropriate answer of the following questions:
1.11 Infrastructure software are covered under
(a) Generic products (b) Customised products
(c) Generic and Customised products (d) none of the above
1.12 Management of software development is dependent on
(a) people (b) product
(c) process (d) all of the above
1.13 During software development, which factor is most crucial?
(a) People (b) Product
(c) Process (d) Project
1.14 Program is
(a) subset of software (b) super set of software
(c) software (d) none of the above
1.15 Milestones are used to
(a) know the cost of the project (b) know the status of the
project
55
(c) know user expectations (d) none of the above
Multiple Choice Questions
Note: Select most appropriate answer of the following questions:
1.16 The term module used during design phase refers to
(a) Function (b) Procedure
(c) Sub program (d) All of the above
1.17 Software consists of
(a) Set of instructions + operating system
(b) Programs + documentation + operating procedures
(c) Programs + hardware manuals (d) Set of programs
1.18 Software engineering approach is used to achieve:
(a) Better performance of hardware (b) Error free software
(c) Reusable software (d) Quality software product
1.19 Concept of software engineering are applicable to
(a) Fortran language only (b) Pascal language only
(c) ‘C’ language only (d) All of the above
1.20 CASE Tool is
(a) Computer Aided Software Engineering (b) Component Aided Software Engineering
(c) Constructive Aided Software Engineering (d)Computer Analysis Software Engineering
56
Exercises
1.1 Why is primary goal of software development now shifting from
producing good quality software to good quality maintainable software?
1.2 List the reasons for the “software crisis”?Why are CASE tools not
normally able to control it?
1.3 “The software crisis is aggravated by the progress in hardware
technology?” Explain with examples.
1.4 What is software crisis? Was Y2K a software crisis?
1.5 What is the significance of software crisis in reference to software
engineering discipline.
1.6 How are software myths affecting software process? Explain with the
help of examples.
1.7 State the difference between program and software. Why have documents
and documentation become very important.
1.8 What is software engineering? Is it an art, craft or a science? Discuss.
57
Exercises
1.9 What is aim of software engineering? What does the discipline of
software engineering discuss?
1.10 Define the term “Software engineering”. Explain the major differences
between software engineering and other traditional engineering disciplines.
1.11 What is software process? Why is it difficult to improve it?
1.12 Describe the characteristics of software contrasting it with a diagram
that the software does not wear out.
1.13 Write down the major characteristics of a software. Illustrate with a
diagram that the software does not wear out.
1.14 What are the components of a software? Discuss how a software
differes from a program.
1.15 Discuss major areas of the applications of the software.
1.16 Is software a product or process? Justify your answer with example

58
Exercises
1.17 Differentiate between the following
(i) Deliverables and milestones (ii) Product and process
(iii) Measures, metrics and measurement
1.18 What is software metric? How is it different from software measurement

1.19 Discuss software process and product metrics with the help of expales.

1.20 What is productivity? How is it related to effort. What is the unit of


effort.
1.21 Differentiate between generic and customized software products. Which
one has larger share of market and why?
1.22 Distinguish between generic and customized software products. Which
one has larger share of market and why?

59
Exercises

1.23 Describe the role of management in software development with the help
of examples.
1.24 What are various factors of management dependency in software
development. Discuss each factor in detail.

1.25 What is more important: Product or process? Justify your answer.

60

You might also like