Search

Scientific presentations, usually given with slide presentation software such as PowerPoint™, are the most common method for disseminating knowledge to students and peers. Unfortunately, many are boring, text-heavy, and bullet point-riddled data dumps, with animations or cartoons that obscure or distract rather than clarify the message. These presentations, which we have all sat through and/or delivered, are often so dull that they are referred to as "death by PowerPoint™." In this paper, the authors intend to impart basic techniques for organizing and communicating information in the most effective, engaging, and actionable ways possible. We focus on three processes: generating ideas and outlining a talk, creating visually appealing uncluttered slides, and delivering an inspiring, practice-changing presentation. We also discuss considerations for a virtual presentation. We believe that even experienced speakers could benefit from reflecting on these recommendations and editing their slide presentations for clarity and simplicity.

It has been almost a third of a century since the world was caught up in a complex computing and software political clash. The clash was over something originally called the Strategic Defense Intiative (SDI), later somewhat-facetiously called "Star Wars," the notion of an anti-missile system that would shoot down an incoming enemy missile. The time was around the mid- 1980s. The two most vehement sides on the issue were - academic and theoretic computer science types, who thought it couldn't be done. - practitioner engineers and software people, who thought it could.

The capacity to reflect on past practice is important for continuous learning in software development. Reflection often takes place in cycles of experience followed by conscious application of learning from that experience, during which a software developer might explore comparisons, ponder alternatives, take diverse perspectives, and draw inferences, especially in new and/or complex situations. Such reflective practice has been shown in different disciplines to be an effective developmental practice for organizations, for teams, and for individuals. The guest editors of this special issue on reflection describe the concept in general and the selected articles in particular.

An ongoing, annual survey of publications in systems and software engineering identifies the top 15 scholars and institutions in the field over a 5-year period. Each ranking is based on the weighted scores of the number of papers published in TSE, TOSEM, JSS, SPE, EMSE, IST, and Software of the corresponding period. This report summarizes the results for 2003-2007 and 2004-2008. The top-ranked institution is Korea Advanced Institute of Science and Technology, Korea for 2003-2007, and Simula Research Laboratory, Norway for 2004-2008, while Magne Jorgensen is the top-ranked scholar for both periods.

This paper summarizes a survey of publications in the field of systems and software engineering from 2002 to 2006. The survey is an ongoing, annual event that identifies the top 15 scholars and institutions over a 5-year period. The rankings are calculated based on the number of papers published in TSE, TOSEM, JSS, SPE, EMSE, IST, and Software. The top-ranked institution is Korea Advanced Institute of Science and Technology, Korea, and the top-ranked scholar is Magne Jorgensen of Simula Research Laboratory, Norway.

Lying is an understudied activity, especially in the software field. Yet lying is apparently quite common. In a 2006 survey of software practitioners, 86 percent of the respondents had encountered such lying. The most common occurrences were in estimation and status reporting, with those forms of lying happening on 50 percent of projects, some respondents saying even 100 percent. Respondents said that when lying happens, developers at the bottom level of the management hierarchy are most aware of the lying; they often know it's happening even when their management doesn't. Respondents also provided numerous suggestions on how to diminish or eliminate lying. However, many suggested that it's human nature to lie and that little can be done about it.

This paper presents the findings of a five-year study of the top scholars and institutions in the systems and software engineering field, as measured by the quantity of papers published in the journals of the field in 2001-2005. The top scholar is Magne Jorgensen of Simula Research Laboratory, Norway, and the top institution is Korea Advanced Institute of Science and Technology, Korea. This paper is part of an ongoing study, conducted annually, that identifies the top 15 scholars and institutions in the most recent five-year period.

This paper presents the findings of a five-year study of the top scholars and institutions in the Systems and Software Engineering field, as measured by the quantity of papers published in the journals of the field in 2000-2004. The top scholar is Hai Zhuge of the Chinese Academy of Sciences, and the top institution is Korea Advanced Institute of Science and Technology. This paper is part of an ongoing study, conducted annually, that identifies the top 15 scholars and institutions in the most recent five-year period.

In this second installment of a three-part series, the succession of interconnected creative milestones is traced.

This paper presents the findings of a five-year study of the top scholars and institutions in the Systems and Software Engineering field, as measured by the quantity of papers published in the journals of the field. The top scholar is Khaled El Emam of the Canadian National Research Council, and the top institution is Carnegie Mellon University and its Software Engineering Institute.This paper is part of an ongoing study, conducted annually, that identifies the top 15 scholars and institutions in the most recent five-year period.

In this paper, we examine the state of computer science (CS) research from the point of view of the following research questions:1.What topics do CS researchers address? 2.What research approaches do CS researchers use? 3.What research methods do CS researchers use? 4.On what reference disciplines does CS research depend? 5.At what levels of analysis do CS researchers conduct research? To answer these questions, we examined 628 papers published between 1995 and 1999 in 13 leading research journals in the CS field. Our results suggest that while CS research examines a variety of technical topics it is relatively focused in terms of the level at which research is conducted as well as the research techniques used. Further, CS research seldom relies on work outside the discipline for its theoretical foundations. We present our findings as an evaluation of the state of current research and as groundwork for future CS research efforts.

This paper presents the findings of a five-year study of the top scholars and institutions in the Systems and Software Engineering field, as measured by the quantity of papers published in the journals of the field. The top scholar is Khaled El Emam of the Canadian National Research Council, and the top institution is Carnegie Mellon University and its Software Engineering Institute.This paper is part of an ongoing study, conducted annually, that identifies the top 15 scholars and institutions in the most recent five-year period.

In this paper, we examine the state of software engineering (SE) research from the point of view of the following research questions: 1. What topics do SE researchers address? 2. What research approaches do SE researchers use? 3. What research methods do SE researchers use? 4. On what reference disciplines does SE research depend? 5. At what levels of analysis do SE researchers conduct research? To answer those questions, we examined 369 papers in six leading research journals in the SE field, answering those research questions for each paper. From that examination, we conclude that SE research is diverse regarding topic, narrow regarding research approach and method, inwardly-focused regarding reference discipline, and technically focused (as opposed to behaviorally focused) regarding level of analysis. We pass no judgment on the SE field as a result of these findings. Instead, we present them as groundwork for future SE research efforts.

This paper presents the findings of a five-year study of the top scholars and institutions in the Systems and Software Engineering (SSE) field, as measured by the quantity of papers published in the journals of the field. The top scholar is Richard Lai of La Trobe University in Australia, and the top institution is Carnegie Mellon University (CMU) and its Software Engineering Institute. The paper lists the top 15 scholars and institutions.

This paper presents the findings of a five-year study of the top scholars and institutions in the Systems and Software Engineering field, as measured by the quantity of papers published in the journals of the field. The top scholar is Richard Lai of La Trobe University in Australia, and the top institution is Carnegie Mellon University and its Software Engineering Institute. The paper lists the top 15 scholars and institutions.

This article is a background report describing a comprehensive study of research in the three computing disciplines Computer Science, Software Engineering, and Information Systems. Findings relate to research topics, approaches, methods, reference disciplines, and levels of analysis. The article informally describes the process used and the research products produced.

Who are the most published authors in the field of systems and software engineering (SSE)? Which are the most published institutions? It is the intention of this article to answer those questions. It is the expectation of the Journal of Systems and Software to make this an annual event, publishing each year a cumulative summary of the most prolific authors and institutions in the field. The methodology of the study (including the journals surveyed) and its limitations will be discussed later. It is important to note here, however, that this study is clearly about SSE and not (for example) computer science or information systems. Both the study methodology and, as will be noted below, the findings, are deliberately and specifically different from what would have been learned in studies focused on those other disciplines. Here are the findings.

We've invited five renowned experts in software testing to give a brief answer to an admittedly broad question: does the practice of software testing effectively meet industry needs?

Who are the most published scholars in the field of Systems and Software Engineering (SSE)? Which are the most published institutions? This paper is the third in an annual series whose goal is to answer those questions. The first two such papers were [Glass 1994; 1995]. This article reports on the top scholars and institutions for the three-year period of 1993–1995. The methodology of the study, including the journals surveyed, and its limitations will be discussed later in this article. It is important to note, however, that this study focuses on systems and software engineering, and not, for example, on computer science or information systems. Here are the findings.

The computing literature contains much advice on new methods and technologies to improve the productivity and quality of the computing organization. But there is little research-generated evaluative evidence to support this advice, and the result is that the responsibility for evaluating new technology at present rests with those who will use it. Practitioner organizations tend to use pilot studies to perform this evaluation. But there is surprisingly little written on how to conduct such studies, and those studies that have been done are all too frequently either biased or inadequate, suggesting there is need for guidelines for the conduct of pilot studies. This article presents such guidelines, in the form of a detailed set of steps to be performed during a pilot study, with a rationale for why the steps are important and the consequences if they are omitted. The result of an evaluation of the guidelines on over two dozen government pilot studies is presented, showing that although the guidelines may be too rigorous, they form at least a foundation from which a useful set of steps for a particular pilot project might be tailored.

Examination of the three reasons offered for the decline of systems development—automation, delegation to users, and prepackaging—provides scant evidence that death is imminent.

This is a closed-book quiz. Quick, now - what percentage of software projects fail? Let me hazard a guess as to your answer. Odds are, you said something like "70 percent." Am I right? Now, I want to analyze why you said whatever you said. A friend of mine, Nicholas Zvegintzov (the Chief Guru of software maintenance), likes to say that, if you track down the sources of the things we "know" in our field, you'll find that what we thought was a plethora of sources for that knowledge generally boils down to only a precious few. That raises the question "Where do we get our information on software failure rates?" I've seen software failure trumpeted from so many academic research papers that I had to quit counting (they tend to see a "software crisis" and then say that the research work they're describing will help eliminate it). However, if you closely examine the citations they use to support the claims of crisis, over and over again the citations boil down to one primary source, the Standish Chaos Reports. And, if you take matters one step further, the papers generally cite the 1994 report. I want to question the unquestionable status of that Standish report. That's because, you see, my own observations lead me to believe that something is terribly wrong with those Standish findings.

This paper is the second in an annual series whose goal is to answer the questions Who are the most published authors in the field of systems and software engineering (SSE)? From which institutions do the most systems and software engineering published papers emerge? The first paper (Glass, 1994) in the series was published a year ago. The current study reports on the top scholars and institutions for the years 1993 and 1994. The methodology of the study (including the journals surveyed) and its limitations are discussed later in the paper. This study focuses on systems and software engineering and not, for example, on computer science or information systems. The findings are as follows.

With the advantage of more than 25 years' hindsight, this twenty-first century author looks askance at the "crisis" in software practice and expresses deep concern for a crisis in software research. >

It is the year 2010. The results of the application revolution have pretty well settled down In the world of systems and software engineering, and the application-focused paradigm is the way almost everyone is working. What was the application revolution? It was the realization—and the actions necessitated by it—that the construction of software was more application-dependent than we had previously understood.

This article summarizes a workshop organized and conducted by the authors on April 1 and 2, 1993, under the auspices of Portland State University and the Oregon Center for Advanced Technology Education. This workshop provided a uniquely comprehensive and realistic look at the state of the art and practice of object-oriented programming. Issues discussed at the workshop and summarized here include the naturalness of object-oriented technology, reuse potential, programming support and evaluation tools, and the cost of converting to an object-oriented design technology. The findings should be of interest to researchers, organizations, and individuals who are exploring and/or using the object-oriented approach to software development. The article concludes by offering some recommendations for the use of objectoriented technology.

There have been many successes over the years in defining and refining curricula’ for the related fields of computer science (CS), software engineering (SE), and information systems (IS) [l-12], but there have been surprisingly few attempts to compare and contrast those curricula. There are valid reasons for performing such an analysis. The three fields taken together represent much of academia’s coverage of the use of computers and the creation of software to solve problems (for other coverage, such as the field known as computer engineering, see section 2.4). It is important that this coverage be complete and cohesive. Even if in the beginning there was some sort of vital and planned interrelationship between the topics, their separate evolution may have resulted in undesirable couplings and lack of cohesion when considered from the broader computing perspective. Therefore it is important to ask several questions

There are two conflicting views of the complexity of software development: ‘anyone can do it’, or ‘it is the most complex activity the human mind has ever undertaken’. We address this difference empirically in two exploratory studies that examined the intellectual (non-routine) and clerical (routine) nature of software tasks. The first study sought to determine the proportion of software tasks that can be regarded as intellectual or clerical in nature. Taxonomics of software tasks were classified based on the assessment of highly experienced raters. The second study examined the length of time novice systems analysts spent in carrying out tasks during the information requirements specification phase of the systems development life cycle. The experiment used protocol and videotape analysis. Results show that the numbers of intellectual tasks in software development, and the time spent on those tasks, both predominate over clerical tasks by 4 to 1. These initial results suggest that even simple tasks are more intellectual than the ‘anyone can do it’ or the ‘software development can be automated’ viewpoints frequently expressed in the literature.

There is newly emerging interest in an application focused approach to progress in computer science and software engineering. We review the early history of interest in that topic, both in industry and in a professional society (the Association for Computing Machinery) and find a sequence of events that constitute a steady trend away from such application focus. We then ask, “Is it time to reevaluate this trend?” and suggest some directions for doing so. Special focus is placed on the need for a taxonomy of application domains. It is noted that the development of more meaningful taxonomies will not be easy.

Formal processes are increasingly recommended for those who build software. However, an analysis of the methods used by top software designers shows that cognitive, creative processes—in some ways the polar opposite of formal processes—are closer to the essence of the design task. Further analysis of the work of top designers exposes additional facts about design that challenge the traditional, textbook views. The implications of these findings to software builders are explored in this article.

It’s 2020, and IS enterprises have emerged from their relationship with outsourcing a bit wiser. Why did the relationship seem so promising, and what made the parties go their separate ways? Is there hope for a reconciliation?