This paper describes a tutorial to introduce a product line engineering solution, including tools and methods, that is the subject of an upcoming ISO standard and known as "Feature-Based Systems and Software Product Line Engineering." Its usage is spreading beyond the traditional engineering realm, across the entire enterprise in areas such as product marketing, portfolio planning, manufacturing, supply chain management, product service and maintenance, and much more.

This paper describes a demonstration of the product line engineering tool and framework Gears from BigLever Software. Gears provides a single feature modeling language, a single variation point mechanism that works across the entire product lifecycle, and a single automated product configurator that are used to configure a product portfolio's shared engineering assets appropriately for each product in the portfolio. The result is an automated production line capability that can quickly produce any product in the portfolio from the same, single set of shared assets.

Summary form only given. A product line is a family of similar products with variations in features and functions. Product Line Engineering (PLE) is an engineering discipline for product lines using a shared set of engineering assets, a managed set of features, and an efficient means of production. It takes advantage of the commonality shared across the family while efficiently and systematically managing the variation among the products. PLE can trace its roots in software back to the 1970s; its roots in manufacturing go back centuries. But only the relatively recent (2000s or so) advent of industrial-strength automation and methodology has enabled Systems and Software PLE to emerge as a reliably repeatable engineering paradigm. It is worth studying because of the phenomenal improvements in product time to market, engineering productivity, portfolio scalability, and system quality that PLE has shown, over and over, to bring to organizations that apply it. This talk explains the fundamentals of modern PLE, shares some brief case studies, and discusses how the underpinnings of formal methods and notations are enabling PLE to achieve its remarkable results.

Product lines that use automated tools to configure shared assets (e.g., software or requirements or test cases or user documentation) based on product descriptions have long been known to bring about substantial development cost avoidance when compared to clone-and-own or product-specific development techniques. Now, however, it can be shown that the cost avoidance for configuring multiple shared assets is superlinear -- that is, the overall cost avoidance exceeds the sum of the that brought about by working with each of the shared assets in isolation. That is, a product line that configures (for example) requirements and code will avoid more cost than the sum of code-based plus requirements-based cost avoidance. In addition, we also observe a superlinear effect in terms of the number of products in the portfolio as well. This paper explores why these effects occur, and presents analytical and empirical evidence for their existence from one of the largest and most successful product lines in the literature, the AEGIS Weapon System. The result may lead to new insight into the economics of product line engineering in the systems engineering realm.

This paper describes a tutorial on an advanced set of product line engineering solutions, tools, and methods, which are being referred to as Second Generation Product Line Engineering (2GPLE).

Automotive manufacturing ranks among the most extreme instances of systems and software product line engineering (PLE). The product family numbers in the millions, each product is highly complex in its own right, and the variation across products is literally astronomical in scale. This paper explores the aspects that make the domain extreme and the very specific implications they have for PLE. These implications include the need for efficient manufacturing, complexity management, concurrent development streams, globally distributed engineering and production, a hierarchical product family tree, multi-level variation binding, constraint management, and a highly robust and integrated PLE tooling environment. Happily, the PLE paradigm supporting these implications brings about a number of opportunities for analysis and automation that provide efficiencies of production previously unattainable. We focus on one example in depth: The management and automated generation of the many thousands of calibration parameters that determine vehicle-specific software behavior. Throughout, we use the vehicle product line at General Motors, which we believe to be the world's largest, to illustrate and ground our journey through automotive PLE.

This paper tells the story of the AEGIS Weapon System product line and how it evolved from a series of standalone software programs with no sharing into a true systems and software product line. The paper focuses on the strong internal and external governance of the product line. The need for strong governance is brought about by the strong role that the AEGIS customer community plays in oversight of design, development, and procurement. The paper recounts the product line's beginnings, and describes how the product line is operated today. Organizational issues, measurement issues, and governance issues are covered, along with a summary of important lessons learned about operating a product line in an environment of strong competing interests.

This paper describes a tutorial on an advanced set of product line engineering solutions, tools, and methods, which are being referred to as Second Generation Product Line Engineering (2GPLE).

Many organizations that produce a portfolio of products for different customers need to ensure that sensitive or restricted content that may appear in some products must not appear in others. Examples of this need include complying with statutes in different countries of sale, protection of intellectual property developed specifically for one customer, and more. For organizations operating under these requirements and producing their products under a product line engineering paradigm that relies on automation in product derivation, there is a need for a method to ensure that the content restrictions have been met in the derived products. This paper describes an auditing method that meets this need. It was created for use in the Second Generation Product Line Engineering approach that is being applied by Lockheed Martin in their AEGIS ship combat system product line.

The paradigm of software product line (SPL) has already become popular not only in researchers but also in practitioners. However, that never means SPL is practiced in the real development. It is often observed that many companies hesitate to introduce SPL although they are bothered by numerous product variants of different/changing requirements or constraints and understand the importance of SPL.

This paper describes a tutorial on an advanced set of product line engineering solutions, tools, and methods, which are being referred to as Second Generation Product Line Engineering (2GPLE).

Live Training Transformation (LT2) is the product line strategy put in place by the United States Army Program Executive Office for Simulation, Training and Instrumentation (PEO STRI). The purpose of the LT2 product line is to provide a common set of core assets including architectures, software components, standards and processes that form the basis of all Army Live Training systems. As products consuming LT2 core assets evolve to meet the latest requirements of the military live training community, changes to the core product line architecture must also be made. Based on thorough analysis of the LT2 core capabilities and user trends toward web-enabled and mobile computing technologies, a Service Oriented Architecture (SOA) strategy was identified and adopted as the objective architecture for the evolving LT2 product line. Future success of the LT2 product line now depends on the alignment of product line engineering concepts with the business and technical benefits of SOA, and to ensure that systematic reuse continues to provide substantial return-on-investment for the Army. This paper addresses the challenges of adopting SOA into an existing software product line, the unique circumstances of the LT2 SOA environment, and present a set of analysis and design considerations for the product line engineering community.

General Motors faces probably the most complex Systems and Software Product Line Engineering (PLE) challenges ever, in terms of product complexity, richness of variation, size of organization, and an unforgiving requirement to support over a dozen simultaneous development streams all geared towards each new model year. To meet this challenge, GM turned to an advanced set of explicitly defined product line engineering solutions, which have been referred to as Second Generation PLE (2GPLE). This includes reliance on features as the lingua franca to express product differences in all phases of the lifecycle, deeply nested hierarchical product lines, industrial strength automation to provide modeling consistency throughout, and more. This paper explains how 2GPLE is being applied at General Motors, and the technical and organizational lessons learned so far.

This paper describes a demonstration of the product line engineering tool and framework Gears from BigLever software. Gears provides a single feature modeling language, a single variation point mechanism, and a single automated product configurator that are used to configure a product portfolio's shared engineering assets appropriately for each product in the portfolio. The result is an automated production line capability that can quickly produce any product in the portfolio from the same, single set of shared assets.

Second Generation Systems and Software Product Line Engineering (2GPLE) has emerged to pick up where classic software product line practice leaves off, and is empowering a whole new class of product lines that solve unprecedented challenges of scale and variation complexity. These so-called "mega-scale" product lines often define product spaces with more possible variations than there are atoms in the universe.

In the development of complex systems the requirements for the system will almost always remain uncertain late into the software development. In gas turbine engine control systems at Rolls-Royce, typically 50% of requirements will change between Critical Design Review and Entry into Service. Ignoring or not planning for requirements uncertainty will cause scrap and rework that will manifest later in the project. This paper evaluates the impact of not managing these uncertainties and describes how Rolls-Royce uses Requirements Uncertainty Analysis to reduce this impact. The paper summarises the findings from an extensive Six Sigma study into requirements uncertainty and provides an overview of the technique now used to identify and monitor uncertainty through a project life. The return on investment of this technique has been between 100:1 and 500:1.

Currently, software testing is mainly carried on independently from software architecture-related information. Some approaches propose to perform integration and regression testing with respect to software architecture descriptions, but less attention has been paid to analysing software architecture in order to develop a less costly and time-consuming test plan that covers the requirements of the system of interest. If on one side, it is well known that providing an effective test plan is crucial to software quality, on the other side software testing is extremely difficult because it stems from the complexity of current software systems.

The objective of this workshop is to bring together researchers and practitioners to report and discuss the challenges and opportunities for integrating quantitative methods in product line engineering with the objective of achieving both technical and business goals. In particular, we are seeking contributions that, on the one hand, deal with product line estimation and metrics for the effective management of product line projects, and on the other hand, provide some insight into new trends in value-based product line engineering.

A good estimation tool offers a "model" of a project and is usually used to estimate cost and schedule, but it can also be used to help make trade decisions that affect cost and schedule as well as to estimate risks and opportunities. It was evident that Rolls-Royce needed a cost model to underpin decisions when they launched a Software Product Line initiative. The first generation cost model was based on COCOMO II, which represents the software product as a single size measure (Source Lines of Code) but makes limited use of the architecture or any characteristics of the product being developed. The next generation of the cost model, currently under development, is intended to account for the quality attributes of the core assets and the resulting products in order to estimate their impact on cost and net-benefit to the business. The objective of this paper is to describe our current efforts to integrate key quality attributes into the SPL cost model. We describe the quality attributes selected, the reason for their selection and the benefits we expect to obtain after integrating them into the model.

A complex system's requirements almost always remain uncertain late into its software development. In gas turbine engine control systems at Rolls-Royce, for a traditional project (non-product line) typically 50% of requirements will change between Critical Design Review and Entry into Service. Requirements uncertainty is particularly relevant when defining the scope of a Software Product Line. If the core asset team fails to recognise or accommodate requirements uncertainty, changes will manifest later in the product line. If the core asset team over-compensates by adding too much functionality or variability to account for a wide range of uncertainty, they will invest effort that may never be required. The optimal balance can be found through an application of requirements uncertainty analysis and understanding the balance between the impact of risk and mitigation effort. This paper first describes the use of the requirements uncertainty analysis technique at Rolls-Royce for traditional (non-product line) software development and then explains how this technique works in the context of a software product line.

This paper summarizes the workshop on Architecture-Based Testing and System Validation which was organized in conjunction with the 9th Working IEEE/IFIP Conference on Software Architecture. The main goal of the workshop was to bring together researchers and practitioners both from the architecture design and software testing community to enable architecture-based software testing.

Requirements specifications seldom allow software and system architects to understand the business goals for a system. Architects need that information in order to design an appropriate architecture for the problem at hand. In this paper, we present a lightweight method based on goal oriented requirements engineering that begins with a canonical list of business goals and elicits specific business goals from the perspective of various stakeholders. It then interprets those business goals in terms of the quality attribute requirements that are so important to software architectures. Experience with using this method for a Boeing Air Transport System is presented.

Early aspects deal with crosscutting concerns in requirements analysis, domain analysis and architecture design [1]. Work on early aspects focuses on systematically identifying, modularizing, and analyzing such crosscutting concerns and their impact at the early phases of the software development life cycle.

An organization is architecturally competent if it has the ability to acquire, use and sustain the skills and knowledge necessary to carry out architecture-related practices that lead to systems that serve the organization's business goals. This paper presents some principles of architecture competence, based on four models that aid in explaining, measuring, and improving the architecture competence of an individual or an organization with respect to these principles, The principles are based on a set of fundamental beliefs about software architecture.

Much research in the software architecture field has focused on the purely technical aspects of architecting: architectural styles, documentation, analysis, architecture description languages, reverse engineering, and so forth. In this working session we seek to explore a less exhaustively studied, but equally important, realm: architectural competence. What defines a competent software architect? And equally important, what defines an architecturally competent software development organization? In particular, we seek to better understand the following issues: (a) What do architects actually do on a day-to-day basis? (b) What skills and knowledge must a competent architect have? (c) What does it mean to be a competent architect? (d) What can an organization do to get the best performance from its software architects? (e) How can we measure architectural competence of an individual or an organization and how can we increase this? Our goal for this working session is to propose an initial "theory" of architectural competence, even if very informally rendered, and then provide some practical guidance deriving from that theory to practicing architects (and to those who aspire to be architects), as well as technical managers in software development organizations.

This paper focuses on the human aspects of architecting software-in particular, the duties, skills, and knowledge of software architects. We present the results of a survey of approximately 200 public sources of information aimed at professional software architects that we conducted in the summer of 2006. We summarize what those sources have to say about the duties, skills, and knowledge that competent architects must perform and have.

The Views and Beyond (V&B) approach to software architecture provides practical guidance on the what, why, and how of creating IEEE 1471-2000 compliant documentation for your software architecture that will be used for years to come. The approach is based on the well-known concept of views and is presented in the context of prevailing prescriptive models for architecture, including the unified process and UML 2.0, which has improved support for representing key architectural elements over its predecessors. In this paper, students will be introduced to the views and beyond approach and will gain hands-on experience creating a new architectural style using the V&B style guide and learn how to document an architectural view in that style using the V&B view template. This paper concludes with a discussion of tool support for architectural documentation and a demo of a Web-based documentation system.

This paper argues that software architecture has always been the enabler for the ever-upward spiral in software engineering of more powerful problem-space languages, and will continue to be so

This paper summarizes the Workshop in Aspect-Oriented Requirements Engineering and Architecture Design.

This work describes a workshop that is intended to fill the void between variability requirements visible to those who deal with features and other product-level concerns, and the variability mechanisms visible to creators and consumers of a product line's core assets. The goal of the workshop is to begin to codify a body of knowledge for the informed and purposeful selection of variability mechanisms to use in a software product line's core assets.

A hall of fame serves as a way to recognize distinguished members of a community in a field of endeavor. Those elected to membership in a hall of fame represent the highest achievement in their field, serving as models of what can be achieved and how. Each Software Product Line Conference culminates with a session in which members of the audience nominate systems for induction into the Software Product Line Hall of Fame. These nominations feed discussions about what constitutes excellence and success in product lines. The goal is to improve software product line practice by identifying the best examples in the field. Nominations are acted on by a panel of expert judges, who decide which nominees will be inducted into the Hall of Fame. You can read about the current members of the Software Product Line Hall of Fame at http://www.sei.cmu.edu/productlines/plp_hof.html. Inductees from 2005 will be announced at the SPLC 2006 Hall of Fame session.

The "Software Architecture Documentation in Practice" working session at WICSA addressed practical issues concerning the creation, evolution, and uses of software architecture documentation. After paper presentations, discussion topics included enforcement/traceability, tooling, inhibiting factors to the widespread use of documentation, uses of architecture documentation, and UML as an architecture description language.

This lecture maps the concepts and templates explored in this tutorial with well-known architectural prescriptions, including the 4+1 approach of the Rational Unified Process, the Siemens Four Views approach, and the ANSI/IEEE-1471-2000 recommended best practice for documenting architectures for software-intensive systems. The lecture concludes by re-capping the highlights of the tutorial, and asking for feedback.

Building a system at the architectural level can be thought of as decomposition into components followed by a series of exercises in matching. Components must be composed with each other via matching mechanisms; matching signatures within those mechanisms ensures that data and control flows through the system; and matching semantics among the components ensures that the system meets its behavioral requirements. The standard concepts of software architecture (components, connectors, styles) have been widely used with little more than intuitive understanding of their meaning. Mechanism matching is currently an ad hoc exercise that relies on the peculiarities of programming language facilities. This paper presents a set of well-known but informally described software architectural elements used in system composition, and taxonomizes them under a basic set of characteristic features. This classification allows us to describe legal combinations of architectural elements by performing a simple matching exercise on the relevant features of the member elements. This classification also allows us to identify architectural elements that can be substituted for each other and satisfy the same mechanism matching requirements. This leads to delayed binding of architectural mechanisms, which in turns provides increased flexibility and greater opportunities for reuse of units of computation.

Software architects use a number of commonly-recognized "styles" to guide their design of system structures. Each of these is appropriate for some classes of problems, but none is suitable for all problems. How, then, does a software designer choose an architecture suitable for the problem at hand? Two kinds of information are required: (1) careful discrimination among the candidate architectures and (2) design guidance on how to make appropriate choices. In this paper, we support careful discrimination with a preliminary classification of styles. We use a 2D classification strategy with control and data issues as the dominant organizing axes. We position the major styles within this space and use finer-grained discriminations to elaborate variations on the styles. This provides a framework for organizing design guidance, which we partially flesh out with rules of thumb.

Many organizations face a serious challenge introducing new technologies into existing systems. Effective modernization requires knowing and articulating specific goals for the reengineering effort, conscious selection of technologies and technical approaches that can achieve those goals in the context of the class of system being upgraded, a staged migration plan, and an integration strategy to make in-hand components work under the newly adopted architecture. Although the study of reengineering is moving towards an engineering discipline, there are as yet no proven decision frameworks that allow an organization to rationally choose a modernization strategy. This paper provides an in-depth look at the engineering trade-offs made in modernizing a manufacturing engineering design system to use distributed object technology. From this case study, the outlines of a more general reengineering decision framework can be seen, and these are discussed.

This paper introduces MT, a collection of integrated tools for specifying and analyzing real-time systems using the Modechart language. The toolset includes facilities for creating and editing Modechart specifications. Users may symbolically execute the specifications with an automatic simulation tool to make sure that the specified behavior is what was intended. They may also invoke a verifier that uses model-checking to determine whether the specifications imply (satisfy) any of a broad class of safety assertions. To illustrate the toolset's capabilities as well as several issues that arise when formal methods are applied to real-world systems, the paper includes specifications and analysis procedures for a software component taken from an actual Naval real-time system.>

The authors examine the issues of satisfiability, clairvoyance, the demonstrable existence of timing faults, and event causality, all in the context of formal methods for real-time systems. Representative languages and logics are introduced to illustrate the points. The authors introduce SRSL, a simplified specification language used to illustrate the issues involved. They examine these issues in a particular specification language, Modechart. An action-free subset of Modechart is shown to be satisfiable and to obviate the need for clairvoyance. A technique for eliminating nonlinearizable computations from a specification language is shown. The usefulness of the ideas is illustrated by their use in a Modechart simulator.>

Many have sought a software design process that allows a program to be derived systematically from a precise statement of requirements. It is proposed that, although designing a real product in that way will not be successful, it is possible to produce documentation that makes it appear that the software was designed by such a process. The ideal process and the documentation that it requires are described. The authors explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. The contents of each of the required documents are outlined.

A careful reader, Max Stern of Teradata Corporation, has brought to our attention two errors in the above paper.1On page 253 in the second paragraph under point 4) the text reads, “A purely digital or purely hybrid computer is a special case of this general module.” It should read, “A purely digital or purely analog computer is a special case of this general model.”

This paper discusses the organization of software that is inherently complex because of very many arbitrary details that must be precisely right for the software to be correct. We show how the software design technique known as information hiding, or abstraction, can be supplemented by a hierarchically structured document, which we call a module guide. The guide is intended to allow both designers and maintainers to identify easily the parts of the software that they must understand, without reading irrelevant details about other parts of the software. The paper includes an extract from a software module guide to illustrate our proposals.