Slides 01

5/21/2018 Slides 01

1/50

ISBN 0-13-146913-4Prentice-Hall, 2006

Chapter 1

What is Software

Engineering?

Copyright 2006 Pearson/Prentice Hall. All rights reserved.

5/21/2018 Slides 01

2/50

Pfleeger and Atlee, Software Engineering: Theory and Practice Page 1.2 2006 Pearson/Prentice Hall

Contents

1.1 What is Software Engineering?1.2 How Successful Have We Been?

1.3 What Is Good Software?

1.4 Who Does Software Engineering?

1.5 A Systems Approach1.6 An Engineering Approach

1.7 Members of the Development Team

1.8 How Has Software Engineering Changed?

1.9 Information System Example

1.10 Real Time Example

1.11 What this Chapter Means for You

5/21/2018 Slides 01

3/50


Objectives

What we mean by software engineering Software engineerings track record

What we mean by good software

Why a systems approach is important How software engineering has changed since

the 1970s.

5/21/2018 Slides 01

4/50


1.1 What is Software Engineering?

Solving Problems

Software products are large and complex Development requires analysis and synthesis

Analysis: decompose a large problem intosmaller, understandable pieces

abstraction is the key

Synthesis: build (compose) software from smallerbuilding blocks

composition is challenging

5/21/2018 Slides 01

5/50



Solving Problems (continued)

The analysis process

5/21/2018 Slides 01

6/50




The synthesis process

5/21/2018 Slides 01

7/50




Method: refers to a formal procedure Tool: an instrument or automated system for

accomplishing something in a better way

Procedure: a combination of tools andtechniques to produce a product

Paradigm:philosophy or approach forbuilding a product

5/21/2018 Slides 01

8/50



Where Does the Software Engineer Fit In?

Computer science: focusing on computerhardware and programming languages

Software engineering: focusing on computeras a problem-solving tool

5/21/2018 Slides 01

9/50



Where Does the SW Engineer Fit in? (continued)

Relationship between computer science andsoftware engineering

5/21/2018 Slides 01

10/50


1.2 How Successful Have We Been?

Perform tasks more quickly and effectively Word processing, spreadsheets, e-mail

Support advances in medicine, agriculture,

transportation, multimedia education, andmost other industries

However, software is not without problems

5/21/2018 Slides 01

11/50



Sidebar 1.1 Terminology for Describing Bugs

A fault: occurs when a human makes amistake, called an error, in performing somesoftware activities

A failure: is a departure from the systemsrequired behaviour

5/21/2018 Slides 01

12/50



Examples of Software Failure

IRS hired Sperry Corporation to build an automatedfederal income tax form processing process

An extra $90 M was needed to enhance the original $103product

IRS lost $40.2 M on interests and $22.3 M in overtime

wages because refunds were not returned on time

Malfunctioning code in Therac-25 killed severalpeople

Reliability constraints have caused cancellation of

many

s fety critic l

systems

Safety-critical: something whose failure poses a threat tolife or health

5/21/2018 Slides 01

13/50



Sidebar 1.2 Perspective on Quality

Thetranscendental view: quality issomething we can recognize but not define

Theuser view: quality is fitness for purpose

Themanufacturing view: quality isconformance to specification

Theproduct view: quality tied to inherentproduct characteristics

Thevalue-based view: depends on theamount the customers is willing to pay for it

5/21/2018 Slides 01

14/50


1.3 What is Good Software?

Good software engineering must alwaysinclude a strategy for producing qualitysoftware

Three ways of considering quality

The quality of the product

The quality of the process

The quality of the product in the context of the

business environment

5/21/2018 Slides 01

15/50



The Quality of the Product

Users judge external characteristics (e.g.,correct functionality, number of failures, typeof failures)

Designers and maintainers judge internalcharacteristics (e.g., types of faults)

Thus different stakeholders may havedifferent criteria

Need quality models to relate the usersexternal view to developers internal view

5/21/2018 Slides 01

16/50



The Quality of the Product (continued)

McCalls quality model

5/21/2018 Slides 01

17/50



The Quality of the Process

Quality of the development and maintenanceprocess is as important as the productquality

The development process needs to be

modeled Modeling will address questions such as

Where to find a particular kind of fault

How to find faults earlier

How to build in fault tolerance What are alternative activities

5/21/2018 Slides 01

18/50



The Quality of the Process (continued)

Models for process improvement SEIs Capability Maturity Model (CMM)

ISO 9000

Software Process Improvement and Capability

dEtermination (SPICE)

5/21/2018 Slides 01

19/50



The Quality in the Context of the Business Environment

Business value is as important as technicalvalue

Business value (in relationship to technicalvalue) must be quantified

A common approach: return on investment(ROI) what is given up for other purposes

ROI is interpreted in different terms:

reducing costs, predicting savings,improving productivity, and costs (effortsand resources)

5/21/2018 Slides 01

20/50



The Quality of the Context of the Business Environment

Industrys view of ROI

5/21/2018 Slides 01

21/50



Customer: the company, organization, orperson who pays for the software system

Developer: the company, organization, orperson who is building the software system

User: the person or people who will actuallyuse the system

5/21/2018 Slides 01

22/50



(continued)

Participants (stakeholders) in a softwaredevelopment project

5/21/2018 Slides 01

23/50


1.5 Systems Approach

Identify activities and objects Define the system boundary

Consider nested systems, systems

interrelationship

5/21/2018 Slides 01

24/50



The Element of a System

Activities and objects An activity is an event initiated by a trigger

Objects or entities are the elements involved inthe activities

Relationships and the system boundaries

A relationship defines the interaction amongentities and activities

System boundaries determine the origin of inputand destinations of the output

5/21/2018 Slides 01

25/50



The Elements of a System (continued)

Example of systems: a human respiratorysystem

5/21/2018 Slides 01

26/50



The Element of a System (continued)

A computer system must also be clearlydescribed: System definition of a paycheckproduction

5/21/2018 Slides 01

27/50



Interrelated Systems

Some systems are dependent to othersystems

The interdependencies may be complex

It is possible for one system to exist insideanother system

If the boundary definitions are detailed,building a larger system from the smaller

ones is relatively easy

5/21/2018 Slides 01

28/50



Interrelated Systems (continued)

A layered system

5/21/2018 Slides 01

29/50


1.6 Engineering Approach

Building a System

Requirements analysis and definition System design

Program design

Writing the programs

Unit testing

Integration testing

System testing

System delivery Maintenance

5/21/2018 Slides 01

30/50



Requirement analysts: work with the customers toidentify and document the requirements

Designers: generate a system-level description ofwhat the system us supposed to do

Programmers: write lines of code to implement the

design Testers: catch faults

Trainers: show users how to use the system

Maintenance team: fix faults that show up later

Librarians: prepare and store documents such assoftware requirements

Configuration management team: maintaincorrespondence among various artifacts

5/21/2018 Slides 01

31/50



(continued)

Typical roles played by the members of adevelopment team

5/21/2018 Slides 01

32/50


1.8 How Has Software Engineering Changed?

The Nature of the Change

Before 1970s Single processors: mainframes

Designed in one of two ways

as a transformation: input was converted to output

as a transaction: input determined which functionshould be performed

After 1970s

Run on multiple systems

Perform multi-functions

5/21/2018 Slides 01

33/50


1.8 How Has SE Changed?

Wasserman s Seven Key Factors

Criticality of time-to-market Shifts in the economics of computing

Availability of powerful desktop computing

Extensive local- and wide-area networking Availability and adoption of object-oriented

technology

Graphical user interfaces Unpredictability of the waterfall model of

software development

5/21/2018 Slides 01

34/50



Wasserman s Seven Key Factors (continued)

The key factors that have changed thesoftware development

5/21/2018 Slides 01

35/50



Wasserman s Discipline of Software Engineering

Abstraction Analysis and design methods and notations

User interface prototyping

Software architecture Software process

Reuse

Measurement

Tools and integrated environments

5/21/2018 Slides 01

36/50



Abstraction

A description of the problem at some level ofgeneralization

Hide details

5/21/2018 Slides 01

37/50



Analysis and Design Methods and Notations

Provide documentation Facilitate communication

Offer multiple views

Unify different views

5/21/2018 Slides 01

38/50



User Interface Prototyping

Prototyping: building a small version of asystem

Help users identify key requirements of a system

Demonstrate feasibility

Develop good user interface

5/21/2018 Slides 01

39/50



Software Architecture

A systems architecture describes the systemin terms of a set of architectural units andrelationships between these units

Architectural decomposition techniques

Modular decomposition

Data-oriented decomposition

Event-driven decomposition

Outside-in-design decomposition Object-oriented decomposition

5/21/2018 Slides 01

40/50



Software Process

Many variations Different types of software need different

processes

Enterprise-wide applications need a great deal ofcontrol

Departmental applications can take advantage ofrapid development

5/21/2018 Slides 01

41/50



Software Process (continued)

Pictorial representation of differences indevelopment processes

5/21/2018 Slides 01

42/50



Software Reuse

Commonalities between applications mayallow reusing artifacts from previousdevelopments Improve productivity

Reduce costs Potential concerns It may be faster to build a smaller application

than searching for reusable components

Generalized components take more time to build Must clarify who will be responsible formaintaining reusable components

Generality vs specificity: always a conflict

5/21/2018 Slides 01

43/50



Measurement

Using measurement to help find a solution

5/21/2018 Slides 01

44/50



Tools and Integrated Environments

Platform integration (on heterogeneousnetworks)

Presentation integration (commonality ofuser interface)

Process integration (linking tools and thedevelopment process)

Data integration (to share common data)

Control integration (the ability of one tool toinitiate action in another one)

5/21/2018 Slides 01

45/50



Piccadilly System

Piccadilly Television: regional British TVfranchise

Advertising scheme has many constraints:

alcohol adverts only after 9pm

if actor in show, no same actor in advert within 45minutes

if advert in class of product, no other advert insame class during same break

rates dependent on amount of time bought

Software to determine, track advertising time

5/21/2018 Slides 01

46/50



Piccadilly System (continued)

Piccadilly Television franchise area

5/21/2018 Slides 01

47/50



Piccadilly System (continued)

Piccadilly systems context diagram

5/21/2018 Slides 01

48/50



Ariane-5 rocket, from the European SpaceAgency

June 4, 1996: functioned well for 40seconds, then veered off course and was

destroyed Contained four satellites: cost was $500

million

Reused code from Ariane-4 rocket

5/21/2018 Slides 01

49/50



Ariane-5 Definition of Quality

From the Lions et al report: demonstrated the high quality of the Ariane-5

programme as regards engineering work ingeneral and completeness and traceability of

documents. the supplier of the SRI was only following

the specification given to it. The exceptionwhich occurred was not due to random failure buta design error.

5/21/2018 Slides 01

50/50

1.11 What this Chapter Means for You

Given a problem to solve Analyze it

Synthesize a solution

Understand that requirements may change

Must view quality from several differentperspectives

Use fundamental software engineeringconcepts (e.g., abstractions andmeasurements)

Keep system boundary in mind

Documents

Slides 01