Software Process Modelling

Traditionally, software process modelling focused on one complete model of the software process. As languages evolved and became more complex, so too have software process models. Models of the software life-cycle first came about during the 1950s/60s. Primarily, they were to “provide a conceptual scheme for rationally managing the development of software systems” (Scacchi 2002). Examples include the Classic Software Life-cycle (or waterfall approach); Stepwise Refinement; Incremental Development and Release (prototyping); and Industrial and Military Standards, and Capability Models, for example (ISO12207) (Scacchi 2002). “A software life-cycle model is either a descriptive or prescriptive characterisation of how software is or should be developed… software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution”

(Scacchi 2002). A difficulty in software development is the “representation and integration” of project information in a manner which projects can be controlled efficiently (Huseth and Vines 1987). Standards relating to process modelling are typically paper based, therefore meta-processes are suggested to structure

processes and enable the automatic verification of implementations and other standards against them (Ledru et al. 2006; Purper 2000; Turgeon and Madhavji 2000a). “Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products” (Sutton et al. 1991).

However, Starke (1994) extends the difficulty of modelling the software process by identifying five key areas which require consideration and relate to the terminologies used, number of available languages and

paradigms, types and instances of process models, dynamic changes which occur, and standardisation of approaches (Starke 1994). Zave (1989) proposes that “some application domains for which software is written are well understood, and some are not. This distinction is crucial to understanding – and improving – the software process” (Zave 1989). A close relationship is suggested between the domains software process and information systems modelling, in that both address a similar problem but use different approaches, and one could learn from the other to alleviate such difficulties (Conradi et al. 1994).

It is claimed that “by formalising the methods that are… used to develop software, we will be able to correct deficiencies, and incrementally enhance the way software is constructed” (Huseth and Vines 1987). “The process of software design… is one of the most creative of human activities” (Katayama 1988) and therefore, to formalise such an activity may seem counter intuitive. “Difficulties in (formally) specifying… software processes… are due to the fact we have not… clearly identified what we can (because it is purely mechanical) and what we cannot automate (because it requires creativity, intuition)” (Rombach 1988). Focussing on characterising, planning, executing, learning and feedback, a formalised Specification Framework is suggested to account for automated support in the Software Engineering environment (Rombach 1988). A formal approach to specification is extended to account specifically for process modelling and is presented as the Organisational Base Model in Sa and Warboys (1994). It utilises a formal stepwise refinement technique which is extremely complex and plagued with unfamiliar terminology and temporal operators, understanding of which is required to understand and apply the method. The logic also requires further clarification as it appears to have an altogether sequential nature. Therefore, it is difficult to see how alternative and exceptional cases could be modelled. It is considered important that any formalisation should be human understandable (specifically by managers); able to develop with the changing environment; hierarchical in design; able to accommodate process concurrency; and design alternatives (Katayama 1988). Justification for such a

formalisation can be given in that “every scientific study begins with description; software methods… need to be described in some language so that they can be better used and communicated; and the software industry needs some means of process description to achieve better quality control over products” (Katayama 1988).

However, it is argued that complete formalisation is not required so long as there are enough manual-overrides available for human users to account for any alternate or exceptional behaviours within a process (Jackson 2000).

Integrated Project Support Environments (IPSEs) can be used to support the software development process.

Focus in Ashok et al. (1988) is given to the architecture of such an environment and it is argued that they should “maintain an explicit model (representation) of the software process that is to be followed in a project”

(Ashok et al. 1988). The architecture is hierarchically arranged, “communicating sequential tasks” (Ashok et al. 1988) in the form of activities. Researchers at the Software Engineering Institute examined ways to augment software processes with management support (Kellner 1991). View-based models focus on eliciting information about the software process from multiple sources, thereby constructing a model of the software process from numerous alternate views. By giving focus to a single view, each view can be subject to an individual verification procedure. The application here looks to provide management planning and control mechanisms within software process modelling. The approach uses the STATEMATE tool to “represent, analyses, and simulate software processes” (Kellner 1989, 1991) and is characterised by the inclusion of three alternate modelling viewpoints. They are firstly, function (in the form of an Activity Chart displaying what happens in the process); Secondly, behavioural (in the form of a State Chart displaying when and how things happen); and lastly, organisational (in the form of a Module Chart displaying where things happen and who is involved in such happening) (Kellner 1989, 1991). In Nuseibeh et al. (1993) two views of granularity are suggested to enhance the model of the software process. This method supports the decomposition of the global view of the software process into smaller processes in terms of individual developers (Nuseibeh et al.

1993). The “big problem” faced with traditional project life-cycles is that they are both costly and time consuming, which leads for the need for process definitions to be agile (Hogg 2009). One way to improve the software development process is suggested in Turgeon and Madhavji (2000b) where a similar view-based modelling approach to software process modelling is considered. It is suggested that “models of software processes elicited using a view-based approach are generally of higher quality (specifically, more complete) than those elicited using traditional, non-view based, modelling approaches” (Turgeon and Madhavji 2000b).

Users require that “business systems… be… available instantly and operate flawlessly” (UC4 2008). The concept of Case Management was first introduced in the 1990s. It is suggested that the traditional structured environment is fixed and considered at design time, whereas an unstructured and ad hoc process flow can be considered at execution time. Therefore, a successful BPMS must provide both Design-Time and Run-Time Case Management (Hogg 2009). To facilitate such agility, it is suggested that the process be able to be adapted by the user role in execution time and not be bound by design-time decisions (Hogg 2009), giving flexibility to user roles. The scale of distributed and enterprise computing adds to the complications involved in creating such systems and, therefore, the objective is to change processes “to respond dynamically to changing business requirements and competitive pressures” (UC4 2008). Tools must venture “into a new realm where applications and events can be driven dynamically in response to constantly changing business conditions” (UC4 2008).

Contemporary models of software development must account for software, the interrelationships between software products and production processes, as well as for the roles played by tools, people and their workplaces (Scacchi 2002).

Software process technologies were originally intended for computer expert use and as such, they describe the software process in a sequential nature and do not account for concurrency (Taylor 1987). Traditional software processes are simple and stepwise, but lack the flexibility to support the natural environment and

“capture and formalise a wide variety of data types, types of users, classes of tools, and the complex relationships between the steps of a process that will be used in a large software development project”

(Huseth and Vines 1987). “In order to improve software development capability, one should improve

software development processes” (Turgeon and Madhavji 2000b) and provide “automated support” (Rombach 1988). “It could be argued that process descriptions should not be procedural at all, and that functional descriptions have much greater potential for promoting concurrency” (Taylor 1987). An alternative

consideration when modelling the software process is to take business goals as the foundation for that process, rather than activities or products (Taylor 1987; Thomas 1989). Difficulties are compounded when the process involves a team effort as there is a need to ensure that individual members are all singing of the same specification (Taylor 1987). Therefore, methods which embrace business process research in modelling concurrent activities and business goals in the software process could be preferred over procedural ones. “The use of behavioural description makes it possible to describe the software process at any desired level of abstraction and, therefore, assists in accommodating aspects of the process which are poorly understood”

(Williams 1988). Models “must go beyond representation. They must support comprehensive analysis of a process. In addition, models should allow predictions regarding the consequences of potential changes and improvements” (Kellner 1989); which leads to the recommendation of enactable models where simulation can be used to “draw a clear and touchable picture of the future system for the managers and users” (Mahmudi and Tavakkoli 2005), supported by Grützner et al. (2004).