3 research outputs found

    A Source-Code Maintainability Evaluation Model for Software Products

    Get PDF
    The maintainability index (MI) has been proposed to calculate a single number which expresses the maintainability of a system. This article presents a model for evaluating the maintainability of software products. The model improves the shortcomings observed in the maintainability assessment approaches in the quality assessment models SQuaRE (ISO25000), ISO 9126, Squale and the FCM standard. Its main innovation is to take into account the importance of entities in the system when calculating the maintainability score. This implies that the same type of defect will have a different score depending on the entity presenting it. Seven experts with several years of experience evaluated the model. They confirmed the effectiveness and usability of the model. Then, we compared our model with the Squale maintainability index and the classical maintainability index. The results show no correlation between these models. The implications are that each method gives a slightly different view of maintainability

    Identifying the exact fixing actions of static rule violation

    Get PDF
    International audience—We study good programming practices expressed in rules and detected by static analysis checkers such as PMD or FindBugs. To understand how violations to these rules are corrected and whether this can be automated, we need to identify in the source code where they appear and how they were fixed. This presents some similarities with research on understanding software bugs, their causes, their fixes, and how they could be avoided. The traditional method to identify how a bug or a rule violation were fixed consists in finding the commit that contains this fix and identifying what was changed in this commit. If the commit is small, all the lines changed are ascribed to the fixing of the rule violation or the bug. However, commits are not always atomic, and several fixes and even enhancements can be mixed in a single one (a large commit). In this case, it is impossible to detect which modifications contribute to which fix. In this paper, we are proposing a method that identifies precisely the modifications that are related to the correction of a rule violation. The same method could be applied to bug fixes, providing there is a test illustrating this bug. We validate our solution on a real world system and actual rules

    Towards Automation of the FORM/BCS Method

    Get PDF
    The software industry is facing more complex computer systems, with short development and sustainability issues. To deliver good software with these constraints, software reuse has become a central concept for minimizing design and realization costs. This study improves upon Feature-Oriented Reuse Method with Business Component Semantics (FORM/BCS), a software development method that produces adaptable architectures from reusable domain components. This is a promising method for reusable software assets and model creation. The objective of the FORM/BCS is to bring the industrial production chain to the software. This study proposes a model to automatically transform the FORM/BCS business subsystem component into a process business component. Two metamodels for business subsystems and process business components were developed. In addition, this study establishes correspondences between the source metamodel and target metamodel classes, transformation rules, and the instance of the source metamodel and generates the target metamodel instance. Detailed findings can help practitioners reduce software design costs and development time, and contribute to the advancement of knowledge in software engineering
    corecore