05 Fakultät Informatik, Elektrotechnik und Informationstechnik
Permanent URI for this collectionhttps://elib.uni-stuttgart.de/handle/11682/6
Browse
Search Results
Item Open Access A comprehensive safety engineering approach for software-intensive systems based on STPA(2015) Abdulkhaleq, Asim; Wagner, Stefan; Leveson, NancyFormal verification and testing are complementary approaches which are used in the development process to verify the functional correctness of software. However, the correctness of software cannot ensure the safe operation of safety-critical software systems. The software must be verified against its safety requirements which are identified by safety analysis, to ensure that potential hazardous causes cannot occur. The complexity of software makes defining appropriate software safety requirements with traditional safety analysis techniques difficult. STPA (Systems-Theoretic Processes Analysis) is a unique safety analysis approach that has been developed to identify system hazards, including the software-related hazards. This paper presents a comprehensive safety engineering approach based on STPA, including software testing and model checking approaches for the purpose of developing safe software. The proposed approach can be embedded within a defined software engineering process or applied to existing software systems, allow software and safety engineers integrate the analysis of software risks with their verification. The application of the proposed approach is illustrated with an automotive software controller.Item Open Access Towards building knowledge on causes of critical requirements engineering problems(2015) Kalinowski, Marcos; Spínola, Rodrigo Oliveira; Conte, Tayana; Prikladnicki, Rafael; Méndez Fernández, Daniel; Wagner, Stefan[Context] Many software projects fail due to problems in requirements engineering (RE). [Objective] The goal of this paper is to gather information on relevant RE problems and to represent knowledge on their most common causes. [Method] We replicated a global family of RE surveys in the Brazil and used the data to identify critical RE problems and to build probabilistic cause-effect diagrams to represent knowledge on their common causes. [Results] The survey was answered by 74 different organizations, including small, medium and very large sized companies, conducting both, plan-driven and agile development. The most critical RE problems, according to those organizations, are related to communication and to incomplete or underspecified requirements. We provide the full probabilistic cause-effect diagrams with knowledge on common causes of the most critical identified RE problems online. [Conclusion] We believe that the knowledge presented in the diagrams can be helpful to support organizations in conducting causal analysis sessions by providing an initial understanding on what usually causes critical RE problems.Item Open Access Does outside-in teaching improve the learning of object-oriented programming?(2015) Janke, Erica; Brune, Philipp; Wagner, StefanObject-oriented programming (OOP) is widely used in the software industry and university introductory courses today. Following the structure of most textbooks, such courses frequently are organised starting with the concepts of imperative and structured programming and only later introducing OOP. An alternative approach is to begin directly with OOP following the Outside-In teaching method as proposed by Meyer. Empirical results for the effects of Outside-In teaching on students and lecturers are sparse, however. We describe the conceptual design and empirical evaluation of two OOP introductory courses from different universities based on Outside-In teaching. The evaluation results are compared to those from a third course serving as the control group, which was taught OOP the "traditional" way. We evaluate the initial motivation and knowledge of the participants and the learning outcomes. In addition, we analyse results of the end- term exams and qualitatively analyse the results of interviews with the lecturers and tutors. Regarding the learning outcomes, the results show no signif- icant differences between the Outside-In and the “traditional” teaching method. In general, students found it harder to solve and implement algorithmic problems than to understand object oriented (OO) concepts. Students taught OOP by the Outside-In method, however, were less afraid that they would not pass the exam at the end of term and understood the OO paradigm more quickly. Therefore, the Outside-In method is no silver bullet for teaching OOP regarding the learning outcomes but has positive effects on motivation and interest.Item Open Access XSTAMPP: An eXtensible STAMP platform as tool support for safety engineering(2015) Abdulkhaleq, Asim; Wagner, StefanSTPA (Systems-Theoretic Processes Analysis) is a new hazard analysis technique based on STAMP. STPA is already being used in different industrial domains (e.g. space, aviation, medical or automotive). To support the application of STPA and make using STPA more efficient, we developed an open tool called A-STPA. However, the current usage of ASTPA by safety analysts in different areas shows a number of shortcomings in terms of documenting unsafe control actions, drawing different levels of control structure diagrams, documenting the causal factors in STPA Step 2 and supporting the application of STPA in different areas. In this paper, we present an extensible STAMP platform called XSTAMPP as tool support designed specifically to serve the widespread adoption and use of STPA in different areas, to facilitate STPA application to different systems and to be easily extended to include different requirements and features. Moreover, XSTAMPP has the potential to be extended in the future to support the application of CAST for accident analysis. We believe that XSTAMPP is a useful first step toward establishing a base platform to support the application of STAMP methodologies in different domains.Item Open Access A controlled experiment for the empirical evaluation of safety analysis techniques for safety-critical software(2015) Abdulkhaleq, Asim; Wagner, StefanContext: Today's safety critical systems are increasingly reliant on software. Software becomes responsible for most of the critical functions of systems. Many different safety analysis techniques have been developed to identify hazards of systems. FTA and FMEA are most commonly used by safety analysts. Recently, STPA has been proposed with the goal to better cope with complex systems including software. Objective: This research aimed at comparing quantitatively these three safety analysis techniques with regard to their effectiveness, applicability, understandability, ease of use and efficiency in identifying software safety requirements at the system level. Method: We conducted a controlled experiment with 21 master and bachelor students applying these three techniques to three safety-critical systems: train door control, anti-lock braking and traffic collision and avoidance. Results: The results showed that there is no statistically significant difference between these techniques in terms of applicability, understandability and ease of use, but a significant difference in terms of effectiveness and efficiency is obtained. Conclusion: We conclude that STPA seems to be an effective method to identify software safety requirements at the system level. In particular, STPA addresses more different software safety requirements than the traditional techniques FTA and FMEA, but STPA needs more time to carry out by safety analysts with little or no prior experience.Item Open Access A case study on artefact-based RE improvement in practice(2015) Méndez Fernández, Daniel; Wagner, StefanBackground: Most requirements engineering (RE) process improvement approaches are solution-driven and activity-based. They focus on the assessment of the RE of a company against an external norm of best practices. A consequence is that practitioners often have to rely on an improvement approach that skips a profound problem analysis and that results in an RE approach that might be alien to the organisational needs. Objective: In recent years, we have developed an RE improvement approach (called ArtREPI ) that guides a holistic RE improvement against individual goals of a company putting primary attention to the quality of the artefacts. In this paper, we aim at exploring ArtREPI’s benefits and limitations. Method: We contribute an industrial evaluation of ArtREPI by relying on a case study research. Results: Our results suggest that ArtREPI is well-suited for the establishment of an RE that reflects a specific organisational culture but to some extent at the cost of efficiency resulting from intensive discussions on a terminology that suits all involved stakeholders. Conclusions: Our results reveal first benefits and limitations, but we can also conclude the need of longitudinal and independent investigations for which we herewith lay the foundation.Item Open Access Fast feedback cycles in empirical software engineering research(2015) Vetrò, Antonio; Ognawala, Saahil; Méndez Fernández, Daniel; Wagner, StefanBackground/Context: Gathering empirical knowledge is a time consuming task and the results from empirical studies often are soon outdated by new technological solutions. As a result, the impact of empirical results on software engineering practice is often not guaranteed. Objective/Aim: In this paper, we summarize the ongoing discussion on "Empirical Software Engineering 2.0" as a way to improve the impact of empirical results on industrial practices. We propose a way to combine data mining and analysis with domain knowledge to enable fast feedback cycles in empirical software engineering research. Method: We identify the key concepts on gathering fast feedback in empirical software engineering by following an experience-based line of reasoning by argument. Based on the identified key concepts, we design and execute a small proof of concept with a company to demonstrate potential benefits of the approach. Results: In our example, we observed that a simple double feedback mechanism notably increased the precision of the data analysis and improved the quality of the knowledge gathered. Conclusion: Our results serve as a basis to foster discussion and collaboration within the research community for a development of the idea.Item Open Access What do practitioners vary in using scrum?(2015) Diebold, Philipp; Ostberg, Jan-Peter; Wagner, Stefan; Zendler, UlrichBackground: Agile software development has become a popular way of developing software. Scrum is the most frequently used agile framework, but it is often reported to be adapted in practice. Objective: Thus, we aim to understand how Scrum is adapted in different contexts and what are the reasons for these changes. Method: Using a structured interview guideline, we interviewed ten German companies about their concrete usage of Scrum and analysed the results qualitatively. Results: All companies vary Scrum in some way. The least variations are in the Sprint length, events, team size and requirements engineering. Many users varied the roles, effort estimations and quality assurance. Conclusions: Many variations constitute a substantial deviation from Scrum as initially proposed. For some of these variations, there are good reasons. Sometimes, however, the variations are a result of a previous non-agile, hierarchical organisation.Item Open Access Preventing incomplete/hidden requirements: reflections on survey data from Austria and Brazil(2015) Kalinowski, Marcos; Felderer, Michael; Conte, Tayana; Spinola, Rodrigo; Prikladnicki, Rafael; Winkler, Dietmar; Méndez Fernández, Daniel; Wagner, Stefan[Context] Many software projects fail due to problems in requirements engineering (RE). [Goal] The goal of this paper is analyzing a specific and relevant RE problem in detail: incomplete/hidden requirements. [Method] We replicated a global family of RE surveys with representatives of software organizations in Austria and Brazil. We used the data to (a) characterize the criticality of the selected RE problem, and to (b) analyze the reported main causes and mitigation actions. Based on the analysis, we discuss how to prevent the problem. [Results] The survey includes 14 different organizations in Austria and 74 in Brazil, including small, medium and large sized companies, conducting both, plan-driven and agile development processes. Respondents from both countries cited the incomplete/hidden requirements problem as one of the most critical RE problems. We identified and graphically represented the main causes and documented solution options to address these causes. Further, we compiled a list of reported mitigation actions. [Conclusions] From a practical point of view, this paper provides further insights into common causes of incomplete/hidden requirements and on how to prevent this problem.