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: Overview

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 6/04 M Edited document PWalters


This document is the gateway into the Arcade Game Maker (AGM) product line example and includes supporting information that is not in standard product line documents. For example, included in this document is an overview of the structure of the fictional company that produces the product line. As such, this document is not part of the product line but supports various pedagogical devices such as problem scenarios.

This case study presents an example software product line. The example is intended for several types of use including training and self-study. The example follows the approach to software product lines described by Clements and Northrop [Clements 02].

This case study, which examines a company that has adopted the product line approach, covers a three-increment process that the company went through to reach a stable product production process. The product line experiment will build three game products, each in three variations. The case study provides a number of assets and tracks the evolution of the product line as well as the decisions that led the product line to its current state. The AGM example is meant to be an actual product line with assets sufficient enough for readers to extend the product line to include additional products with very little effort and contribute additional assets.

The Company


AGM, a subsidiary of a multinational corporation, produces a series of software-intensive products delivered directly to retailers that, in turn, sell them directly to individual consumers. The company is one of several subsidiaries that share portions of the product roadmap established by the parent corporation. They all make similar products but for somewhat different markets.

The remainder of this documentation will refer to the subsidiary as "the company" or "AGM."


AGM has a chief executive officer (CEO) who reports to the corporation's chairman of the board. Although the chairman has line authority over the AGM CEO, the CEO has a great deal of latitude in achieving the objectives identified by the corporation.

The CEO has several direct reports (see the following figure), including a vice president for product development (VPPD), a vice president for product planning (VPPP), and a vice president for business affairs (VPBA). The local director of human resources also reports to the CEO.

There are a number of horizontal interactions among these positions as illustrated in the figure. The director of human resources (DHR) controls the training budget for AGM. The VPPD must coordinate with the DHR to train managers and engineers in new techniques. The VPPP has primary responsibility for the product roadmap, while the VPPD is attempting to develop an efficient means of producing those products.

CEO Interactions

The engineering personnel all report to the VPPD as shown in the second figure. Originally, there was one product team that encompassed all the engineers. Within that team, the engineers were divided into functional specialties. The hardware teams built the game boxes, and the software teams developed the game code. As the product line was initiated, AGM decided to maintain the specialty approach by maintaining the functional teams while also having a project-based approach in which each product, as well as each major asset, is viewed as a project. Personnel are "matrixed" into a project (see figure). Initially, a core asset team and the first product team were formed as projects. Now, there are three active product teams and one core asset team.

Each product team is responsible for one game, including all three variations of that game. The core asset team is responsible for delivering core assets to each product team and for making the infrastructure for each different environment as transparent as possible.

VPPD's Matrix Development Organization

Core Asset Development Project Charter

The Core Asset Development Team is responsible for providing the Product Development teams with high-quality assets that meet their needs in a timely manner. The team will work within the constraints of the specified production method to produce assets that are compatible with the manner in which products will be produced by the product development teams. The team will negotiate schedules with the product development teams to ensure timely delivery of the assets. The Core Asset Development Project will be an on-going project with no pre-determined completion date. The project will only terminate when the product line is terminated. However, the initial level of activity will be much higher than eventually when refined versions of most of the assets have been delivered. During this lowering of activity, core asset development team personnel will gradually be transferred to product development teams wherever possible. The team lead will report to the product line manager.

Product Development Project Charter

The product development teams are responsible for delivering products that meet the functional and quality product requirements. The team is responsible for developing any product-specific functionality not accommodated by variation mechanisms in the core assets. The team will work within the constraints of the product-specific production plan for the product to be built.

Each Product Development Project will have a definitive termination point defined in its production plan. The schedule in that plan will identify headcounts for various points in the project and the anticipated termination date. The team lead reports to the product line manager.

Strategic Objectives

The company has identified four strategic objectives. The AGM product line is expected to contribute directly to the attainment of those objectives.

Market Position

AGM will be a market leader. Currently two other companies have a larger market share. This market is sensitive to how rapidly new technologies are introduced into products and the scope of the feature set. The company has been a "late adopter" of new technologies such as C++ and Java. To achieve this strategic objective, the company decided it must become at least an early adopter.

Time to Market

The company will be able to produce products at an increasingly rapid rate. Ideas for games come from a number of sources. Many ideas come from the popular media where an idea has a very short life span. AGM must be quick to develop and deploy any games based on the popularity of a media or sports figure or one inspired by an actual event.


AGM will increase productivity so that the effort per product decreases. Software makes up roughly 90% of the content of current products. To remain competitive, AGM must reduce the cost of building the games.

Mass Customization

The company will be able to serve more specialty markets. The current product development process requires too many resources to make products with projected sales of under a million units profitable. For example, the parent company's marketing division sees an opportunity in the area of convention giveaway products. They would like to be able to add a company's logo and other advertising marks to a game and sell it to that company as a marketing handout at conventions.

Funding for the Organization

The initial AGM product line is funded from the CEO's discretionary account as a pilot project at the request of the VPPD. The funding model is structured with a checkpoint at the end of each of three increments. The CEO has set expectations for each of these checkpoints and reserves the right to cancel the pilot at any of the checkpoints. At the end of the first increment, the freeware increment, no profit will have been made but the organization should show a trend toward a substantial increase in productivity. By the end of the second increment, there should be a positive trend in profit. At the end of the third increment, evidence of the improvements resulting from the software product line approach should be sufficiently positive to propagate the product line idea to the rest of the corporation.

Future funding for product line efforts will be evaluated using the SIMPLE and the data from the pilot. As sets of products are identified, the return on investment for using the product line approach will be computed as the basis for decision making. The product line strategy will be used when it is economically beneficial to do so.

Current Development Environment

In this section, we describe the software development environment prior to the use of the product line approach.

Language History

The company began manufacturing games in C in the late 1970s and migrated to C++ in the late 1980s. In the mid 1990s, the company switched to Java as the primary development language but kept some core functionality in C++. The company originally used simple applets as the basis for the game interface but has now begun to use a variety of approaches including active server pages for Internet-based games.

Design Paradigm

The company used a structured method with a functional paradigm until the mid 1990s when it began to take advantage of some of the object-oriented (OO) features of C++. Later, when the company switched to Java, it went to a full OO design paradigm with an iterative, incremental development process. Recently, this OO approach has been modified slightly to become a component-based approach.

Development Personnel

The development staff is heavily loaded with people who have been with the company for many years. A few employees have computer science degrees, but more have electrical engineering degrees due to the early emphasis on specialized game boxes. Only recently has the Human Resources department taken an active role in building a skills profile and actively recruiting software engineers who specialize in the various practices needed by the product line organization..

The staff can best be characterized as "developers." A developer performs the full life cycle of tasks: analysis, design, and coding tasks. Two developers have been trained on and dedicated to architecture on a part-time basis. The newer developers are paired with more experienced personnel for six months to a year for on-the-job training. Developers perform unit testing, and a separate team handles integration and system testing.


This section provides a comprehensive timeline for AGM's product line activities. This timeline supports the company's decisions and the evolution of its thinking and artifacts.

1998: May - A team investigates OO analysis and design techniques by creating an implementation of the Brickles game; this internal release involved a domain analysis and a design.
2000: March - AGM considers building freeware versions of games prior to releasing the actual game, as advertising for the "real" thing.
June - An implementation of Brickles is released to the public; the team experimented with domain analysis and OO modeling.
October - AGM's executive team reviews its strategic objectives and finds the need for a quicker time to market and wider variety of products.
2002: March - The VPPD and lead engineers identify software product lines as a possible solution technology.
April - AGM assigns a scout team to investigate product lines and decides that its first product line will be a set of freeware games.
May - AGM identifies a tentative product roadmap for the freeware product line.
July - AGM reorganizes its engineering staff into two teams: the core asset team and the initial product team.
August - AGM's scout team attends the Carnegie Mellon Software Engineering Institute's (SEI's) Second Software Product Line Conference (SPLC2).
September - Based on their experiences at SPLC2, AGM's scout team recommends an emphasis on architecture and generating domain-based assets. A production strategy is created.
November - The first version of AGM's arcade game domain analysis is released, along with a prerelease version of product line architecture.
December - The final version of AGM's arcade game product line domain analysis is released. The production method is defined and the production plan is created.
2003: February - The first release of AGM's product line architecture is made available.
April - AGM's first product reaches final release.
May - Artifacts from AGM's first product are reengineered to be core assets.
August - AGM's three freeware games have been constructed using the core assets.
Note: All activities beyond this point are tentative.
October - AGM's first client product will be released.
2004: January - The first of three AGM products to run on wireless devices will be released.
2005: January - A new product line will address new challenges.

Executive Profiles


The CEO was hired into the corporation just as the AGM was being formed. He has several years of experience managing the development of products using game boxes but less so with the software portion of the product. He has been CEO for the life of the company.

He has a degree in electrical engineering. Due to this background, he views product building as the assembly of preconstructed standard parts. Until very recently, he did not understand why it took the software developers longer to produce their portion of the product than it took the hardware staff. When it became obvious that software development was a bottleneck for product development, he took an in-depth look at software development both in general and in his company.

VP for Product Development (VPPD)

The VPPD was hired several years after the subsidiary was formed. She has experience in building software-intensive products but not games. She has a degree in computer science and understands the problems accompanying software development.

The CEO and VPPD complement each other when they take time to fully explain their perspectives on a problem. Without this sharing of information, they often clash because of their different viewpoints. If either takes action without consulting the other, the decision is often modified later after they discuss the situation.

VP for Product Planning (VPPP)

The VPPP has a background in consumer electronics such as game boxes, but he is less familiar with new environments such as wireless devices. He does not understand the implications of a specific feature being on the product delivery schedule or the implications it has on the product's memory consumption or performance.

VP for Business Affairs (VPBA)

The VPBA has a master's degree in business administration but little experience with software-intensive products. For the entire five years he's been with the company, he's been the VPBA. When the product line effort began, he became aware of the problems associated with purchasing software from outside vendors. He still has difficulty understanding the differences between contracts for software and contracts for hardware.

Director of Human Resources (DHR)

The DHR has been the subsidiary company's DHR since its inception. He was in the Human Resources department of the parent corporation before joining the subsidiary. He tends to focus on the myriad of laws affecting the employer/employee relationship. He has not developed any type of training tracking system, nor does he elicit training ideas from the other executives.

The DHR participates in product-oriented discussions but usually contributes only when the issues involve personnel. He often reminds the other executives of the conflicting demands on the development staff. He is often a conduit for expressing developers' concerns to the other executives.


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.