Linda M. Northrop

SEI's software product line tenets

Software product lines are emerging as a viable, important software development paradigm. Based on the Software Engineering Institutes research and experience, the concepts, activities, and practices described here can lead to successful product line development. How-tos, success stories, and lessons learned expand on the approach.

Initiating software product lines

E li Whitney revolutionized the manufacturing of rifles using interchangeable parts. Henry Ford did the same for automobiles, integrating the idea of interchangeable parts and an assembly line. A growing number of software development organizations are adopting approaches that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles to construct high-quality products faster and cheaper. Standard methods, referred to as software product line or software family practices, have developed around these approaches. This special issue focuses on the technical, managerial, and organizational activities related to introducing these practices. guest editors’ introduction

A Basis for Analyzing Software Architecture Analysis Methods

A software architecture is a key asset for any organization that builds complex software-intensive systems. Because of an architectures central role as a project blueprint, organizations should analyze the architecture before committing resources to it. An analysis helps to ensure that sound architectural decisions are made. Over the past decade a large number of architecture analysis methods have been created, and at least two surveys of these methods have been published. This paper examines the criteria for analyzing architecture analysis methods, and suggests a new set of criteria that focus on the essence of what it means to be an architecture analysis method. These criteria could be used to compare methods, to help understand the suitability of a method, or to improve a method. We then examine two methods—the Architecture Tradeoff Analysis Method and Architecture-level Modifiability Analysis—in light of these criteria, and provide some insight into how these methods can be improved.

Adopting and Institutionalizing a Product Line Culture

The strengths of product line engineering have been described before. But how can an organization make the move from developing one-of products to product line engineering without major interruptions in the day-today work? This paper describes how to perform the transition to product line engineering and lists the various strategies for such a transition. It also describes how to create an adoption plan and how to institutionalize product line engineering in an organization.

Exploring the Context of Product Line Adoption

To successfully adopt a product line approach an organization needs to define its adoption goals, conceive a strategy, and implement a plan to achieve those goals. This process is repeated for each business unit and individual affected by the product line adoption. This paper describes how the characteristics of the market, organization, business unit, and individual influence product line adoption goals, strategies, and plans.

Enterprise Framework for the Disciplined Evolution of Legacy Systems

Organizations that migrate legacy systems to distributed, open system environments or to a single product line of systems often fail because they concentrate on a narrow set of software issues without fully considering a broader set of enterprisewide management and technical issues. This article describes an enterprise framework that characterizes the global environment in which system evolution takes place and provides insight into the activities, processes, and work products that shape the disciplined evolution of legacy systems. The following checklists help identify critical enterprise issues that correspond to each of the frameworks elements.

Introduction to software product lines

Software product lines have emerged as a new software development paradigm of great importance. A software product line is a set of software-intensive systems sharing a common, managed set of features, and that are developed in a disciplined fashion using a common set of core assets. Organizations developing their family of products as a software product line are experiencing order-of-magnitude improvements in cost, time to market, staff productivity, and quality of the deployed products.

Software product lines: reuse that makes business sense

Summary form only given. Traditionally, software-intensive systems have been acquired, developed, tested, and maintained as separate products, even if these systems have a significant amount of common functionality and code. Such an approach wastes technical resources, takes longer, and costs more than necessary. A product line approach to software can reduce development cycles, improve return on software investments, improve software system integration, and give an organization more future options. Building a new product or system becomes more a matter of assembly or generation than creation, of integration rather than programming. Organizations of all types and sizes are discovering that a product line strategy, when skillfully implemented, can improve productivity, quality, and time to market. Software product lines present at long last a reuse strategy with real economic benefit. Making the move to product lines, however, is a business and technical decision and requires considerable changes in the way organizations practice software engineering, technical management, and organizational management. This article explores the basic concepts of software product lines, share experience reports from companies employing the paradigm, and explore the software engineering and management practices necessary to develop a successful software product line.

Reuse that pays

A company builds a software system capable of running a diesel engine in a week, and in one case over a weekend, as opposed to the full year that it used to take. Another company builds one of its typical systems with 13 software engineers instead of the more than 100 it once required, and at the same time decreases the systems defect rate ten-fold. Still another increases its software-intensive product offerings from four per year to 50 per year. Imagine being able to use one person to integrate and test 1.5 million source lines of Ada for a real-time command-and-control system onboard a ship, with safety-critical requirements? Or increasing software productivity four-fold over three years, as another company has done? These organizations all achieved their results through strategic software reuse. We software people have been promising the benefits of reuse for decades. Are we finally achieving a reuse strategy that lives up to its hype?

Structured Variation Management in Software Product Lines

Variation management is one of the key challenges associated with software product lines. Much is written about this topic. There are methods and tools available, home-grown and commercial, which attempt to make handling product line variations practical. The focus of these methods is on supporting software development; that is, handling variations in the code core assets. However, there are non-code core assets and they also have variations. For example, there are marketing roadmaps, requirement specifications, test cases, process definitions, and all kinds of documentation including user guides, to name just a few. These core assets also have to implement the required variations of the product line and need to do so in a consistent way or there will be incompatible implementations and resultant inefficiencies. The approach to variation we are suggesting takes an organization-wide perspective, covering the entire gamut of core assets not just the code We describe the definition, implementation, and management, including tools support, of a few essential variations throughout the organization to make handling product line variations more efficient and effective.