Search

One of the reasons for the lack of rigor in software engineering compared to physical and behavioral sciences is that the theories that underpin our work, both as software engineers and as software engineering researchers, have not been given enough attention. To provide a step forward towards greater rigor, a framework has been created with which to explore theories of software engineering and software engineering research. This framework provides a simple theory modeling language and model calculus to explore informally described theories and to generate the results of composing modeled theories. To illustrate and evaluate this framework, a general theory about software engineering is presented and then two simple theories, D and E, are proposed as the basis for laying out a unified theoretical foundation for software engineering and software engineering research. Software Engineering consists of two logical parts: design, and empirical evaluation (both terms used in their broadest senses). Theory D is the theoretical basis for the design part, and theory E is the theoretical basis for empirical evaluation. These two theories are then composed in various ways to lay out a space (a taxonomy, or ontology if you will) for software engineering and software engineering research. Finally, it is claimed that software engineering and software engineering research (both fully integrated with empirical evaluations) are models (in the logical sense) for these atomic and composed theories. To further evaluate the framework, examples are provided of modeling (implicit) theories found in a number of software engineering (theory) papers. The results of this research are: 1) a scientific elegance in creating larger more complex theories out of simpler theories, 2) an elegant way of explaining the complexity of software engineering and software engineering research, and 3) a theory modeling language and model calculus for composing the resulting theoretical models. [ABSTRACT FROM AUTHOR]

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development, maintenance, and evolution. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes by focusing on the properties of the changes rather than the properties of the code itself. Our study reveals that 1) there is less than 4 percent probability that a one-line change will introduce a fault in the code, 2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes, 3) nearly 50 percent of the changes were small changes, 4) nearly 40 percent of changes to fix faults resulted in further faults, 5) the phenomena of change differs for additions, deletions, and modifications as well as for the number of lines affected, and 6) deletions of up to 10 lines did not cause faults. [ABSTRACT FROM AUTHOR]

We have found that, when software is developed by multiple, geographically separated teams, the cost-benefit trade-offs of software inspection change. In particular, this situation can significantly lengthen the inspection interval (calendar time needed to complete an inspection). Our research goal was to find a way to reduce the inspection interval without reducing inspection effectiveness. We believed that Internet technology offered some potential solutions, but we were not sure which technology to use nor what effects it would have on effectiveness. To conduct this research, we drew on the results of several empirical studies we had previously performed. These results clarified the role that meetings and individuals play in inspection effectiveness and interval. We conducted further studies showing that manual inspections without meetings were just as effective as manual inspections with them. On the basis of these and other findings and our understanding of Internet technology, we built an economical and effective tool that reduced the interval without reducing effectiveness. This tool, Hypercode, supports meetingless software inspections with geographically distributed reviewers. HyperCode is a platform independent tool, developed on top of an Internet browser, that integrates seamlessly into the current development process. By seamless, we mean the tool produces a paper flow that is almost identical to the current inspection process. HyperCode's acceptance by its user community has been excellent. Moreover, we estimate that using HyperCode has reduced the inspection interval by 20 to 25 percent. We believe that, had we focused solely on technology (without considering the information our studies had uncovered), we would have created a more complex, but not necessarily more effective tool. We probably would have supported group meetings, restricted each participant's access to review comments, and supported a wider variety of inspection methods. In other words, the principles derived from our empirical studies dramatically and successfully directed our search for a technological solution. [ABSTRACT FROM AUTHOR]

A critical aspect of the design for any large software system is its gross structure represented as a high-level organization of computational elements and interactions between those elements. The structure of the software has long been recognized as an important issue of concern. However, software architecture has begun to emerge as an explicit field of study for software engineering practitioners and researchers.

Features are often the basic unit of development for a very large software system and represent long-term efforts, spanning up to several years from inception to actual use. Developing an experiment to monitor (by means of sampling) such lengthy processes requires a great deal of care in order to minimize costs and to maximize benefits. Just as prototyping is often a necessary auxiliary step in a large-scale, long-term development effort, so, too, is prototyping a necessary step in the development of a large-scale, long-term process monitoring experiment. Therefore, we have prototyped our experiment using a representative process and reconstructed data from a large and rich feature development. This approach has yielded three interesting sets of results. First, we reconstructed a 30-month time diary for the lead engineer of a feature composed of both hardware and software. These data represent the daily state (where the lead engineer spent the majority of his time) for a complete cycle of the development process. Second, we found that we needed to modify our experimental design. Our initial set of states did not represent the data as well as we had hoped. This is exemplified by the fact that the "Other" category is too large. Finally, the data provide evidence for both a waterfall view and an interactive, cyclic view of software development. We conclude that the prototyping effort is a necessary part of developing and installing any large-scale process monitoring experiment. [ABSTRACT FROM AUTHOR]

We present a general model of software development environments that consists of three components: structures, mechanisms, and policies. The advantage of this model is that it distinguishes intuitively those aspects of an environment that are useful in comparing and contrasting software development environments. Our initial application of the model is to characterize four classes of environments by means of a sociological metaphor based on scale: the individual, the family, the city, and the state models. The utility of the IFCS taxonomy is that it delineates the important classes of interactions among software developers and exposes the ways in which current software development environments inadequately support the development of large systems. We demonstrate the generality of our model by also applying it to a previously published taxonomy that categorizes environments according to how they relate to four historical trends: language-centered, structure-oriented, toolkit, and method-based environments. [ABSTRACT FROM AUTHOR]

Focuses on a study which described experiments to enhance understanding of the structure of software-development processes with the goal of reducing the process-development interval. Special measurement concerns on software development processes; Purpose of documenting an organization's dimensions.

The article introduces the September 2000 issue of the journal, IEEE Transactions on Software Engineering. The importance of exception handling is well-recognized by system designers and software engineers. Exception handling is very often the most important part of the system because it deals with abnormal situations. This special issue of the journal concentrates on exception handling. Out of 39 submissions of paper on exception handling 9 articles were selected for publication in this journal. These papers represent the important research directions and issues in exception handling in a broad range of disciplines, such as operating system, programming languages, workflow systems and spreadsheet programs. This special issue is published in two parts. The first part includes papers which focus on traditional issues which focus on traditional issues related to programming languages, program design testing and empirical studies.

The article presents guest editorial, published in the May 2000 issue of the periodical "IEEE Transactions on Software Engineering," vol. 26, no. 5. The Fifth International Conference on Software Reuse that was held in Victoria B.C., Canada, included papers, mini-workshops, panels, and tutorials dedicated to various aspects of the software reuse enterprise, software architecture, and reuse over the Internet. Out of the 31 papers that were presented, a select few were nominated by the program committee as representing special, innovative contributions. In addition to that the article presents information on the two papers related to major technological approaches to software reuse. The first paper, considers the problem of selecting the best realizations and algorithms for a general purpose data structure. The second paper, is concerned with the problem of adapting class libraries for specific requirements.

The article presents an introduction to the special issue of the 9th International Conference on Software and Systems Process (ICSSP) 2016, which was held in Austin, Texas, from May 14 to 15, 2016. It is noted that ICSSP 2016 panel entitled "Process in Action" was moderated by professor Leon Osterweil to discuss current challenges in process evolution and application in real-world.

The article presents commentary from DeWayne E. Perry of the University of Texas at Austin on mining software repositories (MSR). In his view many opportunities exist for future implementation of MSR, particularly in the area of prospective studies. He sees MSR as having value in experimental approaches aimed at improving analysis and testing.

Software evolution is an increasingly challenging and compelling concern for every developed software system because of the changes in the requirements, the technology, etc. When software evolution is carried out, software architecture emerges as one of the cornerstones that should be considered from two different points of view: as an artifact for the evolution, as it helps the architect plan and restructure the system, and as an artifact of the evolution, because it has to be modified as well. This paper focuses on the second point of view--that is, on the evolution of the software architecture, but taking into account architectural knowledge as a key driver of the process. Given that architecture rationale and design intent are critical in evolving software systems, it is imperative that they be captured in some useful form to aid that evolution process. We present a new approach for evolution styles that extends them by considering in their description the architectural knowledge as a valuable asset of the evolution process. [ABSTRACT FROM AUTHOR]

Presents an introduction to the July 2005 issue of the journal "IEEE Software."

The authors reflect on the works of professor Meir M. "Manny" Lehman known as "Father of Software Evolution." They state that after the best known work of Lehman, which is the Laws of Software Evolution, software engineering recognized the need for continuous changes to real-world software systems to satisfy new and evolving user requirements and expectations to adapt to technological innovation. They add that laws formulated by Lehman provided useful insights to understanding software process.