Continuous software engineering is a rapidly growing discipline in software engineering. Among its many reported benefits is increased development velocity, faster feedback for developers, and better software quality. It also comes with its own share of challenges, most of which are centered on making automated builds more efficient or detecting problems with build configuration. However, the majority of literature in this area does not take into account software developers, which are arguably the cornerstone of software development. Software development is still a human-driven endeavour. It is a developer who writes the code, tests it, makes the final decision while factoring in the build results, and so on. Furthermore, software development does not happen in a vacuum. Development takes place within the context of practices dictating how it should be done, and perceived benefits that drive practice adoption and implementation. Software development, and by extension continuous software development, is a socio-technical endeavour that features interactions between human aspects (developers, testers, etc.), technical aspects (automation), and environmental aspects (process, project-specific characteristics, infrastructure, etc.). While the software engineering field has its share of theories, frameworks, and models, or borrows them from other fields, we still do not have a human-centric framework for software engineering that takes into account other socio-technical aspects (technical and environmental). My dissertation addresses this need for a socio-technical framework by illustrating a series of studies that ultimately resulted in the creation of a socio-technical theory of continuous software engineering that focuses on phenomena involving both humans and automation. In particular, I focus on the role of continuous software engineering tools (automation) in the software development process and how they displace existing tools, disrupt existing workflows, and feature in software developer decision making. This theory will enable further research in this area as well as allow researchers to make more grounded recommendations for industrial applications. / Graduate

The full enforcement of the General Data Protection Regulation (GDPR) that began on May 25, 2018 forced any organization that collects and/or processes personal data from European Union citizens to comply with a series of stringent and comprehensive privacy regulations. Many software organizations struggled to comply with the entirety of the GDPR's regulations both leading up and even after the GDPR deadline. Previous studies on the subject of the GDPR have primarily focused on finding implications for users and organizations using surveys or interviews. However, there is a dearth of in-depth studies that investigate compliance practices and compliance challenges in software organizations. In particular, small and medium enterprises are often neglected in these previous studies, despite small and medium enterprises representing the majority of organizations in the EU. Furthermore, organizations that practice continuous integration have largely been ignored in studies on GDPR compliance. Using design science methodology, we conducted an in-depth study over the span of 20 months regarding GDPR compliance practices and challenges in collaboration with a small, startup organization. Our first step helped identify our collaborator's business problems. Subsequently, we iteratively developed two artifacts to address those business problems: a set of privacy requirements operationalized from GDPR principles, and an automated GDPR tool that tests these GDPR-derived privacy requirements. This design science approach resulted in five implications for research and for practice about ongoing challenges to compliance. For instance, our research reveals that GDPR regulations can be partially operationalized and tested through automated means, which is advantageous for achieving long term compliance. In contrast, more research is needed to create more efficient and effective means to disseminate and manage GDPR knowledge among software developers. / Graduate

Building a shared understanding of non-functional requirements (NFRs) is a known but understudied challenge in requirements engineering, primarily in organizations that adopt continuous software engineering (CSE) practices. During the peak of the COVID-19 pandemic, many CSE organizations complied with working remotely due to the imposed health restrictions; some continued with remote work while implementing business processes to facilitate team communication and productivity. In remote CSE organizations, managing NFRs becomes more challenging due to the limitations to team communication coupled with the incentive to deliver products quickly. While previous research has identified the factors that lead to a lack of shared understanding of NFRs in CSE, we still have a significant gap in understanding how CSE organizations, particularly in remote work, build a shared understanding of NFRs in their software development. This thesis presents a study that explores how a remote CSE organization builds a shared understanding of NFRs. We conducted a six-month case study of a remote CSE organization using ethnography-informed methods and methods from grounded theory. Through thematic analysis of our qualitative data from interviews and observations, we identify some practices in building a shared understanding of NFRs, such as validating NFRs through feedback. In addition, we identified some of the impediments to building a shared understanding of NFRs in the organization, such as gaps in communication and the limited understanding of customer context. Furthermore, we conducted member-checking interviews to validate our findings for relevance and to gain additional insights on the shared understanding of NFRs within the organization. The collaborative workspace the organization uses for remote interaction is Gather, which simulates physical workspaces, and which our findings suggest allows for informal communications instrumental for building shared understanding. As actionable insights, we discuss our findings in light of proactive practices that represent opportunities for software organizations to invest in building a shared understanding of NFRs in their development. / Graduate

Submitted by Geandra Rodrigues (geandrar@gmail.com) on 2018-07-20T12:18:30Z No. of bitstreams: 1 camilaacaciodepaiva.pdf: 9167548 bytes, checksum: 23bc00520b1453f40c0c4c739227c90b (MD5) / Approved for entry into archive by Adriana Oliveira (adriana.oliveira@ufjf.edu.br) on 2018-07-23T15:21:00Z (GMT) No. of bitstreams: 1 camilaacaciodepaiva.pdf: 9167548 bytes, checksum: 23bc00520b1453f40c0c4c739227c90b (MD5) / Made available in DSpace on 2018-07-23T15:21:00Z (GMT). No. of bitstreams: 1 camilaacaciodepaiva.pdf: 9167548 bytes, checksum: 23bc00520b1453f40c0c4c739227c90b (MD5) Previous issue date: 2018-06-27 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / O software está cada vez mais presente no cotidiano das pessoas. Vários setores ou aspectos do ambiente são influenciados por ele. Desta forma, o desenvolvimento de software torna-se uma atividade crítica. Assim, o processo de teste se torna crucialmente importante, pois qualquer negligência pode refletir na qualidade do produto. Contudo, o cenário de desenvolvimento de software vem sofrendo mudanças a partir da necessidade de suprir demandas com maior agilidade e as exigências do mercado. É fundamental haver uma visão holística dos processos de desenvolvimento do software com o objetivo de gerar um ciclo de melhoria contínua. Tal visão é denominada como Engenharia de Software Contínua. A Engenharia de Software Contínua é caracterizada pelo uso do feedback de execuções para alcançar uma melhoria contínua e pela realização das atividades de maneira contínua. Feedback esse que pode ser fornecido através da proveniência de dados: descrição das origens de um dado e os processos pelos quais passou. Diante disso, este trabalho apresenta uma infraestrutura que tem como foco a captura e o armazenamento do histórico dos dados de execução do projeto, a previsão dos resultados dos testes de unidade através de algoritmos de previsão Logistic Regression, Naive Bayes e C4.5 Algorithm, e a disponibilização dos dados para aplicações externas. Além disso, oferece elementos de visualização que auxiliam na compreensão dos dados. Um experimento com dados de um projeto real foi realizado com o intuito de identificar a acurácia das previsões. / Software is increasingly present in people's daily lives. Various sectors and the environment are influenced by them. In this way, the development of software becomes a critical activity. Thus, the testing process becomes crucially important because any negligence can affect the quality of the product and the insecurity related to the use of the software. However, the software development scenario has undergone changes from the need to meet demands with greater agility and the demands of the market. It is fundamental to have a holistic view of the software development processes in order to generate a cycle of continuous improvement. Such a view is referred to as Continuous Software Engineering. Continuous Software Engineering is characterized by the use of feedback from executions to achieve continuous improvement and by performing activities on an ongoing basis. Feedback this can be provided through the provenance of data: description of the origins of a given and the processes by which it passed. This work presents an infrastructure that focuses on the capture and storage of the project execution data history, the prediction of the results of the unit tests through prediction algorithms: Logistic Regression, Naive Bayes and C4.5 Algorithm, and the provision of data for external applications. It also provides preview elements which help in understanding the data. An experiment with data from a real project was carried out in order to identify the accuracy of the prediction.

Abstract Continuous software engineering (CSE) has instigated academic debate regarding the rapid, parallel cycles of releasing software and customer experimentation. This approach, originating from Web 2.0 and the software-as-a-service domain, is widely recognised among software-intensive companies today. Earlier studies have indicated some challenges in the use of CSE, especially in the context of business-to-business and product-oriented, embedded systems development. Consequently, research must address more explicit definitions and theoretical models for analysing the prerequisites and organisational capabilities related to the use of CSE. This dissertation investigates various approaches to conducting empirical evaluations related to CSE. The study aims to improve existing models of CSE and to empirically validate them in the context of software companies. The study also aims to accumulate knowledge regarding the use of CSE, as well as its impacts. The case study method is applied for the collection and analysis of empirical data. Twenty-seven interviews are conducted at five companies. In addition, a systematic literature review is used to synthesise the empirical research on agile release engineering practices. Design science research is used to portray the model design and the evaluation process of this dissertation. Three approaches for evaluating CSE are constructed: (1) LESAT for software focuses on enterprise transformation using an organisational self-assessment approach, (2) STH+ extends the “Stairway to Heaven” model and evaluates company practices with respect to evolutionary steps towards continuous experimentation-driven development, and (3) CRUSOE defines 7 key areas and 14 diagnostic questions related to the product-intensive software development ecosystem, strategy, architecture, and organisation, as well as their continuous interdependencies. This dissertation states the relevance of CSE in the context of product-intensive software development. However, more adaptations are anticipated in practices that involve business and product development stakeholders, as well as company external stakeholders. / Tiivistelmä Jatkuva ohjelmistotuotanto on herättänyt keskustelua nopeasta, samanaikaisesta ohjelmistojulkaisemisesta ja asiakaskokeiluista. Toimintatapa on peräisin Web 2.0 ja software-as-a-service yhteydestä, mutta se tunnetaan nykyään yleisesti ohjelmistoja kehittävissä yrityksissä. Aiemmat tutkimukset ovat osoittaneet haasteita jatkuvan ohjelmistotuotannon käytössä. Erityisesti haasteita on havaittu yritykseltä yritykselle liiketoiminnassa ja tuotepainotteisten sulautettujen järjestelmien yhteydessä. Näin ollen on havaittu tarve tutkimuksen avulla kehittää täsmällisempiä määritelmiä ja teoreettisia malleja, joilla voidaan analysoida jatkuvan ohjelmistotuotannon käyttöön liittyviä edellytyksiä ja organisaatioiden kyvykkyyksiä. Tässä väitöskirjassa tutkitaan malleja, joilla voidaan empiirisesti arvioida jatkuvaa ohjelmistotuotantoa. Tutkimuksella pyritään parantamaan nykyisiä malleja ja arvioimaan niiden käyttöä ohjelmistoyrityksissä. Lisäksi tutkimuksella pyritään kasvattamaan tietoa jatkuvasta ohjelmistotuotannosta ja sen vaikutuksista. Tiedon keräämiseen ja analysointiin käytettiin tapaustutkimus menetelmää. Kaksikymmentäseitsemän haastattelua tehtiin viidessä yrityksessä. Lisäksi tehtiin ketterään ohjelmistojulkaisuun keskittyvä systemaattinen kirjallisuuskatsaus. Väitöskirjassa käytetään Design Science Research menetelmää kuvaamaan tutkimuksen eri vaiheita, joissa malleja suunniteltiin ja arvioitiin. Tutkimuksessa rakennettiin kolme tapaa jatkuvan ohjelmistotuotannon arvioimista varten: (1) LESAT for Software keskittyy organisaation muutoskyvykkyyden arviointiin käyttäen itsearviointimenetelmää, (2) STH+, laajentaa ”Stairway to Heaven” mallia ja arvioi yrityksen käytäntöjä eri evoluutioaskelmilla matkalla kohti kokeilupainotteista tuotekehitystä, (3) CRUSOE määrittelee seitsemän pääaluetta ja 14 kysymystä liittyen tuotekehityksen ekosysteemiin, strategiaan, arkkitehtuuriin, organisointiin sekä näiden välisiin jatkuviin riippuvuuksiin. Väitöskirja osoittaa jatkuvan ohjelmistokehityksen olevan merkityksellinen myös tuotepainotteisessa ohjelmistokehityksessä. Nähtävissä kuitenkin on, että useita nykykäytäntöjä on tarvetta muokata. Erityisesti muokkaustarvetta on tuotekehityksen ja liiketoiminnan sidosryhmiin ja yrityksen ulkoisiin sidosryhmiin liittyvissä käytännöissä.