Software Engineering New1 1062217755 2

7/29/2019 Software Engineering New1 1062217755 2

1/165

Software Engineering

Lecture 1

Introduction to Software Engineering

Code of Conduct

Software Engineering is a collaborative activity. You areencouraged to work together, but ...

Some tasks may require individual work.

Always give credit to your sources and collaborators.

Good professional practice: To make use of the expertise of others

and to build on previous work, with proper attribution.

Unethical and academic plagiarism: To use the efforts of otherswithout attribution.

Projects

Project teams, about 3 to 5 peoples.

Select your own project, any branch of software engineering

Real project for real client who intends to use the software inproduction.

Feasibility study and plan

Presentations:

requirements

design

final


2/165

Project Selection

Some suggested projects

Recitation section to suggest projects

Contact potential clients:

Gain idea of their expectations

Estimate scope and complexity of the project

Discuss business decisions

Assemble project team

Advertise on the web site

Previous Experience

Biggest program that you have written?

Biggest program that you have worked on?

Biggest project team that you have been part of?

Longest project that you have worked on?

Most people who have used your work?

Longest that your project has been in production?

Course Themes

1. Leadership of large software projects

Software as a product

Clients and their needs

Quality

Requirements and specification

Usability

Evolution

Project management

Personnel management

Economic, legal, and social factors


3/165

Course Themes

2. Large and very large systems

Software design

Software architecture

Object-oriented design

Dependable systems

Reliability

Verification

Legacy systems

Characteristics of Software Products

General characteristics

Usability

Maintainability

Dependability

Efficiency

Good software products require good programming,

but ...

Programming quality is the means to the end, not theend itself.

Software as a Product

Software is expensive!!

Every software project has a trade-off between:

Functionality

Resources (cost)

Timeliness

Example:

Accounting Management System


4/165

Client (a.k.a Customer)

The client provides resources and expects some productin return.

Client satisfaction is the primary measurement ofsuccess.

Question: Who is the client for Microsoft Excel?

Variety of Software Products

Examples?

-Operation System

-Database Management System

-Embedded System

-Games

-Application Software

-

Categories of Product

Categories of client and software product:

Generic (e.g., Microsoft Excel)

Bespoke (customized) (e.g., IRS internalsystem)

Many systems are customized versions of generic

packages (e.g., Cornell's payroll system)


5/165

Variety of Software Products

Software products are very varied

--> Client requirements are very different

--> There is no standard process for software engineering

--> There is no best language, operating system, platform,database system, development environment, etc.

A skilled software developer knows about a wide variety of

approaches, methods, tools. The craft of software engineering

is to select appropriate methods for each project and apply them

effectively.

Professional Responsibility

Organizations put trust in software developers:

Competence: Software that does not work effectively candestroy an organization.

Confidentiali ty: Software developers and systemsadministrators may have access to highly confidential information

(e.g., trade secrets, personal data).

Legal environment: Software exists in a complex legal

environment (e.g., intellectual property, obscenity).

Acceptable use and misuse: Computer abuse can paralyze anorganization (e.g., the Internet worm).


Lecture 2

The Software Process


6/165

Books

Frederick P. Brooks, Jr. The Mythical Man Month.Addison-Wesley, 1972.

Ian Sommerville, Software Engineering, 6th edition.Addison-Wesley, 2000.

Grady Booch, James Rumbach, Ivar Jacobson, TheUnified Modeling Language. Addison-Wesley 1999.

Software Process

Fundamental Assumption:

Good processes lead to good software

Good processes reduce risk

Risk Management

What can go wrong in a software project?

How can the risk be reduced?


7/165

The Software Process (Simplified)

Requirements

Operation andMaintenanceImplementation

Design

Feasibility and

Planning

The Waterfall Model

Requirements

Definition

System and

Software design

Programmingand Unit Testing

Integration and

System Testing

Operation and

Maintenance

Requirements Analysis and Definition

The system's services, constraints and goals are established by

consultation with system users. They are then defined in a

manner that is understandable by both users and development

staff.

This phase can be divided into:

Feasibility study (often carried out separately)

Requirements analysis

Requirements definition

Requirements specification


8/165

System and Software Design

System design: Partition the requirements to hardware orsoftware systems. Establishes an overall system

architecture

Software design: Represent the software system functions

in a form that can be transformed into one or more

executable programs

Unified Modeling Language (UML)

Programming and Unit Testing

The software design is realized as a set of programs orprogram units. (Written specifically, acquired from

elsewhere, or modified.)

Individual components are tested against specifications.

Integration and System Testing

The individual program units are:

integrated and tested as a complete system

tested against the requirements as specified

delivered to the client


9/165

Operation and Maintenance

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified andfixed.

Evolution: The system evolves over time asrequirements change, to add new functions or adapt the

technical environment.

Phase out: The system is withdrawn from service.

Discussion of the Waterfall Model

Advantages:

Process visibility

Dependence on individuals

Quality control

Cost control

Disadvantages:

Each stage in the process reveals newunderstanding of the previous stages, that

requires the earlier stages to be revised.

Feedback in the Waterfall Model

RequirementsDefinition

System andSoftware design

Programming

and Unit Testing

Integration and

System Testing

Operation andMaintenance


10/165

Iterative Refinement

(Evolutionary Development)

Concept:Initial implementation for user comment, followed

by refinement until system is complete.

Vaporware: user interface mock-up

Throw-away software components

Dummy modules

Rapid prototyping

Successive refinement


Requirements

DesignImplementation

(prototype)

Evaluation


Outline

Description

Concurrent

Activities

Requirements

Design

Implementation

Initial

Version

Intermediate

Versions

Final

Version


11/165

Iterative Refinement & Software

Process

Outline

Description

Concurrent

Activities

Requirements

Design

Implementation Final

Version


When is iterative refinement appropriate?

Iterative Refinement + Waterfall Model:

Graphics for Basic

Outline Description: Add vector graphics to

Dartmouth Basic.

Phase 1: Extend current language with a preprocessor

and run-time support package. (1976/77)

Phase 2: Write new compiler and run-time system

incorporating graphics elements. (1978/80)


12/165


Graphics for Basic

Design Issues:

Pictorial subprograms: coordinate systems, window/viewport

User specification of perspective

Design Strategy: (Iterative Refinement)

Write a series of prototypes with various proposed semantics

Evaluate with a set of programming tasks


Graphics for Basic

Phase 1: Implementation (Waterfall)

When the final specification was agreed, the entirepreprocessor and run-time support were recoded.

The system was almost entirely bug-free.

Phase 2: New compiler (Waterfall)

Phase 1 was used as the requirements definition for thefinal version.

Observations about Software Processes

Completed projects should look like the Waterfall Model

but ... the development process is always partly evolutionary.

Risk is lowered by:

Prototyping key components

Dividing into phases

Following a visible software process

Making use of reusable components


13/165


Lecture 3

(a) Feasibility Study

(b) Requirements Definition

Feasibility Study

Before beginning a project, a short, low-cost study to identify

Client

Scope

Potential benefits

Resources needed:

staff, time, equipment, etc.

Potential obstacles

Where are the risks? How can they be minimized?

Feasibility Study

A feasibility study leads to a decision:

go ahead

do not go ahead

think again

In production projects, the feasibility study

often leads to a budget request.

In research, a feasibility study is often in the

form of a proposal.


14/165

CS 501: Client

In CS 501, you have two clients:

The client for the project

The professor for the course

Can you satisfy them both?

Scope

What are the boundaries of the project?

CS 501 Examples:

Static web pages with open access on the Web [Web Profiler]

Used by the general public [Digital Collections]

Varying data formats [Legal Information]

Thousands of sensors [Data mining]

Support for Windows, Mac, Unix [SALSA]

Potential Benefits

Why are you doing thi s project?

Examples

Create a marketable product

Improve the efficiency of an organization

Control a system that is too complex to control manually

New or improved service

Safety or security

Get a good grade on CS 501


15/165

Resources

Examples: CS 501

Staff: 5 to 7 students, with some help. How many hours per week?

What skills do people have?

Time: Must be completed by end of semester, including

operational system, documentation, presentation

Equipment and software: What special needs are there?

Client: Will the client be sufficiently available and helpful?

Obstacles

CS 501 projects

Start-up time. Creating a team, scheduling meetings, acquiring

software, learning new systems, ...

Business considerations. Licenses, trade-secrets, ...

Too ambitious. Nothing to show at the end of the semester.

Changing circumstances. Client leaves the university, ...

What else?

How to Minimize Risk?

CS 501 Proj ects

Several target levels of functionality:

required, desirable, optional

Visible software process: intermediate deliverables

Good communication within team and with

Teaching Assistant


Good processes reduce risk


16/165

Feasibility Report

A wri tten document

For a general audience: client, financial management,

technical management, etc.

Short enough that everybody reads it

Long enough that no important topics are skipped

Requirements Definition and Analysis

Requirements

Definition

System and

Software design


Integration and

System Testing

Operation and

Maintenance

Example: Library of Congress

(A Partial Failure)

Outline DescriptionThe Library of Congress requires a repository system

to store and make accessible very large amounts of

highly varied material over long periods of time.


17/165

Chronology

1993-94 CNRI carries out research on architectures for

digital libraries

1995-97 CNRI implements prototype repository for

Library of Congress

1998 CNRI and Library of Congress carry out requirements

definition

Repository

Identification System Search System

Users

The Repository

Storage and Representation of Complex

Objects

Data

Several representations:

thumbnail image

reference image

archival image

Metadata

Each representation may

have its own metadata


18/165

Repository: Research Achievements

1. CORBA implementation of repository access protocol.

2. Integration of persistent naming through handle system.

3. Use of structural metadata to describe complex objects,

elementary typology.

4. Access management framework and implementation.

5. Applet-based middleware for user interfaces.

6. Information visualization program to view the structure of

large collections.

Good Discoveries During Prototype

Structuring complex information in digital libraries

Data driven digital library interfaces

Comparison of object-oriented, relational, and file

based storage systems

Naming and identification of library objects

Boundaries of required repository system

Bad Discoveries During Prototype

Resistance to change within Library of Congress

Technical weakness of Library of Congress

Gaps in CNRI architecture


19/165

Mistakes

Confusion of objectives (research and implementation)

Failure to involve all stakeholders

Over-ambitious (no proper feasibility study)

The Requirements Process

FeasibilityStudy

Requirements

Analysis

Requirements

DefinitionRequirements

SpecificationFeasibility

Report System

Models Definition of

Requirements

Specification of

RequirementsRequirements

Document

Requirements Definition

High-l evel abstract descri ption of requirements:

Specifies external system behavior

Comprehensible by customer, management and users

Should r eflect accurately what th e customer wants:

Services that the system will provide

Constraints under which it will operate


20/165

Library of Congress Requirements Study

Team (all experienced): Librarian, Software Engineer (CNRI),Computing Project Leader (Library of Congress), + 2 others

Advisors: Mailing list of about 20 knowledgeable stakeholders.

Timetable: Preliminary report (2 months). Final report (1 month).

Functional Requirements

Example: Library of Congress repository

Support for complex digital objects

Access management

Identification

Information hiding

Open protocols and formats

Integration with other systems (scope)

Current Storage Structure

(in Unix files, by aggregate)

Index Generation

(including pre-processing)

American Memory User Interface

(retrieval, navigation, & display)

Object Administration System

Repository

NDLP Workflow

Tracking Support

Handle-server

NDLP collections

already released

NDLP collections

in conversion

Coolidge collection

(for repository test)

Future

NDLP collections

NOW FUTURE

ILS OPAC InterfaceOther User Interfaces

(e.g. RLG, OCLC, DLF partners)

Other applications

and materials

ILS

Handle assignment

& registration Handle resolution

Supporting infrastructure

DRAFTOVERVIEW OF ITS SUPPORT

FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY

AM user interface plus

access managementfor objects/collections


21/165

Non-functional Requirements

Environment:

Estimates of sizes, numbers of users, etc.

Reliability and performance measures and targets

Preferred:

Example: Library of Congress repository

Hardware and software systems (e.g., IBM/Unix) Database systems (e.g., Oracle)

Programming languages (e.g., C and C++)

Evolution of Requirements

If the requirements definition is wrong, the system will be

a failure.

With complex systems, understanding of requirements

always continues to improve.

Therefore...

The requirements definition must evolve.

Its documentation must be kept current (but clearly

identify versions).


Lecture 4

Management I: Project Management


22/165

The Aim of Project Management

To complete a project: On time

On budget

With required functionality

To the satisfaction of the client

Without exhausting the team

The Project Manager

Create and maintain the schedule

Should track progress against schedule

Keep some slack in the schedule

Be continually making adjustments:

Start activities before previous activity complete

Sub-contract activities

Renegotiate deliverables

Keep senior management informed

Project Planning Methods

The Critical Path Method, Gantt charts, Activity bar charts, etc.are roughly equivalent.

These methods are best when:

Model is updated regularly (e.g., monthly)

The structure of the project is well understood

The time estimates are reliable

Activities do not share resources

[Critical Path Method is excellent for large construction

projects.]


23/165

Example: An Open University Course

Deliverables:

16 Written texts (bound in pairs)

8 Television programs

8 Radio programs

4 Computer programs

1 Home experimental kit (scientific calculator)

4 Assignments and sample solutions

Flexibility

Schedule: Dates for broadcasting TV and radio programs arefixed. Printing and mailings can be accelerated if overtime is

used.

Functionality: The course team can decide what goes into the

components of the course.

Resources: The size of the course team can be increased

slightly.

Scheduling: Critical Path Method

An activity

A dummy activity

An event

A milestone


24/165

Critical Path Method

Edit

Unit 3

Print

Unit 3

Revise

Unit 3Mail

Unit 3

other

activities

START END


Edit

Unit 3Typeset

Unit 3

Revise

Unit 3MailUnits 3/4

other

activities

Edit

Unit 4

Print

Units 3/4

Revise

Unit 4

other

activities

Typeset

Unit 4

START


START

Edit

Unit 3

ScriptTV 2

Make

TV 2

Edit

Unit 4

Prototype Computer 1

Program

Computer 1

Document

Computer 1

Mail

Delivery


25/165

Time Estimates for Activities (Weeks)

64

2

2

3

3

1

3

3

82

1 1

4

12

12

1

4

Earliest Start Dates

64

2

2

3

3

1

3

3

8

2

1 1

4

12

12

1

4

0

1

12

12

4

15 17

17

17

19

22

26

23 25

Latest Start Dates

64

2

2

3

3

1

3

3

82

1 1

4

12

12

1

0

11

12

14

13

15 17

17

17

20

23

26

24 25

4


26/165

Critical Path

0/0

1/11

12/12

12/14

4/13

15/15 17/17

17/17

17/17

19/20

22/23

26/26

23/24 25/25

Slack

0/0

1/11

17/17

23/24

10

5

0

12/12

12/14

4/13

15/15 17/17

17/17 19/20

22/23

26/26

25/25

10

0 0

00 0

0

22

99

1

1

3

1 1

Key Personnel

In computing, not all people are equal:

The best are at least 5 times more productive

Some tasks are too difficult for everybody

Adding more people adds communications complexity

Some activities need a single mind

Sometimes, the elapsed time for an activity can not be

shortened.

What happens to the project if a key person is sick or quits?


27/165

Key Personnel: Schedule for Editor

Earliest Start Date Activity

Weeks 15-16 Edit Unit 3Weeks 17-18 Edit Unit 4

Weeks 19-20 Edit Unit 5

Weeks 21-22 Edit Unit 6

Week 15 Review draft of Unit 7

Week 17 Review draft of Unit 8

Week 19 Check proofs of Unit 3

Week 21 Check proofs of Unit 4

Weeks 18-19 Vacation

Week 22 Out sick

Start-up Time

On a big project, the start-up time is typically three to six

months:

Personnel have to complete previous projects (fatigue) or

recruited.

Hardware and software has to be acquired and installed.

Staff have to learn new domain areas and software (slow

while learning)

Clients may not be ready.

Experience with Critical Path Method

Administrative computing department at Dartmouth used the

Critical Path Method for implementation phase of major projects.

Experience: Elapsed time to complete projects was consistently

25% to 40% longer than predicted by model.

Analysis:

Some tasks not anticipated (incomplete understanding)

Some tasks had to be redone (change of requirements,

technical changes)

Key personnel on many activities (schedule conflicts)

System ZZZ (non-billable hours)


28/165


Lecture 5

(a) Documentation

(b) Requirements Analysis

Documentation

Reasons for documentation:

visibility (e.g., project plan, interim report)

user support (e.g., user manual)

team communication (e.g., interface specifications)

maintenance and evolution (e.g., requirements)

Characteristics of documentation:

accurate and kept current

appropriate for audience

maintained online (usually)

simple but professional in style and appearance

Documentation is expensive --> Quality not volume

Form of Documentation

External

Printed

Web site

Internal

Program documentation

Program context (e.g., copyright notices)


29/165

Requirements Definition and Analysis

Requirements

Definition

System and

Software design


Integration and

System Testing

Operation and

Maintenance


FeasibilityStudy

Requirements

Analysis

Requirements



Report System


Requirements

Specification of


Document

Requirements Analysis

1. Understand the requirements in depth:

Domain understanding

Examples: science research, application

Stakeholders

Example: companies, ministries, Danang City


30/165

Viewpoint Analysis

Example: Uni versity Admi ssions System

Applicants

University administration

Admissions office

Financial aid office

Special offices (e.g., athletics, development)

Computing staff

Operations

Software development and maintenance

Academic departments

Interviews with Clients

Cli ents may have onl y a vague concept of requi rements.

Prepare before you meet with them

Keep full notes

If you don't understand, delve further

Small group meetings are often most effective

Cli ents often confuse the current system with the

underlyi ng requirement.


2. Organ ize the requi rements:

Classification into coherent clusters

(e.g., legal requirements)

Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)

Example: Dartmouth general ledger system


31/165


3. Model the requir ements: Informal

Prose

Systematic

Procedural models

Data-centric models

Object models

Formal models

Procedural Models: Flowchart

Operation

Decision

Manual operation

Report

Flowchart: University Admissions

Form

received New?

Databaserecord

T

Notify

student

F Update

databaseComplete?

Notifystudent

T

FEvaluate


32/165

Procedural Models: Pseudo-code

Example: Check project project plan

check_plan (report)

ifreport (date_time) > due_date_timethen error (too_late)

ifreport (client) = none then error (no_client)ifreport (team) < min_team or > max_team

then error (bad_team)iferror() = none

then comments = read_report (report)

return (comments (text), comments (grade))else return error()

Data-Flow Models

External entities

Processing steps

Data stores or sources

Data flows

Example: University Admissions

Applicant

Application

form Receive

application

Completed

applicationEvaluate

Rejection

Offer


33/165


Assemble Application Stage

Applicant

Applicationform

Receive

Completed

application

Supporting

information

Pending

database

Acknowledgment

Initiate

evaluation

Applicant

database

Evaluation

request

AND

AND

Acknowledgment


Process Completed Application Stage

Rejection

Evaluation

Applicant

database

Evaluation

request AcceptanceFinancial

aid

Offer

Special

request

Requirements Analysis v. System Design

Dilemma.

Requirements analysis should make minimal assumptions

about the system design.

But the requirements definition must be consistent with

computing technology and the resources available.

In practice, analysis and design are interwoven. However, do

not to al low the analysis tools to prejudge the system design .


34/165


Lecture 6

(a) Requirements Analysis (continued)

(b) Requirements Specification


FeasibilityStudy

Requirements

Analysis

Requirements



Report System


Requirements

Specification of


Document


Methods for data modeli ng and design

Data flow diagrams

Entity-relation diagrams

Data dictionaries

Object models

Many of these methods blur the distinction between

analysis and design.


35/165

Entity-Relation Model

A Design Methodology for Relational Databases A database of entities and relations

Tools for displaying and manipulating entity-

relation diagrams

Tools for manipulating the database (e.g., as

input to database design)

Warning: There is much confusion about

definitions and notation

Entity-Relation Diagram

An entity

A relation between

entities

An entity or relation

attribute

An inheritance

relation

Example: CS 501 Project

Student

CS501

Student

Major

Project

5 to 7

1

Member of

Person

Client

1

Tech contact

0:n0:n

0:n


36/165

MARC Format for Monographs

(Books)

001 89-16879 r93

245 Campus strategies for libraries and electronic information260 {Bedford, Mass.} : Digital Press, c1990.

650 Academic libraries--United States--Automation.

650 Libraries and electronic publishing--United States.

700 Arms, Caroline R. (Caroline Ruth)

Entity-Relation Diagram for MARC

Book

Short title

Catalog

record

Describes

Control numb

Subject

headingIs about

CreatorEditor of

Author of

1:n

1

0:n

0:n

0:n

0:n

0:n

0:n

Data Dictionaries

A data dicti onary is a li st of names used by the system

Brief definition (e.g., what is "date")

What is it (e.g., number, relation)

Where is it used (e.g., source, used by, etc.)

May be combined with a glossary

As the system is implemented, the data dicti onary in the

requirements is input to the system data dictionary, which is a

formal part of the system specif ication.


37/165

A Note on Object Models

This course teaches object models as a tool for design.

Some people recommend object models for requirements

analysis, but it is difficult to use them without constraining

the system design.

Non-Functional Requirements

Product requirements

performance, reliability, portability, etc...

Organizational requirements

delivery, training, standards, etc...

External requirements

legal, interoperability, etc...

Examples of Non-Functional

Requirements

Privacy (Mercury digital l ibrary)

Functional requirement:

Usage data for management of system

Non-functional requirement:

Usage data must not identify individuals

Mi nimi zing records (NeXT)

Functional requirement:

Retain all required records

Non-functional requirement:

Discard all other records


38/165

Unspoken Requirements

Example:Resistance to change at XXX

Requirements Specification

What is the purpose of the Requirements Specification?

Requirements Specification: Purpose

1. I t descri bes the requir ements to the stakeholders

Expressed in the terms that the stakeholders understand

Comprehensible from many viewpoints

Reviewed by stakeholders so that they understandimplications

Must be clear about assumptions (things left out)


39/165


2. It describes the requir ements to the impl ementers As precise and specific as possible

Expressed in terms that they understand

Comprehensible to new team members


3. I t records the requirements for the futu re

An essential part of system evolution

4. I f may be a contractual document

See you in court!

Requirements Specification: Approaches

Natural language

Structured natural language

Design description language

Requirements specification language

Graphical notation

Formal specification

See Sommerville, Chapter 7.


40/165


Lecture 7

Management II

Business and Legal Aspects of


Legal Environment

Software is developed in a complex legal and

economic framework. Changes in l aws fol low

changes in technical wor ld.

Jurisdictions:

Vietnamese laws

International treaties

Federal and state statues

Precedents Supreme Court

Cost of establishing precedent

Legal Topics

International

Intellectual property (copyright, patent, contract)

Tort (e.g., liability of Internet service provider)

Privacy

Free speech and its limitations (government secrets,

obscenity, blasphemy, hate)

Legal Information Institute: http://www.law.cornell.edu/


41/165

Copyright

A copyright gives the owner the exclusive right to: reproduce

distribute

perform

display

license

Gradually extended to cover text, music,photographs, designs, software, ...

Copyright

Copyright at creation

Works for hire

Contracts and licenses

First sale

Fair use

Infringement (contamination)

I nternational differences Moral rights

Copyright registration

Software Patents

Should be: non-obvious, novel, useful

17 years from award (20 years from application)

Poor quality of examining can lead to broad patents for

routine computing concepts

International differences

Copyright applies to the expression of ideas, patents to the

ideas themselves.


42/165

Contracts and Licences

Contracts allow intellectual property to be sold or li censed

Promise in exchange for adequate consideration

Written document with signature

Permanent or temporary, whole or part

Exclusive or non-exclusive

Termination, problems and difficulties

Terms and conditions as agreed

Enforceable by courts

Derivative Works

When software is derived from other software:

New code is owned by new developer

Conditions that apply to old code apply to derived work

If you write S, which is derived from A, B, C and D, you cannot distribute or licenses S unless you have right to distribute

each of A, B, C and D.

To create a software product, you must have documentedrights to use every component.

Privacy

Invasions of privacy:

intrusion

appropriation of name or likeness

unreasonable publicity

false light

Be very careful about collecting personal

data without the knowledge of the individual


43/165

Software Business Questions

You are employed for company X writing software.

When you leave, who owns your work? What use can youmake of the work?

You work free-lance for company X. When you finish,

who owns your work? What use can you make of the work?

Read the contract!

Your Next Job ...

Employment contract may restrict your next job (not

working for competitors, etc.)

Trade-secret information (non-disclosure agreement)

Ask when you are interviewed!

Trade Secrets and Non-Disclosure

Agreements

Trade Secret

"... information, including a formula, pattern, compilation,

program, device, method, technique, or process that derives

independent economic value from not being generally known

and not being readily ascertainable and is subject to reasonableefforts to maintain secrecy."

Uniform Trade Secrets Act

Non-Di sclosure A greement

Legal agreement not to disclose trade secrets.


44/165

Some Business Models

Software developed in-house

Package licensed to customer, binary only (Microsoft

model)

Package licensed to customer, source code for customer's

modifications

Bespoke software for customer (may be owned by

supplier or customer)

Software bundled with hardware product (PalmPilot)

Free-Lance Software Development

You and a few friends create a company to develop software.

How much should you charge per hour?

You plan to work 40 hours a week for 50 weeks of the year and

want to earn $50,000.

Hourly rate = $50,000 / (40 x 50) = $25

But ...

Free-Lance Software Development

Salary $50,000Taxes and benefits $15,000

Rent, equipment, etc. $10,000

Fees, services, etc. $15,000

Travel and misc. $10,000

TOTAL EXPENSE $100,000

Hours worked 2,000less administration 400

less marketing 350

BILLABLE HOURS 1,250

Hourly rate = $100,000 /1,250 = $80


45/165

Fixed and Variable Cost: Packaged Software

Example:

The initial development cost of a software product

is $10 million.

The cost of packaging and distribution of each

copy is $5.

Technical support costs average $15 per copy.

The package sells for $200 per copy.

Fixed cost = $10 million

Variable cost = $20

Fixed and Variable Costs: Profit or Loss

$15M

$10M

$5M

Unit

sales2,500 5,000 7,500

Community Development

Shareware

Open source (e.g., Linux, Apache, Perl, etc.)

-> Shared development

-> Market penetration

Example: TCP/IP for Vax/VMS

Software may be open source, but packaging and

services can be profitable businesses


46/165

Open Source

Free redistribution

Source code

Derived works

Integrity of the author's source code

No discrimination against persons or groups

Open Source

No discrimination against fields of endeavor

Distribution of license

License must not be specific to a product

License must not contaminate other software

http://www.opensource.org/osd.html

Practical Advice

Be aware of the law, but do not pr etend to be a lawyer.

Use a professional for :

Contracts and licenses

Troubles (complaints, injunctions, subpoenas, etc.)

Personnel issues

When in doubt, ask help!


47/165

Source Code Management

Or

Configuration Management: How I

learned to Stop Worrying and Hate My

Co-workers Less

Source Code Management

Also known as Configuration Management

Source Code Managers are tools that:

Archive your development files

Serve as a single point of entry/exit when adding or

updating development files

Why You Want A Source Control

System

Supports concurrent development

Manage diverging source code bases

Records file/release versions

Easy access to all previous revisions

Can record why a revision was made

Optimal disk space usage

Youll end up doing something equivalent anyway so it

may as well be automated


48/165

Source Code Management Tools Are

Not

A substitute for project management

A replacement for developer communication

How They Work

Central database of source code, documentation, build

tools

Each file stored only once - all other versions are diffs of

that one copy

To Make a Change

Check out the latest version of a file

Make the changes

Update the database

What should be in the database

Source Code

Documentation

Build Tools

Often need old versions of the tools to build old versions

of the software

Ensures software is rebuilt exactly as the customer

received it

Test Suites

Anything else you might want later


49/165

Version Control

Companies ship several products from the same source

base (i.e. Win NT and Windows 2000 versions of MSOffice)

When tracking down bugs you want to examine the code

as it was when the product shipped

Code Sharing

Multiple people can work on the same source base without

colliding

(1) Locks individual files so only one person at a time can

modify it *OR*

(2) Allows multiple people to modify a source file and the

system will automatically merge the changes (usually)

Locking

Only one person can work on a file at once

Works fairly well if developers work on different areas ofthe project and dont conflict often

Problem 1: People forget to unlock files when they are

done

Problem 2: People work around locking by editing aprivate copy and checking in when the file is finally

unlocked - easy to goof and lose changes


50/165

Merging

Several people can work on a file at once

Before committing changes, each user merges their copywith the latest copy in the database

This is normally done automatically by the system and

usually works, but you should not blindly accept the result

of the merge

Labeling

Label all the files in the source base that make up a product

at each milestone

Just before and just after a major change (e.g.. changing

several interfaces)

When a new version ships

Version Trees

Each file in the database has a version tree

Can branch off the version tree to allow separate

development paths

Typically a main path (trunk) for the next major version

and branches off of shipped versions for maintenance


51/165

Branching

When a new version ships, typically create a branch in the

version tree for maintenanceDouble update: fix a defect in the latest version and then

merge the changes (often by hand) into the maintenance

version

Also create personal versions so you can make a change

against a stable source base and then merge in the latest

version later

Examples

RCS

Solaris: man rcsintro

CVS

Solaris: man cvs

www.cyclic.com/cvs/info.html

Visual SourceSafe

msdn.microsoft.com/SSAFE

ClearCase

www.rational.com

RCS

File management only

Transaction model

check out and lock

edit

check in and unlock

Little support for binaries


52/165

CVS

Built on top of RCS

Therefore little support for binaries

Database can be remote

No locking: merge before commit

Fast

Integrates with emacs

SourceSafe

Microsofts entry into the field

Project-based

Checkout-edit-checkin model

Built-in web site creation tools

Integrates with MSDEV

Clearcase

Clearcase is configuration management on steroids

You create a view of the database with a config spec,

which describes how to select files from the database.

When you set a view, Clearcase creates a virtual filesystem

containing only those versions of the files selected by the

config spec


53/165

Clearcase Features

Distributed System

Several groups at different locations can work on the samedatabase

Can install triggers

Example: e-mail the author of a file when some one makes

a change to it

Uses merging model like CVS, but can also lock files

More Clearcase Features

Integrates with MSDEV

Build Management

Knows to rebuild out-of-date files even if your makefile

doesnt

Slow and a bit buggy

Helpful Rules for Version Control Bliss

Archived Files Should Always Compile

Code Review Files Before Check-in

Compile and run latest archived files *as a set* before

Check-in

No Cheating (even simple bug fixes need to undergo this

process)


54/165


Lecture 10

Formal Specification


Why?

Precise standard to define and validate software

Why not?

May be time consuming

Methods not suitable for all applications


Ben Potter, Jane Sinclair, David Till,

An Introduction to Formal Specification and Z

(Prentice Hall) 1991

Jonathan Jacky

The Way of Z

(Cambridge University Press) 1997


55/165

Mathematical Specification

Example of specifi cation

B1,B2, ...Bkis a sequence ofm x m matrices

1, 2, ... kis a sequence ofm x m elementarymatrices

B1-1 = 1

B2-1 = 21

Bk-1 = k ... 21

The numerical accuracy must be such that, for all k,

BkBk-1 - I <

Specification of Programming Languages

::= |

::= {}

::= . {} |

. {} E |

E

::= |

::= + | -

Pascal number syntax

Formal Specification Using Diagrams

digit

unsigned in teger

digit. E

+

-

unsigned integerunsigned integer

unsigned number


56/165

Two Rules

Formal specification does not guarantee correctness

Formal specification does not prescribe the implementation

Informal: The function intrt(a) returns the largest integer

whose square is less than or equal to a.

Formal (Z):

intrt:N N

a : N

intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)

Example: Z Specification Language

Example: Algorithm

1 + 3 + 5 + ... (2n - 1) = n2


57/165

Example: Program

int intrt (int a)

/* Calculate integer square root */{

int i, term, sum;

term = 1; sum = 1;

for (i = 0; sum


58/165

State Transition Diagram

Patients Fields Setup ReadyBeam

on

Enter Enter Start

Stop

Select field

Select patient

(interlock)

(ok)

State Transition Table

Select

Patient

Select

FieldEnter ok Start Stop interlock

Patients

Fields

Setup

Ready

Beam

on

Fields

Fields

Fields

Patients

Patients

Patients

Setup

Setup

Setup

Ready

Beamon

Ready

Z Specification

STATE::=patients |fields |setup | ready | beam_on

EVENT::=select_patient|select_field| enter|start|stop

| ok| interlock

FSM == (STATEXEVENT) STATE

no_change, transitions, control:FSM

Continued on next slide


59/165

Z Specification (continued)

control= no_change transitions

no_change = {s : STATE; e :EVENT (s, e) s }

transitions = { (patients, enter) fields,

(fields, select_patient) patients, (fields, enter) setup,

(setup,select_patient) patients, (setup,select_field) fields,

(setup, ok) ready,

(ready,select_patient) patients, (ready,select_field) fields,

(ready,start) beam_on, (ready, interlock) setup,

(beam_on,stop) ready, (beam_on, interlock) setup }

Schemas

Schema:

The basic unit of formal specification.

Describes admissible states and operations of a

system.

LibSys: An Example of Z

Library system:

Stock of books

Registered users.

Each copy of a book has a unique identifier.

Some books on loan; other books on shelves available

for loan.

Maximum number of books that any user may have on

loan.


60/165

LibSys: Operations

Issue a copy of a book to a reader.

Reader return a book.

Add a copy to the stock.

Remove a copy from the stock.

Inquire which books are on loan to a reader.

Inquire which readers has a particular copy of a book.

Register a new reader.

Cancel a reader's registration.

LibSys

Level of Detail:

Assume given sets:

Copy,Book,Reader

Global constant:

maxloans

Schemas Describing Operations

Naming conventi ons for objects:

Before: plain variables, e.g., r

After: with appended dash, e.g., r'

Input: with appended ?, e.g., r?

Output: with appended !, e.g., r!


61/165

Operation: Issue a Book

Inputs: copy c?, reader r?

Copy must be shelved initially: c? shelved

Reader must be registered: r? readers

Reader must have less than maximum number of books on loan:

#(issued {r?}) < maxloans

Copy must be recorded as issued to the reader:

issued' = issued {c? r?}

The stock and the set of registered readers are unchanged:

stock'=stock; readers'= readers

Domain and Range

dom mX Y

x

ran m

y

m : X Y

dom m = { x X : y Y x y}

ran m = { yY : x X x y}

Operation: Issue a Book

stock,stock': Copy Book

issued, issued': Copy Reader

shelved,shelved': F Copy

readers, readers': FReader

c?: Copy; r? :Reader

[See next slide]

Issue


62/165

Operation: Issue a Book (continued)

[See previous slide]

Issue

shelved dom issued= domstock

shelved' dom issued'= domstock'

shelved dom issued= ;shelved' dom issued'=

ran issued readers; ran issued' readers'r: readers #(issued {r}) maxloans

r: readers' #(issued' {r}) maxloans

c? shelved; r? readers; #(issued {r?}) < maxloans

issued' = issued {c? r?}stock'=stock; readers'= readers

there may not be an intuitive model

Navigation around large space

Conventions are growing over the years

=> scroll bars, buttons, help systems, sliders

=> good for users, good for designers

Menus

Easy for users to learn and use

Certain categories of error are avoided

Enables context-sensitive help

Major diffi culty is structure of lar ge menus

Scrolling menus (e.g., states of USA)

Hierarchical

Associated control panels

Menus plus command line

Users prefer br oad and shall ow to deep menu systems


123/165

1

Information Presentation

Information tobe displayed

Presentation

software

Display

Information Presentation

Text

precise, unambiguous

fast to compute and transmit

Graphics

simple to comprehend

uses of color

shows variations

Help System Design

Help system design is dif fi cult!

Must prototype with mixed users

Categories of help:

=> Overview and general information

=> Specific or context information

=> Tutorials (general)

=> Cook books and wizards

=> Emergency ("I am in trouble ...")

Must have many routes to same information

Never blame the user!


124/165

1

System Considerations of User

Interfaces

Personal computer cycles are there to be used

Any network transfer involves delay

Shared systems have unpredictable performance

Data validation often requires access to shared data

Mobile code poses security risks

Usability and Cost

Performance may be expensive in hardware or special

software development

User interface development may be a major part of a

software development project

Costs are multiplied if a user interface has to be used on

different computers or migrate to different versions of

systems

Web browsers provide a general purpose user interface that

others maintain

Extensibility in Web Browsers

Data types:helper applications, plug-ins

Protocols

HTTP, WAIS, Gopher, FTP, etc.

proxies

Executable code

CGI scripts at server

JavaScript at client

Java applets

Style sheets


125/165

1

Web User Interface: Basic

Web serversWeb browser

Static pages from server

All interaction requires communication with server

Web User Interface: CGI Script

User interface

tables

CGI

Scripts


Scripts can configure pages Scripts can validate information

All interaction requires communication with server

Web User Interface: JavaScript

User interface

tables

CGI

Scripts


JavaScripts can validate information as typed

Some interactions are local

Server interaction constrained by web protocols

Java

Script

html


126/165

1

Web User Interface: Applet

Any

server


Any executable code can run on client

Client can connect to any server

Applets

Device-Aware User Interfaces

Examples of devices:

desk-top computer, fast network connection

laptop computer, intermittent connectivity

PalmPilot, intermittent use of cradle

Smart telephone

Digital camera, camcorder

Device-aware user interfaces are aware of:

=> Performance of device

=> Connectivity

The Importance of Design

Good support f or users i s more than a cosmetic fl ouri sh

Elegant design, appropriate functionality, & responsive system:

=> a measurable difference to their effectiveness

A system that is hard to use:

=> users may fail to find important results,

or mis-interpret what they do find

=> user may give up in disgust

A computer system is only as good as the in terf ace it provi des to

its users


127/165

1


Lecture 19

Performance of Computer Systems

Moore's Law

Original version:

The density of transistors in an integrated circuit will double

every year. (Gordon Moore, Intel, 1965)

Current version:

Cost/performance of silicon chips doubles every 18 months.

Moore's Law and System Design

Design system: 2000

Production use: 2003

Withdrawn from production: 2013

Processor speeds: 1 1.9 28

Memory sizes: 1 1.9 28

Disk capacity: 1 2.2 51

System cost: 1 0.4 0.01


128/165

1

Moore's Law: Rules of Thumb

Planning assumptions:

Every year:cost/performance of silicon chips improves 25%

cost/performance of magnetic media improves 30%

10 years = 100:1

20 years = 10,000:1

Parkinson's Law

Original: Work expands to fill the time available. (C.

Northcote Parkinson)

Planning assumptions:

(a) Demand will expand to use all the hardware available.

(b) Low prices will create new demands.

(c) Your software will be used on equipment that you have not

envisioned.

False Assumptions

Unix file system will never exceed 2 Gbytes (2 32bytes).

AppleTalk networks will never have more than 256 hosts (28bits).

GPS software will not last 1024 weeks.

Nobody at Dartmouth will ever earn more than $10,000 per month.

etc., etc., .....


129/165

1

Moore's Law and the Long Term

1965 When?

Whatlevel?

2000?

Within your

working life?

Predicting System Performance

Mathematical models

Simulation

Direct measurement

Al l requir e detail ed understanding of the

in teracti on between softwar e and systems.

Queues

arrive wait in line service depart

Single server queue


130/165

1

Queues

arrive wait in line

service

depart

Multi -server queue

Mathematical Models

Queueing theory

Good estimates of congestion can be made for single-

server queues with:

arrivals that are independent, random events

(Poisson process)

service times that follow families of distributions

(e.g., negative exponential, gamma)

Many of the results can be extended to multi-server

queues.

Utilization: Rule of Thumb

utilization =mean service time

mean inter-arrival time

When the utilization of any system component

exceeds 30%, be prepared for congestion.


131/165

1

Behavior of Queues: Utilization

mean

delay

utilization10

Simulation

Model the system as set of states and events

advance simulated time

determine which events occurred

update state and event list

repeat

Discrete time simulation: Time is advanced in fixed steps

(e.g., 1 millisecond)

Next event simulation: Time is advanced to next eventEvents can be simulated by random variables (e.g., arrival

of next customer, completion of disk latency)

Timescale

Operations per second

CPU instruction: 400,000,000

Disk latency: 60

read: 25,000,000 bytes

Network LAN: 10,000,000 bytes

dial-up modem: 6,000 bytes


132/165

1

Measurements on Operational Systems

Benchmarks: Run system on standard problemsets, sample inputs, or a simulated load on the system.

Instrumentation: Clock specific events.

Serial and Parallel Processing

Single thread v. multi-thread

e.g., Unixfork

Granularity of locks on data

e.g., record locking

Network congestion

e.g., back-off algorithms

Example: Performance of Disk Array

Each transaction must:

wait for specific disk platter

wait for I/O channel

signal to move heads on disk platter

wait for I/O channel

pause for disk rotation

read data

Close agreement between: results from queueing theory,

simulation, and direct measurement (within 15%).


133/165

1

The Software Process

Requirements

Definition

System and

Software design


Integration and

System Testing

Operation and

Maintenance

Lecture 20

Coding Standards

Tools for Debugging 1


Coding Standards

Or

How to Pound all of your odd-shaped

programmers into a one size fits all hole


134/165

1

I think there may be a bug in Joes Code - Please Fix

func GreenEggsNHam(Not SamIAm, Green EggsNHam)

foreach Green TryThem in SamIAm

do EatThem(TryThem) = false

NotInACarNotOnABus(EggsNHam)

func NotInACarNotOnABus(Green EggsNHam)

EatThem(EggsNHam) = true

NotOnAPlane(EggsNHam)

foreach NotLikeThem SamIAm of EggsNHam do

if not EatThem(SamIAm) then

NotInACarNotOnABus(SamIAm)

IDoNotLikeThem(EggsNHam)

Joes Code Following a Sane Coding Standard . . .

func DepthFirstSearch(graph G, vertex v)

foreach vertex w in G

do Encountered(w) = false

RecursiveDFS(v)

func RecursiveDFS(vertex v)

Encountered(v) = true

PreVisit(v)

foreach neighbor w of v do

if not Encountered(w) then

RecursiveDFS(w)

PostVisit(v)

What are Coding Standards

Coding standards are guidelines for code style and documentation.

The dream is that any developer familiar with the guidelines can work

on any code that followed them.

Standards range from a simple series of stat ements to involved

documents.


135/165

1

Areas Typically Covered

Program Design

Naming Conventions

Formatting Conventions

Documentation

Possibly Even Licensing

Why Have Coding Standards

Greater consistency between developers

Easier to develop and maintain

Saves time and money

Prime Directive

Document every time you violate a standard.

No standard is perfect for every application, but failure to

comply with your standards requires a comment


136/165

1

Amblers Law of Standards

Industry Standards > organizational standards > project s tandards > no standards

The more commonly accepted a standard the easier it is for team members tocommunicate

Invent standards when necessary, but dont waste time creating something that you

wont be able to use later.

All languages have recommended coding standards available. It is well worth your

effort to find and use industry standards

Push for organizational standards whenever possible

Good Coding Style

Names

Use full English descriptors

Use mixed case to make names readable

Use abbreviations sparingly and consistently

Avoid long names

Avoid leading/trailing underscores

Documentation

Document the purpose of every variable

Document why something is done not just what

Accessors

use getVar() and setVar() functions on all class variable unless class is

being used solely as a data structure (OOP)

Member Functions Documentation

What and why member function does what it does

Parameters / return value

How function modifies object

Preconditions /Postconditions

Concurrency issues

Restrictions

Internal Documentation

Control Structures

Why as well as what the code does

Difficult or complex code

Processing order


137/165

1

Three Rules

Coding standards neednt be onerous - find a standard that

works for your team.Standardize early - the effort to bring your old work into

the standard will be too great otherwise.

Encourage a culture where standards are followed.

Examples of Coding Standards

http://www.ambysoft.com/javaCodingStandards.html

http://www.swtech.com/java/codestd/

http://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.html

http://www.scriptics.com/doc/styleGuide.pdf


Lecture 21

Dependable Systems I

Reliability
http://www.ambysoft.com/javaCodingStandards.htmlhttp://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://www.scriptics.com/doc/styleGuide.pdfhttp://www.scriptics.com/doc/styleGuide.pdfhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standards.htmlhttp://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://www.swtech.com/java/codestd/http://www.ambysoft.com/javaCodingStandards.html


138/165

1

Software Reliability

Failure: Software does not deliver the service expected by

the user (e.g., mistake in requirements)

Fault: Programming or design error whereby the delivered

system does not conform to specification

Reliability: Probability of a failure occurring in operationaluse.

Perceived reliability: Depends upon:

user behavior

set of inputs

pain of failure

Reliability Metrics

Probability of failure on demand

Rate of failure occurrence (failure intensity)

Mean time between failures

Availability (up time)

Mean time to repair

Distribution of failures

Hypothetical example: Cars are safer thanairplane in accidents (failures) per hour, but lesssafe in failures per mile.

Reliability Metrics for Distributed Systems

Traditi onal metri cs are hard to apply in mul ti -component

systems:

In a big network, at a given moment something will be givingtrouble, but very few users will see it.

A system that has excellent average reliability may give

terrible service to certain users.

There are so many components that system administratorsrely on automatic reporting systems to identify problem areas.


139/165

1

User Perception of Reliability

1. A personal computer that crashes frequently v. a machinethat is out of service for two days.

2. A database system that crashes frequently but comes back

quickly with no loss of data v. a system that fails once in three

years but data has to be restored from backup.

3. A system that does not fail but has unpredictable periods

when it runs very slowly.

Cost of Improved Reliability

$

Up time

99% 100%

Will you spend your money on new functionality

or improved reliability?

Specification of System Reliability

Example: ATM card reader

Failure class Example Metric

Permanent System fails to operate 1 per 1,000 days

non-corrupting with any card -- reboot

Transient System can not read 1 in 1,000 transactions

non-corrupting an undamaged card

Corrupting A pattern of Never

transactions corrupts

database


140/165

1

Principles for Dependable Systems

The human mind can encompass only limited complexity:

=> Comprehensibility

=> Simplicity

=> Partitioning of complexity

Principles for Dependable Systems

High-quality has to be built-in

=> Each stage of development must be done well

=> Testing and correction does not lead to quality

=> Changes should be incorporated into the structure

Quality Management Processes

Assumption:


The importance of routine:

Standard terminology (requirements, specification,

design, etc.)

Software standards (naming conventions, etc.)

Internal and external documentation

Reporting procedures


141/165

1

Quality Management Processes

Change management:Source code management and version control

Tracking of change requests and bug reports

Procedures for changing requirements specifications,

designs and other documentation

Release control

Design and Code Reviews

Colleagues review each other's work:

can be applied to any stage of software development

can be formal or informal

The developer provides colleagues with:

documentation (e.g., specification or design), or code listing

talks through the work while answering questions

Most effective when developer and reviewers prepare well

Benefits of Design and Code Reviews

Benefits: Extra eyes spot mistakes, suggest improvements

Colleagues share expertise; helps with training

An occasion to tidy loose ends

Incompatibilities between modules can be identified

Helps scheduling and management control

Fundamental requirements:

Senior team members must show leadership

Must be helpful, not threatening


142/165

1

Process (Plan) Reviews

Objectives:

To review progress against plan (formal or informal)

To adjust plan (schedule, team assignments,

functionality, etc.)

Impact on quality:

Good quality systems usually result from plans that are

demanding but realistic

Good people like to be stretched and to work hard, but

must not be pressed beyond their capabilit ies.

Statistical Testing

Determine the operational profile of the software

Select or generate a profile of test data

Apply test data to system, record failure patterns

Compute statistical values of metrics under test conditions

Statistical Testing

Advantages:

Can test with very large numbers of transactions

Can test with extreme cases (high loads, restarts, disruptions)

Can repeat after system modifications

Disadvantages:

Uncertainty in operational profile (unlikely inputs)

Expensive

Can never prove high reliability


143/165

1

Error Avoidance

Risky programming constructs

Pointers

Dynamic memory allocation

Floating-point numbers

Parallelism

Recursion

Interrupts

All are valuable in certain circumstances, but

should be used with discretion

Defensive Programming

Mu rphy's Law:If anything can go wrong, it will.

Defensive Programming:

Redundant code is incorporated to check system state aftermodifications

Implicit assumptions are tested explicitly

Defensive Programming Examples

Use boolean variable not integer

Test i


144/165

1

Some Notable Bugs

Built-in function in Fortran compiler (e0 = 0)

Japanese microcode for Honeywell DPS virtual memory

The microfilm plotter with the missing byte (1:1023)

The Sun 3 page fault that IBM paid to fix

Left handed rotation in the graphics package

Good people work around problems.

The best people track them down and f ix them!


Lecture 22

Dependable Systems II

Validation and Verification

Defensive Programming

Mu rphy's Law:If anything can go wrong, it will.

Defensive Programming:

Redundant code is incorporated to check system state after

modifications

Implicit assumptions are tested explicitly


145/165

1

Defensive Programming Examples

Use boolean variable not integer

Test i


146/165

1

Fault Tolerance

Backwar d Recovery:

Record system state at specific events (checkpoints). After

failure, recreate state at last checkpoint.

Combine checkpoints with system log that allows

transactions from last checkpoint to be repeated automatically.

Fault Tolerance

General Approach:

Failure detection

Damage assessment

Fault recovery

Fault repair

N-version programming -- Execute independentimpl ementation in parall el, compare result s, accept the

most probable.

Validation and Verification

Validation: Are we building the right product?

Verification: Are we building the product right?

In practice, it is sometimes difficult to distinguish between

the two.

That's not a bug. That's a feature!


147/165

1

Cleanroom Software Development

Software development process that aims to develop zero-defect

software.

Formal specification

Incremental development with customer input

Constrained programming options

Static verification

Statistical testing

I t is always better to prevent defects than to remove them later.

Example: The four color problem.

Static and Dynamic Verification

Static veri fi cation:Techniques of verification that do not

include execution of the software.

May be manual or use computer tools.

Dynamic verification

Testing the software with trial data.

Debugging to remove errors.

Static Validation & Verification

Carried out throughout the software development process.

Validation &

verification

Requirements

specification Design Program


148/165

1

Static Verification: Program Inspections

Program reviews whose objective is to detect faults

Code may be read or reviewed line by line.

150 to 250 lines of code in 2 hour meeting.

Use checklist of common errors.

Requires team commitment, e.g., trained leaders

So effective that it can replace unit testing

Inspection Checklist: Common Errors

Data faults: Initialization, constants, array bounds, character strings

Control faults: Conditions, loop termination, compound statements,

case statements

Input/output faults: All inputs used; all outputs assigned a value

Interface faults: Parameter numbers, types, and order; structures and

shared memory

Storage management faults: Modification of links, allocation and de-allocation of memory

Exceptions: Possible errors, error handlers

Static Analysis Tools

Program analyzers scan the source of a program forpossible

faults and anomalies (e.g., Lint for C programs).

Control flow: loops with multiple exit or entry points

Data use: Undeclared or uninitialized variables, unused

variables, multiple assignments, array bounds

Interface faults: Parameter mismatches, non-use of

functions results, uncalled procedures

Storage management: Unassigned pointers, pointer

arithmetic


149/165

1

Static Analysis Tools (continued)

Cross-reference table: Shows every use of a variable,

procedure, object, etc.

Information flow analysis: Identifies input variables on which

an output depends.

Path analysis: Identifies all possible paths through the

program.

Test Design

Testing can never prove that a system is corr ect. I t can only

show that (a) a system is correct in a special case, or (b) that i t

has a fault .

The objective of testing is to find faults.

Testing is never comprehensive.

Testing is expensive.

Testing and Debugging

Testing is most eff ective if di vided into stages:

Unit testing at various levels of granularity

tests by the developer

emphasis is on accuracy of actual code

System and sub-system testing

uses trial data

emphasis is on integration and interfaces

Acceptance testing

uses real data in realistic situations

emphasis is on meeting requirements


150/165

1

Acceptance Testing

Alpha Testing: Clients operate the system in a realisticbut non-production environment

Beta Testing: Clients operate the system in a carefullymonitored production environment

Parallel Testing: Clients operate new system alongsideold production system with same data and compare

results

The Testing Process

System and Acceptance Testing is a major par t of a software

project

It requires time on the schedule

It may require substantial investment in datasets,

equipment, and test software.

Good testing requires good people!

Management and client reports are important parts oftesting.

What is the definition of "done"?

Testing Strategies

Bottom-up testing. Each unit is tested with its own test

environment.

Top-down testing. Large components are tested with

dummy stubs.

user interfaces

work-flowclient and management demonstrations

Stress testing. Tests the system at and beyond its limits.

real-time systems

transaction processing


151/165

1

Test Cases

Test cases are specific tests that are chosen because they are

likely to find faults.

Test cases are chosen to balance expense against chance of

finding serious faults.

Cases chosen by the development team are effective intesting known vulnerable areas.

Cases chosen by experienced outsiders and clients will be

effective in finding gaps left by the developers.

Cases chosen by inexperienced users will find other

faults.

Test Case Selection: Coverage of Inputs

Objective is to test all c lasses of input

Classes of data -- major categories of transaction and

data inputs.

Cornell example: (undergraduate, graduate, transfer, ...)

by (college, school, program, ...) by (standing) by (...)

Ranges of data -- typical values, extremes

Invalid data, reversals, and special cases.

Test Case Selection: Program

Objective is to test all functions of each computer program

Paths through the computer programs

Program flow graph

Check that every path is executed at least once

Dynamic program analyzers

Count number of times each path is executed

Highlight or color source code

Can not be used with time critical software


152/165

1

Program Flow Graph

if-then-elseloop-while

Fixing Bugs

Isolate the bug

Intermittent --> repeatable

Complex example --> simple example

Understand the bug

Root cause

Dependencies

Structural interactions

Fix the bugDesign changes

Documentation changesCode changes

Moving the Bugs Around

Fi xin g bugs is an err or-prone process!

When you fix a bug, fix its environment

Bug fixes need static and dynamic testing

Repeat all tests that have the slightest relevance(regression testing)

Bugs have a habit of r eturning!

When a bug is fixed, add the failure case to the test suite

for the future.


153/165

1

Regression Testing

Applied to modified software to provide confidence thatmodifications behave as intended and do not adversely

affect the behavior of unmodified code.

Basic technique is to repeat entire testing process after

every change, however small.

Real Time Software Development

Testing and debugging need special tool s and

environments

Debuggers, etc., can not be used to test real timeperformance

Simulation of environment may be needed to testinterfaces -- e.g., adjustable clock speed

General purpose tools may not be available

Software Engineering for Real Time

The special characteristics of real time computing require

extra attention to good software engineering principles:

Requirements analysis and specification

Development of tools

Modular design

Exhaustive testing

Heroic programming will fail!


154/165

1


Management III

Managing People

Administration

Return of laptops and wireless cards

-> Dates for return will be announced on "Notices"

-> All equipment must be returned before the

examination. Bring the receipt to the exam.

-> If an extension granted, (e.g., independent

research) must return and be issued again

I f any repair s needed, please swap for replacement sin cewarrant y runs out on December 15.

Administration

Early examination

December 7, 10:00 to 11:30, Upson 5130

Send email to [email protected] if you plan

to take the early examination, by December 5

Al l laptops and wir eless cards must be retur ned

before the examination


155/165

1

Managing People

Theoretical: Organizational behavior

Industrial psychology

Group behavior

Cognitive fundamentals

Economic motivation

Maslow's Hierarchy of Needs

Self-realization needs

Esteem needs

Social needs

Safety needs

Physiological needs

Software Engineering Basics

Professional staff are the major cost of software

Professional staff vary greatly in productivity

=> Ability

=> Education and training

=> Motivation

=> Interaction with colleagues and leaders

=> Work environment

People are productive when happy and happy when

productive


156/165

1

Software is Built by Teams

Best size for a team is 3 to 8 people

Team members may include:

developers (from trainee to expert)

domain experts

graphic or interface designers

software librarians

testers

Teams must have:

administrative leadership (manager)

technical leadership

Group Working

50%

interaction

with

others

20%

non-productive

30%

working alone

Communication

InformalKitchen, smokers' doorway, after work, etc.

Walkabout (tours)

Ad hoc meetings

Staff meetings (non-technical)

Example:Tektronics

Technical meetings

Facilitation

Record of decisions


157/165

1

Administrative Leader (Manager)

Personnel

Assigning tasksHiring, promoting, etc.

Resources

Budgets

Space, facilities

Equipment

Project management

Relationships with other teams and clients

Project plan and schedule

Hiring Criteria

Productivity is a combination of:

Analytic ability

Verbal ability and communication skills

Education

Application domain knowledge

Adaptability and inquisitiveness

Personality and attitude

Platform experience

Programming language experience

Staff Retention

Technically interesting workup to date hardware and software

opportunities to learn and experiment

Feeling of appreciation

management recognition

money and promotion

Working conditions

space, light, noise, parking

flexibility

Organizational dynamics


158/165

1

Firmness

Managers must be fi rm when needed:

Assignment of tasks must be equitable and open;

everybody will have to tackle some of the dreary tasks

Carrots are better than sticks, but poor performance must

be addressed.

Nobody is indispensable; nobody should be allowed to

think that they are indispensable

Technical Challenges

Canceling projects

Example: the Andrew window manager

Changes of environment

Example: the World Wide Web

Technical tinkering v. needed re-engineering

Turning a Group Around

To turn a weak group into a strong one is the greatestchallenge of leadership

The art of the possible

Promotion of the best over the old leaders

Using opportunities to reorganize

Resignations and terminations

Respect people who try, yet refuse to accept problem areas

Brutal and abrupt rarely equals persistent and fi rm


159/165

1

How to be Led

As a jun ior member of a team, what can you do to make it

productive?


Lecture 26

Risk in Software Engineering

Failures and Risks

Software development projects can fai l in many ways:

Bad software engineering

Late, over budget

Lack of function, f

Software Engineering New1 1062217755 2

Documents

Transcript of Software Engineering New1 1062217755 2