新版软件体系结构(SoftwareArchitecture)培训课件

软件体系结构

(SoftwareArchitecture)讲义八：软件产品线——实践与模式软件体系结构

(SoftwareArchitecture)内容软件产品线简介软件产品线的基本活动典型的产品线实践域产品线实践模式案例研究小结内容软件产品线简介软件产品线简介背景(Background)概念(Concept)产品线的好处和代价(BenefitsandCostsofaProductLine)相关术语解释(NoteonTerminology)软件产品线简介背景(Background)背景(1/2)一个产品线(ProductLine)是共享一组公共的、可管理的特性，并且满足特定市场需求的产品集合产品线方法必将成为新世纪中占主导地位的软件生产模式，产品的灵活性是市场的必然需求，而产品线将通过裁剪，生产出满足特定用户或用户群需要的产品从开发者的角度，产品线的成功在于产品之间通过共性的共享，达到了生产上经济的目的产品线方法在制造业中并不新鲜！但在软件开发中，CMUSEI提出的“软件产品线”还是比较新的概念，并被迄今为止的实践证明是可行的，可以有效地提高生产率、缩短产品上市时间、提高质量和客户满意度背景(1/2)一个产品线(ProductLine)是共享一背景(2/2)从构成软件成分的抽象粒度和面向应用的角度来看，软件开发的手段是不断提高的

1960s，子程序(subroutines) 1970s，模块(modules) 1980s，对象(objects) 1990s，构件(components) Now，系统(Systems)产品线方法可以看作是软件复用发展的一个更高阶段背景(2/2)从构成软件成分的抽象粒度和面向应用的角度来看，概念一个软件产品线是满足下列性质的一组软件系统：共享一组相同的、可管理的特性集合满足一类特定的市场需求以预先规定的方式基于公共核心资产集合开发在一个软件产品线中，新产品形成通过以下步骤：从公共资产库中选取合适的构件使用预定义的变化性机制进行裁剪，如参数化、继承必要时增加新的构件在整个产品线范围内共同的体系结构指导下，进行构件组装，形成系统新产品(系统)的开发从“创造”变为“组装(生成)”其中，占支配地位的活动是“集成”而非“编程”概念一个软件产品线是满足下列性质的一组软件系统：使用产品线的好处和代价(1/7)使用产品线带来的好处和付出的代价都是与产品线中产品之间的复用相关的好处1：产品线体系结构提供了在产品线中进行系统开发的结构，构件间的关系和约束。一旦定义好了产品线体系结构，意味着产品线中所有产品的系统设计已基本完成代价1：产品线体系结构必须支持产品线内部固有的变化性，所以除了定义构件本身和构件之间的约束（必需的，可选的，可替换的），还要定义在产品线中开发系统时构件使用和演化的原则，增加了产品线体系结构定义的复杂性好处2：设计决策、数据结构、算法、文档、编码和调试信息等都属于可复用资产，它们在产品线的所有产品中可被反复使用代价2：因为可复用资产要适应不同产品之间的差异，所以要求可复用资产有足够通用的特性，同时要保证性能不被降低，增加了资产设计和实现的复杂性使用产品线的好处和代价(1/7)使用产品线带来的好处和付出的使用产品线的好处和代价(2/7)好处3：为软件开发购买的开发环境、配置管理工具、设备管理工具可以在整个产品线中使用，相当于投资的“分期付款”代价3：要求这些可复用的工具和环境有足够的适应性，适应一个产品线的通用性又可以适应单独产品的变化性，因此对这些工具和环境的要求较高好处4：产品线是面向特定领域中的共性产品，开发人员具有适应整个产品线的经验，可以按照需要随时转换项目，提高生产效率代价4：专业人员的培训需要花很大代价使用产品线的好处和代价(2/7)好处3：为软件开发购买的开发使用产品线的好处和代价(3/7)CEO更高的生产效率更快速的上市持续的成长和市场份额经济地获取特定市场领域的能力COO劳动力的有效使用开拓新市场、新技术和新产品的能力流动的人力资源“池”技术经理增长的可预测性良好建立的角色和责任有效生产使用产品线的好处和代价(3/7)CEO使用产品线的好处和代价(4/7)软件产品开发人员高昂的士气更大的工作满足度集中于产品真正的独特方面方便的软件集成更少的交付延迟组织内部更大的机动性更强的市场化能力有更多学习新技术的时间成为具有良好质量记录和信用记录的产品开发队伍成员使用产品线的好处和代价(4/7)软件产品开发人员使用产品线的好处和代价(5/7)体系结构设计师或核心资产开发人员更大的挑战工作具有更大的影响组织内重要性的提升象产品线一样具有市场销路市场销售人员可预测的高质量产品可预测的交付时间可以销售家族系列产品使用产品线的好处和代价(5/7)体系结构设计师或核心资产开发使用产品线的好处和代价(6/7)客户更高质量的产品可预测的交付时间可预测的费用特定需求的已知费用良好测试的培训材料和文档分享维护费用加入一个用户组的潜在可能终端用户更少的缺陷更好的培训材料和文档建立与其他用户的网络使用产品线的好处和代价(6/7)客户使用产品线的好处和代价(7/7)好处一个人承担150万行Ada源代码的集成和测试工作，该系统是一个实时的、安全要求很高的舰船指挥和控制系统在三年的时间里，生产效率翻了4番(以单位时间内、每个工程师在每个发布的产品中完成的功能数目来衡量)一周完成驱动内燃机运行的软件系统（甚至一个特殊情况在一个周末），而不是以前的一年时间比没有采用资产复用的预计时间提前了12个月，参加军事模拟训练代价把资源用于核心资产库的开发，为此取消了三个大项目重新安排不适应产品线方法的员工在新方法发挥作用之前，推迟产品发布一年时间使用产品线的好处和代价(7/7)好处相关术语解释(1/4)核心资产库（coreassetsbase）核心资产库是产品线的基础，是管理支持产品开发的可复用资源的机制核心资产库中的资产通常包括体系结构、可复用软件构件、框架、领域模型、需求描述、文档和规约、性能模型和度量、日程、预算、测试计划、测试用例、工作计划、过程描述、通讯协议描述、用户界面描述、应用生成器、设计准则和设计决策，……其中，体系结构是最为关键的资产相关术语解释(1/4)核心资产库（coreassetsb相关术语解释(2/4)开发（development）“开发”在这里是一个广义的词，指的是如何获得核心资产（或产品）软件进入一个组织可以通过以下三个渠道之一：自己构建(build)，包括从零开始或从遗产系统中挖掘直接购买(purchase)，通常不做修改委托加工(commission)，同别人签订合同为其特别定制这里的“开发”实际上包括构建、获取、购买、翻新老系统，或以上各种方式的组合相关术语解释(2/4)开发（development）相关术语解释(3/4)产品线(productline)vs.产品族(productfamily)产品线是共享一组公共的、可管理的特性，并且满足特定市场需求的产品集合产品族是一组相关的软件系统，它们是基于公共的核心资产开发出来的尽管产品线以产品族的方式构造是最高效的，但从技术上来讲，产品线可以不是产品族同样，如果产品族的结果产品在市场目标上彼此关系不大，也不一定构成产品线注意：我们关于软件产品线的定义隐含了产品线是作为一个产品族来开发的，并且其中的产品按照规定的方式开发相关术语解释(3/4)产品线(productline)v术语对照

Productline Productfamily Coreassets Platform Productfamily Platform-basedfamily Businessunit Productline相关术语解释(4/4)术语对照相关术语解释(4/4)内容软件产品线简介软件产品线的基本活动典型的产品线实践域产品线实践模式案例研究小结内容软件产品线简介产品线方法的基本活动核心资产开发(CoreAssetDevelopment)产品开发(ProductDevelopment)管理(Management)产品线方法的基本活动核心资产开发(CoreAssetDe产品线方法的基本活动产品线方法的基本活动领域工程和应用工程领域工程领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程，它覆盖了建立可复用软件构件的所有活动。针对一个领域中的所有系统，而不局限于某个特定的系统。应用工程：应用工程是开发单个特定应用系统的活动。针对一组特定的需求，产生一个特定的解决方案。与应用工程相比，领域工程处于一个较高的抽象级别上。领域工程和应用工程领域工程行为产品领域工程领域分析领域设计领域实现领域模型DSSA领域构件应用工程系统1系统2系统n分析用户需求设计应用系统规约应用系统实现应用系统体系结构应用系统应用工程系统n+1基于领域模型的分析用户需求基于DSSA的设计应用系统规约应用系统实现/集成应用系统体系结构应用系统行为产品领域工程领域领域领域领域DSSA领域系统1系统2系统活动1：核心资产开发活动1：核心资产开发核心资产开发活动的输入(1/5)产品约束产品线中的产品有哪些共性和变化性？它们提供哪些行为特性？根据市场和技术预测将来产品要具有哪些功能？遵循什么标准？满足哪些性能要求？同哪些外部系统交互？满足哪些物理限制？满足哪些质量要求（如可用性、安全性等）？……核心资产必须以最小牺牲产品质量（如安全性、可靠性、可用性等）的代价，换取对产品共性和个性的满足核心资产开发活动的输入(1/5)产品约束核心资产开发活动的输入(2/5)风格、模式和框架符合产品约束和生产约束的相关体系结构是什么？构件交互的协议和模式是什么？有哪些可用的设计模式？有哪些可用的应用框架？……尽管这些是体系结构定义的输入，它们被提高到如此高度的目的在于强调体系结构在软件产品线实践中的重要性核心资产开发活动的输入(2/5)风格、模式和框架核心资产开发活动的输入(3/5)生产约束产品线的产品要遵循哪些商业、军事或公司的规范？产品线的产品所基于的底层基础设施是什么?产品推向市场的时间需求是什么？哪些COTS构件是可用的？哪些遗产构件可被复用？……对这些问题的回答对核心资产的构造，以及核心资产自身具有显著的影响核心资产开发活动的输入(3/5)生产约束核心资产开发活动的输入(4/5)生产策略生产策略是实现核心资产的总体方法。产品线采用自顶向下还是自底向上的开发方法？转移资产生产成本的策略是什么？通用构件是自行开发还是从市场购买？产品是自动生成还是组装？核心资产的生产如何管理？……生产策略刻画了体系结构和相关构件的获得及演化途径核心资产开发活动的输入(4/5)生产策略核心资产开发活动的输入(5/5)已有资产的清单在开发产品线之前有哪些可用的软件资产，譬如：库函数、框架、算法、工具、构件等？有哪些可用的技术管理过程、预算模型、培训资源？……资产清单包括所有事先存在的潜在资产。通过仔细分析，开发组织可以确定什么是最适合利用的核心资产开发活动的输入(5/5)已有资产的清单核心资产开发活动的输出(1/2)产品线空间(Scope)产品线空间描述了构成产品线的产品，不仅仅是产品名称的枚举列表，还包括这些产品的共性和变化性，例如产品提供的操作，性能和其他质量属性，运行的平台等此外，产品线空间会随着市场条件、组织计划、商业目标等的改变而不断演化，产品线空间的演化是产品线演化的起点核心资产库资产库是利用产品线进行产品开发的基础，包括：产品线中所有产品共享的体系结构支持系统复用的软件构件，包括设计和实现构件测试计划，测试用例，集成计划和各种文档核心资产开发活动的输出(1/2)产品线空间(Scope)核心资产开发活动的输出(2/2)生产计划生产计划描述了怎样基于资产库开发产品所有上述核心资产，例如领域模型、需求、体系结构、构件、测试计划等，都有“附带”的过程(process)定义它们如何在产品开发中使用。生产计划基本上是这样一组“附带”的过程，它描述了这些个别的过程如何组合起来构建产品的总体方案生产计划为复用者提供了一个基于产品线开发产品的指南。每个产品的变化性是同预定义的变化点相一致的，例如，从分类的构件中选择一个提供某种特性，增加/删除构件，通过继承或参数化裁剪构件生产计划描述了产品之间必要的变化性，缺乏了生产计划，产品的开发者将不知道核心资产之间的联系，如何有效地和在产品线约束下利用它们基于核心资产、以生产计划为指导、生产出产品线空间的产品核心资产开发活动的输出(2/2)生产计划开发核心资产库(1/4)体系结构是产品线中最重要的核心资产，产品线的体系结构既要满足所有产品线空间中产品的共性，又要满足每个产品的个性规定可能成为核心资产的软件构件解决核心资产库的构件和形成产品的构件之间的通信问题定义一致性规则以保证产品遵循体系结构规范保证体系结构在产品线生命周期中的可行性产品线空间的共性体现在体系结构中，变化性体现在可裁剪/可替换的构件中影响产品线体系结构开发的因素产品线空间相关的风格、模式和应用框架遗产系统的知识开发核心资产库(1/4)体系结构是产品线中最重要的核心资产，开发核心资产库(2/4)体系结构在产品线中的意义体系结构是核心资产库的关键部分，既体现了产品线的共性需求，又通过变化点支持产品空间中的一个产品谱系；体系结构描述了产品线中产品的结构，而且给出了核心资产库中构件的接口规约；体系结构决定要开发哪些构件，决定哪些构件在整个产品线中是通用的而哪些构件在不同实例之间存在变化性；开发一个体系结构需要产品空间、相关风格、模式和框架知识以及已有资产清单。

开发核心资产库(2/4)体系结构在产品线中的意义开发核心资产库(3/4)其他的核心资产包括同可复用软件构件相关的资产，需求规约设计/界面规约代码测试计划/案例/规程性能模型评审表格/规程……最后，需要定义当产品线演化时，核心资产将如何更新。例如更多的可用资源、技术改进、市场转向等影响了产品线空间开发核心资产库(3/4)其他的核心资产包括同可复用软件构件相开发核心资产库(4/4)附加过程（attachedprocesses）开发核心资产库(4/4)附加过程（attachedproc定义产品空间产品线空间确定了产品线中包含的产品，定义了产品的共性和变化性。产品线空间必须被认真定义，过宽：核心资产将无法适应广谱的变化性，生产的经济性将丧失，产品线将退化成“一次一个产品”的老的开发模式过窄：核心资产的通用性将无法适应未来发展的需要，并且规模经济无法实现影响产品线空间的因素市场需求、竞争对手和企业目标产品约束，例如产品可以在哪些平台上运行和产品必须具有的性能相关系统和产品对于市场和技术的预测定义产品空间产品线空间确定了产品线中包含的产品，定义了产品的开发生产计划成功的产品线实践依赖于文档化的、被良好理解的、有效的软件实践和过程，用于开发和演化产品、体系结构和其他核心资产生产计划描述了如何基于资产库开发产品，制定将单个资产的“附加”过程连接起来的全局策略，这些过程包括：产品线的开发方式：自顶向下vs.自底向上体系结构的开发和维护可裁剪/可替换构件在开发产品过程中的使用方式为使用、裁剪和演化核心资产，应用的特定工具度量由于产品线实践（或其它过程改善）为企业带来的效益，并制定为度量采集相关数据的计划生产计划在每次产品开发中被实例化开发生产计划成功的产品线实践依赖于文档化的、被良好理解的、有产品线方法的基本活动产品线方法的基本活动活动2：产品开发活动活动2：产品开发活动产品开发产品开发活动是产品线的目标，核心资产开发只是达到该目的的一种手段。产品开发活动依赖于核心资产开发活动的三个输出：产品线空间核心资产生产计划，再加上特定产品的需求特定产品的需求经常表现为产品线通用需求的一个增量(delta)，或一组产品线需求的增量生产计划要被实例化为特定产品的生产计划产品开发产品开发活动是产品线的目标，核心资产开发只是达到该目产品开发活动中输入/输出关系产品开发活动的输入和输出之间存在一个不断反馈和迭代的过程快速生成产品线中特定成员的能力会影响产品线空间，也许被当初负责定义产品线空间的人所忽视每个新产品可能同其它产品相似，因此需要生成新的核心资产当更多的产品被生产出来时，生产的效率可能意味着需要新的系统生成过程，从而引起生产计划的变更产品线对客户的影响表现为，一个客户可能改变他的需求，以便同产品线空间保持一致，从而达到利用产品线优势，缩短产品上市时间、提高可靠性和降低开发成本的目的产品开发活动中输入/输出关系产品开发活动的输入和输出之间存在软件产品的开发/获取

产品开发的方式产品线中的产品由一个产品组开发；产品线中的产品由分布在整个企业的不同产品组开发；软件产品的开发/获取产品开发的方式产品开发的活动（应用工程）特定系统需求获取特定系统SA的获取可复用构件的选择和组装变化性处理产品开发的活动（应用工程）特定系统需求获取特定系统SA的获取管理管理在成功的产品线实践中起着关键的作用为产品线中的各个活动合理分配资源，起协调监督的作用协调核心资产开发和产品开发迭代过程中的技术活动设置适当的组织机构，以保证组织内的各部门得到足够数量的合适资源（如，良好训练的员工）为保证核心资产演化，确定合适的预算模型，并提供相应的资金组织核心资产库中的资产，以方便查找合适的可复用资产如果产品线外包给其他公司，管理活动负责监督承包人，确保资产和产品符合合同要求，通过资产库达到企业目标管理部门与外部的接口推选一位称职的管理者，称为ProductLineChampion管理管理在成功的产品线实践中起着关键的作用内容软件产品线简介软件产品线的基本活动典型的产品线实践域产品线实践模式案例研究小结内容软件产品线简介典型的产品线实践域基本概念(BasicTerminology)产品线实践域分类(CategoriesofPracticeAreas)重要实践域(ImportantPracticeAreas)典型的产品线实践域基本概念(BasicTerminolo基本概念(1/2)一个实践域是一组活动的集合或工作体(bodyofwork)，组织必须掌握，以便成功地实施产品线的基本工作实践域是对产品线基本活动（如“开发核心资产”）的细化，通过定义一组较小且易于管理的活动，有助于达到目标实践域为组织采用产品线方法提供了起点为了能够执行每个实践域的基本活动，要求掌握相关的实践域。这里的“掌握”意味着，能够重复成功的实践企业的能力成熟度需要达到CMM2级！基本概念(1/2)一个实践域是一组活动的集合或工作体(bo基本概念(2/2)尽管很多实践域在任何成功的软件开发中都是基本要素，但在产品线方法中有其同单个系统工程不同的特性描述实践域的模板描述(Introductoryoverview)产品线的特有之处(Aspectspeculiartoproductlines)应用于资产开发(Howappliedtocoreassetdevelopment)应用于产品开发(Howappliedtoproductdevelopment)具体实践(Specificpractices)实践风险(Practicerisks)参考(References)基本概念(2/2)尽管很多实践域在任何成功的软件开发中都是基初始级(1)

软件配置管理软件质量保证软件子合同管理软件项目跟踪和监督软件项目规划需求管理可重复级(2)定义级(3)

软件质量管理量化的过程管理管理级(4)

过程变化管理技术变化管理错误预防优化级(5)

软件配置管理软件质量保证软件子合同管理软件项目跟踪和监督软件项目规划需求管理

对等复审组间协作软件产品工程集成的软件管理培训计划组织过程定义组织过程关注CMM的关键过程域(KPAs)初始级(1)软件配置管理可重复级(2)定产品线实践域分类产品线的实践域可以粗略地分为三类软件工程实践类：采用合适的技术创建和演化核心资产及产品的实践技术管理实践类：采用工程化方法创建和演化核心资产及产品的管理实践组织管理实践类：协调整个产品线活动的管理实践产品线实践域分类产品线的实践域可以粗略地分为三类软件工程实践类软件工程实践类是那些采用合适的技术创建和演化核心资产及产品的实践：9项体系结构定义(ArchitectureDefinition)体系结构评价(ArchitectureEvaluation)构件开发(ComponentDevelopment)COTS利用(COTSUtilization)挖掘现存资产(MiningExistingAssets)需求工程(RequirementsEngineering)软件系统集成(SoftwareSystemIntegration)测试(Testing)理解相关领域(UnderstandingRelevantDomains)软件工程实践类软件工程实践类是那些采用合适的技术创建和演化核技术管理实践类技术管理实践类是使创建和演化核心资产及产品“工程化”的管理实践：8项配置管理(ConfigurationManagement)数据收集、度量和跟踪(DataCollection,Metrics,andTracking)开发/购买/挖掘/委托的分析(Make/Buy/Mine/CommissionAnalysis)过程定义(ProcessDefinition)产品线范围确定(ProductLineScoping)技术规划(TechnicalPlanning)技术风险管理(TechnicalRiskManagement)工具支持(ToolSupport)技术管理实践类技术管理实践类是使创建和演化核心资产及产品“工组织管理实践类组织管理实践类用于协调整个产品线的活动：12项形成合适的组织结构(AchievingtheRightOrganizationalStructure)构建和交流商业实例(BuildingandCommunicatingaBusinessCase)用户界面管理(CustomerInterfaceManagement)开发和实现获取策略(DevelopingandImplementinganAcquisitionStrategy)投资预算(Funding)启动和制度化产品线(LaunchingandInstitutionalizingaProductLine)市场分析(MarketAnalysis)操作(Operations)组织计划(OrganizationalPlanning)组织风险管理(OrganizationalRiskManagement)技术预测(TechnologyForecasting)培训(Training)组织管理实践类组织管理实践类用于协调整个产品线的活动：12项实践域同基本活动的关系(1/3)实践域同基本活动的关系(1/3)实践域同基本活动的关系(2/3)实践域同基本活动的关系(2/3)实践域同基本活动的关系(3/3)实践域同基本活动的关系(3/3)软件工程实践类软件工程实践类是那些采用合适的技术创建和演化核心资产及产品的实践：9项体系结构定义(ArchitectureDefinition)（P54）体系结构评价(ArchitectureEvaluation)构件开发(ComponentDevelopment)COTS利用(COTSUtilization)挖掘现存资产(MiningExistingAssets)需求工程(RequirementsEngineering)软件系统集成(SoftwareSystemIntegration)测试(Testing)理解相关领域(UnderstandingRelevantDomains)软件工程实践类软件工程实践类是那些采用合适的技术创建和演化核实践域1：体系结构定义该实践域描述了定义产品线体系结构所必须的活动。体系结构将决定一个组织能否高效地从共享的资产库中生产出产品体系结构是任何软件项目成功的关键因素，当然包括产品线。体系结构是从问题空间（用户需求）向解空间（设计）过渡的第一个制品，它决定了结果产品的质量属性，例如性能、可修改性、可移植性项目组织结构和管理模式理解软件系统如何工作的起点实践域1：体系结构定义该实践域描述了定义产品线体系结构所必须体系结构定义体系结构需求产品的质量属性是否同其他系统交互开发组织的业务目标可用的构件资源（制作/购买/挖掘/订做）体系结构方法自顶向下（从需求到设计到实现）在设计应用功能之前，关注系统基础结构方面在研究基础结构之前，关注应用功能体系结构风格体系结构定义体系结构需求体系结构定义构件接口接口包括了构件使用者可以确实做的一组假设静态特征：合约(contract)描述了每个服务的前置条件、后置条件、构件不变式动态特征：状态机、时态逻辑一个完整的合约同时包括了对外提供的服务和对外要求的资源协议(protocol)描述构件之间的交互连接构件(connectingcomponents)应用是通过连接构件进行构造的，以使能通讯和协作过程调用、远程过程调用CORBA、COM+、JavaBeans体系结构定义构件接口产品线的特有之处(1/2)同单个系统的体系结构几乎固定了系统中可能存在的变化性，产品线体系结构明确规定了产品线空间允许的变化性，并提供内在的机制在具体产品中实例化这些变化性相对于单个系统，产品线对体系结构在变化性方面提出了更高的要求。产品线中产品之间的差异可能表现在行为、质量-属性、运行平台、网络、物理配置、中间件、规模等许多方面，例如，一个产品可能要求高度安全，处理速度较慢另一个产品要求速度快，安全性较低体系结构必须具有足够的灵活性同时支持这两个产品产品线的特有之处(1/2)同单个系统的体系结构几乎固定了系统产品线的特有之处(2/2)产品线体系结构对变化性的支持可以采取多种形式：参数化：所有的变化性事先明确，并固化在代码内，在系统构造时对构件、子系统等的形式参数进行赋值继承和代理：面向对象系统提供的子类对父类的属性和行为进行改变的机制构件替换：在保持接口一致的前提下，可以用功能强大的构件替换以前较弱的构件；此外，还包括构件数目的扩充产品线的特有之处(2/2)产品线体系结构对变化性的支持可以采应用于核心资产开发产品线体系结构是核心资产中关键成员，预期在同整个产品线保持相同的生存期，并且保持相对稳定体系结构定义了核心资产库中的软件构件集合，以及相关的支撑资产，如各种文档和测试制品体系结构本身的“附属”过程（或产品开发者指南）也是产品线保持持久的重要核心资产应用于核心资产开发产品线体系结构是核心资产中关键成员，预期在应用于产品开发在构造新产品时，按照“附属”的过程，对产品线体系结构进行实例化，其中最重要的是固定变化性在构造新产品时，如果发现产品线体系结构无法支持的变化性，应考虑对其进行扩充应用于产品开发在构造新产品时，按照“附属”的过程，对产品线体具体实践体系结构定义和基于体系结构的开发体系结构风格和模式产品开发者指南在产品线体系结构实现变化性继承扩充和扩充点参数化配置和模块连接语言(MIL)自动生成，如Yacc，Lex编译时刻的不同实现选择，如#ifdef具体实践体系结构定义和基于体系结构的开发实践风险没有熟练的体系结构设计师管理和文化落后的工具过度参数化过多的固定点实践风险没有熟练的体系结构设计师实践域2：体系结构评价体系结构是软件产品线的基础之一，必须尽早对其评估，降低修改成本该实践可以在不同阶段实施在体系结构还在设计时在初步体系结构设计完成和详细设计开始之间甚至在系统开发完成之后（例如再工程或挖掘）体系结构评价必须同组织的商业目标紧密联系起来，例如如果其中一个商业目标是希望系统有较长的生命周期，可修改性就是一个重要的质量属性质量属性的目标必须具体，例如易修改性这一抽象质量属性在评价具体体系结构时必须说明是针对什么样的变化该体系结构具有（或没有）易修改性实践域2：体系结构评价体系结构是软件产品线的基础之一，必须尽产品线的特有之处产品线的体系结构和每个产品的体系结构都要进行评价，但评价的标准有所不同对产品线体系结构的评价注重其健壮性和通用性对产品体系结构的评价注重其能否满足该产品的行为（behavioral）和质量要求必须考虑到体系结构为产品线服务这一事实产品线体系结构评估必须在限定硬件和其他变量变化范围的基础上确定体系结构所能达到的性能产品线的特有之处产品线的体系结构和每个产品的体系结构都要进行应用于核心资产开发很明显，体系结构评价要应用于作为产品线核心资产一部分的产品线体系结构由于需求、商业目标和体系结构都是不断变化的，因此需要周期性的小型评估来保证体系结构和商业目标的一致体系结构评估也可应用于核心资产的候选构件和内部开发的构件不适用于黑盒复用的体系结构用于评估的质量属性目标包括候选的核心资产是否支持产品线的质量目标是否能够支持产品线中产品的预期发展应用于核心资产开发很明显，体系结构评价要应用于作为产品线核心应用于产品开发体系结构评估应当在体系结构的实例或变化点上进行，这些实例或变化点用来创建产品线上的一个或多个产品对于产品线体系结构来说，产品体系结构评估是否是一个相对独立的过程取决于产品体系结构和产品线体系结构在质量属性影响方式（quality-attribute-affectingways）上的差异大小由于产品体系结构评估是产品线体系结构评估的变种（variation），评估制品当然可以根据所使用的评估方法进行复用把产品线体系结构评估或产品体系结构评估的附属过程建档当提出一个超出原产品线范围的新产品时，要重新评估产品线体系结构。如果不适用于新产品，评估可用于决定如何修改体系结构来适应新产品应用于产品开发体系结构评估应当在体系结构的实例或变化点上进行具体实践ATAM（ArchitectureTrade-offAnalysisMethod）SAAM(SoftwareArchitectureAnalysisMethod)SPE(SoftwarePerformanceEngineering)ARID(ActiveReviewsforIntermediateDesigns)主动设计评审(ActiveDesignReviews)具体实践ATAM（ArchitectureTrade-of实践风险不恰当的人参与评估生命周期中的不恰当时机没有时间进行评估评估的不恰当解释重新评估失败实践风险不恰当的人参与评估实践域3：构件开发软件构件是一个复合单元，具有“契约”规定的接口和明确的环境依赖。软件构件可以被独立发布，并可以被第三方合成构件开发指的是在体系结构上下文中，生产实现特定功能的构件。构件是被封装的，通过接口对外呈现其功能，并同其他构件集成构件接口静态方面：接口经常通过“契约”的方式进行说明，即每个服务的前置、后置条件，以及表达构件内服务交互的不变式动态方面：状态机，时态逻辑等完整的“契约”应包括构件“对外提供的”和“为完成自身功能所需的”构件连接连接机制提供了构件通讯和协调的机制，例如CORBA，COM，IIOP和其它基础设施构件的连接方式限制了构件的可复用性实践域3：构件开发软件构件是一个复合单元，具有“契约”规定的产品线的特有之处产品线的共性体现在体系结构中，变化性体现在可裁剪/可替换的构件中。因此，构件必须具有足够的灵活性以满足体系结构定义的变化点构件开发同产品线相关的方面包括：计划构件开发关键基础设施、体系结构规则或模式、实现技术说明构件UML+OCL提供变化性支持Inheritance,Extension,Uses,Configuration,Parameters,Templateinstantiation,andGeneration产品线的特有之处产品线的共性体现在体系结构中，变化性体现在可应用于核心资产开发构件和相关的制品（接口规范，“附属”的过程，测试支持等）构成了核心资产库的最大部分。相应的，构件开发是产品线核心资产开发最大的部分构件同软件体系结构一起构成了开发产品的概念基础应用于核心资产开发构件和相关的制品（接口规范，“附属”的过程应用于产品开发构件是填充产品体系结构“骨架”的构造块。特定产品的体系结构是通过绑定产品线体系结构的变化点实现的，变化的绑定是为了达到特定的产品属性，例如实时效率、容错等，这就有助于确定使用哪些构件，以及如何对这些构件的变化性进行实例化一个产品中的构件可以通过下述途径获得：直接来自核心资产库固定内在的变化性经过修改和裁剪：adapter设计模式，继承，Wrapper重新开发核心资产库中构件的“附属”过程描述了如何选择和绑定变化性应用于产品开发构件是填充产品体系结构“骨架”的构造块。特定产具体实践特定的构件模型产品线体系结构应包括一个基本构件模型，用作实现的基础CORBA(CommonObjectRequestBrokerArchitecture)DCOM(DistributedCommonObjectModel)JavaBeans具体实践特定的构件模型实践风险DecompositionflawsLackofconformancetospecifiedinterfaceInadequatespecificationsWronglevelofspecificityExcessiveinter-componentdependencies实践风险Decompositionflaws实践域4：COTS利用COTS产品独立存在于特定的系统，由商业组织为商业目的而开发，COTS产品一般通过购买或许可证的方式获得。在政府环境中，又称为NDI(non-developmentalitems)产品在过去的10年中，中间件技术和标准的爆炸性增长使其在大型系统开发中普遍采用COTS产品的利用有以下特点：降低成本利用公共体系结构促进大规模复用失去对构件适应体系结构和构件演化的控制实践域4：COTS利用COTS产品独立存在于特定的系统，由商COTS产品的利用步骤COTS产品的利用一般需要以下的步骤：仔细分析体系结构，COTS构件和体系结构存在互动关系理解组织需求，某些组织有特定的技术约束或标准仔细研究市场，特别注意不断发展的新技术、新标准和新构件以灵活的方式处理用户需求，在需求和COTS之间需要折衷开发评价产品和技术的方法，包括评价步骤和评价策略选择可行的产品和技术购买产品把COTS产品集成到体系结构中测试产品配置，即集成测试以发展的观点管理和演化系统COTS产品的利用步骤COTS产品的利用一般需要以下的步骤：产品线的特有之处同其它产品线构件一样，COTS构件必须具有足够的灵活性以适应产品线变化性的需要采用COTS构件时，必须考虑到产品维护和升级的周期同COTS构件周期的不一致COTS构件需要的新活动包括：鉴定潜在适用的COTS构件采用包装器、中间件等对构件进行裁剪组装经过裁剪后的构件当新版本发布时，考虑对COTS构件进行升级产品线的特有之处同其它产品线构件一样，COTS构件必须具有足应用于核心资产开发COTS产品是核心资产的可行选择，现有的商业构件，包括数据库、GUI、WWW浏览器、基于Java的产品和其它基于DCOM或CORBA的中间件代表了资产基础设施的重要部分选择COTS构件作为核心资产，需要考虑以下因素：COTS构件的相对稳定性接口、相关协议和标准COTS构件可能会对产品线需求和体系结构产生反作用应用于核心资产开发COTS产品是核心资产的可行选择，现有的商应用于产品开发当一个产品的特有部分恰好可以由COTS构件完成时，没有理由不考虑采用COTS构件这时需要考虑上述提到的各种活动，即鉴定潜在适用的COTS构件采用包装器、中间件等对构件进行裁剪组装经过裁剪后的构件当新版本发布时，考虑对COTS构件进行升级应用于产品开发当一个产品的特有部分恰好可以由COTS构件完成具体实践基于COTS的系统实践COTS使用风险评估(CotsUsageRiskEvaluation)具体实践基于COTS的系统实践实践风险COTS构件之间交互的未知性对COTS产品的修改COTS构件的替换缺乏严格的配置管理缺乏适应性缺乏COTS产品的支持实践风险COTS构件之间交互的未知性实践域5：挖掘现有资产挖掘现有资产是指对旧系统的一部分进行挖掘和改善，然后应用于原本并不支持的新系统中。不仅包含对代码的重用，还包括对业务模型、规则库（rulebases）、需求规格说明等要正确计算对遗留资产复用所需的成本由于资产挖掘时资源密集型的活动，所以小粒度的复用几乎不可能产生任何经济效益实践域5：挖掘现有资产挖掘现有资产是指对旧系统的一部分进行挖产品线的特有之处为产品线挖掘的资产必须同新开发的核心资产有相同的质量挖掘的资产必须被打包，同时要考虑到复用，必须满足产品线的需求、必须与产品线体系结构保持一致、必须满足产品线的质量目标挖掘的资产必须满足产品线中大多数产品的需求为软件产品线挖掘资产要考虑到如下几个方面在共性和变化点这两个方面，与现有产品的一致性对未来潜在产品的适应性使资产接口遵循产品线体系结构约束所需要的工作量从体系结构未来的演化发展对资产提出的潜在需求，考虑它的可扩展性资产的维护历史产品线的特有之处为产品线挖掘的资产必须同新开发的核心资产有相应用于核心资产开发挖掘现有资产的过程主要是在为产品线寻找合适的候选对象具有良好结构和文档，并且经过长时间使用的资产，可以直接或稍作修改就放入核心资产库通过包装能够满足新的交互性需求的资产，也是需要的反之，是我们不需要的。如果包含进来，就需要长期高额的维护费用候选构件资产必须与产品线体系结构一致，必须满足对该构件的行为需求，必须适应每一个变化点应用于核心资产开发挖掘现有资产的过程主要是在为产品线寻找合适应用于产品开发可以用于产品开发，但与非产品线情况下没有任何区别对所挖掘的构件值得花较多时间考虑它是真的专用于某个产品，还是可广泛应用于产品线中其它产品，从而能更准确的确定修复（rehabilitation）成本应用于产品开发可以用于产品开发，但与非产品线情况下没有任何区具体实践再工程的选择分析（OptionsAnalysis）建立挖掘上下文建立遗产构件库分析候选构件分析挖掘选项选择挖掘选项具体实践再工程的选择分析（OptionsAnalysis）实践风险(1/2)与挖掘相关的主要风险无法找到适用的资产选择了错误的资产与挖掘活动相关的风险不成功的搜索过于成功的搜索标准模糊（Fuzzycriteria）没有搜索出非软件资产不合适的资产糟糕的修复（rehabilitation）评估实践风险(1/2)与挖掘相关的主要风险实践风险(2/2)导致挖掘风险的组织因素存储空间不足（Lackofcorporatememory）采用的方法不当缺少工具支持Turfconflict无法获得开发所需的资源实践风险(2/2)导致挖掘风险的组织因素实践域6：需求工程(1/2)需求是对系统要做什么、系统如何工作、要表现出的性质、系统必须具备的质量以及系统及其开发必须满足的约束等内容的表述，包括：需求获取（requirementselicitation）需求分析需求验证需求管理涉及到的角色需求者（IEEE中定义的用户）开发者（设计和实现系统的人）作者（编写需求文档的人）实践域6：需求工程(1/2)需求是对系统要做什么、系统如何工需求工程(2/2)角色之间的沟通对不同相关人员提出的需求之间潜在的矛盾进行决策需求的易变性导致需要一种管理变更的机制，即需求变更管理过程。这个过程的基础是需求和系统产品之间的可跟踪性（traceabilitylinks）以及需求和相关决策、折中之间的可跟踪性需求者开发者作者沟通需求工程(2/2)角色之间的沟通需求者开发者作者沟通产品线的特有之处产品线需求定义了产品线中的产品及其特性涵盖整个产品线的共有需求是极其重要的核心资产，必须与只针对产品某个子集（或者单个产品）的需求分开描述。只针对产品某个子集（或者单个产品）的需求同样也需要维护和管理整个产品线的公共需求由很多变化点组成，这些变化点同样也可以用来创建产品特有需求产品线范围与产品线需求的关系针对产品线的需求工程和针对具体产品的需求工程的区别需求抽取需求分析需求规格说明需求验证（verification）需求管理产品线的特有之处产品线需求定义了产品线中的产品及其特性应用于核心资产的开发由需求工程生产的需求制品本身就是非常重要的核心资产。另外，产品线需求还有助于其他核心资产的开发和获取。需求制品将有助于：确定一条产品线的可行性，精化其范围和业务用例（businesscase）为产品线体系结构奠定基础确保其他核心资产支持预期的变化确定产品线和产品的进度和预算创建产品线中产品的测试用例以及其他测试制品产品线需求工程还有一个显著特点是存在一个快速的早期设计，用来捕获影响初始设计的高层需求应用于核心资产的开发由需求工程生产的需求制品本身就是非常重要应用于产品开发

需求工程在以下几个方面起重要作用确定将某个产品作为产品线的一部分进行开发的可行性特定产品的开发、测试和部署由产品开发而导致的产品线演化应用于产品开发需求工程在以下几个方面起重要作用具体实践领域分析技术相关人员视图(stakeholder-view)建模特征建模Use-case建模Change-case建模需求与相关工作产品的可跟踪性具体实践领域分析技术实践风险主要风险在于在产品线的整个生命周期中不能正确地捕获需求。文档中包含错误的或不适当的需求，没有及时更新需求或者根本没有对需求建档错误的需求可能由以下原因造成：没有正确区分产品线范围的需求和产品特有的需求通用性不足通用性过度变化点不正确只考虑到行为而没考虑到质量实践风险主要风险在于在产品线的整个生命周期中不能正确地捕获需实践域7：软件系统集成软件系统集成是指将独立的软件构件组合成一个集成的整体集成受到构件接口定义的限制接口：构件生产者对其他构件所能做的一系列安全的假设实践域7：软件系统集成软件系统集成是指将独立的软件构件组合成产品线的特有之处软件的系统集成出现在将核心资产安装到核心资产库和构建单个产品的过程中集成所需要做的工作量在产品线的软件系统集成中，集成成本被分摊到众多产品中去“持续集成”（continuouslyintegration）几乎为0每个产品都完全由核心资产组成，不存在针对特定产品的代码非常大需要相当多的编码工作把需要的核心构件集成为一个内聚的整体0considerable大多数产品线位于中间某一点产品线的特有之处软件的系统集成出现在将核心资产安装到核心资产应用于核心资产开发采购和挖掘核心资产的过程中，一定要考虑到集成的因素。尽量不要单纯使用自然语言，还要使用一种机器可检查的形式来描述要评估所挖掘和采购的构件的可集成性和粒度应用于核心资产开发采购和挖掘核心资产的过程中，一定要考虑到集应用于产品开发产品线的一个好处在于，对产品线中的每个后续产品，软件的系统集成成本呈下降趋势任何情况下，必须根据与定义的、经过测试的计划来进行集成应用于产品开发产品线的一个好处在于，对产品线中的每个后续产品具体实践接口语言封装中间件系统生成FAST生成器具体实践接口语言实践风险自然语言描述的接口文档构件粒度不够大对变化的支持太大太复杂实践风险自然语言描述的接口文档实践域8：测试(1/2)测试的两个基本目的在开发过程中，测试用于帮助开发人员识别导致失败的错误，进而对其修复。测试用于确定一个产品是否满足其需求。测试包括以下三个基本活动分析构造执行和评价测试要遵循以下几个原则测试是客观的测试是系统化的测试是完整（thorough）的测试是开发过程中不可或缺的一部分实践域8：测试(1/2)测试的两个基本目的测试(2/2)下面几点是我们讨论测试的基础分析和设计模型确认（validation）单元测试子系统集成测试系统集成测试回归测试适应性测试验收（acceptance）测试部署测试可靠性模型（reliabilitymodels）测试(2/2)下面几点是我们讨论测试的基础产品线的特有之处在产品线组织中的测试对象必须包括核心软件资产、具体软件产品，以及它们之间的交互与单个系统开发不同，测试的职责分布在组织的不同部分。另一个不同点是测试是一个可以在很多产品中复用的活动指导方针为复用构造测试软件的结构产品线体系结构提供对测试的支持为了系统集成测试复用资产采用回归测试保持对验收（acceptance）测试的跟踪产品线的特有之处在产品线组织中的测试对象必须包括核心软件资产应用于核心资产开发(1/2)以两种方式应用于核心资产开发测试本身就是可复用的核心资产，包括：文档测试数据集测试软件测试其他核心资产测试非软件的核心资产测试软件核心资产应用于核心资产开发(1/2)以两种方式应用于核心资产开发应用于核心资产开发(2/2)界面规格说明结构测试套件规格说明的实现结构测试套件多种实现导致多种测试套件（suite）应用于核心资产开发(2/2)界面规格说明结构测试套件规格说明应用于产品开发以两种基本方式应用于产品开发验证（verification）确认（validation）应用于产品开发以两种基本方式应用于产品开发具体实践对分析和模型评审（review）而言，指导性审查包括审查检查表和测试。审查过程由测试用例引导具体实践对分析和模型评审（review）而言，指导性审查包括实践风险主要风险是测试不充分，以及没有采用能带来高回报的方式。包括：不充分的单元测试工具支持的不足导致的不充分的单元测试不充分的规格说明不充分的集成测试不充分的测试基础设施实践风险主要风险是测试不充分，以及没有采用能带来高回报的方式实践域9：理解相关领域必要性应履行以下职责标识出对建造当前（或未来）产品有用的专业领域标识出领域内重复出现的问题及已知的解决方案使用便于相关人员交流的方式获取和表达这些信息，在整个过程中使用和重用这些信息对相关领域的一个正式分析的范围依赖于组织的领域经验的深度能够用于分析的资源数量当组织成功应用如下几点时，表明它已充分理解了产品相关领域能够推理出一个要进行的设计所蕴含的技术和业务要求决定所要生产的产品应具有什么样的特性、能力以及需要的技术生产一组使用了相关领域知识的制品实践域9：理解相关领域必要性产品线的特有之处理解相关领域是理解产品线范围内所定义产品的共性和变化性的第一步不同于单个产品，产品线开发强调获取和描述覆盖多领域的多个系统的共性和变化性。产品线的领域模型将明确识别领域中的共性和变化性，而单个系统的领域模型可能不会这样领域模型尤其有助于判别：哪些功能（capability）会成为领域中各系统的共性以及有哪些变化点哪些功能的子集会被打包并作为产品线的资产领域中的系统要受到哪些约束（如标准、法律约束、业务限制、特定硬件平台）哪些资产构成典型的领域成员是否继续产品线的开发产品线的特有之处理解相关领域是理解产品线范围内所定义产品的共应用于核心资产开发为产品线生命周期中早期整个产品线中可实现大力度软件复用的机会进行标识和建模还支持产品线的业务用例（businesscase），以及“确定范围（scoping）”和“需求工程”实践域应用于核心资产开发为产品线生命周期中早期整个产品线中可实现大应用于产品开发消费者兑现产品或现有产品新功能（capability）的需求导致业务决策。这些决策可以也应该受到领域理解的支持。最简单的情况是所要求的功能已作为核心资产开发的一部分完成了建模和分析否则，就要根据该需求对产品线的影响作出决策新产品或新功能是作为特定消费者的一次性解决方案来开发吗？考虑到将来复用的可能性，是否把所要求的新功能加入到产品线中。对相关领域的理解有助于对这些问题的判定应用于产品开发消费者兑现产品或现有产品新功能（capabil具体实践主要的实践是找到相关领域中的资深人员。提取和表达相关领域信息的实践具体体现在以下分析过程中：范围、共性和变化性分析领域分析和设计过程面向特征的领域分析复用驱动的软件过程方法的合成过程（synthesisprocessofthereuse-drivensoftwareprocessapproach）组织领域建模的领域分析过程具体实践主要的实践是找到相关领域中的资深人员。提取和表达相关实践风险分析瘫痪（analysisparalysis）缺少必须的领域专家文档和相关领域信息的共享不充分缺乏对分析过程的理解缺乏适当的工具支持领域分析过程和领域产品缺少管理委员会实践风险分析瘫痪（analysisparalysis）技术管理实践域技术管理实践是指那些对核心资产和产品的创建及其演化进行设计和工程化所必须的管理实践技术管理中的实践域包括8项：配置管理数据收集、度量（metrics）和跟踪开发/购买/挖掘/委托分析过程定义确定范围技术规划（TechnicalPlanning）技术风险管理工具支持技术管理实践域技术管理实践是指那些对核心资产和产品的创建及其实践域1：配置管理(1/2)配置管理是对制品的变化进行评估、调整、审批以及实现的一种规范，这些制品用来构造和维护软件系统软件配置管理的目的是在项目的软件生命周期中建立和维护软件项目中产品的完整性软件配置管理包括识别软件项目中的配置项、控制这些配置项及其变更，并且记录和报告这些配置项的状态及其变更活动实践域1：配置管理(1/2)配置管理是对制品的变化进行评估、配置管理(2/2)成功的配置管理需要一组良好定义的、规范化的规则和标准，这些规则和标准应该清楚地定义以下内容：配置管理拥有管理权限的一组制品制品如何命名制品如何进入和离开受控集合在配置管理中，制品允许以何种方式改变在配置管理中，如何获得一个制品的不同版本以及在什么条件下可以使用各个版本的制品如何使用配置管理工具来实现和执行配置管理配置管理(2/2)成功的配置管理需要一组良好定义的、规范化的产品线的特有之处(1/3)产品线中的配置管理通常被看作是一类系统中配置管理问题的多维版本核心资产构成了一个需要进行管理的配置产品线中的每个产品构成了一个必须进行管理的配置对于以上所有配置的管理，都必须在一个过程中进行协调产品线的特有之处(1/3)产品线中的配置管理通常被看作是一类产品线的特有之处(2/3)产品线的配置管理比一个单独系统的配置管理复杂的多，具体表现在：在单个系统的配置管理中，系统地每一个版本拥有与之相关的一个配置，用于定义该产品生产中相关配置相的版本。在产品线的配置管理中，必须有一个配置来维护每一个产品的每一个版本在单个系统的配置管理中，每一个产品以及它的所有版本都可以单独进行管理。在产品线配置管理中不可能采用这种方式，因为核心资产将被应用于所有产品产品线配置管理必须控制核心资产库的配置，并且控制所有开发人员对它们的使用情况只有功能强大的配置管理工具才可以应用于产品线配置管理产品线的特有之处(2/3)产品线的配置管理比一个单独系统的配产品线的特有之处(3/3)具体来说，产品线配置管理的工具、过程和环境必须支持以下内容：并行开发分布式工程（Distributedengineering）构造（build）和发布（release）管理变更管理配置和工作区（workspace）管理过程管理仓库（repository）管理产品线的特有之处(3/3)具体来说，产品线配置管理的工具、过应用于核心资产开发整个核心资产库处于配置管理的控制之下需要具有的特性：支持对资产概念的灵活定义配置管理工具能够报告制品的两个不同版本的差别应用于核心资产开发整个核心资产库处于配置管理的控制之下应用于产品开发配置管理过程应该使得新产品的初始配置变得更加容易配置管理工具必须能够跟踪所使用的配置项的所有版本应用于产品开发配置管理过程应该使得新产品的初始配置变得更加容具体实践配置管理计划的IEEE/ANSI标准关于配置管理的CMMI步骤具体实践配置管理计划的IEEE/ANSI标准实践风险过程不够健壮配置管理开始的太晚多条产品演化路径没有强制执行配置管理实践支持工具不够健壮实践风险过程不够健壮实践域2：数据收集、度量和跟踪度量的目的是为了指导管理决策，两个阶段：初始阶段指出将要跟踪的目标定义度量标准（metrics），这些单位将用于跟踪所要实现目标的进展情况识别为了获得度量结果而必须收集的数据给予可以预见的风险，刻画可能产生（discover）预期结果和问题详细说明如何收集数据、何时收集数据以及谁负责收集数据执行阶段收集指定的数据分析所收集的数据，并将其转换成度量结果，然后把它们与初始阶段描述的预期目标进行比较确定为消除所发现问题要实施的活动确认这些活动能否正确解决这些问题实践域2：数据收集、度量和跟踪度量的目的是为了指导管理决策，产品线的特有之处产品线与单个系统采用了相同的技术，但在产品线中，数据收集需要提供三方面的信息来支持以下各个活动：核心资产开发，包括开发可复用资产以及支持使用它们的基础设施产品开发，包括为客户开发的各个产品对整个产品线的管理，包括制定整个产品线组织的战略计划和发展方向产品线的特有之处产品线与单个系统采用了相同的技术，但在产品线应用于核心资产开发核心资产管理者关心两件事情：核心资产开发的效率核心资产用于相关产品开发时的效果为了达到高效（efficiency）的目标，管理者应当将重点放在跟踪开发核心资产所需要的时间和费用上为了达到有效（effectiveness）的目标，管理者应该将重点放在提供能够尽量避免产品开发重复劳动的资产上应用于核心资产开发核心资产管理者关心两件事情：应用于产品开发产品开发的度量活动包括两方面：传统的和专用于产品线的传统的度量包括对产品开发管理所必须的度量结果的收集和分析用于产品线的度量包括收集产品线需要的数据，以及核心资产管理者为提高效率需要的度量数据，而这些数据只能在产品开发时获得应用于产品开发产品开发的度量活动包括两方面：传统的和专用于产具体实践选择度量标准数据收集复用度量标准具体实践选择度量标准实践风险度量失配（Metricmismatch）目标没有度量标准（Goalswithoutmetrics）测量没有校准（Measurementnotaligned）高成本度量（Costlymetrics）实践风险度量失配（Metricmismatch）实践域3：开发/购买/挖掘/委托的分析该实践域的目的是：强调有意识的、合理的选择软件来源的重要性给出一些有助于选择的分析方法实践域3：开发/购买/挖掘/委托的分析该实践域的目的是：产品线的特有之处产品线的分析方法与单个系统的分析方法类似，但侧重点不同：由于成本较高而被单个系统排出的选项对于产品线可能是可以接受的，因为成本可以分摊到大量产品上“开发”、“挖掘”和“委托”往往更加昂贵，因为这些资产需要更健壮，以便能在整条生产线中复用“购买”不会比单个系统昂贵，因为COTS构件是以通用为目的之一开发的产品线总是倾向于建立在遗留资产的基础上；公司开发很多相似产品的行为通常是产品线方法应用的原动力产品线的特有之处产品线的分析方法与单个系统的分析方法类似，但应用于核心资产开发因为所有的核心资产都必须从某处获得，所以自行开发/购买/挖掘/委托分析是整个核心资产开发的基础。影响分析的因素包括：质量成本（包括机会成本）与产品线需求的一致性与产品线体系结构的一致性支持产品线中产品所要求的变化的灵活性可维护性进度组织成功实施四个选项的能力应用于核心资产开发因为所有的核心资产都必须从某处获得，所以自应用于产品开发产品线中的某些产品可能需要资产库中没有的其他软件构件，应该使用相同的决策分析过程来决定如何获得这些构件应用于产品开发产品线中的某些产品可能需要资产库中没有的其他软具体实践对于宽度优先策略，要考虑的初始问题:有哪些时间上的约束？这些时间约束的外部因素是什么？外部条件的可靠性如何？必须获得的资产的定义如何？产品线需求是否已经定义？产品线中所有产品需求的共性和变化性是否已经定义？软件将要适应的系统体系结构是否已经完整定义？是否存在一个独立于产品线市场的资产市场？（如果没有，就不能像COTS那样在开放市场上获得资产）完成上面基本分析之后，可能会选择其中两三个甚至一个。在对每一种选项进行更详细的分析时，要包括以下内容：“自行开发”选项的问题示例“购买”选项的问题示例“挖掘”选项的问题示例“委托”选项的问题示例具体实践对于宽度优先策略，要考虑的初始问题:实践风险不要将这个实践域的风险与每种选项中的风险混为一谈。这里的风险是指在各种选项中进行选择时可能产生的风险对这个实践域来说，最主要的风险是选择了错误的选项实践风险不要将这个实践域的风险与每种选项中的风险混为一谈。这实践域4：过程定义过程定义实践域是关于一个组织对过程定义和建档的能力“软件过程模型”用来描述已定义软件的开发过程模型的构造一个正式的模型应该满足以下目标：便于理解和交流支持过程管理支持过程改进实践域4：过程定义过程定义实践域是关于一个组织对过程定义和建产品线的特有之处需要更多的合作由于有数量庞大的产品和小组合作，所以每个人只有以事先约定好的方式进行工作，整个组织才会运转起来产品线要求各个独立的组织实体之间可以进行可重复的、持续的、规范的交互，要做到这一点，就必须严格遵循一个过程产品线的特有之处需要更多的合作应用于核心资产开发每一个核心资产都拥有一个与之相关的附属过程来解释如何使用该核心资产构建产品线中的产品。通过过程定义，可以详细的描述这些过程还有一些过程揭示了资产在产品线生命周期中是如何创建、评估、维护和演化的应用于核心资产开发每一个核心资产都拥有一个与之相关的附属过程应用于产品开发附属过程不仅和资产开发有关，也和产品开发相关和核心资产一样，产品也有其改进和维护的规则，这些规则通常在实施“操作（Operation）”实践时创建的过程定义中应用于产品开发附属过程不仅和资产开发有关，也和产品开发相关具体实践为过程使用者提供过程电子文档集成化过程支持环境使计算机系统可以自动执行一些必须的过程步骤一个通用的过程定义避免了定义一个必须考虑到所有可能变化的完整产品线过程的需要具体实践为过程使用者提供过程电子文档实践风险过程失配过程不能满足产品线的需要过程支持不足过程质量差别太大缺乏支持（Lackofbuy-in）强制遵循某过程（Dictatorialintroduction）实践风险过程失配实践域5：确定范围确定范围是指界定一个系统（或一个系统集合）的活动，这一活动具体包括定义哪些行为和方面包含在系统“之中”，那些排出在系统“之外”在产品线中，确定范围是一项基础活动，它将决定产品线长期生存能力实践域5：确定范围确定范围是指界定一个系统（或一个系统集合）产品线的特有之处确定范围的结果是产生一个范围定义文档，这个文档本身会成为产品线核心资产的一部分范围的定义开始时掺尝试比较宽松、通用的文档，随着知识的增多逐渐被细化为表格范围定义的目标就是在产品线“之中”和“之外”划一条边界，这条边界对产品线友好处识别共性和变化性是覆盖整个产品线所有实践域的主题，是产品线概念的精髓，也是范围定义的精髓范围确定活动不仅出现在从零开始构建的产品线中，还可能出现在其他各种情况中产品线的特有之处确定范围的结果是产生一个范围定义文档，这个文应用于核心资产开发范围定义是一种核心资产，它将广泛的被参考，并随着产品线的成长和发展不断更新范围定义应通知需求工程过程，以确保与需求相关的核心资产与范围定义的一致性应用于核心资产开发范围定义是一种核心资产，它将广泛的被参考，应用于产品开发产品开发中用范围定义来评估一个产品是否可纳入产品线应用于产品开发产品开发中用范围定义来评估一个产品是否可纳入产具体实践检查现有产品通过研讨会来理解产品线的目标和产品绘制环境（context）图创建属性/产品矩阵创建产品线场景PuLSE-ECO具体实践检查现有产品实践风险范围太大或太小范围中包括了错误的产品重要的相关人员没有参与实践风险范围太大或太小实践域6：技术规划(1/2)技术规划是各层次管理的基本功能之一，它为其他管理工作，尤其是跟踪和控制奠定了基础。技术规划过程应该包括：确定计划及其内容确定计划的承诺（commitment）