1.1 Identification
The Sykes/McGregor ArcadeGame Product Line 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 ArcadeGame scope document.
1.2 Document Map
The Sykes/McGregor ArcadeGame Product Line is described in a series of documents. These documents are related to each other as shown in Figure DOCMAP. 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 manage the production of products.
Figure DOCMAP
1.3 Concepts
A software product line is a group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission and that are developed from a common set of core assets in a prescribed way.
A product line core asset is any deliverable that is intended for continuing use in multiple products.
A product is any saleable or useable output produced from the product line assets.
Application engineering is the construction of a product using the product line architecture and selecting from the inventory of available product line components. It is accomplished by identifying the specific values for each variation point in the product line architecture. The organization that manages this set of activities is responsible for using the assets to produce a single product. This team is responsible for achieving the specific qualities defined for the product.
Domain engineering creates, acquires, and manages the resources needed to build an entire set of products. The organization that manages this set of activities is responsible for long-term maintenance of individual assets that will be used across products. The organization produces sufficient assets to cover the variations in the architecture.
1.4 Readership
This document is intended to provide some level of information to all of the stakeholders in the Sykes/McGregor ArcadeGame 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.
The Sykes/McGregor ArcadeGame product line is being operated by two individual teams. One is based at Clemson University and one at Wofford College. The two principals are professors at the two schools. The product line is a cooperative effort. Decisions are either joint decisions between the two principals or they are unilateral decisions localized within the realm of responsibility of one of the principals.
Other contributors involved in the product line will be under the direct authority of one of the two principals. They will follow specifications in creating their assigned assets. They will document any decisions they make and these decisions will be reviewed by the appropriate principal.
The products produced in the product line will be used for the purposes of experimentation and publication. The software will be freeware with no one individual retaining a proprietary interest. The software will be covered by the GNU Freeware License.
Sykes and McGregor have 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. Having an organization that maintains a set of assets will provide a quick response (provided the needed product is with in the scope of the product line).
The product line approach is being adopted to improve Sykes/McGregor’s planning process. The product line will be a success if products are developed more rapidly without sacrificing quality. The planning process will consider publication possibilities over the breadth of the product line.
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 Sykes/McGregor 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 section 1.3.
4.1.1 Domain Engineering
Initially, the domain engineering team will be developing a component-based architecture for the product line. The team will construct the ArcadeGame framework and the components that populate the framework. Eventually, the team will also be constructing the game-specific components.
4.1.2 Application Engineering
An application engineering team will have responsibility for building a specific product. Initially, this task will start with the team configuring the ArcadeGame framework and then building any additional components needed to complete the application. Eventually, the team would construct an application by selecting from the product line components.
4.2 Processes
The organization has decided to use a modified version of the Rational Unified Process (RUP). Each of the logical organizational units will operate the process for their area of responsibility. That means that the core asset team will step through all of the phases except for final product integration. Each application engineering team will operate every step in RUP including product integration. The differences come in the amount of resources required at each step. The application engineering teams will use less effort at each step than the core asset teams.
4.3 Physical organization
The product line organization currently has members in two physical locations: Clemson, SC and Spartanburg, SC. There is the potential for more members to be added. The realities of geographic separation will be taken into consideration when creating work breakdown structures. Related tasks will be assigned to a single physical location.
In general, the work will be shared between the two design centers. Specifically the Clemson design center will have a larger responsibility for documents and process and the Spartanburg center will have the larger responsibility for architecture and design.
If other teams in remote locations are added to the product line organization, they should be added in one of two ways. The team would either have responsibility for a specific component or for a specific product in the product line.
The arcade game domain is a rapidly changing and expanding body of knowledge and market of products. Projects currently take a sufficiently long time that initial product conception under goes numerous iterations prior to final product release. The product line must encompass sufficient products to make the approach economically feasible, yet not have a time horizon that is so far in the future that the product line architecture is changed radically.
5.1 Notations and Languages
The architectures and other design assets will be constructed using the Unified Modeling Language (UML). Extensions to UML will be used to facilitate the representation of an architecture.
The code assets will be implemented in C#.NET. This language was chosen as part of the exploratory part of the product line. The product line team will be exploring the component capabilities of the .NET platform.
5.2 Development Process
The organization will use a modified version of the Rational Unified Process (RUP) as the development process for both the core assets and the specific products. The changes that must be made in RUP are described in section 4.2.
5.3 Operational Constraints
5.3.1 First Economic Law of Product Lines
The number of products that it takes to make a product line profitable is directly related to the amount of variation among the products. The upper bound of this relationship is the cost of building the products in a "one off" approach. Theoretically, the lower bound might be the cost of a single project; however, this is not realistic. Weiss's estimate of 3 products, on average, is a better lower limit.
5.3.2 Second Economic Law of Product Lines
The viability of a product line is directly related to the useful lifetime of the domain components created and used by the product line. If the useful lifetime of a component is less than the interval between releases of products then the components are not "re"usable.
In this section we will present recommendations to the rest of the organization as to steps that are required in order for the product line to succeed.
6.1 Perform a detailed scope analysis
Our past performance has indicated a tendency to begin tinkering with code and from there to evolve a product. For this product line to be successful we need to carefully describe the scope and variations of the products in the product line.
6.2 Prototype Implementations
The organization has not used C#.NET previously. A number of components should be prototyped, tested and trashed. The final implementation of assets should reflect the experience from these prototypes.
6.3 Establish clear responsibilities
With two independent groups working together, the team should develop a clear line of responsibility.
|
[Bachmann 00] |
Bachmann F., et. al.,
The Architecture Based Design Method, SEI Technical Report, 2000. (http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html) |
|
[Bass 98] |
Bass L., Clements P. and
Kazman R., Software Architecture in Practice, Addison-Wesley, 1998. |
|
[McGregor 92] |
McGregor, John D. and
Sykes, David A. Object-Oriented Software Development: Engineering Software for
Reuse, International Thomson, 1992. |
|
[McGregor 01] |
McGregor, John D. and
Sykes, David A. A Practical Guide to Testing Object-Oriented Software,
Addison-Wesley, 2001. |
|
[Northrop 02] |
Northrop
L., Framework for Software Product Line Practice, SEI Report, 2002. (http://www.sei.cmu.edu/plp/framework.html) |