Three design principles are prominent in software development-encapsulation, data hiding, and separation of concerns.These principles are used as subjective quality criteria for both procedural and object-oriented applications.The purpose of research is to quantify encapsulation, data hiding, and separation of concerns is quantified using cyclomatic-based metrics.As a result of this research, the derived design metrics, coefficient of encapsulation, coefficient of data hiding, and coefficient of separation of concerns, are defined and applied to production software indicating whether the software has low or high encapsulation, data hiding, and separation of concerns.

Software flaws represent a serious threat to system integrity. Today, software plays an increasingly important role in the infrastructure of government agencies. These entities outsource and use open-source software within their critical infrastructure; however, the origins and security characteristics of this code are rarely certified. We compare the relative effectiveness of the statement, branch, and cyclomatic code coverage software testing methodologies for detecting flaws in software. Uncovering Weaknesses in Code With Cyclomatic Path Analysis Foreign influence on DoD software is a major security concern [1]. A programmer can insert a flaw into code that looks like an honest mistake, but when triggered leads to unexpected behavior in the system on which the software resides. The consequences could be anything from system unavailability to outright hijacking of the system and all of its functionality. Given the potentially catastrophic consequences of allowing exploitable software flaws to reside in operational systems, software testing is now being acknowledged as a critical step to mitigate software supply chain risks [2]. Protecting against the “inside job” is not the only concern for those wishing to protect software systems from attack. Foreign adversaries persistently attempt to break into the networks of defense facilities and their contractors. A successful intruder would steal anything that could provide economic or strategic advantage. The speculated compromise of the Joint Strike Fighter [3] is a high profile example, with tens of thousands of hours of programming feared lost. Not only can code be copied, it can be studied intensively for weaknesses. By interfacing operational systems running the software and injecting attacks to trigger exploitable weak-

It is now understood that software metrics alone are not enough to characterize software quality. To cope with this problem, most of advanced and/or industrially validated quality models aggregate software metrics: for example, cyclomatic complexity is combined with test coverage to stress the fact that it is more important to cover complex methods than accessors. Yet, aggregating and weighting metrics to produce quality indexes is a difficult task. Indeed, certain weighting approaches may lead to abnormal situations where a developer increasing the quality of a software component seeing the overall quality degrade. Finally, mapping combinations of metric values to quality indexes may be a problem when using thresholds. In this paper, we present the problems we faced when designing the Squale quality model, then we present an empirical solution based on weighted aggregations and on continuous functions. The solution has been termed the Squale quality model and validated over 4 years with two large multinational companies: Air France-KLM and PSA Peugeot-Citroen.

During the past decade, software development concepts have undergone a dynamic revolution. Software development methodologies have evolved to meet changing life cycle patterns which have had as their objective, emphasis on analysis and design. In addition, computerassisted software engineering (CASE) has emerged to meet the unprecedented growth in analysis and design activities and is affecting how future systems will be developed and tested. These methodologies reinforce the need to accurately define systems specification prior to implementation. The concern over present and future software quality has grown as the volume and complexity of applications increase. Software applications are critical to business operation and lead to severe maintenance problems when they fail. This fact has prompted many firms to develop software engineering programs which attempt to define and implement techniques for software validation, verification, and testing throughout the development life cycle.

................................................................................................ iii

System designers can quantify the complexity of a software design by using a trio of finely tuned design metrics.

This paper deals with the use of Structured Analysis just prior to system acceptance testing. Specifically, the drawing of data flow diagrams (DFD) was done after integration testing. The DFD's provided a picture of the logical flow through the integrated system for thorough system acceptance testing. System test sets, were derived from the flows in the DFD's. System test repeatability was enhanced by the matrix which flowed from the test sets.

This paper describes a graph-theoretic complexity measure and illustrates how it can be used to manage and control program complexity. The paper first explains how the graph theory concepts apply and gives an intuitive explanation of the graph concepts in programming terms. The control graphs of several actual FORTRAN programs are then presented to illustrate the correlation between intuitive complexity and the graph theoretic complexity. Several properties of the graph-theoretic complexity are then proved which show, for example, that complexity is independent of physical size (adding or subtracting functional statements leaves complexity unchanged) and complexity depends only on the decision structure of a program.The issue of using non-structured control flow is also discussed. A characterization of non-structured control graphs is given and a method of measuring the “structuredness” of a program is developed. The relationship between structure and reducibility is illustrated with several examples.The last section of the paper deals with a testing methodology used in conjunction with the complexity measure; a testing strategy is defined that dictates that a program can either admit of a certain minimal testing level or the program can be structurally reduced.