Pedagogical Product Line
Overview
Business Case
Scope
Requirements
Concept of Operations
Architecture
Unit Test Plans
Production Plans
System Test Plans
Brickles Product
Pong Product
Bowling Product
Bibliography
Glossary
Misc Documents

Arcade Game Maker Pedagogical Product Line: Brickles Wireless Tier Production Plan

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
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 A, M Cloned the Brickles freeware tier production plan 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. 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 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 document describes how the Brickles wireless tier product will be produced in the AGM product line. 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 Brickles wireless tier product team. All of the base classes illustrated in the Base Classes figure have been implemented and are available to the product-specific development teams.

The Brickles-specific tasks had been performed for the freeware tier product. None of the product-specific tasks have been carried out yet for the wireless tier.

We were planning to produce the Brickles product for the wireless tier from these assets. Unfortunately, the freeware tier products used C#, which has no Mobile Information Device Profile (MIDP) API and forced us to switch to Java. Doing so required porting the code assets to Java and revising the Java APIs.

Producing this document is part of the project planning.

Strategic View of Product Development

Assumptions

Two broad assumptions apply:

  1. 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.
  2. 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.

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 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 possible games 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 strategy1 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:

Analysis-Level Assets

The requirements document includes the following assets:

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

Integration Tests

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

The following integration tests are currently available:

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.

The following test plans are currently available:

Inputs and Dependencies

Inputs

Game inputs are as follows:

Dependencies

Game dependencies are as follows:

Variations

Absorbing vs. Reflecting

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

  1. A stationary element may reflect the movable element according to the laws of physics.
  2. 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 needed vary from one game to another and from one tier to another.

For the wireless tier, a set of Palm hardware events is handled using the WABI library for Java.

Detailed Production Process

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

  1. identify the product, define it, and analyze it incrementally
  2. design the product
  3. build the product
  4. test the product

Identify, Define, and Analyze the Product Incrementally

This step includes the following tasks:

  1. 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.)
  2. 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.
  3. Analyze features for the new game that are variations from previous games, and identify existing features that must change for this game.

Design the Product

This step includes the following three tasks:

  1. Plan how to provide those features from existing components.
    Port from C# to Java, class by class, and then replace C#-specific APIs with Java APIs.
  2. Plan how to provide the remaining features from new assets.
    Derive newly required assets from the newly ported Java assets.
  3. Design the new implementation of the EventHandlerDefinitions interface.
    Replace mouse and keyboard events with the stylus event handlers.

Build the Product

This step includes the following nine tasks:

  1. Start a new Eclipse project using Game_name Definitions as its name.
    Use this class for all new classes except the game definition.
  2. Start a new class using Game_name.
  3. Change the namespace name to Game_name.
  4. Configure the new GameBoard.
  5. Copy data.txt from a previous game's working directory.
    This is the resource file for the game.
  6. Edit data.txt to reflect the new game.
  7. Write the game-specific classes needed for the game.
  8. Compile the resource file.
  9. Copy the compiled resource file to the directory containing the classes.

Test the Product

This step includes the following six tasks:

  1. Test each core asset, by inspection or execution, as it is created or revised.
  2. If the asset is revised, revise the previous testing materials and reapply them to the new version of the asset.
  3. For a code asset, code the unit test asset as a JUnit test class.
  4. Revise the initial generic game system test set for each new game.
  5. Create a game-specific system test set for each new game as shown in the following figure.
  6. Maintain system test cases as text documents and apply them manually.


System Test Cases Related to Products

Tailoring the Production Plan to a Product-Specific Production Plan

This is the specialized version of the generic production plan. The details below are for informational purposes only.

Overall, the production plan template 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.

The next 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 the steps from the process described in the Detailed Production Process section. 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 (Gary) ≅ 0.5 day (10/5/04)
Product Analysis Analyze the features. Analyst (Gary) ≅ 0.5 day (10/5/04)
Product Design Identify new elements needed by the game. Designer (Jason) ≅ 2 hours (10/6/04)
Identify changes to existing elements. Designer (Jason) ≅ 6 hours (10/6/04)
Design product-specific implementation of the game interface. Designer (Jason) ≅ 1 day (10/7/04)
Design product-specific implementation of EventHandlerDefinitions. Designer (Jason) ≅ 1 day (10/8/04)
Product Build Create new implementations and make changes to existing classes. Developer (Bob) ≅ 2 days (10/9/04)
Create new Eclipse projects for libraries and the application. Developer (Bob) ≅ 0.5 hour (10/10/04)
Create the new make file. Automated/developer ≅ 2 days (10/10/04)
Product Test Create unit tests for new elements. Developer (Bob) ≅ 2 days (10/11/04)
Modify existing unit tests for existing elements. Developer (Bob) ≅ 1 day (10/13/04)
Execute unit tests. Developer (Bob) ≅1 day (10/14/04)
Modify/extend the product test suite. Tester (John) ≅1 day (10/15/04)
Execute the product tests. Tester (John) ≅ 1 day (10/16/04)

Production Resources

The primary resources are the Eclipse JDT 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 Eclipse environment to create any new required components. After all components are created, 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 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 $1,000
Generic GameBoard In-house $ 725
Required Sprites: Puck, Paddle, Brick, BrickPile, Wall, Ceiling, Floor In-house $1,950
Implementation of EventHandlerDefinitions interface: BricklesEventHandlerDefinitions In-house $2,050

The senior personnel are billed at $75/hour, and junior personnel are billed at $50/hour. In the first table, there are 32 hours of senior analyst and designer times and 66.5 hours of junior developer and tester time. All costs are in-house components, so the BOM has a total cost of $5,725 for the assets needed for this product.

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 Processes2

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.


Process to Change the Production Plan

References and Further Reading

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


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