​​ 点击报名后领取>>>软考16本电子版教材 & 36本辅导教材 + 27套历年真题试卷 + 21套精编知识点6G资料包​​

1.4软件工程

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。IEEE对软件工程的定义是:将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

软件工程由方法、工具和过程三个部分组成。软件工程方法是完成软件工程项目的技术手段，它支持整个软件生命周期期;软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成;软件工程中的过程贯穿于软件开发的各个环节，管理人员在软件工程过程中要对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估估算、质量保证和配置管理等。

1.4.1需求分析

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据IEEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

1.需求的层次

简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

(1)业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作莫定了基础。

(2)用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景(scenarios)进行整理，从而建立用户需求。

(3)系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能(服务)，使用户的业务目标得以满足:非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性(例如，可维护性、可重用性、性能等)和其他非功能需求。设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明，例如

必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

2.质量功能部暑

质量功能部署(Quality Function Deployment，QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为分别是常规需求、期望需求和意外需求。

(1)常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。

(2)期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

(3)意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以(出于成本或项目周期的考虑)选择不实现任何意外需求。

3.需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

4.需求分析

在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计的基础的。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作需求分析将提炼、分析和审查已经获取到的需求，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题坡的研究与理解，为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。

使用SA方法进行需求分析，其建立的模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中，一般使用实体联系图(E-R图)表示数据模型，用数据流图(Data Flow Diagram，DFD)表示功能模型，用状态转换图(State Transform Diagran，STD)表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系:DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能:STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。

OOA的基本任务是运用O0方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。OOA模型包括用例模型和分析模型，用例是种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模;分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

5.软件需求规格说明书

软件需求规格说明书(Software RequirementSpecification，SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少

在国家标准GBT8567-2006中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括以下内容。

(1)范围。本部分包括SRS适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号;简述SRS适用的系统和软件的用途，描述系统和软件的一般特性;概述系统开发、运行和维护的历史:标识项目的投资方、需方、用户承建方和支持机构:标识当前和计划的运行现场:列出其他有关的文档:概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求;说明编写SRS所依据的基线。

(2)引用文件。列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。

(3)需求。这一部分是SRS的主体部分，详细描述软件需求，可以分为以下项目:所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求(包括硬件需求、硬件资源利用需求、软件需求和通信需求)、软件质量因素、设计和实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先次序和关键程度。

(4)合格性规定。这一部分定义一组合格性的方法，对于第(3)部分中的每个需求，指定所使用的方法，以确保需求得到满足。合格性方法包括演示、测试、分析、宙查和特殊的合格性方法(例如，专用工具、技术、过程、设施和验收限制等)。

(5)需求可追踪性。这一部分包括从SRS中每个软件配置项的需求到其涉及的系统(或子系统)需求的双向可追踪性。

(6)尚未解决的问题。如果有必要，可以在这一部分说明软件需求中的尚未解决的遗留问题。

(7)注解。包含有助于理解SRS的一般信息，例如，背景信息、词汇表、原理等这一部分应包含为理解SRS需要的术语和定义，所有缩略语和它们在SRS中的含义的字母序列表。

(8)附录，提供那些为便于维护SRS而单独编排的信息(例如，图表、分类数据等)。

为便于处理，附录可以单独装订成册，按字母顺序编排。

另外，国家标准《计算机软件需求说明编制指南》(GBT9385-1988)也给出了个详细的SRS写作大纳，由于该标准年代久远，一些情况已经与现实不符，本书不再介绍。

6.需求验证

资深软件工程师都知道，当以SRS为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在在问题，这时修补需求错误就需要做大量的工作。相对而言在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资盒因此，有必要对于SRS的正确性性进行验证，以确保需求符合良好特特征。需求验证也称为需求确认，其活动是为了确定以下几个方面的内容。

(1)SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。

(2)SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。

(3)需求是完整的和高质量的。

(4)需求的表示在所有地方都是一致的。

(5)需求为继续进行系统设计、实现和测试提供了足够的基础。

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅阅读SRS，通常很难想象在特定环境下的系统行为。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

7.UML

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持O0A和OOD，还支持从需求分析开始的软件开发的全过程从总体上来看，UML的结构包括构造块、规规则和公共机制三个部分。

构造块。UML有三种基本的构造块，分别是事物(thing)、关系(relationship和图(diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合

规则。规则是构造块如何放在一起的规定，包括为构造块命名:给一个名字以特定含义的语境，即范围;怎样使用或看见名字，即可见性:事物如何正确、一致地相互联系，即完整性:运行或模拟动态模型的含义是什么，即执行。

公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制四种。

1)UML中的事物

UML中的事物也称为建模元素，包括结构事物物(structural things)、行为事物(behavioral things，也称动作事物)、分组事物(grouping things)和注释事物(annotational things，也称注解事物)。这些事物是UML模型中最基本的OO构造块。

(1)结构事物:结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。

UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点。

(2)行为事物:行为事物是UML模型中的动态部分，代表时间和空间上的动作UML有两种主要的行为事物。第一种是交互(内部活动)，交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接);第二种是状态机，状态机由一系列对象的状态组成。

(3)分组事物:分组事物是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段段，而构件可以存在于系统运行阶段

4)注释事物:注释事物是UML模型的解释部分。

2)UML中的关系

UML用关系把事物结合在一起，主要有下列四四种关系

(1)依赖(dependency):依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

(2)关联(association):关联描述一组对象之间连接的结构关系。

(3)泛化(generalization):泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。

(4)实现( realization):实现是类之间的语义关系，其中的一个类指定了由另类保证执行的契约。

3)UML2.0中的图

UML2.0包括14种图，分别列举如下:

(1)类图(class diagram):类图描述一组类、接口、协作和它们之间的关系。在O0系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。

(2)对象图(object diagram):对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

(3)构件图(component diagram):构件图描述一个封装的类和它的接口、端口以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。

(4)组合结构图(composite structurediagram):组合结构图描述结构化类(例如构件或类)的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。

(5)用例图(use case diagram):用例图描述一组用例、参与者及它们之间的关系用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。

(6)顺序图(sequence diagram，也称序列图):顺序图是一种交互图(interaction diagram)，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

(7)通信图( communication diagram):通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构(关系)。在UML1.X版本中，通信图称为协作图(collaborationdiagram)。

(8)定时图(timing diagram，也称计时图):定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

(9)状态图(state diagran):状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。

(10)活动图(activity diagram):活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。

(11)部署图(deployment diagram):部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部。

(12)制品图(artifact diagram):制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。

(13)包图( package diagram):包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系

14)交互概览图( interactionoverview diagram):交互概览图是活动图和顺序图的混合物。

4)UML视图

UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图：

(1)逻辑辑视图:逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

(2)进程视图:进程视图是可执行线程和进程作为活动类的建模，它是逻辑辑视图的次执行实例，描述了并发与同步结构。

(3)实现视图:实现视图对组成基于系统的物理代码的文件和构件进行建模。

(4)部署视图:部署视图把构件部署到一组物理节点上，表示软件到到硬件的映射和分布结构。

(5)用例视图:用例视图是最基本的的需求分析模型。

另外，UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素，以及不保证模型的完整性，但模型逐步地要达到完整和一致。

8.面向对象分析

OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA的任务是“做什么”，OOD的任务是“怎么做”面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。

1)用例模型

SA(结构化分析)方法采用功能分解的方式来描述系统功能，在这种表达方式中统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。采用SA方法来描述系统需求，很容易混淆需求和设计的界限，这样的描述实际上已经包含了部分的设计在内。因此，系统分析师常感到迷感，不知道系统需求应该详细到何种程度。一个极端的做法就是将需求详细到概要设计，因为这样的需求描述既包含了外部需求也包含了内部设计。SA方法的另一个缺点是分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能项如何相互关联来实现一个完整的系统服务的。

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。用例方法是一种需求合成技术，先获取需求，记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

1)识别参与者:参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。参与者一定在系统之外，不是系统的部分，可以通过下列问题来帮助系统分析师发现系统的参与者:谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些(其他的)系统使用这个系统？谁从这个系统获取信息?谁为这个系统提供信息？是否有事情自动在预计的时间发生？

(2)合并需求获得用例:将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例，首先，要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗满:其次，进行合并操作。在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作。合并后，将产生用例，将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架。

(3)细化用例描述:用例建模的主要工作是书写用例规约(use casespecificatio而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流(基本事件流和扩展事件流)和后置条件等，其他的还可以包括非功能需求和用例优先级等。

(4)调整用例模型:在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。

包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。

扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。

泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

2)分析模型

前文从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束还要对需求进行深入分析，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

为了使模型独立于具体的开发语言，系统分析师需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起点就是领域模型。领域模型又称为概念模型或简称为域模型，也就是找到那些代表事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。每一个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也可以产生一个或多个顺序图。所有这些图的集合就构成了系统的分析模型。

建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，其中有学者将前三个步骤统称为CRC(Class-Responsibility- Collaborator类-责任-协作者)建模类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等，它们在UML中的表示方式，如图1-10所示（图暂缺）

(1)关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系其余的关系涉及类元自身的描述，而不是它们的实例。对于关联关系的描述，可以使用关联名称、角色、多重性和导向性来说明。

(2)依赖关系。两个类A和B，如果B的变化可能会引起起A的变化，则称类A依赖于类B，依赖可以由各种原因引起，例如，一个类向另一个类发送消息、一个类是另个类的数据成员、一个类是另一个类的某个操作参数等。

(3)泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。

(4)共享聚集。共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用:车轮坏了，可以再换一个新的。

(5)组合聚集。组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。例如，一个公司包含多个部门，它们之间的关系就是组合关系。公司旦倒闭，也就没有部门了。

(6)实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

​

文章源于网络，如有侵权，请私信文章标题联系删除，谢谢。

为了能让更多人享受软考的政策福利和现实功利，51CTO旗下软考教研团队联合薛大龙老师，认真严肃向大家推出软考2日直播特训营。

扫码入群0元领取6G的软考6资料包+2天软考特训营名额

软考资料包括：软考16本电子版教材 & 36本辅导教材 + 27套历年真题试卷 + 21套精编知识点6G资料包​

软考训练营名额+资料领取方式>>>

扫下方码入群后按照老师的要求操作即可领取。

51CTO软考两天直播训练营

这门课恰好能够为你答疑解惑，助你快速入门并掌握软考知识要点，获得技能提升。为自己的职业发展规划制定一个更明确的规划，迈出升职加薪的第一步。

训练营周期为 两天直播课 晚8：00-9：00

心急的小伙伴可直接扫码解锁。

☟☟☟

2天软考直播特训营

3大必备技能

↓↓↓

限时 0 元 即可解锁

点击下方链接报名

仅限前100个名额

报名链接: ​ ​​https://edu.51cto.com/surl=oR9sp3​​​

课程涵盖：高分知识点梳理，案例分析解题方法、论文通用模板等。我们力争通过2天的直播课程，助力您快速入门并一次性通关软考！

如果你对这门课程还不太了解的话，就跟我一起往下看吧。

我们的主讲老师薛大龙老师，深耕软考教育培训20余年，主编出版软考辅导教材60余本，非常熟悉软考题目的要求、难度、以及判卷标准。

完成本体验营2天所有课程及作业考核，学员将掌握信息系统项目管理师、系统集成项目管理工程师的高频考点及答题技巧：

①掌握信息系统项目管理师知识体系；

②掌握考试高分占比知识领域；

③掌握考试考情前沿分析；

④掌握论文与案例超干货答题方法；

⑤掌握名师对真题的独到解析。

报名前，你还需要知道的3件事

1）课程形式

直播课程+社群学习活动

2）课程时间

报名后老师安排上课 晚8:00-9:00

3）报名后要做什么？

付费后根据提示添加学姐为好友，开营前学姐会统一拉人入群。

2天软考考证特训营

0 元 解锁课程

还可 领取「6G课程资料」

点击下方链接报名 仅限前100个名额

报名链接: ​​https://edu.51cto.com/surl=oR9sp3​​​