Studying the laws of software evolution in a long-lived FLOSS project

ome free, open-source software projects have been around for quite a long time, the longest living ones dating from the early 1980s. For some of them, detailed information about their evolution is available in source code management systems tracking all their code changes for periods of more than 15 years. This paper examines in detail the evolution of one of such projects, glibc, with the main aim of understanding how it evolved and how it matched Lehman's laws of software evolution. As a result, we have developed a methodology for studying the evolution of such long-lived projects based on the information in their source code management repository, described in detail several aspects of the history of glibc, including some activity and size metrics, and found how some of the laws of software evolution may not hold in this case

Definition of a support infrastructure for replicating and aggregating families of software engineering experiments

Experimental software engineering includes several processes, the most representative being run experiments, run replications and synthesize the results of multiple replications. Of these processes, only the first is relatively well established in software engineering. Problems of information management and communication among researchers are one of the obstacles to progress in the replication and synthesis processes. Software engineering experimentation has expanded considerably over the last few years. This has brought with it the invention of experimental process support proposals. However, few of these proposals provide integral support, including replication and synthesis processes. Most of the proposals focus on experiment execution. This paper proposes an infrastructure providing integral support for the experimental research process, specializing in the replication and synthesis of a family of experiments. The research has been divided into stages or phases, whose transition milestones are marked by the attainment of their goals. Each goal exactly matches an artifact or product. Within each stage, we will adopt cycles of successive approximations (generateand- test cycles), where each approximation includes a diferent viewpoint or input. Each cycle will end with the product approval.

Replications of software engineering experiments

There are many open issues that must be addressed before the replication process can be successfully formalized in empirical software engineering research. We define replication as the deliberate repetition of the same empirical study for the purpose of determining whether the results of the first experiment can be reproduced. This definition would appear at first glance to be good. However, it needs several clarifications that have not yet been forthcoming in software engineering: – What is the exact meaning of the same empirical study? Namely how similar should an experiment be to the baseline study for it to be considered a replication? What is the exact meaning of a result being reproduced? Namely how similar does a result have to be to the result of the baseline study for it to be considered reproduced? These and other methodological questions need to be researched and tailored for empirical software engineering.

Looking for the Holy Grail of Software Development

The history of Software Engineering has been marked by many famous project failures documented in papers, articles and books. This pattern of lack of success has prompted the creation of dozens of software analysis, requirements definition, and design methods, programming languages, software development environments and software development processes all promoted as solving ?the software problem.? What we hear less about are software projects that were successful. This article reports on the findings of an extensive analysis of successful software projects that have been reported in the literature. It discusses the different interpretations of success and extracts the characteristics that successful projects have in common. These characteristics provide Software Project Managers with an agenda of topics to be addressed that will help ensure, not guarantee, that their software project will be successful.

Explora: A Visualisation Tool for Metric Analysis of Software Corpora

When analysing software metrics, users find that visualisation tools lack support for (1) the detection of patterns within metrics; and (2) enabling analysis of software corpora. In this paper we present Explora, a visualisation tool designed for the simultaneous analysis of multiple metrics of systems in software corpora. Explora incorporates a novel lightweight visualisation technique called PolyGrid that promotes the detection of graphical patterns. We present an example where we analyse the relation of subtype polymorphism with inheritance and invocation in corpora of Smalltalk and Java systems and find that (1) subtype polymorphism is more likely to be found in large hierarchies; (2) as class hierarchies grow horizontally, they also do so vertically; and (3) in polymorphic hierarchies the length of the name of the classes is orthogonal to the cardinality of the call sites.

Final report -- a survey of software tools usage /

S/N 003-003-02378-7

SAGA, a system to automate the management of software production /

"UILU-ENG 81 1702"--Cover.

Features of software development tools /

Item 247.

Highway engineering software and source book : a synthesis of software programs available for the Victor 9000 microcomputer.

Mode of access: Internet.

SubCM: A tool for improved visibility of software change in an industrial setting

Software Configuration Management is the discipline of managing large collections of software development artefacts from which software products are built. Software configuration management tools typically deal with artefacts at fine levels of granularity - such as individual source code files - and assist with coordination of changes to such artefacts. This paper describes a lightweight tool, designed to be used on top of a traditional file-based configuration management system. The add-on tool support enables users to flexibly define new hierarchical views of product structure, independent of the underlying artefact-repository structure. The tool extracts configuration and change data with respect to the user-defined hierarchy, leading to improved visibility of how individual subsystems have changed. The approach yields a range of new capabilities for build managers, and verification and validation teams. The paper includes a description of our experience using the tool in an organization that builds large embedded software systems.

The role of software tools in influencing creative problem solving in engineering design and education

Creativity is increasingly recognised as an essential component of engineering design. This paper describes an exploratory study into the nature and importance of creativity in engineering design problem solving in relation to the possible impact of software design tools. The first stage of the study involved an empirical investigation in the form of a case study of the use of standard CAD tool sets and the development of a systems engineering software support tool. It was found that there were several ways in which CAD influenced the creative process, including enhancing visualisation and communication, premature fixation, circumscribed thinking and bounded ideation. The tool development experience uncovered the difficulty in supporting creative processes from the developer's perspective. The issues were the necessity of making assumptions, achieving a balance between structure and flexibility, and the pitfalls of satisfying user wants and needs. The second part of the study involved the development of a model of the creative problem solving process in engineering design. This provided a possible explanation for why purpose designed engineering software tools might encourage an analytical problem solving approach and discourage a more creative approach.