Abstract

The upstream activities of software development projects are often viewed as both the most important, the least understood, and hence the most problematic. This is particularly noticeable in terms of satisfying customer requirements. Business process modelling is one solution that is being increasingly used in conjunction with traditional software development, often feeding in to requirements and analysis activities. In addition, research in Systems Engineering for Business Process Change,1 highlights the importance of modelling business processes in evolving and maintaining legacy systems that support those processes. However, the major use of business process modelling, is to attempt to restructure the business process, in order to improve some given aspect, e.g., cost or time. This restructuring may be seen either as separate activity or as a pre-cursor to the development of systems to support the new or improved process. The analysis of these business models is, therefore, vital to the improvement of the process and the development of supporting software systems. Supporting this analysis is the focus of this paper. Business processes are typically described with static (diagrammatic) models. This paper proposes a quantitative approach to aid analysis and comparison of these models. This is illustrated using the process-modelling notation, Role Activity Diagrams (RADs). We studied 10 prototyping processes across a number of organisations and found that roles of the same type exhibited similar levels of coupling across processes. Where roles did not adhere to tentative threshold values, further investigation revealed unusual circumstances or hidden behaviour. Notably, analysis of the prototyping roles (which exhibited the greatest variation in coupling), found that coupling was highly correlated with the size of the development team and the number of participants. This suggests that prototyping in large projects had a different process to that for small projects and required more mechanisms for communication. We conclude that counts (measures) may be useful in the analysis of static process models.