Welcome to Aoki's Blog!
"吾生也有涯，而知也无涯"-
软件工程相关名词解释
软件工程相关名词解释
\1. 软件：
一般认为，程序是计算机为完成特定任务而执行的指令的有效集合。站在应用的角度可以通俗地理解为：
面向过程的程序=算法+数据结构
面向对象的程序=对象+消息
面向构件的程序=构件+构架
通常，软件有以下定义：
软件=程序+数据+文档
这里的“程序”，是对计算机任务的处理对象和处理规则的描述；这里的“文档”，是为了理解程序所需的详细描述性资料；这里的“数据”，主要是软件系统赖以运行的初始化数据。
软件的最新定义如下：
软件=知识+程序+数据+文档
定义中增加了“知识”。这里的“知识”,主要指各种各样的相关行业领域的专业知识。实际上，知识只是网络的外在表现，程序，数据，文档才是网络的内在实质。也就是说，知识是通过程序、数据、文档来实现的。
对这一定义的另外一种解释是，软件到底是什么呢？软件就是网络，网络就是知识，知识就是信息。站在网民的角度看，软件就是知识加信息。站在程序员角度看，软件就是程序加数据；站在软件管理者角度看，软件就是数据加文档。
网络是知识的载体，知识是网络的灵魂。
\2. 软件工程
软件工程是研究软件开发和管理的一门学科。
这里，以是强调开发。开发是软件工程的主体，开发是在规定的时间、按照规定的成本，开发出符合规定质量要求的软件。二是强调管理或过程管理。当然，开发中有管理，管理是为了更好地开发。所以开发和管理是一个问题的相辅相成的两个方面。许多软件项目的失败，不是在开发技术上出了问题，二是在管理过程上出了问题。所以在某种程度上说，对于一个软件企业，过程管理比开发技术更重要。三十强调工程。要将软件的开发（包括维护）当成一项工程，既要按照工程的办法去开发，又要按照工程的办法去管理。四是强调学科。时至今日，软件工程不止是一门课程，而是一个学科体系，即软件工程知识体系。
\3. 软件工程学科体系（swebok2004）：
软件工程作为一个学科体系，到21世纪初才初步形成。2001年4月18日，美国发布了软件工程知识体系指南SWEBOK（guide to the Software Engineering body of Knowledge）0.95版。2004年，软件工程学科体系的内容才基本确立，就在这一年，美国ACM和IEEE-CS联合制订了SWEBOK2004版，它将软件工程学科体系的知识划分为如下10个知识域：
（1）软件需求：软件需求是真实世界中的问题而必须展示的特性。软件的需求知识域有7个子域：需求基础、需求过程、需求获取、需求分析、需求规格说明、需求确认、实践考虑。
（2）软件设计：软件设计既是定义一个系统的体系结构，组件，接口和其他特征的过程，又是这个过程的结果，软件设计知识域有6个子域：软件设计基础，软件设计关键问题，软件结构与体系结构，软件设计质量的分析与评价，软件设计符号，软件设计的策略与方法。
（3）软件构造：它指通过编码，验证，单元测试，集成测试和排错的组合，具体创建一个可以工作的，有意义的软件。其知识域有3个子域：软件构造基础，管理构造，实际考虑
（4）软件测试：它由在有限测试用例集合上，根据期望的行为对程序的行为进行的动态验证组成，测试用例是从实际上无限的执行域中适当选择出来的。软件测试知识域有5个子域：软件测试基础和测试级别，测试技术，需求分析，与测试相关的度量，测试过程。
（5）软件维护：软件一旦投入运行，就可能出现异常，运行环境可能发生改变，用户会提出新的需求。生命周期中的软件维护，从软件交付时开始。软件维护的知识域有4个子域：软件维护基础，软件维护的关键问题，维护过程，维护技术。
（6）软件配置管理：软件配置是为了系统地控制配置的变更，维护软件在整个系统生命周期中的完整性及可追踪性，而标志软件在不同时间点上的配置的学科。软件配置管理知识域有6个子域：软件配置管理过程管理，软件配置标志，软件配置控制，软件配置状态统计，软件配置审核，软件发行管理和交付。
（7）软件工程管理：进行软件工程的管理与度量，虽然度量是所有知识域的一个重要方面，但是这里所说的是度量程序的主体。软件工程管理只是域有6个子域：启动和范围定义，软件项目计划，软件项目实施，评审与评价，关闭，软件工程度量。前5个覆盖软件过程工程管理，第6个描述软件度量的程序。
（8）软件工程过程：涉及软件工程过程本身的定义、实现、评定、度量、管理、变更和改进。软件工程过程知识域有4个子域：过程实施与改变、过程定义、过程评定、过程和产品度量。
（9）软件工程工具和方法：它具有软件工程工具、软件工程方法两个子域。
（10）软件质量：处理跨域整个软件生命周期过程的软件质量的考虑，由于软件质量问题在软件工程中无处不在，其他知识领域也涉及到质量问题。软件质量知识域有3个子域：软件质量基础，软件质量过程、时间考虑。
在上述软件工程学科体系中前5个知识域是讲软件开发，后5个知识域是讲软件管理。由此可见，软件工程知识体系包括软件开发和软件管理两大部分，所以软件工程的定义也应该包括软件开发和软件管理两项内容。
\4. 软件工程课程
软件工程课程与软件工程学科体系是有区别的：前者是一门或一组课程，后者是一个知识体系；前者是一个局部问题，后者是一个整体问题。
作为一门软件工程客户才能，它研究的内容至今没有统一的说法。可以这么认为，软件工程课程研究的内容应该涵盖“软件生命周期模型、软件开发方法、软件支持过程、软件管理过程、软件工程标准与规范”这5个方面。
序号 研究方向 具体内容 1 软件生命周期模型 如：瀑布模型，增量模型 2 软件开发方法 如：面向过程的方法 3 软件支持过程 如：CASE工具ROSE，北大青鸟系统，Power Designer 4 软件管理过程 如：CMMI，软件企业文化，敏捷（XP）文化现象 5 软件工程标准与规范 如：命名标准与规范，设计标准与规范，编程标准与规范 尽管软件生命周期模型和软件支持过程非常重要，但是现代软件工程研究的重点，仍然是软件开发方法和软件管理过程。在软件管理过程的内容中，除了ISO9001的CMMI之外，还将软件企业文化也列入其中，如微软企业文化，敏捷文化现象和IBM企业文化。
软件工程标准是对软件产品的约束，如软件产品的界面标准，包装标准，文档标准，测试标准，评审标准，鉴定标准等。软件工程规范是对软件开发人员行为的约束，例如命名规范，需求规范，设计规范，编码规范，维护规范等。在软件企业内部，企业管理人员特别重视软件工程的标准与规范。为此，每个大型的软件企业，根据自身的特点，都制订并发布了自己的软件工程标准与规范，在自己企业内部严格执行。
\5. 软件工程基本原理
习惯上，人们常常把软件工程方法（开发方法）、工具（支持方法的工具）、过程（管理过程）称为软件工程三要素，而把美国著名的软件工程专家B.W Boehm于1983年提出的7条原理作为软件工程的基本原理。
（1） 用分阶段的生命周期计划严格管理软件开发。阶段划分为计划、分析、设计、编程、测试和运行维护。
（2） 坚持进行阶段评审。若上一阶段评审不通过，则不能进入下一阶段开发
（3） 实行严格的产品版本控制
（4） 采用现代程序设计技术
（5） 结果应能清楚地审查。因此，对文档要有严格的要求
（6） 开发小组的成员要少而精
（7） 要不断地改进软件工程实践的经验和技术，要与时俱进
上述7条原理，虽然是在面向过程设计时代（结构化时代）提出的，但是，直到今天，在面向元数据和面向对象的程序设计新时代，它仍有效。根据“与时俱进”的原则，还有一条基本原理在软件的开发和管理中特别重要，需要补充进去，作为软件工程的第8条基本原理。
（8） 二八定律
在软件工程中，所谓二八定律，就是一般人常常将20%的东西误认为80%的东西，而将80%的东西误认为是20%的东西。
例如，对软件项目进度和工作量的估计：一般人主观上认为已经完成了80%，但实际上只完成了20%；对于程序中存在问题的估计，：一般人不知道80%的问题存在于20%的程序之中；对模块功能的估计：一般人不知道20%的模块，实现了80%的功能；对人力资源的估计：一般人不知道20%的人，解决了程序中80%的问题；对投入资金的估计：一般人不知道信息系统中80%的问题，可以用20%的资金来解决。
研究二八定律的现实意义是，指导软件计划的制订与执行。
\6. 软件生命周期模型
软件生命周期模型时指在整个软件生命周期中，软件开发过程应该遵循的开发路线图。或者说，软件生命周期模型是软件开发全部过程、活动和任务的结构框架。
例如：瀑布模型、增量模型、螺旋模型、喷泉模型、XP模型、原型模型和RUP迭代模型，它们都有各自清晰的开发路线图，规定了各自的开发过程、活动和任务的结构框架。
从字面上理解，“软件生命周期”应该涵盖软件产品、项目或系统从产生、投入使用看到被淘汰的全过程。由于早期人们关注的是技术开发活动，还没有考虑到管理活动，因此“软件生命周期模型”主要描述的还是软件开发的过程及其任务。
与人不同的是，软件的生命周期和软件生命周期模型有关：不同的软件生命周期模型，可能对应着不同的生命周期。生命周期不同，该软件的开发阶段划分、评审次数、基线标准都有所不同。软件公司的项目组在开发一个大项目或产品时，首先在技术上必须选择一个软件生命周期模型，使该模型非常适合这个项目或产品的生命周期模型；随后通过对软件生命周期模型的裁剪，给出适用于本项目或产品的软件生命周期定义；以生命周期定义为标准，在需求定义之后，编制详细的软件开发计划；然后项目组按计划进行软件开发，软件工程管理部门按计划进行软件过程跟踪和管理。
软件生命周期模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。一般以时间为序，软件生命周期模型可详细地划分为9个阶段。
序号 周期名称 序号 周期名称 1 立项（或签合同）、下达任务书 6 软件测试 2 需求分析 7 软件发布与实施 3 概要设计 8 软件维护 4 详细设计 9 版本更新或退役 5 编码实现 软件开发方法是指在软件工程开发路线图中，开发人员对软件需求、设计、实现、维护所采用的开发思想开发技术、描述方法、支持工具等。
软件工程中软件开发方法的集合，称为软件工程方法论。
\7. 迭代模型及其9个核心流程
针对瀑布模型的缺陷，人们提出了迭代模型。
所谓迭代，是指活动的多次重复。从这个意义法伤来讲，原型不断完善，增量不断产生，都是迭代的过程。因此，快速原型法和增量模型都可以看成局部迭代模型。但这里所讲的迭代模型时RUP推出的一种“逐步求精”的面向对象的软件开发过程模型，被认为是软件界迄今为止最完善、可实现商品化的开发过程模型。
RUP模型的原型图看起来非常简单，其内涵却非常丰富。它表面上是一个二维图，实质上用一张二维图表示了一个多维空间模型。从宏观上看，它是一个大的迭代过程；横坐标表示软件产品所处的4个阶段：先启、精化、构建、产品化（移交），纵坐标表示软件产品在每个阶段的工作流程。从微观上看，任何一个阶段本身，其内部工作流程也是一个小的迭代过程。
为使项目能够顺利地进行，一种较灵活（并且风险更小）的方法是：多次执行各个开发工作流程，从饿了更好地理解需求，设计出更为强壮的软件架构，逐步提高开发组织能力，最终交付一系列逐步完善的实施成果，这就是迭代生命周期模型。每次按顺序完成一系列工作流程就称为一次迭代，每次迭代，均以次要里程碑结束，按照特定的迭代成功标准，对迭代的结果进行评估。每个阶段都可以进一步细分为迭代。迭代是产生可执行的产品发布（内部或外部的）的完整开发循环，所发布的产品是开发过程最终产品的子集，它将通过一次又一次的迭代实现递增成长，最后形成最终的软件系统或产品。
优点：
n 在开发的早期或中期，用户需求可以变化；
n 在迭代之初，不要求有一个相近的产品原型
n 模型的适用范围很广，几乎适用于所有项目的开发
缺点：传统的组织方法是按顺序（一次且仅一次）完成每个工作流程，即瀑布式生命模型。迭代模型采取循环工作方式，每次循环均使工作产品更靠近目标产品，这要求项目组成员具有很高的水平并掌握先进的开发工具。反之，存在较大的技术和技能风险。
模型的9个核心流程：
迭代声明周期模型包含9个核心流程（需要指出的，采用迭代模型，事先要有一个初始业务模型，以便进行迭代。这就是为什么将“业务建模”作为9个核心流程之首的道理）。
（1） 业务建模：目的是， 了解目标组织的结构和机制；了解目标组织中当前存在的问题，并确定改进的可能性；确保客户、最终用户和开发人员就目标组织达成共识；导出支持目标组织所需的系统需求。通俗地讲，业务建模就是用户业务流程的重新规划与合理改进，即业务流程的优化，目的是使开发出来的系统能反映最优化的业务流程。
（2） 需求获取：目的是，与客户在系统的工作内容方面达成并保持一致；使系统开发人员能够更清楚地了解系统需求；定义系统边界；为计划迭代的内容提供基础；为估算开发系统所需成本和时间提供基础；定义系统的用户界面，重点是用户的需要和目标。
（3） 分析设计：目的是，将需求转换为未来系统的设计；逐步开发强壮的系统构架；使设计适合实施环境，为提高性能而进行设计。
（4） 实施：目的是，对照实施子系统的分层结构定义代码结构；以构件（源文件，二进制文件，可执行文件以及其他文件等）方式实施类和对象；对已开发的构件按单元进行测试；将各实施成员（或团队）完成的结果集成到可执行系统中。
（5） 测试：目的是，核实对象之间的交互；核实软件的所有构件是否正确集成；核实所有需求是否已经正确实施；确定缺陷并确保在部署软件之前将缺陷解决。
（6） 部署：目的是，将构件部署到网络的各个节点上，使最终用户可以使用该软件产品。
（7） 配置与变更管理，目的是，始终保持工作产品的完整性和一致性
（8） 项目管理：目的是，为软件密集型项目的管理提供框架；为项目计划，人员配备，执行和检测提供实用准则；为风险管理提供框架。
（9） 环境：目的是，为软件开发组织提供软件开发环境（流程和工具），该环境将支持开发团队。
\8. XP模型
XP模型，即极限编程模型，它本来是敏捷企业文化现象，但是不少人将它当成一种软件开发模型。
对传统软件开发模型进行重新审视发现，它们太正规、太呆板、太浪费资源，从而提出了省时省力的XP模型。它属于轻量级开发模型，由一组简单规则（需求、实现、重构、测试、发布）组成，它既保持开发人员的自由创造性，又保持对需求变动的适应性，即使在开发的后期，也不怕用户需求的变更。
在需求、实现、重构、测试、发布的迭代过程中，XP模型有4条核心原则：交流、简单、反馈和进取。XP开发小组包括开发人员、管理人员和客户。
优点：
l 采用简单策略，不需要长时间计划和复杂管理，开发周期短
l 采用迭代增量开发，反馈修正和反复测试的方法，因而软件质量有保证。
l 适应用户需求变化，因而与用户关系和谐。
缺点： XP模型作为一种新的模型，在实际应用中还存在一些问题，引起了一些争议。它一般适用于小型项目，同时，它与ISO9001、CMMI的精神也存在冲突。
\9. 订单软件
与固定的用户签订软件开发合同，由软件公司启动该项目的开发，这类软件被称为“订单软件”，典型的例子有企业资源规划系统ERP和电子商务大型网站。
\10. 非订单软件
市场调研之后，认为某产品将会有巨大的市场空间，而软件公司在人力资源、设备资源、抵抗风险、资金和时间上都具备开发该产品的能力，于是决定立项，这类软件被称为“非订单软件”，典型的例子是网上游戏软件
\11. 任务书
有一份《任务书》的正文。包括任务下达的对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理（技术经理和产品经理）、其他保证措施、奖惩措施等。《任务书》正文可长可短，若《合同》或《立项建议书》很详细，则正文可短，若《合同》或《立项建议书》很粗很短，则正文应该很长、很详细。
有一份《任务书》的附件。一般情况下，它就是软件《合同》/《立项建议书》，如果是指令性计划，它的格式和内容，也应与《合同》/《立项建议书》基本相同，即附件的内容应覆盖系统的功能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。
《任务书》与《合同》/《立项建议书》一样重要，它是该项目的第二份管理文档。
\12. 合同
对于一些大型项目，在签订合同之前，一般有一个招标和投标的过程，只有中标之后才能签订合同。开发“非订单软件”需要“立项”，开发“订单软件”需要签订“合同”。所以“立项”与“合同”是IT企业软件项目（或产品）的两个源头。一旦立项或签订合同，企业领导或软件管理部门就要下达《任务书》，开发部门接到《任务书》后就要组建开发团队，成立项目组。
\13. 立项建议书
立项文档就是《立项建议书》，它本身不是软件策划的内容，但是很重要，也很特殊。《立项建议书》的目的，就是在某种程度上代替开发合同或用户需求报告，作为软件策划的基础。《立项建议书》的编制者一般不是软件开发人员，而是软件公司的市场销售人员，因为他们熟悉市场行情及客户需求
\14. 需求分析
1997年，IEEE软件工程标准词汇表中定义的需求为：
（1） 用户解决问题或达到目标所需的条件或能力
（2） 系统或系统部件要满足合同、标准、规范或其他正式规定文档所具有的条件或能力
（3） 一般反映（1）或（2）所描述的条件或能力的文档说明
一般而言，需求分析阶段位于软件开发的前期，它的基本任务是准确地定义未来系统的目标，确定为了满足用户的需要系统必须做什么。
需求分析分为两个阶段：需求获取阶段和需求规约阶段。需求关系的是系统的目标而不是系统实现。
需求可以分为两类：功能性需求和非功能性需求。前者定义了系统做什么，后者定义了系统工作时的特性。
\15. 基线
基线是软件工作产品，它是要经内部和外部评审过的，是下一阶段工作的基础。
\16. 审计
审计，是复查评审活动程序的合法性，是否按程序与规范进行等
\17. 里程碑
里程碑是一个标记，只需要经过内部评审。一个里程碑是一个检查点，但不一定对应一条基线
\18. 定义软件过程
所谓定义软件过程，就是根据选定的生命周期模型，规定软件的开发1模型，以及每一阶段的工作步骤和文档标准等内容。
在项目策划阶段，先要根据项目特性，使用软件生命周期模型，对项目中将要进行的软件工程过程进行描述。根据项目自身的特点，对项目的类型进行详细划分，然后根据软件组织的“生命周期模型裁剪指南”，对标准软件过程进行裁剪，形成项目定义软件过程。再使用项目定义软件过程，指导项目策划活动的进行。
开发计划是对项目定义软件过程的具体描述。软件项目的规模、工作量、成本、进度、质量、人员配置和其他资源等，与项目定义软件过程中的活动紧密相关。由于项目定义软件过程的标准，全部由“生命周期模型裁剪指南”而得到，因此软件项目能共享过程数据，并且吸取软件组织中积累的经验教训。
\19. LOC
LOC（line of code），LOC指所有的可执行源代码行数。包括可交付的工作控制语言（job control language，JCL）语句，数据定义，数据类型声明，等价声明，输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。
\20. 功能模型
（Function Model, FM）。实质上是用户需求模型，用来描述系统能做什么，即对系统的功能，性能，接口和界面进行定义。
\21. 业务模型
（Operation Model，OM），实质上是业务逻辑模型，用于描述系统在何时，何地、由何角色、按什么业务规则去做，以及做的步骤或流程，即对系统的操作流程进行定义。
\22. 数据模型
（Data Model, DM）,实质上是实体或类的状态关系模型，用于描述系统工作前的数据来自何处，工作中的数据暂存在什么地方，工作后的数据放到何处，以及这些数据的状态以及相互之间的关联，即对系统的数据结构进行定义。
\23. 风险分析
软件策划过程，也包括对软件风险进行分析。所谓软件风险分析，指对项目及团队的政策风险、技术风险、技能风险、资源风险等因素，进行逐个分析与分解，将一个大风险分解为若干个小风险，对各个小风险进行排除，最后制订跟踪和监控风险的风险管理计划。软件一般存在5种风险，如下表：
序号 风险名称 风险内容 1 政策风险 IT企业外部和IT企业内部两个方面的政策及政策的变化，将会给项目带来什么风险 2 技术风险 新技术的成熟程度以及难度系数，将会给项目带来什么风险 3 技能风险 项目组成员学习、领会、掌握、运用新技术的能力，将会给项目带来什么风险 4 资源风险 保证项目正常进行所需的各种资源的供应程度，将会给项目带来什么风险 5 其他风险 目前意想不到的风险，即不可预测的风险，如天灾人祸 \24. 三层结构设计
三层结构设计通常被划分为表示层、中间层和数据层三层，各个分层之间通过对外接口互相访问。分层的主要目的是，允许各层可以随着需求的变化或技术的变化而独立地升级或替换，如当替换数据库时，只需要变化数据层。
所谓的三层结构，就是在原来两层结构（Client/Server）的客户层和数据层之间，加入一个中间层（也叫业务层），并将应用程序的业务规则、数据访问、合法型校验等工作放到了中间层进行处理，这样就变成了三层结构，也不仅仅有B/S应用才是三层结构，三层是指逻辑上的三层，即使这三层都放置到了一台机器上。当然，这三层也可以放在两台或三台机器上。
（1） 表示层（浏览层）
表示层也称为浏览层，它通常采用图形化用户界面，在客户端PC或工作站上运行。站在“三个模型”建模思想上看，系统内部支持表示层的模型是“功能模型”，尽管“功能模型”中的功能思想组件放在业务层，但是功能组件的表现方式却在表示层上。该层的主要功能是：
1）接受用户请求，将这些请求反馈给业务逻辑层，等待业务逻辑层的应答信息
2） 对业务逻辑层的应答信息，进行显示（不进行任何加工） 3） 有时也会兼做业务逻辑层的一些小功能，比如对用户输入数据的验证，以及操作合法性的检验
（2） 中间层（业务层）
中间层也称业务层，有时又称为应用层，它由许多构建或组件组成，它们完全体现了用户的业务逻辑或业务规则。站在“三个模型”建模思想看，系统内部支持业务层的模型是“业务模型”。尽管Java EE与.NET在实现业务层上的方法略有差异，但是，业务层本质上在表示层与数据层之间起桥梁作用。有时，业务层被划分为两个子层：业务逻辑层和数据访问层。业务层的主要功能是：
1） 接受从表示层传来的用户请求信息
2） 根据用户的请求信息生成SQL语句
3） 利用生成的SQL语句从数据层取数据、修改数据、删除数据
4） 将结果返回给表示层
（3） 数据层
数据层是数据库服务器上的数据库层，它包括数据库管理系统DBMS和数据库DB两部分。站在“三个模型”建模思想看，系统内部支持数据层的模型是“数据模型”，该层的主要功能是：
1）接受业务层数据处理请求的SQL语句或存储过程
2） 利用SQL语句或存储过程，对数据库服务器上数据库的相关表进行存储或检索
3） 将存储或检索的结果信息，传递给业务层
\25. 构件
所谓构件，就是被标识的且可被复用的软件制品。
构件与部件，组件基本上是一个意思，有时会认为部件和组件的粒度比构件大一些或范围更广一些。上述定义有三个特点：第一个特点是构件要被明确标识，即有一个被调用的名字；第二个特点是应该可服用，不可复用的只能称为模块或子系统，第三个特点是构件是软件制品，在宏观上软件制品可以是项目计划、成本估价、体系结构、需求模型、设计模型、程序代码、窗口界面、文档、数据结构、测试用例等。
\26. 中间件
中间件是一个非常大的组件（构件），一般在网络上运行，完成批量数据的传递和通信工作，调用方式是通过一组事先约定的格式与参数进行的。常见的中间件为问价传输中间件，如IBM公司的消息队列中间件MQ，在网络节点之间进行点对点的数据通信和传输。又如城市医疗保险系统中的中间件，它在市医保局节点和全市各家医院节点之间，进行点对点的数据通信和传输，病号每次划价计费，节点之间就交换一次信息。在详细设计说明书中已对新增中间件的功能和算法进行了详述，此处只要将详细设计翻译为源程序即可。
\27. 结对编程
在敏捷方法中，成对（或结对）编程时极限编程的实践之一。当进行成对编程时每一个程序员输入代码，另一个在旁边观察代码中是否存在错误，并思考下一步要进行的工作。
优点：
1） 可以提高代码的可读性和可理解性，产生高质量的代码
2） 提高编程效率，使编程速度更快，代码错误更少，后期测试和纠错的工作量就会大大降低
3） 成对编程可以提高开发团队的凝聚力和协作精神
规则：
1） 编码标准
2） 积极参与
3） 非强制性
4） 定期轮换
5） 速度匹配
6） 新老匹配
\28. 软件测试
软件测试按照规定的测试规程发现软件缺陷的问题。
为了理解这个定义，有如下解释：
1） 软件测试是一个过程，而且是一个发现软件缺陷，但不包括修复软件缺陷的过程。
2) 软件测试是按照规定的测试规程进行。这些规程包括制定测试计划，搭建测试环境，明确测试任务，规定测试时间、方法和步骤，记录测试数据和产生测试报告
3) 在测试规程中，测试计划最为重要，它指导整个测试计划
4) 在测试计划中，测试需求的定义很重要。如果没有列出明确的测试需求，那么就并不会设计出正确的测试用例，最后必然导致盲目的测试。这样，隐藏的软件缺陷也无法被发现。
5) 软件测试的目的是发现软件缺陷，软件测试的目标是尽可能早地发现软件缺陷，因为缺陷发现越早，其修复成本越低。
软件测试不仅仅局限于测试程序代码，还可以测试软件数据与软件文档。也就是说，软件生命周期中所产生的软件工作产品，都可以作为测试对象，因为它们影响最终软件产品的质量。
\29. 软件缺陷
定义如下：
软件未实现产品说明书要求的功能。
软件出现产品说明书指明不应该出现的错误
软件实现了产品说明书未说明的功能
软件未实现产品说明书虽未明确提及但应该实现的目标
软件难以理解，不易使用，运行速度慢，或者软件测员，最终用户认为软件不好。
由于不同的理解方式和中英文翻译问题，软件缺陷的说法很多，如错误、失效、失败等，本书中统称为软件缺陷（bug）。实际测试中，将软件缺陷定义为不同级别，代表不同程度的软件缺陷。
随着软件定义的变化，软件缺陷的定义也应随之更新。软件缺陷不仅仅局限于软件代码，还包括文档缺陷（不符合规范或者不详细，有错误和歧义等）、测试缺陷（测试不充分，或测试方法本身的局限）、过程缺陷（软件生命周期的流程问题造成的产品质量问题）和管理缺陷（由于管理本身不到位导致的产品质量问题）。
\30. 软件测试的V模型
早期的软件测试V模型
模型的左侧是开发阶段，右侧是测试阶段。开发阶段从了解并定义软件需求开始，然后要把需求转换到概要设计和详细设计，最后形成程序代码。测试阶段是在代码编写完成之后，先做单元测试，然后做集成测试、系统测试和验收测试。
单元测试：主要检测代码的编写是否符合详细设计中单个模块或组件的要求
集成测试：主要检测此前测试过的单个模块或组件，能否正确地集成到系统，与其他模块一起运行，是否符合概要设计和详细设计说明书的要求。
系统测试：以集成后的完整系统作为测试对象，主要检测其是否符合需求说明书、概要设计说明书和详细设计说明书的要求。
验收测试：主要检测软件产品是否符合用户需求，用户合同和需求说明书中的要求，需要得到用户认可并签字确认。
改进后的V模型：
改进后的V模型，一是加入软件测试分析和测试设计阶段，二是体现“尽早”思想。改进后的V模型，形成了一个没有软件开发过程的、单独的软件测试V模型。它的左边是软件测试需求分析和测试设计，右边是软件测试执行。虽然测试执行过程同样集中在软件编码之后，但是测试需求分析和测试设计已经提前，一直提前到与开发阶段并行开展。一方面可以为后期的测试执行过程做计划和准备，另一方面可以对软件的阶段性产品（软件工作产品）进行测试。前期的软件工作产品主要是文档，如测试需求分析阶段，就是测试软件需求分析过程的工作产品《需求规格说明书》，进而提炼出测试需求。
\31. 黑盒测试
黑盒测试又称为不透明盒测试，它给我们的更多启示是它的思考方式，即不考虑（主观上屏蔽）或者不需要（客观条件限制）知道被测对象的内部实现细节，只关心输入输出。在运用黑盒测试方法进行软件测试时，它并不关心软件的内部逻辑结构和实现方法，而是站在使用者的角度，主要测试软件的功能指标，即测试系统的功能模型。黑盒测试的依据是软件的行为描述，是面向功能的穷举输入测试。从理论上讲，只有把所有可能的行为都作为测试用例输入，才能完成黑盒测试工作。黑盒测试的对象可以是软件单元、软件模块、软件组件、软件子系统和软件系统，也可以是发散思维到软件文档，软件管理文档等软件生命周期中的任何可测试对象。
黑盒测试用例设计方法：
（1） 等价类划分法
（2） 边界值分析法
（3） 错误推测法
（4） 因果图分析法
（5） 场景分析法
\32. 白盒测试
白盒测试又称为透明盒测试，要求测试人员必须清楚被测对象的内部实现细节。白盒测试方法的测定依据是《详细设计说明书》。理论上讲，面向程序执行路径进行穷举代码测试，直至覆盖所有路径，才算完成了白盒测试。白盒测试的测试对象，侧重于软件单元，模块和构件等小规模对象，绝对不适合软件项目或产品的等大规模测试对象。
实用的白盒测试覆盖技术有4种，即语句覆盖，条件覆盖，分支覆盖和组合覆盖。覆盖的主要思想，是从不同角度尽可能提高代码的测试覆盖率。为了减少测试工作量，应该使每一个测试用例满足多个覆盖条件。
\33. 等价类
等价类划分的具体做法是：把所有可能的输入数据，即软件的输入域，划分成若干部分（子集），使每部分内的数据都是等效的（对于软件而言，等效可以理解为对数据的处理过程以及处理结果都完全一致），然后从每一个子集中选取少数具有代表性的数据，作为测试用例。
每一个等价类又可以划分为两种不同类别：有效等价类和无效等价类。
\34. 边界值
边界值分析方法是对等价类划分方法的补充。
测试工作者已经总结出经验：大量的错误常常发生在输入或输出范围的边界上，因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例使，首先参考等价类划分法确定边界情况，除了在等价类中选取典型代表数据外，通常还要着重测试边界值情况，应当选取正好等于、刚刚大于、或刚刚小于边界的值作为测试数据。
\35. 测试需求
它指软件测试员站在与用户相同角度上理解的需求，主要是确保需求的可测试性。同时找出软件需求和用户需求的偏差，并确保认可的偏差修改后体现在软件需求中，因为测试工作以《软件需求说明书》为基准，测试人员需要尽量保证《软件需求说明书》可以满足测试工作。
\36. Bug
即软件缺陷，如错误，失效，失败等。
\37. CMMI
软件能力成熟度模型CMMI，是由美国卡内基-梅隆大学软件工程研究所退出的评估软件能力与成熟度等级的一套标准。该标准基于众多软件专家的实践经验，侧重于软件开发过程管理能力的提高，是软件生产过程改进的标准和软件企业成熟度等级评估的标准。由于该标准不涉及具体的软件开发方法和技术，所以它具有广泛性、通用性和持久性。
CMMI的作用：概括地讲，过程能力成熟度模型集成CMMI的作用，主要是软件组织的能力评估和过程改进，它的应用领域具体体现在三个方面：
软件组织，用它来不断改进自身的软件过程管理能力
评估机构，用它来评估某软件组织当前软件能力成熟度级别
客户，用它来评价某承包商（软件外包商）的软件能力
CMMI的实质：
为了真正达到持续改进软件过程能力的目的，并以尽量低的成本获得高的效益，首先要弄清楚“过程”、“项目”、“组织”、“度量”等五个基本概念。
以“过程”为核心，抓软件组织的管理，即软件“组织”的过程改进
以“项目”为手段，抓团队开发过程的“活动”，即落实过程改进的措施
以“活动”记录为基础，抓软件过程的“度量”，即“度量”软件组织改进的情况
\38. 软件配置管理
软件配置管理SCM，是对软件开发过程中配置项的一组追踪和控制活动，它开始于软件开发之初，结束于软件淘汰之时。软件配置管理在软件过程管理中，占有特殊得到地位，也是项目管理的重要内容。无论是ISO9001、CMMI，还是软件企业文化，都非常强调配置管理。在大中型软件企业内部设置专职的配置管理员，在各个项目组内部设置兼职的配置管理员，引进配置管理电子工具，开展配置管理的日常工作。
\39. CMMI阶段的成熟度等级
阶段模型的5个等级，称为成熟度等级ML，从ML1级到ML5级。
CMMI的等级 PA数目 管理特点 ML1:Initial（初始级） 0 过程不可预测且缺乏控制 ML2：Managed（已管理级） 7 过程为项目服务，即项目级管理 ML3：Defined（以定义级） 11 过程为组织服务，即组织级管理 ML4:Quantitatively Managed(定量管理级) 2 过程已度量和控制，即定量级管理 ML5：Optimizing（优化级） 2 集中于过程改进，即优化级管理 \40. 极限编程
极限编程（即XP）是一个周密而严谨的软件开发流程。XP从4个基本方面对软件项目进行改善：交流、简单、反馈和进取。
XP程序员与客户交流、与同事交流；
他们的设计简单而干净；
他们通过测试来得到反馈；
他们根据变化修改代码，并争取尽可能早地将软件交付给客户。
在此基础上，XP程序员能够勇于面对需求变化和技术变化，“船小好调头”，对需求变化和技术变化做出敏捷反应，把那个取得成功，是敏捷文化的特色和本质。
\41. 软件质量管理的三大支柱
软件质量保证SQA是一个过程，是CMMI和ISO9001的重要议题，是微软公司和IBM公司的重点课题，同样也是项目管理的重要内容。
软件质量：是供方提供的软件产品满足用户明确和隐含需求的能力特性的总和。
通常，人们将“质量标准”、“配置管理”、“质量测试”作为质量管理的三大支柱。
而将”SQA计划”、“SQA进度”、“SQA评审和审计”作为质量管理三大要素。
软件质量保证是一个质量管理过程，基本思想是“以事先预防为主，以事后纠偏为辅”，采取标本兼治的方法。
The End
-
计算机网络概述
计算机网络概述
-
计算机网络体系结构
计算机网络体系结构
一、计算机网络分层结构
两个系统中实体间的通信是一个很复杂的过程，为了降低协议设计和调试过程的复杂性，也为了便于对网络进行研究、实现和维护，促进标准化工作，通常对及时算计网络的体系结构以分层的形式进行建模。
我们将计算机网络的各层及其协议的集合称为网络的体系结构。
网络设计者以分层的方式组织协议以及实现这些协议的网络硬件和软件，每个协议就属于这些层次之一。某层向它的上一层提供服务，即所谓每一层的服务模型。例如，第n层提供的服务可能包括报文从网络的一边到另一边的可靠传送。这可能是通过使用第n-1层的边缘到边缘的不可靠报文传送，加上第n层的检测和重传丢失报文的功能来实现的。
计算机网络的体系结构通常都具有可分层的特性，它将复杂的大系统分为若干个较容易实现的层次。分层的基本原则如下：
- 每次都实现一种相对独立的功能，降低大系统的复杂度
- 各层之间界面自然清晰，易于理解，相互交流尽可能少
- 各层功能的精确定义独立于具体的实现方法，可以采用合适的技术来实现
- 整个分层结构应该促进标准化工作
-
数据通信基础
数据通信基础 写在前面
物理层协议的主要任务就是确定与传输媒体的接口有关的一些特性，如下所述：
- 机械特性：指明接口所用接线器的形状和尺寸、引脚数目和排列、固定和锁定装置等。
- 电气特性：指明在接口电缆的各条线上出现的电压范围1.
- 功能特性：指明某条线上出现的某一电平代表何种意义。
- 过程特性：指明对于不同功能的各种可能事件的出现顺序。
一、数据通信的模型
一个数据通信系统可划分为三大部分，即源系统（或发送端，发送方）、传输系统（或传输网络）和目的系统（或接收方、接收端）。
源系统一般包括两部分：
- 源点：源点设备产生要传输的数据。
- 发送器：通常源点生成的数字比特流要通过发送器编码之后才能在传输系统中进行传输。
目的系统一般包括两部分：
- 接收器：接收传输系统传送过来的信号，并把它转换为能够被目的设备处理的信息。
- 终点：终点设备从接收器获取传送来的数字比特流，然后进行信息输出。终点又称为目的站或信宿。
在源系统和目的系统之间的传输系统可以是简单的传输线路，也可以是连接在源系统和目的系统之间的复杂网络系统。
通信的目的是传送消息。
数据是消息的实体。
信号是数据的电器或电磁表现。根据信号中代表的消息的参数的取值方式不同，信号可分为两类：
- 模拟信号（或连续信号）——消息的参数的取值时连续的
- 数字信号（或离散信号）——消息的参数的取值时离散的。在使用时间域的波形表示数字信号时，代表不同离散数值的基本波形就称为码元。在使用二进制编码时，只有两种不同的码元，一种代表0状态，另一种代表1状态。
速率、波特与带宽
速率也称为数据率，指的是数据的传输速率，表示单位之间内传输的数据量。可以用码元传输速率和信息传输速率表示。
- 码元传输速率。又称码元速率，波形速率等，它表示单位时间内数字通信系统所传输的码元个数，单位是波特（Baud）。1波特表示数字通信系统每秒传输一个码元。这里的码元可以是多进制的，也可以是二进制的，但码元速率与进制数无关。
- 信息传输速率。又称信息速率，比特率等。它表示单位时间内数字通信系统传输的二进制码元数（即比特数），单位是比特/秒（b/s).
二、编码与调制
-
常用编码方式
要利用信道传输数据，必须将数据转换为能在传输媒体媒体上传送的信号。信道可以分为传送模拟信号的模拟信道和传送数字信号的数字信道两大类。
将数字数据转换为数字信号的过程称为编码。
将数字信号转换为模拟信号的过程称为调制。
归零制：正脉冲代表1，负脉冲代表0；
不归零制：正电平代表1，负电平代表0；
曼彻斯特编码：位周期中心的是上跳变代表0，位周期中心的下跳变代表1；
差分曼彻斯特编码：在每一位的中心处始终有跳变。位开始边界有跳变代表0，而位边界没有跳变代表1；
-
基本的调制方法
矩形脉冲波形的数字信号包含从直流开始的低频分量，被称为基带信号
在数字信道上直接传输基带信号的方法称为基带传输
基带信号往往包含较多的低频成分，甚至直流成分。而许多模拟信道仅能通过某一频率范围的信号，不能直接传输这种基带信号。因此必须对基带信号进行调制，使它能够在模拟信道中传输。
在很多情况下，需要使用载波进行调制，把基带信号的频率范围搬移到较高的频段以便在信道中传输。经过载波调制后的信号称为带通信号，而使用载波的调制称为带通调制。
最基本的带通调制的方法有： 1）调幅（AM），即载波的增幅随基带数字信号而变化。
2）调频（FM），即载波的频率随着基带数字信号的变化而变化。
3）调相（PM），即载波的初始相位随基带数字信号而变化。
在数字通信中，调幅、调频和调相相应地称为幅移键控、频移键控和相移键控。实现调制和解调功能的设备称为调制解调器。
三、奈奎斯特定理与香农定理
-
奈奎斯特定理
奈奎斯特定理又称奈氏准则。它指出在理想低通（没有噪声、带宽有限）的信道中，极限码元速率为2W波特，其中W是理想低通信道的带宽，单位是Hz。若用V表示每个码元离散电平的数目（码元的离散电平数目是指有多少种不同的码元，比如有16种不同的码元，则需要有4位二进制位，因此数据传输率是码元传输率的4倍），则极限速率为
理想低通信道下的极限数据传输率=$2Wlog_2V$（单位为b/s)
对于奈氏准则，可以得出以下结论：
1）在任何信道中，码元传输的速率是有上限的。若传输速率超过此上限，就会出现严重的码间串扰问题，使得接收端不可能完全正确地识别码元。
2）信道的频带越宽(即通过的信号高频分量越多)，就可用更高的速率进行码元的有效传输。
3）奈氏准则给出了码元传输速率的限制，但是并未对信息传输速率给出限制，即未对一个码元可以对应多少个二进制位给出限制。
由于码元的传输速率受奈氏准则的制约，所以要提高数据的传输速率，就必须设法使每个码元携带更多个比特的信息量，此时就需要多元制的调制方法。
-
香农定理
香农定理给出了带宽受限且有高斯白噪声干扰的信道的极限数据传输率，当用此速率进行传输时，可以做到不产生误差。香农定理定义为：
信道的极限数据传输率=$Wlog_2(1+S/N)$ 单位为b/s
式中，W为信道带宽，S为信道所传输信号的平均功率，N为信道内部的高斯噪声功率，$S/N$为信噪比，即信号的平均功率与噪声的平均功率之比。
对于香农定理，可以得出以下的结论： 1）信道的带宽或信道中的信噪比越大，信息的极限传输速率越高。
2）对一定的传输带宽和一定的信噪比，信息传输速率的上限是确定的。
3）只要信息的传输速率低于信道的极限传输速率，就能找到某种方法来实现无差错的传输。
4）香农定理得出的是极限信息传输速率，实际信道能达到的传输速率比它低不少。
从香农定理可以看出，若信道带宽W或信噪比S/N没有上限，则信道的极限信息传输速率也没有上限。
奈氏准则只考虑了带宽与极限码元速率的关系，而香农定义不仅考虑了带宽，而且考虑到了信噪比。这从另一个侧面表明，一个码元对应的二进制位数是有限的。
四、传输方式
-
并行传输与串行传输
并行传输，是指一次发送n个比特而不是一个比特，为此，在发送端和接收端之间需要有n条传输线路。
串行传输，是指数据是一个比特一个比特发送的，为此，发送端和接收端之间只需要一条传输线路。
-
异步传输与同步传输
异步传输以字节为独立的传输单位，字节之间的时间间隔不是固定的，接收端仅在每个字节的起始处对字节内的比特实现同步。为此，通常需要在每个字节前后分别加上起始位和结束位，这里的异步是指在字节级上的异步，但是字节中的每个比特仍然要同步，它们的持续时间是相同的。
采用同步传输方式时，数据块以稳定的比特流形式传输，字节之间没有间隔，也没有起始位和结束位。由于不同设备的时钟频率存在一定差异，为避免在传输大量数据的过程中累积误差所导致的错误，要采取技术使得收发双方的时钟保持同步。实现收发双方时钟同步的方法有两种，即外同步和内同步。
外同步，是在发送端和接收端之间提供一条单独的时钟线，发送端在发送数据信号的同时，另外发送一条时钟同步信号。接收端根据接收到的时钟同步信号来校正时间基准，实现收发双方之间的同步。
内同步，是发送端将时钟同步信号编码到发送数据中一起传输，如曼彻斯特编码与差分曼彻斯特编码都含有时钟编码，具有自同步能力。
-
单工、半双工、全双工
1）单向通信，又称为单工通信，即只能有一个方向的通信而没有反方向的交互。如广播等。
2）双向交替通信，又称半双工通信，即通信的双方都可以发送信息，但不能双方同时发送。这种通信方式是一方发送另一方接收，过一段时间再反回来。
3）双向同时通信，又称为全双工通信，即通信的双方可以同时发送和接收信息。
-
The End