Kirjallisuuskatsaus testiautomaatiomalleista ketterässä ohjelmistotestauksessa

Test automation is considered to be a crucial part of a modern Agile development team. Agile software testing methods and development practices, such as Test Driven Development (TDD) or Behavior Driven Development (BDD), continuously assure software quality during development time, from project start to finish. Agile software development methods require Agile testing practices for its implementation. Software quality is built-in and delivering functional and stable software continuously is a key business capability. Automated system and acceptance tests are considered as a routine part of the Continuous Integration (CI) and Continuous Delivery (CD) pipeline. The objective of the research was to study, what test automation models, Agile practices and tools are found in Agile test automation literature and what kind of generic Agile test automation model can be synthesized from this literature. The objective was completed by conducting a systematic literature review of test automation models. The initial search included fifty scientific articles, from which ten models were selected for further analysis. The selected articles and their models were modelled using prescriptive modelling. The tools and Agile practices mentioned in the articles were recorded and categorized. Each model was also categorized according to its domain of application. Using the collected data, a synthesized generic model for Agile test automation model was created. Test automation models proved difficult to evaluate as the models were vastly different from each other in their description, depth of detail, utility, environment, scope and domain of application. A generic Agile test automation model would be characterized with agent, activity, artefact and event elements. It would have a functional information perspective and would be formally presented in text and graphic form. Continuous Integration was identified as the most popular Agile development method and Scrum as the most popular Agile management practice. Continuous Integration was also identified as the most popular tool category

Innovative Development of a Cross-Center Timeline Planning Tool

The Payload Operations Integration Center (POIC) at Marshall Space Flight Center (MSFC) supports planning, coordination and scheduling of science activities for the International Space Station (ISS) in coordination with other NASA centers, international partners, and payload developers. The ability to efficiently plan and re-plan in response to change is critical to the flight planning teams. With the achievement of supporting a fourth crew member aboard the ISS and an increasing amount of payload science activities, came the need for a dynamic, more efficient way of building timeline planning reports that could be readily updated as fast as payload science plans could change. This paper addresses software architecture considerations in the successful cross-center development of an automated planning tool with multiple data sources. It also discusses the practical implementation of a time-boxed, hybrid Agile Software Development (ASD) approach to deliver customer-driven value despite changing requirements with respect to low-Earth orbit operational planning activities. The goal of this paper is to open discussion with members of the international community and trade effective strategies for cross-center architectural and customer-developer driven collaborations, to support increasing utilization of planning and conducting science activities in space

Agile SoC Development with Open ESP

ESP is an open-source research platform for heterogeneous SoC design. The platform combines a modular tile-based architecture with a variety of application-oriented flows for the design and optimization of accelerators. The ESP architecture is highly scalable and strikes a balance between regularity and specialization. The companion methodology raises the level of abstraction to system-level design and enables an automated flow from software and hardware development to full-system prototyping on FPGA. For application developers, ESP offers domain-specific automated solutions to synthesize new accelerators for their software and to map complex workloads onto the SoC architecture. For hardware engineers, ESP offers automated solutions to integrate their accelerator designs into the complete SoC. Conceived as a heterogeneous integration platform and tested through years of teaching at Columbia University, ESP supports the open-source hardware community by providing a flexible platform for agile SoC development.Comment: Invited Paper at the 2020 International Conference On Computer Aided Design (ICCAD) - Special Session on Opensource Tools and Platforms for Agile Development of Specialized Architecture

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

How is FOLIO Different from Its Predecessors?

FOLIO is a future-oriented library service platform. Enlightened by the results of the 2021 International Survey of Library Automation, the author shared thoughts on how FOLIO meets librarians’ expectations, why it’s a good time to get involved in the FOLIO project and what challenges FOLIO is facing at the current development stage

The implications of digitalization on business model change

Context: Digitalization brings new opportunities and also challenges to software companies. Objective: Software companies have mostly focused on the technical aspects of handing changes and mostly ignoring the business model changes and their implications on software organization and the architecture. In this paper, we synthesize implications of the digitalization based on an extensive literature survey and a longitudinal case study at Ericsson AB. Method: Using thematic analysis, we present six propositions to be used to facilitate the cross-disciplinary analysis of business model dynamics and the effectiveness and efficiency of the outcome of business modeling, by linking value, transaction, and organizational learning to business model change. Conclusions: Business model alignment is highlighted as a new business model research area for understanding the relationships between the dynamic nature of business models, organization design, and the value creation in the business model activities

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