Micro-Scholarship, What it is, How can it help me.pdf
Chapter1 Advanced Software Engineering overview
1. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1
Chapter 1
overview Software Engineering
2. 2
What is Software?
Software is: (1) instructions (computer programs) that when
executed provide desired features, function, and
performance; (2) data structures that enable the programs to
adequately manipulate information and (3) documentation
that describes the operation and use of the programs.
Software is developed or engineered, it is not
manufactured in the classical sense.
Software doesn't "wear out."
Although the industry is moving toward component-based
construction, most software continues to be custom-built.
The IEEE definition:
Software Engineering: (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance
of software; that is, the application of engineering to software. (2) The
study of approaches as in (1).
6. 6
The Essence of Practice
Polya suggests:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality
assurance).
7. 7
Hooker’s General Principles
1: The Reason It All Exists
2: KISS (Keep It Simple, Stupid!)
3: Maintain the Vision
4: What You Produce, Others Will Consume
5: Be Open to the Future
6: Plan Ahead for Reuse
7: Think!
8. 8
How It all Starts
SafeHome:
Every software project is precipitated by some
business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a
changing business environment;
• the need to extend the functions and features of an
existing application, or
• the need to create a new product, service, or system.
9. 9
The Four P’s
People — the most important element of a
successful project
Product — the software to be built
Process — the set of framework activities and
software engineering tasks to get the job done
Project — all work required to make the
product a reality
Project Management Concepts
10. 10
Stakeholders
Senior managers who define the business issues that
often have significant influence on the project.
Project (technical) managers who must plan, motivate,
organize, and control the practitioners who do software
work.
Practitioners who deliver the technical skills that are
necessary to engineer a product or application.
Customers who specify the requirements for the software
to be engineered and other stakeholders who have a
peripheral interest in the outcome.
End-users who interact with the software once it is
released for production use.
11. 11
Team Leader
The MOI Model
Motivation. The ability to encourage (by “push or
pull”) technical people to produce to their best ability.
Organization. The ability to mold existing processes
(or invent new ones) that will enable the initial
concept to be translated into a final product.
Ideas or innovation. The ability to encourage
people to create and feel creative even when they
must work within bounds established for a particular
software product or application.
12. 12
Software Teams
the difficulty of the problem to be solved
the size of the resultant program(s) in lines of code or
function points
the time that the team will stay together (team lifetime)
the degree to which the problem can be modularized
the required quality and reliability of the system to be
built
the rigidity of the delivery date
the degree of sociability (communication) required for
the project
The following factors must be considered when
selecting a software project team structure ...
13. 13
closed paradigm—structures a team along a traditional
hierarchy of authority
random paradigm—structures a team loosely and depends
on individual initiative of the team members
open paradigm—attempts to structure a team in a manner
that achieves some of the controls associated with the
closed paradigm but also much of the innovation that
occurs when using the random paradigm
synchronous paradigm—relies on the natural
compartmentalization of a problem and organizes team
members to work on pieces of the problem with little active
communication among themselves
Organizational Paradigms
suggested by Constantine [Con93]
14. 14
Avoid Team “Toxicity”
A frenzied work atmosphere in which team members
waste energy and lose focus on the objectives of the work
to be performed.
High frustration caused by personal, business, or
technological factors that cause friction among team
members.
“Fragmented or poorly coordinated procedures” or a poorly
defined or improperly chosen process model that becomes
a roadblock to accomplishment.
Unclear definition of roles resulting in a lack of
accountability and resultant finger-pointing.
“Continuous and repeated exposure to failure” that leads
to a loss of confidence and a lowering of morale.
15. 15
Agile Teams
Team members must have trust in one another.
The distribution of skills must be appropriate to the
problem.
Mavericks may have to be excluded from the team, if
team cohesiveness is to be maintained.
Team is “self-organizing”
An adaptive team structure
Uses elements of Constantine’s random, open, and
synchronous paradigms
Significant autonomy
16. 16
Problem Decomposition
Sometimes called partitioning or problem
elaboration
Once scope is defined …
It is decomposed into constituent functions
It is decomposed into user-visible data objects
or
It is decomposed into a set of problem classes
Decomposition process continues until all
functions or problem classes have been
defined
17. 17
The Process
Once a process framework has been
established
Consider project characteristics
Determine the degree of rigor required
Define a task set for each software engineering
activity
• Task set =
• Software engineering tasks
• Work products
• Quality assurance points
• Milestones
18. 18
The Project
Projects get into trouble when …
Software people don’t understand their customer’s needs.
The product scope is poorly defined.
Changes are managed poorly.
The chosen technology changes.
Business needs change [or are ill-defined].
Deadlines are unrealistic.
Users are resistant.
Sponsorship is lost [or was never properly obtained].
The project team lacks people with appropriate skills.
Managers [and practitioners] avoid best practices and
lessons learned.
19. 19
Common-Sense Approach to Projects
Start on the right foot. This is accomplished by working hard
(very hard) to understand the problem that is to be solved and
then setting realistic objectives and expectations.
Maintain momentum. The project manager must provide
incentives to keep turnover of personnel to an absolute
minimum, the team should emphasize quality in every task it
performs, and senior management should do everything
possible to stay out of the team’s way.
Track progress. For a software project, progress is tracked as
work products (e.g., models, source code, sets of test cases)
are produced and approved (using formal technical reviews) as
part of a quality assurance activity.
Make smart decisions. In essence, the decisions of the
project manager and the software team should be to “keep it
simple.”
Conduct a postmortem analysis. Establish a consistent
mechanism for extracting lessons learned for each project.
20. 20
To Get to the Essence of a Project
Why is the system being developed?
What will be done?
When will it be accomplished?
Who is responsible?
Where are they organizationally located?
How will the job be done technically and
managerially?
How much of each resource (e.g., people,
software, tools, database) will be needed?
Barry Boehm [Boe96]
21. 21
Critical Practices
Formal risk management
Empirical cost and schedule estimation
Metrics-based project management
Earned value tracking
Defect tracking against quality targets
People aware project management
22. 22
A Good Manager Measures
process
measurement
What do we
use as a
basis?
• size?
• function?
project metrics
process metrics
product
product metrics
Process and Project Metrics
23. 23
Why Do We Measure?
assess the status of an ongoing project
track potential risks
uncover problem areas before they go
“critical,”
adjust work flow or tasks,
evaluate the project team’s ability to
control quality of software work products.
24. 24
Process Measurement
We measure the efficacy of a software process
indirectly.
That is, we derive a set of metrics based on the
outcomes that can be derived from the process.
Outcomes include
• measures of errors uncovered before release of the
software
• defects delivered to and reported by end-users
• work products delivered (productivity)
• human effort expended
• calendar time expended
• schedule conformance
• other measures.
We also derive process metrics by measuring the
characteristics of specific software engineering tasks.
25. 25
Process Metrics Guidelines
Use common sense and organizational sensitivity when
interpreting metrics data.
Provide regular feedback to the individuals and teams who
collect measures and metrics.
Don’t use metrics to appraise individuals.
Work with practitioners and teams to set clear goals and
metrics that will be used to achieve them.
Never use metrics to threaten individuals or teams.
Metrics data that indicate a problem area should not be
considered “negative.” These data are merely an indicator for
process improvement.
Don’t obsess on a single metric to the exclusion of other
important metrics.
27. 27
Process Metrics
Quality-related
focus on quality of work products and deliverables
Productivity-related
Production of work-products related to effort expended
Statistical SQA data
error categorization & analysis
Defect removal efficiency
propagation of errors from process activity to activity
Reuse data
The number of components produced and their degree
of reusability
28. 28
Project Metrics
used to minimize the development schedule by making the
adjustments necessary to avoid delays and mitigate
potential problems and risks
used to assess product quality on an ongoing basis and,
when necessary, modify the technical approach to improve
quality.
every project should measure:
inputs—measures of the resources (e.g., people, tools)
required to do the work.
outputs—measures of the deliverables or work products
created during the software engineering process.
results—measures that indicate the effectiveness of the
deliverables.
29. 29
Typical Project Metrics
Effort/time per software engineering task
Errors uncovered per review hour
Scheduled vs. actual milestone dates
Changes (number) and their
characteristics
Distribution of effort on software
engineering tasks
30. 30
Software Project Planning
The overall goal of project planning is to
establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical
project.
Why?
So the end result gets done on time, with
quality!
Estimation for Software Projects
31. 31
Project Planning Task Set-I
Establish project scope
Determine feasibility
Analyze risks
Risk analysis is considered in detail in Chapter 25.
Define required resources
Determine require human resources
Define reusable software resources
Identify environmental resources
32. 32
Project Planning Task Set-II
Estimate cost and effort
Decompose the problem
Develop two or more estimates using size, function
points, process tasks or use-cases
Reconcile the estimates
Develop a project schedule
Scheduling is considered in detail in Chapter 27.
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
33. 33
Estimation
Estimation of resources, cost, and schedule for
a software engineering effort requires
experience
access to good historical information (metrics)
the courage to commit to quantitative predictions
when qualitative information is all that exists
Estimation carries inherent risk and this risk
leads to uncertainty
35. 35
Project Estimation
Project scope must be
understood
Elaboration (decomposition) is
necessary
Historical metrics are very helpful
At least two different techniques
should be used
Uncertainty is inherent in the
process
39. 39
Example: LOC Approach
Average productivity for systems of this type = 620 LOC/pm.
Burdened labor rate =$8000 per month, the cost per line of
code is approximately $13.
Based on the LOC estimate and the historical productivity
data, the total estimated project cost is $431,000 and the
estimated effort is 54 person-months.
40. 40
Example: FP Approach
The estimated number of FP is derived:
FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.
41. 41
Process-Based Estimation
Obtained from “process framework”
application
functions
framework activities
Effort required to
accomplish
each framework
activity for each
application function
42. 42
Process-Based Estimation Example
Activity
Task
Function
UICF
2DGA
3DGA
DSM
PCF
CGDF
DAM
Totals
% effort
CC Planning
Risk
Analysis Engineering
Construction
Release TotalsCE
analysis design code test
0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00
1% 1% 1% 8% 45% 10% 36%
CC = customer communication CE = customer evaluation
0.50
0.75
0.50
0.50
0.50
0.25
2.50
4.00
4.00
3.00
3.00
2.00
0.40
0.60
1.00
1.00
0.75
0.50
5.00
2.00
3.00
1.50
1.50
1.50
8.40
7.35
8.50
6.00
5.75
4.25
0.50 2.00 0.50 2.00 5.00
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Based on an average burdened labor rate of $8,000 per
month, the total estimated project cost is $368,000 and
the estimated effort is 46 person-months.
44. 44
Estimation with Use-Cases
use cases scenarios pages Êscenarios pages LOC LOC estimate
e subsystem 6 10 6 Ê 12 5 560 3,366
subsystem group 10 20 8 Ê 16 8 3100 31,233
e subsystem group 5 6 5 Ê 10 6 1650 7,970
Ê Ê Ê Ê
stimate Ê Ê Ê Ê 42,568
User interface subsystem
Engineering subsystem group
Infrastructure subsystem group
TotalLOC estimate
Using 620 LOC/pm as the average productivity for systems of
this type and a burdened labor rate of $8000 per month, the
cost per line of code is approximately $13. Based on the use-
case estimate and the historical productivity data, the total
estimated project cost is $552,000 and the estimated
effort is 68 person-months.
45. 45
Empirical Estimation Models
General form:
effort = tuning coefficient * size
exponent
usually derived
as person-months
of effort required
either a constant or
a number derived based
on complexity of project
usually LOC but
may also be
function point
empirically
derived
46. 46
COCOMO-II
COCOMO II is actually a hierarchy of
estimation models that address the following
areas:
• Application composition model. Used during the early
stages of software engineering, when prototyping of
user interfaces, consideration of software and system
interaction, assessment of performance, and
evaluation of technology maturity are paramount.
• Early design stage model. Used once requirements
have been stabilized and basic software architecture
has been established.
• Post-architecture-stage model. Used during the
construction of the software.
47. 47
The Software Equation
A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”
49. 49
Computing Expected Cost
(path probability) x (estimated path cost)
i i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) + 0.70 ($450K)
similarly,
expected cost = $382K
expected cost = $267K
expected cost = $410K
build
reuse
buy
contr
expected cost =
= $429 K
50. 50
What is Risk?
Risks are potential problems that may
affect successful completion of a
software project.
Risks involve uncertainty and potential
losses.
Risk analysis and management are
intended to help a software team
understand and manage uncertainty
during the development process.
51. 51
Risk Strategies
Reactive strategies
very common, also known as fire fighting
project team sets resources aside to deal with
problems
team does nothing until a risk becomes a problem
Proactive strategies
risk management begins long before technical
work starts, risks are identified and prioritized by
importance
team builds a plan to avoid risks if they can or to
minimize risks if they turn into problems
52. 52
Software Risks - 1
Project risks
threaten the project plan
Technical risks
threaten product quality and the timeliness
of the schedule
Business risks
threaten the viability of the software to be
built (market risks, strategic risks,
management risks, budget risks)
53. 53
Software Risks - 2
Known risks
predictable from careful evaluation of current project
plan and those extrapolated from past project
experience
Unknown risks
some problems will simply occur without warning
54. 54
Risk Analysis
Risk identification
Risk projection
impact of risks/likelihood of risk actually happening
Risk assessment
what will change if risk becomes problem
Risk management
55. 55
Risk Identification
Product-specific risks
the project plan and software statement of
scope are examined to identify any special
characteristics of the product that may
threaten the project plan
Generic risks
are potential threats to every software
product
• product size
• customer characteristics
• development environment
• technology to be built
56. 56
Risk Projection
The risk drivers affecting each risk component
are
classified according to their impact category
potential consequences of each undetected software
fault or unachieved project outcome are described
58. 58
Risk Estimation
1. Establish a scale indicating perceived
likelihood of risk occurring
2. Determine consequences.
3. Estimate impact of consequences on project
(for each risk).
4. Note overall accuracy of risk projection (to
avoid misunderstandings).
59. 59
Risks Category Probability Impact RMMM
Estimated size of project in LOC or FP PS 80% 2 **
Lack of needed specialization increases
defects and reworks
ST 50% 2 **
Unfamiliar areas of the product take more
time than expected to design and implement
DE 50% 2 **
Does the environment make use of a
database
DE 35% 3
Components developed separately cannot
be integrated easily, requiring redesign
DE 25% 3
Development of the wrong software
functions requires redesign and
implementation
DE 25% 3
Development of extra software functions that
are not needed
DE 20% 3
Strict requirements for compatibility with
existing system require more testing, design,
and implementation than expected
DE 20% 3
Operation in unfamiliar software environment
causes unforeseen problems
EV 25% 4
Team members do not work well together ST 20% 4
Key personnel are available only part-time ST 20% 4
60. 60
Risk Table Construction - 1
List all risks in the first column of the
table
Classify each risk and enter the
category label in column two
Determine a probability for each risk and
enter it into column three
Enter the severity of each risk
(negligible, marginal, critical,
catastrophic) in column four.
61. 61
Risk Table Construction - 2
Sort the table by probability and impact
value
Determine the criteria for deciding
where the sorted table will be divided
into the first priority concerns and the
second priority concerns
First priority concerns must be managed
(a fifth column can be added to contain
a pointer into the RMMM document)
62. 62
CATEGORY COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE
CATASTROPHIC 1 Failure to meet would result in mission
failure
Failure results in increased costs
and schedule delays with
expected values in excess of
$500K
2
Significant
degradation to non-
achievement of
technical
performance
Non-responsive
or
unsupportable
software
Significant,
financial
shortages,
budget
overrun likely
Unachievable
delivery date
CRITICAL 1 Failure to meet the requirement would
degrade system performance to a point
where mission success is questionable
Failure results in operational
delays and/or increased costs
with expected value of $100K to
$500k
2
Some reduction in
technical
performance
Minor delays in
software
modifications
Some
shortage of
financial
resources,
possible
overruns
Possible
slippage in
delivery date
63. 63
CATEGORY COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE
MARGINAL 1 Failure to meet the requirement would
result in degradation of secondary
mission
Costs, impacts, and/or
recoverable schedule slips with
expected value of $1K to $100K
2 Minimal to small
reduction in
technical
performance
Responsive
software
support
Sufficient
financial
resources
Realistic,
achievable
schedule
NEGLIGIBLE 1 Failure to meet the requirement would
create inconvenience or nonoperational
impact
Error results in minor cost and/or
schedule impact with expected
value of less than $1K
2 No reduction in
technical
performance
Easily
supportable
software
Possible
budget
underrun
Early
achievable
date
64. 64
Risk Assessment - 1
Define referent levels for each project
risk that can cause project termination
performance degradation
cost overrun
support difficulty
schedule slippage
Attempt to develop a relationship
between each risk triple (risk,
probability, impact) and each of the
reference levels.
65. 65
Risk Assessment - 2
Predict the set of referent points that define a
region of termination, bounded by a curve or
areas of uncertainty.
Try to predict how combinations of risks will
affect a referent level
67. 67
Risk Refinement
Process of restating the risks as a set of more
detailed risks that will be easier to mitigate,
monitor, and manage.
CTC (condition-transition-consequence) format
may be a good representation for the detailed
risks (e.g. given that <condition> then there is a
concern that (possibly) <consequence>).
68. 68
RMMM - 1
Risk mitigation
proactive planning for risk avoidance
Risk monitoring
assessing whether predicted risks occur or
not
ensuring risk aversion steps are being
properly applied
collect information for future risk analysis
determining which risks caused which
problems
69. 69
RMMM - 2
Risk Management
contingency planning
actions to be taken in the event that mitigation steps
have failed and the risk has become a live problem
70. 70
Risk Mitigation Example
Risk: loss of key team members
Determine causes of job turnover.
Eliminate causes before project starts.
After project starts, assume turnover is going to occur
and work to ensure continuity.
Make sure teams are organized and distribute
information widely.
Define documentation standards and be sure
documents are produced in a timely manner.
Conduct peer review of all work.
Define backup staff.
71. 71
Risk Information Sheets
Alternative to RMMM plan in which each risk
is documented individually.
Often risk information sheets (RIS) are
maintained using a database system.
RIS components
risk id, date, probability, impact, description
refinement, mitigation/monitoring
management/contingency/trigger
status
originator, assigned staff member
72. 72
Safety and Hazards
Risks are also associated with software
failures that occur in the field after the
development project has ended.
Computers control many mission critical
applications today (weapons systems,
flight control, industrial processes, etc.).
Software safety and hazard analysis are
quality assurance activities that are of
particular concern for these types of
applications
73. 73
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
Project Scheduling
74. 74
Scheduling 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
75. 75
These slides are
designed to
accompany
Software
Engineering: A
Practitioner’s
Approach, 7/e
(McGraw-Hill
2009). Slides
copyright 2009 by
Roger Pressman.
Effort and Delivery Time
Effort
Cost
Impossible
region
td
Ed
Tmin = 0.75T d
to
Eo
Ea = m( td
4/ 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
76. 76
Effort Allocation
“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
40-50%
30-40%
15-20%
77. 77
Defining Task Sets
determine type of project
assess the degree of rigor required
identify adaptation criteria
select appropriate software engineering tasks
78. 78
Task Set Refinement
1.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
82. 82
Schedule 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 (the
diamonds shown in Figure 27.3) have been
accomplished by the scheduled date.
compare actual start-date to planned start-date for
each project task listed in the resource table (Figure
27.4).
meet informally with practitioners to obtain their
subjective assessment of progress to date and
problems on the horizon.
use earned value analysis (Section 27.6) to assess
progress quantitatively.
83. 83
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]
84. 84
Computing 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
85. 85
Computing 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.
86. 86
Computing 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
87. Assignment:
1. Provide at least five examples of how the law of
unintended consequences applies to computer software.
2. Provide detailed examples (both positive and
negative) that indicate the impact of software on our
society.
3. Many modern applications change frequently—before
they are presented to the end user and then after the
first version has been put into use. Suggest a few ways
to build software to stop deterioration due to change.
4. Consider the seven software categories presented. Do
you think that the same approach to software
engineering can be applied for each? Explain your
answer
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 87