Ohjelmistokehityssyklien kiihdytys osana julkaisutiheyden kasvattamista ohjelmistotuotannossa

In recent years, companies engaged in software development have taken into use practices that allow the companies to release software changes almost daily to their users. Previously, release frequency for software has been counted in months or even years so the leap to daily releases can be considered big. The underlying change to software development practices is equally large, spanning from individual development teams to organizations as a whole. The phenomenon has been framed as continuous software engineering by the software engineering research community. Researchers are beginning to realize the impact of continuous software engineering to existing disciplines in the field. Continuous software engineering can be seen to touch almost every aspect of software development from the inception of an idea to its eventual manifestation as a release to the public. Release management or release engineering has become an art in itself that must be mastered in order to be effective in releasing changes rapidly. Empirical studies in the area should be helpful in further exploring the industry-driven phenomenon and understanding the effects of continuous software engineering better. The purpose of this thesis is to provide insight into the habit of releasing software changes often that is promoted by continuous software engineering. There are three main themes in the thesis. A main theme in the thesis is seeking an answer to the rationale of frequent releases. The second theme focuses on charting the software processes and practices that need to be in place when releasing changes frequently. Organizational circumstances surrounding the adoption of frequent releases and related practices are highlighted in the third theme. Methodologically, this thesis builds on a set of case studies. Focusing on software development practices of Finnish industrial companies, the thesis data has been collected from 33 different cases using a multiple-case design. Semi-structured interviews were used for data collection along with a single survey. Respondents for the interviews included developers, architects and other people involved in software development. Thematic analysis was the primary qualitative approach used to analyze the interview responses. Survey data from the single survey was analyzed with quantitative analysis. Results of the thesis indicate that a higher release frequency makes sense in many cases but there are constraints in selected domains. Daily releases were reported to be rare in the case projects. In most cases, there was a significant difference between the capability to deploy changes and the actual release cycle. A strong positive correlation was found between delivery capability and a high degree of task automation. Respondents perceived that with frequent releases, users get changes faster, the rate of feedback cycles is increased, and product quality can improve. Breaking down the software development process to four quadrants of requirements, development, testing, and operations and infrastructure, the results suggest continuity is required in all four to support frequent releases. In the case companies, the supporting development practices were usually in place but specific types of testing and the facilities for deploying the changes effortlessly were not. Realigning processes and practices accordingly needs strong organizational support. The responses imply that the organizational culture, division of labor, employee training, and customer relationships all need attention. With the right processes and the right organizational framework, frequent releases are indeed possible in specific domains and environments. In the end, release practices need to be considered individually in each case by weighing the associated risks and benefits. At best, users get to enjoy enhancements quicker and to experience an increase in the perceived value of software sooner than would otherwise be possible.Ohjelmiston julkaisu on eräänlainen virstanpylväs ohjelmiston kehityksessä, jossa ohjelmiston uusi versio saatetaan loppukäyttäjille käyttöön. Julkaistu versio voi sisältää ohjelmistoon uusia toiminnallisuuksia, korjauksia tai muita päivityksiä. Ohjelmiston julkaisutiheys säätelee kuinka tiheästi uusia versioita julkaistaan käyttäjille. Ohjelmistojen julkaisutiheys voi vaihdella sovelluksesta ja toimintaympäristöstä riippuen. Kuukausien tai vuosien pituinen julkaisuväli ei ole alalla tavaton. Viime vuosina tietyt ohjelmistoalalla toimivat yritykset ovat ottaneet käyttöön jatkuvan julkaisemisen malleja, joilla pyritään lyhentämään julkaisuvälejä kuukausista aina viikkoihin tai päiviin. Jatkuvan julkaisemisen mallien käyttöönotolla on merkittäviä vaikutuksia niin ohjelmistokehitysmenetelmiin kuin työn sisäiseen organisointiin. Jatkuvan julkaisun mallien myötä julkaisunhallinnasta on tullut keskeinen osa ohjelmistokehitystä. Väitöstyössä käsitellään julkaisutiheyden kasvattamiseen liittyviä kysymyksiä kolmen eri teeman alla. Työn ensimmäinen teema keskittyy julkaisutiheyden kasvattamisen tarkoitusperien ymmärtämiseen. Toisessa teemassa suurennuslasin alla ovat ohjelmistokehityksen käytänteet, jotka edesauttavat siirtymistä kohti jatkuvaa julkaisua. Kolmannessa teemassa huomion kohteena ovat työn organisointiin ja työkulttuurin muutokseen liittyvät seikat siirryttäessä jatkuvaan julkaisuun. Väitöstyössä esitettyihin kysymyksiin on haettu vastauksia tapaustukimusten avulla. Tapaustutkimusten kohteena ovat olleet suomalaiset ohjelmistoalan yritykset. Tietoja on kerätty haastattelu- ja kyselytutkimuksin yli kolmestakymmennestä tapauksesta. Tutkimusten tulosten perusteella julkaisutiheyden kasvattamiselle on edellytyksiä monessa ympäristössä, mutta kaikille toimialoille se ei sovellu. Yleisesti ottaen tiheät julkaisut olivat harvinaisia. Monessa tapauksessa havaittiin merkittävä ero julkaisukyvykkyyden ja varsinaisen julkaisutiheyden välillä. Julkaisukyvykkyys oli sitä parempi, mitä pidemmälle sovelluskehityksen vaiheet olivat automatisoitu. Jatkuvan julkaisun käyttöönotto edellyttää vahvaa muutosjohtamista, työntekijöiden kouluttamista, organisaatiokulttuurin uudistamista sekä asiakassuhteiden hyvää hallintaa. Parhaassa tapauksessa tiheät julkaisut nopeuttavat niin muutosten toimittamista käyttäjille kuin palautesyklejä sekä johtavat välillisesti parempaan tuotelaatuun

Driving Software Quality and Structuring Work Through Test-Driven Development

Test-driven development is a software development method where programmers compose program code by first implementing a set of small-scale tests which help in the design of the system and in the verification of associated code sections. The reversed design and implementation process is unique: traditionally there is no attempt to verify program code that does not yet exist. Applying practices of test-driven design to a software development process-a generally complex activity involving distinct individuals working in an organization-might have an impact not only on the process itself but on the outcome of the process as well. In order to assess whether test-driven development has perceivable effects on elements of software development, a qualitative literature survey, based on empirical studies and experiments in the industry and academia, was performed. The aggregated results extracted from the studies and experiments on eleven different internal and external process, product and resource quality attributes indicate that there are positive, neutral and negative effects. Empirical evidence from the industry implies that test-driven development has a positive, reducing, effect on the number of defects detected in a program. There is also a chance that the code products are smaller, simpler and less complex than equivalent code products implemented without test-driven practices. While additional research is needed, it would seem that the test-driven produced code is easier for the developers to maintain later, too; on average, maintenance duties took less time and the developers felt more comfortable with the code. The effects on product attributes of coupling and cohesion, which describe the relationships between program code components, are neutral. Increased quality occasionally results in better impressions of the product when the test-driven conform better to the end-user tests but there are times when end-users cannot discern the differences in quality between products made with different development methods. The small, unit-level, tests written by the developers increase the overall size of code products since most of the program code statements are covered by the tests if a test-driven process is followed. Writing tests takes time and the negative effects are associated with the effort required in the process. Industrial case studies see negative implications to productivity due to the extra effort but student experiments have not always been able to replicate similar results under controlled conditions

Revisiting Continuous Deployment Maturity : A Two-Year Perspective

Background: Achieving a steady stream of small releases and employing practices such as continuous deployment requires maturity in company processes. Maturity models provide one approach for companies to pinpoint areas of improvement by providing a position and hints to reflect on. Incorporating maturity models with agile software development and continuous deployment has its challenges, though. Aims: The focus of the study is in understanding the evolution of software processes towards continuous deployment in an industry organization over time when a maturity model is used as a yardstick in evaluation. Method: An embedded case study by design, the study utilizes and replicates a survey on the state of software projects in a large Finnish software company, Solita. The survey was initially conducted in 2015 with responses from 35 projects and now replicated in 2017 with responses from 43 projects. Both quantitative and qualitative approaches for survey responses are used in the analysis. Results: Maturity of software processes in the case company show improvement in deployment and in monitoring, albeit short of statistical significance. Technological advances in the application of cloud computing have likely spurred development in these areas. Capability in processes related to test automation and quality has not changed much in two years. Conclusions: Maintaining maturity in software processes requires constant attention as impressions on process quality can gradually diminish. Projects which are built on a compatible technology stack have a greater chance in achieving continuous deployment and thus being more mature. Customer preferences also make a difference in the ability to reach certain maturity levels.Peer reviewe

Unwasted DASE : Lean Architecture Evaluation

A software architecture evaluation is a way to assess the quality of the technical design of a product. It is also a prime opportunity to discuss the business goals of the product and how the design bears on them. But architecture evaluation methods are seen as hard to learn and costly to use. We present DASE, a compact approach that combines carefully selected key parts of two existing architecture evaluation methods while making evaluation lean and fast. We have applied DASE in three industrial cases and the early results show that even a one-day evaluation workshop yields valuable results at a modest cost.A software architecture evaluation is a way to assess the quality of the technical design of a product. It is also a prime opportunity to discuss the business goals of the product and how the design bears on them. But architecture evaluation methods are seen as hard to learn and costly to use. We present DASE, a compact approach that combines carefully selected key parts of two existing architecture evaluation methods while making evaluation lean and fast. We have applied DASE in three industrial cases and the early results show that even a one-day evaluation workshop yields valuable results at a modest cost.A software architecture evaluation is a way to assess the quality of the technical design of a product. It is also a prime opportunity to discuss the business goals of the product and how the design bears on them. But architecture evaluation methods are seen as hard to learn and costly to use. We present DASE, a compact approach that combines carefully selected key parts of two existing architecture evaluation methods while making evaluation lean and fast. We have applied DASE in three industrial cases and the early results show that even a one-day evaluation workshop yields valuable results at a modest cost.Peer reviewe

Tiedon käyttö palvelujärjestelmän arvioinnissa : THL:n arviointitoiminto ja Tietoikkuna

Työpaperissa tarkastellaan THL:n sote-arviointiyksikössä tehtävää palvelujärjestelmän arviointitoimintaa ja sen indikaattoreista muodostuvaa tietopohjaa. Lisäksi tarkastellaan verkkopalvelu Tietoikkunaa, joka tukee tietopohjan ajantasaisuutta, avoimuutta ja hyödynnettävyyttä

Ammattitaudit ja ammattitautiepäilyt 2012 : Työperäisten sairauksien rekisteriin kirjatut uudet tapaukset

Työterveyslaitoksen Työperäisten sairauksien rekisteriin (TPSR) on vuodesta 1964 lähtien kerätty tietoa ammattitautien, ammattitautiepäilyjen ja eräinä työtapaturmina korvattavien vammojen vuoksi lääkäreiden tutkimuksissa olleista potilaista. Tapaturmavakuutuslaitosten liitto (TVL) ja Maatalousyrittäjien eläkelaitos (MELA) toimittavat ammattitauteja ja ammattitautiepäilyjä koskevat tiedot Työterveyslaitokseen. Lääkäreiden työsuojeluviranomaiselle toimittamia tietoja käytetään näiden tietojen täydentämiseen etenkin hengitystieallergioissa ja ihotaudeissa. Ammattitautien ja ammattitautiepäilyjen kokonaismäärien lisäksi julkaisussa on erikseen vakuutuslaitosten ammattitauteina vahvistamat sairaudet

Metalli-metalli liukupintaisten lonkan varrellisten ja pinnoite-tekonivelten luksaatiot

English abstrac

Occupational diseases in Finland in 2012 :New cases of recognized and suspected occupational diseases

This publication presents a statistical summary of recognized and suspected occupational diseases in Finland. The first part of the publication is a review, which aims to give an overall picture of the incidence of occupational diseases in 2012, and of he main trends in recent years. The second part conists of statistical tables, which describe in greater detail the occurrence of occupational diseases in Finland in 2012

Continuous Experimentation Cookbook : An introduction to systematic experimentation for software-intensive businesses

An increasing number of companies are involved in building software-intensive products and services – hence the popular slogan “every business is a software business”. Software allows companies to disrupt existing markets because of its flexibility. This creates highly dynamic and competitive environments, imposing high risks to businesses. One risk is that the product or service is of only little or no value to customers, meaning the effort to develop it is wasted. In order to reduce such risks, you can adopt an experimentdriven development approach where you validate your product ideas before spending resources on fully developing them. Experiments allow you to test assumptions about what customers really want and react if the assumptions are wrong. This book provides an introduction to continuous experimentation, which is a systematic way to continuously test your product or service value and whether your business strategy is working. With real case examples from Ericsson, Solita, Vaadin, and Bittium, the book not only gives you the concepts needed to start performing continuous experimentation, but also shows you how others have been doing it

Risk factors for intraoperative calcar fracture in cementless total hip arthroplasty

Background and purpose - Intraoperative periprosthetic femoral fracture is a known complication of cementless total hip arthroplasty (THA). We determined the incidence of-and risk factors for-intraoperative calcar fracture, and assessed its influence on the risk of revision. Patients and methods - This retrospective analysis included 3,207 cementless THAs (in 2,913 patients). 118 intraoperative calcar fractures were observed in these hips (3.7%). A control group of 118 patients/hips without calcar fractures was randomly selected. The mean follow-up was 4.2 (1.8-8.0) years. Demographic data, surgical data, type of implant, and proximal femur morphology were evaluated to determine risk factors for intraoperative calcar fracture. Results - The revision rates in the calcar fracture group and the control group were 10% (95% CI: 5.9-17) and 3.4% (CI: 1.3-8.4), respectively. The revision rate directly related to intraoperative calcar fracture was 7.6%. The Hardinge approach and lower age were risk factors for calcar fracture. In the fracture group, 55 of 118 patients (47%) had at least one risk factor, while only 23 of118 patients in the control group (20%) had a risk factor (p = 0.001). Radiological analysis showed that in the calcar fracture group, there were more deviated femoral anatomies and proximal femur bone cortices were thinner. Interpretation - Intraoperative calcar fracture increased the risk of revision. The Hardinge approach and lower age were risk factors for intraoperative calcar fracture. To avoid intraoperative fractures, special attention should be paid when cementless stems are used with deviant-shaped proximal femurs and with thin cortices.Peer reviewe