Tải bản đầy đủ (.pdf) (77 trang)

Lecture Software process improvement: Lesson 40B - Dr. Ghulam Ahmad Farrukh

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (374.68 KB, 77 trang )

A Goal­based Framework for 
Software Measurement
Lecture # 40­B

1


A Goal­based Framework for 
Software Measurement
• Today, we’ll talk about a conceptual 
framework for the diverse software­
measurement activities that contribute to an 
organization’s software practices
• These practices may include not only your 
usual development and maintenance 
activities, but also any experiments and case 
studies you may perform as you investigate 
new techniques and tools
2


A Goal­based Framework for 
Software Measurement
• This framework is based on three 
principles:
– Classifying the entities to be examined
– Determining relevant measurement tools
– Identifying the level of maturity that your 
organization has reached

3




Classifying Software Measures

4


• The first obligation of any software 
measurement activity is identifying the 
entities and attributes we wish to measure
• In software, there are three such classes 
(discussed next):

5


• Processes
– These are collections of software­related 
activities

• Products
– These are any artifacts, deliverables or 
documents that result from a process activity

• Resources
– These are entities required by a process activity
6


• A process is usually associated with some 

timescale, i.e., the activities in the process are 
ordered or related in some way that depends 
on time, so that one activity must be 
completed before another can begin
• The timing can be explicit, as when design 
must be complete by October 31, or implicit, 
as when a flow diagram shows that design 
must be completed before coding can begin 7


• Resources and products are associated with 
the process
• Each process activity has resources and 
products that it uses, as well as products 
that are produced
• Thus, the product of one activity may feed 
another activity, e.g., the design document
8


• Before, we discuss these entities in detail, 
let’s distinguish between internal and 
external attributes:
– Internal attributes
– External attributes

9


Internal Attributes

• Internal attributes of a product, process or 
resource are those that can be measured 
purely in terms of the product, process or 
resource itself
• In other words, an internal attribute can be 
measured by examining the product, 
process or resource on its own, separate 
from its behavior
10


External Attributes
• External attributes of a product, process or 
resource are those that can be measured 
only with respect to how the product, 
process or resource relates to its 
environment
• Here, the behavior of the process, product 
or resource is important, rather than the 
entity itself
11


Examples of Internal and 
External Attributes
• Some attributes of software can be 
determined without executing it, like, 
software size, its complexity, and the 
dependencies among modules
• Some attributes of software can only be 

measured when code is executed, like, the 
number of failures experienced by a user, 
difficulty in navigating screens, database 
search time
12


• There is a clear need for internal attribute 
measurements to support measurement and 
decision making about external attributes
• We need to identify the relationships among 
internal and external attributes, as well as to 
find new and useful methods for measuring 
directly the attributes of interest
13


Processes (3.1.1)
• We often have questions about our software 
development activities and processes that 
measurement can help us answer
• We want to know how long it takes for a 
process to complete, how much it will cost, 
whether it is effective or efficient, and how 
it compares with other processes that we 
could have chosen
14


• However, only a limited number of internal 

process attributes can be measured directly
• These measures include:
– The duration of the process or one of its 
activities;
– The effort associated with the process or one of 
its activities;
– The number of incidents of a specified type 
arising during the process or one of its activities

15


• For example, we may be reviewing our 
requirements to ensure their quality before 
turning them over to the designers
• To measure the effectiveness of the review 
process we can measure the number of 
requirements errors found during 
specification
16


• We can measure the number of 
requirements errors found during 
integration testing to determine how well 
we are doing
• We can get insight into the resources 
needed for development process by 
measuring the number of personnel working 
on the project between May 1 and 

September 30
17


Average Cost of each Defect 
Detected during the process

18


Average Cost of each Defect 
Detection during the Process
Cost
Number of Errors Found

this is an indirect measure
19


Effectiveness of Software Inspections

20


Effectiveness of Software 
Inspections
Measure the average amount of effort 
expended per thousand lines of code 
reviewed


21


Effectiveness of Software Testing 
Process

22


Effectiveness of Software 
Testing Process
The testing process may be composed of unit testing, 
integration testing, system testing, and acceptance 
testing
Each component process can be measured to 
determine how effectively it contributes to overall 
testing effectiveness
We can track the number of errors identified in each 
sub­process, along with the duration and cost of 
identifying each error, to see if each sub­process is 
23
cost­effective


• Cost is not the only process measure we can 
examine
• Controllability, observability, and stability 
are also important in managing large 
projects
• These attributes are clearly external


24


• We often use propose objective measures of 
external attributes in terms of internal 
attributes
• For example, measures of the effectiveness 
of code maintenance can be defined in 
terms of the number of faults discovered 
and the number of faults corrected
25


×