Software Process Technology

This position paper discusses the need for a systematic framework which can be used to analyse software processes and derive process models. We propose the idea of process viewpoints which have associated process models and which incorporate questions about process and potential process improvement. The questions associated with each process viewpoint are derived from organisational concerns which must be explicitly identified. This work has been carried out in the context of a project which is investigating approaches to requirements engineering process improvement.

Analyzing software process models to predict the behavior of software processes helps in planning and enacting software projects. Since software process models can capture the key information that is necessary to assess process-related risks, this paper discusses how approaches for software process analysis may be applied to software risk assessment. A characterization scheme for process analysis approaches is stated based on a set of necessary risk assessment requirements. Existing analysis approaches are evaluated with respect to the characterization scheme. Proceeding from this evaluation, an approach to software process analysis is proposed that is specifically tailored to software risk assessment. This analysis approach takes advantage of a wide range of information by integrating empirically validated models. It is also shown how this approach fits into the context of the MVP (multi-view processes) project at the University of Kaiserslautern.

Software development organizations are beginning to recognize that measurement is a prerequisite for systematic process improvement, and have started to measure their products and processes in order to understand, analyze, plan, and guide their projects. Successful measurement requires a solid understanding of the products, processes, and resources to be measured, an understanding which can only be gained via explicit models. In the MVP Project we are integrating the G/Q/M measurement paradigm with the MVP-L process modeling language in order to guide teams of software developers. This integrated approach is supported by a prototype system, MVP-S, a process-sensitive software engineering environment which offers advanced project guidance using role definitions and measurement data. We motivate the need for measurement, sketch an integration of the measurement and modeling approaches, and demonstrate how MVP-S improves the quality of guidance using measurement.

Practical experiences carried out so far, show that it is plausible to combine metrication and process modelling and thereby profit from their mutual influence. Tooling has not played an important part in the experiences. However, it was found that a simple drawing tool and a spread sheet are useful.These experiences are being investigated further to validate the approach. It is too soon to comment on the benefits and costs involved. At least part of the benefits is a better understanding of the processes that are involved in software development and a means to measure improvement.

Case studies are an essential feature of process modelling research. This work introduces a possible structure to assist in assembling and reporting the fragmented findings of such experiences

In this paper it is argued that in order to achieve the required reduction in product lead-time for embedded software a proper differentiation and integration of a number of key developemt processes like: usability engineering, hardware engineering and software engineering should take place. It is furthermore argued that this makes only sense if an appropriate modular system architecture exists, which admits a flexible Δ development approach for its major components.

The conclusion I draw, with respect to the research agenda for the SP community, is that the emerging interest for the inter-operability of a set of independently developed modules should be cultivated, and will play an important tactical role, but should not be considered a strategic target, as should instead be that of identifying a core language (a few core languages, each) accompanied by several compatible sub-languages. The reason is that the experience with systems that interconnect independent modules will be an effective way to understand what is needed of each of them, as service providers, and what instead is there that should not, like hidden co-ordination policies and possibly incompatible redundancies. However, the quest for inter-operability alone reflects an optimistic laisser-faire attitude with respect to the evolution of PSEEs: let the individuals communicate and grow, and the community will also grow. I don't see any real evidence supporting this view. Also O&H show some doubts, when they state that “it will be interesting=8A to see whether interoperability difficulties appear and accelerates the drift [in the direction of increasingly different coding languages and platforms] continues”. Rather, I see some analogy between interoperability and construction with natural materials: in both cases the engineer has to cope post-hoc with mismatches that can be instead avoided using carefully designed artificial bricks and sub-languages, respectively. As a final note, there is at least one candidate as a basis for the core language, namely the emerging co-ordination theory [3].n

The paper describes the different phases and subdomains of process modelling and their needs for conceptual and linguistic support, and in what forms. We group the relevant factors into three dimensions: meta-process phases, process elements, and the tool/user views. In the first dimension, we focus on enactable process models. For such models, we describe the design alternatives for a core process modelling language and a set of tailored sub-languages to cover special process elements. However, no detailed and functional comparison of possible modelling language are attempted.Then we address interoperability between related sub-models and its implication to the language design. We also present a general architecture for a Process-Centered Software Engineering Environment, with a segmented repository of model servers.Some concrete language realisations, mainly from the EPOS PSEE, are used throughout the presentation. We also give a realistic example of the design of an interoperable PSEE, and discuss how it can be improved using an extended EPOS.The paper concludes that we have to live with many sub-languages around a core process modelling language. However, the underlying linguistic paradigm in this core language is not judged critical. What counts is use of standard support technologies, interoperability to handle heterogeneous and distributed process information, non-intrusive process support, end-user comprehension, and flexible support for evolution (metaprocess).

A wide variety of techniques and approaches are needed to understand and improve software development processes. The critical research problem is supporting the move from completely informal process descriptions to a form that includes parts that are at least machine processable. We discuss a series of engineering experiments on process visualization and analysis using simple process interface descriptions. This work grew out of two needs: the need to understand a process's internal structure and the need to understand and improve the process system's architecture. We discuss the various approaches we have taken to understand processes from these two standpoints: we report on the different forms of visualization we have used, both for processes in the small as well as processes in the large, and their resulting benefits; we delineate the various forms of analysis and report how they have played a seminal role in process improvement by providing the quantitative basis of both process understanding and process improvement efforts.

Guiding software development via an enacted process model has by now become state-of-the-art, leading to Software Engineering Environments. Similarly administrative office work also largely follows pre-defined procedures, laws, and regulations, which essentially also establish a process model. Computer support for this field is currently hotly discussed under the catch word of ‘work flow’.We explore similarities and differences of both fields with respect to a variety of characteristics. It concludes that both fields obey the same basic paradigm, i.e. describing the desired processes by a process model and enacting this model by a process mechanism. The characteristics are sufficiently similar to justify a common approach, but at the same time there exist significant differences which make it necessary to use different implementations for software development and administrative processes.

Software processes are complex activities where designers, managers, programmers, and users must cooperate to achieve effective results. The work done in the software process community during the last years has been mainly focused on the provision of means to model software processes and to support asynchronous, text-based communication. On the other side, CSCW (Computer Supported Cooperative Work) technology aims at supporting general cooperation activities among human agents exchanging multimedia information. Recently, there has been an increasing interest on the issues related to the integration of these two technologies.This paper discusses different integration strategies between the SPADE PSEE (Process-centered Software Engineering Environment) and the ImagineDesk toolkit for the development of CSCW systems. It outlines how the advantages and limitations of the two systems can be matched to achieve more effective computer support in software production.

Software process management and business process management are areas of research for some years now. Both suffer from considering processes as isolated entities. In contrast to that, we believe that software processes and business processes are impacted by many other processes surrounding them. In this article we motivate why we understand processes as entities which communicate with each other. We suggest mechanisms to support modeling and enaction of communicating processes.

It is advocated here that integrating abstraction and modularity into the concept of point of view, and extending the view concept to the process itself (and not only to data used by processes), provides an uniform conceptual framework for aspects like agent point of view, quality models and process monitoring.

In this paper, we advocate decentralised process modelling and suggest that understanding and modelling the development processes of individual development participants is the key to supporting collaborative development. Our approach relies on recognising individual developers' states (“situations”) by analysing local development histories. Different situations can be used to trigger a variety of further development actions, such as consistency checks between process models of different development participants. We report on experience using regular expressions to specify particular situations and rules to associate actions with these situations.

We have implemented mtp as part of Marvel's successor, Oz, which adds a variety of other new functionality (see [2]). Example applications have included idraw as a UNI_QUEUE tool, where process steps are queued for one-at-a-time execution (the same userid may submit process steps from multiple clients, and the user interface is transferred as needed); emacs as a UNI_NO_QUEUE tool where steps are not queued but may overlap (typically on a single monitor); a local natural language processing system written in commonlisp as a MULTI-QUEUE tool, where steps are queued for one-at-at-time execution (and the UI is transferred among users participating in the same session as needed); and Marvel itself as a MULTI_NO_QUEUE tool (that supplies its own clients for multiple users).

Coordination theory is an interdisciplinary approach to studying the management of dependencies among activities. By its very nature software process technology deals with coordination. However it often expresses coordination in terms of low level details. An effective coordination theory would give us a better set of coordination abstractions. We illustrate the close relationship between these fields and propose areas where they could learn from each other.

This paper deepens the idea of cooperation in the software process. It demonstrates the interest of distinguishing two levels of abstraction when modelling software processes to reason about cooperation in the sense of positive interactions between processes and respectively between the associated human agents. It illustrates the stepwise specification methodology used in the context of the the COO framework to specify process models.

In this paper a very simple reflexive formal software development method is described. The method is called OBM which provides a formal specification language. This paper demonstrates that the OBM development method can be defined as a process model in the OBM language. An example is used to illustrate how to develop and modify applications using the OBM development method.