James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008

James Nowotarski

30 October 2008

SE 325/425Principles and

Practices of Software Engineering

Autumn 2008

2

Topic Duration

Configuration management 45 minutes

Project management 30 minutes

*** Break

Current events 15 minutes

Project management 30 minutes

Risk management 60 minutes

Today’s Agenda

33

Software Engineering Body of Knowledge

Software requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality

Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org

What is SE?

tonight

http://www.swebok.org/

4

Thin spread of application domain knowledge

Fluctuating and conflicting requirements

Communication and coordination breakdowns

Three critical factors in development environments when designing large software systems

Closely related

Source: Kurtis, B., Krasner, H., & Iscoe, N. (1988, November). A field study of the software design process for large projects. Communications of the ACM, 31(11), 1268-1287.

Software Configuration Management

6

Software configuration management (SCM) process

identification

change control

version control

configuration auditing

reporting

SCIs

Software Vm.n

7

SRSSRS

SRSSRS

SRSSRSTest

cases

SRSSRS

SRSSRS

SRSSRS

Code

SystemSpec

SRS

Projectplan

SRSSRS

SRSSRS

SRSSRSDesign

Documents

WBS RMMM

Change creates complexity because we have multiple versions of each SCI.

Software configuration items (SCIs)

8

SCIs

SCIs SCIs

SCIs

modified

approved

extracted

SCIs

stored

Project database

Formaltechnicalreviews

Softwareengineering

tasks

SCM controls

Baselined SCI’s

9

IEEE Std. 610.12-1990 defines a baseline as:

A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Baselines

10

Change requests

Change driversUsersBusiness EnvironmentTechnology

Impact analysisWhere-UsedRequirements traceability

11

“Requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.”Gotel and Finkelstein, 1994.

Requirements traceability

12

Why traceability?

13

Req No. Description Traces To

U2 Users shall be able to process retirement claims S10, S11, S12

U3 Users shall be able to process survivor claims S13

S10 The system shall accept retirement data U2

S11 The system shall calculate the amount of retirement U2

S12 The system shall calculate point-to-point travel time U2

S13 The system shall calculate the amount of survivor annuity.

U3

Entities U2 U3 S10 S11 S12 S13

U2 X X X

U3 X

S10 X

S11 X

S12 X

S13 X

Traceability matrix

14

An alternate and probably more common representation.

Traceability matrix

17

Control the Change1. Need for change is

recognized2. Change request is

submitted as a “request for change” (RFC)

3. Developer evaluates4. Change report is

generated5. Change control

authority makes a decision to either: Proceed Deny request.

6. Request is queued for action. ECO is generated(Engineering Change Order).

7. Individuals assigned to configuration objects.

8. Objects checked out and change made.

9. Change audited.10. Objects checked in.11. Baseline established.

SQA activities performed.

12. Rebuild & distribute.

18

Sam

ple

RF

C f

orm

fro

m: N

atio

nal W

eath

er S

ervi

ce

http

://w

ww

.nw

s.no

aa.g

ov/o

so/o

so1/

oso1

1/os

o112

/drg

/drg

rc.h

tm

19

Boeing 767

“Requests for changes came from internal and external sources. Some, such as the color of carpeting or seating arrangements, were negotiated by airline customers; others, such as parts or wiring changes, were proposed by engineers. In total, the two sources generated 12,000 changes on the first 767.”

Source: Harvard Business School. (1991, April 1). The Boeing 767: From concept to production (A). [Case number: 9-688-040]. Boston, MA: Harvard Business School Publishing.

20

Boeing 767

“Managers tracked these changes carefully. Even before the plane’s basic design was frozen, all major changes had to be filed using the same formal procedure. This was done to ensure specifications remained accurate. Once assembly began, a Production Change Board, chaired by the operations department, reviewed all engineering change requests and assessed their likely impact on schedule and cost. If the changes were approved, an implementation plan was then developed.”

21

Basic version control techniques

Maintain ONLY the most recent version and a history of changes. Earlier versions are recreated through

“subtractions” from the recent version

Maintain full copies of ALL versions.More space required

22

Before and after baselining an object may change many times.

These changes can be represented in an evolution graph.

Obj1.0

Obj1.1

Obj1.2

Obj1.3

Obj1.4

Obj2.0

Obj2.1

Obj1.1.1

Obj1.1.2

How does the developer reference all modules, documents, and test cases for version 1.4?How does the marketing department know what customers currently have version 2.1?How can we ensure that changes to 2.1 source code are properly reflected in corresponding documentation?

Version control

23

Check-in/Check-out

Most version control tools in widespread use employ the checkout-edit-checkin model to manage the evolution of version-controlled files in a repository or codebase.

http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

24

Serial development with exclusive checkouts.

In a strictly sequential development model, when a developer checks-out a file, the file is write-locked:

No one may checkout the file if another developer has it checked-out. Instead, they must wait for the file to be checked-in (which releases or removes the write-lock).

This is considered a pessimistic concurrency scheme which forces all work to take place on a single line of development.


25

Concurrent development using branches

Branching is a common mechanism to support concurrent software development.

Allows development to take place along more than one path for a particular file or directory.

When the revision on the new branch is modified and checked-in, the two lines of development will have different contents and will evolve separately


26

Merging is the means by which one development line synchronizes its contents with another development line.

The contents of the latest version on a child branch are reconciled against the contents of the latest version on the parent branch (preferably using a 2-way or 3-way file differencing or comparison tool).


Synchronizing using merges

Project Management

28

Need for PM balance

PMI focus

Leadershipfocus

Earned Value

30

Earned value (EV)

Definition: Budgeted value of the work actually completed to date

The value of a task is proportional to the size of the task # widgets # lines of code budgeted $$$ (this is what we will use)

EV = % complete X overall size of task

Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.

Cost/Schedule GraphCost/Schedule GraphCost/Schedule GraphCost/Schedule Graph

FIGURE 13.5


Earned Value Review ExerciseEarned Value Review ExerciseEarned Value Review ExerciseEarned Value Review Exercise

FIGURE 13.6

Challenges of Project Execution

IT project failure rates are still high . . .

34

Source: Standish Group, 2007

. . . yet more IT organizations than ever require PMI certification

35

Source: Standish Group, 2007

IT o

rgan

izat

ion

s th

at r

equ

ire

PM

I ce

rtif

icat

ion

fo

r P

M’s

Project Summit, Nov. 13, 2006

If this is your view of PM, you will fail

Value

Deliverables

ActivitiesTime

Establish Business Value Metrics

Old School – Monitor a project

New School – Manage a project

Measure Threshold Action

Schedule 10% variance Beat up the team to get the project done on time

Budget 10% variance Beat up the team to get the project done on budget

Earned Value 10% variance

Measure Threshold Action State< 2% variance No action required

2%-5% varianceIndependent audit/assessment to identify root causes of variance, review results within eight weeks

5%-7% variance Re-evaluate business case to ensure it is still valid. Take immediate action on root cause of variance. Review results within four weeks

7% + Discontinue project — no longer achieving the returns needed to justify the investment

Business Impact Measure

Sacrifice quality and beat up the team

38

Keep eye on horizon

BusinessValue

PMI focus(record & report)

39

• High-level executive who endorses and provides political support for the completion of a project

Key to project success:Project sponsor

Organization

The business situation will drive the degree to which IT is weighted toward business users vs. IT concerns

Business user concerns• Responsiveness• Customization• Innovation

IT concerns• Efficiency • Standards• Control

Business situation

Director - CIO

Director, IS Planning

Director, Software Engineering

Manager, Production

Director, Business Technology

Manager, Administration

Director, Technical Services

• Enterprise Arch• Security• S/W Evaluation

• Business analysts• Program managers• Data warehouse

• Developers• Development tools

• Operations• Help desk• Application support

• Network• PC technicians

• $4B revenue company• 400 person IT shop, $70M

• IT HR• IT Finance

Purely centralized ITCEO

Corporatemanagement

and users

Trend: Matrix IT

CEO

VP Finance VP Marketing VP Product A VP Product B

Function 1

Sys dev’t Finance

Function 1

Function 1

Function 1

CIOArchitecture

Operations

Sys dev’t Marketing

Sys dev’t Product A

Sys dev’t Product B

Sys. dev’t

High-Performance Teams

45

Characteristics of High-Performing Teams


Splitting/MultitaskingSplitting/MultitaskingSplitting/MultitaskingSplitting/Multitasking

FIGURE 8.10FIGURE 8.11


Splitting/MultitaskingSplitting/MultitaskingSplitting/MultitaskingSplitting/Multitasking

• Splitting/Multitasking

–A scheduling technique use to get a better project schedule and/or increase resource utilization.

•Involves interrupting work on an activity to employ the resource on another activity, then returning the resource to finish the interrupted work.

•Is feasible when startup and shutdown costs are low.

•Is considered the major reason why projects fail to meet schedule.

48

Layered behavioral model


The Five-Stage Team Development ModelThe Five-Stage Team Development ModelThe Five-Stage Team Development ModelThe Five-Stage Team Development Model

FIGURE 11.1


The Punctuated Equilibrium Model The Punctuated Equilibrium Model of Group Developmentof Group Development

The Punctuated Equilibrium Model The Punctuated Equilibrium Model of Group Developmentof Group Development

FIGURE 11.2

51

Maslow’s Hierarchy

Managing Diversity

53

Functional Cultural Generational Gender Organizational

Managing Diversity

Global delivery

Planning; high level

tasksExecution

Common processestechnology and tools


Hofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions Framework

• Individualism versus collectivism– Identifies whether a culture holds individuals or the group

responsible for each member’s welfare.

• Power distance– Describes degree to which a culture accepts status and power

differences among its members.

• Uncertainty avoidance– Identifies a culture’s willingness to accept uncertainty and

ambiguity about the future.

• Masculinity-femininity– Describes the degree to which the culture emphasizes

competitive and achievement-oriented behavior or displays concerns for relationships.


Sample Country Clusters on Hofstede’s Dimensions Sample Country Clusters on Hofstede’s Dimensions of Individualism-Collectivism and Power Distanceof Individualism-Collectivism and Power Distance

Sample Country Clusters on Hofstede’s Dimensions Sample Country Clusters on Hofstede’s Dimensions of Individualism-Collectivism and Power Distanceof Individualism-Collectivism and Power Distance

FIGURE 15.5

Risk Management

58

“The basic problem of software development is risk”

Beck, K. (2000). Extreme programming explained. Boston, MA: Addison-Wesley

Risk management

59

“It is futile to try to eliminate risk”

-- Peter Drucker, management guru

Risk management

60

“Companies demonstrated to us that running away from risk is a loser, and that risk comes with the territory of a valuable project.”

De Marco, T. & Lister, T. (2003). Waltzing with bears: Managing risks on software projects. New York: Dorset House.

Risk management

61

What is risk?

62

Categories of software risk

Project Technical Business Legal

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

team• Requirements• Complexity• Size

63



Threaten software quality• Applying unproven

technology• Conversion may uncover

“dirty” data• New interface with a legacy

system

64



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

65



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

party solutions provider)

Proactive vs. reactive risk management

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

68

Tackle risk early in the project

69

Risk management process

Identify Analyze Plan

Cost of protection Cost of exposure

$$ $$

Control

70

Risk management process: artifacts

Identify Analyze Plan Control

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

• Mitigation plan• Monitoring plan• Contingency plan

71

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

72

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?

73

Risk management process




74

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)

77

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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 78

Risk Exposure ExampleRisk Exposure Example

Risk identification.Risk identification. Only 70 percent of the software Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be the application. The remaining functionality will have to be custom developed.custom developed.

Risk probability.Risk probability. 80% (likely). 80% (likely). Risk impact.Risk impact. 60 reusable software components were planned. If 60 reusable software components were planned. If

only 70 percent can be used, 18 components would have to be only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that developed from scratch (in addition to other custom software that has been scheduled for development). Since the average has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.to develop the components would be 18 x 100 x 14 = $25,200.

Risk exposure. Risk exposure. RE = 0.80 x 25,200 ~ $20,200. RE = 0.80 x 25,200 ~ $20,200.

79

Risk planning




RMMM=Risk Mitigation, Monitoring, & Mgmt

80

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

81

Risk control


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


82

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

83

Assignment 4 (Risk Management) Readings Current event reports

For November 6

Extra Slides

85

Requirements validationValidating that all requirements have been fulfilled.

Impact analysisAssessing the impact of a proposed change(Existing or new requirements)

Regression testingTest selection following a change.

Requirements MonitoringMeasuring system’s ongoing ability to meet systemic requirements.

Recording RationalesProviding a history

Why traceability?

86

Strategies are typically implemented through projects

87

Expectancy TheoryM = V * E * I

V

I

E

88

Discuss

Millenials (born 1978-92) – How different?

xx