• No results found

Proactive Software Complexity Assessment

N/A
N/A
Protected

Academic year: 2021

Share "Proactive Software Complexity Assessment"

Copied!
2
0
0

Loading.... (view fulltext now)

Full text

(1)

Proactive Software Complexity Assessment

Vard Antinyan

Presentation:

7th of November 2017, 13:00 Room Omega, Jupiter Building Hörselgången 5, 417 56, Gothenburg

University of Gothenburg

Main adviser: Prof. Miroslaw Staron Second advisor: Assoc. Prof. Anna Sandberg

Examiner: Prof. Jörgen Hansson

Opponent: Prof. Tracy Hall Committee:

Prof. Luigi Lavazza Prof. Dag Søberg Prof. Daniel Sundmark

(2)

Abstract

Large software development companies primarily deliver value to their customers by continuously enhancing the functionality of their products. Continuously developing software for customers insures the enduring success of a company. In continuous devel- opment, however, software complexity tends to increase gradually, the consequence being deteriorating maintainability over time. During short periods of time, the gradual complexity increase is insignificant, but over longer periods of time, complexity can de- velop to an unconceivable extent, such that maintenance is no longer profitable. Thus, proactive complexity assessment methods are required to prevent the gradual growth of complexity and instead build quality into developed software.

Many studies have been conducted to delineate methods for complexity assessment.

These focus on three main areas: 1) the landscape of complexity, i.e., the source of the complexity; 2) the options for complexity assessment, i.e., how complexity can be meas- ured and whether the results of assessment reflects reality; and 3) the practicality of using complexity assessment methods, i.e., the successful integration and use of as- sessment methods in continuous software development.

Partial successes were achieved in all three areas. Firstly, it is clear that complexity is understood in terms of its consequences, such as spent time or resources, rather than in terms of its structure per se, such as software characteristics. Consequently, current complexity measures only assess isolated aspects of complexity and fail to capture its entirety. Finally, it is also clear that existing complexity assessment methods are used for isolated activities (e.g., defect and maintainability predictions) and not for integrated decision support (e.g., continuous maintainability enhancement and defect prevention).

This thesis presents 14 new findings across these three areas. The key findings are that:

1) Complexity increases maintenance time multifold when software size is constant.

This consequential effect is mostly due to a few software characteristics, and whilst oth- er software characteristics are essential for software development, they have an insig- nificant effect on complexity growth; 2) Two methods are proposed for complexity as- sessment. The first is for source code, which represents a combination of existing com- plexity measures to indicate deteriorating areas of code. The second is for textual re- quirements, which represents new complexity measures that can indicate the inflow of poorly specified requirements; 3) Both methods were developed based on two critical factors: (i) the accuracy of assessment, and (ii) the simplicity of interpretation. The methods were integrated into practitioners’ working environments to allow proactive complexity assessment and prevention of deteriorating maintainability.

In addition, several additional key observations were made, primarily that the focus should be in creating more sophisticated software complexity measures based on empir- ical data indicative of the code characteristics that most influence complexity. It is desir- able, therefore, to integrate such complexity assessment measures into the practitioners’

working environments to ensure that complexity is assessed and managed proactively.

This would allow quality to be built into the product rather than having to conduct sepa- rate, post-release refactoring activities.

Keywords: complexity, metric, measure, code, requirement, software quality, technical risk, technical debt, continuous integration, agile development

Technical Report No 143D ISBN 978-91-982237-2-9

References

Related documents

1.) The literature review implies an objective reality about how a product may actually benefit customer‟s wellbeing – product’s actual quality. This is further

Through close cooperation with haulage firms and development over short iterations, a prototype of an Android application and a corresponding web portal for the reporting and

Configuration files and configuration switches directly in the source code provide the means to derive specific products from the product line of Sony Ericsson.. To

Through semi-structured interviews conducted with both parts, it was possible to point out the challenges faced by large scale companies and social enterprises

These increasing demands on the development process led to the development of different agile methods, proposing not only how companies should work internally within

The VSM is then sorted after classification groups. Firstly, an algorithm locates the cyclic groups of the VSM by searching for mirrored dependencies down the diagonal. The

Having the data on development processes (as described in previous paragraph) was sufficient for creating a ranking of practices with respect to the frequency of their usage.

Figure 27 presents an image of the grinding machine during one of the high temperature trials and an image of the laser scanning operating on the surface of one slab