Software scale measure--measurement of internal properties of software
3.1 Basic knowledge 1. Where can I measure the size of the software?
? Number of software functions: Streaming graph, use case diagram
? Number of software modules: module function result diagram
? Number of lines of code: operator, operand
? Number of pages in the design document
? Number of pages in the user manual
2. The size of the software can be used to reflect:
? Effort Workload (Person month)
? Cost
? Productivity efficiency
? Schedule Schedule
3. Software size can be defined according to the following:
? Length (code length, specification length)
? Functionality functionality
? Complexity complexity
? Reuse Software Reuse
4. Measure the size of the software with software functionality (functionality):
? Functional point function points
? Feature points Feature Point
? Objects point Object Points
? Use case points use-case point
3.2 Function Point measurement method (FUNCTIONPOINT,FP)
The function point measurement method can be analyzed by data flow diagram,dfd, and four elements in the Data flow chart: The starting point, the stream, the processing, the data storage;
Function points Calculation method: function point = UFC * VAF (FP = pre-adjusted functional points * adjustment factor);
(1) According to the following table to measure the five types of elements in the streaming diagram:
Measure elements |
Number |
Weight factor Simple general complex |
Subtotal |
Number of inputs |
|
3 4 6 |
&nbs P; |
Number of outputs |
|
4 5 7 | td>
Number of user queries |
|
3 4 &NB Sp 6 |
|
Number of internal files |
|
5 7 10 |
|
Number of external interfaces |
|
7 &N Bsp 15 |
|
Total |
| td>
|
(2) 5 Types of measurement elements (input, output, query, internal file, external interface) difficult to divide into three difficult levels: simple, general, complex, and give the corresponding weight factor. Evaluate the difficulty level of each measurement element and calculate the weighting factor.
(3) The UFC calculation is related to two factors: the number of 5 types of measurement elements (input, output, query, internal file, external interface), the ease of each measurement element (simple, general, complex).
In theory, there are 15 different kinds of items (each of the 5 classes has three complexity levels), so
Pre-adjustment function points calculation method: Multiply the number of items by the weight value of the class, and then sum the 15 products:
The UFC =∑ (the first?? Number of class items) ∗ weight value??)
(4) VAF: The impact of performance requirements on software size, including the complexities associated with internal system complexity and the functionality of the user perspective.
A total of 14 factors Fi (1≤i≤14), the degree of influence from light to heavy from 0-5 reviews. 0 means that the sub-factor has no effect on the system, 3 means that the sub-factor has a moderate effect on the system, and 5 means that the sub-factor plays a key role in the system being constructed.
Table 1 Technical Complexity system components
F1 |
Reliable Backup and recovery |
F8 |
Online updates |
F2 |
Communication |
F9 |
Complex interfaces |
F3 |
Distributed functionality |
F10 |
Complex processing |
F4 |
Performance |
F11 |
Re-usability |
F5 |
Heavily-used configurations |
F12 |
Ease of installation |
F6 |
Online data entry |
F13 |
Multi-site |
F7 |
Ease of operation |
F14 |
Easy to change |
(5)
VAF value [0.65, 1.35], all fi values are 0 o'clock vaf=0.65, the value of all fi is 5 o'clock vaf=1.35.
Advantages of the function point measurement method:
The software scale can be predicted before design and coding, that is, it can be predicted in the requirement analysis phase, the cost, workload and progress of the project can be forecasted in the early stage of the software development cycle, and it will contribute to the contract negotiation (cost, schedule), and the measure of software scale can be used according to certain standards;
function point Measurement method defect:
The FP calculation is subjective: the degree of difficulty of the 5 types of measurement elements and the extent of their performance impact are determined by people;
Recurring calculation problem: The internal complexity is calculated repeatedly when the weighted and VAF calculations of the input and output of the function points are not adjusted.
The problem with numerical visualization: When the complexity of Fi is "General", the rating is 3, then the value of VAF should be 1. But the vaf=1.07 is calculated according to the formula.
Problems used early in the life cycle: compute function points, not only user requirements documents, but also a more complete software system specification.
application area problem: The function point measure is suitable for the measurement data processing system, such as MIS system, but not suitable for the system of real-time system, control system or scientific application field.
3.3 Feature Point measurement Method (Featurepoint, FeP) feature point measurement method is based on the function point measurement method to consider the complexity of the algorithm , that is to consider the system in the
The following factors: input, output, query, internal file, external interface, algorithm. The method of feature point measurement is suitable for the system with complex algorithms such as real-time system, control system, embedded system, etc.
The module is measured.
The 3.4 Object Point measurement Method (Objectpoint,op) Object Point measurement method is a preliminary measure of software size in the feasibility analysis stage of software development process.
Method.
Divide objects in the system into three categories: the components of screen (interface), report, and third-generation languages divide three classes of objects into simple, general, and complex categories based on the interface, the number of data sources in the report (Tables and views), and the source.
Interface complexity level
Number of views included |
Number and source of data tables |
Total < 4 (<2 server, <2 client) |
Total < 8 (2-3 server, 3-5 client) |
Total 8 + (>3 server, >5 client) |
<3 |
Simple |
Simple |
Moderate |
3-7 |
Simple |
Moderate |
Complex |
8+ |
Moderate |
Complex |
Complex |
Report Complexity level
Number of bars included |
Number and source of data tables |
Total < 4 (<2 server, <2 client) |
Total < 8 (2-3 server, 3-5 client) |
Total 8 + (>3 server, >5 client) |
<3 |
Simple |
Simple |
Moderate |
3-7 |
Simple |
Moderate |
Complex |
8+ |
Moderate |
Complex |
Complex |
Complexity weights for object points
The number of points of the three types of objects can be added to the system object points. If you consider reuse in the system, assume that the r% object is reused from a previous project: New object point = Object Point * (1-r%)
The 3.5 use case Point measurement (use-casepoint, up) use case diagram is a method used to perform requirements analysis when designing software for object-oriented method analysis. Use case diagrams include use cases and roles, and use case points to measure software sizing methods primarily measure use cases and roles in use cases. Six steps to calculate a use case point:
(1) Calculate the role weight before the adjustment (unadjusted actor weights, UAW)
(2) Calculation of use-case weights before adjustment (unadjusted, UUC)
(3) Calculation of the use case point before adjustment (UUCP) UUCP = UAW + Uuc
(4) Computational complexity factor (TCF)
TCF = 0.6 + (0.01 * tfactor)
(5) Computing Environment Factor (EF)
EF = 1.4 + ( -0.03 * EFactor)
(6) Calculate adjusted use case point (UPC) UPC = UUCP * TCF * EF
Role weighting assessment that divides roles into simple, general, and complex three types:
Two methods of weight evaluation of use cases, that is, based on the interaction evaluation method and the evaluation method based on the analysis class, both of which divide the use case into simple, general and complex three kinds
Because a use case is an abstract description of a set of action sequences (interactions), the system executes the sequence of actions and produces the corresponding results. Therefore, the more these interactions are contained in a use case, the more complex it is. Because use case analysis is the process from the use case model to the analysis model, it is the bridge between demand and design. Use case analysis assigns the behavior of the system to the analysis class, allowing the analysis class to interact to complete the system's behavior. Therefore, the more analytical classes involved in a use case, the more complex it is. The analysis class consists of three kinds: Boundary class, control class, entity class.
Role type |
Describe |
Weight factor |
Simple |
Program Interface |
1 |
So so |
Interactive interface, protocol-driven interface |
2 |
Complex |
Graphical interface, human-computer interface |
3 |
Use case type |
Describe |
Weight factor |
Simple |
3 or less than 3 interactions |
5 |
So so |
4-7 Interactions |
10 |
Complex |
More than 7 interactive |
15 |
Use case type |
Describe |
Weight factor |
Simple |
Less than 5 analysis classes |
5 |
So so |
5-10 Analysis Classes |
10 |
Complex |
Over 10 analysis classes |
15 |
3.6 Length to measure the size of software Halstead method
LOC
Specification and length of design
3.8 LOC (line of Code)
LOC = Ncloc + CLOC
Ncloc:non-commented line of code non-comment row cloc:commented lines of code comment line
Note density: Cloc/loc, which reflects the program's understandable, modifiable, maintainable
Advantages of the LOC metric:
(1) Simple, can be automatically measured
(2) Directly related to the workload and cost of the program
Disadvantages of the LOC metric:
(1) Define ambiguity (such as whether the number of lines of code counts as comment lines)
(2) Code length related to programming language
(3) Not suitable for predicting software size in the early stages of software development (4) in relation to the developer's capabilities
The fourth Chapter software structure measure method
Early software metrics were associated with functional decomposition-oriented design methods, mostly based on module metrics.
Process-oriented programming, the main factors affecting the quality of software: coupling, cohesion, complexity, modularity and size.
Using the software module structure diagram for analysis, can be measured from the following aspects:
? Maximum number of data transfers between modules
? Average of the amount of data passed between modules
? Total amount of data transferred between modules
? Number of common data between modules
? Module fan-in, fan-out average, and maximum value? Module condition call, number of circular calls? Maximum depth (number of layers)
It is generally believed that a well-designed software product uses its internal structure to describe its characteristics. The internal structure properties of the software include modularity, coupling, cohesion, complexity, information flow, reuse degree and so on. If you can measure these attributes, you can identify parts of the software that are difficult to implement, test, and maintain.
4.2 Types of structure metrics
Structure affects the time and effort, maintenance costs, and complexity of design, coding, and testing. This paper mainly measures three kinds of structure: control flow structure, data flow structure and structure. Control flow solves the order of execution of various directives in the program, reflecting
The iterative and cyclic nature of the program. The program size can only be counted once for an instruction, and the control flow reflects that a command may be executed more than once when the program is actually running.
Data flow is capable of tracking a program's trajectory as it creates or processes a data item. Data flow metrics Describe the behavior of data interacting with a program.
Data Structure is a matter of organization that is not related to a program. If the data elements are organized into tables, queues, stacks, or other well-defined structures, it is easy to define the algorithm for creating, modifying, or deleting data when the program is implemented. The data structure reflects the difficulty of writing the program "to process the data" and the test cases that define "to verify the correctness of the program"
The difficulty of the time. In some cases, the complexity of the program is caused by complex data structures rather than complex control flows or data flow structures.
4.3 Control Flow structure
The modeling of control flow metrics usually takes a forward graph (Directed graph).
In a graph, each node (or point) corresponds to a program statement, and each arc (or a forward edge) represents a control flow from one statement to another. This graph is a control flow graph (Control-flow graph) or flow graph.
The McCabe cyclomatic complexity can measure the control flow structure in the following three ways:
(1) The complexity of the program is measured by the number of turns in the program flow graph. (You need to connect the end-to-end nodes of the program flow graph).
(2) calculated by V (G) = E–n +2, where E is the number of sides in the program flow graph, and n is the node count in the program flow graph.
(3) The number of decision statements that can be judged by the branch and loop in the program.
4.4 Data Flow structure 4.4.1 coupling
The coupling within the module (Cohesion) to the module (coupling).
Coupling: The degree of interdependence between two modules. So coupling refers to a property of a module pair, not a design attribute as a whole. The complete works of the modules in the design represent global coupling (globalcoupling), and global coupling can be deduced from the coupling of the possible module pairs.
There are two modules X and y in the system, and there may be 6 coupling relationships between the two modules:
(1) No coupling relationship between r0:x and y, i.e. x and y are completely independent;
(2) Data coupling relationships r1:x and y are linked by parameters, where each parameter is a data element or a collection of homogeneous data items that do not contain control elements. Any connection between the modules is necessary for this type of coupling;
(3) The tag coupling relationship r2:x and y treat the same record type as a parameter. This type of coupling can make two of other unrelated modules dependent on each other;
(4) The control coupling relation r3:x passes a parameter to Y, which can control the behavior of Y. That is, the passed parameter is a flag, such as passing a value of 1 or 0, to control the execution of the program in Y;
(5) Public coupling relationship r4:x and Y refer to the same global data. This type of coupling makes it necessary to change the modules of all public coupling relationships when the global data format changes.
(6) The content coupling relation r5:x refers to the interior of Y, that is, a branch of x enters Y, or changes the data within Y, or modifies a statement within Y.
The order of the above 6 coupling relationships: the least dependent on the top and the strongest at the bottom. by the i〉j, the RI〉RJ. I equals 1 or 2, it is considered a loose coupling between x and Y (loosely coupled). is equal to 4 or 5, i.e. public coupling and content coupling are tightly coupled (tightly coupled).
Use (I, j) to denote the coupling between the module x and Y, where I represents the coupling relationship ri,j represents the number of times the coupling of a given type appears between X and Y.
The coupling between module x and y is measured by:
C (x, y) = k + n/n+1
K represents the largest coupling relationship between X and Y Rk,n is the number of connections between x and Y. (Fention, Melton. 1990)
Assuming that the system S is composed of module D1, ..., Dp,..., Dq,..., Dn, then the system S global coupling degree C is measured by:
C (S) is the median of the set {C (Dp, Dq): 1≤p≤q≤n}
The global coupling degree of the system S reflects the overall level of connectivity in the system. Coupling is one of the most important properties affecting the quality of system design.
4.4.2 Internal Gathering
When a module is clustered, it is the degree to which each component of the module is required to complete the same task. 7 Kinds of cohesion: functional cohesion: A module to complete a well-defined function; Sequential clustering: The module completes more than one function, but the order in which these functions appear is the specification
provisions; Communication cohesion: The module completes more than one function, but these functions are located on the same data body; In-process clustering: modules do more than one function, but these functions are only relevant to a common process;
Time to gather: the module completes more than one function, these functions are in the same time to appear. Such as: Initialize the module.
Logical cohesion: The module completes more than one function, but these functions are only logically related; Coincidence: The module completes more than one function, these functions are irrelevant.
The order of the above 7 coupling relationships: The strongest cohesion at the top and the weakest cohesion at the bottom. A measure of how cohesive the system is:
Cohesive rate = number of modules/modules with function cohesion (Yourdon and Constantine, 1979)
Complex cohesive measurement methods (Bieman and Ott, 1994) 4.4.3 information flow
The flow of information between modules and other parts of the system exists in the following situations:
(1) One module calls another module and passes information to the module, and (2) the called module returns a result to the calling module.
If the information returned by the called module is subsequently passed to the second called module, there is a local flow of indirection (local indirect flow), and the global flow is considered to exist if the flow is passed from one module to another through a global data structure.
4.5 Data Structures
Data structures are measured by simple data types such as integer types, character types, and Boolean types, complex data structures, and various operations on these data types.
The calculation of operators and operands in the Halstead method is a measure of data structure.
The sixth chapter software quality measurement
External properties: Properties that can be measured when considering an association with an external environment. For example, reliability refers to the probability of a failure-free operation. and its operating environment and users; Internal properties can be measured early in the software life cycle, while external attributes are only available when the software or product finishes
The internal properties are easier to measure than external properties, internal properties tend to affect external properties, and external properties can be predicted through internal properties.
Software quality is "the degree to which the software is consistent with the need for a clear and implicit definition." Specifically, software quality is the degree to which the software complies with clearly described functional and performance requirements, the development standards clearly described in the documentation, and the implied features that all specialized software developers should have.
External attributes in Baidu Encyclopedia:
1. Performance (performance) refers to the system's responsiveness, that is, how long it takes to respond to an event, or the number of events the system can handle in a certain period of time;
2. Availability (availability) refers to the percentage of time that the system can function properly;
3. Reliability (reliability) refers to the ability of the system to maintain the functional characteristics of the software system in the presence of accidental or erroneous use, in the face of an application or error;
4. Robustness (robustness) refers to the ability of a system to withstand stress or change in a process or environment;
5. Security refers to the ability of the system to provide services to legitimate users while blocking attempts or denial of service by unauthorized users;
6. Modifiable (modification) refers to the ability to quickly change the system at a higher performance-price ratio;
7. Variability (changeability) refers to the ability of an architecture to expand or change into a new architecture; 8. Ease of use (usability) is a measure of how easy it is for a user to accomplish a specified task using a software product; 9. Testability (testability) refers to the ability characteristics of software to detect faults and isolate their faults to
And at a certain time or cost under the premise of testing design, test execution ability; 10. functionality (function ability) refers to the ability of the system to perform the desired work; 11. Interoperability (Inter-operation) refers to the interaction between the system and the outside world or between systems and systems
Ability.
6.2 Software Quality Modeling
McCall quality model, Boehm quality model, ISO 9126 quality model
6.2.1 McCall Quality Model
McCall quality model is divided into three categories: product operation, product revision and product transfer. Product operation: Correctness, robustness, efficiency, completeness, availability, risk; product modifications: comprehensible, maintainability, flexibility, testability, product transfer: portability, reuse, interoperability.
6.2.2 Boehm Quality Model
The Boehm software quality model quantifies software quality through a series of attributes, using hierarchical quality model structures, including high-level attributes, middle-tier attributes, and raw attributes.
High-level properties: As-is Utility general use maintainability maintainability
The Portability Portability middle attribute contains 7 quality elements:
Portability, reliability, efficiency, ergonomics (ease of use), testability, understandable, modifiable
6.2.3 ISO 9126 Quality model
ISO 9126 defines the 6 quality characteristics of the software: 1. Functionality (functionality): When the software is used under specified conditions, the SOFTWARE PRODUCT is provided with a full
The ability to express and implicitly require functionality; 2. Reliability (Reliability): When used under specified conditions, the SOFTWARE product maintains the specified performance level
other abilities; 3. Ease of Use (usability): When used under specified conditions, software products are understood, learned, made
The ability to use and attract users;
4. Efficiency (efficiency): Under the specified conditions, relative to the quantity of all resources, software products can provide the appropriate performance capabilities;
5. Maintainability (maintainability): The ability of software products to be modified. Modifications may include corrections, adaptations, precautions, and improvements.
6. Portability (portability): the ability of a software product to move from one environment to another.
Review of Software Metrics