|
|
ID,label,chapter,name,content
|
|
|
Root,Root,0,软件工程,"软件工程引言精简版
|
|
|
|
|
|
软件工程是构建高质量软件的过程、方法和工具的集合，旨在通过规范化的开发流程、科学的管理方法和先进的工具技术，实现软件的高效、高质量开发和维护。在当今信息化高速发展的时代，软件已成为推动社会进步和发展的重要力量，而软件工程则是软件行业持续发展的基石。
|
|
|
|
|
|
软件工程允许我们根据实际需求调整软件的工作方式，使其更好地适应市场环境和用户需求。在实践中，软件工程需要遵循一系列的开发步骤和原则，从需求分析到设计、编码、测试再到维护，每一个环节都需要严格把控，确保软件的质量和稳定性。
|
|
|
|
|
|
随着技术的不断进步，软件工程也在不断发展和完善。我们需要不断地学习和掌握新的技术和方法，以适应不断变化的软件需求和技术环境。相信在未来的日子里，软件工程将能够创造出更多、更好、更智能的软件产品，为人们的生活和工作带来更多的便利和惊喜，继续推动社会信息化进程，成为社会发展不可或缺的重要力量。"
|
|
|
CH1,Subject,1,第1章 软件与软件工程,"① 理解软件的基本概念。学习计算机软件的定义，认识其作为长期维护的工作产品的特点，及其在不同系统架构下的适应性。
|
|
|
② 掌握软件工程的核心过程。学习软件工程的定义和开发流程，理解软件工程包括的方法、实践和工具，了解如何通过这些手段完成高质量软件产品的构建。
|
|
|
③ 认识软件工程师的职责和作用。了解软件工程师的角色，学习其如何应用软件工程过程进行软件开发与技术支持，认识产业界中软件的普遍应用。
|
|
|
④ 理解工作产品的不同视角。学习从软件工程师和用户两个角度理解“工作产品”这一概念，区分程序、数据及其他支持软件的工作产品。
|
|
|
⑤ 认识软件工程的意义和重要性。了解软件工程的重要性，学习它如何帮助构建复杂的系统，提升工作和生活的质量，并使复杂的工作有序进行。
|
|
|
⑥ 掌握质量保证方法。了解质量保证措施的概念，学习如何根据所开发软件的特点，选择合适的质量保证思想，并在实际开发中加以应用。"
|
|
|
T1.1,Topic,1,1.1 软件的本质,"① 理解软件的双重作用。学习软件作为产品和交付载体的双重角色，理解它如何通过计算机硬件和网络的支持，显示计算潜力，并承担信息转换的关键任务。
|
|
|
② 掌握软件的功能和应用。理解软件在不同平台（如移动电话、台式机、云或大型计算机）上的作用，学习其如何通过生成、管理、获取、修改、显示或传输各种信息（从比特传输到复杂的增强现实数据）来实现其功能。
|
|
|
③ 了解软件作为产品生产载体的作用。学习软件如何作为产品生产的基础平台，支持计算机控制（操作系统）、信息通信（网络）、以及应用程序开发和控制（软件工具和环境）的功能。
|
|
|
④ 认识软件在现代社会中的重要性。理解软件如何在信息转换、商业管理、全球信息网络和隐私安全等方面发挥重要作用。学习软件如何提高个人和企业的效率、竞争力，同时也带来了安全风险。
|
|
|
⑤ 分析软件的负面影响。了解软件可能带来的隐私威胁以及如何为恶意行为提供途径，培养对软件安全问题的警觉性，意识到其在数字化社会中的潜在风险。"
|
|
|
S1.1.1,Section,1,1.1.1 定义软件,软件通常由指令集合、数据结构和描述信息组成，通过执行这些指令，软件能够实现特定的功能和性能需求。与硬件不同，软件作为逻辑系统元素，避免了物理磨损的影响，这使得其失效率曲线与硬件有显著不同。硬件失效率呈“浴缸曲线”模式，初期因设计或生产缺陷导致较高失效率，随后的修正使失效率趋于稳定，然而环境因素会导致硬件逐渐磨损并再次增加失效率。而软件的失效率在初期通常较高，随着错误修正趋于平稳，但随着软件生命周期中的变更，失效率会受到每次变更引入的缺陷影响，呈现波动。换言之，软件不会像硬件那样磨损，但不断的变更会导致软件的退化。软件维护也因此变得更加复杂，因为每次变更都可能引入新的错误，无法像硬件那样通过替换部件来修复问题。
|
|
|
SS1.1.1.1,SubSection,1,1.1.1.1 软件的双重角色,"①软件是一种产品：扮演着信息转换的角色；产生、管理、查询、修改、显示、传递信息。
|
|
|
②软件是生产产品的载体，提供以下基础平台：计算机控制 (e.g., 操作系统)信息通信 (e.g., 网络软件)应用软件开发 (e.g., 软件工具)"
|
|
|
SS1.1.1.2,SubSection,1,1.1.1.2 什么是软件,"软件是一组要素的集合：程序、文档、数据。
|
|
|
|
|
|
①程序的正常运行离不开必要的文档和数据：
|
|
|
②文档是开发、使用和维护程序所需要的图文资料；
|
|
|
③数据是使程序能够适当地处理信息的数据结构（包括数据库、一些配置文件等）。"
|
|
|
SS1.1.1.3,SubSection,1,1.1.1.3 软件与硬件具有不同的特性,软件是逻辑的而非物理的系统元素。因此，软件和硬件具有完全不同的特性：软件不会“磨损”。
|
|
|
P1.1.1.3.1,Problem,1,1.1.1.3.1 软件是设计开发出的产品,"软件是设计开发的，而不是传统意义上生产制造的：硬件和软件可通过优秀的设计获得高品质产品，然而硬件在制造阶段可能会引入质量问题，这在软件中并不存在（或者易于纠正）；
|
|
|
软件产品成本主要在于开发设计，硬件的成本在批量生产时仍然很高。"
|
|
|
P1.1.1.3.2,Problem,1,1.1.1.3.2 软件不会“磨损”,"①磨损的硬件部件可以用备用部件替换，而软件却不存在备用部件。
|
|
|
②每个软件的缺陷都暗示了设计的缺陷或者在从设计转化到机器可执行代码（实现）的过程中产生的错误。
|
|
|
③软件维护要应对变更请求，比硬件维护更为复杂。
|
|
|
④不断的变更是软件退化的根本原因。"
|
|
|
P1.1.1.3.3,Problem,1,1.1.1.3.3 基于构件的构造模式,"工程学科的发展将产生一系列标准的设计器件。可复用构件的使用可以使得工程师专心于设计中真正创新的部分。在硬件设计中，构件复用是工程进程中通用的方法 (例如，标准螺丝钉、可订购的集成电路)。
|
|
|
|
|
|
现代可复用软件构件封装了数据和对数据的处理。例如，图形窗口、下拉菜单和各种交互机制。"
|
|
|
S1.1.2,Section,1,1.1.2 软件应用领域,"计算机软件可分为七个主要应用领域，软件工程师在这些领域面临不断的挑战。系统软件包括服务于其他程序的基础软件，如编译器、操作系统和驱动程序，处理的是复杂或不确定的数据。应用软件解决特定的业务需求，协助企业进行商务或技术决策。工程/科学软件则应用于广泛的数值计算领域，如天文学、气象学等科学研究。嵌入式软件嵌入在产品或系统中，提供如汽车燃油控制、微波炉控制等功能。
|
|
|
产品线软件通过可复用构件为多个用户提供特定功能，关注特定市场的需求。Web/移动App依赖网络环境，广泛应用于云计算、浏览器和移动设备中。人工智能软件通过启发式方法解决传统计算难以处理的复杂问题，涵盖机器人、机器学习、模式识别等领域。全球数百万软件工程师致力于这些项目的开发、修复和升级，同时，遗留系统的维护和更新成为他们面临的重要任务。"
|
|
|
SS1.1.2.1,SubSection,1,1.1.2.1 计算机软件的7类应用,计算机软件分为系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web/移动App及人工智能软件七大类。系统软件服务于其他程序，处理信息结构；应用软件解决特定业务需求；工程/科学软件涵盖广泛领域；嵌入式软件实现产品控制功能；产品线软件提供可复用构件；Web/移动App以网络为中心；人工智能软件解决复杂问题。软件工程师需面对技术挑战，具备产品设计、项目管理、算法设计及机器学习等能力。
|
|
|
P1.1.2.1.1,Problem,1,1.1.2.1.1 系统软件,"系统软件是一整套服务于其他程序的程序：
|
|
|
①某些系统软件（例如编译器、编辑器、文件管理软件）处理复杂但确定的信息结构。
|
|
|
②另一些系统应用程序（例如操作系统构件、驱动程序、网络软件、远程通信处理器）主要处理的是不确定的数据。
|
|
|
|
|
|
系统软件多具有以下特点：
|
|
|
①和计算机硬件大量交互；
|
|
|
②多用户大量使用；
|
|
|
③需要调度、资源共享和复杂进程管理的同步操作；
|
|
|
④复杂的数据结构以及多种外部接口。"
|
|
|
P1.1.2.1.2,Problem,1,1.1.2.1.2 应用软件,应用软件是解决特定业务需要的独立应用程序。这类应用软件处理商务或技术数据，以协助业务操作或协助做出管理/技术决策。
|
|
|
P1.1.2.1.3,Problem,1,1.1.2.1.3 工程/科学软件,"工程／科学软件：这类软件通常带着“数值计算”算法的特征，工程和科学软件涵盖了广泛的应用领域，天文学到火山学，从自动压力分析到轨道动力学，从计算机辅助设计到分子生物学，从遗传分
|
|
|
析到气象学。"
|
|
|
P1.1.2.1.4,Problem,1,1.1.2.1.4 嵌入式软件,"嵌入式软件存在于某个产品或者系统中，可实现和控制面向最终用户和系统本身的特性和功能。
|
|
|
①嵌入式软件可以执行有限的和内部的功能（例如微波炉的按键控制）
|
|
|
②可以提供重要的功能和控制能力（例如汽车中的燃油控制、仪表板显示、刹车系统等汽车电子功能）。"
|
|
|
P1.1.2.1.5,Problem,1,1.1.2.1.5 产品线软件,"产品线软件包括可复用的构件，并为多个不同用户的使用提供特定功能。其关注有限的及内部的市场（例如库存控制产品）或者大众消费品市场。
|
|
|
软件产品线都使用相同的底层应用软件和数据体系结构来开发，并使用可在整个产品线中进行复用的一组软件构件来实现。"
|
|
|
P1.1.2.1.6,Problem,1,1.1.2.1.6 Web/移动app,"Web/移动App：以网络为中心，其概念涵盖了宽泛的应用软件产品，包括基于浏览器的App、云计算、基于服务的计算和安装在移动设备上的软件。
|
|
|
最简单可以是一组超文本链接文件，仅仅用文本和有限的图形表达信息。随着Web 2.0的出现，网络应用正在发展为复杂的计算环境：比如，网游、网络社区应用。"
|
|
|
P1.1.2.1.7,Problem,1,1.1.2.1.7 人工智能软件,"人工智能软件。利用启发式方法（非数值算法）解决常规计算和直接分析无法解决的复杂问题。
|
|
|
这个领域的应用程序包括机器人、决策系统、模式识别（图像和语音）机器学习、定理证明和博弈等。"
|
|
|
S1.1.3,Section,1,1.1.3 遗留软件,"成千上万的计算机程序属于前述七个应用领域，其中一些是先进的软件，但另一些则已过时，通常被称为遗留软件。遗留软件自20世纪60年代以来，一直是软件工程的难题，特别是在不断变化的商业需求和技术平台下，这些系统的维护成本高且演化风险大。遗留系统通常存在许多问题，如设计难以扩展、代码混乱、缺乏文档、测试不充分等，然而它们依然支撑着核心业务功能，成为企业不可或缺的部分。
|
|
|
虽然遗留软件经常需要进行适应性调整、升级或扩展，但如果它能够满足当前用户需求并且稳定运行，就不必进行修改。随着时间的推移，软件可能需要根据新的计算环境、商业需求或协作需求进行改进和改建。面对这些变更，遗留系统通常需要进行再工程，以确保其能够与新系统兼容。现代软件工程的目标是使这些新旧系统具有互操作性和协作性，确保软件在不断的变化中得以延续和改进。"
|
|
|
SS1.1.3.1,SubSection,1,1.1.3.1 遗留软件的定义,"遗留软件是那些已经过时但仍在运行的软件，它们：①开发年代久远；②一直在使用；③在使用过程中被不断地修改以满足商业需要和计算平台的变化；④可能仍然支持着核心业务。
|
|
|
它们通常难以维护和升级，但对业务至关重要，因此需要特别的关注和管理。
|
|
|
|
|
|
“遗留软件系统……他们在几十年前诞生，他们不断被修改以满足商业需要和计算平台的变化。这类系统的繁衍使得大型机构十分头痛，因为他们的维护代价高昂且系统演化风险高。”——Dayani-Fard"
|
|
|
SS1.1.3.2,SubSection,1,1.1.3.2 遗留软件的“质量差”问题,"遗留软件通常具有数不清的问题：
|
|
|
设计难以扩展；
|
|
|
代码令人费解；
|
|
|
文档混乱，可能缺失；
|
|
|
变更管理混乱；
|
|
|
测试记录未归档；
|
|
|
……"
|
|
|
SS1.1.3.3,SubSection,1,1.1.3.3 遗留软件为什么要演化?,"由于遗留软件常常支撑着核心业务，对其变更必须非常谨慎。如果它能够满足用户的需求并可靠运行，则不要修改它。
|
|
|
然而，随着时间的推移，遗留系统经常会出于下述原因而发生演化：
|
|
|
①进行适应性变化，以满足新的计算环境或者技术的需要；（满足新需求）
|
|
|
②根据新的业务需求进行升级；（升级）
|
|
|
③扩展以及具有与更多现代系统或数据库的协作能力；（扩展）
|
|
|
④改建以适应多样化的网络环境；（改建）"
|
|
|
T1.2,Topic,1,1.2 定义软件工程学科,"① 理解软件工程的定义。学习IEEE对软件工程的定义，掌握软件工程是如何将系统化、规范化、可量化的方法应用于软件的开发、运行和维护，并理解工程化方法在软件开发中的重要性。
|
|
|
② 认识软件工程的适应性与灵活性。了解不同的软件开发团队可能对“系统化、规范的、可量化的方法”有不同的看法，学习如何平衡规范性与适应性、灵活性之间的关系。
|
|
|
③ 掌握软件工程的层次结构。学习软件工程的层次化技术，理解软件工程方法的基础是质量承诺，并探索全面质量管理(TQM)、六西格玛等理念如何促进持续的过程改进。
|
|
|
④ 理解软件工程的基础层次：过程。学习软件过程如何将各个技术层次结合在一起，支持软件开发，建立工作环境，确保质量，合理管理变更，并在项目中设定里程碑。
|
|
|
⑤ 理解软件工程的方法。掌握软件工程方法的作用及其技术解决方案，学习方法覆盖的技术领域，如沟通、需求分析、设计建模、程序构造、测试和技术支持等。
|
|
|
⑥ 认识软件工程工具的作用。了解软件工程工具如何为过程和方法提供支持，学习计算机辅助软件工程(CASE)如何通过集成工具提升开发效率，使得一个工具产生的信息能被另一个工具使用。"
|
|
|
S1.2.1,Section,1,1.2.1 软件工程的定义,"①软件工程：将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件； ——IEEE [IEEE93a]
|
|
|
②软件工程：建立和使用一套合理的工程原则，从而经济地获得可靠的、可在实际机器上高效运行的软件。 ——Fritz Bauer [Nau69]"
|
|
|
S1.2.2,Section,1,1.2.2 软件工程是一种层次化技术,软件工程，作为将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护的学科，其核心在于平衡规范化与灵活性。软件工程不仅是一种技术实践，更是一种层次化的技术体系。从质量承诺的根基出发，通过构建合理的过程框架，结合多样化的方法和技术手段，最终实现软件的高效开发和维护。在这个层次化的技术体系中，过程定义了框架，方法提供了技术解决方案，而工具则为过程和方法提供了自动化支持。因此，深入理解和应用软件工程的层次化技术，对于提高软件开发的效率和质量具有重要意义。
|
|
|
SS1.2.2.1,SubSection,1,1.2.2.1 软件工程层次,软件工程是一种层次化技术。任何工程方法（包括软件工程）必须构建在质量承诺的基础之上。你也许听说过全面质量管理（TQM）、六西格玛和类似的理念促进了持续不断的过程改进文化，正是这种文化最终引导人们开发出更有效地软件工程方法。支撑软件工程的根基在于【质量关注点】。
|
|
|
P1.2.2.1.1,Problem,1,1.2.2.1.1 过程层,"软件工程的基础是【过程】层。过程定义了一个框架，给出了开发步骤，构建该框架是有效实施软件工程技术必不可少的。
|
|
|
软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。软件过程构成了软件项目管理控制的基础，建立了工作环境以便应用技术方法、提交工作产品（模型、文档、数据、报告、表格等）、建立里程碑、保证质量以及正确地管理变更。"
|
|
|
P1.2.2.1.2,Problem,1,1.2.2.1.2 方法层,"软件工程【方法】为构建软件提供技术上的解决方法（“如何做”）。
|
|
|
方法覆盖面很广，包括沟通、需求分析、设计建模、编程、测试和技术支持。"
|
|
|
P1.2.2.1.3,Problem,1,1.2.2.1.3 工具层,"软件工程【工具】为过程和方法提供自动化或半自动化的支持。
|
|
|
这些工具可以集成起来，使得一个工具产生的信息可被另外一个工具使用，这样就建立了软件开发的支撑系统。成为“计算机辅助软件工程”。"
|
|
|
T1.3,Topic,1,1.3 软件过程,"软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
|
|
|
①活动(activity)主要实现宽泛的目标（如与利益相关者进行沟通)，与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。
|
|
|
②动作(action，如体系结构设计）包含主要工作产品(如体系结构设计模型)生产过程中的一系列任务。
|
|
|
③任务(task)关注小而明确的目标，能够产生实际产品（如构建一个单元测试)。
|
|
|
|
|
|
在软件工程领域，过程不是对如何构建计算机软件的严格规定，而是一种具有可适应性的调整方法，以便于工作人员(软件团队）可以挑选适合的工作动作和任务集合。
|
|
|
其目标通常是【及时、高质量地交付软件】，以满足软件项目资助方和最终用户的需求。
|
|
|
|
|
|
当开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。
|
|
|
软件开发中所遵循的路线图就称为“软件过程”。"
|
|
|
S1.3.1,Section,1,1.3.1 过程框架,"框架是事物的基本组织、结构。
|
|
|
|
|
|
过程框架定义了若干个框架活动，为实现完整的软件工程奠定了基础的框架：
|
|
|
①定义了若干小的框架活动，为完整的软件开发过程建立了基础；
|
|
|
②每一个活动由一组软件工程动作组成：
|
|
|
③每一个动作都包括一系列相互关联的可考核的任务。（每一个任务完成一个动作定义的一部分工作。）"
|
|
|
SS1.3.1.1,SubSection,1,1.3.1.1 通用的5个框架活动,通用过程框架：适用于绝大多数软件项目，包含五个最基本的框架活动：沟通、策划、建模、构建、部署。
|
|
|
P1.3.1.1.1,Problem,1,1.3.1.1.1 沟通,"在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作是极其重要
|
|
|
的，其目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。"
|
|
|
P1.3.1.1.2,Problem,1,1.3.1.1.2 策划,"如果有地图，任何复杂的旅程都可以变得简单。软件项目好比是一个复杂的旅程，策划活动就是创建一个""地图""，以指导团队的项目旅程，这个地图称为软件项目计划，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。"
|
|
|
P1.3.1.1.3,Problem,1,1.3.1.1.3 建模,无论你是庭园设计师、桥梁建造者、航空工程师、木匠还是建筑师，每天的工作都离不开模型。你会画一张草图来辅助理解整个项目大的构想——体系结构、不同的构件如何结合，以及其他一些特性。如果需要，可以把草图不断细化，以便更好地理解问题并找到解决方案。软件工程师也是如此，需要利用模型来更好地理解软件需求，并完成符合这些需求的软件设计。
|
|
|
P1.3.1.1.4,Problem,1,1.3.1.1.4 构建,必须对所做的设计进行构建，包括编码（手写的或者自动生成的）和测试，后者用于发现编码中的错误。
|
|
|
P1.3.1.1.5,Problem,1,1.3.1.1.5 部署,软件（全部或者部分增量）交付给用户，用户对其进行评测并基于评测给出反馈意见。
|
|
|
S1.3.2,Section,1,1.3.2 普适性活动,"在软件工程领域，普适性活动作为软件工程过程框架的重要组成部分，发挥着至关重要的作用。这些活动贯穿于软件项目的始终，旨在帮助软件团队更好地管理和控制项目的进度、质量、变更和风险。典型的普适性活动包括软件项目跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用性管理以及工作产品的准备和生产等。这些活动相互协作，共同构成了软件工程过程的核心，为软件团队提供了一套科学、规范的工作方法。
|
|
|
|
|
|
通过软件项目跟踪和控制，团队能够实时评估项目进度，并采取必要的措施确保项目按计划进行。风险管理则帮助团队识别和应对可能影响项目成果或产品质量的风险。软件质量保证和技术评审则关注于提高软件产品的质量，确保软件产品符合利益相关者的要求。测量活动则为团队提供了关于过程、项目和产品的关键数据，支持团队做出明智的决策。软件配置管理则管理变更带来的影响，保持软件的一致性和完整性。可复用性管理则通过定义复用标准和建立复用机制，提高软件开发的效率和质量。
|
|
|
|
|
|
综上所述，普适性活动在软件工程过程中扮演着举足轻重的角色，它们为软件团队提供了一套系统化、规范化的工作方法，支持团队高效地开发高质量的软件产品。"
|
|
|
SS1.3.2.1,SubSection,1,1.3.2.1 典型的普适性活动,典型的普适性活动包括软件项目跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用性管理以及工作产品的准备和生产等。这些活动相互协作，共同构成了软件工程过程的核心，为软件团队提供了一套科学、规范的工作方法。
|
|
|
P1.3.2.1.1,Problem,1,1.3.2.1.1 软件项目跟踪和控制,项目组根据计划来评估项目进度，并且采取必要的措施来保证项目按进度计划进行。
|
|
|
P1.3.2.1.2,Problem,1,1.3.2.1.2 风险管理,对可能影响项目成果或者产品质量的风险进行评估。
|
|
|
P1.3.2.1.3,Problem,1,1.3.2.1.3 软件质量保证,确定和执行保证软件质量的活动。
|
|
|
P1.3.2.1.4,Problem,1,1.3.2.1.4 技术评审,评估软件工程产品，尽量在传播到下一个活动之前发现错误并清除。
|
|
|
P1.3.2.1.5,Problem,1,1.3.2.1.5 测量,定义和收集过程、项目以及产品的度量，以帮助团队在发布软件时满足利益相关者的要求。同时，测量还可与其他框架活动和普适性活动配合使用。
|
|
|
P1.3.2.1.6,Problem,1,1.3.2.1.6 软件配置管理,在整个软件过程中管理变更所带来的影响。
|
|
|
P1.3.2.1.7,Problem,1,1.3.2.1.7 可复用性管理,定义工作产品（包括软件构件）复用的标准，并且建立构件复用机制。
|
|
|
P1.3.2.1.8,Problem,1,1.3.2.1.8 工作产品的准备和生产,包括生成产品（如建模、文档、日志、表格和列表等）所必需的活动。
|
|
|
S1.3.3,Section,1,1.3.3 过程的适应性调整,"软件工程过程并不是教条的法则，不要求软件团队机械地执行；而应该是灵活可适应的（根据软件所需解决的问题、项目特点、开发团队和组织文化等进行适应性调整）。因此，不同项目所采用的项目过程可能有很大不同。
|
|
|
|
|
|
这些不同主要体现在以下几个方面：
|
|
|
1.活动、动作和任务的总体流程以及相互依赖关系。
|
|
|
2.在每一个框架活动中，动作和任务细化的程度。
|
|
|
3.工作产品的定义和要求的程度。
|
|
|
4.质量保证活动应用的方式。
|
|
|
5.项目跟踪和控制活动应用的方式。
|
|
|
6.过程描述的详细程度和严谨程度。
|
|
|
7.客户和利益相关者对项目的参与程度。
|
|
|
8.软件团队所赋予的自主权。
|
|
|
9.团队组织和角色的明确程度。"
|
|
|
T1.4,Topic,1,1.4 软件工程实践,"① 理解软件工程实践的框架。学习通用软件过程模型的框架活动（如沟通、策划、建模、构建和部署），掌握这些活动如何组成软件工程工作的体系结构轮廓，了解它们在实际软件工程实践中的作用和重要性。
|
|
|
② 掌握软件工程实践的核心活动。理解如何将框架活动应用于实际的软件工程工作中，学习每个活动（沟通、策划、建模、构建和部署）在软件开发生命周期中的具体操作与实施方法。
|
|
|
③ 认识软件工程中的基本概念与原则。通过对各框架活动的学习，理解软件工程实践中的基本概念和原则，掌握如何灵活地将这些概念和原则应用于不同的开发场景和项目需求，以提高软件开发的效率和质量。"
|
|
|
S1.4.1,Section,1,1.4.1 软件工程实践的精髓,"软件工程实践的核心精髓可以通过四个基本步骤来总结：首先是理解问题，这要求我们不仅要准确识别问题本身，还要明确利益相关者、定义问题的已知与未知部分，并考虑是否能将问题分解为更小的、易于理解的子问题。其次是策划解决方案，在动手编码前，需要进行设计思考，回顾类似问题的解决经验，识别可复用的元素，定义子问题，并创建可行的设计模型。
|
|
|
接下来的步骤是实施计划，即将设计转化为实际代码，保证代码与设计的一致性，确保每个组成部分的正确性。最后是检查结果，通过测试确保解决方案的正确性，验证系统是否按预期运行，并确认其符合需求。这些步骤虽看似常识，但它们为软件开发提供了清晰的框架，确保开发过程中的目标明确，最终提升软件的质量和成功率。"
|
|
|
SS1.4.1.1,SubSection,1,1.4.1.1 理解问题,"虽然难于承认，但我们遇到的问题很多都源于我们的傲慢。我们只听了几秒钟就断言“好，我懂了，让我们开始解决这个问题吧”。不幸的是，理解一个问题不总是那么容易，需要花一点时间回答几个简单问题：
|
|
|
①谁将从问题的解决中获益？也就是说，谁是利益相关者？
|
|
|
②有哪些是未知的？哪些数据、功能、特征和行为是解决问题必需的？
|
|
|
③问题可以划分吗？是否可以描述为更小、更容易理解的问题？
|
|
|
④问题可以图形化描述吗？可以建立分析模型吗？"
|
|
|
SS1.4.1.2,SubSection,1,1.4.1.2 策划解决方案,"现在你理解了要解决的问题（或者你这样认为），并迫不及待地开始编码。在编码之前，稍稍慢下来做一点点设计：
|
|
|
①以前曾经见过类似问题吗？在潜在的解决方案中，是否可以识别一些模式？
|
|
|
②是否已经有软件实现了所需要的数据、功能、特征和行为？
|
|
|
③类似问题是否解决过？如果是，解决方案所包含元素是否可以复用？
|
|
|
④可以定义子问题吗？如果可以，子问题是否已有解决方案？
|
|
|
⑤能用一种可以快速实现的方式来描述解决方案吗？能构建出设计模型吗？"
|
|
|
SS1.4.1.3,SubSection,1,1.4.1.3 实施计划,"前面所创建的设计勾画了所要构建的系统的路线图。也许存在没有想到的路径，也可能在实施过程中会发现更好的解决路径，但是这个计划可以保证在实施过程中不至于迷失方向。需要考虑的问题是：
|
|
|
①解决方案和计划一致吗？
|
|
|
②源码是否可追溯到设计模型？
|
|
|
③解决方案的每个组成部分是否可以证明正确？
|
|
|
④设计和代码是否经过评审？
|
|
|
⑤或者更好的算法是否经过正确性证明？"
|
|
|
SS1.4.1.4,SubSection,1,1.4.1.4 检查结果,"你不能保证你的解决方案是最完美的，但是你可以保证设计足够的测试来发现尽可能多的错误。为此，需回答：
|
|
|
①能否测试解决方案的每个部分？
|
|
|
②是否实现了合理的测试策略？
|
|
|
③解决方案是否产生了与所要求的数据、功能、特征和行为一致的结果？
|
|
|
④是否按照项目共同利益者的需求进行了确认？"
|
|
|
S1.4.2,Section,1,1.4.2 通用原则,在软件工程中，原则是指支撑整个思想体系的根本规则或假设。这些原则涵盖不同的抽象层次，既包括软件工程的整体原则，也涉及具体的框架活动（如沟通）、软件开发过程中的关键操作（如体系结构设计）和技术任务（如编写用例场景）。无论这些原则聚焦于哪个层面，它们都旨在帮助我们建立一种系统化的思维方式，确保在实际的软件工程实践中能够做到扎实和有效。因此，遵循这些原则对于保证软件工程的质量和成功至关重要。
|
|
|
SS1.4.2.1,SubSection,1,1.4.2.1 David Hooker的7个关注软件工程整体实践原则,David Hooker提出的7个软件工程整体实践原则，深刻揭示了软件开发过程中的关键要素。这些原则强调，首先应以用户价值为核心，确保软件产品能够真正满足用户需求；同时，追求简洁设计，避免不必要的复杂性，以提高软件的可维护性和可扩展性。此外，确保团队对项目愿景有共同的理解，重视团队协作，以及设计适应变化的系统，都是确保项目成功的关键。同时，规划重用也是提高开发效率、降低成本的重要手段。最后，在行动前进行深入思考，确保决策的正确性和有效性。这些原则共同构成了软件工程实践的指导方针，帮助开发者开发出高质量、高效率、满足用户需求的软件产品。
|
|
|
P1.4.2.1.1,Problem,1,1.4.2.1.1 第一原则：存在价值,一个软件系统因能为用户提供价值而具有存在价值，所有的决策都应该基于这个思想。在确定系统需求之前，在关注系统功能之前，在决定硬件平台或者开发过程之前，问问你自己：这确实能为系统增加真正的价值吗？如果答案是不，那就坚决不做。所有的其他原则都以这条原则为基础。
|
|
|
P1.4.2.1.2,Problem,1,1.4.2.1.2 第二原则：保持简洁,在软件设计中需要考虑很多因素。所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于维护的系统。这并不是说有些特性应该以“简洁”为借口而取消。的确，优雅的设计通常也是简洁的设计，但简洁不意味着“快速和粗糙”。事实上，它经常是经过大量思考和多次工作迭代才达到的，这样做的回报是所得到的软件更易于维护且错误更少。
|
|
|
P1.4.2.1.3,Problem,1,1.4.2.1.3 第三原则：保持愿景,在软件设计中需要考虑很多因素。所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于维护的系统。这并不是说有些特性应该以“简洁”为借口而取消。的确，优雅的设计通常也是简洁的设计，但简洁不意味着“快速和粗糙”。事实上，它经常是经过大量思考和多次工作迭代才达到的，这样做的回报是所得到的软件更易于维护且错误更少。
|
|
|
P1.4.2.1.4,Problem,1,1.4.2.1.4 第四原则：关注使用者,在需求说明、设计、编写文档和实现过程中，牢记要让别人理解你所做的事情。对于任何一个软件产品，其工作产品都可能有很多用户。进行需求说明时应时刻想到用户，设计中始终想到实现，编码时考虑到那些要维护和扩展系统的人。一些人可能不得不调试你所编写的代码，这使得他们成了你所编写代码的使用者，尽可能地使他们的工作简单化会大大提升系统的价值。
|
|
|
P1.4.2.1.5,Problem,1,1.4.2.1.5 第五原则：面向未来,在现今的计算环境中，需求规格说明随时会改变，硬件平台几个月后就会淘汰，软件生命周期都是以月而不是年来衡量的。然而，真正具有“产业实力”的软件系统必须持久耐用。为了做到这一点，系统必须能适应各种变化，能成功做到这一点的系统都是那些一开始就以这种路线来设计的系统。永远不要把自己的设计局限于一隅，经常问问“如果出现……应该怎样应对”，构建可以解决通用问题的系统，为各种可能的方案做好准备，而不是仅仅针对某一个具体问题。[2]
|
|
|
P1.4.2.1.6,Problem,1,1.4.2.1.6 第六原则：提前计划复用,复用既省时又省力。软件系统开发过程中，高水平的复用是一个很难实现的目标。曾有人宣称代码和设计复用是面向对象技术带来的主要好处，然而，这种投入的回报不会自动实现。提前做好复用计划将降低开发费用，并增加可复用构件以及构件化系统的价值。
|
|
|
P1.4.2.1.7,Problem,1,1.4.2.1.7 第七原则：认真思考,这最后一条规则可能是最容易被忽略的。在行动之前清晰定位、完整思考通常能产生更好的结果。仔细思考可以提高做好事情的可能性，而且也能获得更多的知识，明确如何把事情再次做好。如果仔细思考过后还是把事情做错了，那么，这就变成了很有价值的经验。思考就是学习和了解本来一无所知的事情，使其成为研究答案的起点。把明确的思想应用在系统中，就产生了价值。使用前6条原则需要认真思考，这将带来巨大的潜在回报。
|
|
|
T1.5,Topic,1,1.5 这一切都是如何开始的,"① 理解软件工程项目的起始点。学习软件工程项目的起始阶段通常源自业务需求，如对现有应用程序缺陷的修正、系统改造、功能扩展或新产品的开发。了解如何通过对话和需求分析来识别并表达业务需求。
|
|
|
② 掌握软件需求的非正式表达与转化。认识到在软件项目初期，业务需求通常是通过简短且非正式的对话来传达的，学习如何从这些非正式的需求表达中提取有效的信息，转化为具体的技术要求。
|
|
|
③ 认识软件在产品开发中的核心作用。了解在软件工程项目中，尽管初期可能仅提及硬件或产品功能，软件往往是确保产品成功的关键因素。通过SafeHome产品的案例，理解软件如何在产品的设计、功能实现以及市场竞争中起到决定性作用。
|
|
|
④ 分析软件开发项目中的市场需求与技术可行性。学习如何通过市场调查和技术可行性研究来评估软件产品的潜力。掌握如何平衡市场需求、产品定价、技术可行性及资源需求，从而推动软件项目的成功实施。"
|
|
|
S1.5.1,Section,1,1.5.1 软工项目来自业务需求,"①每个软件工程项目都来自业务需求：
|
|
|
②对现有应用程序缺陷的纠正；
|
|
|
③改变遗留系统以适应新的业务关键；
|
|
|
④扩展现有应用程序功能和特性；
|
|
|
⑤开发某种新的产品、服务或系统。
|
|
|
|
|
|
软件项目的初期，业务需求通常是在谈话过程中非正式地表达出来。"
|
|
|
T1.6,Topic,1,1.6 小结,"软件是以计算机为基础的系统和产品中的关键部分，并且是世界舞台上最重要的技术之一。在过去的60年里，软件已经从特定问题求解和信息分析的工具发展为独立的产业。如何在有限的时间内利用有限的资金开发高质量的软件，仍然是我们所面对的难题。
|
|
|
|
|
|
软件——程序、数据和描述信息——覆盖了技术和应用的很多领域。遗留软件仍旧给维护人员带来了特殊的挑战。
|
|
|
软件工程包括【过程、方法和工具】，这些工具使得快速构建高质量的复杂计算机系统成为可能。
|
|
|
软件过程包括五个框架活动——沟通、策划、建模、构建和部署，这些活动适用于所有的软件项目。
|
|
|
|
|
|
软件工程实践按照一组核心原则，是一项解决问题的活动。随着你对于软件工程的了解越来越多，你会逐渐理解开始一个软件工程项目的时候为什么要考虑这些原则。"
|
|
|
CH3,Subject,3,第3章 敏捷和敏捷过程,"① 理解敏捷软件工程的核心概念。学习敏捷软件工程的哲学理念，掌握其作为一种替代方案如何快速交付成功系统，强调尽早发布、增量开发、小而高效的自主团队、非正式方法以及精简工作产品等原则。
|
|
|
② 认识敏捷开发的基本步骤和框架。了解敏捷开发是如何保留传统软件工程的基本框架活动（如沟通、策划、建模、构建和部署），但将这些活动缩减为推动项目组快速构建和交付的最小任务集。理解这一方法如何重视快速响应变化和适应需求。
|
|
|
③ 掌握敏捷开发团队的角色与协作方式。学习敏捷开发团队的组成，包括软件工程师、项目经理、客户和最终用户等，了解团队如何通过自组织和自主管理推动项目进展，注重人员之间的交流与合作，确保项目按时交付可用增量。
|
|
|
④ 理解敏捷开发中的工作产品。了解敏捷开发过程中最重要的工作产品是可交付的软件增量，及其如何在合适的时间交付给客户。学习如何通过用户故事和测试用例等文档来支持开发和测试。
|
|
|
⑤ 认识敏捷软件工程的质量保证方法。了解敏捷团队如何通过可交付的增量、团队自评过程及与客户的互动来保证软件质量。学习如何通过持续的反馈循环来验证开发是否满足客户需求，以及如何通过灵活的过程调整来保持质量。"
|
|
|
T3.1,Topic,3,3.1 什么是敏捷,"① 理解敏捷的基本理念。学习敏捷软件工程的核心理念，掌握其如何应对快速变化，强调灵活应变和适应不断变化的需求。理解敏捷不仅是响应变化，还包括与团队成员、技术人员和业务人员之间更高效的沟通与协作。
|
|
|
② 认识敏捷的开发哲学和团队结构。理解敏捷如何通过推动团队合作、减少“我们”和“他们”之间的隔阂，促进开发团队与客户共同工作。学习敏捷如何通过灵活的团队结构和协作态度来实现更高效的开发过程。
|
|
|
③ 掌握敏捷开发的交付与计划策略。了解敏捷开发强调快速交付可运行软件，并不注重中间产品。学习如何通过增量交付策略，尽快将可工作的软件交付给客户，以确保项目能够持续适应和满足需求。
|
|
|
④ 认识敏捷方法的灵活性和局限性。学习敏捷方法如何应对不确定性，理解项目计划的局限性，并掌握如何设计灵活的开发过程，适应任务和项目需求。理解敏捷开发强调流水线化的任务流程，以便高效地进行计划和执行。"
|
|
|
S3.1.1,Section,3,3.1.1 敏捷宣言,"1.个体与交互胜过过程与工具
|
|
|
2.可用的软件胜过完备的文档
|
|
|
3.客户协作胜过合同谈判
|
|
|
4.响应变化胜过遵循计划"
|
|
|
S3.1.2,Section,3,3.1.2 敏捷价值观,敏捷价值观的核心在于更重视人与人之间的互动、可工作的软件、与客户的持续合作以及对变化的响应。首先，个体与互动高于流程与工具，强调团队成员的协作比工具和流程更为重要。其次，可工作的软件高于全面的文档，意味着开发的重点应放在交付可运行的软件，而不是过度依赖文档。客户合作高于合同谈判则强调与客户的紧密合作，以适应需求变化，而非仅仅按照合同执行。最后，响应变化高于遵循计划，倡导灵活应变，适应需求的变动，确保项目能够在不确定的环境中持续进展。通过这些价值观，敏捷方法力求提高项目的灵活性和效率。
|
|
|
S3.1.2.1,SubSection,3,3.1.2.1 沟通,不但要促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。
|
|
|
S3.1.2.2,SubSection,3,3.1.2.2 简单,画一两张图表来代替几十甚至几百行的代码，类似这种方法成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。
|
|
|
S3.1.2.3,SubSection,3,3.1.2.3 反馈,Kent Beck在Extreme Programming Explained中有句话讲得非常好：“过度自信是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。
|
|
|
S3.1.2.4,SubSection,3,3.1.2.4 勇气,"1、有勇气主动挑战工作，并承担责任。
|
|
|
2、有勇气只进行简单的设计，并相信它能够满足客户需求。
|
|
|
3、有勇气编写测试代码，并相信测试代码能够满足需求。
|
|
|
4、有勇气拥抱变化，积极适应变化，响应客户需求。
|
|
|
5、有勇气在需求变化时重构代码。
|
|
|
6、有勇气不断采用新的开发技术或方法，不断改进，以提高用户满意度。
|
|
|
7、有勇气对自己的阶段工作进行回顾，总结自己错误的行为并及时纠正。
|
|
|
8、有勇气面对各种困难和风险，鼓励并带领伙伴一起齐心协力、克服困难、渡过难关。
|
|
|
9、有勇气向客户承诺并达到它。
|
|
|
10、有勇气对用户说“不”。尊重用户价值，对用户负责，不欺瞒用户。
|
|
|
11、有勇气挑战权威，表达自己正确的见解并用实践证明。
|
|
|
12、有勇气接受任何成员的好建议并改进之。"
|
|
|
S3.1.2.5,SubSection,3,3.1.2.4 尊重（谦逊）,最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。
|
|
|
S3.1.3,Section,3,3.1.3 敏捷开发,敏捷开发是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件。
|
|
|
S3.1.4,Section,3,3.1.4 敏捷,敏捷是一种以迭代和增量开发为核心的软件开发方法，强调快速交付可用的软件、灵活应对需求变化以及持续改进。它通过将开发过程分为多个小的迭代周期，每个周期交付一个功能完善的产品增量，确保项目能灵活应对市场变化。敏捷注重团队协作与客户沟通，通过频繁反馈调整开发方向，保证开发工作始终符合客户需求。敏捷方法特别适用于需求不确定或经常变化的项目，可以提高开发效率和软件质量。
|
|
|
SS3.1.4.1,SubSection,3,3.1.4.1 变化以及敏捷团队,"敏捷团队是能够适当响应变化的灵活团队：
|
|
|
变化就是软件开发本身，软件构建有变化、团队成员在变化、使用新技术会带来变化。
|
|
|
各种变化都会对开发的软件产品以及项目本身造成影响。我们必须接受“支持变化”的思想，它应当根植于软件开发的每一件事中，因为它是软件的心脏与灵魂。
|
|
|
敏捷团队意识到软件是由团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。
|
|
|
普遍存在的变化是敏捷的基本动力。"
|
|
|
SS3.1.4.2,SubSection,3,3.1.4.2 敏捷不仅仅是有效地响应变化,"它鼓励能够形成沟通（组员之间、技术和商务人员之间、软件工程师和经理之间）更便利的团队结构和协作态度。
|
|
|
它强调可运行软件的快速交付而不那么看重中间产品（这并不总是好事情）；
|
|
|
它将客户作为开发团队的成员以消除一直普遍存在多数软件项目中的“区分你我”的态度；
|
|
|
它意识到在不确定的世界里计划是有局限性的，项目计划必须是可以灵活调整的。"
|
|
|
T3.2,Topic,3,3.2 敏捷及变更成本,"① 理解传统软件开发中变更成本的增长模式。学习在传统的软件开发方法中，随着项目进展，变更成本的非线性增长。掌握如何在项目初期适应变更相对简单，而在后期，尤其是在体系结构和核心功能设计修改时，变更的成本和时间消耗急剧增加。
|
|
|
② 认识敏捷开发如何应对变更成本。了解敏捷软件工程如何通过增量交付和其他实践，如持续单元测试和结对编程，降低变更成本。学习敏捷过程如何“拉平”变更曲线，使得在项目后期进行变更时，不会引发过高的费用和时间成本，确保项目的灵活性。
|
|
|
③ 比较传统方法与敏捷方法对变更成本的影响。通过对比传统方法和敏捷方法的变更曲线（传统方法的非线性增长与敏捷方法的平缓趋势），学习敏捷开发如何显著降低后期变更的成本，尤其是在面对重要功能修改或架构调整时。
|
|
|
④ 分析敏捷开发的增量交付与成本控制关系。学习敏捷如何通过增量交付的策略，持续交付可工作的软件，结合其他敏捷实践，帮助团队在整个开发过程中灵活响应变更，降低后期调整带来的负面影响。"
|
|
|
S3.2.1,Section,3,3.2.1 传统软件开发方法的变更,"软件开发的传统方法中（有几十年的开发经验作支持），变更的成本费用随着计划的进展成非线性增长。这种方法在软件开发团队收集需求时（在项目的早期）相对容易适应变更。
|
|
|
|
|
|
如果我们在经过数月的开发时间之后将会怎么样？团队在进行确认测试的过程中（也许是在项目后期的某个活动中），一个重要的利益相关者要求变更一个主要的功能：这一变更需要对软件的体系结构设计进行修改，包括设计和构建三个新组件，修改另外五个组件，设计新的测试等。费用会迅速升级，而这方面的开销则是可观的。"
|
|
|
S3.2.2,Section,3,3.2.2 敏捷的变更,"敏捷的拥护者认为，一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化。
|
|
|
敏捷过程包括增量交付。当增量交付与其他敏捷实践耦合时，例如连续单元测试及结对编程，引起变更的费用会衰减。
|
|
|
虽然关于拉平曲线的程度的讨论仍然在进行，但是证据表明，敏捷变更费用显著降低。"
|
|
|
T3.3,Topic,3,3.3 什么是敏捷过程,"① 理解敏捷软件过程的关键假设。学习敏捷软件过程中三个核心假设，包括预测需求稳定性和客户优先级变化的困难，理解设计与构建交错进行的特性，以及分析、设计、构建和测试难以预测的原因。掌握这些假设如何影响敏捷过程的设计和实施。
|
|
|
② 认识敏捷过程的可适应性。了解如何应对不可预测性，敏捷过程必须具备可适应性，能够快速响应需求变化和技术变化。学习敏捷开发如何通过适应性设计，确保软件能够灵活调整，以应对动态变化的环境。
|
|
|
③ 掌握增量式开发策略的重要性。了解增量式开发策略如何帮助团队快速交付可运行的软件原型，并通过客户反馈实现调整。这种策略能够在短时间内交付部分实现的系统，确保项目能适应客户的需求变化，并持续改进。
|
|
|
④ 分析敏捷过程中的客户反馈机制。学习客户反馈如何驱动敏捷过程的迭代改进，掌握如何通过客户的定期评价和反馈，快速调整软件开发方向，从而提高产品质量和客户满意度。"
|
|
|
S3.3.1,Section,3,3.3.1 敏捷原则,"1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
|
|
|
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
|
|
|
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
|
|
|
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
|
|
|
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
|
|
|
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
|
|
|
7. 可运行软件是进度的首要度量标准。
|
|
|
8. 敏捷过程提倡可持续的开发速度。责任人（sponsor）、开发者和用户应该能够保持一个长期的、恒定的开发速度 。
|
|
|
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
|
|
|
10. 简单是必要的。
|
|
|
11. 最好的架构、需求和设计出自于自组织团队。
|
|
|
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。
|
|
|
★并不是每一个敏捷模型都同等使用这12项原则，一些模型可以选择忽略（或至少淡化）一个或多个原则的重要性。"
|
|
|
S3.3.2,Section,3,3.3.2 敏捷过程的特征,首先，需求和优先级的预测往往非常困难，尤其是在项目早期阶段。其次，理论上软件开发应遵循先设计后构建的顺序，但在实际中，设计和构建往往是交替进行的，因为设计者并非全知全能。最后，软件开发中的核心元素，如分析、设计、构建和测试，经常需要调整和变化，这种灵活性是敏捷方法的核心。为了解决这些问题，敏捷方法强调持续反馈和自适应调整，确保每次变更都能以增量的方式推进，提升软件开发的速度和质量。通过自适应和增量改进，敏捷过程能够应对不可预测的需求和变化。
|
|
|
SS3.3.2.1,SubSection,3,3.3.2.1 敏捷过程的三大假设,"任何敏捷软件过程的特征都是以某种方式提出若干关键假设，这些假设适用于大多数软件项目：
|
|
|
1. 提前预测哪些需求是稳定的以及那些需求会变更是非常困难的。同样，预测项目开发过程中客户优先级的变更也很困难。
|
|
|
2. 对很多软件来说，设计和构建是交错进行的。也就是说，两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。
|
|
|
3. 分析、设计、构建和测试并不像我们设想的那么容易预测。（从制定计划的角度来看）。"
|
|
|
SS3.3.2.2,SubSection,3,3.3.2.2 敏捷过程的一个重要问题,"“如何建立能解决不可预测性的过程？”
|
|
|
答案就在于过程的可适应性（对于快速变更的项目和技术条件）。因此，敏捷过程必须具有可适应性"
|
|
|
S3.3.3,Section,3,3.3.3 人的因素,在敏捷开发中，人的因素至关重要，决定了团队是否能有效达成目标。首先，所有团队成员必须共同瞄准相同的目标，即在规定时间内向客户交付可运行的软件增量。为了达成这一目标，团队需不断做出适应性变化，以调整和优化工作过程。其次，团队成员之间以及团队与其他利益相关者之间的精诚合作是项目成功的基础。决策能力也是关键，敏捷团队需要有自由和权限在技术和项目管理上做出自主决策。此外，团队还需具备解决模糊问题的能力，应对不断变化和不可预见的挑战。相互信任与尊重是敏捷团队成功的核心，团队的凝聚力和协作能力使整体能力超过个体能力。最后，自组织是敏捷开发的一个关键特点，团队能够根据需要自主组织工作、选择适应的开发过程和进度安排，从而提升效率并增强团队合作与士气。
|
|
|
SS3.3.3.1,SubSection,3,3.3.3.1 构造而非选择,“敏捷开发关注个人的才智和技巧，根据特定人员和团队来塑造过程。”这一描述的关键点在于“构造可以满足人员及团队需求的过程模型”，而非选择其他的过程模型。
|
|
|
SS3.3.3.2,SubSection,3,3.3.3.2 对敏捷团队以及成员的要求,在软件工程中，敏捷团队及其成员需具备快速适应变化的能力，这是敏捷开发的核心。团队成员需拥有较高的个人技能和出色的合作能力，以应对软件开发过程中的各种挑战。同时，敏捷团队必须树立支持变化的思想，将变化视为推动项目进展的机遇。此外，持续改进和不断学习也是敏捷团队的重要特征，通过分享经验、知识和最佳实践，促进整个团队的成长和进步。这些要求共同构成了敏捷团队的核心竞争力，使其能够在快速变化的市场环境中保持领先地位，成功交付高质量的软件产品。
|
|
|
P3.3.3.2.1,Problem,3,3.3.3.2.1 基本能力,同在传统软件工程中一样，在敏捷开发中，“能力”一词包含了个人内在才能、特定的软件相关技能以及对所选过程的全局知识。
|
|
|
P3.3.3.2.2,Problem,3,3.3.3.2.2 共同目标,虽然敏捷团队成员能完成不同的任务，为项目提供不同的技能，但是所有人必须瞄准同一个目标，即在承诺的时间内向客户提交可运行的软件增量。为了实现这一目标，项目组还应当做出或大或小的连续的适应性变化，以使过程更适合于团队的需要。
|
|
|
P3.3.3.2.3,Problem,3,3.3.3.2.3 精诚合作,项目组成员之间，项目组与所有其他利益相关者之间必须精诚合作。
|
|
|
P3.3.3.2.4,Problem,3,3.3.3.2.4 决策能力,包括敏捷团队在内，任何一个好的软件项目组必须有能够掌握自身命运的自由。这意味着应当赋予项目组在技术和项目问题上的自主决策权。
|
|
|
P3.3.3.2.5,Problem,3,3.3.3.2.5 模糊问题解决能力,软件项目经理应当认识到：敏捷项目组被迫不断面对不确定的事情，被迫不断和变更作斗争。有时，项目组不得不接受今天正在解决的问题明天根本不需解决这样的现实。
|
|
|
P3.3.3.2.6,Problem,3,3.3.3.2.6 相互信任和尊重,敏捷团队必须成为具有凝聚力的团队，这样的团队展现出的相互信任和尊重使其形成“一个强有力的组织，确保整体的实力大于各部分实力之和”。
|
|
|
P3.3.3.2.7,Problem,3,3.3.3.2.7 自组织,"自组织在敏捷开发中具有三重含义：
|
|
|
（1）敏捷团队组织自身以完成工作 (组织团队)；
|
|
|
（2）团队组织最能适应当前环境的过程 (组织过程)；
|
|
|
（3）团队组织最好的进度安排以完成软件增量交付 (组织进度)。
|
|
|
|
|
|
自组织具有一些技术上的好处，但是更为重要的是它能促进合作，鼓舞士气。本质上，这也就是项目组的自我管理。"
|
|
|
T3.4,Topic,3,3.4 Scrum,"① 理解Scrum过程模型的基本概念。学习Scrum的起源和背景，了解Scrum的核心原则与敏捷宣言一致，掌握Scrum框架中的主要活动，如需求、分析、设计、演化和交付，了解如何通过“冲刺”模式组织开发过程。
|
|
|
② 掌握Scrum中的冲刺机制。理解“冲刺”在Scrum中的作用，学习如何通过设定时间盒（通常为30天）完成一个具体的工作任务，了解冲刺的目标、工作流程以及冲刺结束后的交付成果。
|
|
|
③ 了解Scrum团队的结构与角色。学习Scrum团队的组成，包括Scrum Master、产品负责人和开发团队等角色。了解这些角色在Scrum框架中的职责和相互协作方式，掌握团队如何高效合作并应对项目中的不断变化。
|
|
|
④ 掌握Scrum中的日常管理活动。学习Scrum的日常例会，包括每日15分钟的站立会议（Daily Scrum），了解如何通过每日的团队沟通跟踪进展、解决问题并调整计划，确保每个冲刺的顺利推进。"
|
|
|
S3.4.1,Section,3,3.4.1 Scrum团队和制品,Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。
|
|
|
S3.4.2,Section,3,3.4.2 冲刺规划会议,在开始每个冲刺之前，产品负责人会提出他的开发目标，以在即将开始的冲刺中完成增量。
|
|
|
S3.4.3,Section,3,3.4.3 每日Scrum会议,Scrum会议可帮助团队尽早发现潜在的问题。
|
|
|
S3.4.4,Section,3,3.4.4 冲刺评审会议,开发团队认为增量已完成时，就要召开冲刺评审会议，时间安排在冲刺结束时。
|
|
|
S3.4.5,Section,3,3.4.5 冲刺回顾,理想情况下，在开始另一个冲刺规划会议前， Scrum master将与开发团队一起安排一场3小时的“冲刺回顾”会议。在会议上，团队将讨论：在冲刺中哪些方面进展顺利？哪些方面需要改进？ 团队在下一个冲刺中将致力于改进什么？
|
|
|
T3.5,Topic,3,3.5 其他敏捷过程,"① 理解敏捷框架的多样性。学习软件工程历史上敏捷过程模型的演变，认识到不同敏捷框架的出现并广泛应用，了解它们如何通过不同的实践方法来优化软件开发过程和团队协作。
|
|
|
② 掌握常见的敏捷框架：极限编程（XP）。了解极限编程（XP）的核心理念和实践，学习其如何通过紧密的团队协作、频繁的交付和持续的客户反馈来提升软件质量和开发效率。
|
|
|
③ 了解看板（Kanban）和DevOps的基本概念。学习看板方法如何帮助团队通过可视化工作流和限制在制品来提高效率，掌握DevOps如何通过开发与运维的协作来加速软件交付并提升系统可靠性。
|
|
|
④ 比较不同敏捷框架的特点和适用场景。理解Scrum、XP、看板和DevOps的异同，掌握在不同项目和团队中选择合适的敏捷框架的策略，以实现更高效的软件开发和更好的客户满意度。"
|
|
|
S3.5.1,Section,3,3.5.1 XP框架,极限编程（XP）是一种广泛应用的敏捷软件开发方法，强调通过持续集成、频繁发布、用户反馈和简单设计来快速交付高质量的软件。XP的核心活动包括策划、设计、编码和测试，每个活动都有明确的实践和规则。
|
|
|
SS3.5.1.1,SubSection,3,3.5.1.1 极限编程介绍,"极限编程Extreme Programming是使用最广泛的敏捷过程。其具有三个特点：
|
|
|
1.是一些相互关联的准则和惯例的集合；
|
|
|
2.追求变更曲线平坦化；
|
|
|
3.适合于小团队、高风险的项目。"
|
|
|
SS3.5.1.2,SubSection,3,3.5.1.2 极限编程活动,XP使用面向对象方法作为推荐的开发范型，它包含了策划、设计、编码和测试4个框架活动的规则和实践。
|
|
|
P3.5.1.2.1,Problem,3,3.5.1.2.1 策划,"1.创建“故事”卡片，描述软件所需功能与特性，由客户用自然语言书写。
|
|
|
2.评估每个故事，确定开发成本（以周数为单位）。
|
|
|
3.客户与XP团队共同决定故事分组，确定下一个发行版本（软件增量）。
|
|
|
4.对发布版本做出基本承诺。
|
|
|
排序待开发故事：先实现快速、高权值、高风险的故事。
|
|
|
5.首个版本发布后，XP团队计算项目速度。
|
|
|
6.开发中，客户可增删改故事或调整权值，XP团队据此调整计划。"
|
|
|
P3.5.1.2.2,Problem,3,3.5.1.2.2 设计,"1.严格遵循KIS原则，即追求简洁而非复杂。避免为假定未来需求而设计额外功能。
|
|
|
2.推荐使用CRC卡来明确与当前软件增量相关的面向对象类。CRC卡包括类、责任和协作者。
|
|
|
3.在故事设计遇阻时，应立即构建可执行原型（Spike解决方案），通过实践验证设计，降低实现风险，并确认初步估计。
|
|
|
4.鼓励重构，即在保持代码外部行为不变的前提下，改进其内部结构。重构旨在优化设计和代码，但工作量随软件规模增长而显著增加。"
|
|
|
P3.5.1.2.3,Problem,3,3.5.1.2.3 编码,"1.推荐在故事开发和初步设计后，先开发覆盖所有故事的单元测试，再开始编码。这样能在编码完成后立即测试，提供即时反馈。
|
|
|
2.提倡结对编程，两人共用一台计算机开发代码，实时解决问题和保证质量，同时专注手头问题。
|
|
|
3.结对编程中，成员角色略有不同，一人负责编码细节，另一人确保编码标准。
|
|
|
4.完成工作后，代码需与其他人集成。团队或结对者自己负责集成，后者采用“连续集成”策略，避免兼容性和接口问题。"
|
|
|
P3.5.1.2.4,Problem,3,3.5.1.2.4 测试,"1.单元测试应使用自动框架，便于执行与重复，支持代码修改后的即时回归测试。
|
|
|
2.个人测试集成到“通用测试集”，每日系统验证，为XP团队提供进度指示并及早预警。
|
|
|
3.频繁小修比截止期前大修更省时。
|
|
|
4.XP验收测试由客户主导，针对用户故事实现的功能与特征。"
|
|
|
S3.5.2,Section,3,3.5.2 看板法,看板法（Kanban）是一种精益方法，专注于优化工作流和过程改进。它通过变更管理和服务交付两大核心要素来实现这一目标，强调团队自组织和灵活调整工作流程，以更好地响应客户需求和改进工作效率。
|
|
|
SS3.5.2.1,SubSection,3,3.5.2.1 看板法介绍,看板法是一种精益方法学，提供了描述改进过程或工作流的方法。
|
|
|
SS3.5.2.2,SubSection,3,3.5.2.2 看板法的6个核心实践,看板的六个核心实践总结为：首先，通过可视化工作流，使项目进展一目了然。其次，限制在制品数量，确保团队专注于当前任务，提高交付效率。接着，管理工作流，识别并消除浪费，优化流程。同时，明确过程策略，包括选择工作和定义完成标准，确保团队目标一致。此外，建立反馈循环，基于数据持续改进过程。最后，鼓励团队合作与参与，共同推动项目前进。这些实践共同构成了看板方法的核心，有助于团队高效、灵活地开发软件，持续交付价值。
|
|
|
P3.5.2.2.1,Problem,3,3.5.2.2.1 可视化工作流,1.使用看板图可视化工作流。看板图按列组织，分别表示软件功能的每个元素的发展阶段。板上的卡片应包含单个用户故事或最近发现的写在便利贴上的缺陷，团队会随着项目进展将标记从“要做”推进到“正在进行”，再到“已完成”。
|
|
|
P3.5.2.2.2,Problem,3,3.5.2.2.2 限制工作负荷,2.在给定时间内要限制当下工作负荷。鼓励开发人员在开始另一项任务之前完成当前任务。这将缩短交付时间，提高工作质量，并提高团队向利益相关者频繁交付软件功能的能力。
|
|
|
P3.5.2.2.3,Problem,3,3.5.2.2.3 减少浪费,3.通过了解当前价值流，分析停滞位置，定义变更以及实施变更来管理工作流以减少浪费。
|
|
|
P3.5.2.2.4,Problem,3,3.5.2.2.4 明确过程策略,4.明确的过程策略。制定清晰的过程策略，包括选择工作项目的理由和定义“完成”的标准。这有助于团队成员明确工作目标和期望，从而更加高效地完成任务。
|
|
|
P3.5.2.2.5,Problem,3,3.5.2.2.5 创建反馈循环,5.通过创建反馈循环聚焦持续改进，基于过程数据引入变更，并在进行变更后评价变更对过程的影响。
|
|
|
P3.5.2.2.6,Problem,3,3.5.2.2.6 变更中的相互合作,6.在过程变更中相互合作，并根据需要让所有团队成员和其他利益相关人参与进来。这有助于增强团队的凝聚力和协作能力，确保项目的顺利进行。
|
|
|
SS3.5.2.3,SubSection,3,3.5.2.3 团队会议,看板法的团队会议与Scrum框架中的会议类似。如果将看板法引入现有项目，则并非所有项目都将在待定项栏目中启动。开发人员需要问自己:它们现在在哪里?它们从哪儿来?它们到哪里去?从而将自己的卡片放到团队过程栏。
|
|
|
S3.5.3,Section,3,3.5.3 DevOps,DevOps是一种促进开发与运维紧密协作的文化和实践方法，旨在打破传统上开发和运维之间的壁垒，提升软件交付和运维效率。它结合了敏捷开发和精益思想，强调自动化、持续集成、持续交付和持续监控。DevOps的核心理念是通过缩短开发周期、提高软件质量和提升客户满意度来实现快速、可靠的产品交付。这个方法不仅改变了开发和运维团队的工作方式，还推动了跨职能团队之间的协作，减少了沟通障碍和错误的发生。通过自动化测试、构建和部署，DevOps能够确保软件在开发过程中始终处于可部署状态，并能够快速响应业务需求变化。整个DevOps流程持续循环，通过不断反馈和优化来实现高效的工作流和持续改进。
|
|
|
SS3.5.3.1,SubSection,3,3.5.3.1 DevOps介绍,DevOps由Patrick DeBois创建，旨在将开发和运维相结合。DevOps尝试在整个软件供应链中应用敏捷和精益开发原则。DevOps通过快速响应客户的需求或希望的变化来提升客户体验。这可以提高品牌忠诚度，增加市场份额。像DevOps这样的精益方法可以通过减少重复劳动和转向更高业务价值的活动，为组织提供更强的创新能力。在消费者用到产品前，产品不会赚钱，而DevOps可以为生产平台提供更快的部署[Sha17]。
|
|
|
SS3.5.3.2,SubSection,3,3.5.3.2 DevOps的5个持续循环阶段,DevOps的五个持续循环阶段包括：持续开发，强调快速迭代和代码管理；持续集成，通过自动化构建和测试尽早发现问题；持续测试，利用自动化工具确保软件质量；持续部署/发布，自动化将新代码推入生产环境；持续监控，确保应用性能并收集使用信息。这些阶段形成了一个闭环，促进了开发与运营之间的紧密协作，加速了软件交付过程，同时提高了软件的质量和可靠性。通过自动化和持续改进，DevOps实践帮助团队快速响应变化，满足业务需求。
|
|
|
P3.5.3.2.1,Problem,3,3.5.3.2.1 持续开发,将软件可交付成果分解到多次冲刺中开发，增量由开发团队的质量保证成员进行测试。
|
|
|
P3.5.3.2.2,Problem,3,3.5.3.2.2 持续测试,自动化测试工具用于帮助团队成员同时测试多个代码增量，以确保在集成之前他们没有缺陷。
|
|
|
P3.5.3.2.3,Problem,3,3.5.3.2.3 持续集成,将具有新功能的代码段添加到现有代码和运行环境中，然后对其进行检查以确保部署后没有错误。
|
|
|
P3.5.3.2.4,Problem,3,3.5.3.2.4 持续部署,在此阶段，将继承代码部署（安装）到生产环境，其中包括准备接收新功能的分布在全球的多个站点。
|
|
|
P3.5.3.2.5,Problem,3,3.5.3.2.5 持续监控,开发团队成员的运维人员通过监控软件在生产环境中的性能，并在用户发现问题之前主动查找问题，以提高软件质量。
|
|
|
T3.6,Topic,3,3.6 小结,"在现代经济中，市场条件变化迅速，客户和最终用户的要求不断更新，新一轮竞争威胁会没有任何征兆地出现。从业者必须使软件工程工作保持敏捷——要定义灵活机动、有适应能力和精益的过程以适应现代商务的需求。
|
|
|
软件工程的敏捷理念强调4个关键问题:自组织团队对所开展工作具有控制力的重要性;团队成员之间以及开发参与者和客户之间的交流与合作;对“变更代表机遇”的认识;强调快速交付让客户满意的软件。敏捷过程模型能解决上述问题。
|
|
|
现实情况是，没有一种敏捷方法适合每个项目。敏捷开发人员在自主团队中工作，并有权创建自己的过程模型。
|
|
|
Scrum强调使用一组软件过程模式，这些模式已证明对时间紧迫、需求变更和业务关键的项目有效。Scrum团队没有理由不使用看板图来帮助其组织日常规划会议
|
|
|
极限编程(XP）按照策划、设计、编码和测试4个框架活动组织，并提出一系列新颖且有力的技术，以保证敏捷团队创建的体现利益相关者指定优先级特征和功能的软件能频繁发布。没有什么能部阻止人们使用DevOps技术来缩短部署时间。"
|
|
|
CH6,Subject,6,第6章 指导实践的原则,"① 理解软件工程实践的原则。学习软件工程实践中的四大核心要素：原则、概念、方法和工具，掌握它们如何共同作用，指导软件工程的实施。理解这些要素如何帮助开发团队高效、系统地完成软件开发任务。
|
|
|
② 掌握软件工程实践的关键概念。通过实践原则，理解软件开发过程中涉及的各类概念，如设计原则、开发方法和工具应用。学习如何运用这些概念和原则确保软件开发的质量与效率。
|
|
|
③ 认识工具在软件工程中的重要性。学习软件工程中工具的作用，了解工具如何支持方法的应用并帮助团队实现软件开发目标。理解如何选择合适的工具支持实践过程，提高开发效率和质量。
|
|
|
④ 强化质量保障措施与敏捷适应性。掌握如何通过质量保障措施来确保工作产品的质量，理解快速、安全驾驶的技术应用，认识到在软件开发过程中对技术的适应性要求。学习如何处理软件工程中的变化，确保软件质量在开发过程中得到保证。"
|
|
|
T6.1,Topic,6,6.1 核心原则,"① 理解软件工程的核心原则。学习软件工程中的核心原则，理解它们如何在过程层面为软件开发提供哲学基础，帮助团队有效执行框架活动和普适性活动，以确保开发出符合需求的高质量软件。
|
|
|
② 掌握核心原则在实践中的应用。学习这些核心原则如何转化为具体的价值观和规则，指导团队在分析问题、设计解决方案、实现和测试过程中做出正确的决策，确保每个开发阶段的质量与效率。
|
|
|
③ 认识核心原则对软件部署的影响。了解核心原则如何在软件最终部署阶段发挥作用，确保软件能够顺利交付用户并满足其使用需求。掌握如何通过遵循这些原则优化软件的发布和后期维护。
|
|
|
④ 加强问题分析和解决方案设计的能力。学习如何运用核心原则分析软件开发中的问题，并基于这些原则设计、实现、测试和部署高效的解决方案，确保整个软件开发过程的顺利进行。"
|
|
|
S6.1.1,Section,6,6.1.1 指导过程的原则,软件过程在软件工程中至关重要，不同的项目和团队需要不同的过程模型。因此，团队必须根据自身的需求来调整和适应过程。无论选择什么样的过程模型，它都应该包含通用过程框架中的基本元素，这些元素有助于确保项目的顺利进行。通过遵循核心原则，可以优化过程，确保软件开发的质量和效率。这些原则可以延伸到任何软件过程的实施中，为团队提供指导，帮助他们更好地应对项目中的各种挑战。
|
|
|
SS6.1.1.1,SubSection,6,6.1.1.1 介绍,在软件工程领域，指导过程的原则是确保项目顺利进行、提高开发效率并保证软件质量的核心指导方针。这些原则不仅为软件开发团队提供了明确的方向和框架，还帮助团队在复杂多变的环境中保持高效、灵活和可持续的发展。通过遵循这些原则，团队能够更好地理解用户需求、制定有效的开发计划、管理变更和风险，并最终创造出有价值的工作产品。
|
|
|
SS6.1.1.2,SubSection,6,6.1.1.2 适用于通用过程框架的8个原则,在软件工程领域，通用过程框架的八个原则为软件开发提供了坚实的指导。它们共同构成了一套全面的方法论，旨在帮助团队在复杂多变的环境中保持高效、灵活和可持续的发展。遵循这些原则，团队能够更好地理解用户需求、制定有效的开发计划、管理变更和风险，并最终创造出有价值的工作产品。以下将详细探讨这些原则在软件工程中的应用和意义。
|
|
|
P6.1.1.2.1,Problem,6,6.1.1.2.1 原则1：敏捷,关于你所选择的过程模型是传统的还是敏捷的，敏捷开发的基本原则会提供判断方法。你所做的工作的每方面都应着重于活动的经济性——保持你的技术方法尽可能简单，保持你的工作产品尽可能简洁，无论何时尽可能根据具体情况做出决定。
|
|
|
P6.1.1.2.2,Problem,6,6.1.1.2.2 原则2：每一步都关注质量,每个过程活动、动作及任务的出口条件都应关注所生产的工作产品的质量。
|
|
|
P6.1.1.2.3,Problem,6,6.1.1.2.3 原则3：做好适应的准备,过程不是信奉经验，其中没有信条。必要的时候，就让你的方法适应于由问题、人员以及项目本身施加的限制。
|
|
|
P6.1.1.2.4,Problem,6,6.1.1.2.4 原则4：建立一个有效的团队,软件工程过程和实践是重要的，但最根本的还是人。必须建立一个彼此信任和尊重的自组织团队。
|
|
|
P6.1.1.2.5,Problem,6,6.1.1.2.5 原则5：建立沟通和协调机制,建立沟通和协调机制。项目失败是由于遗漏了重要信息，或是利益相关者未能尽力去创造一个成功的最终产品。这些属于管理的问题，必须设法解决。
|
|
|
P6.1.1.2.6,Problem,6,6.1.1.2.6 原则6：管理变更,管理变更。管理变更的方法可以是正式的或非正式的，但是必须建立一 种机制，来管理变更要求的提出、变更的评估、变更的批准以及变更实施的方式。
|
|
|
P6.1.1.2.7,Problem,6,6.1.1.2.7 原则7：评估风险,在进行软件开发时会出现很多问题。建立应急计划是非常重要的。某些应急计划会成为安全工程任务的基准(第18章)。
|
|
|
P6.1.1.2.8,Problem,6,6.1.1.2.8 原则8：创造能给别人带来价值的工作产品,唯有那些能为其他过程活动、动作或任务提供价值的工作产品才值得创造。每一个工作产品都会作为软件工程实践的一部分传递给别人。一定要确保工作产品所传达的是必要信息，不会模棱两可或残缺不全。
|
|
|
S6.1.2,Section,6,6.1.2 指导实践的原则,软件工程实践的核心目标是按时交付符合所有利益相关者要求的功能和特征的高质量、可运行的软件。为了实现这一目标，必须遵循一系列指导技术工作的核心原则。这些原则的优势在于它们适用于不同的分析方法、设计方法和构建技术，无论是使用何种程序设计语言、自动化工具，还是采用何种验证与确认方法，都能确保软件开发过程的高效与质量。这些原则为实践提供了通用的框架，帮助团队在技术实现中保持一致性和可靠性。
|
|
|
SS6.1.2.1,SubSection,6,6.1.2.1 介绍,"在软件工程实践中，我们的核心追求是按时交付高质量、可运行且满足所有利益相关者需求的功能与特性。这一崇高目标不仅要求我们在技术实现上精益求精，更需要在开发过程中遵循一系列指导实践的核心原则。
|
|
|
这些指导实践的原则，其独特优势在于跨越了不同的分析方法、设计方法和构建技术的界限，展现出强大的普适性和灵活性。无论我们采用何种程序设计语言、自动化工具，或是验证与确认方法，这些原则都能确保我们的软件开发过程既高效又富有质量。它们为我们提供了一个通用的框架，使团队在技术实现的道路上能够保持高度的一致性和可靠性，从而有效应对开发过程中的各种挑战"
|
|
|
SS6.1.2.2,SubSection,6,6.1.2.2 指导实践的8个原则,指导实践的8个原则在软件工程领域中至关重要，它们包括分治策略以简化问题、需求抽象以提炼功能、模块化以提高可维护性、信息隐藏以保护模块完整性、状态转换以控制运行流程、异常处理以增强健壮性、准时交付以满足用户需求，以及易于维护以确保软件长期可用性。这些原则共同构成了软件工程的核心指导思想，旨在开发出高质量、可维护且可扩展的软件产品。
|
|
|
P6.1.2.2.1,Problem,6,6.1.2.2.1 原则1：分治策略（分割和攻克）,"更具技术性的表达方式是：分析和设计中应经常强调关注点分离( Separation of Concerns, SoCs)。一个大问题分解为一组小元素(或关注点)之后就比较容易求解。"
|
|
|
P6.1.2.2.2,Problem,6,6.1.2.2.2 原则2：理解抽象的使用,在这一核心原则中， 抽象就是对系统中些复杂元素的简单化、用一个专业用语来交流信息。我使用报表这一抽象概念，是假设你可以理解什么是报表，报表表示的是目录的普通结构，可以将经典的功能应用其中。在软件工程实践中可以使用许多不同层次的抽象，每个抽象都通告或暗示着必须交流的信息。在分析和设计中，软件团队通常从高度抽象的模型开始(如报表)然后逐渐将这些模型提炼成软低层次的抽象(如专栏或SUM功能)。
|
|
|
P6.1.2.2.3,Problem,6,6.1.2.2.3 原则3：力求一致性,无论是创建分析模型、开发软件设计、开发源代码还是创建测试用例、一致性原则都建议采用用户熟悉的上下文以使软件易于使用。例如，为手机应用设计一个用户界面，一致的菜单选择、一致的色彩设计以及一致的可识别图标都有助于增强用户体验。
|
|
|
P6.1.2.2.4,Problem,6,6.1.2.2.4 原则4：关注信息传送,软件所涉及的信息传送是多方面的——从数据库到最终用户、从遗留的应用系统到WebApp、从最终用户到图形用户界面(GUI)、从操作系统到应用、从一个软件构件到另一个构件，这个列表几乎是无穷无尽的。在每一种情况下，信息都会流经界面，因而，就有可能出现错误、遗漏或者歧义的情况。这一原则的含义是必须特别注意界面的分析、设计、构建以及测试。
|
|
|
P6.1.2.2.5,Problem,6,6.1.2.2.5 原则5：构建能展示有效模块化的软件,对重要事务的分制(原则1)建立了软件的哲学.模块化则提供了实现这一哲学的机制。任何一个复杂的系统都可以被分割成许多模块(构件)、但是好的软件工程实践不仅如此，它还要求模块必须是有效的。也就是说，每个模块都应该专门集中表示系统中约束良好的一个方面。另外，模块应当以相对简单的方式与其他模块、数据源以及环境方面关联。
|
|
|
P6.1.2.2.6,Problem,6,6.1.2.2.6 原则6：寻找模型,软件工程师使用模式为他们过去遇到的问题进行分类，并重用其解决方案。通过允许复杂系统中的构件独立发展，可以将这些设计模式应用于更广泛的系程和系统集成问题。模式将在第14章中进一步讨论。
|
|
|
P6.1.2.2.7,Problem,6,6.1.2.2.7 原则7：在可能的时候，用大量不同的观点描述问题及其的解决办法,当我们用大量不同的观点检测一个问题及其求解方法时，就很有能获得更深刻的认识，并发现错误和遗漏。统一建模语言（UML）提供了一种从多个视角描述问题解决方案的方式。
|
|
|
P6.1.2.2.8,Problem,6,6.1.2.2.8 原则8：记住，有人将要对软件进行维护,从长期看，缺陷暴露出来时，软件需要修正；环境发生变化时，软件需要适应；利益相关者需要更多功能时，软件需要增强。如果可靠的软件工程能够贯穿于整个软件过程，就会便于这些维护活动的实施。
|
|
|
T6.2,Topic,6,6.2 指导每个框架活动的原则,"① 了解框架活动的指导原则。学习每个框架活动（如沟通、策划、建模、构建和部署）背后的核心原则，理解这些原则如何影响软件过程中的各个阶段，确保每个活动的顺利开展和高效执行。
|
|
|
② 掌握原则在具体框架活动中的应用。通过案例分析，学习如何将6.1节中提到的核心原则应用到具体的框架活动中，帮助软件开发团队应对不同阶段的挑战，优化每个环节的工作效果。
|
|
|
③ 认识不同框架活动的交互与影响。理解各个框架活动之间的关系及其如何协同工作，学习如何在不同活动间有效地切换和调整，以保证软件开发的连贯性和一致性。
|
|
|
④ 提高实际应用中的判断力和执行力。培养根据每个框架活动的原则做出正确决策的能力，帮助您在实际开发过程中更加敏捷和高效地应对变化和需求，确保最终交付的软件符合质量标准和用户期望。"
|
|
|
S6.2.1,Section,6,6.2.1 沟通原则,在分析、建模或规格说明之前，必须通过沟通活动收集客户的需求。对于某些客户问题，可能适合使用计算机进行求解，软件人员需要对客户请求做出响应，开始沟通。然而，从沟通到理解并非一帆风顺。高效的沟通，包括与其他技术人员、客户、利益相关者以及项目经理的沟通，往往是软件工程师面临的最大挑战之一。尽管沟通方式多种多样，但关键在于认识到，并非所有人在沟通手段的多样性和沟通的有效性方面具有一致性。有效的沟通不仅仅依赖于手段的丰富性，更依赖于如何确保信息准确、清晰地传递。
|
|
|
SS6.2.1.1,SubSection,6,6.2.1.1 介绍,在软件工程领域，沟通是确保项目成功的关键。从分析、建模到规格说明，每一步都需与客户深入沟通。高效沟通面临诸多挑战，需遵循一系列原则以确保信息准确传递。沟通方式多样，选择时需考虑对方特点和需求。本文探讨与客户沟通的原则，同样适用于项目内部沟通。沟通中需保持耐心和细心，倾听对方意见，及时反馈解决问题，并注重沟通技巧的运用，如清晰表达、积极倾听和有效反馈。总之，沟通原则是软件工程不可或缺的部分，遵循这些原则能更好与客户及利益相关者协作，推动项目成功实施。
|
|
|
SS6.2.1.2,SubSection,6,6.2.1.2 沟通的10个原则,"沟通，作为人类社会中不可或缺的一部分，无论是在日常生活还是工作领域，都发挥着举足轻重的作用。在软件工程领域，沟通更是项目成功的关键因素。为了确保项目顺利进行，我们需要遵循一系列沟通原则，以建立起有效的沟通桥梁。本文将介绍沟通的10个原则，这些原则旨在帮助我们在复杂的项目环境中，与团队成员、客户及其他利益相关者建立良好的沟通关系。
|
|
|
倾听、有准备的沟通、推动沟通活动、当面沟通、记录决定、保持通力协作、限定讨论范围、采用图形表示、灵活转换话题以及双赢协商，这10个原则共同构成了沟通的基础框架。遵循这些原则，我们将能够更有效地传递信息、解决冲突，并最终推动项目的成功实施。接下来，让我们逐一探讨这些原则，并深入理解它们在软件工程领域中的重要性。"
|
|
|
P6.2.1.2.1,Problem,6,6.2.1.2.1 原则1：倾听,在沟通之前，一定要确保你能够理解他人的观点，对对方的需求有所了解，然后再倾听。仔细倾听讲话者的每一句话，而不是急于叙述你对这些话的看法。如果有什么事情不清楚，可以要求他澄清，但是不要经常打断别人的讲述。当别人正在陈述的时候不要在言语或动作上表现出异议(比如转动眼睛或者摇头)。
|
|
|
P6.2.1.2.2,Problem,6,6.2.1.2.2原则2：有准备的沟通,在与其他人碰面之前花点时间去理解问题。如果必要的话，做一些调查来理解业务领域的术语。如果你负责主持一个会议，那么在开会之前准备一个议事日程。
|
|
|
P6.2.1.2.3,Problem,6,6.2.1.2.3 原则3：沟通活动需要有人推动,"每个沟通会议都应该有个主持人(推动者），其作用是：
|
|
|
(1)保持会议向着有效的方向进行；
|
|
|
(2)调解会议中发生的冲突；
|
|
|
(3)确保遵循我们所说的沟通原则。"
|
|
|
P6.2.1.2.4,Problem,6,6.2.1.2.4 原则4：最好当面沟通,但是，如果能以一些其他表示方式把相关信息是现出来，通常可以工作得更好，例如可以在集中讨论中使用草图或文档草稿。
|
|
|
P6.2.1.2.5,Problem,6,6.2.1.2.5 原则5：记笔记并且记录所有决定,任何解决方法都可能有缺陷。参与沟通的记录员应该记录下所有要点和决定。
|
|
|
P6.2.1.2.6,Problem,6,6.2.1.2.6 原则6：保持通力合作,当项目组成员的想法需要汇集在一起用以阐述一个产品或者某个系统的功能或特性时，就产生了协作与合作的问题。每次小型的协作都可能建立起项目成员间的相互信任，并且为项目组创建一致的目标。
|
|
|
P6.2.1.2.7,Problem,6,6.2.1.2.7 原则7：把讨论集中在限定的范围内,在任何交流中，参与的人越多，话题转移到其他地方的可能性就越大。推动者应该保持谈话模块化，只有某个话题完全解决之后才能开始别的话题(不过还应该注意原则9)。
|
|
|
P6.2.1.2.8,Problem,6,6.2.1.2.8 原则8：如果某些东西很难表述清楚，就采用图形表示,语言沟通的效果很有限，当语言无法表述某项工作的时候，草图或者绘图通常可以让表述变得更为清晰。
|
|
|
P6.2.1.2.9,Problem,6,6.2.1.2.9 原则9：敏捷地转换话题,"交流如同所有其他软件工程活动一样需要时间，与其永无止境地迭代，不如让参与者认识到还有很多话题需要讨论(参见原则2),“转换话题”有时是达到敏捷交流的最好方式。"
|
|
|
P6.2.1.2.10,Problem,6,6.2.1.2.10 原则10：协商不是一场竞赛或者一场游戏，双赢才能发挥协商的最大价值,很多时候软件工程师和利益相关者必须商讨一些问题，如功能和特性、优先级和交付日期等。若要团队合作得好，那么各方要有一个共同的目标，并且协商还需要各方的协调。
|
|
|
S6.2.2,Section,6,6.2.2 策划原则,策划活动包括一系列管理和技术实践，旨在为软件开发团队提供一条清晰的路线图，帮助团队朝着战略目标和战术目标前进。尽管我们可以付出很多努力，但无法准确预测软件项目的进展，也不存在简单的方法可以解决所有可能出现的问题：无法预见的技术问题、项目后期未掌握的重要信息、可能出现的误解以及商务环境的变化。然而，软件团队依然必须制定计划，而这些计划通常是迭代性的。最初的计划会基于已识别的风险和项目范围进行，然后随着项目的推进，团队会不断修改和调整计划，通过多次迭代评估风险并进行相应的修正，直到风险得到有效消除，确保项目朝着预定目标发展。
|
|
|
SS6.2.2.1,SubSection,6,6.2.2.1 介绍,软件工程中的策划原则对项目成功至关重要。它们为开发团队提供清晰路线图，指引团队向战略目标前进。尽管项目进展难以预测，但制定计划仍是必要，它能帮助团队保持方向感，快速适应变化。策划需平衡计划的详细度与迭代性，过度计划可能徒劳无功，而缺乏计划则易引发混乱。因此，制定计划时应结合项目实际和团队能力，确保计划既具指导性又具灵活性。总之，遵循策划原则，包括连续性和反馈循环等，并适度调整计划详细度和迭代性，有助于团队保持方向，适应变化，确保项目成功。
|
|
|
SS6.2.2.2,SubSection,6,6.2.2.2 策划的10个原则,软件工程中的策划原则是确保项目成功的基石。这些原则涵盖了从理解项目范围到适应变化的多个方面，为软件开发团队提供了清晰的指导。通过让利益相关者参与策划，团队可以确保项目的需求和约束得到充分考虑。同时，认识到计划的制定应按照迭代方式进行，有助于团队灵活应对项目中的不确定性。此外，基于已知的估算、考虑风险、保证可实现性、调整计划粒度、确保质量以及描述如何适应变化等原则，都是制定成功项目计划不可或缺的部分。最后，经常跟踪并根据需要调整计划，是确保项目按时交付、满足质量要求的关键。遵循这些策划原则，软件开发团队将能够高效、有序地推进项目，最终取得成功。
|
|
|
P6.2.2.2.1,Problem,6,6.2.2.2.1 原则1：理解项目范围,如果你不知道要去哪里，就不可能使用路线图。范围可以为软件开发团队提供一个目的地。
|
|
|
P6.2.2.2.2,Problem,6,6.2.2.2.2 原则2：让利益相关者参与策划,为了适应这种情况，软件工程师必须经常商谈交付的顺序、时间表以及其他与项目相关的问题。
|
|
|
P6.2.2.2.3,Problem,6,6.2.2.2.3 原则3：要认识道计划的指定应按照迭代方式进行,在工作开始的时候，有很多事情有可能改变，那么就必须调整计划以适应这些变化。另外，在付每个软件增量之后，迭代式增量过程模型应该包含根据用户反馈的信息来修改计划的时间。
|
|
|
P6.2.2.2.4,Problem,6,6.2.2.2.4 原则4：基于已知的估算,"估算的目的是基于项目组对将要完成工作的当前理解，提供一种关于工作量、成本和任务工期的指标。如果信息是含糊的
|
|
|
或者不可靠的，估算也将是不可靠的。"
|
|
|
P6.2.2.2.5,Problem,6,6.2.2.2.5 原则5：计划时考虑风险,如果团队已经明确了哪些风险最容易发生且影响最大，那么应急计划就是必需的了。另外，项目计划（包括进度计划）应该可以调整，以适应那些可能发生的一种或多种风险。
|
|
|
P6.2.2.2.6,Problem,6,6.2.2.2.6 原则6：保证可实现性,人们不能每天百分百地投入工作。变化总是在发生。甚至最好的软件工程师都会犯错误，这些现实情况都应该在项目制定计划的时候考虑。
|
|
|
P6.2.2.2.7,Problem,6,6.2.2.2.7 原则7：调整计划粒度,粒度指的是表示或者执行某些计划要素的细节。“细粒度”的计划可以提供重要的工作任务细节，这些细节是在相对短的时间段内计划完成的（这样就常常会有跟踪和控制的问题)。“粗粒度”的计划提供了更宽泛的长时间工作任务。通常，粒度随项目的进行而从细到粗。在很多个月内都不会发生的活动则不需要细化（太多的东西将会发生变化）。
|
|
|
P6.2.2.2.8,Problem,6,6.2.2.2.8 原则8：制定计划一确保质量,计划中应该确定软件开发团队如何确保开发的质量。如果要执行正式技术评审°的话，应该将其列入进度；如果在构建过程中用到了结对编程（第3章)，那么在计划中要明确描述。
|
|
|
P6.2.2.2.9,Problem,6,6.2.2.2.9 原则9：描述如何适应变化,即使最好的策划也有可能被无法控制的变化破坏。软件开发团队应该确定在软件开发过程中如何适应变化，例如，客户会随时提出变更吗？如果提出了一个变更，团队是不是要立即实现？变更会带来怎样的影响和开销？
|
|
|
P6.2.2.2.10,Problem,6,6.2.2.2.10 原则10：经常跟踪并根据需要调整计划,项目每次会落后进度一天的时间。因此，需要每天都追踪计划的进展，找出计划与实际执行不一致的问题所在，当任务进行出现延误时，计划也要随之做出调整。
|
|
|
S6.2.3,Section,6,6.2.3 建模原则,通过创建模型，我们能够更好地理解和构建软件实体。当实体是物理对象时，我们可以构建与实物相似的3D模型，但在软件开发中，模型呈现的形式有所不同。软件模型必须能够描述信息转换的过程、体系结构、功能、用户需求的特性以及系统行为。模型需要在不同的抽象层次上进行描述，从客户需求出发，然后逐步深入到更技术性的细节。软件工程中通常需要构建两类模型：需求模型和设计模型。需求模型通过描述信息、功能和行为来表达客户需求，而设计模型则聚焦于系统架构、用户界面和构件细节，帮助开发人员高效开发软件。敏捷开发中的建模强调快速设计和反馈循环，并通过原型构造和模型快速设计来加速开发过程。
|
|
|
SS6.2.3.1,SubSection,6,6.2.3.1 介绍,"软件工程中的建模原则为开发者提供了一种理解和设计软件的有效方法。通过创建模型，我们能够更深入地理解需要构建的实体，无论是物理实物还是软件。对于软件而言，模型必须能够表现出软件所转换的信息、体系结构、功能、用户要求的特性以及系统行为。这些原则强调了在不同的抽象层次下完成这些目标的重要性，从客户的角度描述软件，再到更侧重于技术的方面表述软件。
|
|
|
Scott Ambler和Ron Jeffries在他们关于敏捷建模的书中定义的一系列建模原则值得认同。这些原则不仅适用于使用敏捷过程模型的人，也适用于所有执行建模活动和任务的软件工程师。这些原则强调了抽象程度的重要性，以及输入输出在执行建模活动和任务时的关键作用。通过遵循这些原则，我们可以更高效地创建需求模型和设计模型，从而更好地满足客户的需求，提高软件的质量和开发效率。
|
|
|
总的来说，软件工程中的建模原则为我们提供了一种结构化的方法来理解和设计软件，它强调了抽象、沟通、快速设计、部署、交付与反馈的重要性，有助于我们更好地应对软件开发的复杂性和不确定性。"
|
|
|
SS6.2.3.2,SubSection,6,6.2.3.2 建模的10个原则,在敏捷软件开发的背景下，建模的原则显得尤为重要。建模不仅是为了理解软件，更是为了快速、有效地构建和交付高质量的产品。本文总结了建模的10个关键原则，旨在指导软件团队如何高效地进行建模工作。这些原则包括：以构建软件为目标，避免不必要的模型；轻装前进，减少模型创建时间；追求简单，创建易于理解和维护的模型；适应变化，构建灵活的模型；明确模型目的，避免无意义的工作；调整模型以适应系统需求；追求实用而非完美；灵活选择构造方法，注重信息传递；相信直觉，及时发现问题；快速获得反馈，不断优化模型。遵循这些原则，软件团队将能够更高效地构建出满足用户需求的高质量软件。
|
|
|
P6.2.3.2.1,Problem,6,6.2.3.2.1 原则1：软件团队的主要目标是构建软件而不是创建模型,敏捷的意义是尽可能快地将软件提供给用户。可以达到这个目标的模型是值得软件团队构建的，但是，我们需要避免那些降低了开发过程的速度以及不能提供新的见解的模型。
|
|
|
P6.2.3.2.2,Problem,6,6.2.3.2.2 原则2：轻装前进——不要创建任何不需要的模型,每次发生变化时，创建的模型必须是最新的。更重要的是，每创建一个新模型所花费的时间，还不如花费在构建软件（编码或测试)。因此，只创建那些可以使软件的构建更加简便和快速的模型。
|
|
|
P6.2.3.2.3,Problem,6,6.2.3.2.3 原则3：尽量创建能描述问题和软件的最简单模型,不要建造过于复杂的软件保持模型简单，产生的软件必然也会简单。最终的结果是，软件易于集成、易于测试且易于维护（对于变更）。另外，简单的模型易于开发团队成员理解和评判，从而使得持续不断的反馈可以对最终结果进行优化。
|
|
|
P6.2.3.2.4,Problem,6,6.2.3.2.4原则4：用能适应变化的方式构建模型,假设模型将要发生变化，但做这种假设并不草率。问题在于，如果没有相当完整的需求模型，那么所创建的设计（设计模型）会常常丢失重要功能和特性。
|
|
|
P6.2.3.2.5,Problem,6,6.2.3.2.5 原则5：明确描述创建每一个模型的目的,每次创建模型时，都问一下自己为什么这么做。如果不能为模型的存在提供可靠的理由，就不要再在这个模型上花费时间。
|
|
|
P6.2.3.2.6,Problem,6,6.2.3.2.6 原则6：调整模型来适应待开发系统,例如，一个电子游戏应用需要的建模技术与自动驾驶汽车所使用的实时嵌入式的巡航定速软件所需的建模技术或许会完全不同。
|
|
|
P6.2.3.2.7,Problem,6,6.2.3.2.7 原则7：尽量构建有用的模型而不是完美的模型,当构建需求模型和设计模型时，软件工程师要达到减少返工的目的。也就是说，努力使模型绝对完美和内部一致的做法是不值当的。无休止地使模型“完美”并不能满足敏捷的要求。
|
|
|
P6.2.3.2.8,Problem,6,6.2.3.2.8 原则8：对于模型的构造方法不要过于死板。,如果模型能够成功地传递信息，那么表述形式是次要的。虽然软件团队的每个人在建模期间都应使用一致的表达方式，但模型最重要的特性是交流信息，以便软件工程执行下一个任务。如果模型可以成功地做到这一点，不正确的表达方式就可以忽略。
|
|
|
P6.2.3.2.9,Problem,6,6.2.3.2.9 原则9：仔细注意模型,如果你是个有经验的软件工程师，就应相信直觉。软件工作中有许多教训——其中有些是潜意识的。如果有些事情告诉你设计的模型注定会失败（尽管你不能明确地证明），你就有理由再花一些时间来检查模型或开发另一个模型。
|
|
|
P6.2.3.2.10,Problem,6,6.2.3.2.10 原则10：尽可能快地获得反馈,任何模型都是为了传递信息，模型应该能够独立地表达信息，不需要任何人去解释它。每个模型都应经过软件团队的评审。评审的目的是提供反馈，用于纠正模型中的错误、改变误解，并增加不经意遗漏的功能和特性。
|
|
|
S6.2.4,Section,6,6.2.4 构建原则,构建活动是软件开发中的一个关键阶段，涉及编码和测试任务，以确保最终交付给客户和用户的是可运行的软件。在现代软件工程中，编码可以通过多种方式进行：直接编写编程语言的源代码，使用中间设计自动生成源代码，或通过使用第四代编程语言（如Unreal4Blueprints）自动生成可执行代码。最初的测试通常是构件级别的，也就是单元测试，旨在验证单个构件的功能是否正确。随着开发的推进，还需要进行其他级别的测试，包括集成测试（在构建系统时进行）、确认测试（验证系统是否按照需求开发）以及验收测试（由客户进行检验，确保系统满足所有功能和特性要求）。这些测试和测试用例设计在敏捷过程中的持续集成和快速反馈机制中占据了重要位置。
|
|
|
SS6.2.4.1,SubSection,6,6.2.4.1 介绍,构建原则是软件工程中的核心指导，确保编码和测试活动的高效与质量。现代编码实践多样化，从直接生成源代码到使用中间设计或第四代编程语言自动生成代码，均旨在提高开发效率。测试环节同样重要，包括单元测试、集成测试、确认测试和验收测试，确保软件功能、性能符合预期。构建原则强调代码可读性、可维护性，遵循最佳实践，注重测试覆盖率，及时反馈修复问题。遵循这些原则，软件开发团队能开发出更优秀、稳定、可靠的软件产品。
|
|
|
SS6.2.4.2,SubSection,6,6.2.4.2 编码原则,编码原则是在信息编码过程中需要遵循的一系列准则，旨在确保编码的准确性、高效性和可读性。这些原则包括确保编码能准确替代原信息、同一信息对象分配唯一编码、遵循标准和规范、以最小数据量负载最大信息量，以及编码具有一定的可扩展性以适应未来需求变化。遵循这些原则，可以确保信息编码的通用性、互操作性和易用性，提高信息处理的效率和准确性。在实际应用中，需要根据具体的信息类型和需求，选择合适的编码原则和方法进行编码设计。
|
|
|
P6.2.4.2.1,Problem,6,6.2.4.2.1 准备原则,"原则1：理解所要解决的问题。
|
|
|
原则2：理解基本的设计原则和概念。
|
|
|
原则3：选择一种能够满足构建软件以及运行环境要求的编程语言。
|
|
|
原则4：选择一种能提供工具以简化工作的编程环境。
|
|
|
原则5：构件级编码完成后进行单元测试。"
|
|
|
P6.2.4.2.2,Problem,6,6.2.4.2.2 编程原则,"原则6：遵循结构化编程方法来约束算法。
|
|
|
原则7：考虑使用结对编程。
|
|
|
原则8：选择能满足设计要求的数据结构。
|
|
|
原则9：理解软件体系结构并开发出与其相符的接口。"
|
|
|
P6.2.4.2.3,Problem,6,6.2.4.2.3 确认原则,"原则10：适当进行代码走查。
|
|
|
原则11：进行单元测试并改正所发现的错误。
|
|
|
原则12：重构代码来改进代码质量。"
|
|
|
SS6.2.4.3,SubSection,6,6.2.4.3 测试原则,测试原则是指在软件测试过程中需要遵循的一系列指导性原则。这些原则旨在确保测试的有效性、系统性和完整性。首先，测试的主要目标是查找程序错误，因此测试过程应以发现错误为核心。好的测试用例应能够最大限度地揭示尚未被发现的错误，而成功的测试则应能够找到这些错误。此外，测试并非仅仅为了证明软件的正确性，更重要的是要揭示软件中的潜在问题。在测试过程中，需要保持一个观念，即测试永远不是完全的，但可以通过系统的测试来最大限度地发现错误。同时，测试计划应在测试之前就开始制定，并追溯到用户需求，以确保测试的有效性和针对性。在测试策略上，可以应用Pareto原则，重点关注那些可能产生大量错误的程序构件。测试应从微观开始，逐步转向宏观，从单个模块到集成系统全面检测。最后，需要认识到穷举测试是不可能的，但可以通过充分覆盖程序逻辑和条件来确保测试的质量。总之，测试原则是确保软件测试质量和效率的重要保障。
|
|
|
P6.2.4.3.1,Problem,6,6.2.4.3.1 介绍,测试原则确保软件测试的有效性、系统性和完整性，旨在发现程序错误。好的测试用例能最大限度揭示未知错误，测试不仅证明软件正确性，更要揭示潜在问题。测试非完全但应系统，计划需提前制定并追溯用户需求。Pareto原则指导测试策略，重点关注易出错构件。测试从微观到宏观，充分覆盖逻辑和条件，虽穷举测试不可能，但可确保测试质量。
|
|
|
P6.2.4.3.2,Problem,6,6.2.4.3.2 原则1：所有的测试都应该可以追溯到用户需求,软件测试的目标就是要揭示错误。而最严重的错误（从用户的角度来看）是那种导致程序无法满足需求的错误。
|
|
|
P6.2.4.3.3,Problem,6,6.2.4.3.3 原则2：测试计划应该远在测试之前就开始着手,测试计划（第19章）在分析模型一完成就应该开始。测试用例的详细定义可以在设计模型确定以后开始。因此，所有的测试在编码前都应该计划和设计好了。
|
|
|
P6.2.4.3.4,Problem,6,6.2.4.3.4 原则3：将Pareto原则应用于软件测试,简单地说，Pareto原则认为在软件测试过程中80%的错误都可以在大概20%的程序构件中找到根源。接下来的问题当然就是要分离那些可疑的构件，然后对其进行彻底的测试。
|
|
|
P6.2.4.3.5,Problem,6,6.2.4.3.5 原则4：测试应该从“微观”开始，逐步走向“宏观”,最初计划并执行的测试通常着眼于单个程序模块，随着测试的进行，着眼点要慢慢转向在集成的构件簇中寻找错误，最后在整个系统中寻找错误。
|
|
|
P6.2.4.3.6,Problem,6,6.2.4.3.6 原则5：穷举测试是不可能的,即便是一个中等大小的程序，其路径排列组合的数目都非常庞大。因此，在测试中对每个路径组合进行测试是不可能的。然而，充分覆盖程序逻辑并确保构件级设计中的所有条件都通过测试是有可能的。
|
|
|
P6.2.4.3.7,Problem,6,6.2.4.3.7 原则6：为系统的每个模块做相应的缺陷密度测试,通常在最新的模块或者开发人员缺乏理解的模块中进行这些测试
|
|
|
P6.2.4.3.8,Problem,6,6.2.4.3.8 原则7：静态测试技术能得到很好的结果,有超过85%的软件缺陷源于软件文档（需求、规格说明、代码走查和用户手册）。这对系统文档测试是有价值的。
|
|
|
P6.2.4.3.9,Problem,6,6.2.4.3.9 原则8：跟踪缺陷，查找并测试未覆盖缺陷的模式,未发现的缺陷总数是软件质量好坏的指示器，未发现的缺陷类型可以很好地度量软件的稳定性。统计超时发现缺陷的模式可以预测缺陷的期望值。
|
|
|
P6.2.4.3.10,Problem,6,6.2.4.3.10 原则9：包含在演示软件中的测试用例是正确的行为,在维护和修改软件构件时，未预料到的交互操作会无意识地影响另外的一些构件。在软件产品变更后要准备检测系统行为，进行一组回归测试（第19章）是很重要的。
|
|
|
S6.2.5,Section,6,6.2.5 部署原则,部署活动是软件开发过程中至关重要的一环，涉及交付、支持和反馈三个动作。由于现代软件过程模型通常是演化式或增量式的，部署活动并非一次性完成，而是多个周期中的持续过程。在每个交付周期，都会向客户和最终用户提供一个具备可用功能和特性的可运行软件增量。每个支持周期会为交付的功能提供文档支持和人员帮助，而每个反馈周期则为开发团队提供反馈，指导修改软件功能、特性，并改进下一增量的开发方法。这一过程与传统的部署行为不同，其中包括组装部署包、建立支持方案、管理客户期望以及提供最终用户的指导材料等关键步骤。软件增量的交付是软件项目中的重要里程碑，开发团队必须遵循一些原则，确保每个软件增量交付符合预期，满足客户需求，并促进软件的持续改进。
|
|
|
SS6.2.5.1,SubSection,6,6.2.5.1 介绍,软件工程中，部署原则是指在准备将软件增量交付给最终用户时的一系列指导原则。这些原则强调交付、支持和反馈三个关键动作，并贯穿于整个软件开发周期。在交付阶段，需确保每个增量具备可用功能和特性；在支持阶段，提供必要文档和人员帮助；在反馈阶段，积极收集并分析用户反馈。此外，还需遵循组装部署包、建立支持方案、管理客户期望等原则，确保所有组件和依赖项正确打包配置，制定故障排查和恢复计划，以及让客户了解软件状态和未来计划。这些原则有助于软件顺利部署，满足用户需求。
|
|
|
SS6.2.5.2,SubSection,6,6.2.5.2 部署的5个原则,软件增量交付是软件项目的重要里程碑，需遵循五大原则。首先，管理客户期望，避免过度承诺导致失望。其次，确保交付完整的软件包，经过全面测试，适应各种计算配置。再者，提前确定技术支持，确保问题得到及时解决。同时，提供详尽的说明材料，包括培训、故障解决方案及版本差异说明。最后，坚持先改正缺陷再交付，避免低质量产品损害客户信任。这些原则有助于确保软件增量交付的成功和客户满意度。
|
|
|
P6.2.5.2.1,Problem,6,6.2.5.2.1 原则1：客户对于软件的期望必须得到管理,客户期望的结果通常比软件团队承诺交付的要多，这会很快令客户失望。这将导致客户反馈变得没有积极意义并且还会挫伤软件开发团队的士气。建议软件工程师必须认真地处理与客户有冲突的信息。（例如，对不可能在交付时完成的工作做出了承诺；在某次软件增量交付时交付了多于当初承诺要交付的工作，这将使得下次增量所要做的工作随之变少。）
|
|
|
P6.2.5.2.2,Problem,6,6.2.5.2.2 原则2：完整的交付包应该经过安装和测试,所有可执行软件、支持数据文件、支持文档和一些相关的信息都必须组装起来，并经过实际用户的完整测试。所有的安装脚本和其他一些可操作的功能都应该在所有可能的计算配置（例如硬件、操作系统、外围设备、网络)环境中实施充分的检验。
|
|
|
P6.2.5.2.3,Problem,6,6.2.5.2.3 原则3：技术支持必须在软件交付之前就确定下来,最终用户希望在问题发生时能得到及时的响应和准确的信息。如果技术支持跟不上或者根本就没有技术支持，那么客户会立即表示不满。支持应该是有计划的，准备好支持的材料并且建立适当的记录保持机制，这样软件开发团队就能按照支持请求种类进行分类评估。
|
|
|
P6.2.5.2.4,Problem,6,6.2.5.2.4 原则4：必须为最终用户提供适当的说明材料,必须为最终用户提供适当的说明材料。软件开发团队交付的不仅仅是软件本破身，也应该提供培训材料（如果需要的话）和故障解决方案，还应该发布关于“本次增量与以前版本有何不同”的描述。
|
|
|
P6.2.5.2.5,Problem,6,6.2.5.2.5 原则5：有缺陷的软件应该显改正再交付,迫于时间的压力，某些软件组织会交付一些低质量的增量，还会在增量中向客户提出警告：这些缺陷将在下次发布时解决。这样做是错误的。在软件商务活动中有这样一条谚语：“客户在几天后就会忘掉你所交付的高质量软件，但是他们永远忘不掉那些低质量的产品所出现的问题。软件会时刻提醒着问题的存在。”
|
|
|
T6.3,Topic,6,6.3 小结,"""需求建模的目标是创建各种表现形式，用其描述什么是客户需求，为生成的软件设计建立基础，一旦软件建立这些需求将用于验证。需求模型在系统级表示层和软件设计之间构造了桥梁。系统表示层描述了整个系统和业务功能，软件设计描述了软件应用的体系结构、用户接口和构建级的结构。
|
|
|
基于场景的模型从用户的角度描述软件需求。用例是主要的建模元素，它以叙述方式或以模板驱动方式描述了参与者和软件之间的交互活动。在需求获取过程中得到的用地定义了特定功能或交互活动的关键步骤。用例的正式程度和详细程度各不相同,但它们可以为所有的其他分析建模活动提供必要的输入。还可以使用活动图说明场景，活动图是描述特定场景内的处理流的图形表现形式。用例中的时序关系可以使用顺序图来建模。
|
|
|
为了识别分析类，基于类的建模使用从用例和其他编写的应用描述中导出的信息。可以使用语法解析从文本说明中提取候选类、属性和操作，并使用解析结果制定用于定义类的标准。
|
|
|
CRC索引卡可以用于定义类之间的联系。此外，可以使用各种UML建模方法定义类之间的层次、关系、关联、聚合和依赖。
|
|
|
在需求分析阶段的行为建模描述了软件的动态，行为建模采用来自基于场景和基于类的输入来表达分析类的状态。为达到这一目的，要识别状态，定义引起类（或系统）由一种状态转换到另一个状态的事件，还要识别完成转换后发生活动。UML状态图、活动图、泳道图和顺序图可以被用于行为建模。"""
|
|
|
CH8,Subject,8,第8章 需求建模——一种推荐的方法,"① 理解需求建模的基本概念和步骤。掌握需求建模的核心思想和方法，了解需求建模如何通过文字和图表的方式清晰地描绘软件的功能和使用方式。熟悉需求建模的三大步骤：基于场景建模、基于类建模和行为建模，理解其在软件开发中的重要性。
|
|
|
② 掌握用例和UML图的使用。学习如何利用用例（场景）描述软件功能，理解用例在捕捉需求中的作用。此外，学习如何通过UML图（如用例图、类图、时序图等）来展示系统的行为和其他方面，从而更加直观地表达需求。
|
|
|
③ 了解需求模型的评审方法。深入理解如何评审需求模型，确保其正确性、完整性和一致性。掌握如何通过与利益相关者的反馈循环，不断修正和完善需求模型，以减少开发过程中的风险。
|
|
|
④ 提高需求建模的质量保证能力。学习如何在需求建模过程中进行质量控制，确保所构建的需求模型能真实反映系统需求，并能够满足所有利益相关者的期望。了解评审和反馈的重要性，以及如何根据反馈调整需求模型。"
|
|
|
T8.1,Topic,8,8.1 需求分析,"① 理解需求分析的核心概念。需求分析是软件开发的关键阶段之一，它定义了软件操作特性、系统接口及其约束条件。您将学习如何通过需求分析细化和规范化软件需求，确保软件满足用户和其他系统的期望。
|
|
|
② 掌握不同类型的需求模型。需求分析过程中会生成多种模型类型，包括：
|
|
|
场景模型：从不同系统参与者的角度描述需求，常用于展示系统交互。
|
|
|
面向类的模型：描述系统中面向对象的类（包括类的属性和操作），以及这些类如何协作来实现系统需求。
|
|
|
行为模型：用于表示软件如何响应内外部事件。
|
|
|
数据模型：描述系统的信息域。
|
|
|
面向流的模型：描述系统的功能并展示功能元素在系统中的数据流动。
|
|
|
③ 基于场景的建模技术。本节重点讨论基于场景的建模方法，这是现代软件工程中最为流行的建模技术之一。学习如何通过场景模型捕捉系统的需求，如何从用户或系统参与者的角度描述功能需求，并转化为可操作的设计方案。
|
|
|
④ 需求模型与软件设计的关系。了解需求模型如何为后续的系统设计提供基础。这些模型不仅帮助设计者理解和构建系统架构、接口和构件级设计，还能在软件开发后期帮助客户和开发人员评估软件的质量。"
|
|
|
S8.1.1,Section,8,8.1.1 总体目标和原理,在分析建模过程中，软件工程师的主要关注点是确定系统应具备的功能和行为，而不是具体的实现方式。具体来说，分析师需要明确系统应如何与用户交互、处理哪些对象、执行哪些功能、展示何种行为、定义哪些接口以及有哪些约束等。尽管在此阶段难以获得完整的需求规格说明，客户和开发人员通常无法精确地定义所有细节，但这并不妨碍通过迭代的方法逐步完善需求分析和建模。需求模型的主要目标是描述客户需求、为后续的软件设计提供基础，并定义一组可以确认的软件需求。这些需求模型不仅为系统级描述和软件设计搭建桥梁，还确保所有设计元素能够直接追溯到需求模型中，帮助开发团队逐步推进系统的开发过程。
|
|
|
SS8.1.1.1,SubSection,8,8.1.1.1 主要关注点,"在整个需求建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面。包括：
|
|
|
在特定环境下发生哪些用户交互？
|
|
|
系统处理什么对象？
|
|
|
系统必须执行什么功能？
|
|
|
系统展示什么行为？
|
|
|
定义什么接口？
|
|
|
有什么约束？"
|
|
|
SS8.1.1.2,SubSection,8,8.1.1.2 三个主要目标,"需求模型的三个主要目标：
|
|
|
(1) 描述客户需要什么，分析正确性；
|
|
|
(2) 为软件设计奠定基础；
|
|
|
(3) 定义在软件完成后可以被确认的一组需求。"
|
|
|
S8.1.2,Section,8,8.1.2 分析的经验原则,在创建分析模型时，应该遵循一些经验原则以确保其有效性。首先，分析应聚焦于问题或业务域，并保持较高的抽象水平，这有助于清晰地定义系统的核心功能和需求。其次，分析模型应全面反映软件的信息域、功能和行为，为后续设计提供足够的信息。第三，涉及软件体系结构和非功能性细节的考虑应推迟到后期建模阶段，这有助于避免过早进入复杂的技术细节。最后，了解和分析软件元素之间的相互连接方式（即系统耦合）也是至关重要的，以确保系统整体的可维护性和扩展性。总体而言，分析模型的结构应简洁且清晰，同时为所有利益相关者提供价值。
|
|
|
SS8.1.2.1,SubSection,8,8.1.2.1 模型关注可见需求,模型应关注在问题或业务域内可见的需求，抽象的级别应该相对高一些。“不要陷入细节”，即不要试图解释系统将如何工作。
|
|
|
SS8.1.2.2,SubSection,8,8.1.2.2 模型元素存在即有用,需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。(存在即有用)
|
|
|
SS8.1.2.3,SubSection,8,8.1.2.3 基础结构和非功能模型暂缓考虑,关于基础结构和其他非功能的模型应推延到设计阶段再考虑。
|
|
|
SS8.1.2.4,SubSection,8,8.1.2.4 最小化整个系统内联,最小化整个系统内的关联。类和功能之间的联系非常重要，但是，如果“互联”的层次非常高，应该想办法减少互联。
|
|
|
SS8.1.2.5,SubSection,8,8.1.2.5 确认需求模型为所有利益相关者都带来价值,"确认需求模型为所有利益相关者都带来价值。对模型来说，每个客户都有自己的使用目的。
|
|
|
例如利益相关的业务人员将使用模型确认需求，设计人员将使用模型作为设计的基础；质量保证人员将使用模型帮助规划验收测试。"
|
|
|
SS8.1.2.6,SubSection,8,8.1.2.6 保持模型简洁,尽可能保持模型简洁。如果没有提供新的信息，不要添加附加图表；如果一个简单列表就够用，就不要使用复杂的表示方法。
|
|
|
S8.1.3,Section,8,8.1.3 需求建模原则,需求建模原则在过去几十年中不断发展，研究人员针对需求分析中遇到的问题及其根本原因，提出了多种建模方法和符号体系。每种分析方法都有其独特的视角，旨在帮助解决特定的需求定义和建模挑战。需求建模不仅仅是为了准确表达系统需求，还需处理在实际开发过程中可能遇到的模糊性和不确定性。为了有效地应用这些方法，分析师需要根据项目的特点和需求的复杂性，选择合适的建模方法，并灵活调整以适应不断变化的需求。通过合理的建模实践，团队能够在需求收集和分析阶段为后续的设计和实现打下坚实的基础。
|
|
|
SS8.1.3.1,SubSection,8,8.1.3.1 原则1：问题的信息域必须得到表达和理解,信息域包含流入系统（来自终端用户、其他系统或外部设备）的数据，流出系统（通过用户界面、网络界面、图形或者其他形式的数据，以及数据存储区中收集和整理的永久保存的数据。
|
|
|
SS8.1.3.2,SubSection,8,8.1.3.2 原则2：必须定义软件执行的功能,软件功能可以为终端用户带来直接好处，而那些为用户课件的功能提供内部支持的功能也可以直接受益。一些功能可以变换流入系统的数据。在其他情况下，功能会在某种程度上影响内部软件处理或外部系统元素的控制。
|
|
|
SS8.1.3.3,SubSection,8,8.1.3.3 原则3：必须表示软件的行为,计算机软件的行为受其与外部环境的交互作用的驱动。终端用户提供的输入、外部系统提供的控制数据或通过网络收集的监视数据都使软件以特定方式运行。
|
|
|
SS8.1.3.4,SubSection,8,8.1.3.4 原则4：描述信息、功能和行为的模型必须以分层的方式进行分割以揭示细节,需求建模是解决软件工程问题的第一步，为更好地理解问题并为解决方案（设计）建立基础。复杂的问题很难整体解决，因此应该使用分而治之的策略，将一个大而复杂的问题划分为多个子问题，直到每个子问题都相对容易理解为止。（关注点的划分或分离）
|
|
|
SS8.1.3.5,SubSection,8,8.1.3.5 原则5：分析任务应从基本信息转向实现细节,"分析建模首先从终端用户的角度描述问题。描述问题的“本质”时没有考虑解决方案的实现方式。
|
|
|
例如，电子游戏要求玩家在进入危险的迷宫时向其主角“指示”前进的方向（问题的本质）。
|
|
|
实现细节指出如何实现问题的本质。对于电子游戏，可能会使用语音输入、键入键盘指令、游戏手柄等方法实现。"
|
|
|
T8.2,Topic,8,8.2 基于场景建模,"① 理解基于场景建模的核心思想。基于场景建模强调从用户和系统参与者的角度出发，通过描述他们与系统的交互，帮助开发团队更好地理解需求。您将学到如何通过分析这些交互，生成更符合用户期望的系统设计。
|
|
|
② 掌握使用UML建模的技巧。基于场景建模的一个常见方法是使用UML（统一建模语言）。在需求建模阶段，UML可以帮助创建以下图表：用例图、活动图、序列图。
|
|
|
③ 强调用户满意度的重要性。用户满意度是衡量系统成功与否的关键指标。基于场景建模可以帮助开发团队更准确地捕捉用户需求，确保系统的功能设计和实现与用户的实际需求一致。
|
|
|
④ 将场景建模应用于需求分析。学习如何通过分析不同的交互场景，逐步构建系统的需求模型，并将这些模型转化为具体的设计蓝图。通过这种方式，需求不再是抽象的描述，而是通过可视化的UML图表为后续的开发提供清晰的指导。"
|
|
|
S8.2.1,Section,8,8.2.1 参与者和用户概要文件,UML参与者建模用于描述与系统对象交互的实体。参与者可以代表人类利益相关者或外部硬件角色，当这些实体通过交换信息与系统对象互动时，便形成了参与者与系统之间的交互。如果一个物理实体承担多个与系统功能相关的角色，那么多个参与者可能会代表同一个物理实体。UML概要文件（Profile）提供了扩展现有模型以适应其他域或平台的方式。这使得基于Web的系统模型可以被修改并应用于各种移动平台。此外，概要文件还可用于从不同用户的角度对系统进行建模。例如，系统管理员可能会从与最终用户不同的视角审视自动柜员机的功能。
|
|
|
SS8.2.1.1,SubSection,8,8.2.1.1 参与者,UML参与者对与系统对象进行交互的实体进行建模。
|
|
|
SS8.2.1.2,SubSection,8,8.2.1.2 用户概要文件,UML profile提供了一种将现有模型扩展到其他域或平台的方法。
|
|
|
S8.2.2,Section,8,8.2.2 创建用例,在分析建模中，用例描述了参与者如何与系统交互以实现特定目标。用例被视为“行为合同”，详细描述了系统与用户、信息产生者之间的交互。开发初始用例时，需要从特定参与者的角度出发，简洁地描述使用场景。为了确保用例具备价值，必须明确编写的内容、详细程度以及组织结构。通过需求收集和与利益相关者的沟通，开发者可以识别系统功能、确定参与者角色，并根据这些信息编写相应的用例。
|
|
|
SS8.2.2.1,SubSection,8,8.2.2.1 用例的定义,用例的定义 [Ivar Jacobson] ：用例只是帮助定义系统之外存在什么以及系统应完成什么。
|
|
|
SS8.2.2.2,SubSection,8,8.2.2.2 创建用例的疑问,"用例从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。问题是：
|
|
|
(1) 编写什么?
|
|
|
(2) 写多少?
|
|
|
(3) 编写说明应该多详细?
|
|
|
(4) 如何组织说明?"
|
|
|
P8.2.2.2.1,Problem,8,8.2.2.2.1 编写什么？,用例应该基于需求工程工作（起始和获取）提供的信息来编写，包括确定利益相关者、定义问题范围、说明运行目标、建立优先级顺序、概述功能需求以及描述系统将处理的信息（对象）。用例从特定参与者的角度出发，描述一个特定的使用场景，通常通过需求收集会议、与利益相关者的交流或评估活动图来获得
|
|
|
P8.2.2.2.2,Problem,8,8.2.2.2.2 写多少？,用例的数量取决于所需系统功能的列表，每个功能或活动都可能对应一个用例。随着与利益相关者的交谈增多，需求收集团队将为每个标记的功能开发用例。
|
|
|
P8.2.2.2.3,Problem,8,8.2.2.2.3 编写说明应该有多详细？,用例的描述可以是非正式的描述性风格，也可以是更正式的结构化形式。用例描述应该详细到能够捕捉信息的产生者、使用者和系统本身之间的交互，包括主场景和次场景，以及异常处理。
|
|
|
P8.2.2.2.4,Problem,8,8.2.2.2.4 如何组织说明？,"用例可以通过用户活动的顺序序列来表现交互，每个行动由声明性的语句表示。
|
|
|
组织说明时，应该包括主场景（主要的交互步骤）和次场景（可供选择的行为或错误条件）。
|
|
|
异常处理描述了导致系统展示出不同行为的场景，包括失败条件或参与者选择了替代方案。
|
|
|
组织用例时，可以使用“头脑风暴”来推动团队合理地完成每个用例中的异常处理。"
|
|
|
S8.2.3,Section,8,8.2.3 编写用例,在需求建模过程中，非正式用例通常足以应对基本需求描述。然而，当用例涉及复杂的步骤或包含大量异常处理时，便需要采用更正式的方法。正式用例通常包括情境目标、前提条件、触发器、具体场景和异常处理等关键要素。例如，在SafeHome的ACS-DCV用例中，情境目标定义了用例的范围，前提条件说明了初始化时需要了解的信息，触发器标识了用例开始的事件或条件，场景则列出了参与者和系统的特定活动。此外，还会考虑处理那些初始用例未涉及的情景。为了更好地呈现复杂场景，许多开发人员会使用图形化表示，UML图形化用例的能力可以帮助利益相关者更清楚地理解系统需求。
|
|
|
SS8.2.3.1,SubSection,8,8.2.3.1 为什么需要正式的用例描述？,当用例需要包括关键活动或描述具有大量异常处理的复杂步骤时，非正式用例可能不足以满足需求，因此需要更正式的方法。
|
|
|
SS8.2.3.2,SubSection,8,8.2.3.2 SafeHome监视的用例模板中包含的关键元素,包括用例名称、选代、主要参与者、情境目标、前提条件、触发器、场景、异常处理、优先级、何时有效、使用频率、参与者的连接渠道、次要参与者及其连接渠道、未解决的问题。
|
|
|
SS8.2.3.3,SubSection,8,8.2.3.3 图形化用户场景,"每种需求建模方法都有其局限性，用例方法也无例外：
|
|
|
1.如果描述不清晰，用例可能会误导或有歧义。
|
|
|
2.对于必须特别详细和精准的需求建模情景 (例如安全关键系统)，图形化的表示方法更有助于理解。"
|
|
|
T8.3,Topic,8,8.3 基于类建模,"① 理解基于类建模的核心概念。基于类的建模是一种面向对象的方法，重点在于通过识别和定义问题空间中的类及其属性和操作，构建系统模型。类建模帮助开发团队明确系统的基本组成元素和它们之间的关系，进而为设计和实现提供清晰的结构。
|
|
|
② 掌握类建模的基本步骤。学习如何从需求中识别出不同的类，并为每个类定义其属性和操作。类模型是系统设计的基础，帮助确定系统的主要功能和数据流。在UML中，类图是最常见的工具，它展示了系统中类与类之间的关系、继承、接口、关联等特性。
|
|
|
③ 识别和分类类的挑战。与物理世界的对象不同，软件中的类往往更抽象和复杂。基于类建模要求开发人员具有较高的抽象能力，能够从需求中提取出关键的类和它们之间的关系。这一过程对于设计面向对象的软件架构尤为重要。
|
|
|
④ 类与对象的关系。在面向对象的建模中，类是对一类对象的描述，而对象则是类的实例。理解类与对象之间的关系对于创建有效的类模型至关重要。
|
|
|
⑤ 将类建模与其他需求建模方法结合。基于类的建模不仅可以单独使用，还可以与场景建模（用例图）和行为建模结合，提供对系统更全面的理解。通过将类与用户交互场景以及系统行为联系起来，开发团队可以形成一个完整的需求模型，确保系统设计符合实际需求。"
|
|
|
S8.3.1,Section,8,8.3.1 识别分析类,通过分析需求模型中开发的使用场景，并对系统用例进行“语法解析”，可以开始识别分析类。识别过程通常通过检查每个名词或名词短语，给它们加上下划线，并将这些名词记录在一个简单的表格中，以确定类。同时，必须标记同义词。如果某个类（名词）被要求实现某个解决方案，那么这个类就属于解决方案空间的一部分；如果只是描述一个解决方案，那么这个类就不属于解决方案空间的一部分。
|
|
|
SS8.3.1.1,SubSection,8,8.3.1.1 识别类,"通过检查问题描述进行。
|
|
|
从名词中筛选：
|
|
|
①外部实体 (其他系统、设备、人员)
|
|
|
②事物 (报告、显示、字母、信号)
|
|
|
③偶发事件或事件
|
|
|
④角色 (经理、工程师、销售人员)
|
|
|
⑤组织单元 (部门、组、团队)
|
|
|
⑥场地 (制造车间或码头)
|
|
|
⑦结构 (传感器、四轮交通工具、计算机)
|
|
|
统称信息(过于宽泛)、基本属性(过于简单)、纯操作不宜选做类"
|
|
|
SS8.3.1.2,SubSection,8,8.3.1.2 分析类——寻找潜在类,"分析师考虑在每个潜在类是否应使用如下基本特征：
|
|
|
①保留信息：必须记录潜在类的信息才能保证系统正常工作
|
|
|
②所需服务：有一组可确认的，能改变属性值的操作
|
|
|
③多个属性：只有一个属性的类可能在设计中有用，但在分析阶段，更适合作为另一个类的某个属性
|
|
|
④公共属性：可定义一组属性，它们适用于该潜在类的所有实例
|
|
|
⑤公共操作：可定义一组操作，它们适用于该潜在类的所有实例
|
|
|
⑥必要需求：在问题空间中出现的外部实体、或者任何系统解决方案的运行所必需的信息
|
|
|
应注意到：
|
|
|
(1)某些被拒绝的潜在类将成为被接受类的属性；
|
|
|
(2)对问题的不同陈述可能导致作出“接受或拒绝”不同的决定。"
|
|
|
S8.3.2,Section,8,8.3.2 定义属性和操作,在定义分析类时，属性帮助明确类在问题空间中的意义。软件工程师需要通过研究用例，选择合理的事物并为每个类定义必要的属性。每个类应该能够回答哪些数据项能在问题环境内完整定义该类。例如，在SafeHome系统中，System类的属性可以包括识别信息、警报应答信息和激活/关闭信息，这些属性有助于清晰地定义类的功能和数据需求。
|
|
|
SS8.3.2.1,SubSection,8,8.3.2.1 属性定义,"为了给分析类开发一个有意义的属性集合，软件工程师应该研究用例并选择那些合理的""属于""类的""事物""。
|
|
|
|
|
|
属性： “属于”类的事物。
|
|
|
属性描述已经被选择包含在分析模型中的对象。在本质上，正是属性定义了对象——它们阐明了在问题空间中对象意味着什么。每个类都应回答如下问题：什么数据项（组合项或基本项）能够在当前问题环境内完整地定义这个类？此外，如果有超过一个项和某个类相关联，就应避免把这个项定义为属性。"
|
|
|
SS8.3.2.2,SubSection,8,8.3.2.2 操作定义,操作定义了某个对象的行为。尽管存在很多不同类型的操作，但通常可以粗略地划分为4种类型：(1）以某种方式操作数据（例如添加、删除、重新格式化、选择）;(2）执行计算的操作；(3）请求某个对象的状态的操作；(4）监视某个对象发生某个控制事件的操作。
|
|
|
S8.3.3,Section,8,8.3.3 UML类模型,分析师能通过考虑对象间所发生的通信获得对其他操作更为深入的了解。对象通过传递信息与另一个对象通信。在继续对操作进行说明之前，我们探测到了更详实的信息。在许多情况下，两个分析类以某种方式彼此关联。在UML中，这些关系称为关联。
|
|
|
S8.3.4,Section,8,8.3.4 类–职责–协作者建模,类-职责-协作者(CRC)建模提供了一种简洁的方法来识别和组织与系统需求相关的类。在CRC模型中，每个类的职责和协作者通过索引卡来表示，左侧列出类的职责，而右侧列出协作者——即能够提供所需信息或执行相关操作的类。职责代表了类的属性和操作，而协作者则是提供支撑这些职责的其他类。此方法有助于系统性地定义类及其交互关系。
|
|
|
SS8.3.4.1,SubSection,8,8.3.4.1 模型介绍,"类﹣职责﹣协作者（CRC）建模提供了一个简单方法，可以识别和组织与系统或产品需求相关的类。职责是和类相关的属性和操作。协作者是提供完成某个职责所需要信息或动作的类。
|
|
|
|
|
|
类，在前面的8.3.1节中已经介绍了识别类和对象的基本原则。
|
|
|
职责，8.3.2节介绍了识别职责（属性和操作）的基本原则。
|
|
|
协作。类用一种或两种方法来实现其职责，(1）类可以使用其自身的操作控制各自的属性，从而实现特定的职责；(2）类可以和其他类协作。要识别协作可以通过确认类本身是否能够实现自身的每个职责。如果不能实现每个职责，那么需要和其他类交互。"
|
|
|
SS8.3.4.2,SubSection,8,8.3.4.2 拓展类的三种分类方式,"1.实体类，也称模型或业务类，是从问题说明中直接提取出来的。
|
|
|
2.边界类用于创建用户可见的和在使用软件时交互的接口(如交互屏幕或打印的报表)。
|
|
|
3.控制类用于管理“工作单元”。控制类可以管理：
|
|
|
(1) 实体类的创建或更新；(2) 边界类获取信息后的实例化。(3) 对象集合间的复杂通信。(4) 对象间或用户和应用系统间交换数据的确认。"
|
|
|
SS8.3.4.3,SubSection,8,8.3.4.3 职责的5个指导原则,在软件工程的类-职责-写作者建模中，职责的分配至关重要。首先，智能系统应合理分布在各类中，避免职责过度集中或分散，以提高内聚性和可维护性。其次，职责说明应具有普遍性，特别是在上层类中，以保持通用性。同时，信息和行为应封装在同一类中，实现面向对象的封装原则。此外，特定事物的信息应由单独类负责，避免信息分散。最后，相关类应共享职责，特别是在需要同时展示相同行为时，以实现代码复用和减少冗余。这些原则共同指导了软件工程中职责的合理分配，有助于提高软件的质量和可维护性。
|
|
|
P8.3.4.3.1,Problem,8,8.3.4.3.1 智能系统应分布在所有类中以求最佳地满足问题的需求,"1.把“不灵巧”类(几乎没有职责的类)作为一些“灵巧”类(有很多职责的类)的从属。
|
|
|
2.每个对象只了解和执行一些事情 (通常是适度集中)，并提高系统的内聚性，这将提高软件的可维护性并减少变更的副作用影响。
|
|
|
3.应该评估每个CRC模型索引卡上标记的职责，以确定某个类是否应该具有超长的职责列表，如果有这种情况就表明职责太集中，需要将一个类分成多个类或子系统。
|
|
|
4.每个类的职责应表现在同一抽象层上；"
|
|
|
P8.3.4.3.2,Problem,8,8.3.4.3.2 每个职责的说明应尽可能具有普遍性,在类的层级结构的上层保持职责 (属性和操作)的通用性，(因为它们更有一般性，将适用于所有的子类)。
|
|
|
P8.3.4.3.3,Problem,8,8.3.4.3.3 信息和与之相关的行为应放在同一个类中,这实现了面向对象原则中的封装，数据和操作数据的处理应包装在一个内聚单元中。
|
|
|
P8.3.4.3.4,Problem,8,8.3.4.3.4 某个事物的信息应局限于一个类中而不要分布在多个类中,通常应由一个单独的类负责保存和操作某特定类型的信息。通常这个职责不应由多个类分担。如果信息是分布的，软件将变得更加难以维护，测试也会面临更多挑战。
|
|
|
P8.3.4.3.5,Problem,8,8.3.4.3.5 职责应由相关类共享,"很多情况下，各种相关对象必须在同一时间展示同样的行为；
|
|
|
例如，一个视频游戏，必须显示如下类：Player, PlayerBody, PlayerArms, PlayerLegs, PlayerHead。每个类都有各自的属性，并且所有这些属性都需要在用户操作游戏时进行更新和显示。因此，每个对象必须共享职责update()和display()。"
|
|
|
SS8.3.4.4,SubSection,8,8.3.4.4 协作的必要性,协作在软件工程中至关重要。当对象为实现其职责需与其他对象交互时，便产生了协作。协作促进了对象间的信息共享和功能互补，使得对象能够共同完成任务，实现复杂业务逻辑。当类无法单独实现所有职责时，与其他类协作变得尤为必要。这种协作提高了软件的灵活性、可扩展性和健壮性，使得系统更加易于维护。因此，在软件设计过程中，我们需仔细识别对象间的协作关系，设计合理的协作机制，以确保系统高效运行并满足用户需求。协作是软件设计中不可或缺的一环，对于提升软件质量具有重要意义。
|
|
|
SS8.3.4.5,SubSection,8,8.3.4.5 评审模型,当开发出一个完整的CRC模型时，利益相关者代表可以使用如下方法评审模型1．所有参加（CRC模型）评审的人员拿到一部分CRC模型索引卡。每个评审员不能有两张存在协作关系的卡片。2．评审组长细致地阅读用例。当评审组长看到一个已命名的对象时，给拥有相应类索引卡的人员一个令牌。3．当令牌传递时，该类卡的拥有者需要描述卡上记录的职责。评审组确定（一个或多个）职责是否满足用例需求。4．如果发现错误，则对索引卡进行修改。修改可能包括定义新类（和相关的CRC索引卡），或者在已有的卡上修改职责和协作列表。
|
|
|
T8.4,Topic,8,8.4 功能建模,"① 理解功能建模的核心概念。功能建模旨在描述系统所提供的各项功能，特别是用户可观察到的功能。这些功能包括用户直接启动的操作或任务，通过应用程序提供给最终用户的可见功能。例如，金融移动APP中的支付计算功能就是一个典型的用户可观察功能。功能模型帮助分析这些功能如何通过系统内的不同操作和类实现。
|
|
|
② 区分用户可观察的功能与内部实现功能。在功能建模中，重要的是理解用户可观察到的功能与分析类操作之间的关系。用户所看到的功能（如计算抵押贷款金额）是由一系列分析类操作（类中的方法）实现的。功能模型不仅关注最终用户体验，还关注如何通过系统内部的行为来实现这些功能。
|
|
|
③ 探索功能与类操作之间的关系。分析类中的操作是功能建模的关键组成部分。这些操作定义了类的行为，通过操控类的属性并协作完成特定任务，从而实现最终用户所要求的功能。因此，理解这些操作如何在不同类之间协作至关重要。
|
|
|
④ 建模层次化的过程抽象。功能建模涉及多个层次的抽象，通常从更高层次的用户可见功能开始，到较低层次的实现细节。通过这种方式，功能模型帮助开发人员理解每个功能如何与系统的其他部分交互，以及如何从需求到实现逐步转化。
|
|
|
⑤ 将功能建模与其他建模方法结合。功能建模不仅是独立的建模方法，通常与类建模、行为建模等方法一起使用。功能模型帮助明确软件如何运作，而类模型则确保有适当的结构和操作来支持这些功能。"
|
|
|
S8.4.1,Section,8,8.4.1 介绍,UML活动图用于表示处理细节，特别在功能复杂的分析阶段中有所应用。它通过图形化的方式展示特定场景内的交互流，补充用例的描述，类似于流程图。活动图中的圆角矩形代表特定的系统功能，箭头指示信息或控制流的传递，菱形表示决策点，标记出每个可能的流向，而水平线则表示并行活动的发生。这些元素帮助软件工程师明确地描述系统如何在不同情境下运行。
|
|
|
S8.4.2,Section,8,8.4.2 过程视图,无论过程抽象的层次如何，UML活动图都可以用来表示处理细节。从分析阶段，仅在功能相对复杂的情况下才会使用活动图。UML活动图通过提供特定场景内交互流的图形化表示来补充用例，类似于流程图。活动图使用圆角矩形表示特定的系统功能，箭头表示通过系统的流，菱形表示决策分支（标记菱形发出的每个箭头），实水平线表示并行发生的活动。
|
|
|
S8.4.3,Section,8,8.4.3 UML顺序图,"UML 顺序图可用于行为建模。顺序图还可用于显示事件如何引发从一个对象到另一个对象的转移。一旦通过检查用例确定了事件，建模人员就创建了一个顺序图，即用时间函数表示事件是如何引发从一个对象流到另一个对象。顺序图是用例的简化版本，它表示了导致行为从一个类流到另一个类的关键类和事件。
|
|
|
一旦构建了完整的序列图，就可以将导致系统对象之间转换的所有事件整理为一组输人事件和输出事件集合（来自对象）。对于将要构建的系统而言，这些信息对于创建系统的有效设计很有用。"
|
|
|
T8.5,Topic,8,8.5 行为建模,"① 理解行为建模的目标与重要性：行为建模展示软件如何响应内部与外部事件，是设计有效系统的重要环节。它帮助开发人员捕捉系统的动态行为，确保设计符合需求。
|
|
|
② 掌握行为建模工具：行为建模主要使用UML图，特别是UML活动图和状态图。活动图描述系统如何响应内部事件，状态图则展示外部事件如何影响系统状态的变化。
|
|
|
③ 验证行为模型的准确性：确保行为模型准确反映需求，避免设计偏差或误解。
|
|
|
④ 与其他建模技术结合：行为建模与类建模、功能建模等方法结合使用，全面分析系统的需求、功能与动态行为，帮助设计灵活高效的系统。"
|
|
|
S8.5.1,Section,8,8.5.1 介绍,"学习行为建模步骤：
|
|
|
①评估用例：首先，全面理解系统内的交互顺序，确保用例的需求被准确捕获。
|
|
|
②识别事件：分析触发交互顺序的事件，并理解这些事件如何影响对象的行为和状态。
|
|
|
③生成序列：为每个用例创建序列图，展示事件发生时各个对象的交互。
|
|
|
④创建状态图：展示系统如何根据外部事件转换状态。
|
|
|
⑤评审和验证：确保模型的准确性和一致性，验证是否能准确描述系统行为。"
|
|
|
S8.5.2,Section,8,8.5.2 识别用例事件,用例与事件的关系：用例描述了参与者和系统之间的活动顺序，事件则是系统和参与者之间交换信息的事实。 事件的识别：在用例场景中，加下划线的部分表示事件。每个事件都需要确认参与者，并标记交换的所有信息，同时列出所有条件或限制。 事件的例子：以“房主使用键盘键入4位密码”为例，这是一个由房主（Homeowner）向控制面板（ControlPanel）发送的事件，称为输入密码。这个事件传输的信息是4位数字密码，但重要的是已交换信息的事实，而不是信息本身。 事件对控制流的影响：某些事件对用例的控制流有明显影响，而其他事件则没有直接影响。例如，“输入密码”事件不会明显改变控制流，但“比较密码”的结果会明显影响信息流和控制流。 事件的分配：一旦确定了所有事件，这些事件将被分配给所涉及的对象，对象负责生成事件或识别已经在其他地方发生的事件。
|
|
|
S8.5.3,Section,8,8.5.3 UML状态图,"UML状态图用于展示系统中每个类的状态变化，包括主动状态和被动状态，以及导致状态变化的事件（触发器）。
|
|
|
状态转移涉及守卫（必须满足的条件）和动作（与状态转移相关的行为），这些要素帮助详细描述对象在不同状态下的行为和响应。"
|
|
|
S8.5.4,Section,8,8.5.4 UML活动图,UML活动图用于补充用例，通过图形化的方式表示特定场景中的迭代流。它能够清晰地描述系统如何对内部事件作出反应，尤其在复杂的交互中能够帮助软件工程师理解和设计系统流程。活动图通常通过活动矩形表示特定的操作，箭头则表示流程的方向。此外，UML泳道图是活动图的一种变体，它通过划分不同的泳道来表示不同参与者或分析类的职责。例如，在一个系统中，房主、摄像机和接口类可能分别承担不同的责任，泳道图能够清晰地标出每个类在活动中扮演的角色。通过将活动分配到不同泳道，软件开发人员可以更加直观地理解和设计复杂的交互过程，确保不同组件间的协调与响应。
|
|
|
SS8.5.4.1,SubSection,8,8.5.4.1 UML活动图的作用,UML活动图通过展示特定场景下的迭代流来补充用例，提供了系统如何对内部事件做出反应的图形化表示。它能够展示用例中无法直接描述的额外细节，例如用户尝试输入账号和密码的次数限制。
|
|
|
SS8.5.4.2,SubSection,8,8.5.4.2 UML泳道图的应用,"UML泳道图是活动图的变形，它允许建模人员展示活动流，并指出哪个参与者或分析类负责特定的活动。泳道图通过纵向分割图中的并行条（泳道）来表示职责，类似于游泳池中的泳道。
|
|
|
活动图和泳道图都是以过程为导向的，它们可以一起表示参与者如何调用特定功能以满足系统需求。通过将活动图重新排列并分配到相应的泳道中，可以更清晰地展示不同分析类或参与者的职责和活动。"
|
|
|
T8.6,Topic,8,8.6 小结,"""需求建模的目标是创建各种表现形式，用其描述什么是客户需求，为生成的软件设计建立基础，一旦软件建立这些需求将用于验证。需求模型在系统级表示层和软件设计之间构造了桥梁。系统表示层描述了整个系统和业务功能，软件设计描述了软件应用的体系结构、用户接口和构建级的结构。
|
|
|
基于场景的模型从用户的角度描述软件需求。用例是主要的建模元素，它以叙述方式或以模板驱动方式描述了参与者和软件之间的交互活动。在需求获取过程中得到的用地定义了特定功能或交互活动的关键步骤。用例的正式程度和详细程度各不相同,但它们可以为所有的其他分析建模活动提供必要的输入。还可以使用活动图说明场景，活动图是描述特定场景内的处理流的图形表现形式。用例中的时序关系可以使用顺序图来建模。
|
|
|
为了识别分析类，基于类的建模使用从用例和其他编写的应用描述中导出的信息。可以使用语法解析从文本说明中提取候选类、属性和操作，并使用解析结果制定用于定义类的标准。
|
|
|
CRC索引卡可以用于定义类之间的联系。此外，可以使用各种UML建模方法定义类之间的层次、关系、关联、聚合和依赖。
|
|
|
在需求分析阶段的行为建模描述了软件的动态，行为建模采用来自基于场景和基于类的输入来表达分析类的状态。为达到这一目的，要识别状态，定义引起类（或系统）由一种状态转换到另一个状态的事件，还要识别完成转换后发生活动。UML状态图、活动图、泳道图和顺序图可以被用于行为建模。"""
|
|
|
CH15,Subject,15,第15章 质量概念,软件质量是多维的概念，涉及可靠性、功能性和可维护性。实现高质量软件需要通过验证的工程过程、扎实的项目管理、全面的质量控制和质量保证基础设施。质量控制不仅包括开发过程中的缺陷检查，还包括交付后的评估，以减少返工和降低成本。软件质量是团队每个成员的责任，管理者和利益相关者也应积极参与。通过有效的质量保证措施，能够确保软件的稳定性和客户满意度。
|
|
|
T15.1,Topic,15,15.1 什么是质量,"① 理解软件质量的多维度定义：学习质量在软件开发中的多角度理解，包括从用户需求、制造商规格、产品属性和客户价值等视角来定义质量。
|
|
|
② 掌握设计质量与符合质量的关系：了解设计质量如何通过满足需求模型来影响软件的功能性，而符合质量则侧重于实际产品如何遵循设计并满足用户需求和性能目标。
|
|
|
③ 学习如何评估软件质量：理解用户满意度与质量的关系，掌握如何通过优质的设计、按时交付以及与客户需求一致的产品来提升质量。
|
|
|
④ 认识质量保证的重要性：了解质量保证如何通过严格的检查和控制流程，确保软件的高质量，降低返工率，并提高客户的满意度。
|
|
|
⑤ 分析质量对软件成功的影响：了解质量对软件成功的核心作用，如何通过减少错误、提高可靠性和性能来提升用户体验，从而最终确保软件产品的市场竞争力。"
|
|
|
S15.1.1,Section,15,15.1.1 David-Garvin关于质量的5个观点,David Garvin提出的五个关于质量的观点提供了不同的视角来理解质量这一复杂的概念。首先，先验论观点认为质量是直观可识别的，但难以清晰定义，类似于某些哲学中的“不可言喻”的特质。其次，用户观点强调质量从最终用户的目标出发，若产品能满足这些目标，就可认为其具有质量。制造商观点则侧重于从产品的原始规格说明来界定质量，若产品符合这些规格说明，就认为其质量合格。产品观点则将质量视为产品的固有属性，如功能和特性等。最后，基于价值的观点认为质量应依据客户愿意为之支付的价格来评估。总体而言，质量不仅仅是某一个方面的体现，而是多个维度的综合结果。
|
|
|
SS15.1.1.1,SubSection,15,15.1.1.1 先验论观点,先验论观点认为质量是马上就能识别的东西，却不能清楚地定义。
|
|
|
SS15.1.1.2,SubSection,15,15.1.1.2 用户观点,用户观点是从最终用户的具体目标来考虑的。如果产品达到这些目标，就是有质量的。
|
|
|
SS15.1.1.3,SubSection,15,15.1.1.3 制造商观点,制造商观点是从产品原始规格说明的角度来定义质量。如果产品符合规格说明，就是有质量的
|
|
|
SS15.1.1.4,SubSection,15,15.1.1.4 产品观点,产品观点认为质量是产品的固有属性（比如功能和特性）
|
|
|
SS15.1.1.5,SubSection,15,15.1.1.5 基于价值的观点,基于价值的观点根据客户愿意为产品支付多少钱来评测质量。
|
|
|
S15.1.2,Section,15,15.1.2 设计质量和符合质量,"设计质量和符合质量是软件开发中两个关键的质量维度。设计质量指的是在设计阶段，开发团队如何通过选择材料、规定公差、设定性能标准等来赋予产品的特性。在软件开发中，设计质量涉及设计是否能够满足需求模型中的功能和特性。通过在设计阶段采用更高标准的规格，可以提升产品的设计质量。
|
|
|
而符合质量则关注产品在实现过程中，是否遵从设计要求，以及最终交付的系统是否能够达到需求和性能目标。两者的关系可以通过Robert Glass提出的公式表示：用户满意度 = 合格的产品 + 好的质量 + 按预算和进度安排交付。Glass强调，虽然质量重要，但最终用户的满意度才是最为关键的。如果用户对产品不满意，其他任何优点都无法弥补这一缺陷。DeMarco进一步指出，软件产品的质量应以其对用户带来的实质性益处为衡量标准，即如果产品能为用户创造显著的价值，他们可能会接受一些偶尔的可靠性或性能问题。现代的软件质量观点更多强调客户满意度及产品需求的契合程度，而不仅仅是符合设计要求。"
|
|
|
SS15.1.2.1,SubSection,15,15.1.2.1 设计质量,设计质量是指设计师赋予产品的特性。材料等级、公差和性能等规格说明决定了设计质量。在软件开发中，设计质量包括设计满足需求模型规定的功能和特性的程度。
|
|
|
SS15.1.2.2,SubSection,15,15.1.2.2 符合质量,在软件开发中，符合质量关注的是实现遵从设计的程度以及所得到的系统满足需求和性能目标的程度。
|
|
|
S15.1.3,Section,15,15.1.3 质量之外,"“用户满意度 = 合格的产品 + 好的质量 + 按预算和进度安排交付”
|
|
|
如果一个软件产品能给最终用户带来实质性的益处，他们可能会心甘情愿地忍受偶尔的可靠性或性能问题。现代关于软件质量的观点要求关注客户满意度以及与产品需求的一致性。"
|
|
|
T15.2,Topic,15,15.2 软件质量,"① 理解软件质量的定义：掌握软件质量的多维定义，认识到软件质量不仅涉及技术实现，还关系到软件对生产者和用户的价值体现。
|
|
|
② 学习有效软件过程的重要性：了解高质量软件的产生需要依赖有效的软件开发过程，包括合理的项目管理、问题分析、设计可靠的解决方案等关键因素。
|
|
|
③ 区分有用产品与高质量产品：理解“有用的产品”不仅要满足用户需求和功能要求，还必须以可靠、无误的方式交付，包含隐性需求如可用性等。
|
|
|
④ 认识高质量软件带来的增值效益：学习高质量软件如何为开发团队和用户带来增值效益，减少维护和返工，提高软件的可靠性、可用性，最终提高组织的收益。
|
|
|
⑤ 关注软件质量对组织和用户的双重益处：理解软件质量对软件组织（如减少维护成本和提高开发效率）和最终用户（如提高业务流程效率和信息可用性）带来的重要收益。"
|
|
|
S15.2.1,Section,15,15.2.1 软件质量的定义,"(1) 在一定程度上应用有效的软件过程；
|
|
|
(2) 创造有用的产品；
|
|
|
(3) 为生产者和使用者提供明显的价值。"
|
|
|
SS15.2.1.1,SubSection,15,15.2.1.1 有效地软件过程,有效的软件过程为生产高质量的软件产品奠定了基础。过程的管理方面所做的工作是检验和平衡，以避免项目混乱（低质量的关键因素）。软件工程实践允许开发人员分析问题、设计可靠的解决方案，这些都是生产高质量软件的关键所在。最后，诸如变更管理和技术评审等普适性活动与其他部分的软件工程活动密切相关。
|
|
|
SS15.2.1.2,SubSection,15,15.2.1.2 有用的产品,有用的产品是指交付最终用户要求的内容、功能和特征，但最重要的是，以可靠、无误的方式交付这些东西。有用的产品总是满足利益相关者明确提出的那些需求，另外也要满足一些高质量软件应有的隐性需求（例如可用性）
|
|
|
SS15.2.1.3,SubSection,15,15.2.1.3 为软件产品的生产者和使用者带来增值,通过为软件产品的生产者和使用者增值，高质量软件为软件组织和最终用户群体带来了收益。软件组织获益是因为高质量的软件在维护、改错及客户支持方面的工作量都降低了，从而使软件工程师减少了返工，将更多的时间花费在开发新的应用上，软件组织因此而获得增值。用户群体也得到增值，因为应用所提供的有用的能力在某种程度上加快了一些业务流程。最后的结果是：（1)软件产品的收入增加；（2)当应用可支持业务流程时，收益更好；（3）提高了信息可获得性，这对商业来讲是至关重要的。
|
|
|
S15.2.2,Section,15,15.2.2 质量因素,软件质量涵盖多个维度，包括操作特性、承受变更的能力和对新环境的适应能力。操作特性直接影响软件的功能、性能、可靠性和可用性，决定了软件的表现和用户体验。承受变更的能力关注软件对需求变化的适应能力，如可维护性和可扩展性。而对新环境的适应能力则涉及软件在不同平台和环境下的兼容性和可移植性。这些因素共同作用，决定了软件的整体质量和用户满意度。
|
|
|
SS15.2.2.1,SubSection,15,15.2.2.1 McCall的软件质量因素,在软件工程中，McCall的软件质量因素（或称为软件质量特性）是评估软件产品质量的关键指标。这些因素由McCall等人在1979年提出，并分为面向软件产品运行、面向软件产品修正、面向软件产品转移三大类，共包含11个质量特性，McCall的软件质量因素涵盖了软件运行、修正和转移等多个方面，为评估和提高软件产品质量提供了全面的框架。在软件开发过程中，开发者应关注这些质量特性，并采取相应的措施来确保软件的质量。
|
|
|
P15.2.2.1.1,Problem,15,15.2.2.1.1 操作特性 (产品运行),"1.正确性。程序满足其需求规格说明和完成用户任务目标的程度。
|
|
|
2.可靠性。期望程序以所要求的精度完成其预期功能的程度。
|
|
|
3.效率。程序完成其功能所需的计算资源和代码的数量。
|
|
|
4.完整性。对未授权的人员访问软件或数据的可控程度。
|
|
|
5.易用性。对程序进行学习、操作、准备输入和解释输出所需要的工作量。"
|
|
|
P15.2.2.1.2,Problem,15,15.2.2.1.2 承受变更的能力 (产品修改),"1.维护性。查出和修复程序中的一个错误所需要的工作量。
|
|
|
2.灵活性。修改一个运行的程序所需的工作量。
|
|
|
3.易测试性。测试程序以确保它能完成预期功能所需要的工作量。"
|
|
|
P15.2.2.1.3,Problem,15,15.2.2.1.3 对新环境的适应能力 (产品转移),"1.可移植性。将程序从一个硬件和(或)软件系统环境移植到另一个环境所需要的工作量。
|
|
|
2.可复用性。程序 (或部分程序)在另一个应用系统中使用的程度。
|
|
|
3.互操作性。将一个(子)系统连接到另一系统所需要的工作量。"
|
|
|
SS15.2.2.2,SubSection,15,15.2.2.2 ISO 9126质量因素,"1.功能性。软件满足已确定需求的程度，由以下子属性表征：适合性、准确性、互操作性、依从性(遵照功能需求)和安全保密性。
|
|
|
2.可靠性。软件可用的时间长度，由以下子属性表征：成熟性、容错性和易恢复性。
|
|
|
3.易用性。软件容易使用的程度，由以下子属性表征：易理解性、易学习性和易操作性。
|
|
|
4.效率。软件优化使用系统资源的程度，由以下子属性表征：时间特性和资源利用特性。
|
|
|
5.维护性。软件易于修复的程度，由以下子属性表征：易分析性、易改变性、易测试性和稳定性。
|
|
|
6.可移植性。软件可以从一个环境移植到另一个环境的容易程度，由以下子属性表征：适应性、易安装性、符合性 (符合一定的标准和约定)和易替换性 (软件是否容易被替换)。"
|
|
|
SS15.2.2.3,SubSection,15,15.2.2.3 使用质量模型,"1.有效性。用户实现目标的准确性和完整性。
|
|
|
2.效率。为了完全达到用户目标和预期的准确性而花费的资源。
|
|
|
3.满意度。有用、信任、快乐、舒适。
|
|
|
4.远离风险。缓解经济、健康、安全和环境风险。
|
|
|
5.语境覆盖。完整性、灵活性。"
|
|
|
SS15.2.2.4,SubSection,15,15.2.2.4 产品质量模型,"1.功能适应性。完整、正确、适当。
|
|
|
2.性能效率。时间、资源利用、容量。
|
|
|
3.兼容性。共存、互操作性。
|
|
|
4.可用性。适当性、易学性、可操作性、错误保护、美观性、可访问性。
|
|
|
5.可靠性。成熟度、可用性、容错性、可恢复性。
|
|
|
6.安全性。保密性、完整性、可审核性、真实性。
|
|
|
7.可维护性。保密性、完整性、可审核性、真实性。
|
|
|
8.可移植性。适应性、可安装性、可替换性。"
|
|
|
S15.2.3,Section,15,15.2.3 定性质量评估,"1.用户能够多快确定是否可以使用软件产品来帮助他们完成任务？（适当性）
|
|
|
2.用户学会如何使用完成任务所需的系统功能需要多长时间？（易学性）
|
|
|
3.在随后的测试阶段，用户能否回忆起如何使用系统功能，而不必重新进行学习？（易学性）
|
|
|
4.用户使用系统完成任务需要多长时间？（可操作性）
|
|
|
5.系统是否会试图防止用户出错？（错误保护）
|
|
|
6.对于用户界面外观的问题，答案是否给出了满意的回答？（美观性）
|
|
|
7.界面是否符合第12章中的黄金规则所规定的预期？（可访问性）
|
|
|
8.用户界面是否符合预期用户所需的可访问性检查清单？（可访问性）"
|
|
|
S15.2.4,Section,15,15.2.4 定量质量评估,"主观性和特殊性也适用于软件质量的确定。要想对软件质量进行直接量化很难。
|
|
|
|
|
|
可以提出一组可应用于软件质量定量评估的软件度量：
|
|
|
1.也就是说，我们从不真正测量质量，而是测量质量的一些表现。
|
|
|
2.复杂因素在于所测量的变量和软件质量间的精确关系。"
|
|
|
T15.3,Topic,15,15.3 软件质量困境,"① 理解软件质量困境的本质：认识到软件开发中存在的质量与成本之间的平衡问题，过度追求完美可能导致资源浪费和市场机会错失。
|
|
|
② 掌握质量与时间、成本的权衡：了解如何在确保软件质量的同时，避免过度投资时间和成本，找到合适的质量标准以满足市场需求。
|
|
|
③ 学习解决质量困境的方法：理解如何通过有效的工程方法和项目管理策略，确保软件达到可接受的质量水平，避免陷入过度开发或低质量的困境。
|
|
|
④ 应对实际开发中的质量挑战：学会在实际开发中面对质量与资源的挑战时，如何进行合理的决策和调整，以满足用户需求并确保项目按时交付。"
|
|
|
S15.3.1,Section,15,15.3.1 困境论述,"如果生产一个存在严重质量问题的软件系统，你将受到损失，因为没有人想去购买。另一方面，如果你花费无限的时间、极大的工作量和高额的资金来开发一个绝对完美的软件，那么完成该软件将花费很长的时间，生产成本是极其高昂的，以至于破产。要么没人购买，要么几乎耗尽所有资源、错过市场机会。所以企业界的人们努力达到奇妙的中间状态：
|
|
|
1.一方面，产品要足够好，不会立即被抛弃；
|
|
|
2.另一方面，又不是那么完美，不需花费太长时间和太多成本。"
|
|
|
S15.3.2,Section,15,15.3.2 “足够好”的软件,足够好的软件提供用户期望的高质量功能和特性，但同时也提供了一些难解的或特殊的错误。软件供应商希望广大的最终用户忽视错误，因为他们对其他的应用功能是如此满意。
|
|
|
S15.3.3,Section,15,15.3.3 质量的成本,"质量成本包括追求质量过程中或在履行质量有关的活动中引起的费用以及质量不佳引起的费用等。
|
|
|
质量成本可分为：1.预防成本。2.评估成本。3.失效成本。"
|
|
|
SS15.3.3.1,SubSection,15,15.3.3.1 质量成本的争论,"质量是重要的，但是花费太多的时间和金钱才能达到我们实际需要的软件质量水平。毫无疑问，质量是有成本的，但缺乏质量也有成本。真正的问题是：我们应该担心哪些成本？
|
|
|
要回答这个问题，必须既要了解实现质量的成本，又要了解低质量软件导致的成本。"
|
|
|
SS15.3.3.2,SubSection,15,15.3.3.2 质量成本的3个分类,在软件工程中，质量成本涉及追求质量或执行质量相关活动的费用，主要包括预防成本、评估成本和失效成本。预防成本用于防止质量问题发生，包括质量计划、培训等；评估成本则是对已存在的问题进行评估和纠正，如质量检验、测试等；而失效成本是因质量问题导致的直接经济损失，如产品返工、赔偿等。企业应平衡这三类成本，通过合理的质量成本控制策略，减少质量问题，降低总质量成本，同时保持产品的质量和竞争力，实现最佳经济效益。
|
|
|
P15.3.3.2.1,Problem,15,15.3.3.2.1 预防成本,预防成本包括：（1)计划和协调所有质量控制和质量保证所需管理活动的成本；（2)为开发完整的需求模型和设计模型所增加的技术活动的成本；（3)测试计划的成本；（4)与这些活动有关的所有培训成本。不要害怕带来相当大的预防成本。请放心，你的投资将带来丰厚的回报。评估成本包括为深入了解产品“第一次通过”每个过程的条件而进行的活动。
|
|
|
P15.3.3.2.2,Problem,15,15.3.3.2.2 评估成本,评估成本的例子包括：(1)对软件工程工作产品进行技术评审（第16章）的成本；（2)数据收集和度量估算（第23章）的成本；（3)测试和调试（第19-21章）的成本。失效成本是那些在将产品交付客户之前若没有出现错误就不会发生的费用。
|
|
|
P15.3.3.2.3,Problem,15,15.3.3.2.3 失效成本,失效成本可分为内部失效成本和外部失效成本。内部失效成本发生在软件发布之前发现错误时，内部失效成本包括：（1)为纠正错误进行返工（修复）所需的成本；（2)返工时无意中产生副作用，必须对副作用加以缓解而发生的成本；（3)组织为评估失效的模型而收集质量数据，由此发生的相关成本。外部失效成本是在产品已经发布给客户之后发现了缺陷时的相关成本。外部成本的例子包括：解决投诉，产品退货和更换，帮助作业支持，以及与保修工作相关的人力成本。不良的声誉和由此产生的业务损失是另一个外部失效成本，这是很难量化但非常现实的。生产了低质量的软件产品时，不好的事情就要发生。
|
|
|
S15.3.4,Section,15,15.3.4 风险,低质量的软件会带来多种风险，不仅包括开发成本和时间的浪费，还可能导致安全性、可靠性和性能问题，进而影响用户的体验和满意度。在某些领域，这些风险可能引发严重后果，甚至威胁到生命和财产安全。质量不合格的软件可能导致系统故障、数据丢失、法律诉讼、品牌损害等问题。因此，确保软件质量的高标准至关重要，以减少风险和潜在的损失。
|
|
|
SS15.3.4.1,SubSection,15,15.3.4.1 低质量软件带来风险,设计和实现低劣的应用系统所带来的损失并不总是限于金钱和时间。
|
|
|
SS15.3.4.2,SubSection,15,15.3.4.2 一个极端的例子与警示,"在2000年11月，巴拿马的一家医院，28位病人在治疗多种癌症过程中接收了过量的伽玛射线照射。此后数月内，其中5例死于辐射病，15人发展成严重的并发症。是什么造成了这一悲剧？
|
|
|
为了计算每位病人接受的辐射剂量，医院的技术人员对一家美国公司开发的软件包进行了修改。为了提供额外的能力，这3个巴拿马医疗物理学家“调整”了软件，他们被指控犯有二级谋杀罪，这家美国公司正在两个国家面临着严重的诉讼。
|
|
|
|
|
|
事故就是对软件创作者的教训：
|
|
|
软件质量问题很重要，不管是嵌入在汽车引擎中的，工厂里的机械手臂中的，还是嵌入在医院的治疗设备中的，这些应用必须做到万无一失，低劣部署的代码可以杀人。"
|
|
|
S15.3.5,Section,15,15.3.5 疏忽和责任,"政府或企业雇用一个较大的软件开发商或咨询公司来分析需求，然后设计和创建一个基于软件的“系统”，用以支撑某个重大的活动。系统可能支持主要的企业功能（例如，养老金管理)，或某项政府职能（例如，卫生保健管理或国土安全）。
|
|
|
工作始于双方良好的意愿，但是到了系统交付时，情况已变得糟糕，系统延期，未能提供预期的特性和功能，而且易出错，不能得到客户的认可，接下来就要打官司。在大多数情况下，顾客称开发商马虎大意（已带到了软件实践中），因此拒绝付款。而开发商则常常声称，顾客一再改变其要求，并在其他方面破坏了开发伙伴关系。无论是哪一种情况，交付系统的质量都会有问题。"
|
|
|
S15.3.6,Section,15,15.3.6 质量和安全,低质量的软件不仅影响功能和性能，还可能增加安全风险。随着Web和移动系统的普及，软件安全变得尤为重要。软件的设计、构建、测试和编码阶段都需要重视安全性、可靠性和可信性，确保在整个生命周期内都能有效管理风险。质量和安全息息相关，早期发现并解决设计缺陷和实现错误是减少安全问题的关键。因此，构建安全系统必须从设计阶段开始，注重质量控制，以降低潜在的安全隐患。
|
|
|
SS15.3.6.1,SubSection,15,15.3.6.1 质量和安全的关系,随着基于Web的系统和移动系统重要性的增加，应用的安全性已变得日益重要。简而言之，没有表现出高质量的软件比较容易被攻击。因此，低质量的软件会间接地增加安全风险，随之而来的是费用和问题。软件安全与质量息息相关。必须一开始就在设计、构建、测试、编码阶段以及在整个软件生命周期（过程）中考虑安全性、可靠性、可得性、可信性。即使是已认识到软件安全问题的人也会主要关注生命周期的晚些阶段。越早发现软件问题越好。
|
|
|
SS15.3.6.2,SubSection,15,15.3.6.2 两种类型的软件问题,"有两种类型的软件问题，一种是隐藏的错误，这是实现的问题。另一种是软件缺陷，这是设计中的构建问题。人们对错误关注太多，却对缺陷关注不够。
|
|
|
要构造安全的系统，就必须注重质量，并必须在设计时开始关注。"
|
|
|
S15.3.7,Section,15,15.3.7 管理活动的影响,软件质量不仅受到技术决策的影响，还深受管理决策的影响。即使采用了最好的工程实践，糟糕的商业决策和不当的项目管理活动也可能导致软件质量的下降。管理层的决策、资源分配和项目管理方式直接影响软件的开发进度、质量保证和最终交付。有效的管理活动是确保软件质量的关键因素。
|
|
|
SS15.3.7.1,SubSection,15,15.3.7.1 质量受到管理活动影响,"软件质量受管理决定的影响往往和受技术决定的影响是一样的。即使最好的软件工程实践也能被糟糕的商业决策和有问题的项目管理活动破坏。
|
|
|
Meskimen定律能最好地概括软件质量面临的困境：“从来没有时间做好，但总是有时间再做一遍！”
|
|
|
应选择主动做好，而不是被动重做。"
|
|
|
SS15.3.7.2,SubSection,15,15.3.7.2 三种决策,每个项目任务开始时，项目领导人都要作决策，这些决策可能对产品质量有重大影响，决策包括：1.估算决策。2.进度安排决策。3.面向风险的决策。
|
|
|
P15.3.7.2.1,Problem,15,15.3.7.2.1 估算决策,"在确定交付日期和制定总预算之前，给软件团队提供项目估算数据是很少见的。反而是团队进行了“健康检查”，以确保交付日期和里程碑是合理的。在许多情况下,存在着巨大的上市时间压力，迫使软件团队接受不现实的交付日期。结果，由于抄了近路,可以获得更高质量软件的活动被忽略掉了，产品质量受到损害。如果交付日期是不合理的，那么坚持立场就是重要的。这就解释了为什么你需要更多的时间，或者也可以建议在指定的时间交付一个（高质量的）功能子集。"
|
|
|
P15.3.7.2.2,Problem,15,15.3.7.2.2 进度安排决策,"一旦建立了软件项目时间表（第25章)，就会按照依赖性安排任务的先后顺序。例如，由于A构件依赖于B、C和D构件中的处理，因此直到B、C和D构件完全测试后，才能安排A构件进行测试。项目计划将反映这一点。但是，如果时间很紧，为了做进一步的关键测试，A必须是可用的。在这种情况下，可能会决定在没有其附属构件(这些附属构件的运行要稍落后于时间表）的情况下测试A,这样对于交付前必须完成的其他测试，就可以使用A了，毕竟，期限正在逼近。因此，A可能有隐藏的缺陷，只有晚些时候才能发现，质量会受到影响。"
|
|
|
P15.3.7.2.3,Problem,15,15.3.7.2.3 面对风险的决策,风险管理（第26章）是成功软件项目的关键特性之一。必须知道哪里可能会出问题，并建立一项如果确实出问题时的应急计划。太多的软件团队喜欢盲目乐观，在什么都不会出问题的假设下建立开发计划。更糟的是，他们没有办法处理真的出了差错的事情。结果，当风险变成现实后，便会一片混乱，并且随着疯狂程度的上升，质量水平必然下降。
|
|
|
T15.4,Topic,15,15.4 实现软件质量,"① 理解实现软件质量的四大管理和实践活动：了解软件质量的实现依赖于四个关键活动：软件工程方法、项目管理技术、质量控制活动以及软件质量保证。
|
|
|
② 掌握软件工程方法对质量的影响：学习如何通过科学的软件工程方法确保软件质量，包括需求分析、设计、编码和测试等各个环节的规范化管理。
|
|
|
③ 学习项目管理技术的重要性：理解项目管理在确保软件质量中的作用，尤其是在时间、成本、资源管理及风险控制方面的重要性。
|
|
|
④ 理解质量控制与质量保证的区别与作用：明确质量控制活动（如缺陷检测和修复）与质量保证活动（如过程评审和标准化）的不同，并掌握如何有效结合两者实现高质量软件。
|
|
|
⑤ 确保软件质量的持续改进：学习如何通过持续的质量控制和质量保证活动，保持软件质量在整个开发生命周期中的稳定和提升。"
|
|
|
S15.4.1,Section,15,15.4.1 实现高质量软件的四大管理和实践活动,良好的软件质量不会自己出现，它是良好的项目管理和扎实的软件工程实践的结果。四大管理和实践活动可以帮助软件团队实现高质量的软件。
|
|
|
SS15.4.1.1,SubSection,15,15.4.1.1 软件工程方法,软件工程方法。如果希望建立高质量的软件，必须理解要解决的问题，还须能够创造一个符合问题的设计，该设计同时还要有一些性质，即这些性质可以产生具有质量维度和因素的软件。
|
|
|
SS15.4.1.2,SubSection,15,15.4.1.2 项目管理技术,"项目管理技术：
|
|
|
(1) 项目经理使用估算以确认交付日期是可以达到的；
|
|
|
(2) 进度依赖关系明确，团队能够抵抗走捷径的诱惑；
|
|
|
(3) 进行了风险规划，这样出了问题就不会引起混乱，软件质量将受到积极的影响。"
|
|
|
SS15.4.1.3,SubSection,15,15.4.1.3 质量控制,"质量控制。其包括一套软件工程活动，以帮助确保每个工作产品符合其质量目标：
|
|
|
1.评审模型以确保它们是完整的和一致的。
|
|
|
2.检查代码，以便在测试开始前发现和纠正错误。
|
|
|
3.应用一系列的测试步骤以发现处理逻辑、数据处理以及接口通信中的错误。
|
|
|
4.当任何一个工作成果不符合质量目标时，应结合测量和反馈使软件团队调整软件过程。"
|
|
|
SS15.4.1.4,SubSection,15,15.4.1.4 质量保证,质量保证。其包含一组审核和报告功能，用以评估质量控制活动的有效性和完整性。
|
|
|
S15.4.2,Section,15,15.4.2 机器学习和缺陷预测,"缺陷预测是识别可能存在质量问题的软件构件的重要方式。缺陷预测模型使用统计技术来检查软件度量和包含已知软件缺陷的软件构件的组合之间的关系。它们是软件开发人员快速识别容易出错的类的高效方法。这可以减少成本和开发时间。
|
|
|
机器学习是人工智能（AI)技术的一种应用，它为系统提供了无须显式编程就能从经验中学习和改进的能力。换句话说，机器学习关注开发能够访问数据并利用数据进行自学的计算机程序。机器学习技术可以用来自动化发现软件度量和缺陷构件之间的预测关系。机器学习系统处理大量的数据集，这些数据集包含有缺陷的和无缺陷的软件构件的代表性度量组合。这些数据用于优化分类算法。一旦系统通过这种类型的训练构建了一个预测模型，它就可以基于未来软件产品的相关数据进行质量评估和缺陷预测。构建这种类型的分类器是现代数据科学家工作的重要部分。"
|
|
|
T15.5,Topic,15,15.5 小结,"软件正在融入我们日常生活的各个方面，人们对于软件系统质量的关注也逐渐多起来。但是很难给出软件质量的一个全面描述。在这一章，质量被定义为一个有效的软件过程，用来在一定程度上创造有用的产品，为那些生产者和使用者提供适度的价值。
|
|
|
这些年来，提出了各种各样的软件质量度量和因素，都试图定义一组属性，如果可以实现，那么我们将实现较高的软件质量。McCall的质量因素和ISO 25010的质量因素建立了很多特性（如可靠性、可用性、维护性、功能性和可移植性）作为质量存在的指标。
|
|
|
每个软件组织都面临软件质量困境。从本质上说，每个人都希望建立高质量的系统，但生产“完美”软件所需的时间和工作量在市场主导的世界里根本无法达到。这样问题就转化为，我们是否应该生产“足够好”的软件？虽然许多公司是这样做的，但是这样做有很大的负面影响，必须加以考虑。
|
|
|
不管选择什么方法，质量都是有成本的，质量成本可以从预防、评估和失效方面来说。预防成本包括所有将预防缺陷放在首位的软件工程活动。评估成本是与评估软件工作产品以确定其质量的活动有关的成本。失效成本包括失效的内部代价和低劣质量造成的外部影响。
|
|
|
软件质量是通过软件工程方法、扎实的管理措施和全面质量控制的应用而实现的一一所有这些都是靠软件质量保证基础设施支持的。"
|
