Omission of quality software development practices : a systematic literature review

Software deficiencies are minimized by utilizing recommended software development and quality assurance practices. However, these recommended practices (i.e., quality practices) become ineffective if software professionals purposefully ignore them. Conducting a systematic literature review (n = 4,838), we discovered that only a small number of previous studies, within software engineering and information systems literature, have investigated the omission of quality practices. These studies explain the omission of quality practices mainly as a result of organizational decisions and trade-offs made under resource constraints or market pressure. However, our study indicates that different aspects of this phenomenon deserve further research. In particular, future research must investigate the conditions triggering the omission of quality practices and the processes through which this phenomenon occurs. Especially, since software development is a human-centric phenomenon, the psychological and behavioral aspects of this process deserve in-depth empirical investigation. In addition, futures research must clarify the social, organizational, and economical consequences of ignoring quality practices. Gaining in-depth theoretically sound and empirically grounded understandings about different aspects of this phenomenon enables research and practice to suggest interventions to overcome this issue.fi=vertaisarvioitu|en=peerReviewed

Implementing Scrum Wholesale in the Classroom

As the most widely used agile software development method, Scrum has become a mainstay in many organizations that develop software. Despite Scrum’s popularity, several studies examine Scrum implementations that include some parts of the methodology and exclude others. This paper describes how Scrum has been incorporated into the classroom wholesale and highlights important considerations when using Scrum for student software development projects. Students having little to no knowledge of Scrum were able to gain confidence in using the method in a real-world setting. The paper discusses the use of a hands-on Scrum project as a pedagogical tool for teaching the Scrum methodology and software development life cycle principles. Quantitative and qualitative data were collected to understand student experiences with a wholesale Scrum implementation in the classroom. The paper concludes with data analysis and recommendations for implementing Scrum in future projects

Exploring aspects of agile software development risk – results from a MLR

Agile software development methods are widely used by software organisations, focusing on short developmental life cycles and customer satisfaction through the iterative and incremental development of software products. Despite their popularity, these methods present risks that may be underappreciated. This paper examines certain risks attributed to agile software development, with a focus on the lack of documentation, scope creep, technical debt and job satisfaction. Through the application of a multivocal literature review, we find that agile software development can greatly benefit projects. However, when agile methods are implemented inappropriately or sub-optimally, projects risk over-spending, delayed or defective software, employee turnover, and overall decreased productivity. Understanding the risks associated with agile software development can help practitioners to achieve higher efficiency and success in their software development projects

Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. We found five research areas of interest related to the literature of TD in ASD. Among those areas, managing TD in ASD received the highest attention, followed by architecture in ASD and its relationship with TD. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. Focus on quick delivery and architectural and design issues were the most popular causes of incurring TD in ASD. Reduced productivity, system degradation and increased maintenance cost were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which refactoring and enhancing the visibility of TD were the most significant. The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation

Technical Debt in Software Development : Examining Premises and Overcoming Implementation for Efficient Management

Software development is a unique field of engineering: all software constructs retain their modifiability — arguably, at least — until client release, no single project stakeholder has exhaustive knowledge about the project, and even this portion of the knowledge is generally acquired only at project completion. These characteristics imply that the field of software development is subject to design decisions that are known to be sub-optimal—either deliberately emphasizing interests of particular stakeholders or indeliberately harming the project due to lack of exhaustive knowledge. Technical debt is a concept that accounts for these decisions and their effects. The concept’s intention is to capture, track, and manage the decisions and their products: the affected software constructs. Reviewing the previous, it is vital for software development projects to acknowledge technical debt both as an enabler and as a hindrance. This thesis looks into facilitating efficient technical debt management for varying software development projects. In the thesis, examination of technical debt’s role in software development produces the premises on to which a management implementation approach is introduced. The thesis begins with a revision of motivations. Basing on prior research in the fields of technical debt management and software engineering in general, the five motivations establish the premises for technical debt in software development. These include notions of subjectivity in technical debt estimation, update frequency demands posed on technical debt information, and technical debt’s polymorphism. Three research questions are derived from the motivations. They ask for tooling support for technical debt management, capturing and modelling technical debt propagation, and characterizing software development environments and their technical debt instances. The questions imply consecutive completion as the first pursued tool would benefit from—possibly automatically assessable—propagation models, and finally the tool’s introduction to software development organizations could be assisted by tailoring it based on the software development environment and the technical debt instance characterizations. The thesis has seven included publications. In introducing them, the thesis maps their backgrounds to the motivations and their outcomes to the research questions. Amongst the outcomes are the DebtFlag tool for technical debt management, the procedures for retrospectively capturing technical debt from software repositories, a procedure for technical debt propagation model creation from these retrospectives, and a multi-national survey characterizing software development environments and their technical debt instances. The thesis concludes that the tooling support, the technical debt propagation modelling, and the software environment and technical debt instance characterization describe an implementation approach to further efficient technical debt management. Simultaneously, future work is implied as all previously described efforts need to be continued and extended. Challenges also remain in the introduced approach. An example of this is the combinatorial explosion of technology-development-context-combinations that technical debt propagation modelling needs to consider. All combinations have to be managed if exhaustive modelling is desired. There is, however, a great deal of motivation to pursue these efforts when one re-notes that technical debt is a permanent component of software development that, when correctly managed, is a development efficiency mechanism comparable to a financial loan investment.Ohjelmistokehitys on uniikki tekniikan ala: kaikki ohjelmistorakenteet säilyttävät muokattavuutensa — otaksuttavasti ainakin — asiakasjulkaisuun asti. Yhdenkään projektiosakkaan tietämys ei kata koko projektia ja merkittävä osa tästäkin tiedosta karttuu vasta projektin suorittamisen aikana. Nämä ominaisuudet antavat ymmärtää, että ohjelmistokehitysala on sellaisten suunnitelupäätösten kohde, joiden tiedetään olevan epätäydellisiä—joko tarkoituksella tiettyjen projektiosakkaiden intressejä painottavia tai tahattomasti projektia vahingoittavia puutteelliseen tietoon perustuvia. Tekninen velka on konsepti, joka huomioi nämä päätökset sekä niiden vaikutukset. Konseptin tarkoitus on havaita, seurata ja hallita näitä päätöksiä sekä tuloksena syntyviä teknisen velan vaikutuksen alla olevia ohjelmistorakenteita. Edellisen kuvauksen valossa ohjelmistokehitysprojekteille on erityisen tärkeää huomioida tekninen velka sekä mahdollistajana että hidasteena. Tämän vuoksi kyseinen väitöskirja perehtyy tehokkaan teknisen velan hallinnan fasilitointiin moninaisille ohjelmistokehitysprojekteille. Väitöskirjassa tarkastellaan teknisen velan roolia osana ohjelmistokehitystä. Tarkastelu tuottaa joukon premissejä, joihin perustuen esitellään lähestymistapa teknisen velan hallinnan toteuttamiselle. Viisi väitöskirjan alussa esitettyä motivaatiota kiinnittävät ne premissit,joille ratkaisu esitetään. Motivaatiot rakennetaan olemassa olevaan teknisen velan sekä ohjelmistotekniikan tutkimustietoon perustuen. Näihin lukeutuvat muun muassa subjektiivisuus teknisen velan estimoinnissa, teknisen velan informaatiolle nähdyt päivitystaajuusvaatimukset sekä teknisen velan polymorfismi. Havainnoista johdetaan kolme tutkimuskysymystä. Ne tavoittelevat työkalutukea teknisen velan hallinnalle, velan propagoitumisen havainnointia sekä mallinnusta kuin myös ohjelmistotuotantoympäristöjen ja niiden velka instanssien kuvaamista. Tutkimuskysymykset implikoivat peräkkäistä suoritusta: tavoiteltu työkalu hyötyy—mahdollisesti automaattisesti arvoitavista—teknisen velan propagaatiomalleista. Valmiin työkalun käyttöönottoa voidaan taas edistää jos kuvaukset kehitysympäristöistä sekä niiden velkainstansseista ovat käytettävissä työkalun räätälöintiin. Väitöskirjaaan sisältyy seitsemän julkaisua. Väitöskirja esittelee ne kiinnittämällä julkaisujen taustatyön aikaisemmin mainittuihin motivaatioihin sekä niiden tulokset edellisiin tutkimuskysymyksiin. Tuloksista huomioidaan esimerkiksi DebtFlag-työkalu teknisen velan hallintaan, retrospektiivinen prosessi teknisen velan kartoittamiselle versionhallintajärjestelmistä, prosessi teknisen velan mallien rakentamiselle näistä kartoituksista ja monikansallinen kyselytutkimus ohjelmistokehitysympäristöjen sekä näiden teknisen velan instanssien luonnehtimiseksi. Väitöskirjan yhteenvetona huomioidaan, että teknisen velan hallinnan työkalutuki, teknisen velan propagaatiomallinnus ja ohjelmistokehitysympäristöjen sekä niiden teknisen velan instanssien luonnehdinta muodostavat toteutustavan, jolla teknisen velan tehokasta hallintaa voidaan kehittää. Samalla implikoidaan jatkotoimia, sillä kaikkia edellä kuvattuja työn osia tulee jatkaa ja laajentaa. Toteutustavalle nähdään myös haasteita. Eräs näistä on kombinatorinen räjähdys teknologia- ja kehityskontekstikombinaatioille. Kaikki kombinaatiot tulee huomioida mikäli teknisen velan propagaatiomallinnuksesta halutaan kattavaa. Motivaatio väitöskirjassa esitetyn työn jatkamiselle on huomattavaa ja sitä kasvattaa entuudestaan edellä tehty huomio siitä, että tekninen velka on pysyvä komponentti ohjelmistokehityksessä, joka oikein hallittuna on kehitystehokkuutta edistävänä komponenttina verrattavissa finanssialan lainainvestointiin.Siirretty Doriast

Technical debt in modern software development

Ohjelmistokehityksen nopeus ja luonne ovat muuttuneet paljon sitten vesiputousmallin. Moderni ohjelmistotyö on nopeatempoista ja se pyrkii vastaamaan jatkuviin toimintaympäristön muutoksiin. Modernissa ohjelmistotyössä painotetaan muun muassa kehitystyön edistämistä kaiken kattavien suunnitelmien laatimisen sijaan. Modernin ohjelmistotyön toimintakulttuurissa pyritään ylipäänsä ketteryyteen ja joustavuuteen. Kasvanut ohjelmistotuotantonopeus ja ohjelmistokehityskulttuurin muutos voivat kuitenkin altistaa kehitettävän ohjelmiston teknisen velan synnylle. Teknisellä velalla tarkoitetaan ohjelmiston lähdekoodissa esiintyviä, ohjelmointityön seurauksena syntyviä virheitä, jotka vaikeuttavat ohjelmiston jatkokehitystä ja tekevät lähdekoodin tulkinnasta vaikeampaa. Runsaasti teknistä velkaa sisältävää koodia on hidas jatkokehittää. Teknistä velkaa voi syntyä esimerkiksi aikataulupaineiden takia ja tekninen velka tulisikin ottaa huomioon modernissa ohjelmistotyössä. Tässä diplomityössä on tutkittu miten tekninen velka esiintyy ja miten se kehittyy modernissa ohjelmistotyössä. Työn tutkimusosassa on tutkittu kahta nykyaikaisin ohjelmistokehitysmenetelmin toteutettua ohjelmistoa: Vaadin Framework 7 ja Yle Areena. Tutkimuksessa analysoitiin molempien ohjelmistojen koodipohjien kehitystä SonarQubella. SonarQube on staattinen koodin analysointityökalu, joka tuottaa sille syötetystä koodista tietoa koskien muun muassa teknistä velkaa, ohjelmointivirheitä ja haavoittuvuuksia. Työn tuloksissa käsitellään muun muassa teknisen velan kehittymistä ohjelmistoissa pitkällä aikavälillä. Tuloksissa havaittiin, että tekninen velka kasvaa samassa suhteessa lähdekoodin määrän kanssa, mikäli siihen ei kiinnitetä huomioita. Kuitenkin jo vähäiset toimenpiteet lähdekoodin laadun ja siisteyden ylläpitämiseksi auttavat myös teknisen velan hallinnassa, vaikka toimenpiteiden tarkoitus ei alunperin olisikaan torjua nimenomaan teknistä velkaa. Yleisimmät teknisen velan lähteet liittyvät muun muassa perinnekoodiin, ohjelmointityyliin ja literaalien käyttöön vakioiden sijaan. Tuloksissa esiintyy jonkin verran ''kouluesimerkkivirheitä'' esimerkiksi liukulukujen välillä tapahtuvasta vertailusta yhtäsuuruusoperaattorilla tai geneeristen poikkeuksien käyttämistä erikoistettujen sijaan

Technical Debt: An empirical investigation of its harmfulness and on management strategies in industry

Background: In order to survive in today\u27s fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process.Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today’s software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives.Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity.Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer’s working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD.Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial\ua0effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD