Chapter 1

Introduction to Software Engineering

1

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.

2

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)

3

Why Software Engineering?

4

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.

5

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)

6

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?7

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

8

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.

9

What is software?

• Computer programs and associated documentation

• Software =Program + Documentation +Operating Procedures

10

Documentation Manuals

• Documentation consists of different types of manuals are

11

Documentation Manuals

• Documentation consists of different types of manuals are

12

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 specification13

Software Product

• Software product is a product designated for delivery to the user

14

Software Characteristics

• Software is engineered• Software does not wear out.

Failure curve for hardware

15

Software Characteristics

• Software is not manufactured• Reusability of components• Software is flexible

16

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 software17

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

18

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

19

Some Questions

• Studies of IT projects by the Standish Group (2000 and 2006)– 350+ IT managers, 8000+ 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?

20

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

21

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

22

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

23

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

24

Software failures

• Therac-25 (1985-1987): 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)

25

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

26

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

27

Software Applications

28

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

29

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

30

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

31

What is CASE ? (Computer-Aided Software Engineering)

32

Upper-CASEUpper-CASE Tools to support the early process Tools to support the early process

activities of requirements and designactivities of requirements and design Lower-CASELower-CASE

Tools to support later activities such Tools to support later activities such as programming, debugging and as programming, debugging and testingtesting

Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing

What are the attributes of good software?

33

MaintainabilityMaintainability Software must evolve to meet changing needsSoftware must evolve to meet changing needs

DependabilityDependability Software must be trustworthySoftware must be trustworthy

EfficiencyEfficiency Software should not make wasteful use of system resourcesSoftware should not make wasteful use of system resources

UsabilityUsability Software must be usable by the users for which it was designedSoftware must be usable by the users for which it was designed

The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable

What are the key challengesfacing 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

34

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

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.

36

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: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf

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

37

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.

38

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!

39

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!

40