Arcade Game Maker Product Line Concept of Operations

Transcription

1 Arcade Game Maker Product Line Concept of Operations ArcadeGame Team July 2003

2

3 Table of Contents 1 Overview Identification Document Map Concepts Readership 3 2 Approach 4 3 Background 5 4 Organizational Considerations Logical organization Domain Engineering Application Engineering Processes Physical organization 8 5 Technical Considerations Notations and Languages Development Process Operational Constraints First Economic Law of Product Lines Second Economic Law of Product Lines 10 6 Recommendations Perform a detailed scope analysis Prototype Implementations Establish clear responsibilities 11 7 References 12 i

4

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

6 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

7 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

8 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

9 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

10 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 and 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 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

11 4.2 Processes The organization has decided to use a modified version of the Rational Unified Process (RUP) as the software development process. 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. In Tables 1 and 2, the shading shows the amount of effort expended on an activity in a specific phase by the team. Darker shading implies more effort. Table 1 Rational Unified Process Domain Engineering Domain Analysis Inception Elaboration Construction Transition Requirements Capture Requirements Analysis Architecture Design Detailed Design Component Implementation Product Production/Component Integration Product Testing Table 2 Rational Unified Process Application Engineering Domain Analysis Inception Elaboration Construction Transition Requirements Capture 7

12 Requirements Analysis Architecture Design Detailed Design Component Implementation Product Production/Component Integration Product Testing 4.3 Physical organization The product line organization currently has members in two physical locations. There is the potential for more company sites 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 locations. Specifically the headquarters design center will have a larger responsibility for documents and process and the satellite 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 teams are using a configuration management system that is network-based. The physical locations are transparent in the CM structure. All information is available at both sites. 8

13 5 Technical Considerations 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 undergoes 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 documented using the Unified Modeling Language (UML). Extensions to UML1.4, which will appear in UML2.0, will be used to facilitate the representation of the 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 Update Since the first version of this document, tools have begun to appear that implement UML2.0. We are currently updating some design documents to use UML2.0. Our experience with C# for the first three products has led us to change to Java for further implementation. C# did not provide the benefits we had anticipated. 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 manner in which RUP is used by each team is described in section Update Our experience with the initial three products has led us to adjust our development process. We will be using a degree of automatic generation for certain elements of the product line. 5.3 Operational Constraints 9

14 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. The typical estimate that it takes 1.5 as much effort to make components reusable is a better lower limit. Since the products in the AGM product line are being given away as advertisement, profit is only thought of in terms of new business generated. The games have been chosen specifically to be very closely related to each other. The intent in this product line is to minimize costs 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. For example, if the useful lifetime of a component is less than the interval between releases of products then the components are not "re"usable. Although the arcade game industry is an old one, changes in display technologies, releases of new graphics libraries, and new devices do force changes. The software architecture must address the need for evolvability in these areas. 10

15 6 Recommendations 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, each team should develop a clear line of responsibility. 11

16 7 Attached processes Building the organization The executive committee of AGM has the authority to define the AGM product line organization. They determine the size of the product line and consequently the size of the organization Determine the scope of the organization Define interfaces to other organizations Determine the logical structure of the PL organization. Assign authority and responsibility at the appropriate levels. Figure 2 - Building a product line organization 1 This section is the attached process described in [Clements 02]. For the product line Concept of Operations, this process focuses mainly on how the organization is initially constructed. The process also defines how to modify the Concept of Operations of the product line. 12

17 7.2 Modifying the organization The organization will be modified when there is sufficient evidence that the changes will result in improvements. Metrics are collected from the developers about the effectiveness of the current organizational structure. These serve as input to the process in Figure 3. Analyze data collected during operation. Bring together the managers affected by the existing and new organizations. Run scenarios associated with the collected data to investigate proposed organization. Refine the organization and roll it out to the engineers. Figure 3 - Organization modification process The metrics include the speed with which decisions are made; the correctness of the decisions that are made; and the longevity of decisions that are made. Authority and responsibility must be clearly assigned and at the appropriate level. 13

18 8 References For references see the Bibliography document. 14

19 15