James Nowotarski 19 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.

James Nowotarski

19 September 2006

SE 325/425Principles and

Practices of Software Engineering

Autumn 2006

2

Note that we will skim or skip many of these slides

In keeping with the principles of an agile process, we will adapt to the results and feedback as the class unfolds

Disclaimer

3

Topic Duration

Does software engineering matter? 15 minutes

Recap of session 1 & assignment 1 30 minutes

Rational Unified Process 45 minutes

*** Break

Agile methods 60 minutes

Self-test 15 minutes

Today’s Agenda

4

IT OutsourcingBest jobs in America

1. Software engineer

2. College professor

3. Financial adviser

4. Human resources manager

5. Physician’s assistant

6. Market research analyst

7. Computer/IT analyst

8. Real estate appraiser

9. Pharmacist

10. Psychologist

Source:Kalwarski, T., Mosher, D., Paskin, J. & Rosato, D. (2006, May) 50 best jobs in America. Money. Retrieved September 8, 2006, from http://money.cnn.com/magazines/moneymag/bestjobs/

5

Does IT matter?As noted by Carr, IT is often viewed as a commodity and, thus, not “core”

• IT is like electric power -- a commodity that is required by all but provides distinction to none

• IT capability is broadly accessible and affordable

• New or proprietary technologies offer opportunity for companies to gain a step, but this advantage is short-lived

• Further evidence of IT commoditization:– overcapacity– price drops– vendors positioning selves as “utilities”

Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49.

6

“Why write your own application for word processing or e-mail or, for that matter, supply-chain management when you can buy a ready-made, state-of-the-art application for a fraction of the cost?”

“…more companies [are] replac[ing] customized applications with standardized ones”

Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49.

Does SE matter?

7

Buy vs. buildLease (utility model) vs. buy

• Open source vs. lease

Software as a commodity?

Does SE Matter?

8

Topic Duration




*** Break



Today’s Agenda

9

Software Engineering

• The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines (Fritz Bauer, 1969)

Core Concepts

10

Who is Fritz Bauer?

• Professor of Mathematics and Computer Science at Munich University of Technology

11

Who is Fritz Bauer?

• Chairman of 1968 NATO Software Engineering Conference

• Credited with coining the term “software engineering”

12

Who is Fritz Bauer?

• Software engineering = “The part of computer science that is too difficult for the computer scientists.”

13

Technology

ProcessPeople

The focus of SE 425 is the process component of software engineering

Core Concepts

Technology

ProcessPeople

… for the delivery of technology-enabled business solutions

14

Systems development life cycle (SDLC)

Planning Modeling Construction Deployment

Example

Core Concepts

15

SDLC model

• The iteration and control strategy adopted by a systems development organization

• Examples- Waterfall- Iterative/Evolutionary/Spiral- Incremental

Core Concepts

16

The waterfall model is the granddaddy of life cycle models

Core Concepts

Planning

Modeling

Construction

Deployment

17

What’s wrong with waterfall?

18

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

19

Incremental life cycle models advocate delivering the end product piecemeal

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

20

Key Question: Deliverables

Steps Techniques

What does the system need to do?Functional requirementsQuality requirementsData modelProcess model

1. Gather requirements2. Create data model3. Create process model

InterviewingObservationEntity-relationship modelingNormalizationData flow modeling

Contents of a Process Model. Example: Analysis

Roles Estimating guidelines

Business analystEnd useretc.

8 hours per data entityetc.

21

1. Review existing data models2. Define entities

a. Independentb. Dependent, including Intersection entities

3. Define attributes and keys (primary, foreign)4. Define relationships5. Finalize ERD6. Normalize7. Integrate data models as required8. Verify completeness of the data model

9. Validate the data model a. With usersb. With the enterprise’s data administrator

Process for Building Data Models

Process technique availableDiagramming technique available

Core Concepts

22

Modeling/DiagrammingTechnique

Core Concepts

23

1NF = No repeating groups

2NF = 1NF + no partial dependencies (non-key attribute dependent on portion of primary key)

3NF = 2NF + no transitive dependencies (non-key attribute dependent on another non-key attribute)

Normalization (Process Technique)

Core Concepts

24

Topic Duration




*** Break



Today’s Agenda

25

RUP Guiding Principles

IterativeDevelopment

QualityCustomerValue

Attack riskAccommodatechange

Work togetherExecutablesoftware

Architecturebaseline

Component-baseddevelopment

Objectives

Strategies

Tactics

26

Continuously Verify Quality

In the Rational Unified Process, quality is defined as:

“The characteristic identified by the following: • satisfies or exceeds an agreed upon set of requirements, and • assessed using agreed upon measures and criteria, and • produced using an agreed upon process."

More than simply "meeting requirements" or producing a product that meets user needs, or expectations, etc.

Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).

27

Test Each Iteration

Start testing early Continuously test Test each iteration for functionality

and performance Iterative development makes

regression testing necessary Use automated tests whenever

possible

28








Objectives

Strategies

Tactics

29

Why focus on change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

30

Ways to Accommodate Change

31

Controlling Parallel Development

Multiple developers Multiple teams Multiple sites Multiple iterations Multiple releases Multiple projects Multiple platforms

32

Configuration Management

Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products Librarian like function Manages the version number for each software product Changes made are controlled by a Change Control Process Can be managed manually or through the use of a

configuration management tool (Difficult to do manually, but it can be done.)

• Check In• Check Out• Read only for others

33








Objectives

Strategies

Tactics

34

Why emphasis on executable software?

“Without this first pass, the project manager is at the mercy of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic”

35








Objectives

Strategies

Tactics

36

Architecture: Compelling need to stay ahead

Think of the architecture as an “application” to be used by systems developers

Architecture development and application development are related but separate activities that are staggered and occur in parallel:

Architecture

Analyze Design Implement Support

Application

Analyze Design Implement Support

37

Benefits of Architecture

38








Objectives

Strategies

Tactics

39

Software Components

Definition:

A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

Definition:

A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

40

Components

Airplane

Private Data

Object Operations

Airplane

Private Data

Object Operations

Engines

Private Data

Object Operations

Engines

Private Data

Object Operations

Wings

Private Data

Object Operations

Wings

Private Data

Object Operations

Fuselage

Private Data

Object Operations

Fuselage

Private Data

Object Operations

Tail

Private Data

Object Operations

Tail

Private Data

Object Operations

COMPONENTS - Are objects that are combined into new objects without the use of inheritance

41

Benefits of Component Architectures Resilient Reuse proven solution

elements

42

RUP “Hump” Diagram

43

M C DVersion 1

M C DVersion 2

M C DVersion 3

Iterative Development

44

Product is the result of development cycles

Version 1

Development CycleVersion 2

Development CycleVersion 3

Development Cycle

Product delivered to users

45

Development cycle consists of phases

Development Cycle

Inception Elaboration Construction Transition

46

Phase consists of IterationsDevelopment Cycle

Elaboration

Iterationn Iterationn+1

47

Iteration consists of ActivitiesDevelopment Cycle

Elaboration

Iterationn+1IterationnR

A&D

C

T

R

A&D

C

T

Each phase contains one or more iterations

48

Each Iteration is a mini-waterfall

R

A&D

C

T

R

A&D

C

T

R

A&D

C

T

49

Iterative Advantages/Disadvantages

Advantages

Disadvantages

50

Waterfall model

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Source: Royce, W. "Managing the Development of Large Software Systems."

51

Is RUP = Waterfall in disguise?

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Inception

Elaboration

Construction

Transition

52

Iteration consists of ActivitiesDevelopment Cycle

Elaboration

Iterationn+1IterationnR

A&D

I

T

R

A&D

I

T

Each phase contains one or more iterations

53

Inside each phase, you plan iterations across disciplines

54

Phase boundaries in RUP are milestones

Inception Elaboration Construction Transition

55

Milestones

• Exit criteria• Decide to proceed, abort, or change course• Measure progress, e.g.,

– use cases completed– features completed– performance requirements satisfied– risks eliminated– test cases passed

56

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

57


Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

58

RUP Artifacts by Phase and Discipline

Discipline Inception Elaboration Construction TransitionBusiness Modeling

Requirements

Analysis & Design

Implementation

Test

Deployment

59


Discipline Inception Elaboration Construction Transition

Configuration and Change Management

Project Management

Environment

60


Discipline Inception Elaboration Construction TransitionBusiness Modeling

RequirementsVisionUse Cases (20-80%)ActorsSoftware Req SpecGlossary

Analysis & Design Software Arch Doc

Implementation

Build PlanBuildTest Results

Test

Test PlanTest ScriptTest DataTest Results

Test Strategy

DeploymentDeployment Plan Training Materials

Support MaterialsAcceptance Test ResultsChange Requests

Product

Executable ArchitectureUser Interface PrototypeUser Interface DesignUse Case RealizationDesign ModelDatabase Design

Business Architecture

61


Discipline Inception Elaboration Construction Transition

Configuration and Change Management

Project Management Risk ListRisk Mgmt PlanBusiness CaseQA PlanSoftware Dev Plan

Environment

Dev Case (Process)ToolsGuidelinesTemplatesSupport

CM PlanCM EnvironmentChange Requests

62

Executable architecture is key artifact from Elaboration

Executable architecture Driven by carefully selected use cases

• Essential• Difficult• Representative cross-section

Addresses most risky technical elements Needs to satisfy functional and nonfunctional

requirements (“ilities”)• Performance, reliability, usability, availability, etc.• Also concurrency, interprocess communication,

data/process distribution, etc.

63

Unified Modeling Language (UML)

“The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction”

Modeling language, not a method Notation, or diagramming technique

UML is independent of process Can be used with any process

64

Visual Modeling Using UML

Actor A

Use Case 1

Use Case 2

Actor B

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼ °ü¸® Å¬¶óÀÌ¾ðÆ®.EXE

WindowsNT

¹®¼ °ü¸® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

Alpha

UNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇÃ¸´Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È ̧é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close fileUse Case 3

Use casediagram Class diagram

Collaboration diagram

Sequence diagram

Component diagram

Statechartdiagram

Deployment diagram

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

65

Types of UML Models Functional requirements models

Use Cases Domain Models (glossary)

Structural modeling Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams

Behavioral modeling Interaction Diagrams

• Sequence Diagrams• Collaboration Diagrams

Activity Diagrams State Chart Diagrams

66

Use Cases Typical interaction between a user and a computer

system Example: Word use cases

Make some text bold Create an index

Content: A few paragraphs of description Essential tool in requirements capture during Inception

and (mostly) during Elaboration Characteristics

Captures some user-visible function May be small or large Achieves a discrete goal for the user

67

RUP Links

RUP Resourceshttp://www-136.ibm.com/developerworks/rational/products/ruphttp://www-128.ibm.com/developerworks/rational/

products/rup

68

Topic Duration




*** Break



Today’s Agenda

69

Topic Duration




*** Break



Today’s Agenda

70

Agile/Light/Lean Methods

On February 11-12, 2001 seventeen proponents met at Snowbird ski resort and what emerged was the:

Agile “Software Development” Alliance

“We have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”

71

Approach References

XP www.extremeprogramming.org

www.xprogramming.com

M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002.

Crystal A. Cockburn, Agile Software Development, Addison-Wesley, 2001

SCRUM K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.

Adaptive Software Development

J. Highsmith, Adaptive Software Development, Dorset House, 2000.

FDD S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002.

Agile - General http://www.agilealliance.org/home

http://www.agilemodeling.com

Agile/Light/Lean Methods

72

XP Background

Developed by Kent Beck and Ward Cunningham Based on Beck and Ward’s experiences

developing Smalltalk software at Tektronix First large project was the C3 Payroll Project at

Chrysler 1993 project started with Business Modeling 1994 development begun with a small 40 person

consulting firm & Smalltalk 1995 performance problems - Kent Beck brought in to

improve quality 1996 Kent Beck took over project and began

implementing project in a new method that we now call Extreme Programming

73








Objectives

Strategies

Tactics

74

XP Conceptual Framework







Objectives

Strategies

Practices

__________________________

______________

75

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

76


Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

77

XP winds the RUP model more tightly

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Each day on an XP project

FunctioningCode

78

Anatomy of XP Planning Terminology

Release

Iteration

Story

Activity

consists of

consists of

is produced by

79

What is XP

Incremental Change

M C DVersion 1

M C DVersion 2

M C DVersion 3

80

What is XP

“Don’t ask me, ask the system” “Have you written a test case for that yet” Put in production as soon as possible

i.e., don’t “shelter” your code “Without this first pass, the project manager is at the mercy

of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic” – Royce, 1970

Rapid Feedback

81

What is XP

“What is the simplest thing that could possibly work?”

Flattened change curve

Assume SimplicityEmbrace Change

82

What is XP

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

RUP – “In general, as the project progresses, you should be more careful about introducing change”

83

What is XP

Time

Co

st

of

ch

an

ge

XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time

84

What is XP

Quality is assumedExcellent, orInsanely excellent

Quality Work

85

What is XP

Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today

“design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design

Key Practices/Features

86

What is XP

Customer on-site as integral part of team Incremental planning

learning to driveprogrammers provide estimates

Short iterations, small releases2 month releases, 2 week iterations

40-hour week

Key Practices/Features (cont.)

87

What is XP

Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester

Begin with the end in mind . . .

88

Topic Duration




*** Break



Today’s Agenda

89

Read Pressman Chapter 25 Indiana Jones activity Assignment 5 – first batch

For September 26

James Nowotarski 19 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.

Documents

software engineering

disclaimer slide

lease software

se matter

doesnt matter

minutes recap of session

sound engineering principles

agile process