China
Africa
Explore chapters and articles related to this topic
Quality Assurance Improvement with Metrics
Published in Boyd L. Summers, Effective Processes for Quality Assurance, 2019
Measuring the length of code using number of lines of code or assess software quality through defects/bugs. A line of code is any line of program text that is not a comment or a blank line, regardless of the number of statements or fragments of statements on the line. This specifically includes all lines containing program headers, declarations, and executable and nonexecutable statements. Accepted measurements are dependent on the programming language and programmer and well designed with short programs. Source code creation is only a small part of the total development effort, and it is often unclear how to count lines of code implemented for delivery to the client when the product is completely finished. Most work on software measurement has focused on code-based metrics and plan-driven development processes, and more software is now developed by configuring system requirements. Software measurement per metrics can be used to gather data about software and software processes. Product Quality Assurance metrics are particularly useful for highlighting anomalous components that may have quality problems.
System and Software Measurement Programs
Published in Ron S. Kenett, Emanuel R. Baker, Process Improvement and CMMI® for Systems and Software, 2010
Ron S. Kenett, Emanuel R. Baker
In determining “size,” we need a measure that is standardized across projects and independent of the methodology, technology, or development tools used to create the systems or software. Commonly cited measures of size include pages of documentation, number of objects, lines of code or function points, and number of manufactured units. For software, lines of code are typically measured without counting embedded comments in the source code and without special-purpose code used only for testing and debugging. The SEI guideline [5] for measuring lines of code is a standard that can be used to ensure that consistent definitions are used within the organization. As noted in Chapter 2, we emphasize again the importance of operational definitions, in this case to ensure that a line of code means the same thing to everyone involved. A function points is a dimensionless number that is representative of the extent of the functionality of the software—hence, a size measure. Guidelines for counting function points are provided in publications available from the International Function Points User Group (IFPUG). Function points also enable consistent size definitions within an organization, or within the software industry, for that matter, because they are independent of the programming language used for any project.
PLC terms and definitions
Published in Raymond F. Gardner, Introduction to Plant Automation and Controls, 2020
This is the smallest standalone element of code for an action to be carried out to form the sequence of a program. Statements can be simple lines of code, or more complex actions, such as if-then-else or do-while statements. Typically, a statement does not return a value, or then it would be more accurately called a function.
Evaluation criteria for holonic control implementations in manufacturing systems
Published in International Journal of Computer Integrated Manufacturing, 2019
Any evaluation based on complexity measures should be approached with care. It is a challenging task to formulate objective metrics. The proposed evaluation is similar to that shown in Cesarini, Pappalardo, and Santoro (2008) – using a code complexity measure that is based on a simple ‘source lines of code’ (SLOC) measurement. This measure is based on a simple philosophy: more lines of code mean more work, and more errors. Hubbard (1999) argues that a SLOC measurement is dependent on at least three factors: Program functionalityProgrammer skillProgramming language
Do we need to pay technical debt in blockchain software systems?
Published in Connection Science, 2022
Yubin Qu, Tie Bao, Xiang Chen, Long Li, Xianzhen Dou, Meng Yuan, Hongmei Wang
To do so, we search for open-source projects with the keyword blockchain on Github, and manually select these projects by reading the readme file. We first chose the two most popular cryptocurrency projects, including Bitcoin 2 and Ethereum3 projects. Then we select four other projects on Github, based on the fact that these four projects have won a large number of “stars” from other developers. These “stars” mean that these four projects are widely used by developers. These four projects include chia-blockchain ,4 diem-libra-core ,5 fabric,6 solidity.7 Table 1 describes the blockchain projects used in our research, including the name of the project, the code version used, the total number of lines in the project, the programming language used in the project and stars from Github. The bitcoin project is an experimental digital currency. The Ethereum project is official Golang implementation of the Ethereum protocol and Ethereum is an open-source public blockchain platform with smart contract functionality. The diem project is a decentralised, programmable database. The solidity project is a statically typed, contract-oriented, high-level language. The fabric project is a platform for distributed ledger solutions. The chia project is a modern cryptocurrency. For the Bitcoin, solidity and chia projects, we utilise the sloccount8 to calculate the total source lines of code, following a previous study by Maldonado and Shihab (2015b). For the remaining three projects, we developed a Python-based program to count the total number of lines of code.