Quantum computers leverage the principles of quantum mechanics to execute operations. They require quantum programs that define operations on quantum bits (qubits), the fundamental units of computation. Unlike traditional software development, the process of creating and debugging quantum programs requires specialized knowledge of quantum computation, making the development process more challenging.

Quantum computers, which utilize the principles of quantum mechanics, are expected to be applied to a wide range of fields. With the advancement of quantum computer development, a lot of quantum software, which enables the operation of quantum computers, has been developed. It has a distinct nature (e.g., superposition and entanglement of qubits) compared to traditional software, leading to the unique challenges of its development. While prior studies have clarified and defined some unique challenges of quantum software, many remain unclear due to limited research. In this study, we conducted an empirical study of Self-Admitted Technical Debt (SATD) for quantum software. SATD is a type of technical debt, a problem in the code that the developer is aware of. Hence, we conjecture that analyzing SATDs can reveal the unique challenges developers face when developing quantum software. We manually coded 202 comments from the Python® files of the 61 open-source quantum software on GitHub®. The 202 comments correspond to a 95% confidence level with a 5% confidence interval, as in previous studies. The results showed that 88 comments (45.6% of all SATD comments) were quantum-specific SATDs (QSATDs), which require knowledge of quantum computation to repay. Furthermore, we propose a taxonomy for QSATDs. This taxonomy, which consists of four main categories and eight subcategories, classifies QSATDs in terms of quantum-specific aspects such as circuit implementation, backend, and algorithms. Our empirical results are beneficial for quantum software developers, helping them understand implementation areas that require attention. For researchers, our results promote further research, including the exploration of challenges in QSATD repayment.

Significant effort is being put into developing industrial applications for artificial intelligence (AI), especially those using machine learning (ML) techniques. Despite the intensive support for building ML applications, there are still challenges when it comes to evaluating, assuring, and improving the quality or dependability. The difficulty stems from the unique nature of ML, namely, system behavior is derived from training data not from logical design by human engineers. This leads to black-box and intrinsically imperfect implementations that invalidate many principles and techniques in traditional software engineering. In light of this situation, the Japanese industry has jointly worked on a set of guidelines for the quality assurance of AI systems (in the Consortium of Quality Assurance for AI-based Products and Services) from the viewpoint of traditional quality-assurance engineers and test engineers. We report on the second version of these guidelines, which cover a list of quality evaluation aspects, catalogue of current state-of-the-art techniques, and domain-specific discussions in five representative domains. The guidelines provide significant insights for engineers in terms of methodologies and designs for tests driven by application-specific requirements.

When a software failure is observed during testing or operation, developers traditionally execute the software program again for reproducing the failure to analyze the cause of the failure. However, failures are often hard to reproduce because they depend on factors that are hard to expressly control, such as concurrency and nondeterminism. This paper presents a novel experimental fault analysis process for such "hard-to-reproduce failures". The proposed process consists of three phases: assumption of a hypothesis for the cause of a failure, experiments to examine the hypothesis and confirmation of the experimental results. We formalized the process and implemented it by using model extraction and model checking. Model extraction acts as a bridge between the assumption and experiment. Experiments on failure reproduction are conducted using model checking. The results of the case studies show that the process and tools supporting the process enables developers to detect the cause of hard-to-reproduce failures in industrial software development.

Debugging is one of the most time-consuming tasks in software development. The application of a model-checking technique in debugging has strong potential to solve this problem. Here, lessons learned through our practical experiences with POM/MC are discussed. The aim of this proposed hypothesis-based method of debugging is not only to reproduce a failure as counterexamples, but also to obtain a counterexample that is useful for detecting the fault or the cause of the failure. One of the characteristics of the proposed approach is that it degenerates a source code in order to clarify the fault. An example of this degeneration shows that the method is useful for fault analysis and avoidance of the "state-explosion" problem. Furthermore, the characteristics of debugging using POM/MC are explained from the viewpoint of debugging hypotheses.

Software product line engineering has spread as a technique for promoting the efficient development of embedded products with many product line-ups. During the development of network switch products at Hitachi Metals, Ltd., the number of development man-months increased as the number of product line-ups increased. Therefore, we shifted our development paradigm to product line development for efficient product development. We classified software assets as implementation assets, test assets, and design assets, and from these three assets, we extracted common objects and integrated them as reusable elements. By doing so, we promoted the efficient development of software assets and reduced the contradictions between the contents of the software assets. As a result, we reduced the amount of the source code by 53.1%. In this paper, we discuss the details of our technique and the effect of applying it. In addition, we discuss how you can apply our technique in the development of other products.

Model checking is a powerful technique for verifying the correctness of a systempsilas specification. But even when the specification has been verified to be correct, there is still the question of whether the specification covers all the expected behaviors. One of the most important issues for verification is the sufficiency of verification items. In model checking, specification-level properties such as reachability are well-studied, but the sufficiency of a specification against the preceding requirements still remains a challenge.In this paper, we propose a model-checking process with goal oriented requirements analysis, in which goal descriptions in a natural language are systematically refined into linear temporal logic formulae. Furthermore, the coverage of the verification result can be evaluated against the goal model. We developed a tool that supports the process, and applied it to an example. This process lowers the technical barriers to model checking and improves the sufficiency of system verification.