A Framework for Product Line Adoption Grady H. Campbell, Jr., Prosperity Heights Software U
- 格式：pdf
- 大小：168.34 KB
- 文档页数：9
March 1, 20021www.domain-specific.comA Framework for Product Line AdoptionGrady H. Campbell, Jr., Prosperity Heights SoftwareUnder particular conditions, aconventional software developmentprocess is inherently inefficient.Conventional processes wereconceived for the purpose of creating asingle solution to a well-definedproblem. Such processes are not idealfor the needs of a product line business,to repeatedly build similar products forcustomers having diverse andchanging needs. A process that hasbeen conceived for building a productline provides the means to producehigher quality products faster whilereducing redundant effort across thoseproducts. This paper describes aframework within which an organizationcan quickly adopt a product lineapproach tailored to its needs,capabilities, and preferences.BackgroundIn 1990, the Software ProductivityConsortium began developing theSynthesis methodology4 based on theconcept of product families5 extended toencompass all the acts and artifacts of asoftware production. In 1992, itintroduced a reuse adoption method2 toaddress the impediments to instituting aSynthesis process. In 1993, attemptingto formulate Synthesis in terms familiarto its industrial members, it restated thecontext for Synthesis through twodefinitions:Business area: A coherent market ofcustomers having similar needs.Product line: A collection of products(existing and potential) that addressa designated business area.In 1995, Boeing applied Synthesis aspart of a demonstration project for theUS Department of Defense6, providingsignificant insights into the challengesand strategies for instituting a productline approach.In 1996, Thomson-CSF initiated acorporate technology transfer initiativefor the adoption of Synthesis in fourbusiness areas3. This initiative appliedthe SPC reuse adoption method as anadjunct to the SEI Software CapabilityMaturity Model1 (SW-CMM).These and other experiences providethe basis for a disciplined approach toproduct line adoption.Repeatedly building similarproductsMany organizations conduct de factoproduct line businesses, repeatedlybuilding custom products as solutionsto similar problems. Others do so bycreating a single generalized solutionto all such problems by repeatedlyadding capabilities and options to asingle base product. Although theformer costs more than the latter, itProsperity Heights Software
March 1, 20022www.domain-specific.comprovides customers with products thatare more responsive to their specificneeds. The motivation for a product lineapproach is to give organizations theability to deliver custom products with alevel of effort closer to that of building asingle generic product.Traditionally, a product line businesshas been operated as a set ofindependent product developmentefforts that function by drawing from anavailable pool of developers who havepreviously built similar products. Thisconcentration of expertise repeatedlyapplied to different products can resultin good levels of productivity andquality.Such businesses succeed becauseexperienced developers tend to buildsimilar solutions to similar problems.They know how to accommodatedifferences without starting over with anentirely new solution. However, aneffort may fail or deliver an inferiorproduct if a key developer is notavailable when needed.Different people often solve similarproblems differently. Describing similarproblems differently can also lead todifferent solutions. However, the naturaltendency of an experienced developeron seeing a familiar problem is toderive a variation on a past solution.Analogously, a product lineorganization tends to pursue customershaving similar needs because it hasboth the knowledge and expertiserequired to build responsive productsand the practical experience to managecost and schedule constraints. Thesequalities give the organization acompetitive advantage over lessspecialized organizations.The motivation for processimprovement efforts is to eliminaterecurring causes of quality problems. Asecondary motivation is to improveproductivity and reduce costs. Forsoftware development, improvementefforts usually focus on the institution oforganization-wide standard practices.Standard practices reduce differencesin how individuals work, includingensuring that needed information aboutboth development efforts and resultingproducts are recorded and retained.Formalizing a product line with adomain-specific process makes anorganization’s scope of expertiseexplicit and creates an enhancedcapability for building similar productsof a particular type.Reflecting these views, adoption of aproduct line approach is the means bywhich an organization can enhance itsability to deliver high quality customizedproducts rapidly at reduced cost andeffectively evolve this ability over time tomeet changing market needs.The Nature of a Product LineApproachReuse-driven process improvement(PIr) is a unified model for adopting andimproving a product line approach toproduct development. PIr is specificallya definition of the reuse adoptionactivity of the Domain-specificEngineering™ (DsE) methodologyprocess (Figure 1); the purpose of PIr isto guide the conception and adoption ofa DsE process tailored to the needs of aparticular product line business.DsE is a methodology for domain-specific processes7. A domain-specificprocess is a process that is customized ™ Domain-specific Engineering is a trademark ofProsperity Heights Software.
