Arcade Game Maker Pedagogical Product Line: Product Line Production Plan, Release 2

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 and made miscellaneous changes	LMNorthrop
2.1	4/04	M	Modified the AGM production strategy description	JDMcGregor
2.2	6/04	M	Modified in response to comments	JDMcGregor
2.5	10/04	M	Modified due to variation point changes	JDMcGregor
3.0	4/05	M	Edited document	KERiley

Overview

Identification

The Arcade Game Maker (AGM) product line organization will produce a series of arcade games ranging from low to high obstacle count with a range of interaction effects, and it will be available on a variety of platforms. For more details about the scope, see Arcade Game Maker Pedagogical Product Line: Scope.

Document Map

The AGM product line is described in a series of documents that are related as shown in the following figure. This interactive map shows the order in which the documents should be read for the first time. After readers are familiar with the documents, they can go directly to the information needed.

Document Map

Using This Document

This production plan describes the general procedure for producing products with the current AGM asset base. The Management Information section provides a template for product-specific production plans. Product line organizations use production plans to capture how the product teams will build a new product, and a product-specific plan is developed before each product is constructed. This plan follows the outline provided by Chastek and McGregor [Chastek 02a].

Concepts

For definitions of basic concepts, see Arcade Game Maker Pedagogical Product Line: Acronym List/Glossary.

Readership

This document provides a template for product-specific production plans and is intended primarily for product development teams. Managers can use the product-specific plan to determine the resources required to produce a product, and technical members can use it to actually produce a product.

Timeline

This document is a product of the core asset team. All of the base classes illustrated in the Base Classes figure have been implemented and are available to the product-specific development teams.

Strategic View of Product Development

Assumptions

Two broad assumptions apply:

The company has an existing pool of software developers who are highly technical. They have fielded products on a variety of hardware platforms and are accustomed to being involved down to the driver level of the software
The product line contains games that are similar in content but that differ in platform. Differences in platform translate into differences in graphics implementation, which is a major feature of these products.

Qualities

We will briefly describe two types of properties: (1) product and (2) production process.

Product Qualities

Players will enjoy the games if they have a colorful display and realistic action.

A new game element should add to the display quality and portray the item it represents.
Game action must be fast enough to demand the player's attention. If the number of elements slows the game, alternatives must be investigated.
Game action must meet the player's expectation. The motion and reactions of movable elements must be realistic. As elements are added to the game, their actions and boundaries must be correctly set through parameters so that collisions look real.

Production Process Qualities

The production process in the AGM product line is largely manual. Developers are very technical, and the process allows for hands-on manipulation of the product. Providing a tool that automates the production process to a high degree would have frustrated the developers and wasted development resources.

Products Possible From Available Assets

The products that are possible from the available assets are simple, animated games that involve moving and stationary objects. Each game has an area in which all play occurs and implements a set of physical rules that control movement. Using the incremental approach, the asset base is only developed to the extent needed to construct the current set of products. As additional increments are completed, the variety of games that are possible may increase.

Production Strategy

The production strategy includes a domain-based design approach and a manual construction approach. The requirements analysis and architecture development will be based on domain information. For each new product, software developers will manually specialize assets, gather other domain-based core assets, and then build an executable by running a compiler and linker.

Core assets are being built incrementally. Therefore, earlier product teams will have fewer available assets than later product teams. Earlier product teams (particularly the freeware development team) will identify core asset candidates for use in the later increments.

The formal statement of the strategy¹ is as follows:

We will position ourselves as the leading provider of rapidly customized, high-performance, low-cost games by producing products that are easily modified, have better performance than our competitors, are sufficiently low cost to deter potential competitors from entering the market, and require sufficiently few resources to allow their use on any embedded computer. We will produce the initial products using a traditional iterative, incremental development process that uses a standard programming language, integrated development environment (IDE), and available libraries. We will create domain-based assets, including a product line architecture and software components, for the initial products in a manner that will support a migration to automatic generation of the second and third increment products.

Overview of Available Core Assets

Source Code Naming Conventions

The following naming conventions are used:

Game-specific classes begin with the name of the game and are created in a package devoted to that game.
Interface definitions end with "Interface."
Class names begin with capital letters.
Variable names begin with lowercase letters.
Suite methods for the DotUnit test case begin with "test."

Analysis-Level Assets

The requirements document includes the following assets:

The domain analysis model organizes the concepts in the main domain (games) and provides the attributes and relationships of each concept.

Developers who are new to the domain should study this asset to understand the product's background.
The feature model shows the features of products.
The use case model provides a superset of product requirements. Select the appropriate use cases for your product.

High-Level Design Assets

The main high-level design asset is the software architecture, which is described in Arcade Game Maker Pedagogical Product Line - Architecture Documentation, Volume 1: Beyond Views and Volume 2: Software Architecture Views. The following figure shows the architecture's base classes. Product-specific versions of these classes should be defined at a high level in each product-specific production plan.

Base Classes

Source Code

Each interface in the existing architecture has been implemented. The C# components are named according to the guidelines in the Source Code Naming Conventions section.

Test Cases

This section describes existing test cases. Use an existing test case if it covers functionality or features included in the new product.

Test cases are not yet available for all code assets.

Unit Tests

Individual unit tests are constructed using the DotNet testing framework and are available from the Unit Test icon on the Document Map. The source code is in the form of classes.

The following unit test classes are currently available:

The Velocity/Direction/Speed Cluster of tests

Integration Tests

If integrating units results in a component, test it at the API level. (If it results in a GUI, see the following System Tests section.)

System Tests

System tests are currently done manually. Each system test is a scenario derived from a specific use case. When a use case is applied to more than one product, the related test cases can also be applied to that new product. These test cases are documented in the test plan for a product.

Inputs and Dependencies

Inputs

Game inputs are as follows:

mouse and keyboard events
names of the files to save the score and the state of the game (when the change cases for saving are implemented)

Dependencies

Game dependencies are as follows:

graphics library of the programming language
operating system (when the change case for saving a game is implemented)

Variations

Absorbing vs. Reflecting

The stationary game elements participate in the game by providing collision behavior. Core assets include two major behaviors:

A stationary element may reflect the movable element according to the laws of physics.
A stationary element may absorb the movable element so that it is deleted from the game.

A parameter on each element determines which of these behaviors is performed.

Event Handling

The event handling routines vary from one game to another. An implementation of the EventHandlerDefinitions interface is provided as a parameter to the GameBoard component. Each mouse and keyboard event is handled as defined in the implementation of the parameter.

Detailed Production Process

Product teams will use the following four-step production process that was developed as Brickles and Pong freeware games were built:

identify the product, define it, and analyze it incrementally
design the product
build the product
test the product

The exact content of the steps is determined by the attached processes of the core assets that are selected to be used to produce the product.

Identify, Define, and Analyze the Product Incrementally

This step includes the following three tasks:

Identify products.

(Products are already identified. Because each product is a single game, this task was accomplished when you identified games during the product line planning.) Replace this with the scoping rules defined in the scope document that determine whether a product is in scope or not.
Define the rules of the game.

There are several versions of most of these games, so the product team must first decide on a set of rules to implement.
Analyze features for the new game that are variations from previous games, and identify existing features that must change for this game. Replace this with the attached process of the feature model. That process should describe how to create a product configuration by resolving the variations in the feature model.

Design the Product

This step includes the following tasks:

Derive the product-specific architecture from the product line architecture. Replace this with the attached process from the software architecture that describes how to resolve the variation in the product line architecture.
Plan how to provide those features from existing components. Add the attached processes from the selected components. These attached processes should contribute to the feature set and to the test suites.
Plan how to provide the remaining features from new assets.
Design the product-specific implementation of the game interface.
Design the new implementation of the EventHandlerDefinitions interface. Replace this with the attached process for the interface definition. This will provide guidance on implementing the interface.

Build the Product

This step includes the following 10 tasks:

Start new ClassLibrary in a Visual Studio Project using Game_name Definitions as its name. Use this class for all new classes except the game definition.
Start a new Windows Application in a Visual Studio Project using Game_name.
Copy form1.cs from a previous product line project.
Change the namespace name to Game_name.
Configure the new GameBoard.
Replace this with the attached process from the configuration management plan that will guide the product developers in managing the build.
Copy data.txt from a previous game's working directory. This is the resource file for the game.
Edit data.txt to reflect the new game.
Write the game-specific classes needed for the game.
Compile the resource file.
Copy the compiled resource file to the Debug directory.

Test the Product

This step includes the following five tasks:

Test each core asset, by inspection or execution, as it is created or revised. If the asset is revised, revise the previous testing materials and reapply them to the new version of the asset.
For a code asset, code the unit test asset as a DotUnit test class. Replace this with the attached process from the abstract unit test suites that describes how to derive concrete test cases from the abstract test cases.
Revise the initial generic game system test set for each new game.
Create a game-specific system test set for each new game as shown in the following figure.
Maintain system test cases as text documents and apply them manually. Add the attached process for each of the features selected for this product. This process will point to test cases and test procedures for that feature.

System Test Cases Related to Products

Tailoring the Production Plan to a Product-Specific Production Plan

Overall, the product line production plan is very generic and applies to all products built using the current asset base. However, some parts of the plan must be modified for a specific product. Those portions are marked by indicating where to insert the attached processes for the core assets selected to support product-specific development.

In the Detailed Production Process section, each subsection includes directions on how to use a specific attached process in building the production plan.

The Management Information section includes the two most important and obvious sections that must be modified: the schedule and the bill of materials (BOM). Since we are using a manual product production approach, the schedule defines which personnel are needed when. The BOM provides a method for tracking the use of core assets.

Management Information

Schedule

The following table provides a schedule template that includes all steps from the process described in the Detailed Production Processsection. For the product-specific production plan, update the entries in the Performed By and Estimate/Date Performed columns.

Schedule Template
Process Step	Product-Specific Task	Performed By	Estimate/Date Performed
Product Identification	Done during product planning	Product planning	Done
Product Definition	Define the rules of the new game.	Analyst	≅ 0.5 day
Product Analysis	Analyze features.	Analyst	≅ 0.5 day
Product Design	Identify new elements needed by the game.	Designer	≅ 2 hours
	Identify changes to existing elements.	Designer	≅ 0.5 day
	Design product-specific implementation of the game interface.	Designer	≅ 2 hours
	Design product-specific implementation of EventHandlerDefinitions.	Designer	≅ 2 hours
Product Build	Create new implementations and make changes to existing classes.	Developer	≅ 0.5 days
	Create new .Net projects for libraries and the application.	Developer	≅ 0.5 days
	Create the new make file.	Automated/developer	≅ 0.5 days
Product Test	Create unit tests for new elements.	Developer	≅ 0.5 day
	Modify existing unit tests for existing elements.	Developer	≅ 0.5 day
	Execute unit tests.	Developer	≅ 0.5 day
	Modify/extend the product test suite.	Tester	≅ 1 day
	Execute the product tests.	Tester	≅ 0.5 day

Production Resources

The primary resources are the Visual Studio .Net environment and the organization's UML modeling tool.

During the analysis and design steps, extend the UML model to include any new elements that must be defined.

Use the .Net environment to create any new components that are required. After all components are created, use the environment to build an executable.

Bill of Materials (BOM)

The BOM allows you to track the use of core assets. The following table includes a high-level list of available code assets. For the product-specific production plan, update the table with only those specific assets that will be used.

*Bill of Materials (BOM) Template*
Component	Source	Cost
Product-specific Game component	In-house	$0
Generic GameBoard	In-house	$0
Required Sprites (add specifics here)	In-house	$0
Implementation of EventHandlerDefinitions interface	In-house	$0

Product-Specific Details

The rules of the game are the most unique parts of the product. Distribute them across the EventHandlerDefinitions and the Game component, which is the container for the entire game implementation. Most of the rules enforced by Sprites are common across most (if not all) of the games. Develop the EventHandlerDefinitions component (like the Game component) specifically for a game.

Pay attention to the animation loop, which is the single most important product-specific detail in the Game class. It defines the game's sequence of events.

Metrics

Use the following two metrics to evaluate the product production process: (1) the number of new lines of code and (2) the number of unique lines of code.

New Lines of Code

This metric describes the number of lines of new code that must be written for this product. This new code may or may not be used in another product later. A high value indicates more effort required to produce the product and impacts cost and schedule.

Unique Lines of Code

This metric describes the percentage of the lines of code that are unique to this product. This metric changes over time: it can be difficult to predict which code gets reused or remains unique. A high value indicates less similarity between products and indicates a longer payback time.

Attached Processes²

The main attached process that describes how to create the product specific production plan is defined in the Tailoring the Production Plan to a Product-Specific Production Plan section.

Constructing the Production Plan

The following figure shows a high-level version of building a production plan. For details, review Chastek and McGregor's work [Chastek 02a].

High-Level Process for Constructing a Production Plan

Changing the Production Plan

The following figure describes the change process. After each product is produced, data are collected and used to update the core asset base for the next increment's products. After those changes are reflected in the architecture documentation and the generic production plan, the plan is reviewed to identify inconsistencies between it and the core asset base. The core asset team member who owns the plan initiates the review.

Production Plan Change Process

References and Further Reading

For details about the references cited in this document, see Arcade Game Maker Pedagogical Product Line: Bibliography.

¹ For the complete rationale for this production strategy, see the "For the record" memorandum from the VPPD, Memo 04-01.
² This section is the "attached process" described by Clements and Northrop [Clements 02]. The process in Constructing the Production Plan defines how the production plan is initially built. Changing the Production Plan focuses on modifying the existing production plan of the product line.