前言
由于笔记复制到CSDN样式失效，没有精力再重新完整的检查并设置一遍样式，有积分的可以前往下载word、pdf、有道云笔记版本。
需要说明的是，下载的内容与本篇分享内容一致，只有样式的区别【比如重点记忆、常考内容有颜色、字号、自重等样式，目录结构更完善，表格不是图片，等】
本章下载地址：
https://download.csdn.net/download/chengsw1993/85598023
如果发现文章存在阅读不同、显示异常等内容，请评论区告知以便修改，应该都是CSDN的markdown语法导致的。
系列文章
上一篇：【软考-软件设计师精华知识点笔记】第五章 软件工程基础知识
下一篇：【软考-软件设计师精华知识点笔记】第七章 面向对象技术
系统分析与设计
分析系统做什么
目的和任务：对现行系统进一步详细调查，将调查所得文档资料集中，对组织内部整体管理状况和信息处理过程进行分析，为系统开发提供所需的资料，并提交系统方案说明书
步骤：根据当前系统物理模型，得出逻辑模型，分析优化建立目标系统的逻辑模型，进而具体化建立目标系统的物理模型。
系统设计
系统设计基本原理：
- 抽象（重点说明本质方面，忽略非本质方面）；
- 模块化（可组合、分解和更换的单元）；
- 信息隐蔽（将每个程序的成分隐蔽或封装在一个单一的设计模块中）；
- 模块独立（每个模块完成一个相对独立的特定子功能，且与其他模块之间的联系简单）。
模块的设计要求独立性高，就必须高内聚，低耦合，内聚是指一个模块内部功能之间的相关性，耦合是指多个模块之间的联系。
内聚
时间内聚：模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。
过程内聚：模块内各处理成分相关，且必须以特定次序执行。
信息（通信）内聚：信息内聚指模块写成多个功能，各个功能都在同一数据结构上操作，每个功能有唯一入口。
功能内聚：模块仅包括为完成某个功能所必须的所有成分（模块所有成分共同完成一个功能， 缺一不可）。
耦合
数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共 数据结构或外部变量) 来交换输入、输出信息的。
标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子 结构，而不是简单变量。其实传递的是这个数据结构的地址；
控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
内容耦合：当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时，就发生 了内容耦合。此时，被修改的模块完全依赖于修改它的模块。
系统总体结构设计
系统结构设计原则：分解-协调原则、自顶向下原则、信息隐蔽和抽象原则、一致性原则、明确性原则、模块间高内聚低耦合、模块的扇入系数和扇出系数合理、模块规模适当。
子系统划分的原则：子系统要具有相对独立性、子系统之间数据的依赖性尽量小、子系统划分的结果应使数据冗余较小、子系统的设置应考虑今后管理发展的需要、子系统的划分应便于系统分阶段实现、子系统的划分应考虑到各类资源的充分利用。
WebApp分析与设计
WebApp是基于web的系统和应用。大多数WebApp采用敏捷开发过程模型进行开发。
WebApp的特性：网络密集性（服务于不同客户全体的需求）、并发性（大量用户同时访问）、无法预知的负载量（用户数量）、性能（响应时间过长导致用户流失）、可用性（最好724365可用）、数据驱动（和用户的数据交互）。
WebApp五种需求模型：
1、内容模型：给出由WebApp提供的全部系列内容，包括文字、图形、图像、音频和视频。包含结构元素，为WebApp的内容需求提供了一个重要的视图。这些结构元素包含内容对象和所有分析类，在用户与WebApp交互时生成并操作用户可见的实体。
内容的开发可能发生在WebApp实现之前、构建之中、或者投入运行以后（全过程）。
内容对象：产品的文本描述、新闻文章、照片、视频等。
数据树：由多项内容对象和数据项组成的任何内容都可以生成数据树，是内容设计的基础，定义一种层级关系，并提供一种审核内容的方法，以便在开始设计前发现遗漏和不一致内容。
2、交互模型：描述了用户与WebApp采用了哪种交互方式。由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等。
- 用例是交互分析的主要工具，方便客户理解系统的功能。
- 顺序图是交互分析中描述用户与系统进行交互的方式。用户按照已定顺序使用系统，完成相应的功能，如登录流程。
- 状态图是交互分析中对系统进行动态的描述。如状态的变化。
- 用户界面原型展现用户界面布局、内容、主要导航链接、实施的交互机制及用户WebApp的整体美观度。
3、功能模型：许多WebApp提供大量的计算和操作功能，这些功能与内容直接相关（既能使用又能生成内容，如统计报表）。这些功能常常以用户的交互活动为主要目标。
功能模型定义了将用于WebApp内容并描述其他处理功能的操作，这些处理功能不依赖于内容却是最终用户所必需的。
4、导航模型：为WebApp定义所有导航策略。考虑了每一类用户如何从一个WebApp元素（如内容对象）导航到另一个元素。
5、配置模型：描述WebApp所在的环境和基础设施。在必需考虑复杂配置体系结构的情况下，可以使用UML部署图。
WebApp设计
1、架构设计：使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。
MVC（模型-视图-控制器）结构是WebApp基础结构模型之一，将WebApp功能及信息内容分离。
2、构件设计
WebApp构件：定义良好的聚合功能，为最终用户处理内容或提供计算或处理数据；内容和功能的聚合包，提供最终用户所需要的功能。因此，WebApp构件设计通常包括内容设计元素和功能设计元素。
构件级内容设计：关注内容对象，以及包装后展示给最终用户的方式，应该适合创建的WebApp特性。
构件级功能设计：将WebApp作为一系列构件加以交付，这些构件与信息体系结构并行开发，以确保一致性。
3、内容设计：着重于内容对象的表现和导航的组织，通常采用线性结构、网格结构、层次结构、网络结构四种结构及其组合。
4、导航设计：定义导航路径，使用户可以访问WebApp的内容和功能。
软件需求
按需求内容分类：
业务需求：由客户提出的宏观的一个功能需求。
用户需求：设计员去调查需求中涉及到的每个用户的具体需求。
系统需求：经过整合，形成最终的系统需求，包括功能、性能、设计约束三个方面的需求。
从客户角度分类：
基本需求：需求明确规定的功能。
期望需求：除了基本需求外，客户认为理所应当包含在内的其他功能。
兴奋需求：客户未要求的其他功能需求，会浪费项目开发时间和成本。
需求分析
软件需求分类：
功能需求：软件必须完成的基本动作。
性能需求：说明软件或人与软件交互的静态或动态数值需求，如系统响应速度、处理速度等。
设计约束：受其他标准硬件限制等方面的影响。
属性：可用性、安全性、可维护性、可转移/转移性。
外部接口需求：用户接口、硬件接口、软件接口、通信接口。
需求工程
需求工程六个阶段
需求获取：获取需求，方法有收集资料、联合讨论会JRP、用户访谈、书面调查、现场观摩、参加业务实践、阅读历史文档、抽样调查。
需求分析与协商：分析不同人提出的所有需求之间的关系并判断。
系统建模：建立系统的抽象模型。
需求规约：也即需求定义，目的是为了编写需求规约（即需求规格说明书），在双方之间达成一个共识。
需求验证：需求开发阶段的复查手段，需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线。
需求管理：对需求工程涉及的所有过程进行规划和控制。
需求管理
定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。
处理需求变更：主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
需求跟踪：双向跟踪，两个层次，正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少。如下图所示：
结构化分析与设计
结构化的分析方法SA，自顶向下，逐步分解，是面向数据的，强调分析对象的数据流，需要建立：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典（数据元素、数据结构、数据流、数据存储、加工逻辑、外部实体）。
数据流图描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图：
数据流图
数据流图（Data Flow Diagram）：简称DFD
数据流图是可以分层的，从顶层（即上下文无关数据流）到0层、1层等，顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。数据流图示例如下：
数据流图基本设计原则：【下午的试题中补充数据流图，就需要根据该原则】
（1）数据守恒原则：对任何一个加工(操作)来说，其所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据。
（2）守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，即使它们的组成成分相同。
（3）对于每个加工，必须既有输入数据流，又有输出数据流。
（4）外部实体与外部实体之间不存在数据流
（5）外部实体与数据存储之间不存在数据流
（6）数据存储与数据存储之间不存在数据流
（7）父图与子图的平衡原则：子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，此即父图与子图的平衡。父图与子图之间的平衡原则不存在于单张图。
（8）数据流与加工有关，且必须经过加工。
数据字典
数据字典是用来定义在数据流图中出现的符号或者名称的含义，在数据流图中，每个存储、加工、实体的含义都必须定义在数据字典中，并且父图和子图之间这些名称要相同。示例如下：
测试基础知识
系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
测试原则：
应尽早并不断的进行测试；
测试工作应该避免由原开发软件的人或小组承担；
在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果；
既包含有效、合理的测试用例，也包含不合理、失效的用例；
检验程序是否做了该做的事，且是否做了不该做的事；
严格按照测试计划进行；
妥善保存测试计划和测试用例；
测试用例可以重复使用或追加测试。
测试阶段
单元测试：对单个模块进行测试，由程序员自己测试模块内部的接口、信息、功能，测试依据是软件详细说明书。在单元测试中，驱动模块（上层）用来调用被测模块，自顶向下的单元测试中不需要另外编写驱动模块。桩模块（底层）用来模拟被测模块所调用的子模块。
集成测试：将模块组合起来进行测试，分为一次性组装（简单，节约时间，发现错误少，只适合于小项目）和增量式组装（能够发现更多错误，耗时长，又可分为：自顶向下、自底向上、混合式）。
确认测试：对已完成的软件进行功能上的测试，分为内部确认测试（无用户情况）、Alpha测试（用户在开发环境下进行测试）、Beta测试（用户在实际使用时进行的测试）、验收测试（用户根据SRS对项目进行验收）
系统测试：对软件进行性能测试，主要测试三个方面，即负载测试（在极限情况下，系统各项性能指标）、强度测试（系统资源特别低的情况下）、容量测试（并发测试，系统可以处理的同时在线的最大用户数量）。其他还有可靠性等性能测试，系统测试采用的是黑盒测试方法。
回归测试：软件修改错误或变更后，进行回归测试以验证之前正确的代码是否引入了错误。
测试方法
动态测试：程序运行时测试，分为：
黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
灰盒测试法：即既有黑盒，也有白盒。
静态测试：程序静止时，即对代码进行人工审查，分为：
-
桌前检查：程序员检查自己编写的程序，在程序编译后，单元测试前。
-
代码审查：由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行审查。
-
代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。
测试策略
自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。
测试用例设计
黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：
-
等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
-
边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0，150，-1，151四个。
-
错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。
-
因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。
白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从低至高分为下面六种：
- 语句覆盖：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
- 判定覆盖：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
- 条件覆盖：对于代码中的一个条件，可能是组合的，如a>0&&b<0，判断覆盖只针对此组合条件的真假分支做两个测试用例，而条件覆盖是对每个独立的条件都要做真假分支的测试用例，共可有4个测试用例，层级更高，注意区别，条件覆盖，针对每个条件都要真假覆盖，判定覆盖，只针对一个条件判断语句。
- 判定/条件覆盖：使判定中每个条件的所有可能取值（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次，即两种覆盖的综合。
- 条件组合覆盖：每个判定条件中条件的各种可能值的组合都至少出现一次。
- 路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。
调试
测试是发现错误，调试是找出错误的代码和原因。
调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试。
调试的方法有：蛮力法、回溯法（从出错的地方开始，向回找）、原因排除法（找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法）。
系统运行与维护
系统转换
系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：
真接转换：现有系统被新系统真接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。
并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。
分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。
数据转换与迁移：将数据从旧数据库迁移到新数据库中。要在新系统中尽可能的保存旧系统中合理的数据结构，才能降低迁移的难度。也有三种方法：系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。
转换的过程称为ETL，有三个步骤：抽取（旧数据库数据)——转换（三种转换方法）——装载（装入新数据库，并校验数据）。
系统维护
软件维护是软件生命周期中的最后一个阶段，不属于系统开发过程。是在软件已经交付使用之后为了改正错误或满足新的需求而修改软件的过程，即软件在交付使用后对软件所做的一切改动。
系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下：
- 易测试性：指为确认经修改软件所需努力有关的软件属性；
- 易分析性：指为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性；
- 易改变性：指与进行修改、排错或适应环境变换所需努力有关的软件属性；
- 稳定性：指与修改造成未预料效果的风险有关的软件属性。
系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：
正确性维护：发现了bug而进行的修改。
适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。
完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。
预防性维护：对未来可能发生的bug进行预防性的修改。
系统评价
系统评价分类
立项评价：系统开发前的预评价，分析是否立项开发，做可行性评价。
中期评价：项目开发中期每个阶段的阶段评审。或者项目在开发中途遇到重大变故，评价是否还要继续。
结项评价：系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进行的综合评价。
系统评价的指标
（1）从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标。
（2）从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平；对于用户方而言，关心的是用户需求和运行质量；系统外部环境则主要通过社会效益指标来反映。
（3）从经济学角度出发，分别按系统成本、系统效益和财务指标3条线索建立指标。