This paper is a review of research in product development, which we define as the transformation of a market opportunity into a product available for sale. Our review is broad, encompassing work in the academic fields of marketing, operations management, and engineering design. The value of this breadth is in conveying the shape of the entire research landscape. We focus on product development projects within a single firm. We also devote our attention to the development of physical goods, although much of the work we describe applies to products of all kinds. We look inside the “black box ” of product development at the fundamental decisions that are made by intention or default. In doing so, we adopt the perspective of product development as a deliberate business process involving hundreds of decisions, many of which can be usefully supported by knowledge and tools. We contrast this approach to prior reviews of the literature, which tend to examine the importance of environmental and contextual variables, such as market growth rate, the competitive environment, or the level of top-management support.

Over the past decade, software architecture research has emerged as the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. We can understand the evolution and prospects of software architecture research by examining the research paradigms used to establish its results. These are, for the most part, the paradigms of software engineering. We advance our fundamental understanding by posing research questions of several kinds and applying appropriate research techniques, which differ from one type of problem to another, yield correspondingly different kinds of results, and require different methods of validation. Unfortunately, these paradigms are not recognized explicitly and are often not carried out correctly; indeed not all are consistently accepted as valid. This retrospective on a decade-plus of software architecture research examines the maturation of the software architecture research area by tracing the types of research questions and techniques used at various stages. We will see how early qualitative results set the stage for later precision, formality, and automation and how results build up over time. This generates advice to the field and projections about future impact. Keywords: Software architecture, research paradigms 1.

The technology for the design of systems to perform extremely complex combinations of real-time functionality has developed over a long period. This technology is based on the use of a hardware architecture with a physical separation into memory and processing, and a software architecture which divides functionality into a disciplined hierarchy of software components which exchange unambiguous information. This technology experiences difficulty in design of systems to perform parallel processing, and extreme difficulty in design of systems which can heuristically change their own functionality. These limitations derive from the approach to information exchange between functional components. A design approach in which functional components can exchange ambiguous information leads to systems with the recommendation architecture which are less subject to these limitations. Biological brains have been constrained by natural pressures to adopt functional architectures with this different information exchange approach. Neural networks have not made a complete shift to use of ambiguous information, and do not address adequate management of context for ambiguous information exchange between modules. As a result such networks cannot be scaled to complex functionality. Simulations of systems with the recommendation architecture demonstrate the capability to heuristically organize to perform complex functionality. 1.

In this report we present a large manufacturing example (7:01 10 states) that uses the Hierarchical Interface-based Supervisory Control method that we presented in [14]. We discuss the application of our method to the Atelier Inter-etablissement de Productique (AIP), a highly automated manufacturing system. We describe the system, and our supervisor design, closing by discussing the results of successfully applying our method to show that the system is nonblocking and that our supervisors are controllable. This example demonstrates that our method can be applied to interesting systems of realistic complexity that were previously far beyond our means.

Behavior-Oriented Design (BOD) is a development methodology for creating complex, complete agents such as virtual-reality characters, autonomous robots, intelligent tutors. BOD agents are modular, but not multi-agent systems.

Abstract not found

Conventional approaches to analyze the behavior of software applications are black box based, that is, the software application is treated as a whole and only its interactions with the outside world are modeled. The black box approaches ignore information about the internal structure of the application and the behavior of the individual parts. Hence they are inadequate to model the behavior of a realistic software application which is likely to be made up of several interacting parts. Architecture–based analysis, which seeks to assess the behavior of a software application taking into consideration the behavior of its parts and the interactions among the parts is thus essential. Most of the research in the area of architecture–based analysis has been devoted to developing analytical models, with very little if any effort being devoted to how these models might be applied to real software applications. In order to apply these models to software applications, methods must be developed to extract the parameters of the analytical models from information collected during the execution of the application. In this paper we present an experimental approach to extract the parameters of architecture–based models from code coverage measurements obtained during the execution of the application. To facilitate this we use a coverage analysis tool called ATAC (Automatic Test Analyzer in C), which is a part

Designers are often unsuccessful in designing for change using traditional modularity techniques. A complementary modularity technique called information transparency can improve a designer's ability to simplify changes by exposing the interdependence of dispersed program elements that must be changed together for correctness. Information transparency represents modules via similarity and architecture, rather than locality and abstraction. With these, a programmer can create locality with a software tool, easing change in much the same way as traditional modularity. When combined with information hiding, then, more complex module structures can be represented. Information transparency techniques include naming conventions, formatting style, and ordering of code in a file. Transparency can be increased by better matching tool capabilities and programming style. We discuss applications of information transparency and introduce design principles for software designers and tool designers....

Software Cost Reduction (SCR) is a set of techniques for designing software systems developed by David Parnas and researchers from the U.S. Naval Research Laboratory (NRL) beginning in the late 1970s. A major goal of the original SCR research team was to evaluate the utility and scalability ofsoftware engineering

Abstract: To date, the SCR (Software Cost Reduction) requirements method has been used in industrial environments to specify the requirements of many practical systems, including control systems for nuclear power plants and avionics systems. This paper describes the use of the SCR method to specify the requirements of the Light Control System (LCS), the subject of a case study at the Dagstuhl Seminar on Requirements Capture, Documentation, and Validation in June 1999. It introduces a systematic process for constructing the LCS requirements speci cation, presents the speci cation of the LCS in the SCR tabular notation, discusses the tools that we applied to the LCS speci cation, and concludes with a discussion of a number of issues that arose in developing the speci cation.