Software Development Workflow Research Articles

Aspects of modelling requirements in very-large agile systems engineering

Using models for requirements engineering (RE) is uncommon in systems engineering, despite the widespread use of model-based engineering in general. One reason for this lack of use is that formal models do not match well the trend to move towards agile developing methods. While there exists work that investigates challenges in the adoption of requirements modelling and agile methods in systems engineering, there is a lack of work studying successful approaches of using requirements modelling in agile systems engineering. To address this gap, we conducted a case study investigating the application of requirements models at Ericsson AB, a Swedish telecommunications company. We studied a department using requirements models to bridge agile development and plan-driven development aspects. We find that models are used to understand how requirements relate to each other, and to keep track with the product’s evolution. To cope with the effort to maintain models over time, study participants suggest to rely on text-based notations that bring the models closer to developers and allow integration into existing software development workflows. This results in tool trade-offs, e.g., losing the possibility to control diagram layout.

Practical Mutation Testing at Scale: A view from Google

Mutation analysis assesses a test suite’s adequacy by measuring its ability to detect small artificial faults, systematically seeded into the tested program. Mutation analysis is considered one of the strongest test-adequacy criteria. Mutation testing builds on top of mutation analysis and is a testing technique that uses mutants as test goals to create or improve a test suite. Mutation testing has long been considered intractable because the sheer number of mutants that can be created represents an insurmountable problem–both in terms of human and computational effort. This has hindered the adoption of mutation testing as an industry standard. For example, Google has a codebase of two billion lines of code and more than 150,000,000 tests are executed on a daily basis. The traditional approach to mutation testing does not scale to such an environment; even existing solutions to speed up mutation analysis are insufficient to make it computationally feasible at such a scale. To address these challenges, this paper presents a scalable approach to mutation testing based on the following main ideas: (1) mutation testing is done incrementally, mutating only <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">changed code</i> during code review, rather than the entire code base; (2) mutants are filtered, removing mutants that are likely to be irrelevant to developers, and limiting the number of mutants per line and per code review process; (3) mutants are selected based on the historical performance of mutation operators, further eliminating irrelevant mutants and improving mutant quality. This paper empirically validates the proposed approach by analyzing its effectiveness in a code-review-based setting, used by more than 24,000 developers on more than 1,000 projects. The results show that the proposed approach produces orders of magnitude fewer mutants and that context-based mutant filtering and selection improve mutant quality and actionability. Overall, the proposed approach represents a mutation testing framework that seamlessly integrates into the software development workflow and is applicable to industrial settings of any size.

Automatically Learning Formal Models from Autonomous Driving Software

The correctness of autonomous driving software is of utmost importance, as incorrect behavior may have catastrophic consequences. Formal model-based engineering techniques can help guarantee correctness and thereby allow the safe deployment of autonomous vehicles. However, challenges exist for widespread industrial adoption of formal methods. One of these challenges is the model construction problem. Manual construction of formal models is time-consuming, error-prone, and intractable for large systems. Automating model construction would be a big step towards widespread industrial adoption of formal methods for system development, re-engineering, and reverse engineering. This article applies active learning techniques to obtain formal models of an existing (under development) autonomous driving software module implemented in MATLAB. This demonstrates the feasibility of automated learning for automotive industrial use. Additionally, practical challenges in applying automata learning, and possible directions for integrating automata learning into the automotive software development workflow, are discussed.

A Workflow for Ensuring DICOM Compatibility During Radiography Device Software Development.

In medical devices, nonconformance with Digital Imaging and Communications in Medicine (DICOM) standard is a serious risk. DICOM nonconformance radiology devices could cause undetected image loss, increasing examination time, and costs in health centers and could even result in the wrong patient treatment. However, there is a rich literature on medical standards that identify the best practices for producing safe and effective medical software. However, these standards do not expressly provide tools to deal with all the relevant DICOM compatibility issues in a specific case. This study aims to introduce a systematic software development workflow that complies with medical standards and ensures DICOM conformance of a new or upgraded radiology software project. In this approach, DICOM conformance gets the highest priority, and the whole software project is organized around it. Software requirement analysis, risk evaluation, and test management tasks are arranged systematically to make the final device DICOM conformant. This conceptual framework was developed during the R&D work towards a novel radiography device, and it could be employed as a roadmap in other medical imaging software projects. The proposed methodology controls the DICOM compatibility risk of the final software, and its systematic evaluation complied with medical standards.

Code‐level model checking in the software development workflow at Amazon Web Services

AbstractThis article describes a style of applying symbolic model checking developed over the course of four years at Amazon Web Services (AWS). Lessons learned are drawn from proving properties of numerous C‐based systems, for example, custom hypervisors, encryption code, boot loaders, and an IoT operating system. Using our methodology, we find that we can prove the correctness of industrial low‐level C‐based systems with reasonable effort and predictability. Furthermore, AWS developers are increasingly writing their own formal specifications. As part of this effort, we have developed a CI system that allows integration of the proofs into standard development workflows and extended the proof tools to provide better feedback to users. All proofs discussed in this article are publicly available on GitHub.

Security in agile software development: A practitioner survey

Abstract Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model. However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development, as practiced by software developer professionals. Method: A survey ( N = 61 ) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.

Programming the platform university: Learning analytics and predictive infrastructures in higher education

This article offers a case study of how platforms and predictive infrastructures are emerging in higher education. It examines a Learning Analytics Application Programming Interface (API) from a popular Learning Management System. The API is treated firstly as an artefact based on the computational abstraction of educational principles, and secondly as an empirical entry point to investigate the emergence of a Learning Analytics infrastructure in a large Australian university. Through in-depth ethnographic interviews and the interpretative analysis of software development workflows, the paper describes an API-mediated platformisation process involving a range of actors and systems: computational experts, algorithms, data-savvy administrative staff and large corporate actors inserting themselves through back-ends and various other dependencies. In the conclusion, the article argues that the platformisation of higher education is part of a broader project that mobilises programmability and computation to re-engineer educational institutions in the interest of efficiency and prediction. However, the social-scientific study of this project cannot ignore the practical and compromised dimension where human actors and technical systems interact and, in the process, generate meaning.

A longitudinal study of static analysis warning evolution and the effects of PMD on software quality in Apache open source projects

Automated static analysis tools (ASATs) have become a major part of the software development workflow. Acting on the generated warnings, i.e., changing the code indicated in the warning, should be part of, at latest, the code review phase. Despite this being a best practice in software development, there is still a lack of empirical research regarding the usage of ASATs in the wild. In this work, we want to study ASAT warning trends in software via the example of PMD as an ASAT and its usage in open source projects. We analyzed the commit history of 54 projects (with 112,266 commits in total), taking into account 193 PMD rules and 61 PMD releases. We investigate trends of ASAT warnings over up to 17 years for the selected study subjects regarding changes of warning types, short and long term impact of ASAT use, and changes in warning severities. We found that large global changes in ASAT warnings are mostly due to coding style changes regarding braces and naming conventions. We also found that, surprisingly, the influence of the presence of PMD in the build process of the project on warning removal trends for the number of warnings per lines of code is small and not statistically significant. Regardless, if we consider defect density as a proxy for external quality, we see a positive effect if PMD is present in the build configuration of our study subjects.

English

English

Steering Software Development Workflow: Lessons from the Internet

There's a body of literature on the software factory that might lead readers to believe that software development is analogous to manufacturing: requirements enter one end of a pipeline; tested code exits the other. In The Principles of Product Development Flow, Donald Reinertsen challenged this paradigm, proposing that a flow-based model is more applicable. Reinertsen's principles apply to both communication networks and software development workflows, and network optimization approaches are applicable to software development workflows.

Using Modeling and Simulation in the Design of Closed-Loop Insulin Delivery System

The complexity of medical devices is rapidly increasing, enabled by innovations in technology. This same technology has enabled health care to expand from institutional environments to home care and mobile environments. Software plays a critical role in controlling these devices. It is essential that the dependability of these devices is assured because many of them are safety critical; i.e. can cause serious injury or death. Modeling and simulation of device designs is emerging among medical device manufacturers as a technique to help address such challenges. Modeling and simulation has a long history of improving product quality by helping designers to detect defects that may be overlooked in a traditional software development workflow. For example, design requirements can be modeled, and then the model checked for properties of requirement consistency and completeness. Subsequently, the model can be run in-silica permitting rapid-prototyping and comprehensive real-time checking of design behavior which can ultimately be used to help verify actual device implementation. Modeling can be thought of as an incremental process improvement step that happens early in a design phase well before any implementation (writing code or building physical hardware), and can be integrated into any software/hardware development lifecycle. Medical Devices manufacturers and companies in other safety-critical industries such as aerospace and automotive have been using modeling and simulation approaches to verify and validate designs early in their development process for many years now [4][7][8]. Today, many diabetic patients use insulin pumps to manage their own medication delivery through a combination of basal and bolus doses of insulin to maintain healthy blood glucose (BG) levels. With the addition of Continuous Glucose Monitoring (CGM) devices, the opportunity exists to create a closed-loop, automatic control or “artificial pancreas” means of delivering the insulin. In this technical brief, we present a highly abstracted insulin infusion pump system as an example modeling exercise. A simulated environment of the glycemic system of the body, along with the insulin computation algorithm are modeled in Simulink® and tested against various real-world parameters from clinical testing.

Broadcast digital asset management at Lifetime Television

The merging of IT and broadcast technology has been an ever-expanding phenomenon. This merge is particularly evident in the area of digital asset management (DAM). The author, an experienced software developer, describes his first foray into the arena of broadcast technology. Currently he is working on a new DAM system for long form and promo content. The current post-production process will be replaced with an automated tapeless environment supporting ingest, quality control, dubbing, transfer to the editing system, archive management and transfer to on-air systems. This paper describes the education of the author on broadcast technology and the unique needs and concerns of his post-production clients. The merging of IT and broadcast, and the contributions each brings to the success of the implementation of a DAM system is set against the backdrop of a project as it progresses from high-level analysis, vendor selection, system design, hardware implementation, software development, testing and detailed workflow analysis. The author presents a project in the midst of development, with the recurrent pattern of successes and setbacks.

Constructing component-based software engineering environments: issues and experiences

Developing software engineering tools is a difficult task, and the environments in which these tools are deployed continually evolve as software developers’ processes, tools and tool sets evolve. To more effectively develop such evolvable environments, we have been using component-based approaches to build and integrate a range of software development tools, including CASE and workflow tools, file servers and versioning systems, and a variety of reusable software agents. We describe the rationale for a component-based approach to developing such tools, the architecture and support tools we have used some resultant tools and tool facilities we have developed, and summarise the possible future research directions in this area.