A Suite of Object Oriented Cognitive Complexity Metrics

Object orientation has gained a wide adoption in the software development community. To this end, different metrics that can be utilized in measuring and improving the quality of object-oriented (OO) software have been proposed, by providing insight into the maintainability and reliability of the system. Some of these software metrics are based on cognitive weight and are referred to as cognitive complexity metrics. It is our objective in this paper to present a suite of cognitive complexity metrics that can be used to evaluate OO software projects. The present suite of metrics includes method complexity, message complexity, attribute complexity, weighted class complexity, and code complexity. The metrics suite was evaluated theoretically using measurement theory and Weyuker’s properties, practically using Kaner’s framework and empirically using thirty projects

Evaluating Software Complexity Based on Decision Coverage

It is becoming increasingly difficult to ignore the complexity of software products. Software metrics are proposed to help show indications for quality, size, complexity, etc. of software products. In this paper, software metrics related to complexity are developed and evaluated. A dataset of many open source projects is built to assess the value of the developed metrics. Comparisons and correlations are conducted among the different tested projects. A classifica-tion is proposed to classify software code into different levels of complexity. The results showed that measuring the complexity of software products based on decision coverage gives a significant indicator of degree of complexity of those software products. However, such in-dicator is not exclusive as there are many other complexity indicators that can be measured in software products. In addition, we conducted a comparison among several available metric tools that can collect software complexity metrics. Results among those different tools were not consistent. Such comparison shows the need to have a unified standard for measuring and collecting complexity attributes

USEFUL MEASURES OF COMPLEXITY: A MODEL OF ASSESSING DEGREE OF COMPLEXITY IN ENGINEERED SYSTEMS AND ENGINEERING PROJECTS

Many modern systems are very complex, a reality which can affect their safety and reliability of operations. Systems engineers need new ways to measure problem complexity. This research lays the groundwork for measuring the complexity of systems engineering (SE) projects. This research proposes a project complexity measurement model (PCMM) and associated methods to measure complexity. To develop the PCMM, we analyze four major types of complexity (structural complexity, temporal complexity, organizational complexity, and technological complexity) and define a set of complexity metrics. Through a survey of engineering projects, we also develop project profiles for three types of software projects typically used in the U.S. Navy to provide empirical evidence for the PCMM. The results of our work on these projects show that as a project increases in complexity, the more difficult and expensive it is for a project to meet all requirements and schedules because of changing interactions and dynamics among the project participants and stakeholders. The three projects reveal reduction of project complexity by setting a priority and a baseline in requirements and project scope, concentrating on the expected deliverable, strengthening familiarity of the systems engineering process, eliminating redundant processes, and clarifying organizational roles and decision-making processes to best serve the project teams while also streamlining on business processes and information systems.Civilian, Department of the NavyApproved for public release. Distribution is unlimited

Software Metrics and Dashboard

Software metrics are a critical tool which provide continuous insight to products and processes and help build reliable software in mission critical environments. Using software metrics we can perform calculations that help assess the effectiveness of the underlying software or process. The two types of metrics relevant to our work is complexity metrics and in-process metrics. Complexity metrics tend to focus on intrinsic code properties like code complexity. In-process metrics focus on a higher-level view of software quality, measuring information that can provide insight into the underlying software development process. Our aim is to develop and evaluate a metrics dashboard to support Computational Science and Engineering (CSE) software development projects. This task requires us to perform the following activities: Assess how metrics are used and which general classes/types of metrics will be useful in CSE projects. Develop a metrics dashboard that will work for teams using sites like Github, Bitbucket etc. Assess the effectiveness of the dashboard in terms of project success and developer attitude towards metrics and process. Our current focus is on identifying requirements for the metrics dashboard which include the types of metrics that will help understand and improve the software quality. We have also started the development on the metrics dashboard based on the currently identified metrics types. We plan to provide a reliable metrics dashboard which could be used by the CSE development teams to improve their software quality, this will be done by instrumenting the metrics dashboard to gather usage statistics. In this way the dashboard evolves continuously

Software development effort estimation using function points and simpler functional measures: a comparison

Background-Functional Size Measures are widely used for estimating the development effort of software. After the introduction of Function Points, a few "simplified"measures have been proposed, aiming to make measurement simpler and quicker, but also to make measures applicable when fully detailed software specifications are not yet available. It has been shown that, in general, software size measures expressed in Function Points do not support more accurate effort estimation with respect to simplified measures. Objective-Many practitioners believe that when considering "complex"projects, i.e., project that involve many complex transactions and data, traditional Function Points measures support more accurate estimates than simpler functional size measures that do not account for greater-Then-Average complexity. In this paper, we aim to produce evidence that confirms or disproves such belief. Method-Based on a dataset that contains both effort and size data, an empirical study is performed, to provide some evidence concerning the relations that link functional size (measured in different ways) and development effort. Results-Our analysis shows that there is no statistically significant evidence that Function Points are generally better at estimating more complex projects than simpler measures. Function Points appeared better in some specific conditions, but in those conditions they also performed worse than simpler measures when dealing with less complex projects. Conclusions-Traditional Function Points do not seem to effectively account for software complexity. To improve effort estimation, researchers should probably dedicate their effort to devise a way of measuring software complexity that can be used in effort models together with (traditional or simplified) functional size measures

Agent-based distributed performance measurement system for ITSP projects

Measuring the development of an enterprise software project progress and performance is crucial to assure a project follow its path. This attention stems in parts from the frequent reports of high profile cases of mismanaged in IT projects particularly in enterprise level such as information technology strategic planning (ITSP) projects. Many project performance measurement models and frameworks have been proposed to address the problem, however, they are usually hard to manage and inefficient in practice due to the complexity, distribution and dynamism of these types of projects. A large and growing body of literature has shown the advantages of employing the agent technology in distributed, dynamic, and complex environments. Therefore, in this study the advantages of the agent technology will be applied to improve the progress and measurement process of the software project performance measurement approaches. In this paper, a multi-agent system architectural model with the focus in implementation phase of the ITSP projects is proposed to promote and facilitate the process of project performance measurement. Furthermore the prototype of the proposed solution is explained and the evaluation approach is discussed

Functional Size Measurement Tool-based Approach for Mobile Game

Nowadays, software effort estimation plays an important role in software project management due to its extensive use in industry to monitor progress, and performance, determine overall productivity and assist in project planning. After the success of methods such as IFPUG Function Point Analysis, MarkII Function Point Analysis, and COSMIC Full Function Points, several other extension methods have been introduced to be adopted in software projects. Despite the efficiency in measuring the software cost, software effort estimation, unfortunately, is facing several issues; it requires some knowledge, effort, and a significant amount of time to conduct the measurement, thus slightly ruining the advantages of this approach. This paper demonstrates a functional size measurement tool, named UML Point tool, that utilizes the concept of IFPUG Function Point Analysis directly to Unified Modeling Language (UML) model. The tool allows the UML eXchange Format (UXF) file to decode the UML model of mobile game requirement and extract the diagrams into component complexity, object interface complexity, and sequence diagram complexity, according to the defined measurement rules. UML Point tool then automatically compute the functional size, effort, time, human resources, and total development cost of mobile game. Besides, this paper also provides a simple case study to validate the tool. The initial results proved that the tool could be useful to improve estimation accuracy for mobile game application development and found to be reliable to be applied in the mobile game industry

Using Functional Complexity Measures in Software Development Effort Estimation

Several definitions of measures that aim at representing the size of software requirements are currently available. These measures have gained a quite relevant role, since they are one of the few types of objective measures upon which effort estimation can be based. However, traditional Functional Size Measures do not take into account the amount and complexity of elaboration required, concentrating instead on the amount of data accessed or moved. This is a problem since the amount and complexity of the required data elaboration affect the implementation effort, but are not adequately represented by the current size measures, including the standardized ones. Recently, a few approaches to measuring aspects of user requirements that are supposed to be related with functional complexity and/or data elaboration have been proposed by researchers. In this paper, we take into consideration some of these proposed measures and compare them with respect to their ability to predict the development effort, especially when used in combination with measures of functional size. A few methods for estimating software development effort \u2013both based on model building and on analogy\u2013 are experimented with, using different types of functional size and elaboration complexity measures. All the most significant models obtained were based on a notion of computation density that is based on the number of computation flows in functional processes. When using estimation by analogy, considering functional complexity in the selection of analogue projects improved accuracy in all the evaluated cases. In conclusion, it appears that functional complexity is a factor that affects development effort; accordingly, whatever method is used for effort estimation, it is advisable to take functional complexity into due consideration