Arcade Game Maker Product Line – Concept of Operations

19 Pages·2004·0.06 MB·English

by  Systems Staff

Arcade Game Maker

Product Line –

Concept of

Operations

ArcadeGame Team

July 2003

Table of Contents
1 Overview 1
1.1 Identification 2
1.2 Document Map 2
1.3 Concepts 3
1.4 Readership 3
2 Approach 4
3 Background 5
4 Organizational Considerations 6
4.1 Logical organization 6
4.1.1 Domain Engineering 6
4.1.2 Application Engineering 6
4.2 Processes 7
4.3 Physical organization 8
5 Technical Considerations 9
5.1 Notations and Languages 9
5.2 Development Process 9
5.3 Operational Constraints 9
5.3.1 First Economic Law of Product Lines10
5.3.2 Second Economic Law of Product
Lines 10
6 Recommendations 11
6.1 Perform a detailed scope analysis 11
6.2 Prototype Implementations 11
6.3 Establish clear responsibilities 11
7 References 12
i

Revision Control Table
Revision Type
Version Date A-Add, D- Person
Description of Change
Number Revised Delete, M- Responsible
Modify
5.1.1 added to show
changes
2.0 3/10/03 A JMcGregor
5.2.1 added to show
changes

1
1 Overview
1.1 Identification
The Arcade Game Maker (AGM) Product Line organization will produce a series of arcade
games ranging from low obstacle count to high with a range of interaction effects. More
detailed information can be found in the Arcade Game Maker scope document. This
document describes how the product line will be organized and managed. It is modeled after
[Cohen 99].
1.2 Document Map
The Arcade Game Maker Product Line is described in a series of documents. These
documents are related to each other as shown in Figure 1. This map shows the order in which
the documents should be read for the first time. Once the reader is familiar with the
documents, the reader can go directly to the information needed.
This is the Concept of Operations (CONOPS) document. Product Line organizations use this
document to capture how the organization will make decisions and how they will manage the
production of products.

2
Figure 1- Document Map
1.3 Concepts
See the Glossary document for definitions of basic concepts.
1.4 Readership
This document is intended to provide some level of information to all of the stakeholders in
the Arcade Game Maker framework. The CONOPS describes for a manager the decision
making process. When a manager must contact all parties affected by a decision, the
CONOPS provides that roadmap. Technical members of the organization can use the
CONOPS to determine whom to contact for decisions.
3
2 Approach
The Arcade Game Maker product line is operated by an organization that reports directly to
the Vice President for Product Development (VPPD). The VPP appointed a Product Line
Manager (PLM) who manages all aspects of the product line organization. The PLM has a
dotted line report to the Vice President for Product Planning (VPPP).
The product line organization is divided into one permanent core asset team, responsible for
domain engineering, and a varying number of temporary product teams, responsible for
application engineering. The core asset team is responsible for the long-term view of product
development while the product teams take short-term views focused on individual products.
The products produced in the Arcade Game Maker product line will be used for the purposes
of experimentation and publication. The software will be distributed as freeware but the
company will retain its proprietary interest. The software will be covered by the GNU
General Public License.
4
3 Background
Arcade Game Maker (AGM) has a history of sequential development of game-oriented
products in which the results of one project are used as the basis for the next product. This
has been problematic in that there is no official linkage between projects and no formal way
to manage the handoff of pieces produced as output by one project and used as input by
another. Nor have there been any standards for the format or level of quality of the outputs.
Scheduling has also been problematic. When a new product is needed, it is needed very
quickly. The product line organization will provide that quick response (provided the needed
product is with in the scope of the product line) because the core asset base has been designed
for mass customization. The core assets have been designed to handle a specified range of
variability. The scheduling process will be revised based on the new approach to product
production.
AGM’s planning process has not been effective. The product line approach will improve
AGM’s planning process by broadening it scope and lengthening its reach. The planning
process will be modified to address multiple products simultaneously and to look further into
the future in terms of evolution of the individual products. The product line will be a success
if the appropriate products can be developed more rapidly without sacrificing quality. The
planning process will contribute to this by ensuring that the appropriate

5
4 Organizational Considerations
A software product line adds a layer of organization not found in project-oriented software
development organizations. This organization coordinates the development of core assets and
their use by product teams. The AGM product line organization is an independent
organization. The organization owns the product line architecture, the core assets and the
products produced from these assets.
4.1 Logical organization
The product line organization is structured into two layers: domain engineering and
application engineering. These two layers are defined in sections 4.1.1 and 4.1.2.
4.1.1 Domain Engineering
Initially, the domain engineering team is developing a component-based architecture for the
product line. The team will construct the AGM framework and the components that populate
the framework. The team will also be constructing the game-specific components.
AGM has been making games and has a number of versions of various games. The domain
engineering group has decided to explore these previous products to see if any ideas or even
actual code might be mined and packaged for use in the current product line.
The domain engineering team is managed as a sustaining organization. Significant asset
development is managed as a project within the organization. Selected members of the team
have received project management training.
4.1.2 Application Engineering
An application engineering team has responsibility for building a specific product. Initially,
this task will start with the team configuring the AGM framework and then building any
additional components needed to complete the application. The team constructs an
application by selecting from the product line components.
The application engineering team follows the production process defined in the production
plan.
Each product development effort is managed as a project. Selected members of the team have
received project management training. They are eligible to be assigned as the lead of a
product development team.
6