Several arguments support the proposition that corporations can be viewed as cognitive entities. But accepting that corporations perform cognitive functions raises questions about how we might describe and assess those functions. In this paper I propose that we can address such questions by viewing corporate cognition in terms of capabilities that are adapted from human cognition. To illustrate this idea, I use the concept of schemas, a human cognitive capability identified by Piaget, which I recast as a corporate cognitive capability. To develop this example, I review schemas as understood in psychology; use scenarios from corporate settings to motivate their relevance to corporations; and describe a hypothetical capability for corporate cognitive schemas using a template that addresses common concerns in enterprise capability modeling. This example gives support to the idea that cognitive capabilities are relevant on the corporate level. It shows that a corporate cognitive capabilities can be practically modeled like conventional business capabilities and that corporate cognitive capabilities can be related to business goals. This work points to a path for practical investigations and applications of a view of corporations as cognitive entities. It further opens a new domain for software process programming.

Abstract The volume at hand presents the special issue of the 12th International Conference on Software and Systems Process (ICSSP) 2019, which was held in Montreal, Canada, from May 25 to 26, 2019. ICSSP 2019 is the latest in a series of conferences that have been organized by the International Software and Systems Process Association. In our evolving landscape, many companies are making efforts to move towards new technologies and tools, agile principles, and continuous integration and delivery. In doing so, they find opportunity, flexibility, and strength in evolving towards hybrid processes, which are neither purely traditional nor can count as textbook agile. This special issue focuses on hybrid processes.

Informed projection is a technique for estimating work items created and completed for a software release. It combines counts of work items created and completed so far with models of items expected to be created and completed in the remaining schedule to yield projections of expected total items created and completed. Informed projection is not significantly more difficult to use than popular techniques like burn-down and burn-up charts but it overcomes limitations associated with those by accommodating variations in the total amount of work and in the rates of work creation and completion. Experiments confirm that simple models can yield relatively accurate projections fairly early in a release, that these models do not have to be unrealistically accurate, that effective models can be constructed simply, and that the approach works for projects with varied characteristics and patterns of work.

ABSTRACT Software process simulation (SPS) has been evolving over the past two decades after being introduced to the software engineering community in the 1980s. At that time the SPS technology attracted a great deal of interest from both academics and practitioners in the software process community—even to the extent of being one of the recommended techniques for achieving multiple Key Process Areas of Level 4 of the Capability Maturity Model Integration. However, in recent years, the growth of SPS seems to have slowed along with the number of reported applications in industry. This article summarizes the special panel that was held during ICSSP 2012 whose goals were to assess whether this technology remains applicable to today's software engineering projects and challenges and to point out the most beneficial opportunities for future research and industry application. Copyright © 2014 John Wiley & Sons, Ltd.

If you take a broad view, there are many ways ahead for software process modeling and simulation. One way to broaden the view is to include not just software processes but also systems and service processes. Another is to address not just technical processes but also business processes. In any scope, impact can be strengthened by combining modeling and simulation with analytics. A way to assure longevity of the field is to solve problems in practice. These afford a variety of ways to make contributions, including both applied and fundamental. Challenges that must be overcome in achieving practical results are getting access to practitioners, acquiring useful data, and getting your solution adopted (among others). More empirical studies and experience reports are needed. But there are many routes by which contributions may flow to and from the field.

Coordination of project stakeholders is critical to timely and consistent software delivery. In this short paper we present the problem of private information as a guiding framework or lens through which to interpret coordination dynamics within software organizations. We provide evidence of this problem in the form of specific challenges, collected via interviews from a diverse set of extended (i.e., non-development) stakeholders in a globally distributed software development organization.

Integrated Product Development - IPD - is an enterprise-wide process used by IBM to develop technology products including hardware, software, and services. IPD has been in use at IBM for over a decade and has been very effective at increasing efficiency and reducing costs across the whole product life cycle. Within IBM Software Group, IPD at the top level is defined informally through natural-language documents, ad hoc diagrams, and a database of well-defined deliverables. Some key concepts in the SWG IPD definition include a clear statement of the principles on which the process is based, widespread references to business goals, frequent use of governance-oriented formulations, a clearly defined structure for the high levels of the process, a relative lack of concern about lower levels of the process structure, and an emphasis on the characterization of participant roles. The relative lack of formal and semantic rigor in the SWG IPD definition might seem to open the door to a number of problems in process specification and execution. However, this seems to have allowed the process definers to focus on those aspects of the process that are most important and to present those in a natural way. In the context of an organization that is dedicated to the success of the process, this has been an effective approach.

The modularity and customer centric approach of use cases make them the preferred methods for requirement elicitation, especially in iterative software development processes as in agile programming. Numerous guidelines exist for use case style and content, but enforcing compliance to such guidelines in the industry currently requires specialized training and a strongly managed requirement elicitation process. However, often due to aggressive development schedules, organizations shy away from such extensive processes and end up capturing use cases in an ad-hoc fashion with little guidance. This results in poor quality use cases that are seldom fit for any downstream software activities. We have developed an approach for automated and "edit-time" inspection of use cases based on the construction and analysis of models of use cases. Our models contain linguistic properties of the use case text along with the functional properties of the system under discussion. In this paper, we present a suite of model analysis techniques that leverage such models to validate uses cases simultaneously for their style and content. Such model analysis techniques can be combined with a robust NLP techniques to develop integrated development environments for use case authoring, as we do in Text2Test. When used in an industrial setting, Text2Test resulted in better compliance of use cases, in enhanced productivity and, subsequently, in higher quality of test cases.

Full-featured integrated development environments have become critical to the adoption of new programming languages. Key to the success of these IDEs is the provision of services tailored to the languages. However, modern IDEs are large and complex, and the cost of constructing one from scratch can be prohibitive. Generators that work from language specifications reduce costs but produce environments that do not fully reflect distinctive language characteristics.

Programming language design remains a vital field, with interest in languages targeting concurrency, scripting, and aspects, as well as in domain-specific languages. Full-featured integrated development environments (IDEs) have become critical to the adoption of new languages. A key factor in the success of these IDEs is the provision of services specifically tailored to the language. However, modern IDE frameworks are large and complex, and the cost of constructing a language-specific IDE from scratch remains prohibitive

No abstract available

Standard messaging middleware guarantees the delivery of messages to intermediary destinations like message queues, but does not guarantee the receipt or the processing of a message by final recipients. Conditional messaging is an extension to standard messaging middleware that addresses this shortcoming by allowing an application to define, monitor, and evaluate various conditions on messages, such as time constraints on the receipt or the processing of a message by a set of final recipients. In this paper, we introduce the notion of conditional messaging, and present the design and implementation of a flexible and reliable system that supports conditional messaging for use in Java 2 Enterprise Edition and message queuing environments. Our solution uniquely shifts the responsibilities for implementing the management of conditions on messages from the application to the middleware. We further discuss the grouping of multiple conditional messages into atomic units-of-work, which can also integrate requests to transactional resources like distributed objects using object middleware. Conditional messaging serves to implement various kinds of backward dependencies for distributed object transactions that integrate messaging.

This note presents an overview of this ICSE 2002 tutorial.

Many enterprise systems employ both object-oriented middleware (OOM) and message-oriented middleware (MOM). However support for the integration of object and messaging services, in particular for transaction processing across object and messaging components, is very limited. In this paper we introduce the concept of Dependency-Spheres (D-Spheres), a global transaction context for distributed objects and messages. A D-Sphere integrates standard distributed object transactions and conditional asynchronous messages in one single unit-of-work. It is a new service for transaction processing that enhances two-phase-commit ACID transactions with pre-commit message delivery, concurrent evaluations of transaction-critical message conditions, and message compensation support for recovery. D-Spheres enrich standard OOM and MOM services, uniquely providing for an increased level of reliability for their use in combination in enterprise systems.

Little-JIL, a language for programming coordination in processes is an executable, high-level language with a formal (yet graphical) syntax and rigorously defined operational semantics. The central abstraction in Little-JIL is the “step,” which is the focal point for coordination, providing a scoping mechanism for control, data, and exception flow and for agent and resource assignment. Steps are organized into a static hierarchy, but can have a highly dynamic execution structure including the possibility of recursion and concurrency.

Little-JIL, a new language for programming the coordination of agents, is an executable, high-level process programming language with a formal (yet graphical) syntax and rigorously defined operational semantics. Little-JIL is based on two main hypotheses. The first is that the specification of coordination control structures is separable from other process programming language issues. Little-JIL provides a rich set of control structures while relying on separate systems for support in areas such as resource, artifact and agenda management. The second hypothesis is that processes can be executed by agents who know how to perform their tasks but can benefit from coordination support. Accordingly, each step in Little-JIl is assigned to an execution agent (human or automated). These agents are responsible for initiating steps and performing the work associated with them. This approach has so far proven effective in allowing us to clearly and concisely express the agent coordination aspects of a wide variety of software, workflow and other processes.

Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution.The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decompositionand composition a given formalism supports.The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along sdngle dimensions of composition and decomposition.These characteristics lead to a number of well-known and difficult problems.This paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition.This approach addresses numerous problems throughout the software lifecycle in achieving wellengineered, evolvable, flexible software artifacts and traceability across artifacts.

Software process programming is the coding of software processes in executable programming languages. Process programming offers many potential benefits, but their realization has been hampered by a lack of experience in the design and use of process programming languages. APPL/A is a prototype software process programming language developed to help gain this experience. It is intended for the coding of programs to represent and support software processes including process, product, and project management. APPL/A is defined as an extension to Ada, to which it adds persistent programmable relations, concurrent triggers on relation operations (for reactive control), optionally and dynamically enforceable predicates on relations (which may serve as constraints), and composite statements that provide alternative combinations of serializability, atomicity, and consistency enforcement (for programming high-level transactions). APPL/A has been used to code engineering-oriented applications, like requirements specification and design, as well as management-related activities, such as personnel assignment, task scheduling, and project monitoring. APPL/A has also enabled us to experiment with process program design techniques and architectures, including process state reification, intermittent (or persistent) processes, reflexive and metaprocesses, and multiple-process systems. Our ability to address a wide range of software processes and process characteristics indicates that the APPL/A constructs represent important and general capabilities for software process programming.— Authors' Abstract