An Introduction toSoftware Engineering

CSCI 3033 Data Structures

Acknowledgement

Dr. Yue Krishani Abeysekera Wei Ding Charles Moen

What is Software Engineering?

IEEE definition “Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

System Cost

The relative cost of hardware and software changed drastically in the last 60 years.

Time

% Cost hardware software

Consequences

Cost: Software cost ↓ Hardware cost ↓↓: Moore’s Law, much

faster. Earlier day: optimizing hardware usage.

Assembly language C

System Speed

Moore Law for hardware. No Moore Law for software?

Cloud computing. Wirth Law: software speed is

decreasing more quickly than hardware speed is increasing. This is why efficient programs are always

needed.

Consequences

Hardware is now relatively ‘free’? Selling software, not hardware:

Microsoft. Some software is becoming

relatively ‘free’? Selling service, advertisement instead

of software: Google.

Software Crisis (1965-1985)

Budget and Cost Overrun Cancelled Projects Damaged properties Injury and death

9

Software Life Cycle Models

Abstraction of the software life cycle Some examples

Waterfall model (Royce) Spiral model (Boehm) Rational Unified Process (Booch, Jacobson,

Rumbaugh) Extreme Programming

SWEN 4432 Software Engineering

Software Engineering

Waterfall Model

In Royce's original waterfall model, the following phases are followed perfectly in order:

Requirements specification Design Construction (aka:

implementation or coding) Integration Testing and debugging (aka:

verification) Installation Maintenance

Waterfall Model 2

Some drawbacks: Difficult to make revisions due to

unforeseen problems: no feedback loop Focus on paper documents and

distrustful customer-contractor relationships

Major contributions: identify key activities.

Key Software Activities

5 Phases of Software Life Cycle:

Phase 1: Problem Analysis and SpecificationPhase 2: DesignPhase 3: Implementation (Coding) Phase 4: Testing, Execution and DebuggingPhase 5: Maintenance

Phase 1: Problem Analysis and Specification

Computer Science programming assignment -

specific statement of problem

quantitative description

clearly defined requirements:

input, output, calculations, test data

Computer Science programming assignment -

specific statement of problem

quantitative description

clearly defined requirements:

input, output, calculations, test data

Easy in CS courses, not always in the real world.CPSC SomeCourse Assignment 1 The sum-of-the-years digits method of calculating depreciation is illustrated below. $15,000 is to be depreciated over five years. First calculate the “sum-of-the-years digits,” 1 + 2 + 3 + 4 + 5 = 15. Then depreciate 5/15 of $15,000 ($5,000) over the first year, 4/15 of $15,000 ($4,000) over the second year, 3/15 ($3,000) the third year, and so on. Write a program that reads the amount to be depreciated and the number of years over which it is to be depreciated. Then for each year from 1 through the specified number of years, print the year number and the amount of depreciation for that year under appropriate headings. Execute the program with the following data: $15,000 for 3 years; $7,000 for 10 years; $500 for 20 years; $100 for 1year.

“Real World” request -

general statement of problem

qualitative not quantitative

precision missing for input, output, processing

“Real World” request -

general statement of problem

qualitative not quantitative

precision missing for input, output, processing

To: Bob Byte, Director of Computer Center From: Chuck Cash, V.P. of Scholarships and Financial Aid Date: Wednesday, March 11

Because of new government regulations, we must keep more accurate records of all students currently receiving financial aid and submit regular reports to FFAO (Federal Financial Aid Office). Could we get the computer to do this for us?

Phase 1: Problem Analysis and Specification

Statement of specifications

the formal statement of the problem’s requirements

the major reference document

a benchmark used to evaluate the final system

Sometimes stated precisely using a formal method.

The program should display on the screen a prompt for an amount to be depreciated and the number of years over which it is to be depreciated. If should then read these two values from the keyboard. Once it has the amount and the number of years, it should compute the sum of the integers 1, 2, . . . up to the number of years. It should then display on the screen a table with appropriate headings that shows the year number and the number and the depreciation for that year, for the specified number of years.

The program should display on the screen a prompt for an amount to be depreciated and the number of years over which it is to be depreciated. If should then read these two values from the keyboard. Once it has the amount and the number of years, it should compute the sum of the integers 1, 2, . . . up to the number of years. It should then display on the screen a table with appropriate headings that shows the year number and the number and the depreciation for that year, for the specified number of years.

Phase 2: Design

CS courses small systems few hundred lines of

code simple, straightforward self-contained

“Real” world large systems Tens of thousands

of lines of code complex many components

OOD: Object-Oriented Design

1. Identify the objects in the problem's specification and their types.

2. Identify the operations of the objects (methods) needed to solve the problem.

3. Arrange the operations in a sequence of steps, called an algorithm, which, when applied to the objects, will solve the problem.

Phase 3: Implementation (Coding)

Select language of implementation Encode the design Verify integration Combining program units into a complete

software system. Insure quality

programs must be correct, readable, and understandable, that is, well-structured, documented, and stylistic.

Phase 4: Testing, Execution, and Debugging

Validation: "Are we building the right product?" The software should do what the user really

requires check that documents, program modules, etc.

match the customer's requirements.

Verification: "Are we building the product right?" The software should conform to its specification

check that products are correct, complete, consistent with each other and with those of the preceding phases.

Errors can occur anytime

Specifications don't accurately reflect given information or the user's needs/requests

Logic errors in algorithms Incorrect coding or integrationFailure to handle boundary data or test

values

Different kinds of tests required

Unit tests: Each individual program unit works?

Program components tested in isolation

Integration tests : Units combined correctly?

Component interface and information flow tested

System tests: Overall system works correctly?

The "V" Life Cycle Model

Unit testing

Probably the most rigorous and time-intensive

Surely the most fundamental and important

Kinds of errors tested: syntax linking run-time logic

Two major types: Black-box and White-box tests

Black box or functional test

Outputs produced for various inputs are checked for correctness without considering the internal structure of the program component itself.

Program unit is viewed as a black box that accepts inputs and produces outputs, but the inner workings of the box are not visible.

White box or structural test

Performance is tested by examining code’s internal structure.

Test data is carefully selected so that specific parts of the program unit are exercised. Boundary test: test data with boundary values Statement coverage test: test cases that cover all the

statement in a program Conditional statement coverage test: test cases that test all

the conditions in the conditional statements.

Phase 5: Maintenance

Large % of computer center budgets Large % of programmer's time Largest % of software development cost

Why? Includes modifications and enhancements Due to poor structure, poor documentation, poor style

less likely to catch bugs before release make fixing of bugs difficult and time-consuming impede implementation of enhancements

Some Lessons

Implementation (Coding) A small part of the software lifecycle. Easy to outsource (or out-shore) than

requirement analysis and design. A program is not successful if it

gives some output. Course assignments are usually not

a good training for the whole software life-cycle.

Iterative Process

Waterfall model: no visible feedback loop.

Iterative models/overlapping phases: Spiral model Rational Unified Process

Rational Unified Process

An example of an iterative process

New Factors

The Internet age (1994-2003) Browsers as the universal client agents.

Web 2.0 (~2004-present) New software distribution: software as

a service perpetual beta Machine to machine interaction

New Trends: Lightweight Methodologies

Examples: Extreme Programming Agile Software Development Scrum list for software project

management

What should we do?

Aware of the software life-cycle. Aware of the new forces affecting

software development. Aware of the new software

methodologies. Eventually need to learn:

Modeling Language: e.g. UML Software Process

Relevance to our course

Software will always need to be correct and efficient: Need to learn data structures and

algorithms well.

Questions?