993 research outputs found
Influence of developer factors on code quality: a data study
© 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Automatic source-code inspection tools help to assess,
monitor and improve code quality. Since these tools only
examine the software project’s codebase, they overlook other
possible factors that may impact code quality and the assessment of the technical debt (TD). Our initial hypothesis is that human factors associated with the software developers, like coding expertise, communication skills, and experience in the project have some measurable impact on the code quality. In this exploratory study, we test this hypothesis on two large open source repositories, using TD as a code quality metric and the data that may be inferred from the version control systems. The preliminary results of our statistical analysis suggest that the level of participation of the developers and their experience in the project have a positive correlation with the amount of TD
that they introduce. On the contrary, communication skills have
barely any impact on TD.Peer ReviewedPostprint (author's final draft
What to Fix? Distinguishing between design and non-design rules in automated tools
Technical debt---design shortcuts taken to optimize for delivery speed---is a
critical part of long-term software costs. Consequently, automatically
detecting technical debt is a high priority for software practitioners.
Software quality tool vendors have responded to this need by positioning their
tools to detect and manage technical debt. While these tools bundle a number of
rules, it is hard for users to understand which rules identify design issues,
as opposed to syntactic quality. This is important, since previous studies have
revealed the most significant technical debt is related to design issues. Other
research has focused on comparing these tools on open source projects, but
these comparisons have not looked at whether the rules were relevant to design.
We conducted an empirical study using a structured categorization approach, and
manually classify 466 software quality rules from three industry tools---CAST,
SonarQube, and NDepend. We found that most of these rules were easily labeled
as either not design (55%) or design (19%). The remainder (26%) resulted in
disagreements among the labelers. Our results are a first step in formalizing a
definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on
Software Architecture 2017 (Gothenburg, SE
A Quality Model for Actionable Analytics in Rapid Software Development
Background: Accessing relevant data on the product, process, and usage
perspectives of software as well as integrating and analyzing such data is
crucial for getting reliable and timely actionable insights aimed at
continuously managing software quality in Rapid Software Development (RSD). In
this context, several software analytics tools have been developed in recent
years. However, there is a lack of explainable software analytics that software
practitioners trust. Aims: We aimed at creating a quality model (called
Q-Rapids quality model) for actionable analytics in RSD, implementing it, and
evaluating its understandability and relevance. Method: We performed workshops
at four companies in order to determine relevant metrics as well as product and
process factors. We also elicited how these metrics and factors are used and
interpreted by practitioners when making decisions in RSD. We specified the
Q-Rapids quality model by comparing and integrating the results of the four
workshops. Then we implemented the Q-Rapids tool to support the usage of the
Q-Rapids quality model as well as the gathering, integration, and analysis of
the required data. Afterwards we installed the Q-Rapids tool in the four
companies and performed semi-structured interviews with eight product owners to
evaluate the understandability and relevance of the Q-Rapids quality model.
Results: The participants of the evaluation perceived the metrics as well as
the product and process factors of the Q-Rapids quality model as
understandable. Also, they considered the Q-Rapids quality model relevant for
identifying product and process deficiencies (e.g., blocking code situations).
Conclusions: By means of heterogeneous data sources, the Q-Rapids quality model
enables detecting problems that take more time to find manually and adds
transparency among the perspectives of system, process, and usage.Comment: This is an Author's Accepted Manuscript of a paper to be published by
IEEE in the 44th Euromicro Conference on Software Engineering and Advanced
Applications (SEAA) 2018. The final authenticated version will be available
onlin
Implementasi Continuous Integration dan Continuous Delivery Pada Aplikasi myITS Single Sign On
Institut Teknologi Sepuluh Nopember mempunyai infrastruktur server on-premise atau bisa disebut dengan myITS Cloud yang dikelola oleh Direktorat Pengembangan Teknologi dan Sistem Informasi. Aplikasi myITS Single Sign On merupakan aplikasi yang digunakan ITS untuk bisa berinteraksi dengan aplikasi lainnya seperti Classroom, Akademik, dan Beasiswa di myITS. Dalam pengembangan myITS SSO, proses delivery dan deployment dilakukan secara manual, dimana developer atau pengembang melakukan push ke repositori kode yang kemudian dirilis ke dalam server. Pada proses CI/CD penulis menggunakan Jenkins yang akan melakukan build aplikasi ke dalam docker image yang kemudian digunakan di dalam server menjadi sebuah kontainer. Kemudian dalam serangkaian tes yang terjadi terdapat tes untuk mendeteksi masalah kualitas kode menggunakan SonarQube. Setelah itu aplikasi akan di-deploy ke dalam Kubernetes menggunakan Helm dan Rancher. Setelah dilakukannya uji coba, Jenkins dan SonarQube bisa diimpelementasikan kepada proses CI/CD dengan cara diintegrasikan. Aplikasi juga berhasil dikemas menjadi image dengan bantuan aplikasi Docker yang kemdian diunggah ke DockerHub. Dengan berhasilnya aplikasi di¬-deploy kedalam Kubernetes dan tidak ada step pipeline yang terlewat bisa menjadi bukti bahwa implementasi CI/CD pada aplikasi myITS Single Sign On sudah berhasil
- …