1

Chapter 24Project Scheduling and

Tracking

Chapter 24Project Scheduling and

Tracking Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

2

Why Are Projects Late?Why Are Projects Late? an unrealistic deadline established by someone outside the software

development group changing customer requirements that are not reflected in schedule

changes; an honest underestimate of the amount of effort and/or the number of

resources that will be required to do the job; predictable and/or unpredictable risks that were not considered when

the project commenced; technical difficulties that could not have been foreseen in advance; human difficulties that could not have been foreseen in advance; miscommunication among project staff that results in delays; a failure by project management to recognize that the project is falling

behind schedule and a lack of action to correct the problem

an unrealistic deadline established by someone outside the software development group

changing customer requirements that are not reflected in schedule changes;

an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job;

predictable and/or unpredictable risks that were not considered when the project commenced;

technical difficulties that could not have been foreseen in advance; human difficulties that could not have been foreseen in advance; miscommunication among project staff that results in delays; a failure by project management to recognize that the project is falling

behind schedule and a lack of action to correct the problem

3

Your Response per NapoleonYour Response per Napoleon “ Any commander in chief [software

engineering manager] who undertakes to carry out a plan which he considers defective is at fault; he must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army’s [project team’s] downfall.”

“ Any commander in chief [software engineering manager] who undertakes to carry out a plan which he considers defective is at fault; he must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army’s [project team’s] downfall.”

4

How to Change an Unrealistic DeadlineHow to Change an Unrealistic Deadline Perform a detailed estimate of effort and time

using historical data Using an incremental process model, develop

a strategy to deliver critical functionality by the deadline – document the plan

Meet with the customer and explain why the Offer the incremental development strategy

as an alternative

Perform a detailed estimate of effort and time using historical data

Using an incremental process model, develop a strategy to deliver critical functionality by the deadline – document the plan

Meet with the customer and explain why the Offer the incremental development strategy

as an alternative

5

Scheduling PrinciplesScheduling Principles compartmentalization—define distinct tasks interdependency—indicate task interrelationship effort validation—be sure resources are available defined responsibilities—people must be assigned defined outcomes—each task must have an output defined milestones—review for quality

compartmentalization—define distinct tasks interdependency—indicate task interrelationship effort validation—be sure resources are available defined responsibilities—people must be assigned defined outcomes—each task must have an output defined milestones—review for quality

6

Effort and Delivery TimeEffort and Delivery Time

Effort Cost

Impossible region

td

Ed

Tmin = 0.75T d

to

Eo

Ea = m (td4/ ta

4)

development time

Ea = effort in person-months

td = nominal delivery time for schedule

to = optimal development time (in terms of cost)

ta = actual delivery time desired

7

Empirical Relationship: P vs EEmpirical Relationship: P vs E

Given Putnam’s Software Equation (5-3),

E = L3 / (P3t4)

Consider a project estimated at 33 KLOC, 12 person-years of effort, with a P of 10K, the completion time would be 1.3 years

If deadline can be extended to 1.75 years,

E = L3 / (P3t4) ≈ 3.8 p-years vs 12 p-years

Given Putnam’s Software Equation (5-3),

E = L3 / (P3t4)

Consider a project estimated at 33 KLOC, 12 person-years of effort, with a P of 10K, the completion time would be 1.3 years

If deadline can be extended to 1.75 years,

E = L3 / (P3t4) ≈ 3.8 p-years vs 12 p-years

8

Effort AllocationEffort Allocation

40-50%40-50%

30-40%30-40%

“front end” activities customer communication analysis design review and modification

construction activities coding or code generation

testing and installation unit, integration white-box, black box regression

15-20%15-20%

9

Defining Task SetsDefining Task Sets

determine type of project concept development, new application

development, application enhancement, application maintenance, and reengineering projects

assess the degree of rigor required identify adaptation criteria select appropriate software engineering tasks

determine type of project concept development, new application

development, application enhancement, application maintenance, and reengineering projects

assess the degree of rigor required identify adaptation criteria select appropriate software engineering tasks

10

Task Set Refinement1.1 Concept scoping

determines the overall scope of the project.Task definition: Task 1.1 Concept Scoping

1.1.1 Identify need, benefits and potential customers;

1.1.2 Define desired output/control and input events that drive the application;

Begin Task 1.1.2

1.1.2.1 FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted.

1.1.2.2 Derive a list of customer visible outputs/inputs

1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;

endtask Task 1.1.2

1.1.3 Define the functionality/behavior for each major function;

Begin Task 1.1.3

1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;

1.1.3.2 Derive a model of functions/behaviors;

1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;

endtask Task 1.1.3

1.1.4 Isolate those elements of the technology to be implemented in software;

1.1.5 Research availability of existing software;

1.1.6 Define technical feasibility;

1.1.7 Make quick estimate of size;

1.1.8 Create a Scope Definition;endTask definition: Task 1.1

is refined to

11

Define a Task Network

I.1Conceptscoping

I.3aTech. Risk

Assessment

I.3bTech. Risk

Assessment

I.3cTech. Risk

Assessment

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

I.4Proof ofConcept

I.5aConcept

Implement.

I.5bConcept

Implement.

I.5cConcept

Implement.

I.2Conceptplanning

I.6CustomerReaction

Integratea, b, c

12

Timeline ChartsTimeline ChartsTasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1Task 2Task 3Task 4Task 5Task 6Task 7Task 8Task 9Task 10Task 11Task 12

13

Use Automated Tools toDerive a Timeline ChartI.1.1 Identify need and benefits

Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5

14

Schedule TrackingSchedule Tracking conduct periodic project status meetings in which each team

member reports progress and problems. evaluate the results of all reviews conducted throughout the

software engineering process. determine whether formal project milestones (diamonds in

previous slide) have been accomplished by the scheduled date. compare actual start-date to planned start-date for each project

task listed in the resource table meet informally with practitioners to obtain their subjective

assessment of progress to date and problems on the horizon. use earned value analysis to assess progress quantitatively.

conduct periodic project status meetings in which each team member reports progress and problems.

evaluate the results of all reviews conducted throughout the software engineering process.

determine whether formal project milestones (diamonds in previous slide) have been accomplished by the scheduled date.

compare actual start-date to planned start-date for each project task listed in the resource table

meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

use earned value analysis to assess progress quantitatively.

15

Progress on an OO Project-IProgress on an OO Project-I Technical milestone: OO analysis completed

All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been

defined and reviewed. Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted.

Technical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.

Technical milestone: OO analysis completed All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been

defined and reviewed. Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted.

Technical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.

16

Progress on an OO Project-IIProgress on an OO Project-II Technical milestone: OO programming completed

Each new class has been implemented in code from the design model. Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built.

Technical milestone: OO testing The correctness and completeness of OO analysis and design models

has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been

developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have been

conducted for each class. Test cases are designed and cluster testing (Chapter 14) is completed

and the classes are integrated. System level tests have been completed.

Technical milestone: OO programming completed Each new class has been implemented in code from the design model. Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built.

Technical milestone: OO testing The correctness and completeness of OO analysis and design models

has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been

developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have been

conducted for each class. Test cases are designed and cluster testing (Chapter 14) is completed

and the classes are integrated. System level tests have been completed.

17

Earned Value Analysis (EVA)Earned Value Analysis (EVA)

Earned value is a measure of progress enables us to assess the “percent of

completeness” of a project using quantitative analysis rather than rely on a gut feeling

“provides accurate and reliable readings of performance from as early as 15 percent into the project.” [FLE98]

Earned value is a measure of progress enables us to assess the “percent of

completeness” of a project using quantitative analysis rather than rely on a gut feeling

“provides accurate and reliable readings of performance from as early as 15 percent into the project.” [FLE98]

18

Computing Earned Value-IComputing Earned Value-I The budgeted cost of work scheduled (BCWS) is

determined for each work task represented in the schedule. BCWSi is the effort planned for work task i. To determine progress at a given point along the

project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule.

The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence,

BAC = ∑ (BCWSk) for all tasks k

The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. BCWSi is the effort planned for work task i. To determine progress at a given point along the

project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule.

The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence,

BAC = ∑ (BCWSk) for all tasks k

19

Computing Earned Value-IIComputing Earned Value-II Next, the value for budgeted cost of work performed (BCWP) is computed.

The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.

“the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.” [WIL99]

Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:

Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP – BCWS SPI is an indication of the efficiency with which the project is utilizing

scheduled resources.

Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks

that have actually been completed by a point in time on the project schedule.

“the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.” [WIL99]

Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:

Schedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP – BCWS SPI is an indication of the efficiency with which the project is utilizing

scheduled resources.

20

Computing Earned Value-IIIComputing Earned Value-III Percent scheduled for completion = BCWS/BAC

provides an indication of the percentage of work that should have been completed by time t.

Percent complete = BCWP/BAC

provides a quantitative indication of the percent of completeness of the project at a given point in time, t.

Actual cost of work performed, ACWP, is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute

Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP – ACWP

Percent scheduled for completion = BCWS/BAC

provides an indication of the percentage of work that should have been completed by time t.

Percent complete = BCWP/BAC

provides a quantitative indication of the percent of completeness of the project at a given point in time, t.

Actual cost of work performed, ACWP, is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute

Cost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP – ACWP

21

Problem 24.12Problem 24.12

Assume you are a software project manager and that you’ve been asked to computer earned value statistics for a small software project. The project has 56 planned work tasks that are estimated to require 582 person-days to complete. At the time that you’ve been asked to do the earned value analysis, 12 tasks have been completed. However, the project schedule indicates that 15 tasks should have been completed. The following scheduling data (in person-days) are available:

Assume you are a software project manager and that you’ve been asked to computer earned value statistics for a small software project. The project has 56 planned work tasks that are estimated to require 582 person-days to complete. At the time that you’ve been asked to do the earned value analysis, 12 tasks have been completed. However, the project schedule indicates that 15 tasks should have been completed. The following scheduling data (in person-days) are available:

22

Task Planned Effort Actual Effort1 12 12.52 15 113 13 174 8 9.55 9.5 9.06 18 197 10 108 4 4.59 12 1010 6 6.511 5 412 14 14.513 1614 615 8

Task Planned Effort Actual Effort1 12 12.52 15 113 13 174 8 9.55 9.5 9.06 18 197 10 108 4 4.59 12 1010 6 6.511 5 412 14 14.513 1614 615 8

Compute the SPI, schedule variance, percent scheduled for completion, percent complete, CPI, and cost variance for the project.

23

Chapter 25 Risk Management

Chapter 25 Risk Management

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

24

Project Risks

What can go wrong?What can go wrong?What is the likelihood?What is the likelihood?What will the damage be?What will the damage be?What can we do about it?What can we do about it?

25

Reactive Risk ManagementReactive Risk Management

project team reacts to risks when they occur mitigation—plan for additional resources in

anticipation of fire fighting fix on failure—resource are found and applied

when the risk strikes crisis management—failure does not respond

to applied resources and project is in jeopardy

project team reacts to risks when they occur mitigation—plan for additional resources in

anticipation of fire fighting fix on failure—resource are found and applied

when the risk strikes crisis management—failure does not respond

to applied resources and project is in jeopardy

26

Proactive Risk ManagementProactive Risk Management formal risk analysis is performed organization corrects the root causes of

risk TQM concepts and statistical SQA examining risk sources that lie beyond the

bounds of the software developing the skill to manage change

formal risk analysis is performed organization corrects the root causes of

risk TQM concepts and statistical SQA examining risk sources that lie beyond the

bounds of the software developing the skill to manage change

27

Seven PrinciplesSeven Principles Maintain a global perspective—view software risks within the context of

system and the business problem Take a forward-looking view—think about the risks that may arise in the future;

establish contingency plans Encourage open communication—if someone states a potential risk, don’t

discount it. Integrate—a consideration of risk must be integrated into the software process Emphasize a continuous process—the team must be vigilant throughout the

software process, modifying identified risks as more information is known and adding new ones as better insight is achieved.

Develop a shared product vision—if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur.

Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled

Maintain a global perspective—view software risks within the context of system and the business problem

Take a forward-looking view—think about the risks that may arise in the future; establish contingency plans

Encourage open communication—if someone states a potential risk, don’t discount it.

Integrate—a consideration of risk must be integrated into the software process Emphasize a continuous process—the team must be vigilant throughout the

software process, modifying identified risks as more information is known and adding new ones as better insight is achieved.

Develop a shared product vision—if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur.

Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled

28

RISK

Risk Management Paradigm

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack

29

Risk IdentificationRisk Identification Product size—risks associated with the overall size of the software to be built

or modified. Business impact—risks associated with constraints imposed by management

or the marketplace. Customer characteristics—risks associated with the sophistication of the

customer and the developer's ability to communicate with the customer in a timely manner.

Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.

Development environment—risks associated with the availability and quality of the tools to be used to build the product.

Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.

Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.

Product size—risks associated with the overall size of the software to be built or modified.

Business impact—risks associated with constraints imposed by management or the marketplace.

Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.

Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.

Development environment—risks associated with the availability and quality of the tools to be used to build the product.

Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.

Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.

30

Assessing Project Risk-IAssessing Project Risk-I Have top software and customer managers formally

committed to support the project? Are end-users enthusiastically committed to the

project and the system/product to be built? Are requirements fully understood by the software

engineering team and their customers? Have customers been involved fully in the definition

of requirements? Do end-users have realistic expectations?

Have top software and customer managers formally committed to support the project?

Are end-users enthusiastically committed to the project and the system/product to be built?

Are requirements fully understood by the software engineering team and their customers?

Have customers been involved fully in the definition of requirements?

Do end-users have realistic expectations?

31

Assessing Project Risk-IIAssessing Project Risk-II Is project scope stable? Does the software engineering team have the right mix of skills? Are project requirements stable? Does the project team have experience with the technology to

be implemented? Is the number of people on the project team adequate to do the

job? Do all customer/user constituencies agree on the importance of

the project and on the requirements for the system/product to be built?

Is project scope stable? Does the software engineering team have the right mix of skills? Are project requirements stable? Does the project team have experience with the technology to

be implemented? Is the number of people on the project team adequate to do the

job? Do all customer/user constituencies agree on the importance of

the project and on the requirements for the system/product to be built?

32

Risk ComponentsRisk Components performance risk—the degree of uncertainty that the

product will meet its requirements and be fit for its intended use.

cost risk—the degree of uncertainty that the project budget will be maintained.

support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.

schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.

cost risk—the degree of uncertainty that the project budget will be maintained.

support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.

schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

33

Risk ProjectionRisk Projection Risk projection, also called risk estimation, attempts to rate each risk

in two ways the likelihood or probability that the risk is real the consequences of the problems associated with the risk,

should it occur. The are four risk projection steps:

establish a scale that reflects the perceived likelihood of a risk delineate the consequences of the risk estimate the impact of the risk on the project and the product, note the overall accuracy of the risk projection so that there will

be no misunderstandings.

Risk projection, also called risk estimation, attempts to rate each risk in two ways the likelihood or probability that the risk is real the consequences of the problems associated with the risk,

should it occur. The are four risk projection steps:

establish a scale that reflects the perceived likelihood of a risk delineate the consequences of the risk estimate the impact of the risk on the project and the product, note the overall accuracy of the risk projection so that there will

be no misunderstandings.

34

Building a Risk Table

RiskRisk ProbabilityProbability ImpactImpact RMMMRMMM

RiskRiskMitigationMitigationMonitoringMonitoring

& & ManagementManagement

35

Building the Risk TableBuilding the Risk Table

Estimate the probability of occurrence Estimate the impact on the project on a

scale of 1 to 5, where 1 = low impact on project success 5 = catastrophic impact on project success

sort the table by probability and impact

Estimate the probability of occurrence Estimate the impact on the project on a

scale of 1 to 5, where 1 = low impact on project success 5 = catastrophic impact on project success

sort the table by probability and impact

36

Risk Exposure (Impact)Risk Exposure (Impact)

The overall risk exposure, RE, is determined using the following relationship [HAL98]:

RE = P x C

where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.

37

Risk Exposure ExampleRisk Exposure Example Risk identification. Only 70 percent of the software components

scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed.

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

70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software 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.

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

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

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

70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software 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.

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

38

Risk Mitigation, Monitoring,and Management

Risk Mitigation, Monitoring,and Management mitigation—how can we avoid the risk? monitoring—what factors can we track

that will enable us to determine if the risk is becoming more or less likely?

management—what contingency plans do we have if the risk becomes a reality?

mitigation—how can we avoid the risk? monitoring—what factors can we track

that will enable us to determine if the risk is becoming more or less likely?

management—what contingency plans do we have if the risk becomes a reality?

39

Risk Due to Product Size

• • estimated size of the product in LOC or FP?estimated size of the product in LOC or FP?

• • estimated size of product in number of programs, estimated size of product in number of programs, files, transactions?files, transactions?

• • percentage deviation in size of product from percentage deviation in size of product from average for previous products?average for previous products?

• • size of database created or used by the product?size of database created or used by the product?

• • number of users of the product?number of users of the product?

• • number of projected changes to the requirements number of projected changes to the requirements for the product? before delivery? after delivery?for the product? before delivery? after delivery?

• • amount of reused software?amount of reused software?

Attributes that affect risk:Attributes that affect risk:

40

Risk Due to Business Impact

• • affect of this product on company revenue?affect of this product on company revenue?• • visibility of this product by senior management?visibility of this product by senior management?• • reasonableness of delivery deadline?reasonableness of delivery deadline?

• • number of customers who will use this product number of customers who will use this product

• • interoperability constraintsinteroperability constraints

• • sophistication of end users?sophistication of end users?

• • amount and quality of product documentation that amount and quality of product documentation that must be produced and delivered to the customer?must be produced and delivered to the customer?

• • governmental constraintsgovernmental constraints

• • costs associated with late delivery?costs associated with late delivery?

• • costs associated with a defective product?costs associated with a defective product?

Attributes that affect risk:Attributes that affect risk:

41

Risks Due to the Customer

• • Have you worked with the customer in the past?Have you worked with the customer in the past?

• • Does the customer have a solid idea of requirements?Does the customer have a solid idea of requirements?

• • Has the customer agreed to spend time with you? Has the customer agreed to spend time with you?

• • Is the customer willing to participate in reviews?Is the customer willing to participate in reviews?

• • Is the customer technically sophisticated?Is the customer technically sophisticated?

• • Is the customer willing to let your people do their Is the customer willing to let your people do their job—that is, will the customer resist looking over your job—that is, will the customer resist looking over your shoulder during technically detailed work?shoulder during technically detailed work?

• • Does the customer understand the software Does the customer understand the software engineering process?engineering process?

Questions that must be answered:Questions that must be answered:

42

Risks Due to Process Maturity

• • Have you established a common process framework? Have you established a common process framework? • • Is it followed by project teams?Is it followed by project teams?• • Do you have management support for Do you have management support for software engineering software engineering • • Do you have a proactive approach to SQA? Do you have a proactive approach to SQA? • • Do you conduct formal technical reviews?Do you conduct formal technical reviews?

• • Are CASE tools used for analysis, design and Are CASE tools used for analysis, design and testing?testing?

• • Are the tools integrated with one another?Are the tools integrated with one another?

• • Have document formats been established?Have document formats been established?

Questions that must be answered:Questions that must be answered:

43

Technology Risks

• • Is the technology new to your organization?Is the technology new to your organization?• • Are new algorithms, I/O technology required?Are new algorithms, I/O technology required? • • Is new or unproven hardware involved?Is new or unproven hardware involved?

• • Does the application interface with new software?Does the application interface with new software?• • Is a specialized user interface required? Is a specialized user interface required? • • Is the application radically different?Is the application radically different?• • Are you using new software engineering methods?Are you using new software engineering methods?

• • Are you using unconventional software development Are you using unconventional software development methods, such as formal methods, AI-based approaches, methods, such as formal methods, AI-based approaches, artificial neural networks?artificial neural networks?

• • Are there significant performance constraints?Are there significant performance constraints?

• • Is there doubt the functionality requested is "do-able?"Is there doubt the functionality requested is "do-able?"

Questions that must be answered:Questions that must be answered:

44

Staff/People Risks

• • Are the best people available?Are the best people available?• • Does staff have the right skills?Does staff have the right skills?• • Are enough people available?Are enough people available?• • Are staff committed for entire duration?Are staff committed for entire duration?• • Will some people work part time? Will some people work part time? • • Do staff have the right expectations?Do staff have the right expectations?• • Have staff received necessary training?Have staff received necessary training?• • Will turnover among staff be low?Will turnover among staff be low?

Questions that must be answered:Questions that must be answered:

45

Project: Embedded software for XYZ systemProject: Embedded software for XYZ systemRisk type: schedule riskRisk type: schedule riskPriority (1 low ... 5 critical): 4Priority (1 low ... 5 critical): 4Risk factor: Project completion will depend on tests which require Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component hardware component under development. Hardware component delivery may be delayeddelivery may be delayedProbability: 60 %Probability: 60 %Impact: Project completion will be delayed for each day that Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testinghardware is unavailable for use in software testingMonitoring approach: Monitoring approach: Scheduled milestone reviews with hardware groupScheduled milestone reviews with hardware groupContingency plan:Contingency plan: Modification of testing strategy to accommodate delay usingModification of testing strategy to accommodate delay using software simulationsoftware simulationEstimated resources: 6 additional person months beginning 7-1-96Estimated resources: 6 additional person months beginning 7-1-96

Recording Risk Information