宝子们！上半年软考已经结束一段时间了，准备备考下半年软考高级-系统分析师的小伙伴可以开始准备了，毕竟高级科目的难度可是不低的，相信参加过上半年系分的小伙伴深有体会。

这里给大家整理了50个高频考点，涵盖全书90%重点，先把这个存下！再慢慢看书，边看书边背这个，事半功倍，祝大家今年都能考试顺利，成功上岸!

1、与逆向工程相关的概念

（1）重构（restructuring）。重构是指在同一抽象级别上转换系统描述形式。

（2）设计恢复（design recovery）。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。

（3）逆向工程（reverse engineering）：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。

（4）正向工程（forward engineering）。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。

（5）再工程（re-engineering）。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

2、面向对象设计原则

单一职责原则：设计目的单一的类

开放-封闭原则：对扩展开放，对修改封闭

李氏(Liskov)替换原则：子类可以替换父类

依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程

接口隔离原则：使用多个专门的接口比使用单一的总接口要好

组合重用原则：要尽量使用组合，而不是继承关系达到重用目的

迪米特(Demeter)原则(最少知识法则)：一个对象应当对其他对象有尽可能少的了解

3、遗留系统演化策略

淘汰策略：遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

继承策略：遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

改造策略：遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

集成策略：遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。

4、新旧系统转换策略

直接转换：直接转换是在原有系统停止运行的某一时刻，新系统立即投入运行，中间没有过渡阶段。采用这种方式时，人力和费用最省，适用于系统不太复杂或现有系统完全不能使用的场合。但是这种方式风险高。

并行转换：并行转换就是新系统和旧系统并行工作一段时间，经过这段时间的试运行后，再用新系统正式替换下现有系统。那么这种方式，它的好处就是风险很小。在转换期间还可以同时比较新旧两套系统的性能，而且能够让操作人员得到全面的培训，所以对于一些比较大的信息系统，或者处理过程比较复杂，数据比较重要的系统。并行转换是一种最常用的转换方式。那么这种转换方式也有缺点，缺点就在于两套系统并行期间。要有两套人马，或者两套处理方式同时并存，在人力和费用消耗比较大，转换的周期比较长，而且难以控制新旧系统当中数据的变化。所以这就要求要做好转换计划，并且要加强管理。

分段转换：这是直接转换和并行转换的结合，也就是分期分批、逐步转换。一般比较大的系统可以采用这种方式比较合适，他能够保证软件平稳运行，费用也不太高，就是将大的系统分成多个子系统，每成熟一个子系统就切换一个子系统，主要是分期分批。这种分段转换的策略，它的优点就是成熟一个子系统就转换一个子系统。这种新旧转换，震动比较小，用户比较容易接受。但是由于采取的是渐进的方式，会导致新旧系统的转换周期比较长。

5、系统维护分类

正确性维护【修BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误。

适应性维护【应变】：指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。

完善性维护【新需求】：扩充功能和改善性能而进行的修改。

预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。经典实例：【专用】改【通用】。

6、影响可维护性的因素

（1）可理解性：是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度。

（2）可修改性：是指修改软件的难易程度。

（3）可测试性：是指验证软件程序正确的难易程度。

可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大。

（4）可靠性：一个软件的可靠性越高，需要维护的概率就会越低。

（5）可移植性：是指将软件从一个环境移植到新的环境下正确运行的难易程度。软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率。

7、测试阶段划分

单元测试：依据详细设计，模块测试，模块功能、性能、接口等

集成测试：依据概要设计，模块间的接口

系统测试：依据需求文档，在真实环境下，验证完整的软件配置项能否和系统正确连接

确认测试：依据需求文档，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试

8、静态测试与动态测试

静态测试它就不运行软件测试的程序，而是采用人工检测、计算机分析辅助静态分析的手段来对程序进行检测。静态测试的方法主要有桌前检查、代码走查、代码审查。

动态测试可以分为黑盒测试、白盒测试和灰盒测试。白盒测试也称为结构性测试，黑盒测试也称为功能性测试。灰盒测试是二者的结合。

9、需求获取方法

收集资料：把与系统有关的、对系统开发有益的信息收集起来。

用户访谈：1对1-3，有代表性的用户。成本高。

问卷调查：用户多，无法一一访谈。成本低。

现场观摩：针对较为复杂的流程和操作。

参加业务实践：有效地发现问题的本质和寻找解决问题的办法。

联合需求计划（JRP）：高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。

阅读历史文档：对收集数据性的信息较为有用。

情节串联板：一系列图片，通过这些图片来讲故事。

抽样调查：基于数理统计，降低成本，快速获取。样本大小＝ɑ*（可信度系数/可接受的错误）2 ，注： ɑ一般取0.25

10、UML 4+1视图

（1）逻辑视图：以问题域的语汇组成的类和对象集合。

（2）进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。

（3）实现视图：对组成基于系统的物理代码的文件和组件进行建模。

（4）部署视图：把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。

（5）用例视图：最基本的需求分析模型。

......

篇幅有限，有需要PDF完整版或更多资料的朋友，可以自行获取↓↓↓