Towards Quantum Software Requirements Engineering

Quantum software engineering (QSE) is receiving increasing attention, as evidenced by increasing publications on topics, e.g., quantum software modeling, testing, and debugging. However, in the literature, quantum software requirements engineering (QSRE) is still a software engineering area that is relatively less investigated. To this end, in this paper, we provide an initial set of thoughts about how requirements engineering for quantum software might differ from that for classical software after making an effort to map classical requirements classifications (e.g., functional and extra-functional requirements) into the context of quantum software. Moreover, we provide discussions on various aspects of QSRE that deserve attention from the quantum software engineering community

The Essence of Software Engineering

This open access book includes contributions by leading researchers and industry thought leaders on various topics related to the essence of software engineering and their application in industrial projects. It offers a broad overview of research findings dealing with current practical software engineering issues and also pointers to potential future developments. Celebrating the 20th anniversary of adesso AG, adesso gathered some of the pioneers of software engineering including Manfred Broy, Ivar Jacobson and Carlo Ghezzi at a special symposium, where they presented their thoughts about latest software engineering research and which are part of this book. This way it offers readers a concise overview of the essence of software engineering, providing valuable insights into the latest methodological research findings and adesso’s experience applying these results in real-world projects

Incorporating Software Instruction into a Civil Engineering Curriculum

This paper contains the results of a survey of almost 43% of all the private civil engineering firms and government agencies in the state of Mississippi. The survey was focused primarily on the use of software and their thoughts on the software knowledge of new college graduates hired at each place of business. There were three key issues the survey focused on: computer programs used, software proficiencies of new college graduates, and the benefits of prior software knowledge. The paper presents the survey results and analyzes the trends in order to discover what civil engineering firms do and want. Also in this paper, methods of integrating software into a typical civil engineering curriculum are explored. Overall, it was found that several programs were constant in all of the firms, and that even though software knowledge is not required to land a job, it certainly is beneficial

The mythical man-month: essays on software engineering

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time. The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years.

The Impact of Feedback on the Motivation of Software Engineers

This research investigates how feedback affects the motivation of software engineers and develops a model of feedback in software engineering. Motivation has been reported as having an impact on software engineers’ productivity, the quality of the software they produce, the overall success of a software development project, and on the retention of software engineers. Findings from the last 30 years of research investigating motivation in software engineering have identified several factors that influence the motivation of software engineers, but the impact of each individual factor remains unclear. Feedback was identified as a factor affecting motivation by several studies investigating motivation in software engineering. Several theories of motivation exist which identify factors affecting motivation and models of how motivation is affected. Feedback is identified as a factor in four theories of motivation. In 2008 a systematic literature review identified that the majority of previous studies investigating motivation in software engineering were not grounded in motivation theory. This suggests that the majority of previous research investigating motivation in software engineering has not adequately considered theories of motivation and their relevance in software engineering. This research explored the importance of feedback and the effect of the characteristics of feedback on the motivation of software engineers, collecting their thoughts, perceptions, reflections and reactions to feedback using a range of different research methods. The research began with a preliminary study investigating how software engineers perceived feedback, and if the characteristics they identified were comparable to those identified in other disciplines, notably clinical education. Further studies followed by investigating feedback in software engineering, the short-term impact of received feedback, and the effect of the ‘source’ and ‘medium’ feedback characteristics. The findings of the preliminary study were that software engineers identified characteristics of feedback comparable to those found in clinical education, which gave a basis for further studies. Software engineers reported that feedback was the most common method of tracking their individual progress in a software project. A diary study collecting instances of feedback reported by software engineers found that positive feedback typically increased the engineers’ job satisfaction, and that negative feedback typically led to a change in their behaviour. Building on the earlier findings of this research, a scenario study and an online survey combining both scenarios and questions investigated the effect of the source and medium feedback characteristics. The findings of the four studies identified that the feedback recipient’s values and perceptions of the feedback source, and any preference they had to the medium used to send the feedback, affected the impact of received feedback. The findings suggested that the feedback software engineers report as the most valuable is not the same as feedback reported as having the most impact. The findings suggest that in software engineering, theories of motivation do not adequately consider the impact of the characteristics of feedback and the effect of different forms of feedback on motivation. A model of feedback in software engineering was identified by combining the findings of the four empirical studies and relevant literature. The model captures how feedback is experienced by software engineers. Software engineers perceive the characteristics of the received feedback, which provides information that is used to make several assessments about the feedback. Each engineer’s individual value set influences their assessments, and their current state of mind / mood / emotions affect the engineer’s perceptions, assessments, and individual value set. The assessments of the feedback then result in the impact of the received feedback, which can have an effect on the engineer’s attitude, behaviour, motivation, performance, job satisfaction, and feelings

Creating project-based learning in software

BACKGROUND : Project Based Learning (PBL) allows students to learn by doing hands on work and thus also again practical skills. Therefore going to software simulation may seem like a backwards step. However, the opportunity presented itself to create a unit on Artificial intelligence (AI). This lends itself it a software approach. An added benefit was the opportunity to create a PBL AI unit for both Engineering and IT students.PURPOSE : Can Project Based Learning be improved with dedicated, specifically written, software design?DESIGN/METHOD : After introducing a dedicated software package the student marks and student feedback for the AI unit for a few years before the package introduction until the most recent year was analysed. In the student surveys, 2 key questions where examined: unit material quality and feedback to students. Student comments were also studied.RESULTS : Student surveys gave a consistently high mark for unit’s material and student marks seems consistent as well but favourable comments increased. The most significant result was that the students’ thoughts about the project feedback had increased significantly, probably due to the inbuilt feedback system in the dedicated software package.CONCLUSIONS : With an appropriate subject matter a dedicated software package can help students in PBL. Student enjoyment increased which, in turn, increased their motivation

Building a Sustainable Structure for Research Software Engineering Activities

The profile of research software engineering has been greatly enhanced by developments at institutions around the world to form groups and communities that can support effective, sustainable development of research software. We observe, however, that there is still a long way to go to build a clear understanding about what approaches provide the best support for research software developers in different contexts, and how such understanding can be used to suggest more formal structures, models or frameworks that can help to further support the growth of research software engineering. This paper sets out some preliminary thoughts and proposes an initial high-level model based on discussions between the authors around the concept of a set of pillars representing key activities and processes that form the core structure of a successful research software engineering offering.Comment: 5 pages, 1 figure, submitted to the 9th International Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE6.1

Letters to the Editor

Software Safety vs Software Reliability While looking back through Vol. 56, No. 1 (Summer 2020) of Journal of System Safety, I finally took the time to read Nathaniel Ozarin’s article “Lessons Learned in a Complex Software Safety Program.” The article is quite interesting and thought provoking, comparing what actually occurs while implementing a system safety program to the idealized descriptions found in documents such as MIL-STD-882, JSSSEH and AOP-52. While I found the article interesting and informative, I noted that the author consistently characterizes the “software safety problem” as a “reliability” problem, focused on finding and preventing “failures” and ensuring high “reliability.” Some Thoughts on the Probabilistic Criteria for Ensuring Safe Airplane-System Designs We have been employed in the risk sciences for a total of 86 years, including 62 years in reliability engineering and safety engineering positions at The Boeing Company. For many of those years, Yellman was the designated “Risk-Analysis Focal” (person) for Boeing’s 707, 727, 737 and 757 airplane models. For several decades, the United States government has published the same criteria, created by the U.S. Federal Aviation Administration (FAA), intended to ensure that the systems on large (transport-category) aircraft have been designed to be safe [Refs. 1 and 2]. But we believe that the criteria have failed to prevent certain aircraft accidents, and we think that the reasons for that should be better understood. We hope that this discussion will contribute to a better understanding by examining the part potentially played in those accidents by the FAA’s criteria that are defined probabilistically

Using protocol analysis to explore the creative requirements engineering process

Protocol analysis is an empirical method applied by researchers in cognitive psychology and behavioural analysis. Protocol analysis can be used to collect, document and analyse thought processes by an individual problem solver. In general, research subjects are asked to think aloud when performing a given task. Their verbal reports are transcribed and represent a sequence of their thoughts and cognitive activities. These verbal reports are analysed to identify relevant segments of cognitive behaviours by the research subjects. The analysis results may be cross-examined (or validated through retrospective interviews with the research subjects). This paper offers a critical analysis of this research method, its approaches to data collection and analysis, strengths and limitations, and discusses its use in information systems research. The aim is to explore the use of protocol analysis in studying the creative requirements engineering process.<br /