Formalizing Rework in Software Processes

Abstract

Abstract. This paper indicates how effective software-process programming languages can lead to improved understandings of critical software processes, as well as improved process performance. In this paper we study the commonly mentioned, but seldom defined, rework process. We note that rework is generally understood to be a major software development activity, but note that it is poorly defined and understood. In this paper we use the vehicle of softwareprocess programming to elucidate the nature of this type of process. In doing so we demonstrate that an effective language (i.e. one incorporating appropriate semantic features) can help explain the nature of rework, and also raise hopes that this type of process can be expedited through execution of the defined process. The paper demonstrates the key role played in effective rework definition by such semantic features as procedure invocation, scoping, exception management, and resource management, which are commonly found in programming languages. A more ambitious program of research into the most useful processprogramming language semantic features is then suggested. The goal of this work is improved languages, for improved understandings of software processes, and improved support for software development.

A Pattern for Modeling Rework in Software Development Processes

“…In earlier work [1] we suggested that rework can be modeled as re-invocation of one or more development activities that had been carried out previously, but now must be carried out in a context different from the original execution, where a context is any aspect of the process step's dynamic, run-time environment (e.g. input parameters, resources, or personnel employed) that can cause the step to be carried out differently or produce a different result.…”

The role of context in exception-driven rework

“…Suppose, however, that the user fixes the compilation error but the unit test still reports failure, thus causing another round of rework driven by a new instance of UnitTestFailureException. Figure 4 characterizes part of the DDG abstraction in this situation and covers its key features 1 . The diagram consists of two different kinds of nodes.…”

“…The round one stands for the leaf step execution and the rectangle one describes the data object. The exception data object is shown in brown or a deeper 1 Figure 4 is a simplified representation of the DDG that is actually generated automatically. The actual DDG that would be generated by this process execution would contain more features and details that represent such execution aspects as scoping.…”

“…Although there is a common belief that rework plays an important role in all software development processes, it has not been studied thoroughly by the community. Cass et al [1] proposed initial approaches of formalizing rework with the Little-JIL process language. After this, a pattern was created to illustrate the concept more clearly [2].…”

“…Rework [1][2] [3] refers to repeating work activities that were previously done. This is quite common in software development.…”