Chapter 1: Overview Software Engineering Process Paradigms Project management Process and Project Metrics Software estimation Empirical estimation models planning Risk analysis Software project scheduling and Tracking.

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).

3. 3
Wear vs. Deterioration

4. 4
A Layered Technology
Software Engineering
a “quality” focus
process model
methods
tools

5. 5
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

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.

26. 26
Software Process Improvement
SPI
Process model
Improvement goals
Process metrics
Process improvement
recommendations

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

34. 34
Write it Down!
Software
Project
Plan
Project Scope
Estimates
Risks
Schedule
Control strategy

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

36. 36
Estimation Techniques
 Past (similar) project experience
 Conventional estimation techniques
 task breakdown and effort estimates
 size (e.g., FP) estimates
 Empirical models
 Automated tools

37. 37
Functional Decomposition
functional
decomposition
Statement
of
Scope
Perform a
Grammatical “parse”

38. 38
Conventional Methods:
LOC/FP Approach
 compute LOC/FP using estimates of
information domain values
 use historical data to build estimates for
the project

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.

43. 43
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data

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”

48. 48
The Make-Buy Decision

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

57. 57
Risk Impact
 Risk components
 performance
 cost
 support
 schedule
 Risk impact
 negligible
 marginal
 critical
 catastrophic

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

66. 66
Project Termination

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

79. 79
Define a Task Network

80. 80
Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n
Task 1
Task 2
Task 3
Task
4Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task
11Task 12

81. 81
Use Automated Tools to
Derive a Timeline Chart

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