软件工程 实践者的研究方法 第30章答案
Problem:
Measurement theory is an advanced topic that has a strong bearing on software metrics. Using [Zus97], [Fen91], [Zus90] or Web-based sources, write a brief paper that outlines the main tenets of measurement theory. Individual project: Develop a presentation on the subject and present it to your class.
Answer:
4633-23-1P SA: 9420
SR: 6376
Measurement theory is a very convenient theoretical framework to define the underlying theories upon which software engineering measures are based. Measurement theory is not shared by many statisticians and data analysts. The major terms in the measurement theory are:
• Measurement is the process by which numbers or symbols are assigned to the attributes of entities in the real world in such a way as to define them according to clearly defined rules. Measurement is the act of determining a measure.
• A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process.
• A metric is a quantitative measure of the degree to which a system, component, or process possesses a given attribute.
Main tenets (principles) of Measurement Theory:
A measurement process can be characterized by five activities. They are:
1. Formulation: The derivation of software measures and metrics appropriate for the representation of the software that is being considered.
2. Collection: The mechanism used to collect data required to derive the formulated metrics.
3. Analysis: The computation of metrics and the application of mathematical tools.
4. Interpretation: The evaluation of metrics results in an effort to gain insight into the quality of the representation.
5. Feedback: Recommendations derived from the interpretation of product metrics transmitted to the software team.
Software metrics will be useful only if they are characterized effectively and validated so that their own worth is proven. The following principles are representative of many that can be proposed for metrics characterization and validation.
• A metric should have desirable mathematical properties. That is, the metric’s value should be in a meaningful range also, a metric that purports to be on a rational scale should not be composed of components that are only measured on an ordinary scale.
• When a metric represents a software characteristic that increases when positive traits occur or decreases when undesirable traits are encountered, the value of the metric should increase or decrease in the same manner.
• Each metric should be validated empirically in a wide variety of context before being published or used to make decisions. A metric should measure the factor of interest, independently of other factors. It should “scale up” to large systems and work in a variety of programming languages and system domains.
Problem:
Why is it that a single, all-encompassing metric cannot be developed for program complexity or program quality? Try to come up with a measure or metric from everyday life that violates the attributes of effective software metrics defined in Section 30.1.5.
Answer:
4633-23-2P SA: 9420
SR: 6376
A single, all –encompassing metrics cannot be developed for program complexity or quality because, even though hundreds of metrics have been proposed for computer software, not all of them provide practical support to the software engineer. Some demand measurement, that is too complex, others are so doubtful that few real-world professional have any hope of understanding them, and others violate the basic perceptive ideas of what high quality software really is.
Although most software metrics satisfy the attributes of effective software, some commonly used metrics may fail to satisfy one or two of the attributes. One such commonly used (everyday life) metric is the function point metric. It is said that the function point metric fails to satisfy the objective – consistent and objective.
Problem:
A system has 12 external inputs, 24 external outputs, fields 30 different external queries, manages 4 internal logical files, and interfaces with 6 different legacy systems (6 EIFs). All of these data are of average complexity and the overall system is relatively simple. Compute FP for the system.
Answer:
Consider the following data:
The system has external inputs (EI’s) =12
External outputs (EO’s) = 24
External queries (EQ’s) = 30
Internal logical files (ILF’s) = 4
External interface files (EIF’s) = 6
All of these data are of average complexity = 3.
Note:
Functioning point metric:
To compute function points:
To find 
are value adjustment factors(VAF) based on the responses. But as per the scenario, all of these data are of average complexity.
Since, value of 
is 42.
Substitute the value of 
in equation Fp.
Therefore, the functional points(FP) is 299.6.
Problem:
Software for System X has 24 individual functional requirements and 14 nonfunctional requirements. What is the specificity of the requirements? The completeness?
Answer:
Soft are for system X has 24 individual functional requirements and 14 non functional requirements.
functional requirements
Non – functional requirements
To determine the specificity ( lack of ambiguity ) of requirements
A metric that is based on the consistency of the reviewers interpretation of each requirement.
Where 
is the number of requirements for which all reviewers had identical interpretations. The closer the value of 
to 1, the lower is the ambiguity of the specification.
The completeness of functional requirements can be determined by computing the ratio
Where 
is the number of unique function requirements, 
is the number of inputs defined or implied by the specification and 
is the number of states specified.
Problem:
A major information system has 1140 modules. There are 96 modules that perform control and coordination functions and 490 modules whose function depends on prior processing. The system processes approximately 220 data objects that each have an average of three attributes. There are 140 unique database items and 90 different database segments. Finally, 600 modules have single entry and exit points. Compute the DSQI for this system.
Answer:
The information system obtained from data and architectural design to derive a design structure quality index (DSQI) that ranges from 0 to 1.
The total number of modules defined in the information system.
The number of modules whose correct function depends on the source of data input or that produce data to be used else
The number of modules whose correct function depends on prior processing.
The number of data base items.
The total number of unique data base items.
The number of data base segments
The number of modules with a single entry and exit.
Once values 
through 
are determined for a computer program, the following intermediate value can be computed.
Program structure: 
where 
is defined as follows: if the architectural design was developed using a distinct method (e.g data flow oriented design or object – oriented design).Then 
otherwise 
.
Module independence : 
Module not dependent on prior processing : 
Database size : 
Database compartmentalization : 
Module entrance / exit characteristic : 
With these intermediate values determined, the DSQI is computed in the following manner:
Where i = 1 to 6, 
is the value relative weighting of the importance of each of the intermediate values and 
Module independence : 
Modules not independent on prior processing : 
Database size : 
Database compartmentalization: 
Module entrance/ exit characteristic: 
The DSQI is computed in the following manner
Assuming wi=0.167,
DSQI = 0.167 SUM (Di)
=0.644
Problem:
A class X has 12 operations. Cyclomatic complexity has been computed for all operations in the OO system, and the average value of module complexity is 4. For class X, the complexity for operations 1 to 12 is 5, 4, 3, 3, 6, 8, 2, 2, 5, 5, 4, 4, respectively. Compute the weighted methods per class.
Answer:
WMC is simply the sum of each of the individual complexities divided by the average complexity:
Average complexity is =4
WMC=(5/4)+(4/4)+(3/4)+(3/4)+(6/4)+(8/4)+(2/4)+(5/4)+(5/4)+(4/4)+(4/4)
WMC = 1.25 + 1 + 0.75 + 0.75 + 1.5 + 2 + 0.5 + 0.5 + 1.25 + 1.25 + 1 + 1
= 12.75
Problem:
Develop a software tool that will compute cyclomatic complexity for a programming language module. You may choose the language.
Answer:
Cyclomatic complexity for a programming language module:-
Cyclomatic complexity is software metric and it is used to measure the complexity of a program. It directly measures the number of linearly independent path through a program’s source code.
Consider the sensor software. It is an automated tool for identify the users in login process.
Flow diagram of this tool:-
In this process, the reader input waiting for user’s request.
If the first request is valid then control goes to another one and if the first request is not valid then loop go back for valid request. The process is goes like this.
According this tool, the cyclomatic metric measures the amount of decision logic in a single software module. In my implementation, I have taken the software module to be a function. The cyclomatic complexity is based entirely on the Structure of the software’s control flow graph.
Formula for calculating the cyclomatic complexity for each function using it’s control flow graph is
Here
are the number of edges and nodes
Control flow graphs for the control structures found in 
language except for ‘for loop’
Control flow graphs that are used in our sensor tool designing section
Problem:
Develop a small software tool that will perform a Halstead analysis on programming language source code of your choosing.
Answer:
592-15-10P SA CODE: 4475
SR CODE: 4467
Consider the software tool, that calculate the two integer numbers
Source code of adding two integers in Java
Public class Add numbers
{
Public static void main (string [7 args)
{
System.out.print ln (“Adding of two numbers!”);
int a
Integer. Parse Int (args [0]);
int b
Integer. Parse Int (args [1]);
int sum
system. Out. Print ln (“sum:”
sum);
}
}.
Now take the Halstead’s theory and based on analysis of this theory through above source code we may observe like this.
Hallstead uses the primitive measures to develop expressions for the overall program length, potential minimum volume for an algorithm, the actual volume, the language level and other features such as development effort, development time even the project number of faults in the software.
Halstead shows that length N can be estimated by
Program volume (V) may defined
And
Volume ratio (L) expressed as
Here
The number of distinct operators that appear in a program
The number of distinct operands that appear in a program
Total number of operator occurrences
Total number of operand occurrences
So, from the above source code
(that is ‘t’)
(that is variable ‘a & b’)
We apply these values to Halstead analysis theory. Than
So 
Now we need to calculate the volume (v)
Now we need to calculate the volume ratio (L)
Like this we analysis the program source code using Halstead analysis
Problem:
A legacy system has 940 modules. The latest release required that 90 of these modules be changed. In addition, 40 new modules were added and 12 old modules were removed. Compute the software maturity index for the system.
Answer:
A software maturity index (SMI) that provides an indication of the stability of a software product (based on changes that occur for each release of the product ).
The number of modules in the legacy system
The number of modules in the latest release that have been changed
The number of modules in the latest release that have been added.
The number of modules from the preceding release that were removed in the latest
release.
The software maturity index is computed in the following manner:
Solution: CHAPTER30: PRODUCT METRICS
30.1 As an alternative, you might assign readings from one or more recent papers on the subject.
30.2 That’s like asking for a single metric to describe a human being. Should it be weight, height, eye color, IQ, EQ, foot size, ... Software systems are just too complex and have too many attributes, all of which are meaningful. Therefore, the search for a single number is fruitless.
30.3 Unadjusted count total = 340, questionnaire total = 3 * 14 = 42, FP = 363.8 (using one of the tiny tools on the SEPA website.
30.4 The specificity cannot be computed without making assumptions about the number of requirements on which reviewers have identical interpretations for (e.g. if reviewers agree on all 38 requirements Q1 = 38/38 = 1). Completeness cannot be computed without making some assumptions on the number of requirements that have been validated as correct and how many have not yet been validates (e.g. if all 38 have been validated then Q3 = 38/(38 + 0) = 1).
30.5. To compute DSQI, we use equation and related definitions:
S1 = 1140
S2 = 1140 - 96 = 1044
S3 = 490
S4 = 220 + 220*3 = 880
S5 = 140
S6 = 90
S7 = 600
we assume D1 = 1
D2 = 1 - (1044/1140) = 0.08
D3 = 1 - (490/1140) = 0.57
D4 = 1 - (140/880) = 0.84
D5 = 1 - (90/880) = 0.90
D6 = 1 - (600/1140) = 0.47
Assuming wi = 0.167,
DSQI = 0.167 SUM (Di)
= 0.644
This value has no meaning in a vacuum. It must be compared to values for other applications. If lower, design may be suspect.
30.6 WMC is simply the sum of each of the individual complexities divided by the average complexity:
WMC = 1.25 + 1 + 0.75 + 0.75 + 1.5 + 2 + 0.5 + 0.5 + 1.25 + 1.25 + 1 + 1
= 12.75
30.7 – 30.8 These exercises could be good term projects (depending on the nature of the input to the tools).
30.9 The software maturity index is computed using equation
Mt = 940
Fc = 90
Fa = 40
Fd = 12
SMI = [940 - (40 + 90 + 12)] / 940 = 0.85
This value indicated that the system has a way to go before it fully stabilizes (SMI -> 1.0).
+
