Paul Wernick

Metrics and laws of software evolution-the nineties view

The process of E-type software development and evolution has proven most difficult to improve, possibly due to the fact that the process is a multi-input, multi-output system involving feedback at many levels. This observation, first recorded in the early 1970s during an extended study of OS/360 evolution, was recently captured in a FEAST (Feedback, Evolution And Software Technology) hypothesis: a hypothesis being studied in on-going two-year project, FEAST/1. Preliminary conclusions based on a study of a financial transaction system-Logicas Fastwire (FW)-are outlined and compared with those reached during the earlier OS/360 study. The new analysis supports, or better does not contradict, the laws of software evolution, suggesting that the 1970s approach to metric analysis of software evolution is still relevant today. It is hoped that FEAST/1 will provide a foundation for mastering the feedback aspects of the software evolution process, opening up new paths for process modelling and improvement.

Evolution in software systems: foundations of the SPE classification scheme

This paper re-examines the SPE taxonomy of evolving software systems, first proposed in 1980 (Lehman). It builds on the concept that software evolution is related to generic theories of evolution. A refinement of SPE is proposed that has provided a more productive basis for developing testable hypotheses and models about possible differences in the evolution of software systems than was provided by the original scheme.

Software process change

Keynotes.- A Value-Based Software Process Framework.- Exploring the Business Process-Software Process Relationship.- Assessing 3-D Integrated Software Development Processes: A New Benchmark.- Ubiquitous Process Engineering: Applying Software Process Technology to Other Domains.- Process Tailoring and Decision-Support.- Dependencies Between Data Decisions.- Tailor the Value-Based Software Quality Achievement Process to Project Business Cases.- Optimizing Process Decision in COTS-Based Development Via Risk Based Prioritization.- Process Tools and Metrics.- Project Replayer - An Investigation Tool to Revisit Processes of Past Projects.- Software Process Measurement in the Real World: Dealing with Operating Constraints.- Evaluation of Project Quality: A DEA-Based Approach.- Process Management.- A Pattern-Based Solution to Bridge the Gap Between Theory and Practice in Using Process Models.- On Mobility of Software Processes.- Software Process Fusion: Uniting Pair Programming and Solo Programming Processes.- Towards an Approach for Security Risk Analysis in COTS Based Development.- COCOMO-U: An Extension of COCOMO II for Cost Estimation with Uncertainty.- A Product Line Enhanced Unified Process.- Process Representation, Analysis and Modeling.- Automatic Fault Tree Derivation from Little-JIL Process Definitions.- Workflows and Cooperative Processes.- Spiral Lifecycle Increment Modeling for New Hybrid Processes.- Definition and Analysis of Election Processes.- The Design of a Flexible Software Process Language.- Building Business Process Description and Reasoning Meta-model M bp in A-Prolog.- A Process-Agent Construction Method for Software Process Modeling in SoftPM.- Applying Little-JIL to Describe Process-Agent Knowledge in SoftPM.- Process Simulation Modeling.- Reusable Model Structures and Behaviors for Software Processes.- Organization-Theoretic Perspective for Simulation Modeling of Agile Software Processes.- Semi-quantitative Simulation Modeling of Software Engineering Process.- Process Simulation Applications.- Analysis of Software-Intensive System Acquisition Using Hybrid Software Process Simulation.- Simulation-Based Stability Analysis for Software Release Plans.- Exploring the Impact of Task Allocation Strategies for Global Software Development Using Simulation.- Users and Developers: An Agent-Based Simulation of Open Source Software Evolution.- Simulating the Structural Evolution of Software.- Experience Report.- An Empirical Study on SW Metrics for Embedded System.- Process-Family-Points.- Automated Recognition of Low-Level Process: A Pilot Validation Study of Zorro for Test-Driven Development.- Process Evolution Supported by Rationale: An Empirical Investigation of Process Changes.- Implementing Process Change in a Software Organization - An Experience Based Study.- Practical Experiences of Cost/Schedule Measure Through Earned Value Management and Statistical Process Control.

System dynamics modelling of software evolution processes for policy investigation: Approach and example

Abstract This paper describes one of the latest in a series of system dynamics models developed during the Feedback, Evolution And Software Technology (FEAST) investigation into software evolution processes. The intention of early models was to simulate real-world processes in order to increase understanding of such processes. The work resulted in a number of lessons learnt, in particular, with regard to the application of system dynamics to the simulation of key attributes of long-term software evolution. The work reported here combines elements of previous work and extends them by describing an approach to investigate the consequences on long-term evolution, of decisions made by the managers of these processes. The approach is illustrated by discussion of the impact of complexity control activity. This model of the impact on product and global process attributes of decisions regarding the fraction of work applied to progressive and to anti-regressive activities such as complexity control, for instance, exemplifies the results of the FEAST investigation.

The impact of using pair programming on system evolution a simulation-based study

We investigate the impact of pair programming on the long term evolution of software systems. We use system dynamics to build simulation models which predict the trend in system growth with and without pair programming. Initial results suggest that the extra effort needed for two people to code together may generate sufficient benefit to justify pair programming.

Can Thomas Kuhn's paradigms help us understand software engineering?

Recent articles in EJIS have discussed whether or not Information Systems is a ‘discipline’. In The Structure of Scientific Revolutions, Kuhn states that a scientific discipline can be identified by reference to its underlying belief system, the ‘paradigm’ or ‘disciplinary matrix’, to which all workers in that field must commit. An important element of Kuhns model is the notion of ‘scientific communities’. We consider here the belief system underlying Software Engineering (SE). We examine the extent to which a belief system analogous to the disciplinary matrix of a Kuhnian science can be identified in SE. Our preliminary fieldwork has comprised an examination of books used by SE students and practitioners, and in-depth interviews with a number of practitioners. The results of this study suggest that the current status of the theory of SE parallels Kuhns ‘pre-paradigm’ stage of scientific development. At this early stage, theorists and practitioners are divided into schools. These schools are based on differences in the beliefs and models forming their disciplinary matrices. We conclude that the application by analogy of Kuhns view of scientific activity to SE is justifiable. Our findings can assist both SE theorists and practitioners in improving the understanding of how and why software development projects succeed or fail. Our findings also provide a framework within which to place the beliefs, models and values which underlie SE. Such a framework can contribute to the discussion as to whether the software development-related aspects of Information Systems can be considered to be a discipline, and if so how that discipline is structured.

Software evolutionary dynamics modelled as the activity of an actor-network

The pressures which act on a software system over its life from inception to retirement are many and varied. It is an important goal in considering software evolvability to understand, and if possible to manage these influences. Our previous simulations of software evolution processes have concentrated on capturing the human-related aspects of software evolution, whilst effectively treating technical entities as objects which are acted on by humans and their organisations. Latours actor-network theory (ANT) suggests that the non-human entities - development tools, document, the system itself - are potentially active participants in their own evolution. We describe Latours theory, and present a model of a software evolution process in the form of a diagram which places technical and human aspects in juxtaposition closer to that which ANT would suggest than previous models. We believe that this approach will result in a more accurate representation of the process, and thus be a step towards dynamic simulation models whose predictive power will help us to better understand and manage software evolution and evolvability

How natural is natural language?: how well do computer science students write use cases?

Use cases are one of the most common mechanisms for describing and analyzing software system requirements. Due to use of natural language in use case descriptions, it is often assumed that they are easy to understand for stakeholders involved in the software development process [8]. However some authors argue [17,18] that the most common pitfalls of use cases written by professionals is that the customer does not understand them. In this paper we would like to consider whether it is appropriate to take their understandability to non-technically minded stakeholders for granted.We have analyzed 88 use cases written by final-year undergraduate computer science students for an assignment at the University of Hertfordshire and point out ways in which a computing-based mindset or way of thinking infiltrates the use cases, possibly making them difficult to understand for non-technical partners and hindering or pre-empting design decisions. We suggest that the problems we observed among students indicate a need for adding a new rule and/or guideline when teaching students to write good quality use cases, which is to ensure as far as possible that their use cases are free from computing-based structures and vocabulary. We also suggest ways in which students studying technical aspects of computer science might be led into practicing the use of non-technical language.

Software process simulation modelling: A survey of practice

In recent years, simulation modelling of software development processes has attracted considerable interest in software engineering. Despite the growing interest, there is little literature available that reports on the state-of-practice in software process simulation modelling (SPSM). We report results of a survey of simulation in SPSM and relate it to simulation practice in general. The results of this survey indicate that software process simulation (SPS) modellers are generally methodical, work on large complex problems, develop large models, and have a systematic simulation modelling process in place. However, on the other hand, the simulation modelling process and simulation model evaluation have been identified as the most urgent problems to be addressed in SPSM. The results from this investigation are interesting and bring many problems into focus. The paper helps understand the characteristics of the SPSM and SPS modellers, and highlights areas of interest for further in-depth research in the SPSM.

Evaluating three approaches to extracting fault data from software change repositories

Software products can only be improved if we have a good understanding of the faults they typically contain. Code faults are a significant source of software product problems which we currently do not understand sufficiently. Open source change repositories are potentially a rich and valuable source of fault data for both researchers and practitioners. Such fault data can be used to better understand current product problems so that we can predict and address future product problems. However extracting fault data from change repositories is difficult. In this paper we compare the performance of three approaches to extracting fault data from the change repository of the Barcode Open Source System. Our main findings are that we have most confidence in our manual evaluation of diffs to identify fault fixing changes. We had less confidence in the ability of the two automatic approaches to separate fault fixing from non-fault fixing changes. We conclude that it is very difficult to reliably extract fault fixing data from change repositories, especially using automatic tools and that we need to be cautious when reporting or using such data.