《软件产品线》PPT课件.ppt

《《软件产品线》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件产品线》PPT课件.ppt（76页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第七章 软件产品线本章内容o7.1 软件产品线的起源o7.2 软件产品线定义o7.3 软件产品线的基本活动o7.4 软件产品线需求分析n7.4.1 软件产品线需求建模n7.4.2 软件产品线需求分析的特点n7.4.3 利用扩展的UML描述产品线需求n7.4.4 软件产品线需求分析中潜藏的风险本章内容o7.5 软件产品线开发评价o7.6 软件产品线的建立o7.7 软件产品线开发模型n7.7.1 软件产品线的双生命周期模型n7.7.2 软件产品线的N生命周期模型o7.8 软件产品线的组织结构o7.9 软件产品线测试本章内容o7.10 软件产品线的优点o7.11 软件产品线开发所面临的问题7.1 软

2、件产品线的起源o软件开发可以象制造业一样，在产品线上采用标准的软件构件来进行组装生产o软件产品线的起源可以追溯到1976年Parnas对程序族的研究o软件产品线是软件复用的一种重要方法，是一种预先规划的和系统化的软件复用技术o软件产品线的基本思想是：大部分的软件需求并不是全新的，而是已有系统需求的变体7.1 软件产品线的起源n大部分组织都只关注某一具体应用领域，他们不断地重复开发该领域已有的软件变体n这些变体之间通常存在着大量的相似性，而这又为系统化和大规模软件复用奠定了基础o在软件开发过程中，不能采用统计数据进行定量化的度量，而只能通过文字描述和图表显示来进行定性化的度量o定性化度量要求：在

3、分析和评判过程中，需要对有意义和可观察的模式或主题进行对比和解释7.1 软件产品线的起源o在借鉴制造业产品线创建软件产品线时，需要注意以下几个问题：n与生产一个具体的产品相比，软件开发过程是难以预测的，其可变的因素太多n软件不能像具体产品一样进行大规模的生产n不是所有的软件错误都会引发系统失败n软件产品不会磨损n软件系统不受自然界规律的限制o在软件产品线工程中，主要讨论如何确定领域范围和软件资源7.1 软件产品线的起源o在建立软件产品线和识别领域潜在资源时，需要考虑不同的实现技术、各种领域信息、相关的经济收益和由此所引发的风险o软件产品线是最高级别的软件复用技术o软件产品线是一组具有共同体系构

4、架和可复用构件的应用系统，构建了一个支持特定领域产品开发的软件平台o在软件产品线中，根据产品线架构对用户需求进行定制，通过继承可复用成分和应用中的独特部分来创建应用系统7.1 软件产品线的起源o软件产品线已经发展为一个新兴的、多学科交叉的研究领域o它涉及软件工程、管理技术和商业规划等多个方面，几乎涵盖了软件工程的所有方向o目前，软件产品线方法已成为学术界研究的一个热点问题，在软件开发行业中得到了初步的应用o应用软件产品线方法，能够大幅度地减少开发成本，缩短开发周期，同时提高软件产品的质量7.2 软件产品线定义o软件产品线(Software Product Line，SPL)是指一组可管理的，具

5、有公共特性的软件应用系统的集合o在利用软件产品线方法构建一个应用系统时，主要的工作是组装和繁衍，而不是创造，其重要的活动是集成而不是编程o核心资源是软件产品线的实现基础，通常包括：7.2 软件产品线定义n产品线体系结构、可复用软件构件、领域模型、需求陈述、文档技术资料、规格说明书、性能模型、进度表、预算、测试计划、测试用例、工作计划和过程描述等n其中产品线体系结构是核心资源中的最关键部分o关于软件产品线的定义主要包括以下几种：nParnas提出了程序家族的概念，认为“软件产品线是具有广泛公共属性的一组程序7.2 软件产品线定义nWeiss和Lai认为“从项目之间的公共方面出发，预期考虑可变性等

6、因素所设计的程序族就是软件产品线”nLee认为“软件产品线工程是一种新兴的软件工程范型，指导软件开发组织利用核心资源完成软件项目开发任务，而不是从零开始”nBosch认为“软件产品线由一个产品线体系结构，一组可复用构件和由共享的核心资源派生的产品集合构成”7.2 软件产品线定义nKruege认为“软件产品线是一种工程技术，利用通用的产品构建方法和一组共享的软件资源来开发功能相似的应用系统”nPohl给出的定义是“软件产品线工程是使用公用平台、大规模定制技术来开发功能密集型系统和软件产品的范型”nMargaret Davis认为“软件产品线是，在组成和功能方面具有共性(Commonalities

7、)和个性(Variabilities)的多个相似系统所形成的一个系统族”7.2 软件产品线定义nBass、Clements和Kazman认为“软件产品线是在一个公共的软件资源集合基础上建立起来的，共享同一个特性集合的应用系统集”n卡耐基梅隆大学的软件工程研究所给出了软件产品线的经典定义，软件产品线是一个应用系统的集合，这些产品共享一个公共的、可管理的特征集，这个特征集能够满足选定的市场或任务领域的特定需求o软件产品线的主要组成部分包括核心资源和软件项目集合7.2 软件产品线定义n核心资源是领域工程所获得的成果的集合，是软件产品线中应用系统构造的前提基础，也有组织将核心资源称为集成开发平台n核心

8、资源包含了软件产品线中所有系统共享的产品线体系结构，以及新设计开发的或者通过对现有系统再工程得到的、需要在整个产品线中进行系统化重用的构件n此外，与产品线体系结构相关的实时性能模型、体系结构评估结果、与软件构件相关的测试计划、测试实例、设计文档、需求说明书、领域模型、领域范围定义都属于核心资源7.2 软件产品线定义o产品线的定义强调了以下几点：n预先定义的生产方式n共享的软件核心资源n以核心资源为基础的软件开发o软件产品线的成功则恰恰是因为在实践过程中，将技术、过程、组织和业务等进行了综合考虑o在软件产品线中，管理层必须指导、跟踪和强制核心资源的使用7.3 软件产品线的基本活动o软件产品线包括

9、核心资源开发、利用核心资源的项目开发以及在这两部分中所需要的技术协调和组织管理7.3 软件产品线的基本活动o核心资源开发被称之为领域工程，利用核心资源的软件项目开发也被称为应用工程o软件产品线总是针对某一特定领域而创建的，在创建之后，又要为该领域的应用开发服务o在核心资源开发和软件项目开发之间，存在着反馈循环n核心资源促进了应用系统的快速创建，核心资源随着新应用系统的开发而不断地被更新7.3 软件产品线的基本活动o通过跟踪核心资源的使用情况，其结果将被反馈到核心资源的开发活动中，以创建更多有利于复用的基础设施o核心资源开发和软件项目开发都需要人力、物力和财力的投入，因此需要持久的、强有力的和卓

10、有远见的组织管理o管理必须促进企业文化的交流，将新项目的开发放到可用资源环境下进行考虑7.3 软件产品线的基本活动o核心资源开发、软件项目开发和技术协调、组织管理三大活动不断迭代循环，促进产品线的基础设施不断完善o迭代是软件产品线活动所固有的特性，循环存在于核心开发中，循环存在于软件项目开发中，同时，循环也存在于两者的技术协调和组织管理中o核心资源开发活动的输出包括：7.3 软件产品线的基本活动n产品线范围：是关于产品线所能包含的产品描述，列举出所有产品的共性和彼此之间存在的个性差异n核心资源：是产品线中应用系统创建的基础设施n开发计划：描述了如何利用产品线中的核心资源去开发软件项目7.3 软

11、件产品线的基本活动7.3 软件产品线的基本活动7.3 软件产品线的基本活动o软件项目开发活动依赖于核心资源开发活动的输出结果，即产品线范围、核心资源和开发计划o软件项目开发活动的输人包括：n项目实际需求，被表示为领域中一些通用产品描述的变化或增量，也可表示为产品线需求集合的一个增量，通过比较应用需求与产品线需求模型来获得7.3 软件产品线的基本活动n产品线范围，指出当前所要开发的软件项目是否可由产品线来实现，指明该项目可由产品线实现的模块，同时，还应该说明应用系统开发依赖于产品线的程度n用于创建该项目的核心资源n开发计划，详细描述了如何利用核心资源来设计实现该软件项目o软件产品线就是一组相关的

12、应用系统，但是它们如何存在却取决于具体的核心资源、开发计划、作用范围和组织环境7.3 软件产品线的基本活动o软件产品线就是一组相关的应用系统，但是它们如何存在却取决于具体的核心资源、开发计划、作用范围和组织环境o技术协调和组织管理对于软件产品线的成功是至关重要的o产品线工程是在核心资源的基础上，遵循用户的实际需求所开展的一种监督和协调工作o软件产品线是一种正在成熟的软件工程范型，用于开发同一领域中具有相似需求的应用系统7.3 软件产品线的基本活动o在一个特定领域中，基础架构是支持一组具有相似应用需求的领域模型和参考架构，这一基础架构经常被称为产品线体系结构(Product Line Archi

13、tecture，PLA)o描述产品线体系结构的最好手段就是框架，框架是一个可复用的和已经部分实现的软件制品，框架能够被扩展实例化，以生成特定的应用系统7.3 软件产品线的基本活动o软件产品线工程与其它复用技术相比，主要存在以下两方面的差异：n软件产品线工程涉及一系列具有相似应用需求的软件产品n软件项目开发是以公共核心资源为基础来进行的7.4 软件产品线需求分析o软件产品线需求建模是产品线开发过程中的关键性活动，其质量将直接决定整个产品线的成败o需求是对系统要做什么、系统如何工作、系统要表现的特性、系统必须具备的质量以及系统开发过程所必须满足的约束条件的一种叙述o在软件产品线需求建模过程中，需要

14、对产品线内所有产品的公共特性和变化特性进行描述7.4 软件产品线需求分析o分析公共特性和变化特性是产品线工程的一个显著特征n公共特性是指隶属于软件产品线的所有成员产品都必须具备的公有功能和共同特征，公共特性集合是创建软件产品线的基础，是建立产品线体系结构的依据n变化特性是指只存在于软件产品线中某些成员产品的独有功能和个性特征，使其区别于产品线内的其它成员产品，约束和限定产品线体系架构的预期变化7.4 软件产品线需求分析o软件产品线需求建模可以划分为面向产品线的需求过程，即领域需求，和面向产品线中某个具体应用的需求过程，即应用需求o领域需求过程确定了产品需求的范围，在产品线范围内建立面向产品线的

15、需求模型，找出产品线中所有产品的公共特性和变化特性，以形成整个产品线的核心需求资源o领域需求是产品线需求的核心，领域需求过程应对领域内的所有产品进行分析，包括已有的应用系统和潜在的应用系统7.4 软件产品线需求分析o领域需求的来源包括已有的系统功能，潜在的用户需求，以及竞争对手的需求o领域需求过程的输出结果是核心需求资源o应用需求过程根据具体产品的定义和要求，参照可复用的核心需求资源来建立系统的需求模型，获得需求规格说明书o领域需求过程的成果促进了应用需求过程的进展，同时，应用需求过程的反馈又有利于领域需求过程的完善7.4 软件产品线需求分析o软件产品线需求定义了产品线中的产品及其相关特性，涵

16、盖了一系列应用系统的共同特性o产品线需求分析对于产品线开发有着重要的指导作用o产品线需求分析确定了产品线需求与特定产品需求之间的差异和变化点，这种差异和变化点为业务用例提供了输入7.4.1 软件产品线需求建模7.4.1 软件产品线需求建模o产品线领域范围定义n产品线领域范围定义是一项重要的活动，确定了产品线的共性特征和变化因素o产品线领域范围定义的参照信息主要包括以下几个部分n用户需求调研，了解用户需求的基本情况n分析竞争对手，了解市场上有哪些类似的产品，存在着什么样的问题，解决这些问题能给自己带来怎样的收益7.4.1 软件产品线需求建模n分析行业发展动向，预测未来的发展趋势，思考新技术的出现

17、可能会带来的机遇和风险n分析企业竞争能力，了解公司已有的类似产品、客户群、公司需求的状况和公司的技术实力o产品线领域需求收集n首先，根据产品线领域范围定义确定目标用户，对目标用户的需求进行整理n然后，分析同类应用系统的功能，对相关技术资料进行加工提取，以获取共性的领域知识7.4.1 软件产品线需求建模o产品线领域需求分析n寻找产品线领域需求描述中的公共特性和变化特性，这往往依赖于领域专家的知识与经验o产品线领域需求层次划分n软件产品线具有一定的层次关系，这种层次性决定了产品线需求也应该具有对应的层次结构o产品线领域需求规格说明n把分属不同维度的原子需求按其服务的系统或构件进行划分，以形成需求规

18、格说明书7.4.1 软件产品线需求建模o应用系统需求收集n应用需求分析人员，参照产品线领域需求规格说明，分析用户的具体要求和系统功能定义，将系统需求分解为一系列的原子需求o应用系统需求规格说明n收集分解得到的原子需求，按照系统构成方式来进行组织，形成应用系统的需求规格说明文档7.4.2 软件产品线需求分析的特点o产品线领域需求包括固定部分和变化成分o需求模型是客户、领域专家和系统分析师之间进行沟通的有效手段o需求抽取是一个发现、评审、文档化、理解用户需求和阐明系统约束的过程o需求分析是一个提炼用户需求和系统约束的过程7.4.2 软件产品线需求分析的特点o需求规格说明是一个清晰地文档化用户需求和

19、严格地阐明系统约束的过程o需求确认是一个保证系统需求完整、正确、一致和清晰的过程7.4.3 利用扩展的UML描述产品线需求oUML用例(Use Case)图已经被广泛地应用于软件开发过程o用例描述了系统中要发生的事件流，包括具体事件和事件的先后次序o在UML中，角色是与系统进行交互的外部对象o角色也可以是类、系统、子系统或另一个用例7.4.3 利用扩展的UML描述产品线需求o在软件产品线中，可以使用UML用例图来建立产品线需求模型，以描述领域需求的公共特性o在描述产品线变化特性时，用例和角色都可能是变化的oUML仅能提供静态描述，缺乏对产品线变化特性的动态支持，因此，必须对其进行扩展，以满足产

20、品线需求建模的要求7.4.3 利用扩展的UML描述产品线需求o为了支持角色的变化特性，在角色中增加了Selected属性o在软件产品线中，仅有部分产品的用例图可以带有Selected属性的角色o具备Selected属性的角色是否出现将取决于产品的使用环境o在UML用例图中，必须扩充两种新类型的用例关系，即可选关系(optional)和互斥关系(alternative)7.4.4 软件产品线需求分析中潜藏的风险o文档的不充分描述或错误描述，不充分的文档说明将会使所设计的产品线体系结构出现二义性，错误的文档描述将使构件开发过程出现错误o需求通用性不足或泛化过度o需求变化点不确定性，需求变化点的不确

21、定性会造成判断过程出现失误，使应用系统开发出错7.5 软件产品线开发评价o产品线评价应该包括：核心资源开发评价、软件项目开发评价和产品线管理评价o核心资源开发评价n在度量核心资源的作用时，管理者应该关注以下两个问题o开发核心资源所需的时间和费用o核心资源的利用率，在开发应用系统时，应该充分地使用核心资源，以避免不必要的重复劳动7.5 软件产品线开发评价n在评价核心资源的利用率时，应该说明：o核心资源将用于产品开发的哪一阶段，重用的粒度如何o在应用开发过程中，核心资源暴露出多少缺陷o查询、调整和集成核心资源的工作量o在利用核心资源的过程中，指出最耗时的工作o软件项目开发评价n在软件产品线上，搜集

22、相关应用工程活动的信息：所开发系统的质量、客户满意度，以及开发所消耗的时间和费用等7.5 软件产品线开发评价o产品线管理评价n管理工作也需要评价，以衡量技术协调和组织管理是否到位o产品线整体管理评价n项目开发总成本：描述了使用产品线开发软件项目的成本n产品线生产效率：用于度量产品线开发的效率n过程依从性：在软件产品线中，项目开发需要遵照预订的方式来进行，否则就不能产生实际的效果7.5 软件产品线开发评价o核心资源开发管理评价n核心资源利用率：描述核心资源为项目开发所提供的价值n核心资源使用成本：为了有效地将基础设施应用到项目开发过程中，需要计算核心资源重用的成本o软件项目开发管理评价n项目直接

23、开发成本：与传统的开发成本相类似，主要包括使用产品线开发应用系统的直接劳动，即分析、设计、实现和测试的支出，此外，还应该包括对核心资源做适度的裁剪、扩充、实例化以及集成到产品中的成本7.5 软件产品线开发评价n核心资源复用率：管理者应该定期地统计被重用的核心资源和资源重用的情况，可以通过产品线配置管理系统来获得这些信息7.6 软件产品线的建立o产品进化为产品线n参照现有应用问题的解决方案，通过分析、比较、裁剪、扩充和泛化系统框架，来设计软件产品线的体系结构n在产品线体系结构的基础上，逐步地将特定应用系统中的构件转化为产品线的构件o软件产品线替代现有产品集n基本停止现有的项目开发活动，将所有力量

24、都投入到软件产品线的建设工作中7.6 软件产品线的建立n这种方法的目标是：建立一个全新的开发平台，不受现有产品集所存在问题的制约和限制o全新软件产品线的进化n当进入新领域并要进行一系列应用系统的开发工作时，采用进化方法来创建产品线o全新的软件产品线开发n体系结构分析人员、设计人员和领域专家进行多次反复的交流，获得产品线的所有可能需求n分析产品线需求描述，来设计产品线的体系结构框架，开发产品线的核心资源和基础设施7.6 软件产品线的建立n在产品线核心资源全部创建完成之后，才开始第一个软件项目的开发工作7.7 软件产品线开发模型o软件产品线开发的核心思想是：采用特定领域体系结构和构件重用技术来解决

25、一类具有相似需求的领域应用问题o软件产品线是特定领域体系结构设计和基于体系结构开发的有机结合体，其目标是提高软件生产的自动化程度o对开发阶段实施不同的划分，可以形成不同的软件产品线模型7.7.1 软件产品线的双生命周期模型7.7.1 软件产品线的双生命周期模型o整个模型由两个重叠的软件生命周期复合而成，即领域工程生命周期和应用工程生命周期o在领域工程和应用工程中，又分别有各自的分析过程、设计过程和实现过程o产品线领域工程的主要任务是：针对特定领域应用需求，创建可共享的公共软件体系结构、构件和开发模型n产品线领域工程主要包括领域分析、领域设计和领域实现3个阶段7.7.1 软件产品线的双生命周期模

26、型o应用工程是在领域工程的基础上开发软件项目的过程n在软件产品线中，应用工程包括应用需求分析、应用系统设计和应用系统实现3个阶段o在领域工程和应用工程的相应阶段之间，存在着纵向连接线，其含义是：产品线领域工程指导应用工程的实施o应用工程的结果可以反馈给领域工程，促进核心资源的建设，因此，整个软件产品线是一个互相迭代和相互完善的过程7.7.1 软件产品线的双生命周期模型o领域工程是一个在较高抽象层次上，从领域遗留系统中抽取公共的、可重用的核心资源，创建软件产品线以支持应用开发的过程o应用工程使用领域工程所创建的产品线体系结构和构件资源来开发应用系统，此外，还要根据应用的特殊需求来定制新构件o若新

27、定制的构件具有领域可重用特性时，则需要进行泛化处理，将其加入到产品线核心资源中7.7.1 软件产品线的双生命周期模型o青鸟软件生产线将开发组织划分为三个不同的车间n应用架构生产车间、软件构件生产车间以及基于构件-架构复用的应用集成组装车间o青鸟软件生产线的活动主要包括：领域工程、应用工程、标准规范的制定以及质量保证等o在青鸟软件生产线中，将开发人员分成三类，构件和架构生产者、构件和架构管理者以及构件和架构复用者7.7.1 软件产品线的双生命周期模型7.7.2 软件产品线的N生命周期模型o从纵、横两个方向上看，N生命周期模型定义了软件工业体系所包容的产品线组成结构，描述了开发和演化的全过程o从纵

28、向上来看，N生命周期模型包括产品线工程、企业工程、领域工程和应用工程等N个层次，描述了以产品线为生产模式的软件工业体系及其总体架构o从横向上来看，每层都描述了各自工程的开发过程和生命周期7.7.2 软件产品线的N生命周期模型7.7.2 软件产品线的N生命周期模型o第一层是产品线工程，主要包括：产品线分析与计划、产品线确认与分类、产品线标准与规范和产品线发布o第二层是企业工程，描述了使用产品线来开发应用系统的软件企业的内部组织结构、生产过程控制和发展模式o第三层是领域工程，包括产品线确认、领域分析、体系结构设计和体系结构实现o第四层是应用工程，包括市场分析、应用需求分析、应用系统设计和应用系统实

29、现7.7.2 软件产品线的N生命周期模型o在软件产品线N生命周期模型中，不同层次之间使用了双向箭头，表示在不同抽象层次上，可以实现相互迭代的开发、控制和演化o要想创建一条成功的软件产品线，需要注意以下几个问题：n必须具备丰富的领域经验n积累软件开发的有效的基础设施和基础资源n必须设计合理的产品线体系结构n必须建立一套完善的产品线管理机制7.8 软件产品线的组织结构o开发组织应该包括两部分，即核心资源组和软件项目组o对产品线和开发背景的认识不同，将会产生不同的组织结构o根据是否有独立的核心资源组，可以将产品线组织结构划分为两种n一种是设立独立小组负责核心资源的开发工作n另一种是不设立独立的核心资

30、源组7.8 软件产品线的组织结构7.8 软件产品线的组织结构o产品线管理者协调体系结构组、配置管理组、核心资源组和软件项目组来共同完成一系列具有相似需求的应用开发任务n体系结构组负责监控核心资源组和软件项目组，以保证核心资源建设和应用系统开发能够遵循预先定义的架构，同时，要完成构架的演化工作n配置管理组要负责基础资源的更新，维护软件项目的版本n体系结构组、核心资源组和软件项目组之间是互相独立的7.8 软件产品线的组织结构oSEI将软件产品线组织划分为4个部分：n市场分析人员：是产品线、应用系统和客户需求之间的沟通桥梁n核心资源组：负责软件产品线体系结构和构件资源的开发工作n软件项目组：负责完成

31、应用系统的开发工作n产品线管理者：负责开发过程的协调和计划o设有独立核心资源组的结构适用于50100人的大型软件开发企业7.8 软件产品线的组织结构n这种结构可以使小组成员将精力都集中在核心资源的设计和开发工作上，得到更加通用的产品线基础设施o另一种典型的组织结构是不设立独立的核心资源组n核心资源的开发任务由各个软件项目组来完成，只是设立专人来监管核心资源的开发工作7.9 软件产品线测试o同软件测试一样，产品线测试覆盖了产品线工程的整个生命周期o产品线测试的关键在于重用测试用例，而不是测试产品线中的每一个应用系统o在测试软件产品线时，测试的主要对象是产品线的核心资源，包括构件测试和架构测试n构

32、件测试为产品线测试提供了技术支持，同时，也为架构测试提供了可集成的软件单元7.9 软件产品线测试n在测试构件时，验证构件的可变点就成为测试工作的重点n架构测试的任务是检验产品线体系结构设计的合理性o需求分析人员、系统设计人员、体系结构设计师和相关技术实现人员通过阅读产品线体系结构说明书，经过反复的讨论来寻找设计方案中的缺陷，并对其进行修改和完善7.9 软件产品线测试o软件产品线的开发活动和测试活动应该是彼此重合的，架构测试结果可以作为反馈，启动新一轮的产品线开发活动，以完善产品线体系结构7.10 软件产品线的优点o降低开发费用o缩短上市时间o灵活的人员配备o更高的可预测性o更高的质量o减低维护

33、成本o减少系统设计复杂度o便于估计开发成本7.11 软件产品线开发所面临的问题o产品线既要满足领域共性需求，又要设计满足特定产品变化的软件体系结构，同时还要支持产品线体系结构和核心资源的演化o产品线的前期投资比较大，投资回报的周期比较长，而且失败的风险也比较大o难以制定遗留系统向软件产品线迁移的有效策略o软件产品线理论还缺少策略化的重用模型和支持系统化重用的发展策略7.11 软件产品线开发所面临的问题o领域范围和技术基础的变更将会导致软件产品线的更新，甚至是完全抛弃已有的产品线，进一步增加了产品线开发的风险o软件产品线涉及到一个软件企业的多个项目，选择了软件产品线就意味着开发过程要承担由此所带来的诸多风险，在收益和风险之间，难以进行权衡o核心资源设计的通用性要求可能会导致其质量下降，适用范围缩小7.11 软件产品线开发所面临的问题o目前，企业的软件产品线实践经验严重不足o可能需要对软件开发企业的组织结构和方针政策进行相应的调整本章讲授内容已结束谢谢