Pedagogical Product Line
Business Case
Concept of Operations
Unit Test Plans
Production Plans
System Test Plans
Brickles Product
Pong Product
Bowling Product
Misc Documents

Arcade Game Maker Pedagogical Product Line: Scope

Revision Control Table
Version Number Date Revised Revision Type A-Add,
D-Delete, M-Modify
Description of Change Person Responsible
1.0 7/03 A Created document JDMcGregor
2.0 12/03 A, M Put in SEI format, made miscellaneous changes LMNorthrop
3.0 8/04 M Edited document PWalters



The Arcade Game Maker (AGM) product line will produce a series of arcade games. Each game is a one-player game in which the player controls, to some degree, the moving objects. The objective is to score points by hitting stationary obstacles. The games range from low obstacle count to high and will be available on a variety of platforms.

Document Map

The AGM product line is described in a series of documents that are related to each other as shown in the following figure. This interactive map shows the order in which the documents should be read for the first time. Once readers are familiar with the documents, they can go directly to the information needed. This is the scope document. Its purpose is to define the boundaries of the product line. Design and implementation decisions are made to address the full scope of the product line but with no concern for any characteristics outside the product line.

Document Map

Reusable Components

This document establishes the high-level context for work in the product line. In a product line, components are designed to be reusable within the context of the product line. That is, no attempt is made to make a component "as general as possible." Each design decision is made with regard to the extent of the products in the product line. The architecture further refines the context defined in this document.


This document is intended to provide some level of information to all the stakeholders in the AGM software product line. Managers will find information that supports product planning, architects will find information that supports commonality and variability analysis, and product developers will find the rationale for each product's membership in the product line.

Use in Product Production

This document is used in the earliest stages of product production. It is used when the product production process seeks to determine whether it is feasible to build the proposed product as part of the product line. The lists of common features and variations are used to determine the fit between the proposed product and the product line. Later, assets such as the architecture can be used to provide more detailed information about product fit with the product line.

Product Line Context

In-Scope Products

The context of the AGM product line is illustrated in the following figure. The four games shown inside the circle constitute the current definition of the product line. Those shown outside the circle are out of scope and will not be constructed from the assets built for the product line.

Context Diagram

Each product in the product line

The games may have multiple players, but only one is active for a particular match. For example, having a computerized player is useful for testing purposes.

Product Line Variation

The principle variations in the AGM product line are the

These variations are elaborated on in the Arcade Game Maker Pedagogical Product Line - Architecture Documentation, Volume 1: Beyond Views and Volume 2: Software Architecture Views.

Out-of-Scope Products

The AGM product line does not include traditional "board" games. A framework1 for this type of game was provided by McGregor and Sykes [McGregor 92] but is out of scope for this product line. These games contain an element of strategy not included in the current product line. Board games usually allow multiple players. Strategy games are also out of scope. Dungeons and Dragons and other more recent games will not fit in the AGM product line.

In-Scope Features

Each product will provide the user (called a player) with the ability to interact with the game and to control some portion of the action. The product will operate according to the usual rules of each game and provide a graphical representation of the state of the game.

Out-of-Scope Features

Each product will control hardware through an existing operating environment so variations in hardware will be handled by the operating system


The above sections have provided a first level of data capture for scoping the product line. The previous figure provides a functional context. The attribute/product matrix shown in the following table gives a market view of the scope. In this table, the products are divided into three high-level categories, which correspond to three different markets. As the product line expands into commercial products, we should do a more in-depth analysis using a technique such as PuLSE-ECO [DeBaud 99].

Example Attribute/Increment Matrix
Feature Freeware Arcade Games Commercial PC Games Commercial Wireless Games
display standard bitmaps vector graphics wireless access protocol WAP bitmap
interaction mouse/buttons pointing devices/buttons buttons
game pieces simple icons dynamic icons dynamic icons
scoring high scores stored locally local storage/scores shared with subscription scores stored on network/subscription required

Feature Model

In this section, we present a high-level feature model of the arcade game domain. This model captures the product features that are necessary to compete in the market and satisfy our existing customers. It includes all features in all products.

Top-Level Feature Model

Action Subfeatures

Services Subfeatures

Rules Subfeatures

Determining Product Fit2

For a new product to be created using the assets of the product line, the product must be judged to be within the scope of the product line. The process for determining whether a product is in scope will depend on how formally the scope is defined.

For the AGM product line, the scope is partially defined by the attribute/product matrix shown in the previous table. As the process diagrammed in the following figure shows, the new product is compared to each column in the matrix. If the new product fits the first column, the new product may belong in the product line. Next, the proposed product would next be evaluated against the architecture description for a more technical match. If the proposed product fits one of the other columns or does not match any of the columns, additional market analysis should be performed to determine whether the product line scope should be expanded to include the proposed product.

Process Flow for Adding a Product to a Product Line


For information about the references in this document, see another document in the Arcade Game Maker Product Line series: Arcade Game Maker Pedagogical Product Line: Bibliography.

1 A product framework provides a tightly coupled architecture and set of components that can be used to quickly complete any application within the scope of the architecture.

2 This section is the "attached process" described by Clements and Northrop [Clements 02]. For the product line scope, this process focuses mainly on determining whether a particular product could be produced profitably using the assets of the product line.