jehanweerasuriya/uni-ai-dataset huggingface dataset:
Guidelines for conducting and reporting case study research in software engineering
Authors: Per Runeson, Martin Höst
Published in: Empirical Software Engineering (2008-12-18)

Case study is a suitable research methodology for software engineering research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims at providing an introduction to case study methodology and guidelines for researchers conducting case studies and readers studying reports of such studies. The content is based on the authors’ own experience from conducting and reading case studies. The terminology and guidelines are compiled from different methodology handbooks in other research domains, in particular social science and information systems, and adapted to the needs in software engineering. We present recommended practices for software engineering case studies as well as empirically derived and evaluated checklists for researchers and readers of case study research.
No Silver Bullet Essence and Accidents of Software Engineering
Authors: Brooks
Published in: Computer (1987-04-01)

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed.
Object Oriented Software Engineering: A Use Case Driven Approach
Authors: Ivar Jacobson
Published in:  (1992-01-01)

Part 1. Introduction 1. System development as an industrial process Introduction A useful analogy System development characteristics Summary 2. The system life cycle Introduction System development as a process of change System development and reuse System development and methodology Objectory Summary 3. What is object-orientation? Introduction Object Class andinstance Polymorphism Inheritance Summary 4. Object-oriented system development Introduction Function/data methods Object-oriented analysis Object-oriented construction Object-oriented testing Summary 5. Object-oriented programming Introduction Objects Classes and instances Inheritance Polymorphism An example Summary Part II. Concepts 6. Architecture Introduction System development is model building Model architecture Requirements model Analysis model The design model The implementation model Test model Summary 7. Analysis Introduction The requirements model The analysis model Summary 8. Construction Introduction The design model Block design Working with construction Summary 9. Real-time specialization Introduction Classification of real-time systems Fundamental issues Analysis Construction Testing and verification Summary 10. Database Specialization Introduction Relational DBMS Object DBMS Discussion Summary 11. Components Introduction What is a component? Use of components Component management Summary 12. Testing Introduction On testing Unit testing Integration testing System testing The testing process Summary Part III. Applications 13. Case study: warehouse management system Introduction to the examples ACME Warehouse Management Inc. The requirements model The analysis model Construction 14. Case study: telecom Introduction Telecommunication switching systems The requirements model The analysis model The design model The implementation model 15. Managing object-oriented software engineering Introduction Project selection and preparation Project development organization Project organization and management Project staffing Software quality assurance Software metrics Summary 16. Other object-oriented methods Introduction A summary of object-oriented methods Object-Oriented Analysis (OOAD/Coad-Yourdon) Object-Oriented Design (OOD/Booch) Hierarchical Object-Oriented Design (HOOD) Object Modeling Technique (OMT) Responsibility-Driven Design Summary Appendix A On the development of Objectory Introduction Objectory as an activity From idea to reality References Index
Preliminary guidelines for empirical research in software engineering
Authors: Barbara Kitchenham, Shari Lawrence Pfleeger, Lesley M. Pickard, Peter W. Jones, David C. Hoaglin, K. El Emam, Jarrett Rosenberg
Published in: IEEE Transactions on Software Engineering (2002-08-01)

Empirical software engineering research needs research guidelines to improve the research and reporting processes. We propose a preliminary set of research guidelines aimed at stimulating discussion among software researchers. They are based on a review of research guidelines developed for medical researchers and on our own experience in doing and reviewing software engineering research. The guidelines are intended to assist researchers, reviewers, and meta-analysts in designing, conducting, and evaluating empirical studies. Editorial boards of software engineering journals may wish to use our recommendations as a basis for developing guidelines for reviewers and for framing policies for dealing with the design, data collection, and analysis and reporting of empirical studies.
Qualitative methods in empirical studies of software engineering
Authors: Carolyn Seaman
Published in: IEEE Transactions on Software Engineering (1999-07-01)

While empirical studies in software engineering are beginning to gain recognition in the research community, this subarea is also entering a new level of maturity by beginning to address the human aspects of software development. This added focus has added a new layer of complexity to an already challenging area of research. Along with new research questions, new research methods are needed to study nontechnical aspects of software engineering. In many other disciplines, qualitative research methods have been developed and are commonly used to handle the complexity of issues involving human behaviour. The paper presents several qualitative methods for data collection and analysis and describes them in terms of how they might be incorporated into empirical studies of software engineering, in particular how they might be combined with quantitative methods. To illustrate this use of qualitative methods, examples from real software engineering studies are used throughout.
On "Software engineering"
Authors: E. N. Miya
Published in: ACM SIGSOFT Software Engineering Notes (1985-01-01)

No abstract available.
Search-based software engineering
Authors: Mark Harman, S. Afshin Mansouri, Yuanyuan Zhang
Published in: ACM Computing Surveys (2012-11-01)

In the past five years there has been a dramatic increase in work on Search-Based Software Engineering (SBSE), an approach to Software Engineering (SE) in which Search-Based Optimization (SBO) algorithms are used to address problems in SE. SBSE has been applied to problems throughout the SE lifecycle, from requirements and project planning to maintenance and reengineering. The approach is attractive because it offers a suite of adaptive automated and semiautomated solutions in situations typified by large complex problem spaces with multiple competing and conflicting objectives. This article 1 provides a review and classification of literature on SBSE. The work identifies research trends and relationships between the techniques applied and the applications to which they have been applied and highlights gaps in the literature and avenues for further research.
Agent-based software engineering
Authors: Michael Wooldridge
Published in: IEE Proceedings - Software Engineering (1997-01-01)

The technology of intelligent agents and multi-agent systems is expected to alter radically the way in which complex, distributed, open systems are conceptualised and implemented. The paper considers the problem of building a multi-agent system as a software engineering enterprise. Three issues are focused on: how agents might be specified; how these specifications might be refined or otherwise transformed into efficient implementations; and how implemented agents and multi-agent systems might subsequently be verified, to show that they are correct with respect to their specifications. These issues are discussed with reference to a number of case studies. The paper concludes by setting out some issues and open problems for future research.
An open graph visualization system and its applications to software engineering
Authors: Emden R. Gansner, Stephen C. North
Published in: Software Practice and Experience (2000-09-01)

We describe a package of practical tools and libraries for manipulating graphs and their drawings. Our design, which is aimed at facilitating the combination of the package components with other tools, includes stream and event interfaces for graph operations, high-quality static and dynamic layout algorithms, and the ability to handle sizeable graphs. We conclude with a description of the applications of this package to a variety of software engineering tools. Copyright © 2000 John Wiley & Sons, Ltd.
A Methodology for Collecting Valid Software Engineering Data
Authors: Victor R. Basili, David M. Weiss
Published in: IEEE Transactions on Software Engineering (1984-11-01)

An effective data collection method for evaluating software development methodologies and for studying the software development process is described. The method uses goal-directed data collection to evaluate methodologies with respect to the claims made for them. Such claims are used as a basis for defining the goals of the data collection, establishing a list of questions of interest to be answered by data analysis, defining a set of data categorization schemes, and designing a data collection form. The data to be collected are based on the changes made to the software during development, and are obtained when the changes are made. To ensure accuracy of the data, validation is performed concurrently with software development and data collection. Validation is based on interviews with those people supplying the data. Results from using the methodology show that data validation is a necessary part of change data collection. Without it, as much as 50 percent of the data may be erroneous. Feasibility of the data collection methodology was demonstrated by applying it to five different projects in two different environments. The application showed that the methodology was both feasible and useful.
Software Engineering
Authors: Boehm
Published in: IEEE Transactions on Computers (1976-12-01)

This paper provides a definition of the term "software engineering" and a survey of the current state of the art and likely future trends in the field. The survey covers the technology available in the various phases of the software life cycle—requirements engineering, design, coding, test, and maintenance—and in the overall area of software management and integrated technology-management approaches. It is oriented primarily toward discussing the domain of applicability of techniques (where and when they work), rather than how they work in detail. To cover the latter, an extensive set of 104 references is provided.
The guide to the Software Engineering Body of Knowledge
Authors: Pierre Bourque, R. Dupuis, Alain Abran, J.W. Moore, L. Tripp
Published in: IEEE Software (1999-01-01)

Reporting on the SWEBOK project, the authors-who represent the project's editorial team-discuss the three-phase plan to characterize a body of knowledge, a vital step toward developing software engineering as a profession.
Experimentation in software engineering
Authors: Victor R. Basili, Richard W. Selby, David H. Hutchens
Published in: IEEE Transactions on Software Engineering (1986-07-01)

A framework is presented for analyzing most of the experimental work performed in software engineering over the past several years. The framework of experimentation consists of four categories corresponding to phases of the experimentation process: definition, planning, operation, and interpretation. A variety of experiments are described within the framework and their contribution to the software engineering discipline is discussed. Some recommendations for the application of the experimental process in software engineering are included.
A survey of controlled experiments in software engineering
Authors: D.I.K. Sjoeberg, Jo Erskine Hannay, Ole Hansen, Vigdis By Kampenes, Amela Karahasanović, Nils-Kristian Liborg, A.C. Rekdal
Published in: IEEE Transactions on Software Engineering (2005-09-01)

The classical method for identifying cause-effect relationships is to conduct controlled experiments. This paper reports upon the present state of how controlled experiments in software engineering are conducted and the extent to which relevant information is reported. Among the 5,453 scientific articles published in 12 leading software engineering journals and conferences in the decade from 1993 to 2002, 103 articles (1.9 percent) reported controlled experiments in which individuals or teams performed one or more software engineering tasks. This survey quantitatively characterizes the topics of the experiments and their subjects (number of subjects, students versus professionals, recruitment, and rewards for participation), tasks (type of task, duration, and type and size of application) and environments (location, development tools). Furthermore, the survey reports on how internal and external validity is addressed and the extent to which experiments are replicated. The gathered data reflects the relevance of software engineering experiments to industrial practice and the scientific maturity of software engineering research.
Case Study Research in Software Engineering: Guidelines and Examples
Authors: Per Runeson, Martin Höst, Austen Rainer, Björn Regnell
Published in:  (2012-03-07)

Based on their own experiences of in-depth case studies of software projects in international corporations, in this book&amp;nbsp;the authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering.&amp;nbsp; This is the first software engineering specific book on the&amp;nbsp;case study research method.
Evidence-based software engineering
Authors: Barbara Kitchenham, Tore Dybå, Magne Jørgensen
Published in:  (2004-05-23)

Objective: Our objective is to describe how software engineering might benefit from an evidence-based approach and to identify the potential difficulties associated with the approach. Method: We compared the organisation and technical infrastructure supporting evidence-based medicine (EBM) with the situation in software engineering. We considered the impact that factors peculiar to software engineering (i.e. the skill factor and the lifecycle factor) would have on our ability to practice evidence-based software engineering (EBSE). Results: EBSE promises a number of benefits by encouraging integration of research results with a view to supporting the needs of many different stakeholder groups. However, we do not currently have the infrastructure needed for widespread adoption of EBSE. The skill factor means software engineering experiments are vulnerable to subject and experimenter bias. The lifecycle factor means it is difficult to determine how technologies will behave once deployed. Conclusions: Software engineering would benefit from adopting what it can of the evidence approach provided that it deals with the specific problems that arise from the nature of software engineering. 1.
Property-based software engineering measurement
Authors: Lionel Briand, Sandro Morasca, Victor R. Basili
Published in: IEEE Transactions on Software Engineering (1996-01-01)

Little theory exists in the field of software system measurement. Concepts such as complexity, coupling, cohesion or even size are very often subject to interpretation and appear to have inconsistent definitions in the literature. As a consequence, there is little guidance provided to the analyst attempting to define proper measures for specific problems. Many controversies in the literature are simply misunderstandings and stem from the fact that some people talk about different measurement concepts under the same label (complexity is the most common case). There is a need to define unambiguously the most important measurement concepts used in the measurement of software products. One way of doing so is to define precisely what mathematical properties characterize these concepts, regardless of the specific software artifacts to which these concepts are applied. Such a mathematical framework could generate a consensus in the software engineering community and provide a means for better communication among researchers, better guidelines for analysts, and better evaluation methods for commercial static analyzers for practitioners. We propose a mathematical framework which is generic, because it is not specific to any particular software artifact, and rigorous, because it is based on precise mathematical concepts. We use this framework to propose definitions of several important measurement concepts (size, length, complexity, cohesion, coupling). It does not intend to be complete or fully objective; other frameworks could have been proposed and different choices could have been made. However, we believe that the formalisms and properties we introduce are convenient and intuitive. This framework contributes constructively to a firmer theoretical ground of software measurement.
The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering
Authors: Daniel L. Moody
Published in: IEEE Transactions on Software Engineering (2009-11-01)

Visual notations form an integral part of the language of software engineering (SE). Yet historically, SE researchers and notation designers have ignored or undervalued issues of visual representation. In evaluating and comparing notations, details of visual syntax are rarely discussed. In designing notations, the majority of effort is spent on semantics, with graphical conventions largely an afterthought. Typically, no design rationale, scientific or otherwise, is provided for visual representation choices. While SE has developed mature methods for evaluating and designing semantics, it lacks equivalent methods for visual syntax. This paper defines a set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving. Together these form a design theory, called the Physics of Notations as it focuses on the physical (perceptual) properties of notations rather than their logical (semantic) properties. The principles were synthesized from theory and empirical evidence from a wide range of fields and rest on an explicit theory of how visual notations communicate. They can be used to evaluate, compare, and improve existing visual notations as well as to construct new ones. The paper identifies serious design flaws in some of the leading SE notations, together with practical suggestions for improving them. It also showcases some examples of visual notation design excellence from SE and other fields.
IEEE Transactions on Software Engineering
Published in: IEEE Transactions on Computers (1978-03-01)

The definition for sequence dominance which appears in the above paper1should be rephrased precisely and unambiguously as follows:
Knowledge management in software engineering
Authors: Ioana Rus, Mikael Lindvall
Published in: IEEE Software (2002-05-01)

Software organizations’ main assets are not plants, buildings, or&#13;\nexpensive machines. A software organization’s main asset is its intellectual&#13;\ncapital, as it is in sectors such as consulting, law, investment&#13;\nbanking, and advertising. The major problem with intellectual&#13;\ncapital is that it has legs and walks home every day. At the same rate&#13;\nexperience walks out the door, inexperience walks in the door. Whether or&#13;\nnot many software organizations admit it, they face the challenge of sustaining the level of competence needed to&#13;\nwin contracts and fulfill undertakings.
The state of the art in end-user software engineering
Authors: Amy J. Ko, Robin Abraham, Laura Beckwith, Alan F. Blackwell, Margaret Burnett, Martin Erwig, Chris Scaffidi, Joseph Lawrance, Henry Lieberman, Brad A. Myers, Mary Beth Rosson, Gregg Rothermel, Mary Shaw, Susan Wiedenbeck
Published in: ACM Computing Surveys (2011-04-01)

Most programs today are written not by professional software developers, but by people with expertise in other domains working towards goals for which they need computational support. For example, a teacher might write a grading spreadsheet to save time grading, or an interaction designer might use an interface builder to test some user interface design ideas. Although these end-user programmers may not have the same goals as professional developers, they do face many of the same software engineering challenges, including understanding their requirements, as well as making decisions about design, reuse, integration, testing, and debugging. This article summarizes and classifies research on these activities, defining the area of End-User Software Engineering (EUSE) and related terminology. The article then discusses empirical research about end-user software engineering activities and the technologies designed to support them. The article also addresses several crosscutting issues in the design of EUSE tools, including the roles of risk, reward, and domain complexity, and self-efficacy in the design of EUSE tools and the potential of educating users about software engineering principles.
Value-based software engineering
Authors: Barry Boehm
Published in: ACM SIGSOFT Software Engineering Notes (2003-03-01)

Much of current software engineering practice and research is done in a value-neutral setting, in which every requirement, use case, object, and defect is treated as equally important; methods are presented and practiced as largely logical activities; and a "separation of concerns" is practiced, in which the responsibility of software engineers is confined to turning software requirements into verified code. In earlier times, when software decisions had relatively minor influences on a system's cost, schedule, and value, the value-neutral approach was reasonably workable. But today and increasingly in the future, software has a major influence on most systems' cost, schedule, and value; and value-neutral software decisions can seriously degrade project outcomes.This paper presents an agenda for a discipline of Value-Based Software Engineering. It accepts the challenge of integrating value considerations into all of the existing and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. Example elements of this agenda include value-based requirements engineering, architecting, design and development, verification and validation, planning and control, risk management, quality management, and people management. It presents seven key elements that provide candidate foundations for value-based software engineering: Benefits Realization Analysis; Stakeholder Value Proposition Elicitation and Reconciliation; Business Case Analysis; Continuous Risk and Opportunity Management; Concurrent System and Software Engineering; Value-Based Monitoring and Control; and Change as Opportunity.