CS615 –
Software Engineering I |
Lecture 8 |
Risk always involves two characteristics:
Must quantify:
Kinds of Risks:
Project risks threaten the project plan.
Identify potential budgetary, schedule, personnel (staffing and organization), resource, customer, and requirements problems and their impact on a software project
Technical risks threaten the quality and timeliness of the software to be produced
Business risks threaten the viability of the software to be built.
Top five business risks :
(1) building an excellent product or system that no one really wants (market risk)
(2)
building a product that no longer fits into the overall
business strategy for the company (strategic risk)
(3)
building a product that the sales force doesn't understand how
to sell
(4)
losing the support of senior management due to a change in
focus or a change in people (management risk)
(5) losing budgetary or personnel commitment (budget risks).
Known risks - uncovered after evaluation:
Predictable risks - extrapolated from past project experience
e.g.,
· staff turnover
· poor communication with the customer
· dilution of staff effort as ongoing maintenance requests are serviced
Unpredictable risks - occur, but difficult to identify in advance.
· Attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.)
· Two types of risks:
o Generic risks - potential threat to every software project.
o Product-specific risks - identified by: those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand.
§ Identify by looking at the project plan and the software statement of scope
§ Ask question - "What special characteristics of this product may threaten our project plan?"
1.
Have top software and customer managers formally
committed to support the project?
2. Are end-users enthusiastically committed to the project and the system/product to be built?
3. Are requirements fully understood by the software engineering team and their customers?
4. Have customers been involved fully in the definition of requirements?
5. Do end-users have realistic expectations?
6. Is project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the technology to be implemented?
10. Is the number of people on the project team adequate to do the job?
11. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?
Sample Risk Checklist (Long)
· U.S. Air Force pamphlet contains guidelines for software risk identification and abatement.
· Air Force approach requires that the project manager identify the risk drivers that affect software risk components—performance, cost, support, and schedule.
· Risk components:
(1) Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
(2) Cost risk—the degree of uncertainty that the project budget will be maintained.
(3) Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
(4) Schedule risk—the
degree of uncertainty that the project schedule will be maintained and that the
product will be delivered on time.
· Impact of each risk driver on the risk component is divided into one of four impact categories—negligible, marginal, critical, or catastrophic
Attempts to rate each risk in two ways
· The probability that the risk is real
· The consequences of the problems associated with the risk, should it occur.
Project planner, along with other managers and technical staff, performs four risk projection activities:
(1) establish a measure that reflects the perceived likelihood of a risk
(2) delineate the consequences of the risk
(3) estimate the impact of the risk on the project and the product
(4) note the overall accuracy of the risk projection so that there will be no misunderstandings.
Risk table provides a project manager with a simple technique for risk projection
(1) Project team begins by listing all risks in the first column of the table.
Accomplished with the help of the risk item checklists.
(2) Each risk is categorized in the second column
(e.g., PS implies a project size risk, BU implies a business risk).
(3) The probability of occurrence of each risk is entered in the next column of the table.
The probability value for each risk can be estimated by team members individually.
(4) Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge.
(1) Each risk component is assessed using the Risk Charcterization Table (Figure 1) and impact category is determined.
(2) Categories for each of the four risk components—performance, support, cost, and schedule—are averaged to determine an overall impact value.
1. A risk that is 100 percent probable is a constraint on
the software project.
2.
The risk table should be
implemented as a spreadsheet model. This enables easy manipulation and sorting
of the entries.
3.
A weighted average can
be used if one risk component has more significance for the project.
(3) Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact.
· High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom.
(4) Project manager studies the resultant sorted table and defines a cutoff line.
· cutoff line (drawn horizontally at some point in the table) implies that only risks that lie above the line will be given further attention.
· Risks below the line are re-evaluated to accomplish second-order prioritization.
· Risk impact and probability have a distinct influence on management concern.
o Risk factor with a high impact but a very low probability of occurrence should not absorb a significant amount of management time.
o High-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow.
· All risks that lie above the cutoff line must be managed.
· The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan
· Three factors determine the consequences if a risk occurs:
o Nature of the risk - the problems that are likely if it occurs.
o e.g., a poorly defined external interface to customer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project.
o Scope of a risk - combines the severity with its overall distribution (how much of the project will be affected or how many customers are harmed?).
o Timing of a risk - when and how long the impact will be felt.
· Steps recommended to determine the overall consequences of a risk:
Overall risk exposure, RE,
determined using:
RE = P x C
P is the probability of occurrence for a risk
C is the the cost to the project should the risk occur.
Example
Assume the software team defines a project risk in the
following manner:
Risk identification.
· Only 70 percent of the software components scheduled for reuse will 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.
· Have established a set of triplets of the form:
[ri,
li, xi]
where
ri is risk
li is the likelihood (probability) of the risk
xi is the impact of the risk.
· During
risk assessment :
o
further examine the accuracy of the estimates that were
made during risk projection
o
attempt to rank the risks that have been uncovered
o begin thinking about ways to control and/or avert risks that are likely to occur.
· Must Define a risk referent level
o performance, cost, support, and schedule represent risk referent levels.
o There is a level for performance degradation, cost overrun, support difficulty, or schedule slippage (or any combination of the four) that will cause the project to be terminated.
o A risk referent level has a single point, called the referent point or break point, at which the decision to proceed with the project or terminate it are equally weighted.
· Referent level rarely represented as a smooth line on a graph.
· Most cases - a region in which there are areas of uncertainty
· Therefore, during risk assessment, perform the following steps:
1. Define the risk referent levels for the project.
2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.
3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.
4. Try to predict how compound combinations of risks will affect a referent level.
· A risk may be stated generally during early stages of project planning.
· With time, more is learned about the project and the risk
o may
be possible to refine the risk into a set of more detailed risks
· Represent
risk in condition-transition-consequence (CTC) format.
o
Stated in the following form:
· Using
CTC format for the reuse we can write:
Given that all reusable software components must conform to specific design standards and that some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components.
· This
general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target environment.
Effective strategy must consider three issues:
· Proactive approach to risk - avoidance strategy.
·
Develop risk mitigation plan.
·
e.g. assume high staff turnover is noted as a
project risk, r1.
·
Based on past history
o the
likelihood, l1, of high turnover is estimated
to be 0.70
o the
impact, x1, is projected at level 2.
o So…
high turnover will have a critical impact on project cost and schedule.
· Develop a strategy to mitigate this risk for reducing turnover.
·
Possible steps to be taken
· Project manager monitors for likelihood of risk
·
For high staff turnover, the following factors can be
monitored:
· Project manager should monitor the effectiveness of risk mitigation steps.
· Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.
e.g., the project is underway and a number of people
announce that they will be leaving.
·
Mitigation strategy makes sure:
§ backup is available
§ information
is documented
§ knowledge
has been dispersed across the team.
· RMMM steps incur additional project cost
e.g. spending time to "backup" every critical technologist costs money.
· Large project - 30 or 40 risks.
· 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be accounted for by only 20 percent of the identified risks.
· Work performed during earlier risk analysis steps will help the planner to determine which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure).
· Risk Mitigation, Monitoring and Management Plan (RMMM) - documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.
· Alternative to RMMM - risk information sheet (RIS)
RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily.
Causes of Software Lateness:
· Software project scheduling - activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.
· Schedule evolves over time.
o Early
stages of planning - macroscopic schedule - identifies all
major software engineering activities and the product functions to which they
are applied.
o Project
under way - detailed schedule - each entry on the
macroscopic schedule is refined. Here, s
§
specific software tasks are identified and
scheduled.
· Two Points of view for Scheduling
·
Principles guiding software project scheduling:
o
Compartmentalization. The project must be
compartmentalized into a number of manageable activities and tasks.
o
Interdependency. The interdependency of
each compartmentalized activity or task must be determined. Some tasks must
occur in sequence while others can occur in parallel.
o
Time allocation.
§ Each
task to be scheduled allocated some number of work units
§ Each
task assigned a start date and a completion date that are a function of the
interdependencies and whether work will be conducted on a full-time or
part-time basis.
o
Effort validation.
§ Every
project has a defined number of staff members.
§ As
time allocation occurs, the project manager ensures that no more than the
allocated number of people has been scheduled at any given time.
o
Defined responsibilities. Every task that
is scheduled should be assigned to a specific team member.
o
Defined outcomes. Every task that is
scheduled should have a defined outcome. For software projects, the outcome is
normally a work product or a part of a work product.
o
Defined milestones. Every task or group of
tasks should be associated with a project milestone. A milestone is
accomplished when one or more work products has been reviewed for quality and
has been approved.
· Small software development project - single person can analyze requirements, perform design, generate code, and conduct tests.
·
Larger software development project - more people must
become involved.
· Highly nonlinear relationship between chronological time to complete a project and human effort applied to the project.
·
The number of delivered lines of code (source
statements), L, is related to effort and development time
by the equation:
L = P x E 1/3 t 4/3
where
E is development effort in person-months
P is a productivity parameter that reflects a variety of factors that lead to high-quality software engineering work (typical values for P range between 2,000 and 12,000)
t is the
project duration in calendar months.
· Rearranging
this software equation gives an expression for development effort E:
E = L3/(P3t4)
where
E is the effort expended (in person-years) over the entire life cycle for software development and maintenance
t is the development time in years.
Example:
· Real-time software project:
o 33,000 LOC
o 12 person-years of effort.
· If eight people are assigned to the project team, the project can be completed in approximately 1.3 years.
·
Extend the end-date to 1.75 years:
E = L3/( P3t4)
~ 3.8 person-years.
· Extending the end-date six months reduces the number of people from eight to four!
·
40–20–40 rule - Recommended distribution
of effort across the definition and development phases.
o Forty
percent of all effort is allocated to front-end analysis and design.
o Forty
percent is applied to back-end testing.
o Twenty
percent is applied to coding.
· Task set - collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project.
· Task sets are designed to accommodate different types of projects and different degrees of rigor.
·
Most software organizations encounter the following
projects:
·
Degree of rigor is a function of
many project characteristics.
Four different degrees of rigor can be defined:
· Project manager must develop a systematic approach for selecting the degree of rigor that is appropriate for a particular project.
· To accomplish this, project adaptation criteria are defined and a task set selector value is computed
· Adaptation criteria are used to determine the recommended degree of rigor with which the software process should be applied on a project.
Eleven adaptation criteria are defined
for software projects:
· Each adaptation criterion is assigned a grade that ranges between 1 and 5
·
To select the appropriate task set for a project, the
following steps should be conducted:
o
Enter grade into table.
o
Value of a weighting factor ranges from 0.8 to 1.2 and
provides an indication of the relative importance of a particular adaptation
criterion to the types of software developed within the local environment.
o
Entry point multiplier takes on a value of 0 or 1
and indicates the relevance of the adaptation criterion to the project type.
o
Result of the product
grade x weighting factor x entry point multiplier
o
Placed in the Product column of table for each
adaptation criteria individually.
· This
value will be used to help select the task set that is most appropriate for the
project.
·
Interpreting the TSS Value and Selecting the Task
Set
· Once
the task set selector is computed, the following guidelines can be used to
select the appropriate task set for a project:
Task set selector value |
Degree of rigor |
TSS < 1.2 |
casual |
1.0 < TSS < 3.0 |
structured |
TSS > 2.4 |
strict |
· Overlap in TSS values from one recommended task set to another is intended to illustrate that sharp boundaries are impossible to define when making task set selections.
·
The task set selector value, past experience, and
common sense must all be factored into the choice of the task set for a
project.
· Table illustrates how TSS might be computed for a hypothetical project.
o Project manager selects the grades shown in the Grade column.
o Project type is new application development.
o Therefore, entry point multipliers are selected from the NDev column. T
o
he entry in the Product column is computed using
Grade x Weight x NewDev entry point
multiplier
· Value of TSS (computed as the average of all entries in the product column) is 2.8.
· The
manager has the option of using either the structured or the strict task set.
·
Development projects are approached by applying the
following major tasks:
1.
Concept scoping determines the overall scope of the
project.
2.
Preliminary concept planning establishes the
organization's ability to undertake the work implied by the project scope.
3.
Technology risk assessment evaluates the risk
associated with the technology to be implemented as part of project scope.
4.
Proof of concept demonstrates the viability of a
new technology in the software context.
5.
Concept implementation implements the concept
representation in a manner that can be reviewed by a customer and is used for
"marketing" purposes when a concept must be sold to other customers
or management.
6.
Customer reaction to the concept solicits feedback
on a new technology concept and targets specific customer applications.
· Development
framework activities are iterative in nature.
· Actual
development project might approach these activities in a number of planned
increments, each designed to produce a deliverable that can be evaluated by the
customer.
· Model
Selection:
o Linear process model
o
Evolutionary model
· Major tasks may be used to define a macroscopic schedule for a project.
· Macroscopic schedule must be refined to create a detailed project schedule.
·
Refinement begins by taking each major task and
decomposing it into a set of subtasks (with related work products and
milestones).
Example of task decomposition - concept scoping for a development project:
· Individual tasks and subtasks have interdependencies based on their sequence.
· It is likely that development activities and tasks will be performed in parallel.
·
Concurrent tasks must be coordinated so that they will
be complete when later tasks require their work product(s).
·
Task network ( activity network )
is a graphic representation of the task flow for a project.
o The
task network depicts major software engineering tasks.
·
Parallel tasks occur asynchronously
o Planner
must determine intertask dependencies to ensure continuous progress toward
completion.
o
Project manager should be aware of those tasks
that must be completed on schedule if the project as a whole is to be completed
on schedule.
·
Generalized project scheduling tools and techniques can
be applied with little modification to software projects.
·
Program evaluation and review technique (PERT)
and critical path method (CPM) are two project scheduling methods that
can be applied to software development.
·
Both techniques are driven by information already
developed in earlier project planning activities:
o
Estimates of effort
o
A decomposition of the product function
o
The selection of the appropriate process model and task
set
o
Decomposition of tasks
· Interdependencies among tasks may be defined using a task network.
· Tasks
(work breakdown structure (WBS)) are defined for the product as a whole
or for individual functions.
· PERT and CPM provide quantitative tools that allow the software planner to
· Important boundary times discerned from a PERT or CPM network:
1. the earliest time that a task can begin when all preceding tasks are completed in the shortest possible time
2. the latest time for task initiation before the minimum project completion time is delayed
3. the earliest finish—the sum of the earliest start and the task duration
4. the latest finish—the latest start time added to task duration
5. the total float—the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path is maintained on schedule.
· Boundary
time calculations lead to a determination of critical path and provide the
manager with a quantitative method for evaluating progress as tasks are
completed.
· PERT and CPM implemented in a variety of automated tools that are available for the personal computer
· Such tools are easy to use and make the scheduling methods described previously available to every software project manager
· Software project schedule - planner begins with a set of tasks
· Effort, duration, and start date are input for each task.
·
Tasks may be assigned to specific individuals.
·
Timeline chart, ( Gantt chart) generated.:
· The project schedule provides a road map for a software project manager.
· Project schedule defines the tasks and milestones that must be tracked and controlled as the project proceeds.
·
Tracking can be accomplished in a number of different
ways:
o
Conducting periodic project status meetings in which
each team member reports progress and problems.
o
Evaluating the results of all reviews conducted
throughout the software engineering process.
o
Determining whether formal project milestones have been
accomplished by the scheduled date.
o
Comparing actual start-date to planned start-date for
each project task listed in the resource table
o Meeting
informally with practitioners to obtain their subjective assessment of progress
to date and problems on the horizon.
· Time-boxing strategy recognizes that the complete product may not be deliverable by the predefined deadline.
o An
incremental software paradigm is chosen and a schedule is derived for each
incremental delivery.
o Tasks associated with each increment are time-boxed.
o The schedule for each task is adjusted by working backward from the delivery date for the increment.
o A "box" is put around each task.
o When
a task hits the boundary of its time box (plus or minus 10 percent), work stops
and the next task begins.
· Earned value analysis (EVA) - qualitative approaches to project tracking
o Provides a common value scale for every software project task, regardless of the type of work being performed.
o The
total hours to do the whole project are estimated, and every task is given an earned
value based on its estimated percentage of the total.
· Earned value is a measure of progress
o
Able to assess the "percent of completeness"
of a project using quantitative analysis
Following steps performed:
1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule.
1. The work (in person-hours or person-days) of each software engineering task is planned.
2. BCWSi is the effort planned for work task i.
3.
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.
2.
The BCWS values for all work tasks are summed to derive the
budget at completion, BAC. Hence,
BAC = S (BCWSk) for all tasks k
3. Next, the value for budgeted cost of work performed (BCWP) is computed.
1. 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 BCWS and 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.
· Given
values for BCWS, BAC, and BCWP, 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.
o An SPI value close to 1.0 indicates efficient execution of the project schedule.
· SV
is an absolute indication of variance from the planned schedule.
· Percent scheduled for completion = BCWS/BAC
o
provides an indication of the percentage of work that
should have been completed by time t.
· Percent complete = BCWP/BAC
o 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 - the sum of
the effort expended on work tasks that have been completed by a point in time
on the project schedule.
o It
is then possible to compute
Cost performance index, CPI =
BCWP/ACWP
Cost variance, CV = BCWP -
ACWP
o
CPI close to 1.0 provides a strong indication that the
project is within its defined budget.
o
CV is an absolute indication of cost savings
(against planned costs) or shortfall at a particular stage of a project.
· Throughout the software process, a project team errors associated with each work product.
· Error-related measures and resultant metrics are collected over many software projects, can be used as a baseline for comparison against error data collected in real time.
·
Error tracking can be used as one means for assessing
the status of a current project.
· Software team performs formal technical reviews (and, later, testing) to find and correct errors, E, in work products produced during software engineering tasks.
·
Any errors that are not uncovered (but found in later
tasks) are defects, D.
·
Defect removal efficiency is defined as
DRE = E/(E + D)
· DRE
is a process metric that provides a strong indication of the effectiveness of
quality assurance activities
· DRE
can also be used to assist a project manager in determining the progress that
is being made as a software project moves through its scheduled work tasks.
o
e.g. a software organization has collected error
and defect data over the past 24 months and has developed averages for the
following metrics:
§ Errors
per requirements specification page, Ereq
§ Errors
per component—design level, Edesign
§ Errors
per component—code level, Ecode
§ DRE—requirements
analysis
§ DRE—architectural
design
§ DRE—component
level design
§ DRE—coding
· As the project progresses through each software engineering step, the software team records and reports the number of errors found during requirements, design, and code reviews.
· The project manager calculates current values for Ereq, Edesign, and Ecode.
· Compared to averages for past projects.
· If
current results vary by more than 20% from the average, there may be cause for
concern and there is certainly cause for investigation.
· For example, if Ereq = 2.1 for project X, yet the organizational average is 3.6, one of two scenarios is possible:
· Each step in the software engineering process should produce a deliverable that can be reviewed and that can act as a foundation for the steps that follow.
· The Software Project Plan is produced at the culmination of the planning tasks.
·
It provides baseline cost and scheduling information
that will be used throughout the software process.
· The Software Project Plan must
1. communicate scope and resources to software management, technical staff, and the customer
2. define risks and suggest risk aversion techniques
3. define cost and schedule for management review
4. provide an overall approach to software development for all people associated with the project
5.
outline how quality will be ensured and change will be
managed.