1. Chapter 1 Introduction to Software Engineering

2. Recommended Course Textbooks
R. S. Pressman (2005)
Software Engineering: A Practitioner’s Approach, 6th Edition, McGraw-Hill, 880 p.
J. Greene, A. Stellman (2005)
Applied Software Project Management,
O’Reilly, 322 p.
I. Sommerville (2004)
Software Engineering, 7th Edition, Addison Wesley, 784 p.
P. Jalote (2002)
Software Project Management in Practice,
Addison Wesley, 288 p.

3. Why Software Engineering?
Software development is hard!
Important to distinguish “easy” systems (one developer, one user, experimental use only) from “hard” systems (multiple developers, multiple users, products)
Experience with “easy” systems is misleading
One person techniques do not scale up
Analogy with bridge building:
Over a stream = easy, one person job
Over River Severn … ? (the techniques do not scale)

4. Why Software Engineering?

5. Why Software Engineering?
The problem is complexity
Many sources, but size is key:
K Desktop Environment (KDE) contains 1.8 million lines of code
UNIX contains 4 million lines of code
Windows Vista contains 50 million lines of code
Software engineering is about managing this complexity.

6. Software’s Dual Role Software is a product
Delivers computing potential
Produces, manages, acquires, modifies, displays, or transmits information
Software is a vehicle for delivering a product
Supports or directly provides system functionality
Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)

7. Software Development Questions
Why does it take so long to get software finished?
Why are development costs so high?
Why can’t we find all errors before giving software to customer?
Why do we spend so much time and effort maintaining existing programs?
Why do we have difficulty in measuring progress as software is being developed and maintained?

8. 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

9. 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.

10. What is software? Computer programs and associated documentation
Program + Documentation +
Operating Procedures

11. Documentation Manuals
Documentation consists of different types of manuals are

12. Documentation Manuals
Documentation consists of different types of manuals are

13. 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

14. Software Product
Software product is a product designated for delivery to the user

15. Software Characteristics
Software is engineered
Software does not wear out.
Failure curve for hardware

16. Software Characteristics
Software is not manufactured
Reusability of components
Software is flexible

17. Software Problems
People that design and build software have to deal with many problems
Software is too expensive
Software takes too long to build
Software quality is low
Software is too complex to support and maintain
Software does not age gracefully
Not enough highly-qualified people to design and build software

18. Software Cost Software projects often go over budget
Hurts the company and the customer
Bad for the project
Many projects are cancelled
People may get fired or may quit
Bad for the final product
Features are not implemented
Bad quality: not enough money to get it right
Expensive in the long run

19. Software Time Software projects often take too long
Loss of revenue and market share
Both for the vendor and for the client
E.g.: baggage system at Denver airport
Cost: $1 million per day
Projects may become obsolete
Technology changes rapidly
Competing products already on the market
Not enough time to implement all features and to ensure quality

20. Some Questions
Studies of IT projects by the Standish Group (2000 and 2006)
350+ IT managers, applications
What percentage of projects were
cancelled before being completed?
over budget and/or late?
completed on time and on budget?
What was the cost/time overrun?

21. Success Rate
Category 1: on time and on budget, with all initially specified features
Category 2: over budget or over time, with fewer features than specified
Category 3: cancelled

22. Overruns and Deficiencies
Cost and time overruns
Averages for category 2 and category 3
Cost overruns: 189% of original estimate
Time overruns: 222% of original estimate
Feature deficiencies: only 61% of the originally specified features were implemented
Average for category 2

23. Some Reasons for Failure
Lack of user involvement
Incomplete requirements and specs
Changing requirements and specs
Lack of executive support (politics)
Lack of planning and management
Inadequate resources and time
Death-march projects
Technology incompetence

24. Software Quality Software defects result in failures
Example 1: Windows crashes while you play a game at home
Example 2: The software that controls a nuclear reactor crashes
Direct loss of life and money
Millions of dollars
Indirect loss: missed opportunities
e.g. online purchases are down for a day
Loss of credibility, bad publicity

25. Software failures
Therac-25 ( ): six people overexposed during treatments for cancer
Taurus (1993): the planned automatic transaction settlement system for London Stock Exchange cancelled after five years of development
Ariane 5 (1996): roket exploded soon after its launch due error conversion (16-bit floating point into 16-bit signed integer)
The Mars Climate Orbiter assumed to be lost by NASA officials (1999): different measurement systems (Imperial and metric)

26. Example: Ariane 5 Ariane 5 rocket Built by the European Space Agency
First launch: June 1996
Crashed 40 seconds after launch
Cost: $500 million
No people on board
Problem: software failure

27. What Happened?
Overflow when velocity was converted from 64-bit floating point to 16-bit signed integer
The exception was not caught
Inertial Reference System failed
Backup system failed for the same reason
Rocket went off course
Self-destruct module (correctly) activated
The code was OK for Ariane 4
Same software, different environment

28. Software Applications

29. What is a software process?
SP is a set of activities whose goal is the development or evolution of software
Fundamental activities in all software processes are:
Specification - what the system should do
and its development constraints
Development - production of the software system
(design and implementation)
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands

30. What is a software process model?
SPM is a simplified representation of a software process, presented from a specific perspective
Examples of process perspectives:
Workflow perspective represents inputs, outputs and dependencies
Data-flow perspective represents data transformation activities
Role/action perspective represents the roles/activities of the people involved in software process
Generic process models
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components

31. What are the costs of software engineering?
Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs
Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability
Distribution of costs depends on the development model that is used

32. What is CASE ? (Computer-Aided Software Engineering)
Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing
Upper-CASE
Tools to support the early process activities of requirements and design
Lower-CASE
Tools to support later activities such as programming, debugging and testing

33. What are the attributes of good software?
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
Maintainability
Software must evolve to meet changing needs
Dependability
Software must be trustworthy
Efficiency
Software should not make wasteful use of system resources
Usability
Software must be usable by the users for which it was designed

34. What are the key challenges facing software engineering?
Software engineering in the 21st century faces three key challenges:
Legacy systems
Old, valuable systems must be maintained and updated
Heterogeneity
Systems are distributed and include a mix of hardware and software
Delivery
There is increasing pressure
for faster delivery of software

35. Legacy Software
Were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms.
Why must it change?
software must be adapted to meet the needs of new computing environments or technology.
software must be enhanced to implement new business requirements.
software must be extended to make it interoperable with other more modern systems or databases.
software must be re-architected to make it viable within a network environment.

36. Software Evolution
The Law of Continuing Change (1974): E-type systems must be continually adapted else they become progressively less satisfactory.
The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.
The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with distribution of product and process measures close to normal.
The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an evolving E-type system is invariant over product lifetime.
The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution.
The Law of Continuing Growth (1980): The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.
The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.
The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi- agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,” Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from:

37. Software Myths
Affect managers, customers (and other non-technical stakeholders) and developers
Are believable because they often have elements of truth,
but …
Invariably lead to bad decisions,
therefore …
Insist on reality as you navigate your way through software engineering

38. Manager Myths
Management may be confident about good standards and clear procedures of the company.
But the taste of any food item is in the eating; not in the Recipe!
Company has latest computers and state-of-the- art software tools, so we shouldn’t worry about the quality of the product.
The infrastructure is only one of the several factors that determine the quality of the product!
Addition of more software specialists, those with higher skills and longer experience may bring the schedule back on the track!
Unfortunately, that may further delay the schedule!
Software is easy to change
The reality is totally different.
Computers provide greater reliability than the devices they replace
This is not always true.

39. Customer Myths
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 with more features is better software
Software can work right the first time
Both are only myths!

40. Developer Myths Once the software is demonstrated, the job is done.
Usually, the problems just begin!
Software quality can not be assessed before testing.
However, quality assessment techniques should be used through out the software development life cycle.
The only deliverable for a software development project is the tested code.
Tested code is only one of the deliverable!
Aim is to develop working programs
Those days are over. Now objective is to develop good quality maintainable programs!