CSC 480 Software Engineering
Lecture 6September 11, 2002
CSC 480 - Software Engineering
Topics Risk ManagementCost Estimation
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Software Risks
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
The Four Risk ActivitiesIdentificationMindset: try to continually identify risksRetirement planningPrioritizationRetirement or mitigation
CSC 480 - Software Engineering
Risk IdentificationTechnology risksPeople risksOrganisational risksRequirements risksEstimation risks
CSC 480 - Software Engineering
Risks and Risk Types
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Risk Analysis
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Risk Management Strategies
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Risk Factors
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Compute Risk Priorities
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
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.
CSC 480 - Software Engineering
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)
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
Sample FP Computation
CSC 480 - Software Engineering
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
comments:Data about the user's character
2. Encounter foreign characterSimpleMediumComplexSub-Total
factorfactorfactortotals
Ext. inputs0304060
Ext. outputs1405074
comments:Report on results
Ext. inquiries030406016
Int. logical files170100157
comments:Data about the user's character
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
CSC 480 - Software Engineering
Computation of Adjusted FP(Adjusted) Function points = [ Unadjusted function points ] r [ 0.65 + 0.01 r ( total general characteristics ) ]
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
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?
CSC 480 - Software Engineering
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
CSC 480 - Software Engineering
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]
CSC 480 - Software Engineering
Computing COCOMO - Case Study
CSC 480 - Software Engineering
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)
CSC 480 - Software Engineering
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.
Top Related