Is there a way to calculate modularity metric from the preexisting metrics in SonarQube? I want to calculate modularity so that I can use it for my technical debt calculation.
The Modularity of software is a composite metric. Thus, first you need to define the modularity and participating metrics. The paper you mentioned (http://arxiv.org/ftp/arxiv/papers/1309/1309.5689.pdf) offers one of the ways.
An alternative way is to detect modularity design smells and form a modularity metric formula (that uses the number of detected instances of modularity design smells). The modularity design smells are: Insufficient Modularization, Broken Modularization, Cyclically-dependent Modularization, and Hub-like Modularization (refer "Refactoring for software design smells").
Related
I know there are metrics specifically to validate ontologies, but I need something to measure the system that communicates with them. I also know ISO 9126, but I need more specific metrics, which validates, for example, how extensible or maintainable the software is to increase or change with the ontology model.
If understand your question precisely, I think you should read these papers:
Coupling metrics for ontology-based system : http://goo.gl/mhVs2G
Semantic oriented ontology cohesion metrics for ontology-based
systems : http://dl.acm.org/citation.cfm?id=1663922
Metrics for ontologies : http://goo.gl/auhFQK
Evaluating Evaluation Metrics for Ontology-Based Applications:
Infinite Reflection.
Metrics for evaluation of ontology-based information extraction
Semantic oriented ontology cohesion metrics for ontology-based
systems
May be some of the work done by one of my colleagues, Filip Radulovic, might be relevant here.
Software quality model for the evaluation of semantic technologies
Extending Software Quality Models–A Sample in The Domain of Semantic Technologies
and his other papers.
I just finished reading about techniques to detect communities. One thing which is bothering me is that is there a way or is there some network in which we can detect communities using modularity optimization method but not using link communities method ? I was able to find a network which works the other way round (link community method works, but modularity optimization doesn't ). Essentially, what is the flaw in the using links similarities to find communities and in which cases in modularity more preferable.
Thanks
The biggest flaw of the link-based methods are the time complexity which is crucial in large scale networks.
A sample of modularity optimization is the "Newman"'s fast algorithm.
It starts with each node in a separate community and in each step it merges the 2 communities which make the better growth in modularity factor.
You can use the modularity metric of your choice.
The algorithm terminates when the modularity cannot become any better.
I am looking for 3 examples of how I can use function-point measure in quality control or assurance over some other simpler measures i.e. 3 examples where function-points are preferable over some other simpler methods in quality control/assurance.
Function points are used to estimate the effort required to build an application. An alternative would be, e.g., COCOMO which is based on the number of lines of code. FP-based approaches are often considered to be preferrable to COCOMO at early stages of the project development when no clear estimate of the number of lines of code to be developed can yet be given.
Another advantage of the FP-based effort estimation is provided by availability of effort tables (e.g., in Capers Jones' books) for different kinds of applications and different kinds of activities involved in a software project. Hence, by using FPs project manager can obtain a more refined insight in the effort required.
Can anybody suggest a one/two line explanation of the "five" SonarQube categories, in such a way that a non-developer can understand what the percentage figure means?
Efficiency
Maintainability
Portability
Reliability
Usability
One word "synonym" for non-developers (not exact synonym though, but enough to give a quick idea):
Efficiency : performance
Maintainability : evolution
Portability : reuse
Reliability : resilience
Usability : design
Most of those metrics are presented in this Wikipedia entry
Efficiency:
Efficiency IT metrics measure the performance of an IT system.
An effective IT metrics program should measure many aspects of performance including throughput, speed, and availability of the system.
Maintainability
.
is the ease with which a product can be maintained in order to:
correct defects
meet new requirements
make future maintenance easier, or
cope with a changed environment
.
Portability:
the software codebase feature to be able to reuse the existing code instead of creating new code when moving software from an environment to another.
Reliability:
The IEEE defines reliability as "The ability of a system or component to perform its required functions under stated conditions for a specified period of time."
Note from this paper:
To most project and software development managers, reliability is equated to correctness, that is, they look to testing and the number of "bugs" found and fixed.
While finding and fixing bugs discovered in testing is necessary to assure reliability, a better way is to develop a robust, high quality product through all of the stages of the software lifecycle.
That is, the reliability of the delivered code is related to the quality of all of the processes and products of software development; the requirements documentation, the code, test plans, and testing.
Usability
studies the elegance and clarity with which the interaction with a computer program or a web site (web usability) is designed.
Usability differs from user satisfaction insofar as the former also embraces usefulness (see Computer user satisfaction).
See for instance usabilitymetrics.com
This represents for each category the density of violations (non-respect) of rules in the source code.
The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules.
What I want is, suggest some criteria which can be used in decomposing a system into modules.
Cohesion: the functionality in a module is related.
Low coupling: you have minimum dependencies between modules.
Coordinated lifecycle: changes to functionality within a module tends to occur at the same time. Usually a consequence of high cohesion.
I think the Single Responsibility Principle would be a good guide. Try to define responsibilities for each modules, and make each module be responsible for its own thing.
See http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Interesting reading too: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
It is a very old question.
Module is a work assignment to a programmer or group of programmers. This also is the unit of change.
Coupling and cohesion are metrics for estimation quality of relationships between modules but they are not useful for decomposition.
The decomposition should be made using "information hiding" as a criterion.
Introduction with examples and description of process based on "information hiding" principle: http://www.sqrl.ul.ie/Downloads/Lecture2.pdf.
State of art of this question is the software product line topic.