I am Mohsin Ali Student of Sofware Engineering. Software Engineering Sir give us these slides to read and learn from it. And these Slides are very interesting for Sofware Eng Students.

1. 1
SOFTWARE ENGINEERING

2. 2
SOFTWARE CRISES

3. 3
1. Problems Faced By The Customers
1. US Internal Revenue System has abandoned its tax system
modernization program after having spent $4 billion;
2. the state of California spent $1 billion on its non-functional welfare
database system;
3. the £339 million UK air traffic control system was reported as
being two years behind schedule;
4. a discount stock brokerage company had 50 people working 14
hours or more a day to correct three months of records clerically –
the report commented that the new system had been rushed into
operation without adequate testing;
5. in the United Kingdom, a Home Office immigration service
computerization project was reported as having missed two
deadlines and was nine months late;
6. the Public Accounts Committee of the House of Commons (UK)
blamed software bugs and management errors for £12 million of
project costs in relation to an implementation of a Ministry of
agriculture computer system to administer farm subsidies.
7. More ???
SOFTWARE PROJECT FAILURE

4. 4
3. AN INDUSTRY PERSPECTIVE
2. GENERAL
H/W advances continue to outpace the pace of building S/W to tap
hardware’s potential.
 Why cost estimations are mostly incorrect?
 Why requirements are kept changing
 Why does it take so long to get programs finished?
 Why are costs so high?
 Why can’t we find all errors before we give the S/W to our
customer?
 Why do we have difficulty in measuring progress as S/W is being
developed?
Our ability to build S/W could not keep pace with the growing need
of business and market
Demand of highly reliable operations (ticketing, communication and
power control) of S/W due to our dependency on computer
SOFTWARE CRISES

5. 5
4. SOFTWARE COMPETITIVENESS
S/W is now an extremely competitive business. We cannot afford
unlimited cost and time for poor quality software.
SOFTWARE CRISES

6. 6
The statistics – Chaos Report
Project completion
16%
31%
53%
On time, on budget,
with all of the specified
features and functions
Cancelled before they
were completed
delivered and
operational but over-
budget, over-schedule
or with fewer features
and functions than
specified
 Standish Group – 1995
 365 IT executives in US
companies in diverse industry
segments.
 8,380 projects
average cost
overrun = 189%
average
time
overrun =
222%.
61% of originally specified
features included


?
In Averages
• 189% of original budget
• 221% of original schedule
• 61% of original functionality

7. 7
Symptom of Software Crisis
 About US$250 billions spent per year in
the US on application development
 Out of this, about US$140 billions
wasted due to the projects getting
abandoned or reworked; this in turn
because of not following best practices
and standards
Ref: Standish Group, 1996

8. 8
Symptom of Software Crisis
 10% of client/server apps are abandoned or
restarted from scratch
 20% of apps are significantly altered to avoid
disaster
 40% of apps are delivered significantly late
Source: 3 year study of 70 large c/s apps 30 European firms.
Compuware (12/95)

9. 9
Software products:
– fail to meet user requirements
– crash frequently
– expensive
– difficult to alter, debug, enhance
– often delivered late
– use resources non-optimally
Observed Problems

10. 10
Why is the Statistics so Bad?
 Misconception on software development
– Software myths, e.g., the man-month myth
– False assumptions
– Not distinguishing the coding of a computer
program from the development of a software
product
 Software programs have exponential growth in
complexity and difficulty level with respect to size.
– The ad hoc approach breaks down when size of
software increases.

11. 11
Why is the Statistics so Bad?...
 Software professionals lack engineering
training
– Programmers have skills for programming
but without the engineering mindset about
a process and discipline

12. How is Software usually Constructed …
The requirements
specification was
defined like this
The developers
understood it in
that way
This is how the
problem was
solved before.
This is how the
problem is
solved now
That is the program
after debugging
This is how the program is
described by marketing dept.
This, in fact, is what the
customer wanted … ;-)

13. 13
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.
 Application requirements can never be stable;
software can be and has to be made flexible
enough to allow changes to be incorporated as
they happen.

14. 14
Software Myths
(Developer Perspectives)
Once the software is demonstrated, the job is done.
Usually, the problems just begin!

15. 15
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)

16. 16
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)

17. 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 !

18. 18
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!

19. 19
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!

20. 20
Misplaced Assumptions
 All requirements can be pre-specified
 Users are experts at specification of their
needs
 Users and developers are both good at
visualization
 The project team is capable of
unambiguous communication
Ref: Larry Vaughn

21. 21
 Usually small in size
 Author himself is sole
user
 Single developer
 Lacks proper user
interface
 Lacks proper
documentation
 Ad hoc development.
 Large
 Large number of
users
 Team of developers
 Well-designed
interface
 Well documented &
user-manual prepared
 Systematic development
Programs Software Products
Confused with Programs and
Products

22. 22
Software Programming ≠ Software
Engineering
 Software programming: the process of translating a
problem from its physical environment into a language that
a computer can understand and obey. (Webster’s New
World Dictionary of Computer Terms)
– Single developer
– “Toy” applications
– Short lifespan
– Single or few stakeholders
• Architect = Developer = Manager = Tester = Customer = User
– One-of-a-kind systems
– Built from scratch
– Minimal maintenance

23. 23
Software Programming ≠ Software
Engineering
 Software engineering
– Teams of developers with multiple roles
– Complex systems
– Indefinite lifespan
– Numerous stakeholders
• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
– System families
– Reuse to amortize costs
– Maintenance accounts for over 60% of overall
development costs

24.  Second cause of confusion lies in the fact that there is no generally
agreed definition of software engineering, although many are similar.
 Software Engineering as a term was first coined in 1968 at a NATO
conference in West Germany held to discuss the software crises
 For example, Bohem, states that ‘software engineering is the
application of science and mathematics by which the capabilities
of computer equipment are made useful to man via computer
programs, procedures and associated documentation.’
 Other definitions such as Fairley’s 1985 explicitly include the
concerns of management in the software development process:
‘Software engineering is the technological and managerial
discipline concerned with systematic production and
maintenance of software products that are developed and
modified on time and within cost estimates.’
 The term S/W Engineering was/is sometimes confusing, firstly
because S/W engineer (some times) work as system programmer,
people assume that the engineering component of the term comes
from this source. SO we have H/W engg and S/W engg.
WHAT IS SOFTWARE ENGINEERING?

25. "The establishment and use of sound engineering
principles (methods) in order to obtain economically
software that is reliable and works on real machines"
[Bauer 1972].
"cost-effective Software engineering is that form of
engineering that applies the principles of computer science
and mathematics to achieving solutions to software
problems.“ [CMU/SEI-90-TR-003]
"The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance
of software" [IEEE Standard Computer Dictionary,
610.12, ISBN 1-55937-079-3, 1990].
What is Software Engineering? (ctd.)

26. What is Software Engineering? (ctd)
 Software engineering is concerned with the theories,
methods and tools for developing, managing and evolving
software products. (I. Sommerville, 6ed.)
 A discipline whose aim is the production of quality
software, delivered on time, within budget, and satisfying
users' needs. (Stephen R. Schach, Software Engineering,
2ed.)
The practical application of scientific knowledge
in the design and construction of computer
programs and the associated documentation
required to develop, operate and maintain them
(B.W. Boehm)
 Multi-person construction of multi-version software
(Parnas, 1987)

27. 27
So, Software Engineering is …
 Scope
– study of software process, development
principles, techniques, and notations
 Goals
– production of quality software,
– delivered on time,
– within budget,
– satisfying customers’ requirements and users’
needs

28. 28
The Role/Scope Of S/W Engineering In System Design
 A software system is often a component of a much larger system.
 The software engineering activity is therefore a part of a much
larger system design activity in which the requirements of the
software are balanced against the requirements of other parts of
the system being designed.*
 For Example, A requirement such as “the system must not be down
for more than a second in 20 years” or “when a receiver is taken off-
hook, a dial tone is played within half a second” can be satisfied
with a combination of hardware, software and special devices.
 A trade off is required as what should be done in software and what
should be done in hardware. Software implementation offers
flexibility, while hardware implementation offers performance.$
 To do software engineering right, requires a broader look at the
general problem of system engineering. It requires software
engineer to be involved when requirements are being developed
initially for the whole system.

29. 29
 It requires that software engineer attempt to understand the
application area rather than just what abstract interfaces the
software must meet.

30. 30
S/W CHARACTERISTICS
3.
 Software is developed or engineered,
it is not manufactured in the classical
sense.
 Software doesn’t wear out
 Software is complex
 Software is like an ‘aging factory’
 Industry is moving towards
component-based assembling, most
software is custom built.

31. 31
Wear vs. Deterioration
idealized curve
change
actual curve
Failure
rate
Time
increased failure
rate due to side effects

32. 32
Software Applications
System software
Real-time software
Business software
Engineering/scientific software
Embedded software
PC software
AI software
Network applications
Web applications