Results 1 - 10
of
60
A survey of architecture design rationale
, 2006
"... Many claims have been made about the consequences of not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence avai ..."
Abstract
-
Cited by 35 (8 self)
- Add to MetaCart
Many claims have been made about the consequences of not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence available on what design rationale mean to practitioners, how valuable they consider it, and how they use and document it during the design process. This paper reports a survey of practitioners to probe their perception of the value of design rationale and how they use and document the background knowledge related to their design decisions. Based on 81 valid responses, this study has discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated barriers to the use and documentation of design rationale. Based on the findings, we conclude that further research is needed to develop methodology and tool support for design rationale capture and usage. Furthermore, we put forward some specific research questions about design rationale that could be further investigated to benefit industry practice.
Expectations, Outcomes, and Challenges Of Modern Code Review
"... Abstract—Code review is a common software engineering practice employed both in open source and industrial contexts. Review today is less formal and more "lightweight " than the code inspections performed and studied in the 70s and 80s. We empirically explore the motivations, challenges, a ..."
Abstract
-
Cited by 30 (7 self)
- Add to MetaCart
(Show Context)
Abstract—Code review is a common software engineering practice employed both in open source and industrial contexts. Review today is less formal and more "lightweight " than the code inspections performed and studied in the 70s and 80s. We empirically explore the motivations, challenges, and outcomes of tool-based code reviews. We observed, interviewed, and surveyed developers and managers and manually classified hundreds of review comments across diverse teams at Microsoft. Our study reveals that while finding defects remains the main motivation for review, reviews are less about defects than expected and instead provide additional benefits such as knowledge transfer, increased team awareness, and creation of alternative solutions to problems. Moreover, we find that code and change understanding is the key aspect of code reviewing and that developers employ a wide range of mechanisms to meet their understanding needs, most of which are not met by current tools. We provide recommendations for practitioners and researchers. I.
Enriching Reverse Engineering with Feature Analysis
, 2007
"... System comprehension is a prerequisite for software maintenance and evolution, but it is a timeconsuming and costly activity. In an effort to support system comprehension, researchers have devised many different reverse engineering techniques. Several of these are based on statically analyzing the s ..."
Abstract
-
Cited by 19 (5 self)
- Add to MetaCart
System comprehension is a prerequisite for software maintenance and evolution, but it is a timeconsuming and costly activity. In an effort to support system comprehension, researchers have devised many different reverse engineering techniques. Several of these are based on statically analyzing the source code. Purely static analysis techniques, however, overlook valuable end-user knowledge of how a system behaves at runtime. To address this problem, several researchers have identified the potential of exploiting features in a reverse engineering context. Features are abstractions of a system’s problem domain that wellunderstood by end-users. They encapsulate knowledge of a problem domain and denote units of system behavior. Thus, they represent a valuable resource for reverse engineering a system, The main body of feature-related reverse engineering research is concerned with feature identification, a technique to map features to source code. To fully exploit features in reverse engineering, however, we need to extend the focus beyond feature identification and exploit features as primary units of analysis. We formulate our thesis as follows: To exploit the inherent domain knowledge of features for object-oriented system comprehension,
Guidelines for industrially-based multiple case studies in software engineering
- in Research Challenges in Information Science, 2009. RCIS 2009. Third International Conference on
, 2009
"... Abstract—Without careful methodological guidance, case studies in software engineering are difficult to plan, design and execute. While there are a number of broad guidelines for case study research, there are none that specifically address the needs of a software engineer undertaking multiple case ..."
Abstract
-
Cited by 17 (1 self)
- Add to MetaCart
(Show Context)
Abstract—Without careful methodological guidance, case studies in software engineering are difficult to plan, design and execute. While there are a number of broad guidelines for case study research, there are none that specifically address the needs of a software engineer undertaking multiple case studies in an industrial setting. Through a synthesis of existing best practices in case study research, we provide a set of comprehensive guidelines for conducting multiple case studies in software engineering research. Our guidelines can assist software engineering researchers with all stages of multiple case study research, although in this paper we concentrate on the early phases, such as focusing the case study and detailed plan design. To date, three exploratory research projects found our guidelines very useful. We illustrate our guidelines with examples from one of these projects. Keywords-case study guidelines; software engineering; case study planning; case study design; case study data collection I.
How developers develop features
- In Proceedings of CSMR 2007 (11th European Conference on Software Maintenance and Reengineering
, 2007
"... Software systems are typically developed by teams of developers, with responsibilities for different parts of the code. Knowledge of how the developers collaborate, and how their responsibilities are distributed over the software artifacts is a valuable source of information when reverse engineering ..."
Abstract
-
Cited by 11 (2 self)
- Add to MetaCart
(Show Context)
Software systems are typically developed by teams of developers, with responsibilities for different parts of the code. Knowledge of how the developers collaborate, and how their responsibilities are distributed over the software artifacts is a valuable source of information when reverse engineering a system. Determining which developers are responsible for which software artifacts (e.g., packages or classes) is just one perspective. In this paper we comple-ment the static perspective with the dynamic perspective of a system in terms of its features. We want to extract infor-mation about which developers are responsible for which features. To achieve these two perspectives, we correlate developer responsibilities both with a structural view of the system and with a feature view. We identify which devel-opers are responsible for which features, and whether the responsibilities correspond with structural source code ar-tifacts or with features. We apply our technique to two soft-ware projects developed by two teams of students as part of their course work, and to one large open source project.
S.: Analysis of early aspects in requirements goal models: a concept-driven approach
- Transactions on AOSD III. LNCS
, 2007
"... Abstract. Early aspects are stakeholder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Analyzing early as-pects improves early stage decision-making, and helps trace stakeholder interests throughout ..."
Abstract
-
Cited by 8 (5 self)
- Add to MetaCart
(Show Context)
Abstract. Early aspects are stakeholder concerns that crosscut the problem domain, with the potential for a broad impact on questions of scoping, prioritization, and architectural design. Analyzing early as-pects improves early stage decision-making, and helps trace stakeholder interests throughout the software development life cycle. However, analy-sis of early aspects is hard because stakeholders are often vague about the concepts involved, and may use different vocabularies to express their concerns. In this paper, we present a rigorous approach to con-ceptual analysis of stakeholder concerns. We make use of the repertory grid technique to identify terminological interference between stakehold-ers ’ descriptions of their goals, and formal concept analysis to uncover conflicts and trade-offs between these goals. We demonstrate how this approach can be applied to the goal models commonly used in require-ments analysis, resulting in the clarification and elaboration of early aspects. Preliminary qualitative evaluation indicates that the approach can be readily adopted in existing requirements analysis processes, and can yield significant insights into crosscutting concerns in the problem domain.
Resumption Strategies for Interrupted Programming Tasks
"... Interruptions are a daily reality for professional programmers. Unfortunately, the strategies programmers use to recover lost knowledge and resume work have not yet been well studied. In this paper, we perform exploratory analysis on 10,000 recorded programming sessions of 85 programmers to understa ..."
Abstract
-
Cited by 8 (2 self)
- Add to MetaCart
(Show Context)
Interruptions are a daily reality for professional programmers. Unfortunately, the strategies programmers use to recover lost knowledge and resume work have not yet been well studied. In this paper, we perform exploratory analysis on 10,000 recorded programming sessions of 85 programmers to understand the variety of strategies used by programmers for resuming programming tasks. In our study, we find that only 10 % of the programming sessions have coding activity start in less than a minute, only 7 % of the programming sessions involve no navigation to other locations prior to editing, and find evidence of programmers seeking other sources of task context during task resumption. Based on the analysis, we suggest how task resumption might be better supported in future development tools. 1.
M.: ‘Reporting Empirical Research in Open Source Software: The State of Practice
- Proc. 5th IFIP WG 2.13 International Conference on Open Source Systems
"... Abstract. Background: The number of reported empirical studies of Open Source Software (OSS) has continuously been increasing. However, there has been no effort to systematically review the state of the practice of reporting empirical studies of OSS with respect to the recommended standards of perf ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
(Show Context)
Abstract. Background: The number of reported empirical studies of Open Source Software (OSS) has continuously been increasing. However, there has been no effort to systematically review the state of the practice of reporting empirical studies of OSS with respect to the recommended standards of performing and reporting empirical studies in software engineering. It is important to understand, how to report empirical studies of OSS in order to make them useful for practitioners and researchers. Research aim: The aim of our research is to gain insights in the state of the practice of reporting empirical studies of OSS in order to identify the gaps to be filled for improving the quality of evidence being provided for OSS. Method: To that end, we decided to systematically review the empirical studies of OSS. A total of 63 papers reporting empirical studies were selected from the four editions of the Proceedings of the International Conference on Open Source Systems. The data were extracted and synthesised from the selected papers for analysis. Results and conclusions: We have found that the quality of the reported OSSrelated empirical studies needs to be significantly improved. Based on the results of our systematic review and general principles of reporting good empirical research, we present a set of guidelines for reporting OSS-related empirical studies. The suggested guidelines are expected to help the research community to improve the quality of reported studies.
Establishing Maintainability in Systems Integration: Ambiguity, Negotiation, and Infrastructure", forthcoming
- in Proceedings of the 22nd International Conference on Software Maintenance, ICSM'06, 2006 (available on-line at http://www/~thomasos/paper/osterlie_establishing.pdf
"... This paper investigates how maintainability can be established in system integration (SI) projects where maintainers have no direct access to the source code of the third-party software being integrated. We propose a model for maintainability in SI focusing on postrelease activities, unlike traditio ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
(Show Context)
This paper investigates how maintainability can be established in system integration (SI) projects where maintainers have no direct access to the source code of the third-party software being integrated. We propose a model for maintainability in SI focusing on postrelease activities, unlike traditional maintainability models where focus is on pre-release activities. Our model describes maintainability as a process characterized by ambiguity and negotiation that is supported through an infrastructure of debugging and coordination tools. Further, we describe how the process going from a software failure to establishing the fault causing the failure can be managed in SI. The results presented in this paper are based on observations from an ethnographic study of the Gentoo open source software (OSS) community, a large distributed volunteer community of over 320 developers developing and maintaining a software system for distributing and integrating third-party OSS software packages with different Unix versions. 1.
An industrial case of exploiting product line architectures in agile software development
- in Software Product Line Conference (SPLC), 2009
"... There has been an increased interest in exploring the ways of integrating agile software development and software product line approaches. Both approaches share several common goals, which provide the motivation for integrating them. However, there has been little empirical research for understandin ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
(Show Context)
There has been an increased interest in exploring the ways of integrating agile software development and software product line approaches. Both approaches share several common goals, which provide the motivation for integrating them. However, there has been little empirical research for understanding how these approaches can be integrated in industrial settings. This paper presents the findings from a case study of a software development company that has successfully integrated software product line architecture and agile software development practices. The company’s processes are described based on product line and agile practices. The results are expected to provide useful insights into the mechanics of exploiting product line practices in agile software development despite apparent philosophical clashes between the two approaches.
