Software process modelling as relationships between tasks

Systematic formulation of software process models is currently a challenging problem in software engineering. We present an approach to define models covering the phases of specification, design, implementation and testing of software systems in the component programming framework, taking into account non-functional aspects of software (efficiency, etc.), automatic reusability of implementations in systems and also prototyping techniques involving both specifications and implementations. Our proposal relies on the identification of a catalogue of tasks that appear during these phases which satisfy some relationships concerning their order of execution. A software process model can be defined as the addition of more relationships over these tasks using a simple, modular process language. We have developed also a formal definition of correctness of a software development with respect to a software process model, based on the formulation of models as graphs.Peer ReviewedPostprint (published version

Software Process Modelling with FUNSOFT Nets

In this paper we introduce FUNSOFT nets. FUNSOFT nets are high level Petri nets which are well-suited for software process modelling. We define the semantics of FUNSOFT nets in terms of Pr/T nets. Thus we enable the use of standard Petri net analysis techniques for examining software process model properties. We point out which analysis techniques are of interest from a software process modelling point of view. Moreover, we give an example for a software process model represented by a FUNSOFT net and we point out which tools for editing and analysing FUNSOFT nets are available

An Audience Centred Approach to Business Process Reengineering

This paper describes a method for process modelling which is designed to provide guidance to the business process modeller. The method has evolved from our experience of attempting to apply software process modelling approaches to business processes. A major influence on the method has been our observations that a pragmatic approach to notation selection is required in order to maintain a meaningful dialogue with end-users. Business process modelling methods typically fall into two camps. General methods attempt to describe the managerial activities which surround the modelling itself (Coulson-Thomas, 94; GISIP, 95). Specific methods, on the other hand, tend to concentrate on the details of a particular notational approach. However, as with programming languages or design methods, no single notational approach is best suited to all problems. Ideally, the process modeller should be able to incorporate the appropriate notational approach into some coherent generic modelling method.This paper addresses the needs of the modeller at the detailed level without prescribing a specific notation. This is achieved by describing categories of modelling activities which the modeller should undertake within process modelling, and suggesting how notations may be used within these categories. Our method is generally applicable, and is illustrated here by models of processes within the Construction industry

Empirical Studies Applied to Software Process Models

Working Group Report: ICSE'99 Workshop on Empirical Studies of Software Development and Evolutio

Instances and connectors : issues for a second generation process language

This work is supported by UK EPSRC grants GR/L34433 and GR/L32699Over the past decade a variety of process languages have been defined, used and evaluated. It is now possible to consider second generation languages based on this experience. Rather than develop a second generation wish list this position paper explores two issues: instances and connectors. Instances relate to the relationship between a process model as a description and the, possibly multiple, enacting instances which are created from it. Connectors refers to the issue of concurrency control and achieving a higher level of abstraction in how parts of a model interact. We believe that these issues are key to developing systems which can effectively support business processes, and that they have not received sufficient attention within the process modelling community. Through exploring these issues we also illustrate our approach to designing a second generation process language.Postprin

Using UML for modelling the static part of a software process

We study in this paper the use of UML as a tool for modelling the process of software construction. As a case study, we deal with the process of building a library of software components. UML is used in order to define the static part of the process, i.e., the elements that take part on it and their structural relationships. We think that our approach supports some interesting properties in the field of software process modelling (e.g.: modularity; expressivity in model construction; sound formal basis; and flexibility in model enactment). Besides showing the adequacy of UML for modelling the static part, the paper outlines also some drawbacks concerning the description of the dynamic behaviour of the process using only UML, and some possible solutions to them.Peer ReviewedPostprint (author's final draft

Instances and connectors : issues for a second generation process language

This work is supported by UK EPSRC grants GR/L34433 and GR/L32699Over the past decade a variety of process languages have been defined, used and evaluated. It is now possible to consider second generation languages based on this experience. Rather than develop a second generation wish list this position paper explores two issues: instances and connectors. Instances relate to the relationship between a process model as a description and the, possibly multiple, enacting instances which are created from it. Connectors refers to the issue of concurrency control and achieving a higher level of abstraction in how parts of a model interact. We believe that these issues are key to developing systems which can effectively support business processes, and that they have not received sufficient attention within the process modelling community. Through exploring these issues we also illustrate our approach to designing a second generation process language.Postprin

Fine-grain process modelling

In this paper, we propose the use of fine-grain process modelling as an aid to software development. We suggest the use of two levels of granularity, one at the level of the individual developer and another at the level of the representation scheme used by that developer. The advantages of modelling the software development process at these two levels, we argue, include respectively: (1) the production of models that better reflect actual development processes because they are oriented towards the actors who enact them, and (2) models that are vehicles for providing guidance because they may be expressed in terms of the actual representation schemes employed by those actors. We suggest that our previously published approach of using multiple “ViewPoints” to model software development participants, the perspectives that they hold, the representation schemes that they deploy and the process models that they maintain, is one way of supporting the fine-grain modelling we advocate. We point to some simple, tool-based experiments we have performed that support our proposition