• Business process reengineering-the redesign of an organization's business processes to make them more efficient. • Coordination technology-an aid to managing dependencies among the agents within a business process, and provides automated support for the most routinized component processes. * Process-driven software development environments-an automated system for integrating the work of all software related management and staff; it provides embedded support for an orderly and defined software development process. These three applications share a growing requirement to represent the processes through which work is accomplished. To the extent that automation is involved, process representation becomes a vital issue in redesigning work and allocating responsibilities between humans and computers. This requirement reflects the growing use of distributed , networked systems to link the interacting agents responsible for executing a business process. To establish process modeling as a unique area, researchers must identify conceptual boundaries that distinguish their work from model-ing in other areas of information science. Process modeling is distinguished from other types of model-ing in computer science because many of the phenomena modeled must be enacted by a human rather than a machine. At least some mod-eling, however, in the area of human-machine system integration or information systems design has this 'human-executable' attribute. Rather than focusing solely on the user's behavior at the interface or the flow and transformation of data within the system, process model-ing also focuses on interacting behaviors among agents, regardless of whether a computer is involved in the transactions. Much of the research on process modeling has been conducted on software development organizations , since the software engineering community is already accustomed to formal modeling. Software process modeling, in particular , explicitly focuses on phenomena that occur during software creation and evolution, a domain different from that usually mod-eled in human-machine integration or information systems design. Software development is a challenging focus for process modeling because of the creative problem-solving involved in requirements analysis and design, and the coordination of team interactions during the development of a complex intellectual artifact. In this article, software process modeling will be used as an example application for describing the current status of process modeling, issues for practical use, and the research questions that remain ahead. Most software organizations possess several yards of software life cycle description, enough to wrap endlessly around the walls of project rooms. Often these descriptions do not correspond to the processes actually performed during software …

Process modeling

Vaitoskirja pyrkii vastaamaan kahteen kysymykseen: Onko mahdollista muotoilla tuotannon teoriaa? Jos on, johtaako teoria tehokkuuden kohoamiseen, kun sita sovelletaan rakentamiseen?

Historiallinen analyysi paljastaa, etta 1900-luvulla on kehitetty ja sovellettu kolmea eri tuotannon kasitteellista mallia. Tuotanto on nahty muunnoksena, virtana ja arvontuottona. Kaikkia naita malleja voidaan perustellusti pitaa valttamattomina tuotannon ymmartamiseksi, ja niita tulisi siten soveltaa rinnakkain. Vaitostutkimuksessa esitettavaa tuotannon mallia kutsutaan tuotannon TFV-teoriaksi (Transformation, Flow, Value generation).

Tutkimuksen tulokset osoittavat, etta tehokkuutta alentavia ongelmia esiintyy yleisesti rakentamisen kaikissa vaiheissa: rakennuttajan paatoksenteossa, suunnittelun ohjauksessa ja rakennustuotannon ohjauksessa. TFV-teoria selittaa suurelta osin rakentamisen ongelmien syntymisen. Tarkasteltaessa pioneeriyritysten kehittamishankkeita, joissa on sovellettu TFV-teorian tiettyja ydinpiirteita, voidaan havaita, etta talle teorialle perustuvat menetelmat tuottavat merkittavia kustannussaastoja ja muita hyotyja. TFV-teorian avulla voidaan siten suunnata uusiin tehokkaampiin menetelmiin tahtaavaa kokeilua ja kehitystyota seka rakentamisen kaytannon etta tutkimuksen piirissa.

/pdf/an-exploration-towards-a-production-theory-and-its-1y5pohraps.pdf

An exploration towards a production theory and its application to construction

STATEMATE is a set of tools, with a heavy graphical orientation, intended for the specification, analysis, design, and documentation of large and complex reactive systems. It enables a user to prepare, analyze, and debug diagrammatic, yet precise, descriptions of the system under development from three interrelated points of view, capturing structure, functionality, and behavior. These views are represented by three graphical languages, the most intricate of which is the language of statecharts, used to depict reactive behavior over time. In addition to the use of statecharts, the main novelty of STATEMATE is in the fact that it understands the entire descriptions perfectly, to the point of being able to analyze them for crucial dynamic properties, to carry out rigorous executions and simulations of the described system, and to create running code automatically. These features are invaluable when it comes to the quality and reliability of the final outcome. >

/pdf/statemate-a-working-environment-for-the-development-of-1w9uawvlqd.pdf

STATEMATE: a working environment for the development of complex reactive systems

Project controls have traditionally been focused on after-the-fact detection of variances. This thesis proposes a control system, the Last Planner system, that causes the realization of plans, and thus supplements project management’s concern for management of contracts with the management of production.

The Last Planner system has previously been successfully applied by firms with direct responsibility for production management; e.g., specialty contractors. This thesis extends system application to those coordinating specialists, both in design and construction, through a series of case studies, one of which also explores the limits of unilateral implementation by specialists.

In addition to the extended application, two questions drive this research. The first question is 1) What can be done by way of tools provided and improved implementation of the Last Planner system of production control to increase plan reliability above the 70% PPC level? Previous research revealed substantial improvement in productivity for those who improved plan reliability to the 70% level, consequently there is reason to hope for further improvement, possibly in all performance dimensions, especially with application across an entire project rather than limited to individual specialty firms. That question is explored in three case studies, the last of which achieved the 90% target.	

The second question is 2) How/Can Last Planner be successfully applied to increase plan reliability during design processes. That question is explored in an extensive case study, which significantly contributes to understanding the design process from the perspective of active control, but unfortunately does not fully answer the question, primarily because the project was aborted prior to start of construction. However, it is argued that Last Planner is especially appropriate for design production control because of the value-generating nature of design, which renders ineffective traditional techniques such as detailed front end planning and control through after-the-fact detection of variances.

Issues for future research are proposed, including root cause analysis of plan failures and quantification of the benefits of increased plan reliability for both design and construction processes.

/pdf/the-last-planner-system-of-production-control-3b02rm1jde.pdf

The last planner system of production control

Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of traceability tools. A detailed case study on the use of the models is presented. Four kinds of traceability link types are identified and critical issues that must be resolved for implementing each type and potential solutions are discussed. Implications for the design of next-generation traceability methods and tools are discussed and illustrated.

Toward reference models for requirements traceability

Software process simulation modeling: Why? What? How?

A defined software process is needed to provide organizations with a consistent framework for performing their work and im- proving the way they do it. An overall framework for modeling simplifies the task of producing process models, permits them to be tailored to individual needs, and facilitates process evolution. This paper outlines the principles of entity process, models and suggests ways in which they can help to address some of the problems with more conventional approaches to modeling software processes.

/pdf/software-process-modeling-principles-of-entity-process-1suw1yckux.pdf

Software Process Modeling: Principles Of Entity Process Models

: This paper discusses the topic of software process modeling, a means of reasoning about the processes used to develop and maintain software. Although this term is beginning to come into common use, its meaning varies widely. For the purposes of this paper, software process modeling is defined as a methodology that encompasses a representation approach, comprehensive analysis capabilities, and the capability to make predictions regarding the effects of changes to a process. This paper reports the approach we have taken to software process modeling and summarizes our experiences on the Post Deployment Software Support (PDSS) Project. The paper is structured as follows: Chapter 1 - Introduction; Chapter 2 - Overview of the objectives and capabilities of software processing modeling; Chapter 3 - Overview of the PDSS Information Management Project, describing the context for our modeling experience; Chapter 4 - Details and examples of the modeling approach used on the PDSS Project; Chapter 5 - Outcomes and results of those modeling efforts; Chapter 6 - Lessons learned from this effort, and a list of the capabilities required for successful software process modeling; and Chapter 7 - Conclusions and directions for future work.

/pdf/software-process-modeling-3s1dfopij6.pdf

Software Process Modeling

A process guide is a reference document for a particular process, providing assistance to process participants in carrying out that process. Although most organizations have such documents (e.g., standards, manuals), they are frequently deficient in both form and content, and often go unused. This paper describes a program of applied research on improving both the usefulness and usability of process guides. It first discusses an exemplary paper-based process guide. It then describes a prototype web-based Electronic Process Guide (EPG). The paper then introduces a key element of our vision for the future, Collaborative Process Guides (CPGs), which will be integrated with other forms of process technology as well as with collaboration technology. An incremental plan is outlined for developing and maturing the "technology" for this advanced process guidance (EPGs and CPGs). This plan can also be interpreted as a strategy for incrementally introducing process technology into an organization, avoiding user resistance and overcoming some of the perceived drawbacks of process-sensitive software engineering environments.

Marc I. Kellner

Papers

Process modeling

Software process simulation modeling: Why? What? How?

Software Process Modeling: Principles Of Entity Process Models

Software Process Modeling

Process Guides: Effective Guidance for Process Participants