CSC 480 Software Engineering

CSC 480 Software Engineering

Lecture 6September 11, 2002

CSC 480 - Software Engineering

Topics Risk ManagementCost Estimation


Risk ManagementA risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resourcesProduct risks affect the quality or performance of the software being developedBusiness risks affect the organisation developing or procuring the software


Software Risks


Risk

Risk type

Description

Staff turnover

Project

Experienced staff will leave the project before it is finished.

Management change

Project

There will be a change of organisational management with different priorities.

Hardware unavailability

Project

Hardware which is essential for the project will not be delivered on schedule.

Requirements change

Project and product

There will be a larger number of changes to the requirements than anticipated.

Specification delays

Project and product

Specifications of essential interfaces are not available on schedule

Size underestimate

Project and product

The size of the system has been underestimated.

CASE tool under-performance

Product

CASE tools which support the project do not perform as anticipated

Technology change

Business

The underlying technology on which the system is built is superseded by new technology.

Product competition

Business

A competitive product is marketed before the system is completed.

Risk Management Process


The Four Risk ActivitiesIdentificationMindset: try to continually identify risksRetirement planningPrioritizationRetirement or mitigation


Risk IdentificationTechnology risksPeople risksOrganisational risksRequirements risksEstimation risks


Risks and Risk Types


Risk type

Possible risks

Technology

The database used in the system cannot process as many transactions per second as expected.

Software components which should be reused contain defects which limit their functionality.

People

It is impossible to recruit staff with the skills required.

Key staff are ill and unavailable at critical times.

Required training for staff is not available.

Organisational

The organisation is restructured so that different management are responsible for the project.

Organisational financial problems force reductions in the project budget.

Tools

The code generated by CASE tools is inefficient.

CASE tools cannot be integrated.

Requirements

Changes to requirements which require major design rework are proposed.

Customers fail to understand the impact of requirements changes.

Estimation

The time required to develop the software is underestimated.

The rate of defect repair is underestimated.

The size of the software is underestimated.

Risk AnalysisAssess probability and seriousness of each riskProbability may be very low, low, moderate, high or very highRisk effects might be catastrophic, serious, tolerable or insignificant


Risk Analysis


Risk

Probability

Effects

Organisational financial problems force reductions in the project budget.

Low

Catastrophic

It is impossible to recruit staff with the skills required for the project.

High

Catastrophic

Key staff are ill at critical times in the project.

Moderate

Serious

Software components which should be reused contain defects which limit their functionality.

Moderate

Serious

Changes to requirements which require major design rework are proposed.

Moderate

Serious

The organisation is restructured so that different management are responsible for the project.

High

Serious

The database used in the system cannot process as many transactions per second as expected.

Moderate

Serious

The time required to develop the software is underestimated.

High

Serious

CASE tools cannot be integrated.

High

Tolerable

Customers fail to understand the impact of requirements changes.

Moderate

Tolerable

Required training for staff is not available.

Moderate

Tolerable

The rate of defect repair is underestimated.

Moderate

Tolerable

The size of the software is underestimated.

High

Tolerable

The code generated by CASE tools is inefficient.

Moderate

Insignificant

Risk PlanningConsider each risk and develop a strategy to manage that riskAvoidance strategiesReduce the probability that the risk will ariseMinimisation strategiesReduce the impact of the risk on the project Contingency plans


Risk Management MindsetProjectfinishProjectstartIdentificationRetirement2. Java skills not high enough.1. May not be possible to superimpose images adequately.1. Retirement by conquest: Demonstrate image super- impositionRisk 1Risk 2Risk 1ProjectfinishRisk 22. Retirement by avoidance: Use C++Projectstart


Risk Management Strategies


Risk

Strategy

Organisational financial problems

Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.

Recruitment problems

Alert customer of potential difficulties and the possibility of delays, investigate buying-in components.

Staff illness

Reorganise team so that there is more overlap of work and people therefore understand each others jobs.

Defective components

Replace potentially defective components with bought-in components of known reliability.

Requirements changes

Derive traceability information to assess requirements change impact, maximise information hiding in the design.

Organisational restructuring

Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.

Database performance

Investigate the possibility of buying a higher-performance database.

Underestimated development time

Investigate buying in components, investigate use of a program generator.

Risk MonitoringAssess each identified risks regularly to decide whether or not it is becoming less or more probableAlso assess whether the effects of the risk have changedEach key risk should be discussed at management progress meetings


Risk Factors


Risk type

Potential indicators

Technology

Late delivery of hardware or support software, many reported technology problems

People

Poor staff morale, poor relationships amongst team member, job availability

Organisational

organisational gossip, lack of action by senior management

Tools

reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations

Requirements

many requirements change requests, customer complaints

Estimation

failure to meet agreed schedule, failure to clear reported defects

Risk Sources Ordered by ImportanceLack of top management commitmentFailure to gain user commitmentMisunderstanding of requirementsInadequate user involvementFailure to manage end-user expectationsChanging scope and/or objectives


Compute Risk Priorities


Range of cost estimates after conceptualization phase,based on actual cost of $1Integration/TestDesignImplementationRequirementsanalysis$125c$4$1$1$1$1Conceptual-izationphaseRange of cost estimates after requirements analysis phaseRange of Errors in Estimating Eventual Cost


Cost Estimation Roadmap1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or1B. Use function point method to estimate lines of code1B.1 Compute un-adjusted function points.1B.2 Apply adjustment process.2. Use lines of code estimates to compute labor and duration using COCOMO formulas.


Function Point ComputationFunctionExternal Inputs (EI)External Inquiries (EIN)External Outputs (EO)fileExternal Logical Files (ELF)filefileInternal Logical Files (ILF)** Internal logical grouping of user data into filesLogicalgroup ofuser dataLogicalgroup ofuser dataLogicalgroup ofuser dataFor a Single Function (IFPUG)


Function Point ComputationExt. inputs EI 3 or 4 or ... 6 = ___Ext. outputs EO 4 or 5 or ... 7 = ___PARAMETER simple complexcountTotal First compute unadjusted FP Followed by applying adjustment process


Sample FP Computation


Sheet1

Unadjusted function point estimate for initial version of Encounter

SimpleMediumComplexSub-Total

countfactorcountfactorcountfactortotals

Ext. inputs13141613

comments:NameReady/moveQualities

Ext. outputs0405070

Ext. inquiries030406025

Int. logical files170100157

comments:Data about the user's character

Ext. interface files15070105


2. Encounter foreign characterSimpleMediumComplexSub-Total

factorfactorfactortotals

Ext. inputs0304060

Ext. outputs1405074

comments:Report on results

Ext. inquiries030406016

Int. logical files170100157


Ext. interface files15070105

-- comments on aboveData about the user's character

Total unadjusted function points for two functions:41

Sheet2

Sheet3

General Characteristics for FP1. Requires backup/recovery?0-22. Data communications required?0-13. Distributed processing functions? 0 Adjustment 1-7. . . . .0 incidental average essential12345Casestudynone moderate significant


Computation of Adjusted FP(Adjusted) Function points = [ Unadjusted function points ] r [ 0.65 + 0.01 r ( total general characteristics ) ]


Constructive Cost Model (COCOMO)Can we use the estimated KLOC as an effort estimation?KLOC / (KLOC/(man*hr)) = man * hrThe answer is NOThe communication, documentation, and integration efforts increase faster than the product size growsEffort (in man-month) is exponential in size


COCOMOOnce we know the effort estimation in man-month, can we just divide it by the number of developers to get the duration?Duration = Effort / (# developers)The answer is NO, againIt takes one chef five hours to cook a turkey. Can we then expect five chefs get one ready in one hour?


COCOMO Formulas (Boehm)Applies to design through integration & test.*Effort = total person-months required. (2) Duration for increasing Effort* ( y b 2.5x 0.35 )(1) Effort* for increasing LOC( y b 3x 1.12 )exponent:< 1> 1


Basic COCOMO FormulaeEffort in Person-months = aKLOC bDuration = c Effort dSoftware Project a b c d Organic2.41.05 2.5 0.38Semidetached3.01.12 2.5 0.35Embedded3.61.20 2.5 0.32Empirical factors due to Boehm [Bo]


Computing COCOMO - Case Study


Chart1

121722141219

171129101715

102114171020

Jan

Feb

Mar

Apr

May

Jun

Sheet1

aKbapprox.

EffortaK^b

LO2.44.21.0510

HI2.43001.051000

cPdapprox.

DurationcP^d

LO2.5100.386

HI2.510000.3835

Selected References [BO] Barry Bohem, Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981[SPR] http://www.spr.com/library/0langtbl.html 12/99Now http://www.spr.com/products/programming.htm with a fee ($75)


Sources of Risk

In identifying the sources of project risk , you can first include all of the sources of uncertainty mentioned earlier in this chapter, such as misapprehension of scope and changes in requirements. Some of these cant properly be laid to rest until they are actually attempted, but crucial parts can be attacked early on. For example, with persistent communication, the core of the customers scope expectations can be discerned at this point.

The figure lists several sources of risk. One of these is tools such as design automation. Tool vendors can go out of business, discontinue support for the tool versions etc. (Indeed, this is one reason that computer-aided software engineering tools did not catch on in the 1980s.) The mobility of software personnel is another source of risk.

CSC 480 Software Engineering

Documents

software engineeringrisks

software engineeringthe

software components

software engineeringlecture

project risks

project budget

risk management processcsc

risk typescsc