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

James Nowotarski

26 September 2006

SE 325/425Principles and

Practices of Software Engineering

Autumn 2006

2

Topic Duration

Finish RUP, Agile, XP 45 minutes

Risk management 45 minutes

*** Break

Current event reports 15 minutes


Wrap-up 15 minutes

Today’s Agenda

3

Survey Results[plus Jordan]

Key issues/trends: Outsourcing 7 Requirements 5 Web 2.0 4 Security 3 Dispersed teams 3 Project mgmt 2/1 Six sigma/Quality 2/1 Agile methods 2 IT working with business units 2 Upgrades 2 Maintenance 1 Communication 1

4

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

5

The waterfall model is the granddaddy of life cycle models

Waterfall

Planning

Modeling

Construction

Deployment

6

Protracted integration and late breakage

Conventional application of the waterfall model typically results in late integration and performance showstoppers

Dev

elop

men

t p

rogr

ess

(% c

oded

)

100%Late designbreakage

Original target date

Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).

Integrationbegins

What’s wrong with waterfall?

7

Why focus on change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

8

RUP Guiding Principles

IterativeDevelopment

QualityCustomerValue

Attack riskAccommodatechange

Work togetherExecutablesoftware

Architecturebaseline

Component-baseddevelopment

Objectives

Strategies

Tactics

9

RUP “Hump” Diagram

10

Inside each phase, you plan iterations across disciplines

11

Phase boundaries in waterfall are activities

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

12

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

13

Iterative Advantages/Disadvantages

Advantages

Disadvantages Difficult to know when an

iteration is done More difficult to manager Higher need for ongoing user

involvement Easier to lose focus, get

distracted (concurrency)

14 Copyright © 1997 by Rational Software Corporation

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

Risk Profile: Iterative vs. Waterfall

Iterative

15

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

16

RUP Guiding Principles







Objectives

Strategies

Tactics

17

XP Conceptual Framework







Objectives

Strategies

Practices

18

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

19

XP winds the RUP model more tightly

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Each day on an XP project

FunctioningCode

20

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

21

What is XP

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

Flattened change curve

Assume SimplicityEmbrace Change

22

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

23

What is XP

Quality is assumedExcellent, orInsanely excellent

Quality Work

24

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

25

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.)

26

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 Comprehensive suite of tests

Begin with the end in mind . . .

27

Topic Duration

Finish RUP, Agile, XP 45 minutes


*** Break

Current event reports 15 minutes


Wrap-up 15 minutes

Today’s Agenda

28

“The basic problem of software development is risk”

Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley

Risk management

29

What is risk?

something that could go wrong Problem that may occur

Proactive vs. reactive risk management

Don’t worry, I’ll think of something!!

Post-Implementation ReviewProject Manager: Dr. Indiana Jones;

Project Objective: To retrieve priceless gold statue for the museum;

Did the project meet objectives? No. Indy got the statue but lost in in the last phase to evil forces;

Project Costs: High. One guide dead, a severely bruised Indy and a priceless archeological find [the cave which contains photo-electric cells for example] destroyed;

Project Benefits : None - Indy did not save statue for society and research;

Overall success: From all perspectives the Cave Project was dismal failure. Not only did the project fail to meet its objectives but one person died and the project manager was placed at risk throughout the project;

Post-Implementation ReviewIn addition, the project manager Dr. Indiana Jones didn't undertake planning or risk assessment and went into the Cave project completely un-prepared.

Finally, Dr. Jones has exhibited no learning from the project and has continued throughout the entire three releases of the Indiana Jones Integrated Project (Release1: Raiders of the Lost Ark; Release 2: The Temple of Doom; Release 3: The Last Crusade) to walk into other Cave Projects without any planning or formal risk assessment;

Conclusion: Dr. Indiana Jones should be demoted from Project Manager to Trainee ASAP.

34

Categories of software risk

Project Technical Business Legal

Threaten the project plan• Customers• Resources & personnel• Inexperienced management

team• Requirements• Complexity• Size

35



Threaten software quality• Applying unproven

technology• Conversion may uncover

“dirty” data• New interface with a legacy

system

36



Threaten viability of the software product

• Lack of business champion• Senior management

support wanes• Falls out of alignment with

business strategy• Loses budget or personnel

37



• Shareholder lawsuits• Data privacy• Breach of services (third

party solutions provider)

38

Importance of risk management

• Dependence on electronic information and IT systems is essential to support critical business processes. Successful businesses need to better manage the complex technology that is pervasive throughout their organizations in order to respond quickly and safely to business needs. . .

. . . In addition, the regulatory environment is mandating stricter control over information. This, in turn, is driven by increasing disclosures of information system disasters and increasing electronic fraud. The management of IT-related risks is now being understood as a key part of enterprise governance.

Source: IT Governance Institute

Legal/regulatory risks are increasing in importance

39

“It is futile to try to eliminate risk”

-- Peter Drucker, management guru

Risk management

40

Risk management process

Identify Analyze Plan

Cost of protection Cost of exposure

$$ $$

Control

41

Risk management process: artifacts

Identify Analyze Plan Control

• List of risks • Probability• Impact• Cutoff• Risk exposure

• Mitigation plan• Monitoring plan• Contingency plan

42

Risk identification: 80/20 rule

80% of the engineering is consumed by 20% of the requirements

80% of the software cost, errors, and resource consumption is caused by 20% of the components

43

Risk identification: checklists

Example: Technology risks: Is the technology to be built new to your

organization? Do the requirements require the creation of

new algorithms? Does the software interface with new or

unproven hardware or unproven vendor products?

Do the requirements require the creation of components that are unlike anything your organization has previously built?

Do requirements demand the use of new analysis, design, or testing methods?

Do requirements put excessive performance constraints on the product?

44

Risk management process




45

Risk analysis

Software risks always involve the two characteristics of uncertainty and loss.

Uncertainty – The level of certainty about whether the event may or may not happen.

Loss – What is the impact of the event if it does occur?

Don’t hide from project risk. Face it head on!

Measuring Probability In numbers Or as symbols/phrases e.g., ‘High’, ‘Medium’, ‘Low’ These can be converted to numbers if desired

Measuring Impact Same approach as probability – but ‘units’ will probably

be different. e.g., $, time lost, image loss, lives lost

Usually reduced to economic terms

0

0.2

0.4

0.6

0.8

1

1.2

Cat

astr

ophi

c

Larg

e

Med

ium

Low

Sig

nific

ant

Neg

ligib

leterm

loss

(m

illi

on

s)

48

Risk Assessment Example

RISK CATEGORY DESCRIPTION PROBABILITY IMPACTMITIGATION PLAN

CONTINGENCY PLAN

Schedule Unless everything falls into place, may not hit 7/1 conversion go live date

M H

Example

49

Risk planning




50

Risk Assessment Example

RISK CATEGORY DESCRIPTION PROBABILITY IMPACTMITIGATION PLAN

CONTINGENCY PLAN

Schedule Unless everything falls into place, may not hit 7/1 conversion go live date

M H Cut scope to increase likelihood of hitting date;

If date not hit, continue running old system

Example

51

Risk control




52

Group Problem

ERP System Doesn’t Make Grade in Indianahttp://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=95863

In retrospect:• What were the top 2 risks?• What might they have done different to mitigate,

monitor, and manage these risks?

Small group activity

53

Top 2 risks

not ready to go live on scheduled date new system doesn’t interface with existing legacy New system modules don’t interface properly Software quality problems due to inadequate testing Users will not know how to use system (due to

inadequate training) Downtime excessively long while transitioning to new

system Project plan leaves out steps required for dealing with

complexity/scope

54

Mitigation

Talk to Sallie Mae before testing begins Keep old system running until new system

stable More time for testing Talk to experienced personnel Phased rollout Phased delivery, smaller chunks Mock the whole process

55

Monitoring

walkthroughs External party review project Test results (backlog of change

requests, user signoffs, etc.) # users trained, competency

assessment

56

Contingency Planning

do one Fallback plan to existing system

57

“Today, an IT disruption can paralyze a company’s ability to make its products, deliver its services, and connect with its customers, not to mention foul its reputation. Yet few companies have done a thorough job of identifying and tempering their vulnerabilities. Worrying about what might go wrong may not be as glamorous a job as speculating about the future, but it is a more essential job right now.”

Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review. Retrieved September 8, 2006 from EBSCO Host – Business Source Premier database.

Does SE Matter?

58

Read Pressman Chapter 7 Assignment 2 (Risk Management exercise, see course home page) Current Event Reports:

KACZANKOPHAMSHERMANYOCOM-PIATT

For October 3

59

Extra slides

60

Risk vs. Technology Maturity

Impact of Technology Maturity

Risk Early Adopter Mid Adopter Late Adopter

hands-on implementation experience little exper / high riskmore exper / mid risk

much exper / low risk

vendor survival for project after shake-out high risk mid risk low risk

sudden changes in direction of technology high risk mid risk low riskintegrating technology with existing portfolio

high risk mid risk low risk

Benefits

Period for Start of Payoff Short term Mid term Long term

Size of Returns per period Biggest Bigger Big

Risk vs. Return

61

Testing

Requirements

Functional Design

TechnicalDesign

DetailedDesign

Code

Unit Test

IntegrationTest

SystemTest

AcceptanceTest

Flow of Work

Verification

Validation

Testing: Test that the product implements the specification

Legend:

62

Change Control Process

Create InitialSections

Create/ModifyDraft

Review Draft(V&V)

Create Changes to Incorporate

Changes Needed In Document

DocumentApproved

Create Review Revise ReviewReview Approved

Time

...

Document in Production and Under Formal Change Control

Document in Production and Under Formal Change Control

Document Under Development and User Change Control

Document Under Development and User Change Control

Documents

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