当前位置：首页 > news >正文

【架构师干货】软件工程

news 2025/8/29 9:25:10

1. 软件工程概述

软件工程基本原理

软件工程基本原理：通过划分生命周期阶段的方式严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚地审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性。

软件开发生命周期

软件定义时期:包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标具体可分成问题定义、可行性研究、需求分析等。
软件开发时期:就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
软件运行和维护:就是把软件产品移交给用户使用。

软件生命周期各个阶段活动的产物经审批后即可称之为软件配置项。

软件系统文档

软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容。

软件工程过程

软件工程过程是指为获得软件产品包括以下4个方面活动（PDCA）:

P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
D(Do)——软件开发。开发出满足规格说明的软件。
C(Check)——软件确认。确认开发的软件能够满足用户的需求。
A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。

软件系统工具

软件系统工具通常可以按软件过程活动将软件工具分为:

软件开发工具:需求分析工具、设计工具、编码与排错工具、测试工具等。
软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择

软件设计活动

软件设计四个活动:数据设计、架构(体系结构)设计、人机界面(接口)设计和过程设计。

体系结构设计	定义软件系统各主要部件之间的关系。
数据设计	将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
接口设计(人机界面设计)	软件内部，软件和操作系统间以及软件和人之间如何通信。
过程设计	系统结构部件转换成软件的过程描述。

2. 能力成熟度模型

能力成熟度模型CMM

能力等级	特点	关键过程区域
初始级（Initial）	软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
可重复级（Repeatable）	建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。	软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理。
已管理级（Managed）	制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。	软件质量管理和定量过程管理
优化级（Optimized）	加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。	过程更改管理、技术改革管理和缺陷预防。

能力成熟度模型集成CMMI

是若干过程模型的综合和改进，不仅仅软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
CMMI两种表示方法：

阶段式模型：类似于CMM，它关注组织的成熟度，五个成熟度模型如下：

能力等级	特点	关键过程区域
初始级	过程不可预测且缺乏控制
已管理级	过程为项目服务	需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证。
已定义级	过程为组织服务	需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、风险管理、集成化的团队、决策分析和解决方案、组织集成环境
定量管理级	过程已度量和控制	组织过程性能、定量项目管理
优化级	集中于过程改进和优化	组织级改革和实施、因果分析和解决方案

连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。

数据管理能力成熟度评估模型DCMM

DCMM 评估模型即《数据管理能力成熟度评估模型》（GB/T 36073-2018），是我国首个数据管理领域正式发布的国家标准。以下是对它的详细介绍：

核心能力域：DCMM 数据管理能力成熟度评估模型定义了 8 个核心能力域，分别是数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生命周期。这 8 个核心能力域又被细分为 28 个过程域和 441 项评价指标。
成熟度等级：DCMM 将数据管理能力成熟度划分为 5 个等级，自低向高依次为初始级（1 级）、受管理级（2 级）、稳健级（3 级）、量化管理级（4 级）和优化级（5 级）。不同等级代表企业数据管理和应用的成熟度水平不同。具体如下：
- 初始级（1 级）：数据需求的管理主要在项目级体现，没有统一的管理流程，主要是被动式管理。
- 受管理级（2 级）：组织已意识到数据是资产，根据管理策略的要求制定了管理流程，但尚未形成全面的体系。
- 稳健级（3 级）：数据已被当作实现组织绩效目标的重要资产，在组织层面制定了一系列的标准化管理流程，促进数据管理的规范化。
- 量化管理级（4 级）：数据被认为是获取竞争优势的重要资源，数据管理的效率能够量化分析，有明确的量化指标和管理方法。
- 优化级（5 级）：数据被认为是组织生存和发展的基础，相关管理流程能实时优化，持续改进以适应不断变化的业务需求和市场环境。
适用对象：
- 数据拥有方：如金融与保险机构、互联网企业、电信运营商、工业企业、数据中心所属主体、高校、政务数据中心等，可评估自身的数据管理和应用能力，发现问题并提升数据治理水平。
- 数据解决方案提供方：包括数据开发 / 运营商、信息系统建设和服务提供商、信息技术服务提供商等，有助于完善自身解决方案的完备度，提升对外提供产品及服务的数据管理和应用能力。
评估流程：
- 评估准备：评估工作部遴选试点评估单位，入选单位向评估机构提交申请材料。
- 正式评估：评估机构受理后，进行文件评审和现场评审，出具评估报告并给出评估等级推荐意见，报评估工作部备案。
- 结果评议：评估工作部对评估结果进行合规性审查，对量化管理级和优化级评估结论组织专家评议，通过审查、复核或评议的进行公示，公示无异议后由评估机构颁发证书。
作用和价值：
- 帮助企业科学有效地掌握数据管理方法，发现问题和差距，明确提升数据管理能力的路径。
- 有助于企业完善内部管理，提升数据作为核心战略资源的地位。
- 促进企业人员技能提升，推动企业数据管理人才队伍建设。
- 帮助企业提高市场竞争门槛，促进数据元素价值释放，在对外服务、试点项目、数字经济领域等获得更多机会和优势。

3. 软件过程模型

瀑布模型

在这里插入图片描述
瀑布模型（SDLC）：瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。
瀑布模型特点：

从上一项开发活动接受该项活动的工作对象作为输入。
利用这一输入，实施该项活动应完成的工作内容。
给出该项活动的工作成果，作为输出传给下一项开发活动。
对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

螺旋模型

在这里插入图片描述
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。在螺旋模型中，软件开发是一系列的增量发布。
开发过程具有周期性重复的螺旋形状。四个象限分别标志每个周期所划分的四阶段：制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。

V模型

在这里插入图片描述
v模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码。右边的上画线代表了单元测试、集成测试、系统测试与验收测试。V模型的特点如下:

单元测试的主要目的是针对编码过程中可能存在的各种错误
集成测试的主要目的是针对详细设计中可能存在的问题
系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行;
验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
v模型用于需求明确和需求变更不频繁的情形。

原型化模型

原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。
原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下：

实际可行
具有最终系统的基本特征
构造方便、快速、造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。

增量模型

增量模型:首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
特点:由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不同的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。
在这里插入图片描述

喷泉模型

喷泉模型:是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

基于构件的开发模型CBSD

基于构件的开发模型CBSD:利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造多个软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。

形式化方法模型

形式化方法模型:建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。

敏捷模型

开发宣言：
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划。

在这里插入图片描述
敏捷方法区别于其他方法的两个特点：

“适应性”而非“预设性”
“面向人的”而“非面向过程的”

敏捷方法的核心思想：

敏捷方法是适应型，而非可预测型。拥抱变化，适应变化。
敏捷方法是以人为本，而非以过程为本。发挥人的特性。
迭代增量式的开发过程。以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。

主要敏捷方法:

极限编程(XP)。基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手进行改善:加强交流；从简单做起；寻求反馈；勇于实事求是。
1. XP 是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
2. XP提倡测试先行，为了将以后出现bug的几率降到最低。
水晶系列方法。与XP方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
并列争球法(Scrum)。是一种迭代的增量化过程，把每段时间(如30天)一次的迭代称为一个“冲刺”(Sprint)，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。
特性驱动开发方法(FDD)。是一个迭代的开发模型。认为有效的软件开发需要3个要素:人、过程和技术。有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。

统一过程模型(RUP)

RUP 描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP 类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
RUP 软件开发生命周期是一个二维的软件开发模型，RUP 中有9个核心工作流，如下

业务建模:理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
需求:定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
分析与设计:把需求分析的结果转化为分析与设计模型。
实现:把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
测试:检查各子系统之间的交、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
部署:打包、分发、安装软件，升级旧系统;培训用户及销售人员，并提供技术支持。配置与变更管理:跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理:为软件开发项目提供计划、人员分配、执行、监等方面的指导，为风险管理提供框架
环境:为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

RUP 把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4 个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下：

初始阶段:定义最终产品视图和业务模型，并确定系统范围。
细化阶段:设计及确定系统的体系结构，制订工作计划及资源要求
构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交。
移交阶段:把产品提交给用户使用。

RUP 中定义了如下一些核心概念，理解这些概念对于理解RUP 很有帮助。

角色:Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师、设计人员、实现人员、测试员和配置管理人员等，并对每一个角色的工作和职责都做了详尽的说明。
活动: How 的问题。活动是一个有明确目的的独立工作单元。
制品: What的问题。制品是活动生成、创建或修改的一段信息。
工作流:When 的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP的特点:

用例驱动:需求分析、设计、实现和测试等活动都是用例驱动的。
以体系结构为中心:包括系统的总体组织和全局控制、通信协议等。是一个多维的结构，会采用多个视图来描述。在典型的4+1视图模型中:
分析人员和测试人员关心的是系统的行为，会侧重于用例视图；
最终用户关心的是系统的功能，会侧重于逻辑视图;
程序员关心的是系统的配置、装配等问题，会侧重于实现视图;
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；
系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。

在这里插入图片描述
3. 迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程;每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。

软件过程模型总结

类型	特征
瀑布模型	结构化方法。开发阶段性、需求明确、文档齐全、风险控制弱。
原型模型	迭代方法。分为原先开发与目标软件开发。需求不明确。
螺旋模型	迭代方法。瀑布与原型(演化)模型结合体。适用于大型、复杂、风险项目。
喷泉模型	面向对象方法，复用好、开发过程无间隙，节省时间。
V模型	开发与测试结合。
W模型	测试尽早介入，每个阶段都有测试参与，强调开发与测试并行进行，但灵活性受限，对测试人员技术水平要求高。
变换模型、形式化方法模型	适用于形式化开发。
智能模型	适用于基于规则的专家系统。
快速应用开发RAD模型、增量模型	基于构件的开发方法。用户参与、开发或复用构件、模块化要求高，不适用新技术。
RUP/UP模型	用例驱动、架构为中心、迭代、增量。
基于构件的开发模型CBSD	基于构件的开发方法。开发或复用构件。

软件过程构架结构由四个层次组成:方针、过程、规程和第四层的标准、规范、指南、模板、Checklist等组成。

方针为第一层文件,它是组织标准软件的高层次的抽象描述,它反映在公司的过程改进总体方针、政策中，由公司主管副总裁批准执行。
过程为第二层文件，主要规定在项目开发中执行该过程时应当执行的各项活动及适用标准。过程定义文件及其相关文件制定必须符合方针的要求。
规程为第三层文件，是对过程某些复杂活动的具体描述。
标准、规范、指南、模板、Checklist、范例库等是对上级过程或规程提供细致的步骤、活动及说明的支持性文档,第四层的文件从属于上级过程。

4. 逆向工程

软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
逆向工程:软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。逆向工程的四个级别:

实现级:包括程序的抽象语法树、符号表、过程的设计表示。
结构级:包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
功能级:包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。
其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。

逆向工程恢复信息的方法如下表

方法	导出信息
用户指导下的搜索与变换（User-Directed Search and Transformation）	实现级、结构级
变换式方法（Transformation Approaches）	实现级、结构级、功能级
基于领域知识（Domain Knowledge-Based）的方法	功能级、领域级
铅板恢复法	实现级、结构级

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。

重构是指在同一抽象级别上转换系统描述形式。
设计恢复是指借助工县从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
再工程是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。
正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。

5. 需求工程

软件需求

软件需求:是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
分为需求开发和需求管理两大过程，如下所示：
在这里插入图片描述
业务需求:反映企业或客户对系统高层次的目标要求，通常来自项目投资人客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围
用户需求:描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
系统需求:从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

功能需求:也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
非功能需求:指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
设计约束:也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

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

常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。

需求获取

需求获取:是一个确定和理解不同的项目于系人的需求和约束的过程。
常见的需求获取法包括:

用户访谈：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。
问卷调查:用户多，无法一一访谈。
采样:从种群中系统地选出有代表性的样本集的过程。 $样本数量=0.25×(可信度因子错误率)2样本数量=0.25\times \left( \frac{可信度因子}{错误率} \right)^2$
情节串联板:一系列图片，通过这些图片来讲故事。
联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。

需求分析

需求分析:一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析的任务：

绘制系统上下文范围关系图
创建用户界面原型
分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD(质量功能部署)

结构化的需求分析

结构化特点：自顶向下，逐步分解，面向数据。
三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典。
在这里插入图片描述

数据流图DFD

基本图形元素：外部实体、加工、数据存储、数据流。
在这里插入图片描述

数据流：由一组固定成分的数据组成，表示数据的流向。在DFD 中，数据流的流向必须经过加工。
加工:描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误如图所示：
1. 加工3.1.2 有输入但是没有输出，称之为“黑洞”
2. 加工3.1.3 有输出但没有输入。称之为“奇迹”
3. 加工3.1.1 中输入不足以产生输出，我们称之为“灰洞”
数据存储:用来存储数据。
外部实体(外部主体)：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)

分层数据流图

(a) 顶层图
(b) 0层图
(c) 加工1的1层图
(d) 加工2的1层图

数据字典DD

数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
数据字典有以下4 类条目:数据流、数据项、数据存储和基本加工。

符号	含义	举例及说明
$=$	被定义为
$+$	与	$x = a + b$ ，表示 $x$ 由 $a$ 和 $b$ 组成
$\cdots \| \cdots ]$	或	$x = [a ∣ b]$ ，表示 $x$ 由 $a$ 和 $b$ 组成
$}\{ \cdots\ \cdots \}$	重复	$x={a}$ ，表示 $x$ 由 $0$ 个或多个 $a$ 组成

加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3 种。

需求定义

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

需求定义方法

严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上:所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。
原型方法，迭代的循环型开发方式，需要注意的问题:并非所有的需求都能在系统开发前被准确地说明。项目于系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。特点:需要实际的、可供用户参与的系统型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求验证

需求验证:也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤:

需求评审:正式评审和非正式评审。
需求测试:设计概念测试用例。
需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

需求管理

定义需求基线:通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。需求的流程及状态如下图所示:
需求状态的变化

需求变更和风险

主要关心需求变更过程中的需求风险管理，带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
变更产生的原因:外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
变更控制委员会CCB:也称为配置控制委员会，其任务是对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。
在这里插入图片描述
双向跟踪，两个层次，如下图所示：

正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格（需求跟踪矩阵）来表示：

原始需求\用例	UC-1	UC-2	UC-3	......	UC-n
FR-1
FR-2
FR-3
......
FR-m

若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。

处理流程设计

数据流表示工具

程序流程图(Program Flow Diagram, PFD) 用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和和循环结构组合或嵌套而成。
IPO图也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。

N-S图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。
在这里插入图片描述
问题分析图（PAD）是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

业务流程重组BPR

BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。BPR设计原则、系统规划和步骤如下图所示:

在这里插入图片描述

业务流程管理BPM

BPM是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造，而是根据现有流程的具体情况，对流程进行规范化的设计。
流程管理包含三个层面:规范流程、优化流程和再造流程。

业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。常用的业务流程建模工具有BPM，标杆瞄准，IDEF，Peti 网，DEMO。Peti网作为一种从流程的角度出发描述和分析复杂系统的模型工具，适用于多种系统的图形化、数学化建模工具

6. 系统设计

系统设计主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。

系统设计方法：结构化设计方法，面向对象设计方法

系统设计的主要内容：概要设计、详细设计。

概要设计基本任务：又称为系统总体结构设计，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。

详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。

系统设计基本原理

抽象化
自定而下，逐步求精
信息隐蔽
模块独立（高内聚，低耦合）

系统设计原则

保持模块的大小适中
尽可能减少调用的深度
多扇入，少扇出
单入口，单出口
模块的作用域应该在模块之内
功能应该是可预测的。

内聚&耦合

系统设计基本原理:抽象、模块化、信息隐蔽、模块独立。
衡量模块独立程度的标准有两个:耦合性和内聚性。内聚程度从低到高如下表所示：

内聚分类	定义	记忆关键字
偶然内聚	一个模块内的各处理元素之间没有任何联系	无直接关系
逻辑内聚	模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能	逻辑相似、参数决定
时间内聚	把需要同时执行的动作组合在一起形成的模块	同时执行
过程内聚	一个模块完成多个任务，这些任务必须按指定的过程执行	指定的过程顺序
通信内聚	模块内的所有处理元素都在同一个数据结构上操作，或者各处理使用相同的输入数据或者产生相同的输出数据。	相同数据结构、相同输入输出
顺序内聚	一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入	顺序执行、输入为输出
功能内聚	最强的内聚，模块内的所有元素共同作用完成一个功能，缺一不可。	共同作用、缺一不可

耦合程度从低到高如下表所示：

耦合分类	定义	记忆关键字
无直接耦合	两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，不传递任何信息。	无直接关系
数据耦合	两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递	传递数据值调用
标记耦合	两个模块之间传递的是数据结构	传递数据结构
控制耦合	一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择的执行模块内的某一功能	控制变量、选择执行某一功能
外部耦合	模块间通过软件之外的环境联合（如 I/O 将模块耦合到特定的设备、格式、通信协议上）时。	软件外部环境
公共耦合	通过一个公共数据环境相互作用的那些模块间的耦合	公共数据结构
内容耦合	当一个模块直接使用另一个模块的内部数据，或通过非正常入口转入另一个模块内部时。	模块内部关联

人机界面设计

人机界面设计三大黄金原则：

置于用户控制之下
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 提供灵活的交互
- 允许用户交互可以被中断和撤消
- 当技能级别增加时可以使交互流水化并允许定制交互
- 使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直觉性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式揭示信息
保持界面的一致性
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它

7. 测试基础知识

测试原则和方法

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试原则

应尽早并不断的进行测试；
测试工作应该避免由原开发软件的人或小组承担;
在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果;
既包含有效、合理的测试用例，也包含不合理、失效的用例;
检验程序是否做了该做的事，且是否做了不该做的事;
严格按照测试计划进行;
妥善保存测试计划和测试用例;
测试用例可以重复使用或追加测试。

测试方法

软件测试方法可分为静态测试和动态测试。
静态测试:指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括桌前检查、代码审查、代码走查的方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。
动态测试:指在计算机上实际运行程序进行软件测试，一般采用自盒测试和黑盒测试方法。

黑盒测试法:功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
自盒测试法:结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

测试阶段

单元测试
也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或00软件中的类(统称为模块)，测试依据是软件详细设计说明书。
集成测试
目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。
确认测试
主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型:
1. 内部确认测试:主要由软件开发组织内部按照SRS进行测试。
2. Alpha测试:用户在开发环境下进行测试。
3. Beta测试:用户在实际使用环境下进行测试，通过该测试后，产品才能交付用户。
4. 验收测试:针对SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。
系统测试
测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法;性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
配置项测试
测试对象是软件配置项，测试目的是检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间，应确认被测软件配置项已通过单元测试和集成测试。
回归测试
测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

测试策略

自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。

测试用例的设计

黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码由此设计出测试用例，分为下面几类:

等价类划分:把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则:设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止;设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
边界值划分:将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0,150,-1, 151四个。
错误推测:没有固定的方法，凭经验而言，来推测有可能产生问题的地方作为测试用例进行测试。
因果图:由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。

白盒测试用例:知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从低至高分为下面几种:

语句覆盖SC:逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
判定覆盖DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
条件覆盖CC:针对每一个判断条件内的每一个独立条件都要执行一遍真和假。
条件判定组合覆盖CDC:同时满足判定覆盖和条件覆盖。
路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。

在这里插入图片描述

调试

测试是发现错误，调试是找出错误的代码和原因。
调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
调试的方法有:蛮力法、回溯法(从出错的地方开始，向回找)、原因排除法(找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法)。

软件度量

软件的两种属性:外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
McCabe度量法:又称为环路复杂度，假设有向图中有向边数为 $m$ ，节点数为 $n$ ，则此有向图的环路复杂度为 $m - n + 2$
注意 $m$ 和 $n$ 代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边(连线)就是一条有向边，每一条语句(语句框)就是一个顶点。

9. 净室软件工程

净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。

在净室软件工程背后的哲学是:通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

净室软件工程(CSE)的理论基础主要是函数理论和抽样理论。

净室软件工程应用技术手段:

统计过程控制下的增量式开发。
基于函数的规范与设计。
正确性验证。CSE的核心。
统计测试和软件认证。

净室软件工程在使用过程的一些缺点:

CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。
CSE 开发小组不进行传统的模块测试，这是不现实的。
CSE也会带有传统软件工程的一些弊端。

10. 基于构件的软件工程

基于构件的软件工程(CBSE)是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于己有构件的组装。用于CBSE的构件应该具备以下特征。

可组装型:对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
可部署性:软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
文档化:构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
独立性:构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
标准化:构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。构件模型定义了构件实现、文档化以及开发的标准，其包含的模型要素为:
- 接口。构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
- 使用信息。为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。
- 部署。构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体部署信息中包含有关包中内容的信息和它的二进制构成的信息。

构件模型

构件模型提供了一组被构件使用的通用服务，这种服务包括以下两种。

平台服务，允许构件在分布式环境下通信和互操作。
支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务，
中间件实现共性的构件服务，并提供这些服务的接口。

CBSE过程是支持基于构件组装的软件开发过程，过程中的6个主要活动:系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。

CBSE过程与传统软件开发过程不同点

CBSE过程与传统软件开发过程不同点:

CBSE早期需要完整的需求，以便尽可能多地识别出可复用的构件。
在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。
在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
开发就是将已经找到的构件集成在一起的组装过程。

构件组装

构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式。

顺序组装。通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件如上一个构件输出作为下一个构件的输入。
层次组装。这种情况发生在一个构件直接调用自另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。二者之间接口匹配兼容。
叠加组装。这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。

构件组装的三种不兼容问题(通过编写适配器解决)：