According to W. Edwards Deming, American companies require nothing less than a transformation of management style and of governmental relations with industry. In Out of the Crisis, originally published in 1982, Deming offers a theory of management based on his famous 14 Points for Management. Management's failure to plan for the future, he claims, brings about loss of market, which brings about loss of jobs. Management must be judged not only by the quarterly dividend, but by innovative plans to stay in business, protect investment, ensure future dividends, and provide more jobs through improved product and service. In simple, direct language, he explains the principles of management transformation and how to apply them.

Out of the Crisis

After more than 20 years of research and practice in software configuration management (SCM), constructing consistent configurations of versioned software products still remains a challenge. This article focuses on the version models underlying both commercial systems and research prototypes. It provides an overview and classification of different versioning paradigms and defines and relates fundamental concepts such as revisions, variants, configurations, and changes. In particular, we focus on intensional versioning, that is, construction of versions based on configuration rules. Finally, we provide an overview of systems that have had significant impact on the development of the SCM discipline and classify them according to a detailed taxonomy.

/pdf/version-models-for-software-configuration-management-1tcwwh2q9y.pdf

Version models for software configuration management

Details the different activities of software development with a case-study approach whereby a project is developed through the course of the book The sequence of chapters is essentially the same as the sequence of activities performed during a typical software project.

An Integrated Approach to Software Engineering

Software process improvement requires high level formalisms for describing project-specific, organizational and quality aspects. These formalisms must be convenient not only for capture but also for execution purposes. In order to fulfill these requirements and to build a software process environment capable of supporting engineering tasks we have designed a new graphical, but still enactable, formalism called APEL (for Abstract Process Engine Language).

APEL is very ambitious in the sense that it aims to cover a wide spectrum of needs and approaches expressed not only in the software engineering field but also in many others such as real-time systems, object-oriented methodologies, tool integration, CSCW, workflow and information systems. It is then not surprising to see that many concepts and techniques used in APEL are borrowed from these connected fields. A major outcome of the work presented here was to integrate a broad range of concepts and paradigms in a single and coherent framework, but on the basis of a minimal set of primitive concepts which make it very easy to extend. Globally, the aspects which received most attention are: openness, reuse, scalability, human orientation and cooperative work.

Apel: A Graphical Yet Executable Formalism forProcess Modeling

Contemporary business process systems are built to automate routine procedures. Automation demands well-understood domains, repetitive processes, clear organisational roles, an established terminol ...

Interactive Process Models

Developing and maintaining software systems involves a variety of highly interrelated activities The discipline of software engineering studies processes of both product engineering and process engineering Product engineering aims at developing software products of high quality at reasonable cost Process engineering in contrast aims at choosing those product engineering processes appropriate for a given set of project goals and characteristics as well as improving the existing knowledge about those processes Explicit models of both types of processes help a software development organization to gain competitive advantage This paper motivates the need for explicit process models, surveys existing languages to model processes, discusses tools to support model usage, and proposes a research agenda for future software process research

Directions in Software Process Research

Intellectual control over software development projects requires the existence of an integrated set of explicit models of the products to be developed, the processes used to develop them, the resources needed, and the productivity and quality aspects involved. In recent years the development of languages, methods and tools for modeling software processes, analyzing and enacting them has become a major emphasis of software engineering research. The majority of current process research concentrates on prescriptive modeling of small, completely formalizable processes and their execution entirely on computers. This research direction has produced process modeling languages suitable for machine rather than human consumption. The MVP project, launched at the University of Maryland and continued at Universitat Kaiserslautern, emphasizes building descriptive models of large, real-world processes and their use by humans and computers for the purpose of understanding, analyzing, guiding and improving software development projects. The language MVP-L has been developed with these purposes in mind. In this paper, we
motivate the need for MVP-L, introduce the prototype language, and demonstrate its uses. We assume that further improvements to our language will be triggered by lessons learned from applications and experiments.

MVP-L Language Report Version 2

The objective of software process technology is to support the derivation and analysis of software process models, and their use in projects. Software process models should represent as much as possible of a project, and thereby support as many project members as possible. But a very rare few people ever understand a large project as a whole. The rst problem is that every process element is viewed di erently depending on the contexts of the project members. The second problem is that di erent roles exist within a software project. I believe that a useful software process model can only be derived by describing the process from di erent perspectives. Concentration on a subset of information (e.g., product ow) during modeling is helpful [1]. The part of a software process model which corresponds to a role (i.e., supports the role's tasks) is called a view. Views may overlap and have to be integrated to produce a comprehensive software process model. I believe that development and use of comprehensive software process models should be performed by the application of the following three steps:

Multi-view modeling of software processes

Representations of activities dealing with the development or maintenance of software are called software process models. Process models allow for communication, reasoning, guidance, improvement, and automation. Two approaches for building, instantiating, and managing processes, namely CoMo-Kit and MVP-E, are combined to build a more powerful one. CoMo-Kit is based on AI/KE technology; it was developed for supporting complex design processes and is not specialized to software development processes. MVP-E is a process-sensitive software engineering environment for modeling and analyzing software development processes, and guides software developers. Additionally, it provides services to establish and run measurement programmes in software organizations. Because both approaches were developed completely independently major integration efforts are to be made to combine their both advantages. This paper concentrates on the resulting language concepts and their operationalization necessary for building automated process support.

/pdf/enriching-software-process-support-by-knowledge-based-4ymthe24hc.pdf

Enriching Software Process Support by Knowledge-based Techniques

Process support approaches use process models to allow for communication, reasoning, guidance, improvement, and automation. Two approaches are compared and combined to build a more powerful one. In this paper we describe the synthesis of the CoMo-Kit and MVP-E approaches. CoMo-Kit is based on AI/KE technology. It was developed for supporting complex design processes and is not specialized to software development. MVP-E is an environment for modeling, analyzing, and guiding which additionally provides services to establish and run measurement programmes in software organizations. Differences between both approaches are identified which are then used as alternatives when deriving requirements for process support environments. The discussion helps understand what is intrinsic to processes in general and what is special to software development processes in particular. Synthesizing both process support systems, which were developed completely independently, allows to alternate planning and enaction of software development processes.

Martin Verlage

Papers

Directions in Software Process Research

MVP-L Language Report Version 2

Multi-view modeling of software processes

Enriching Software Process Support by Knowledge-based Techniques

A Synthesis of Two Process Support Approaches.