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

James Nowotarski

30 October 2008

SE 325/425Principles and

Practices of Software Engineering

Autumn 2008

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

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

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

Software configuration management (SCM) process

identification

change control

version control

configuration auditing

reporting

Software Vm.n

SRSSRS

SRSSRSTest

SRSSRS

SystemSpec

Projectplan

SRSSRS

SRSSRSDesign

Documents

WBS RMMM

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

Software configuration items (SCIs)

SCIs SCIs

modified

approved

extracted

stored

Project database

Formaltechnicalreviews

Softwareengineering

SCM controls

Baselined SCI’s

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

Change requests

Change driversUsersBusiness EnvironmentTechnology

Impact analysisWhere-UsedRequirements traceability

“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

Why traceability?

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.

Entities U2 U3 S10 S11 S12 S13

U2 X X X

Traceability matrix

An alternate and probably more common representation.

Traceability matrix

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.

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.

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

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

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

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

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.

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

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

Need for PM balance

PMI focus

Leadershipfocus

Earned Value

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

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

Source: Standish Group, 2007

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

Source: Standish Group, 2007

Project Summit, Nov. 13, 2006

If this is your view of PM, you will fail

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

Keep eye on horizon

BusinessValue

PMI focus(record & report)

• 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

VP Finance VP Marketing VP Product A VP Product B

Function 1

Sys dev’t Finance

Function 1

CIOArchitecture

Operations

Sys dev’t Marketing

Sys dev’t Product A

Sys dev’t Product B

Sys. dev’t

High-Performance Teams

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.

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

FIGURE 11.2

Maslow’s Hierarchy

Managing Diversity

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

FIGURE 15.5

Risk Management

“The basic problem of software development is risk”

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

Risk management

“It is futile to try to eliminate risk”

-- Peter Drucker, management guru

Risk management

“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

What is risk?

Categories of software risk

Project Technical Business Legal

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

team• Requirements• Complexity• Size

Threaten software quality• Applying unproven

technology• Conversion may uncover

“dirty” data• New interface with a legacy

system

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

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

party solutions provider)

Proactive vs. reactive risk management

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

Tackle risk early in the project

Risk management process

Identify Analyze Plan

Cost of protection Cost of exposure

Control

Risk management process: artifacts

Identify Analyze Plan Control

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

• Mitigation plan• Monitoring plan• Contingency plan

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

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?

Risk management process

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

leterm

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

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.

Risk planning

RMMM=Risk Mitigation, Monitoring, & Mgmt

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

Risk control

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

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

Assignment 4 (Risk Management) Readings Current event reports

For November 6

Extra Slides

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?

Strategies are typically implemented through projects

Expectancy TheoryM = V * E * I

Discuss

Millenials (born 1978-92) – How different?

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

Documents

IS 483 Information Systems Management James Nowotarski 17 April 2003

James Nowotarski 22 May 2008 IS 425 Enterprise Information Spring 2008

1 CS 425 / CS 625 Software Engineering Fall 2008 Course Syllabus August 25, 2008

25 50 aaR 425- 1 -00450 aaR 425- 1 -004 25 50 425- 1 -004 12Ê 4 Created Date 5/15/2008 10:12:32 AM

James Nowotarski 3 October 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006

James Nowotarski 7 November 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006

SE 470 Software Development Processes James Nowotarski 05 May 2003

IS 483 Information Systems Management James Nowotarski 8 May 2003

James Nowotarski 24 April 2008 IS 425 Enterprise Information Spring 2008

IS 483 Information Systems Management James Nowotarski 3 April 2003

IS 421 Information Systems Analysis James Nowotarski 21 October 2002

James Nowotarski 5 June 2008 IS 425 Enterprise Information Spring 2008

SE 470 Software Development Processes James Nowotarski 28 April 2003

IS 483 Information Systems Management James Nowotarski 24 April 2003

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

SE 470 Software Development Processes James Nowotarski 14 April 2003

ECON 425/563 // CPSC 455/555 NOVEMBER 6, 2008

IS 421 Information Systems Analysis James Nowotarski 4 November 2002

James Nowotarski 12 September 2006 SE 425 Principles and Practices of Software Engineering Autumn 2006

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