Software instability measures indicate the necessity to modify a software module (class, package, subsystem, etc) due to changes in other related software entities. If there is low instability, then there is evidence the analyzed entity has little dependence on others and the project has a good maintainability. Otherwise, there is evidence that the analyzed entity is sensitive to changes occurred in other entities. In the latter case, software reconstruction could be necessary and the maintainability becomes harder because of dependencies. Consequently, the higher the value of instability in an entity the more vulnerable it is to unexpected changes, even if the entity does not suffer direct changes in its code. This article adopts the instability definition of Martin [1] that depends on the afferent (Ca) and efferent (Ce) coupling metrics. It presents a Systematic Literature Review (SLR) of Martin's instability looking for reference values published in scientific articles and practiced in the open source market. Furthermore, this article analyzes the Martin's instability equation and the evolution of Ca, Ce and instability through new releases of 107 software. Authors applied a systematic literature review (SLR), and observed that there is a shortage of reference values in scientific articles. They performed a statistical analysis of instability measures in 107 free software products, involving three different versions of each, totaling 321 product versions. It was not possible determine or suggest a reference value to Ca, Ce and instability measures due to the high variation of those measures. It was observed that 48% of software products had high instability equal to 1, the maximum value allowed, and the instability average obtained was 0.7. Based on results of this paper, we conclude that software architects and engineers should concentrate more efforts to produce low instability software since first version, because the most of software keep the instability level through the releases. More analysis is necessary to confirm this behavior about software instability through releases.

No abstract

No abstract

No abstract

No abstract