第一章 计算机软件与网络基础知识
第二章 信息化基础知识
第三章 系统开发基础知识
第四章 软件架构基础知识
第五章 安全性与可靠性技术
第六章 标准化与知识产权
第七章 应用数据
第八章 专业英语
注：本系列文章部分内容来自：系统架构设计师教程(第4版) ，作者：希赛教育软考学院。目录及知识点收集来自：系统架构设计师考试大纲。仅供学习使用。
目录
- 开发管理
- 项目的范围、时间、成本
- 文档管理工作、配置管理
- 软件开发的质量与风险
- 软件的运行与评价
- 需求管理
- 需求变更
- 需求跟踪
- 软件开发方法
- 软件开发生命周期
- 软件开发模型
- 构件与软件重用
- 逆向工程
- 形式化方法
- 软件开发环境与工具
- 集成开发环境
- 开发工具
- 设计方法
- 分析设计图示
- 结构化分析与设计
- 模块设计
- 面向对象的分析与设计
- I/O设计、人机界面设计
- 基于构件的开发
- 构件的概念与分类
- 中间件技术
- 典型应用架构（J2EE、.NET）
- 测试与评审
- 测试评审方法
- 验证与确认
- 测试自动化
- 测试设计和管理方法
开发管理 项目的范围、时间、成本
项目管理首先要考虑三个约束条件：项目范围、时间进度、成本预算。
项目范围管理：包括保证项目顺利完成所需的全部工作过程。其目的是控制项目的全部活动都在需求范围内，以确保项目资源的高效利用。它主要包括项目启动、范围计划编制、范围定义、范围核实和范围变更控制 5 个部分的内容。
项目成本管理：保证在批准预算内完成项目所需要的过程。软件项目的成本包括：开发成本，开发之前立项阶段及软件在运行中的费用，操作者的培训费用和项目所使用的各种硬件设施费用。项目成本管理包括资源计划编制、成本估算、成本预算、成本控制 4 个主要部分内容。
项目时间管理：包括确保项目按时完成所需的各个过程。包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制 5 个部分内容。
文档管理工作、配置管理软件配置管理：指在软件系统中确定和定义构件（源代码、可执行程序、文档等），在整个生命周期中控制发布和变更，记录和报告构件的状态和变更请求，并定义完整的、正确的系统构件的过程。核心部分：版本管理、问题跟踪和建立管理。
软件配置管理功能：配置标识、版本控制、状态统计、审计和审查、生产、过程管理、小组协作等。
常用的软件配置管理工具：Rational ClearCase，Merant PVCS，Microsoft VSS，CVS。
软件文档管理：指某种数据媒体和其中所记录的数据。具有永久性。用来对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信息。
软件文档的作用：管理依据、任务之间联系的凭证、质量保证、培训与参考、软件维护支持、历史档案、销售可能。
文档的归类：开发文档、管理文档、产品文档。
项目质量管理：包括保证项目能满足原先规定的各项要求所需要的过程，即“总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施”。
软件质量管理包括三个部分：
- 质量计划：判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准。
- 质量保证：定期评估项目总体绩效，建立项目能达到相关质量标准的信心。
- 质量控制：监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。
项目风险管理：对项目风险进行识别、分析、并采取应对措施的系统过程。
项目风险按是否有可确定性划分为：已知风险、可预知风险、不可预知风险。
项目风险按内容可划分为：内部技术风险、内部非技术风险、外部法律风险、外部非法律风险。
风险管理的过程风险管理包括：对项目风险识别、分析和应对的过程。
软件的运行与评价是指软件开发结束后交付用户使用，用户在实际使用中对软件是否符合开发时制定的一系列评价标准进行打分，看是否满足了用户的使用要求。
关注点：软件的稳定性和可靠性评价、软件是否满足了用户的需求、软件实施给用户带来的好处。
需求变更：指在软件开发过程中，用户确定软件需求之后，由于各种客观和主观条件的变化，用户增加了新的需求或改变了原有需求。
为保证项目变更的规范性和项目的有效实施而采取的措施：项目启动阶段的变更预防、项目实施阶段的需求变更。
需求跟踪：指在软件需求管理的过程中定义需求变更流程，分析需求变更影响，控制变化的版本，维护需求变更记录,跟踪每项需求状态。
- 确定需求变更控制过程。
- 进行需求变更影响分析。
- 建立需求基准版本和需求控制版本文档。
- 维护需求变更的历史记录。
- 跟踪每项需求的状态。
软件生命周期划分为 8 个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现、集成测试、确认测试、使用和维护。
软件开发模型瀑布模型：瀑布模型就如同瀑布一样，从一个特定的阶段流向下一个阶段。软件开发是一个阶段化的精确的过程。软件要经过需求分析、总体设计、详细设计、编码、调试、集成测试和系统测试阶段才能够被准确地实现。在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件，当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷，造成后期修改代价太大，难以控制开发的风险。瀑布 V 模型同标准瀑布模型一样，在进行完需求分析后就将进入总体设计阶段，但是除总体设计外，需求分析的结果将作为系统测试的准则，同时软件产品是否符合最初的需求将在系统测试阶段得到验证。
瀑布模型的缺点：需求分析阶段是一切活动的基础，瀑布模型难以适应变化，使用瀑布模型意味着当所有阶段都结束才能最终交付软件产品。
演化模型：一个演化模型可以看做若干次瀑布模型的迭代，当完成一个瀑布模型后，重新进入下一个迭代周期，软件在这样的迭代过程中得以演化、完善。
螺旋模型：将瀑布模型和演化模型结合起来。螺旋模型的每一周期都包括需求定义、风险分析、工程实现和评审 4 个阶段，由这 4 个阶段进行迭代，软件开发过程每迭代一次，软件开发就前进一个层次。螺旋模型的基本做法是在“瀑布模型”的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。螺旋模型强调风险分析。
螺旋模型的缺点：采用螺旋模型，需要具有相当丰富的风险评估经验和专业知识。过多的迭代次数会增加开发成本，延迟提交时间。
增量模型：在系统的技术架构成熟、风险较低的时候，可以采用增量的方式进行系统开发，这样可以提前进行集成测试和系统测试，缩短初始版本的发布周期，提高用户对系统的可见度。
增量模型的两种策略：一是增量发布的办法。另一种策略是原型法。
原型：原型法的每一次迭代都经过一个完整的生命周期。当用户需求很不明确或技术架构中存在很多不可知因素的时候，可以采用原型法。原型的主要目的是获得精确的用户需求，或验证架构的可用性。
构件组装模型：当经过需求分析定义出软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构件之间的关系。在确定了系统构件后，则将独立完成每一个构件，这时既可以开发软件构件，也可以重用已有的构件，当然也可以购买或选用第三方的构件。构件是独立的、自包容的，因此架构的开发也是独立的，构件之间通过接口相互协作。
统一软件过程RUP：本身是一个二维的结构，时间主线就是横轴的阶段，随着时间的流逝，软件开发活动总要经过初始、细化、构建和交付这 4 个阶段方能完成。而纵轴的工作流程则描述了在不同的阶段需要进行的主要工作。纵轴9 个核心工作流：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境。
RUP生命周期：目标里程碑、架构里程碑、能力里程碑、发布里程碑。
RUP 的特点：UP 是一个迭代的二维开发模型，采用不同迭代方式的 UP 可以演变为演化模型或增量模型，UP 的迭代特点使得更容易控制软件开发的风险，UP 是一个迭代的开发模型不属于敏捷方法，在实际应用中可以根据具体问题对 UP 进行裁减。
敏捷方法：尽早地、持续地向客户交付有价值的软件对开发人员来说是最重要的。拥抱变化，即使在开发的后期。经常交付可工作的软件，从几周到几个月，时间范围越小越好。在整个项目中，业务人员和开发者紧密合作。围绕士气高昂的团队进行开发，为团队成员提供适宜的环境，满足他们的需要，并给予足够的信任。在团队中，最有效率的、也是效果最好的沟通方式是面对面地交流。可以工作的软件是进度首要的度量方式。可持续地开发。不断追求优秀的技术和良好的设计有助于提高敏捷性。要简单，尽可能减少工作量。最好的架构、需求和设计都来自于一个自我组织的团队。团队要定期地总结如何能够更有效率，然后相应地自我调整。
构件与软件重用软件重用：利用已经存在的软件元素建立新的软件系统，这其中的软件元素既可以是软件产品、源程序，也可以是文档、设计思想甚至是领域知识。软件重用可以直接提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。
软件重用形式包括：源代码重用、架构重用、应用框架的重用、业务建模的重用、文档及过程的重用、软构件的重用、软件服务的重用。
构件：又称为组件，是一个自包容、可复用的程序集。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部。构件的两个最重要的特性是自包容与可重用。自包容指的是构件的本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。
构件重用：定义构件的标准(如CORBA、Java Bean/EJB、COM/DCOM)，规范开发者的实现和使用者的调用从而实现软件复用。
软件逆向工程：指软件开发过程的逆向过程，即从可运行的程序系统出发．对目标文件进行反汇编，得到其汇编代码，然后对汇编代码进行理解和分析，从而得出对应的源程序、系统结构以及相关设计原理和算法思想等。
软件逆向工程分为两个阶段：系统级逆向，分析目标系统，标识目标系统的组件以及它们之问相互关系。代码级逆向，创建不同形式或更高抽象层次的系统表示。
形式化方法：采用严格的数学方法，使用形式化规约语言来精确定义软件系统。基于数学的方式描述、开发和验证系统。形式化方法包括形式化描述和基于形式化描述的形式化验证两部分内容。形式化描述可以通过计算机技术进行自动处理，进行一致性的检查和证明，提高需求分析的效率和质量。
软件开发环境与工具 集成开发环境集成开发环境IDE：用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具。集成了代码编写功能、分析功能、编译功能、调试功能等一体化的开发软件服务套。所有具备这一特性的软件或者软件套都可以叫集成开发环境。常见的IDE：Visual Studio、Eclipse、PyCharm、Visual C++等。
优点：节省时间和精力、建立统一标准、管理开发工作。
缺点：学习曲线问题、初学者的困难、无法修复坏代码或设计。
建模工具：Rational Rose建模工具、EclipseUML建模工具等。
分析设计工具：XMind、数据库表设计工具-PowerDesigner、流程图设计工具-visio等。
编程工具：java开发工具-IntelliJ IDEA、前端开发工具-webstorm、python开发工具-PyCharm、关系型数据库客户端-navicat、DBeaver、kafka客户端工具-Kafka Assistant、IOS开发-X-Code、Eclipse、Visual Studio、VisualStudio.NET等。
测试工具：java性能分析工具-jprofiler、java性能分析工具-jconsole(JDK的bin目录下)、压力测试工具-JMeter、PostMan等。
项目管理工具：版本控制工具-git，svn、项目管理工具-maven等。
DFD： 是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理（过程）、数据存储。包括基本元素有：过程、外部实体、数据存储、数据流、实时连接。是一个自顶向下、由外到里的过程。
流程图：用来描述程序的细节逻辑，特点是简单、直观、易学，缺点是由于其随意性而使得画出来的流程图容易成为非结构化的流程图。
问题分析图PAD：符合自顶向下、逐步求精的原则，也符合结构化程序设计的思想，它最大的特点在于能够很方便地转换为程序语言的源程序代码。
结构图：基本成分包括模块、调用（模块之间的调用关系）和数据（模块间传递及处理数据信息）。结构图是在需求分析阶段产生的数据流图的基础上进行进一步的设计。
统一建模语言UML：是用于系统的可视化建模语言，是国际统一的软件建模标准。UML 是一种可视化语言，UML 是一种可用于详细描述的语言，UML 是一种构造语言，UML 是一种文档化语言。UML 由构造块、公共机制和架构三个部分组成。
结构化分析与设计结构化分析与设计方法：一种面向数据流的需求分析和设计方法，它适用于分析和设计大型数据处理系统，是一种简单、实用的方法，曾获得广泛的应用。
结构化分析方法的基本思想是：自顶向下逐层分解。分解和抽象是人们控制问题复杂性的两种基本手段。
结构化分析工具：数据流图、数据字典、结构化语言、判定表、判定树。
结构化分析的工作步骤：研究“物质环境”、建立系统逻辑模型、划清人机界限。
结构化设计：包括架构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化的过程。结构化设计是概要设计与详细设计的主要任务。
模块设计模块化：将一个待开发的软件分解成为若干个小的简单部分——模块，每个模块可以独立地开发、测试。其目的是使程序的结构清晰、易于测试与修改。
模块设计原则：信息隐蔽原则、模块独立性原则。
模块的内聚类型与耦合性类型及说明
| 内聚/耦合性类型 | 说明 |
|---|---|
| 功能内聚 | 完成一个单一功能，各个部分协同工作，缺一不可 |
| 顺序内聚 | 处理元素相关，且必须顺序执行 |
| 通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
| 过程内聚 | 处理元素相关，且必须按特定的次序执行 |
| 瞬时内聚 | 所包含的任务必须在同一时间间隔内执行 |
| 逻辑内聚 | 完成逻辑上相关的一组任务 |
| 偶然内聚 | 完成一组没有关系的任务 |
| 非直接耦合 | 没有直接联系，互相不依赖对方 |
| 数据耦合 | 借助参数表传递简单数据 |
| 标记耦合 | 一个数据结构的一部分借助于模块接口来传递 |
| 控制耦合 | 模块间传递信息中包含用于控制模块内部逻辑的信息 |
| 外部耦合 | 与软件以外的环境有关 |
| 公共耦合 | 多个模块引用同一个全局数据区 |
| 内容耦合 | 一个模块访问另一个模块内部数据，一个模块不通过正常入口转到另一个模块的内部，两个模块有一部分程序代码重叠，一个模块有多个入口 |
面向对象方法：以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结构与客观世界的实际比较接近，容易被人们接受。
对象是系统中用来描述客观事物的一个实体，它由对象标识（名称）、属性（状态、数据、成员变量）和服务（操作、行为、方法）三个要素组成，它们被封装为一个整体，以接口的形式对外提供服务。
面向对象分析：目标是开发一系列模型，这些模型描述计算机软件，当它工作时以满足一组客户定义的需求。
I/O设计、人机界面设计接口设计主要包括三个方面的内容：一是设计软件构件间的接口；二是设计模块和其他非人的信息生产者和消费者（如外部实体）的接口；三是人（如用户）和计算机间界面设计。
基于构件的开发 构件的概念与分类构件：指软件系统中可以明确辨识的构成成分。构件是一个组装单元，它具有约定式规范的接口及明确的依赖环境。构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语境有明显依赖关系、可独立部署的可组装软件实体。J2EE 客户端可以基于 Web，也可以基于 Java。
中间件技术中间件：基础软件的一大类，属于可复用软件的范畴。中间件要涉及软件的所有标准、规范和技术，它有更多的内涵，因为它包括平台功能，自身具有自治性、自主性、隔离性、社会化、激发性、主动性、并发性、认识能力等特性，是近似于 Agent（代理）的结构。
中间件特点：满足大量应用的需要；运行于多种硬件和 OS 平台；支持分布计算，提供跨网络、硬件和 OS 平台的透明性的应用或服务的交互；支持标准的协议；支持标准的接口。
中间件的分类：通信处理（消息）中间件、事务处理（交易）中间件、数据存取管理中间件、Web 服务器中间件、安全中间件、跨平台和架构的中间件、专用平台中间件、网络中间件。
J2EE：是针对 Web Service、业务对象、数据访问和消息报传送的一组规范。J2EE 注重两件事，一是建立标准，使 Web 应用的部署与服务器无关；二是使服务器能控制构件的生命周期和其他资源，以便能够处理扩展、并发、事务处理管理和安全性问题。J2EE 规范定义了以下几种构件：应用客户端构件、EJB 构件、Servlets 和 JSP、Applet 构件。J2EE 采用的是多层分布式应用模型。
J2EE层次划分：
- 表示层：基于 Web或者基于 Java。Web主要为HTML、基于 Java主要为Applet。
- 应用服务层：包含表示层请求的表示逻辑和业务逻辑。表示层由显示 HTML 页面的 JSP 页面和 Servlets 实现。业务逻辑通过 RMI 对象和 EJB 实现。EJB 依靠容器来实现事务处理、生命周期和状态管理、资源池、安全等问题，容器是 EJB 运行的环境。
.NET：是一个环境。是一个“不再关注单个网站、单个设备与 Internet 相连的网络环境，而是要让所有的计算机群、相关设备和服务商协同工作”的网络计算环境。.NET 包括 4 个重要特点：一是软件变服务，二是基于 XML 的共同语言，三是融合多种设备和平台，四是新一代的人机界面。Microsoft.NET 开发框架：
- 通用语言运行时：框架的基础，处于框架的最底层。
- 基础类库：从输入输出到数据访问等各方面，提供了一个统一的面向对象的、层次化的、可扩展的编程接口。
- ADO.NET：访问数据库的技术。
- ASP.NET：网络编程结构。
- WinForms：基于 Windows 的应用。
- 开发语言：VB，C++，C#和 Jscript。
- 其他特征：安全系统和配置系统。
软件测试与评审是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。“错误”（error）和“缺陷”（fault）的概念：“错误”主要针对软件开发过程，“缺陷”主要针对软件产品。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品(主要是指程序)中的错误(缺陷)。
测试方法：
- 从测试阶段上分，软件测试通常可分为单元测试(发现编程和详细设计中产生的错误)、集成测试(发现模块间的接口和通信问题)和系统测试(从全局来考察软件系统的功能和性能要求)。
- 从测试方法上分，软件测试可分为白盒测试和黑盒测试。白盒测试：用于单元测试阶段,测试者完全知道程序的结构和处理算法。主要的覆盖标准有 6 种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖。黑盒测试：主要用于集成测试和确认测试阶段，完全不了解软件的内部结构和处理算法，只考虑功能。常用的黑盒测试技术包括等价类划分、边值分析、错误推测和因果图等。
缺陷的分类：输入/输出错误、逻辑错误、计算错误、接口错误、数据错误。
缺陷的等级：轻微、中等、使人不悦、影响使用、严重、非常严重、极为严重、无法容忍、灾难性、传染性。
评审方法：评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。软件评审包括软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查和管理评审。
验证与确认验证与确认：都是确定软件产品是否满足其预期要求和条件的过程。验证可适用于分析、设计、编码、测试和评审等众多的过程，而确认通常用于验收过程。
软件项目的验证一般应包括：合同验证、过程验证、需求验证、设计验证、编码验证、集成验证和文档验证。
确认过程应包括：编写测试需求、测试用例和测试规程。确保这些测试需求、测试用例和测试规程可以反映软件产品的预期用途。执行测试。确认软件产品满足其预期用途。
测试自动化：将测试重复性的、非智力创造性的、需要细致注意力的工作让计算机代替人类去完成即测试自动化。
一些适于考虑进行自动化的测试工作为：测试用例的生成（包括测试输入、标准输出、测试操作指令等）。测试的执行控制（包括单机与网络多机分布运行、夜间及假日运行、测试用例调用控制、测试对象、范围、版本控制等）。测试结果与标准输出的对比。不吻合的测试结果的分析、记录、分类和通报。总测试状况的统计，报表的产生。
测试用例：为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。其本质是从测试角度对被测对象的功能和各种特性的细节展开。测试用例=输入(数据+步骤)+输出+执行条件(环境等)。测试用例应具有代表性、可判定性、可再现性、有效性。测试用例的设计主要根据测试需求，设计出的测试用例要按照规范的模式描述出来。
测试数据管理：基于挑战分析和引入加上应用最佳工具和方法来处理已识别问题的过程，而不会影响最终产出的可靠性和全面覆盖。
