生產(chǎn)線平衡外文翻譯

1、<p>　　中文5470字，3000英文單詞，16500英文字符</p><p>　　文獻出處：Van Zyl J, Walker A J. Product line balancing[C]// Change Management & the New Industrial Revolution, Iemc. 2002.</p><p><b>　　畢業(yè)設(shè)計&l

2、t;/b></p><p>　　UNDERGRADUATE PROJECT</p><p><b>　　英文原文及譯文</b></p><p>　　學 院 機電工程與自動化學院</p><p>　　專 業(yè) 工業(yè)工程</p><p><b>　　學 號 &l

3、t;/b></p><p><b>　　學生姓名 </b></p><p><b>　　指導教師 </b></p><p>　　Product Line Balancing</p><p>　　An empirical approach to balance features acro

4、ss product lines</p><p>　　Jay van Zyl, A J Walker</p><p>　　*Rubico, Johannesburg, South Africa & California, Unites States of America</p><p>　　**Software Engineering Application

5、s Laboratory, Electrical Engineering, University of the Witwatersrand, Johannesburg, South Africa</p><p>　　Summary: How can multiple product lines be integrated across an organization to produce products to

6、market on time? - a question frequently asked by management and product delivery specialists. Once product lines are known product managers need to allocate features over a period of time to create a delivery oriented co

7、mpetence. The product value chain must be understood to balance resources, features and capitalize on market opportunities.</p><p>　　I. Introduction</p><p>　　How can multiple product lines be in

8、tegrated across an organization to produce products to market on time? – a question frequently asked by management and product delivery specialists. Once product lines are known, product managers need to allocate feature

9、s over a period of time to create a delivery oriented competence. The product value chain must be understood to balance resources, features and capitalize on market opportunities. </p><p>　　Other questions a

10、sked throughout a product development life cycle include: How can product line organizations deliver the required assets to produce the required features in their products? How can the organization capitalize on new tren

11、ds by re-using existing systems? What are the dependencies amongst product lines and how will they be managed?</p><p>　　Product managers are responsible for the product chain and the ultimate delivery of pro

12、ducts that can give the organization a competitive edge. The challenges are in the balancing and management of multiple dependent features. This includes the organizational design aspects that need considering. </p>

13、;<p>　　With organizations moving from "product" to "market" focus in their early years the following issues are eminent: products are invented and assets are built that are either not adding va

14、lue or are too early to be adopted by a potential market. If a market focus exists, the "final product" will only contain the assets (realization of features) that potential customers are willing to pay for in

15、the window or commercialization i.e. "successfully commercialize". Balancing and alignment ensure that t</p><p>　　This paper presents an approach whereby various product lines can be managed in par

16、allel and is based on Strategic Product Development - A strategic approach to taking software products to market successfully [1], first published at the Software Product Line Conference in Colorado, USA.</p><

17、p>　　Section II discusses the problems and solutions around product feature balancing. </p><p>　　Section III introduces concepts that can assist with the balancing process. </p><p>　　Section I

18、V gives a brief overview of the product development funnel. </p><p>　　Section V discusses the crucial cycles that product delivery goes through. </p><p>　　Section VI introduces the balancing pro

19、cess. </p><p>　　Finally section VII presents some closing comments.</p><p>　　II. Problems and solutions around product line balancing</p><p>　　Complex products consist of various pr

20、oduct lines that make up a product family. Allocating features to product lines become a tedious and lengthy process. The product manager needs to understand the entire product before a successful allocation can take pla

21、ce.</p><p>　　The complexities around how all the features hang together can be too high for any one person to master.</p><p>　　A. Problems in context</p><p>　　Delivery times of prod

22、ucts are affected if feature allocation is not done properly.</p><p>　　Product dependencies are not fully understood unless a proper balancing exercise was performed. Product quality and delivery times we af

23、fected if dependencies cause rework to be performed.</p><p>　　Re-use rates are affected if the product lines are not architected properly. The architecture will be referenced throughout the balancing process

24、.</p><p>　　Software asset stability is affected if features are moved around during the development process.</p><p>　　Hold-ups occur when technology glitches cannot be solved.</p><p&g

25、t;　　B. Product balancing excellence</p><p>　　Product line balancing is directly related to the planning process. Projects cannot be initiated unless all the features are allocated properly. Executives, produ

26、ct managers, architects and other strategists work together in ensuring that balancing takes place.</p><p>　　Strategic features must be known before the balancing process starts. These are typically allocate

27、d over a two-year period and aligned to the business goals. Queuing theory can be applied to push the most features through the development process [2]. The strategic features must be well defined and managed independent

28、ly of the product line at product family level. As resources become tied up features can be allocated to other product lines and/or developers. A “round-robbin” approach can be used </p><p>　　C. Management i

29、nfluence on the balancing process</p><p>　　Organizational structures must be designed in such a way that executives stay in close contact with the product development life cycle all the way up to pilot devel

30、opment [3]. </p><p>　　Management should become involved early in the process of feature allocation. Clear direction needs to be provided to ensure that all aspects of the final product is understood. The imp

31、ortance of the product architect’s ability is underestimated.</p><p>　　III. Concepts to assist with balancing strategy</p><p>　　Strategists are striving to have enough information in order to ma

32、ke decisions. This is pointless unless the organization is able to respond to strategies in a predictable way.</p><p>　　A. Building a capable organization</p><p>　　The ISO/IEC TR 15504 [4] stand

33、ard has a capability dimension that assesses the ability of processes to perform. Mature organizations use this as a method of benchmarking their capabilities against others in a certain industry. Each level has a brief

34、reference to the individual and team abilities needed to perform.</p><p>　　B. Building a “stage 4” business</p><p>　　The strategic role of teams in the business plays an important role in produc

35、t development. Teams need to be balanced so that each product area can be a source of competitive advantage. Teams require the environment and direction to perform at their optimum. The risk is that teams can be pushed t

36、o perform at a level before they are ready. An evolutionary approach is required where people and teams are educated and prepared over time to operate at level 5 (ISO/IEC 15504).</p><p>　　Weelwright and Clar

37、k [3] define four stages of evolution that a team goes through before achieving a strategic role:</p><p>　　Stage 1: Minimise Negative Potential - Be Internally Neutral</p><p>　　Stage 2: Match Co

38、mpetitors - Be Externally Neutral</p><p>　　Stage 3: Back the Strategy - Be Internally Supportive</p><p>　　Stage 4: Pursue a Distinctive, Sustainable Advantage – Be Externally Supportive</p>

39、;<p>　　C. Business unit design</p><p>　　Ideally business units that look after product development and professional services need to be integrated at the same level of abstraction. Organizational stra

40、tegy must be translated into mission statements for each of the units. These must in turn be translated into action plans.</p><p>　　The product development business unit, functioning at stage 4, can determin

41、e its own strategy, product family definition and product line vision statements. Teams in this unit will be internally supported as the strategy is translated into tangible work definition projects. Teams inside this un

42、it also have ownership of the content of the product lines and related software assets.</p><p>　　Integration of strategies is needed with regards to balancing features of products. Services units provide fee

43、dback at all levels in the organization to ensure effective communication. Planning normally stretches across boundaries for example; if a team in the services unit is involved with testing and usability feedback of soft

44、ware products produced by the products unit, both teams need to plan the integration and resourcing requirements.</p><p>　　IV. The product development funnel</p><p>　　Product conceptualisation a

45、nd product family planning begins with strategic planning at Board level. </p><p>　　Product features are targeted based on a number of dimensions:</p><p>　　?? Targeted customers: What need does

46、 the product satisfy? How does the customer buy this type of products? Which features will most likely attract blue chip customers?</p><p>　　?? Suppliers: What are the influencing factors that will inhibit

47、or enable product feature delivery? Are components used from re-usable product lines?</p><p>　　?? Competitors: Are the product features positioned in such a way that there are clear differentiators? Feature

48、s might be included when competitors’ innovations are easily reproducible.</p><p>　　?? Opportunities: Are there specific features that can be easily integrated to create opportunity?</p><p>　　T

49、he product development funnel is aimed at the micro environment. There are number of facets in the environment that must be considered to set direction and implement the funnel effectively [5].</p><p>　　The

50、funnel is used to take relevant inputs required to deliver products to market continuously.</p><p>　　Concepts are assessed throughout the funnel to obtain a clear understanding of the commercial realities ar

51、ound taking the final product to market.</p><p>　　Feature filters are used to determine the inputs into the eventual product. Attributes such as time-to-market timing, complexity, and resource requirements n

52、eed to be taken into account.</p><p>　　A. Product types and feature allocation</p><p>　　Features built at breakthrough product level can be used throughout a products life cycle. These features

53、must take into account the re-usable software assets that will be produced. Features allocated here must produce a stable platform for future product line developments.</p><p>　　Platform product features are

54、 those that commercialise the breakthroughs. This is a very important element of the planning of the product life-cycle, as features must be allocated based on value added to potential customers. Typical features might i

55、nclude aesthetic enhancements, management tools, and usability.</p><p>　　As the product progresses though its life-cycle, customer and other inputs will direct the allocation of features. Derivative product

56、features are those that add value to an existing and already stable product line.</p><p>　　Certain customers might still be interested in a product even when it is at the end of its life-cycle. Support produ

57、ct features are those that can be added easily without major investment, and still yield a financial return.</p><p>　　B. Product features and project management</p><p>　　Project management is us

58、ed to deliver a certain set of deliverables within the product development funnel. Each project will be responsible for delivering a set of features.</p><p>　　Project practices need to be implemented to ensu

59、re a successful implementation [6].</p><p>　　The macro product development plan shows all the product lines, product features and interdependencies amongst features. Product categories are kept together and

60、innovations in the area of platform products are balanced.</p><p>　　C. Architecting the product line </p><p>　　Breakthrough products normally present significantly new and reworked architectural

61、 designs. It means that there are untested and unexplored areas that represent many risks, as the products that use the architecture mature.</p><p>　　Product line planning will include all the features that

62、will complete a version of the product. Predictability in the innovation process will assist in defining future product lines. Maturity has an influence over the planning process.</p><p>　　Software assets ar

63、e used to build products and products are used to build software assets. If the product lines are architected properly whereby all re-usable components are allocated to a software register, delivery rates will decrease a

64、nd software quality will increase. Software component libraries enhance the overall delivery speed of product versions.</p><p>　　Product lines must be appraised on an on-going basis to ensure the highest pos

65、sible level of re-usability. There are three questions that need to be asked before a feature is built: Are there current software assets that can be used to deliver the functionality? If there is a software asset, but t

66、he functionality is slightly different, should it be enhanced? Only ad this time will a new software component be designed to be included as a software asset. Products lines need to be well defined and </p><p&

67、gt;　　The funnel produces macro feature definitions that are used for the long term planning process. Architectures might be updated and changed depending on the specific types of features that need to be delivered to mar

68、ket. Risk management becomes vital when architectures are affected as it can destabilize the environment.</p><p>　　The architecture must be stabilized early on in the product life cycle. Costly rework is min

69、imized if there is a complete and stable architecture for a product family or product line to build on.</p><p>　　Architectural versioning is used to differentiate the underlying concepts to build product lin

70、es. Each version of the architecture will have its own set of breakthrough products. It is possible for product lines to live across two architectural versions, whereby the product line will produce platform products.<

71、;/p><p>　　V. Product delivery cycles</p><p>　　The product development funnel filters all the product concepts up to the point where development must start. This requires a clear definition of featu

72、res that need to be developed over a certain time frame. Time-to-market, as defined by product strategists, is used to prioritise the product development cycle.</p><p>　　A product line is made up of a number

73、 of code lines. Code lines are for specific technologies and implement features for a specific release of a product.</p><p>　　Architectures are realized over a number of code and product lines. The architect

74、ure may even change over the life cycle of a product although it is not likely. A product is built once the architecture is defined to form the basis of future releases. </p><p>　　Products are built over man

75、y releases. Each release adds functionality and becomes incrementally bigger and more complete. It does not mean that only one code line is used. Many technologies can make up one release of a product, and usage is based

76、 on relevant strengths and weaknesses.</p><p>　　Components that are constructed during the various code lines for a product line are used as software assets [8]. These assets include COTS (commercial off the

77、 shelf) software components and are all part of the final product family. Inter-product line dependencies are managed by having these well-defined components under configuration management early on in the funnel.</p&g

78、t;<p>　　Feature tracking becomes vital as all marketing information and customer/feature availability is used by the sales and marketing work force.</p><p>　　Feature lists form the basis whereby produ

79、ct managers manage product lines throughout product delivery and beyond.</p><p>　　Specialists working on features in a release need to understand the importance of customer acceptance and feedback. The produ

80、ct portfolio has features spread in order to drive the commercial processes from a central location [7].</p><p>　　Technical and management products are needed to establish baseline product versions. The base

81、line will deliver crucial features that will be used by the balancing process. These features are also used during the product's market readiness tests. Entire product lines might be held back from release if certain

82、 crucial features are not fully implemented. Baselines can be internally (technical reasons) or externally (marketing and business) defined.</p><p>　　It is vitally important that the team understands the imp

83、lications of bringing a product version to a close. Forward and backward planning techniques are used to set the actual “work time”. For example, two days are needed to get the team ready and another three days to prepar

84、e the release. Backward planning also forces the team to plan all the “certain-death” milestones. These are the indicators of when certain features have to be completed for the product line and product family to be succe

85、ssf</p><p>　　Management products are only used to assist in delivering the products the client sees (technical products are delivered to the client). Features form a critical part of the management process.

86、Each feature is allocated to a software requirement, architectural element, test procedure and an individual software engineer.</p><p>　　The cycles of improvement diagram describes the cycles of improvement

87、that a product line goes through. The measurement and metrics database is used when features are planned for in the management products. This new planning knowledge is essential in planning for feature size, effort requi

88、red to deliver features, and anticipated defects that will be generated after the baseline. Feature planning knowledge is acquired throughout the many deliveries that make up a product line. Decisions can be ma</p>

89、<p>　　Improvements in the product line are achieved one cycle at a time. After each delivery a thorough analysis is performed to make sure that the measurements are correct and that the metrics are updated.</p&

90、gt;<p>　　Knowledge is distributed amongst product lines. Once updates of the measurement and metrics database have been completed, other product lines need to be informed (horizontal integration). This knowledge i

91、s needed to benchmark product lines against each other. Before the next version of a software asset is built, the updates need to be included in the planning process. Strategic feedback (vertical integration) is also nee

92、ded to ensure that the technology strategy stays in tact.</p><p>　　VI. The balancing process</p><p>　　When balancing product families, product lines and projects, organizations should build thei

93、r own scoring models. Factors that are most important at a point in the product life cycle need to be considered.</p><p>　　Organizational level direction setting is needed to drive the balancing process. Pro

94、duct families operate within the constraints of the organizational business plan that defines the research direction and competitive market. Other areas that are covered include:</p><p>　　?? Organizational

95、resource planning.</p><p>　　?? Strategic features that need to be included in product families in order to compete successfully.</p><p>　　?? Time-to-market deadlines are normally the result of

96、 a strategic planning exercise.</p><p>　　If the process described below is implemented half way through development be sure that changes are not detrimental to products that need to come to a close. There mu

97、st not be a search for commercial viability during the product development process [15]. Product lines must be closed even if limited features are delivered: take one or any one of the product lines to the end quickly. P

98、remature termination of projects delivering a version, stifle the learning ability of the team that needs to deliv</p><p>　　Have well defined product lines</p><p>　　Allocate all the features to

99、a product line</p><p>　　Architect the product lines properly</p><p>　　Define product development regions</p><p>　　Perform feature analysis top-down</p><p>　　Balance fea

100、tures round one</p><p>　　Analyse software assets</p><p>　　Understand influences</p><p>　　Balance features round two</p><p>　　Restart the process</p><p>　　V