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 Memo 04-04

To: CEO
From: Vice President for Product Development
CC: Vice President for Product Planning
Date: August 8, 2004
Re: Variation Point Difficulty

We recently discovered a problem with the AGM product line. A variation point that was not identified in our original analysis requires the reworking of several core assets, and the schedule has slipped. Fortunately, we still have six products to produce. If the usual figures of payoff after three products hold, we will still be much better off having used the product line approach than a one-off approach. We can revise the business case if you want to clarify this issue. Details for the new variation point are included below.

History

Originally, the variation analysis was conducted assuming that products would be manufactured using the Java language. Later, we switched to C# but did not revisit the variation analysis to determine if there were any implications. There were some, but they were not immediately obvious. Construction of the freeware tier of products proceeded with no difficulties. But when construction of the wireless products began, the implications became obvious.

Wireless Products

Our products will operate on wireless devices that use the Mobile Information Device Profile (MIDP). However, we discovered that the MIDP-defined API for products running on the device did not bind to C#, so we switched back to Java. Switching languages required relatively simple revisions to code assets, but then we also discovered that not all devices that support MIDP support floating point arithmetic as well. This restricted MIDP API forced us to switch graphics libraries as well, which required even more extensive revisions to the code assets than we initially anticipated.

Lessons Learned

We have learned two important lessons. First, do not rely on the implementation language to encapsulate the variation in platforms. If the product mix includes devices with which the team is not familiar, there should be an abstraction layer that could be replaced during implementation but that conceptually separates the product functionality from platform concerns. Second, analyses of any type should be revisited, particularly when a decision (such as making a language change) is made that has far-reaching implications. Currently, once an analysis is completed and the report is delivered, it is not clear who has responsibility for the analysis and accompanying decisions or that there is anything to have responsibility for. We can address this confusion by treating an analysis as a working document and identifying an owner who would periodically revise it to reflect current conditions. Unless you object, I will make that policy official and assign owners to the analyses that have been conducted so far.