Top Banner
Software Engineering Software Engineering
37

Software Engineering

Jan 19, 2016

Download

Documents

makala

Software Engineering. How many lines of code?. Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000 lines Microsoft Windows Vista: 50,000,000+ lines. What is Software Engineering ?. NOT just programming - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Software Engineering

Software EngineeringSoftware Engineering

Page 2: Software 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:• 80,000 lines

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

Page 3: Software Engineering

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

Page 4: Software Engineering

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

Page 5: Software Engineering

Over 50% of software projects failOver 50% of software projects fail

Fred Brooks : IBM’s 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”

Page 6: Software Engineering

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

Difficult to accurately estimate how long something will take

Page 7: Software Engineering

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

Developers typically overestimate/overstate their productivity

Page 8: Software Engineering

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

Requirements are not always clearly defined

Page 9: Software Engineering

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

Requirements are not always realistic

Page 10: Software Engineering

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

Requirements are always changing

Page 11: Software Engineering

Software development = tradeoffsSoftware development = tradeoffs

• Cost vs Scope vs Quality vs Time

• Security vs Performance

• Specialization vs Generalization

• Specificity vs Flexibility

Page 12: Software Engineering

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

Page 13: Software Engineering

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

Page 14: Software Engineering

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

Page 15: Software Engineering

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

Page 16: Software Engineering

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

Page 17: Software Engineering

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

Page 18: Software Engineering

In the Beginning…In the Beginning…

Page 19: Software Engineering

Build FirstVersion

Retirement

Operations

Modify untilCustomer satisfied

Code-and-FixCode-and-Fix

Page 20: Software Engineering

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

Page 21: Software Engineering

Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

WaterfallWaterfall

Page 22: Software Engineering

More Detailed WaterfallMore Detailed WaterfallREQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Page 23: Software Engineering

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

Page 24: Software Engineering

Waterfall*Waterfall*REQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Page 25: Software Engineering

PrototypingPrototyping

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype

Page 26: Software Engineering

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%

Page 27: Software Engineering

Incremental (Staged)Incremental (Staged)

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design

Page 28: Software Engineering

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

Page 29: Software Engineering

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– …

Page 30: Software Engineering

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

Page 31: Software Engineering

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

Page 32: Software Engineering

Agile ProgrammingAgile Programming

Initial Concept

Operations

Acceptance Testing

and Delivery

Requirements and Iteration

Planning

Next Iteration

Design andImplement

Page 33: Software Engineering

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)

Page 34: Software Engineering

eXtreme ProgrammingeXtreme Programming

Page 35: Software Engineering

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

Page 36: Software Engineering

What does this mean for me?What does this mean for me?

Page 37: Software Engineering

Software Engineering in CS1007Software Engineering in CS1007

• The programs you write in this class will graded as much on their “quality” as on their functionality

• This means that they should be:– Well-designed– Robust and well-tested

• You need to come up with your own personal “software process” to ensure the quality of the code you write