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: Concept of Operations, Version 2.0

Revision Control Table
Version Number Date Revised Revision Type A-Add,
D-Delete, M-Modify
Description of Change Person Responsible
2.0 7/05 A Created document JDMcGregor

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 AGM products, 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. The map is available online. Click on its icons to access AGM documents. This concept of operations (CONOPS) document describes how the product line will operate to accomplish its work. Product line organizations use this document to capture how the organization makes decisions and manages production.


Document Map

Concepts

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

Readership

This document provides a road map of the decision-making process for the AGM product line organization. Managers use the road map to determine who is affected by a decision and who needs to be informed about specific decisions. Technical members use the CONOPS to determine who to contact for decisions. All product line personnel use the CONOPS as the guide to how to carry out any product line action.

Product line guiding principles

The software product line strategy is intended to improve an organization's product production by planning and building a set of products as a group rather than treating each product separately. There are several fundamentals that affect how the product line organization should operate.

Plan a set of products as a unit. The software product line strategy is intended to improve an organization's product production by planning and building a set of products as a group rather than treating each product separately. The strategy is to analyze the similarities and differences between the products. The similarities allow developers to build assets that are used in all the products achieving very high levels of software reuse among the products. The variabilities allow developers to build assets that can be selected to support any of the identified variations among products.

Use development techniques that maximize reuse of all assets. AGM intends to achieve the high level of reuse through commonality analysis, explicit architectural support, and an organization that separates the functions of building pieces to be reused and using those pieces to build products.

Organize around roles. The Corporate Structure figure shows the structure the VPPD has designed for the product line organization. This CONOPS discusses how this new structure works.

Determine and enforce boundaries on which products are a part of the product line. When assets are created, they are created to apply to as many products in the product line as possible. The strategy is to analyze the commonalities and variabilities between the products. The commonalities allow developers to build assets that are used in all the products achieving very high levels of software reuse among the products. The variabilities allow developers to build assets that are sufficiently flexible to support the range of identified variations among products. The AGM product line scope document captures this information.

Develop a structure that achieves the qualities required in the products AGM produces. The software architecture for the product line is perhaps the most significant core asset. The architecture captures and exploits those commonalities and variabilities. By spanning the range of commonalities and variabilities, the architecture guides the core asset builders in structuring the assets to meet the needs of the product line.

Define a process for producing products that contributes to the achievement of the business goals of the product line. The production plan for a software product line provides an explicit guide to core asset builders about how assets should be structured to be of use to product builders. The production plan also provides a guide to the product builders of how to build products given the characteristics of the core assets. This plan makes clear the need to span all of the features required in any product that is within the scope of the product line as core asset development occurs.

Vision for this product line

AGM expects that using the software product line approach will allow us to gain market share by offering custom products quicker and at lower cost than the competition. In particular, we expect to be able to have entry level, lower cost, employees build products from the core assets. This will reduce the cost of each product. Eventually we expect to automate production fully so that marketing personnel can build products further lowering costs.

We hope to be able to serve smaller niche markets that are within the scope of the product line but that we have not served previously. We will be working with a novelty manufacturer to identify innovative placements of microchips that have potential for simple games.

Metrics for success

The AGM product line will be a success if

Operations

AGM has created a new organization to manage the software product line. In this section we describe that organization and explain how the organization will operate.

Organizational structure

The direct reports to the CEO of AGM, shown in the following figure, remain the same. Each of these direct reports will have a role in governing the product line organization. Detailed role descriptions can be found in the Management Roles section.


Corporate structure

The structure of the product line organization is shown in the next figure. The Vice President for Product Development has the main responsibility and authority for the product line organization. He has appointed the Product Line Manager (PLM), who reports directly to the VPPD.

In consultation with the VPPD, the PLM decided to structure the organization by splitting the roles of core asset building and product building. Initially there is a core asset team and a Brickles product building team. We will add additional teams as other product building projects are chartered. The org chart shows the likely structure for the organization after several product building teams are chartered.

AGM will continue to have the functional teams shown in the organizational chart. These teams report directly to the VPPD. The PLM negotiates with the functional team leads for resources each time a new project is chartered.


Organizational Structure

Communication

The organizational structure, shown in the above figure, facilitates communication in a number of ways. Functional team members who are assigned to different building teams will share experiences at functional team meetings. This will cut across the core asset and product building teams providing an informal route for feedback from users of the core assets to builders of the core assets.

The production process, defined in the AGM production plan, also defines a formal avenue of communication between the core asset builders and the product builders. In this process, regular feedback opportunities are explicitly built into the process phases.

Other entities that facilitate communication include the Architecture Control Board (ACB) and the Configuration Change Board (CCB). The ACB owns the product line architecture and evaluates each request for a change to or deviation from the architecture. This board includes several members of the architecture functional team, the PLM, and the Core Asset team technical lead. The board meets as needed to evaluate requests. Periodically the ACB charters a project to refresh the architecture.

The CCB provides central supervision of the development threads. It ensures consistency among projects and ensures that each new product begins with the appropriate baseline. The CCB consists of the PLM and representatives from all the currently chartered projects including the continuing core asset project.

Operational tools

The core assets are stored in a CVS repository. They are available 24 hours a day. The repository allows the selection of any version of an asset.

A web site on the corporate intranet provides easy access to human-readable assets such as documentation plans and reports. The web site has links to the CVS repository, tool download sites, and related gaming sites.

Beginning with the second increment of the product line, the development environment is the Eclipse extensible IDE. The community version of Omondo's UML Modeler is used to draw architectural and design models. The IDE has a build facility that associates the code assets needed to build a specific version of a specific product.

Core Asset Development

The core asset development team is chartered by the Product Line Manager (PLM) to produce high quality assets that will support the organization in achieving its goals.

Core Asset Building Roles

Since the core assets cover the breadth of resources needed to produce a product, the AGM Core Asset Team has a wide variety of roles. We list a few of those roles.

Production constraints

The members of the AGM product building team are knowledgeable programmers. Most program construction techniques are within their capabilities. There are no constraints on the product techniques that the core asset team can select for building core assets that the product building teams will not be able to handle.

However, AGM's goal is to increase the automation in product production so that costs are lower and the current product builders are available to join the core asset team. This does constrain the techniques somewhat. Using domain specific approaches so that core assets will later translate quickly into a domain specific language and automatic program generation is a good choice for the long-term success of the organization.

Implications of the Production Strategy

The production strategy guides the core asset developers by describing how the assets will be used to produce products. The core asset team must determine how best to satisfy both the production constraints and the production strategy as they select technologies, processes, and models to use in creating the core asset base.

The production strategy for AGM states:

We will produce the initial products using a traditional iterative, incremental development process using a standard programming language, 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.

The strategy calls for a migration from manual production to automatic production. The core asset team must plan how to quickly provide for manual production but then modify assets and develop tools to support automatic production.

This strategy implies that even at the first we should follow a domain-centric approach. By building a domain model before building the architecture and other assets, we will be able to use a number of new techniques for creating a domain-specific language. This language will be the foundation for our move to automated production.

Attached processes

The core asset team attaches a process to each core asset that describes how to use that asset to build products. The attached process fits into the production plan of the product line. We intend to use a production process that is described using the Software Process Engineering Meta-Model. The following figure shows a portion of that figure to illustrate how we have extended the model for our purposes.


Portion of SPEM for Product Lines

Core asset development scenarios

The following scenarios illustrate various situations regarding core asset development.

Core asset acquisition

AGM studies each asset to determine whether it makes sense to build it in house, use one of the legacy assets, commission the construction of the asset by an outside vendor, or purchase an existing product from a vendor to use as the asset. A study team is assigned to determine the best approach. The Product Line Manager assigns a technical manager to chair the group. Members of the core asset development team are assigned based on dependencies with the asset. A representative of purchasing is assigned, as a non-voting member, to support the team. The final decision is made by the Product Line Manager based on the study team's recommendation.

Core asset packaging and delivery

The core asset development team assigned to develop an asset packages it for use and commits it to the core asset base. The packaging for the asset varies with the type and role of the asset. We have decided to use PDF as the packaging for all human readable documents. The software assets being developed in the first increment will use dynamic link library packaging while assets in the second increment will be packaged in ZIP files. The AGM asset development standards call for specific types of documentation to accompany each asset. The asset package must be reviewed by a team consisting of at least two technical staff, a technical manager, and a technical communications specialist. Once issues identified in the review are resolved, the asset is released into the asset base.

Core asset sustainment

Each core asset is assigned an owner when it is placed in the asset base. The owner is usually one of the original developers. The owner tracks trends in the domain and uses of the asset in products. The asset owner receives feedback from product development teams. The owner creates and maintains a sustainment plan which describes the evolution path of the asset. The asset owner periodically spends a portion of their time sustaining their assets. The exact amount of time available for this activity is determined by the owner's functional team leader in consultation with the PLM.

Product Development

The PLM, in response to a request from either the VPPP or the VPPD, examines a proposed product to determine whether it is within the scope of the product line. The PLM charters a product development project for any product that is added to the product line.

Product Building Roles

The product building teams share all of the roles listed in the Core Asset Building Roles section. In addition

Implications of the Production Strategy

The production strategy for AGM states:

We will produce the initial products using a traditional iterative, incremental development process using a standard programming language, 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.

The manner in which the product builders conduct their work is determined by how the core asset team decides to fulfill the production strategy. In the initial increments of the AGM product line, product builders will manually map requirements into the architecture to specific code modules. They will then compile and link code modules. The exact details of this are specified in the AGM Production Plan.

The production strategy will eventually change how the product builders build products and ultimately it will change the skill set required to be a product builder. As the core assets mature to the point they support automatic code generation, the product builders will only need to specify products. Programming skills and even understanding the architecture will be unnecessary.

Using the core assets

The AGM Core Asset Base is accessible to all AGM asset and product builders. The software components in the Base are indexed based on the product line architecture. The other assets are arranged based on the development process. The product builder identifies the type of asset and its role in the product and locates the asset.

Each asset is self-descriptive. The asset package includes a description of how to use the asset including pointers to the correct tools to manipulate the asset.

Each asset is associated with tools that product builders use to incorporate the asset into the production process. In increment one of the AGM product the dynamic linked library is packaged with the product deployment package. In increment two the class jar file is included in the product's self-extracting jar deployment package.

Modifying the core assets

There will be occasions when a core asset will not quite provide the functions required but deadlines will not allow a formal revision of the core asset. With the approval of the product team lead and the PLM, a product builder modifies the core asset to satisfy the required function. The modification is created as a branch in the version control system. The modification is communicated to the core asset owner. The core asset owner will consider whether this branch should remain separate or the branch should be merged in a new version of the asset.

Providing feedback about assets

Checking an asset out of the asset base immediately initiates the feedback request mechanism. This is a triggered event stored in the feedback database. The core asset builder will have specified an interval. At the end of that interval, a feedback request will be emailed to the product builder who checked out the asset.

The product builder will complete this request when they have completed using the asset.

Product development scenarios

Constructing a product using only assets

The AGM product building team assigned to build a product will use an abbreviated development process. (This process is defined by the process definition team and is available in a separate document.) The team uses a word processor to edit the generic product specification. The team then uses the Eclipse IDE to create the product-specific driving loop. Finally, the product is tested on a standard set of test cases plus any product-specific test cases the team wishes to create.

Constructing a product with unique requirements

The product building team assigned to build a product will use a complete development process. (This process is defined by the process definition team and is available in a separate document.) The process uses an incremental approach. The effect of the additional requirements is first analyzed in the context of the existing product line requirements. This is done by modifying the game domain model. The team then plans the revisions to existing assets necessary to accommodate new concepts on the expanded domain model. Any new assets that are required are built, usually by deriving them from existing abstract assets. A member of the asset building team is assigned to assist the product builders in the analysis of how to acquire the required assets.

Management

Launch and Adoption Strategies

AGM is following a reactive product line adoption strategy. We are leveraging existing artifacts to expedite the rapid development of the core assets. This strategy allows us to bootstrap our new organization by modifying the existing assets. They are modified to accommodate a wider range of variation.

This strategy will only be successful if we have the discipline to conduct product line-wide analysis and planning activities. The scope and production plan documents and the software architecture must be completed beyond the initial product.

Management roles

Four levels of management are involved in the AGM product line. Since these do not vary from one product to another we define them by position.

Vice Presidents

The Vice President for Product Development (VPPD) has primary responsibility for the AGM Product Line organization. He has authority over all personnel working on the product line. The Vice President for Product Planning (VPPP) has authority over the scope of the product line. He has final approval on all products assigned for development to the product line organization.

Product Line Manager

The Product Line Manager (PLM) reports to the VPPD with a dotted line relationship with the VPPP. The PLM has day-to-day operational responsibility for the product line operation and content. The PLM has designated authority over certain types of decisions as defined in this document.

Team Leader

The core asset and product builder team leaders report to the PLM. Each has responsibility for achieving the goals specified for their team. The core asset team leader is responsible for creating, managing, and maintaining the inventory of assets needed to build products. The product builder team leader is responsible for producing those products authorized by the PLM.

Project Lead

Each asset and product is developed in a project chartered by the responsible Team Leader. The Project Lead reports to the Team Leader who chartered the project. A project lead has responsibility for achieving the purpose stated in the project charter. The lead has the authority to remove a project member.

Organizational structure, roles and responsibilities

The AGM software product line organization is housed under the Vice President for Product Development (VPPD). The Product Line Manager (PLM) has responsibility for the product line organization and reports to the VPPD. The organization has two teams: the core asset builders and the product builders. Each team has a lead who reports to the PLM.

The core asset team lead is responsible for establishing the production capability of the product line organization. This team produces assets such as the software architecture, the generic production plan, and the software components used to build product executables.

The product building team lead is responsible for operating the production capability of the product line organization. Each product is built by chartering a project staffed by members of this team and representatives from the appropriate functional teams.

AGM also has a system of functional teams. Each team provides a certain expertise to any product development project in the company. The functional team leads report to the VPPD. A functional team lead is responsible for sustaining the expertise of the team so that it is available to AGM as needed.

Challenges and risks to successful implementation

Our products have been developed in isolated, stove-piped projects. Each team has had total autonomy. The primary challenge to successful implementation of the product line organization is developing a method of operation that stresses cooperation among projects.

A second challenge is developing a planning capability that is sufficiently robust to support the product line organization. We do not have a history of careful, comprehensive planning. Core assets are built in anticipation of being used in multiple products. The product line organization must be able to coordinate at least 3 product development efforts to be successful.

The primary risk to this effort is that the necessary practices will not be applied sufficiently well to achieve critical momentum. In that event, we may actually be in a worse situation than before trying the product line approach. We are mitigating this risk by studying successful cases of use of the product line approach and by conducting comprehensive planning exercises among the executive team.

Continuous improvement

One of the goals of the AGM product line organization is to improve our operation over time. The production strategy defines one direction in which to improve. The intention is to mature the core assets to the point that products can be automatically generated from the assets. Data will be collected to guide operational changes.

Management scenarios

Add a product to the product line

The Vice President for Product Planning (VPPP) initiates new products; however, that does not automatically add the product to the product line. At the request of the VPPP, the PLM charters a feasibility study. The study explores the proposed product in the context of the scope of the product line. The study team makes a recommendation to the PLM who, in consultation with the VPPD, determines whether to accept the new product into the product line or to reject the product.

Begin development of a product

In accordance with the agreed upon schedule, the PLM charters a product development project when appropriate. The PLM works with the functional team leads to staff the project.

Assessing progress

The PLM is responsible to the VPPD for periodically assessing the progress of the product line organization. The PLM requests input from the functional team leads as to the impact of the product line on their teams. The PLM also requests input from each of the chartered project managers.

Interconnections

In this section, interconnections among the three basic areas of responsibility are described. Operational risks are also identified.

Core assets and Product building

The core asset team is responsible for providing the product building team high quality assets that are immediately usable. The product building team is responsible for providing the core asset team with feedback about the usefulness of the assets. The product builders also identify, and sometimes create the first generation of, new assets.

A database of deficiency reports (DRs) is maintained by the configuration management team. This tracking mechanism allows the reporter of a deficiency to monitor the resolution of the problem they have reported.

Core assets and Management

Management is responsible for providing the core asset team the resources needed to carry out their charter. The VPPD provides a budget for the core asset team.

The team provides the VPPD with estimates of costs per asset based on long term tracking of development costs.

Product Production and Management

The VPPD provides the PLM with requirements for the products in the product line including delivery requirements. The PLM either charters a product building project in response to those requirements or rejects the product as being outside the scope of the product line.

Escalation

Issues between the core asset team and the product building teams that can not be resolved are escalated to the PLM. Issues between the PLM and one of the teams may be further escalated to the VPPD.

Issues between the product line organization and the VPPP are resolved by the AGM CEO.

Problem resolution meetings are scheduled as needed. All resolutions are recorded in the operational procedures appendix of this documentation.

Risk management

Risk management is everyone's responsibility. The PLM is responsible for maintaining a product line risk assessment. It is updated every time a product line progress report is made to the VPPD. Project leads are responsible for identifying risks to their specific projects. These are maintained as part of the project information.

The operational risks to the product line include

Appendix - Operational Procedure Resolutions

This appendix will be created over time as issue resolutions amplify on the descriptions in the main body of this document.