Software EngineeringSoftware Engineering

How many lines of code?How many lines of code?

Average CS1004 assignment:• 200 lines

Average CS4115 project:• 5000 lines

Corporate e-commerce project:• 100,000 lines

Microsoft Windows Vista:• 50,000,000+ lines

Writing a program is easy– Program = code (with comments)

Developing a software system is harder– System = program plus technical documentation

sufficient such that someone other than original developers can maintain

Developing a software product is very hard– Product = system plus customers, fulfilling the

business needs of those customers, with customer-oriented documentation and support

“__________ was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first”

“IBM OS/360 was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first”

-Fred Brooks, 1975

What is What is Software EngineeringSoftware Engineering??

• NOT just programming

• NOT just programming [part of] a large software system

• NOT just programming as a member of a large team

What is What is Software EngineeringSoftware Engineering??

“The practice of creating and maintaining software applications by applying technologies and practices from engineering, computer science, project management, application domains and other fields.”

-Wikipedia

Why do software projects fail?Why do software projects fail?

Difficult to accurately estimate how long something will take

Why do software projects fail?Why do software projects fail?

Developers typically overestimate/overstate their productivity

Why do software projects fail?Why do software projects fail?

Requirements are not always clearly defined

Why do software projects fail?Why do software projects fail?

Requirements are not always realistic

Why do software projects fail?Why do software projects fail?

Requirements are always changing

Software development = tradeoffsSoftware development = tradeoffs

• Cost vs Scope vs Quality vs Time

• Security vs Performance

• Specialization vs Generalization

• Specificity vs Flexibility

Software EngineeringSoftware Engineering

• Processes:– Project management (resources, time, etc.)– Requirements gathering & management– Software design & architecture– Software development– Testing and quality assurance

• Tools:– Software design, development, and testing– Communication– Requirements and defect tracking– Version control

Why Why StudyStudy Software Engineering? Software Engineering?• Writing a program is easy

– Program = code (possibly with comments)

• Developing a software system is harder– System = program plus technical documentation

sufficient such that someone other than original developers can maintain, typically involving environmental interoperation (beyond just UI and file system)

• Developing a software product is very hard– Product = system plus customers, fulfilling the

business needs of those customers, with customer-oriented documentation and support

Why Why StudyStudy Software Engineering? Software Engineering?• Software Engineering aims at supporting

the development of high-quality software products– High-quality software products are more

robust, efficient and effective– High-quality software products are easier to

use, understand, modify, and compose with other high-quality software products

But I just want to learn Java!!!But I just want to learn Java!!!

Software Engineering is still important!Software Engineering is still important!

• “Software Engineers” aren’t the only ones who should know about software engineering

• Creating high-quality software is necessary in any case in which you or someone else will need to maintain and/or modify your code

Software Engineering ActivitiesSoftware Engineering Activities• System Engineering• Process Selection and Training• Requirements

– Eliciting– Analysis– Recording

• Technology Selection and Training• Design

– Architecture– Components– Modules

• Coding – Unit Testing– Debugging

• Integration– Build– Integration Testing– Configuration Management

• System Testing– Performance Testing & Optimization– Acceptance Testing– Beta Testing

• Deployment– Delivery– Installation

• Operations– System Management– Maintenance– Upgrades

• Support Activities– Project Planning and Tracking– Customer Interaction– Process Improvement– Training– Documentation– Personnel Management

In the Beginning…In the Beginning…

Build FirstVersion

Retirement

Operations

Modify untilCustomer satisfied

Code-and-FixCode-and-Fix

Discussion of Code-and-FixDiscussion of Code-and-Fix

• Really Bad• Really Common• Advantages

– No Overhead– No Expertise

• Disadvantages– No means of assessing progress– Difficult to coordinate multiple programmers

• Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

WaterfallWaterfall

Discussion of WaterfallDiscussion of Waterfall• Articulated by Win Royce, ~1970• Widely used today• Advantages

– Measurable progress– Experience applying steps in past projects can be used in

estimating duration of “similar” steps in future projects– Produces software artifacts that can be re-used in other projects

• The original waterfall model (as interpreted by many) disallowed iteration– Inflexible– Monolithic– Requirements change over time– Maintenance not handled well

• The “waterfall with feedback” model was, however, what Royce had in mind

Waterfall*Waterfall*REQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

PrototypingPrototyping

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype

Discussion of PrototypingDiscussion of Prototyping• Mock-ups allow users to visualize an application that

hasn't yet been constructed• Used to help develop requirements specification

– Useful for rapidly changing requirements– Or when customer won’t commit to specification

• Once requirements “known”, waterfall (or some other process model) used

• Prototypes discarded once design begins– Prototypes should not be used as a basis for implementation,

since prototyping tools do not create production quality code– Customer (and management) may need to be “educated” about

prototypes: a prototype is not 80-90% of the final product, usually not even 10%

Incremental (Staged)Incremental (Staged)

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design

Discussion of IncrementalDiscussion of Incremental

• Iterations are classified according to feature sets

– e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next

• Series of increasingly “complete” releases

The Basic Problem: RiskThe Basic Problem: Risk

• Some modern approaches view “risk” as the main problem of software development– Schedule slips– Business changes– Staff turnovers– New technologies– …

Spiral ModelSpiral Model

PLAN DEVELOP AND TEST

DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS

EVALUATE ALTERNATIVESAND RISKS

Requirements,life-cycle plan

Budget1

Alternatives1

Constraints1

Risk analysis1

Risk analysis2

Risk analysis3

Risk analysis4

Constraints2

Constraints3

Constraints4

Budget2

Budget3Budget4

Altern

atives 2

Altern

ative

s 3Altern

ative

s 4

Prototype1

Proto-type2

Proto-type3

Proto-type4

Concept ofoperation

Softw

are

requ

irem

ents

Validated

requirements

Developmentplan

Integrationand test plan

Softw

are

desig

n

Validated,

verified design

Detaileddesign

Code

Unit test

SystemtestAcceptance

testImplementation

plan

start

Discussion of Spiral ModelDiscussion of Spiral Model

• Proposed by Barry Boehm, ~1986• Similar to Incremental Model, but each

iteration is driven by “risk management” and/or customer feedback

• Determine objectives and current status• Identify risks and priorities• Next iteration addresses (current) highest

risk and/or highest priority items• Repeat

Agile ProgrammingAgile Programming

Initial Concept

Operations

Acceptance Testing

and Delivery

Requirements and Iteration

Planning

Next Iteration

Design andImplement

Discussion of AgileDiscussion of Agile

• Each iteration a mini-project– Each iteration’s deliverable is not a prototype, but an

operational system– Understand risk vs. business value in planning

iterations– Put some working functionality into user’s hands as

early as possible• Timeboxing:

– Set the date for delivering an iteration– Date cannot change– Only functionality (scope) can change– Short duration iterations (weeks, not months)

eXtreme ProgrammingeXtreme Programming

eXtreme ProgrammingeXtreme Programming

• Created by Kent Beck in late 1990s

• “Takes best practices to extreme levels”

• Focuses on five values:– Communication – Simplicity – Feedback – Courage – Respect