Arcade Game Maker Pedagocical Product Line John D. McGregor

August 2003

This work is sponsored by the U.S. Department of Defense.

The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense.

Copyright 2003 by Carnegie Mellon University.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.

External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent.

This work was created in the performance of Federal Government Contract Number F19628-00-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013.

For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

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 misc. changes LMNorthrop

Table of Contents

Abstract .................................................................................................................. iii

1 Introduction ..................................................................................................... 1

2 The Company .................................................................................................. 2 2.1 Type..........................................................................................................2 2.2 Structure ...................................................................................................2

3 Strategic Objectives........................................................................................ 5 3.1 Market position..........................................................................................5 3.2 Time to Market..........................................................................................5 3.3 Productivity...............................................................................................5 3.4 Mass Customization..................................................................................5

4 Current Development Environment............................................................... 6 4.1 Language History......................................................................................6 4.2 Design Paradigm......................................................................................6 4.3 Development Personnel............................................................................6

5 Chronology...................................................................................................... 7

6 Executive Profiles ........................................................................................... 9 6.1 CEO..........................................................................................................9 6.2 VP for Products.........................................................................................9 6.3 VP for Product Planning............................................................................9 6.4 VP for Business Affairs............................................................................10

Abstract

This document presents context information for the Arcade Game Maker (AGM) Product Line, an example product line, being jointly developed by Clemson University and the Software Engineering Institute. This document is not a standard product line development document but is needed to provide the information that would be “common knowledge” in a real development organization. It also provides a level of meta-knowledge that is not captured in written form in an organization but that is needed to fully understand the decisions made in the product line process.

1 Introduction

This document is the gateway into the Arcade Game Maker (AGM) Product Line example. The document 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 does support 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].

The case study examines a company that has adopted the product line approach. The case study covers a three-stage process that the company went through in order to reach a stable product production process. The case study will track the evolution of the product line, the decisions that led the product line to its current state and will provide a number of assets.

This example is meant to be an actual product line with sufficient assets that readers could extend the product line to include additional products with very little effort and could contribute additional assets.

2 The Company

2.1 Type The company, Arcade Games Maker, is a subsidiary of a multi-national corporation. The company produces a series of software-intensive products delivered directly to retailers that in turn sell these products directly to individual consumers. The company is one of several subsidiaries of the corporation. These subsidiaries 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” for “arcade game maker.”

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

The CEO has several direct reports, see Figure 1, 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 the entities in Figure 1. The Director of Human Resources controls the training budget for AGM. The VPPD must coordinate with the Director in order 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

approach in which each product, as well as each major asset, is viewed as a project. Personnel are “matrixed” into a project, see Figure 2. Initially a core asset team and the first product team were formed as projects. There are now three active product teams and one core asset team.

Each product team is responsible for one game. That team is responsible for all three instantiations of that game. The core asset team is responsible for making the infrastructure for each different environment as transparent as possible.

Chairman, corporate

CEO, Arcade Game Maker

VP for Product Planning

VP for Product Development

VP for Business Affairs

Director, Human Resources

Figure 1- CEO interactions

Functional teams

Core Asset team

UI Team Game Engine Team

Architecture Team

Database Team

Brickles team

Pong team

engineer engineer engineer engineer

engineer

engineer engineer engineer

engineer

engineer

engineer

engineer

engineer engineer

engineer

Functional team membership

Pbowling team

VPP

3 Strategic Objectives

The company has identified several strategic objectives. The AGM Product Line is expected to contribute directly to the attainment of those objectives.

3.1 Market Position AGM will be a market leader. Currently two other companies have 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. In order to achieve this strategic objective, the company decided that it must become at least an early adopter.

3.2 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 are 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.

3.3 Productivity AGM will increase productivity so that the labor content per product is lower than it is currently. Software makes up roughly 90% of the content of current products. To remain competitive AGM must reduce the cost of building the games.

3.4 Mass Customization

4 Current Development Environment

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

4.1 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 have now begun to use a variety of approaches including active server pages for internet-based games.

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

4.3 Development Personnel The development staff is heavily loaded with people who have been with the company for many years. A few have computer science degrees but many have electrical engineering degrees. This is 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 specialized software engineers.

5 Chronology

This section provides a comprehensive time line for AGM’s product line activities. This will support the descriptions of decisions that are made and the evolution of the team’s thinking and of the artifacts. 1998:

May – a team investigates object-oriented analysis and design techniques by creating an implementation of the Brickles game; this internal release involved a domain analysis and a design

2000:

March – company considers building freeware versions of games prior to release of actual game as advertising for the “real” thing June – an implementation of Brickles is released to the public; team experimented with domain analysis and object-oriented modeling October - Executive team reviews strategic objectives and finds need for quicker time to market and wider variety of products

2002:

March - VPPD and lead engineers identify software product lines as a possible solution technology April – Scout team assigned to investigate product lines, decision made that first product line will be a set of freeware games May – Identified a tentative product roadmap for the freeware product line July – Reorganized engineering staff into two teams: core team and initial product team

December – first version of arcade game product line domain analysis released

2003: February - first release of product line architecture available April – first product reaches final release May – artifacts from first product are re-engineered to be core assets

August – The three freeware games have been constructed using the core assets

TODAY? all activities beyond this point are tentative

October – First client product to be released 2004: January – the first of three products to run on wireless devices will be released 2005: January – a new product line will address new challenges

6 Executive Profiles

6.1 CEO The CEO was hired into the corporation just as the AGM was being formed. He has a number of 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 entire life of the company.

He has a degree in electrical engineering. Due to this background he views product building as the assembly of pre-constructed 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 in general and in his company in particular.

6.2 VP for Products 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 the 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 when sufficient discussion has occurred.

6.3 VP for Product Planning

6.4 VP for Business Affairs The VPBA is an MBA with little previous experience with software-intensive products. He has been with the company for about 5 years, all as the VPBA. When the product line effort began he became aware of the problems with purchasing software from outside vendors. He still has problems understanding the differences between contracts for software and contracts for hardware.

6.5 Director of Human Resources The DHR has been with the subsidiary company as 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 laws affect 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 only contributes when the issues involve personnel. He often reminds the other executives of the conflicting demands on the development staff. He often is a conduit for developer concerns to the other executives.