有关软件配置管理,需要考虑这样一些问题: 采用什么方式来标识和管理许多已 存在程序(和它们的文档)的各种版本? 在软件交付用户之前和之后如何控 记事文件 制变更? 谁有权批准和对变更安排优先级? 如何保证变更得以正确地实施? 利用什么办法来估计变更可能引起 的其它问题? 这些问题归结到软件配置管理的5个 项目数据库 任务,即配置标识、版本管理、变更控制、 专用工作空间 配置审核和配置报告。 图10.8基线SCI和项目数据库 (4)配置标识 软件配置实际上是一个动态的概念。一方面随着软件生存期的向前推进,软件配置项的 数量在不断增多。另一方面又随时会有新的变更出现,形成新的版本。因此,整个软件生存 期的软件配置就象一部不断演变的电影,而某一时刻的配置就是这部电影的一个片段 为了方便对软件配置的各个片段,即软件配置项进行控制和管理,不致造成混乱,首先 应给它们命名,这就是配置标识的任务 我们可以用面向对象的方法进行标识。通常需标识两种类型的对象:基本对象和复合对 象。基本对象是由软件人员在分析、设计、编码和测试时所建立的“文本单元”。例如,基 本对象可能是需求规格说明中的一节,一个源程序清单、一组用来测试一个等价类的测试用 例。复合对象则是基本对象或其它复合对象的一个集合。如图10.6所示,“设计规格说明” 是一个复合对象,它是一些基本对象,如“数据模型”、“模块N”的集合。 每个对象可用一组信息来唯一地标识它,这组信息包括 (名字、描述、一组“资源”、“实现”) 对象的名字是一个字符串,它明确地标识对象。对象描述是一个表项,它包括:对象所 表示的配置项类型(如文档、程序、数据)、项目标识、变更和/或版本信息。资源是“由对 象所提供的、处理的、引用的或其它所需要的一些实体”。例如,数据类型,特定函数,甚 至变量名都可以看做是对象资源。而“实现”对于一个基本对象来说,是指向“文本单元” 的指针,而对于复合对象来说,则为nul 配置对象的标识还需考虑在命名对象间存在的联系。对象可以是一个复合对象的组成部 分,用联系< part of>进行标识。这个联系定义了对象的层次。在对象层次中,对象之间的联 系不仅存在于层次树的路径中,而且可跨越对象层次的分支相互关联。例如,数据模型与数 据流图是相互关联的,而且它又与一个特定等价类的测试用例组相互关联。 (5)版本控制 整个软件工程过程中所涉及的软件对象都必须加以标识。在对象成为基线以前可能要做 多次变更,在成为基线之后也可能需要频繁地变更。这样对于每一配置对象都可以建立一个 演变图,这个演变图记叙了对象的变更历史。以图109为例,配置对象1.0经过修改成为对 象1.1,又经历了小的修改和变更,产生了版本1.1.1和1.1.2。紧接对版本1.1做了一次更新, 产生对象12,又持续演变生成了1.3和14版本。同时对对象1.2做了一次较大的修改,引 出一条新的演变路径:版本20。 已经开发出来许多工具来辅助标识工作。在某些工具中,当前保持的只是最后版本的完 全副本。为了得到较早时期(文档或程序)的版本,可以从最后版本中“提取”出(由工具编目 的)变更,使得当前配置直接可用,并使得其它版本也可用
11 有关软件配置管理，需要考虑这样一些问题： ▪ 采用什么方式来标识和管理许多已 存在程序(和它们的文档)的各种版本？ ▪ 在软件交付用户之前和之后如何控 制变更？ ▪ 谁有权批准和对变更安排优先级？ ▪ 如何保证变更得以正确地实施？ ▪ 利用什么办法来估计变更可能引起 的其它问题？ 这些问题归结到软件配置管理的 5 个 任务，即配置标识、版本管理、变更控制、 配置审核和配置报告。 (4) 配置标识 软件配置实际上是一个动态的概念。一方面随着软件生存期的向前推进，软件配置项的 数量在不断增多。另一方面又随时会有新的变更出现，形成新的版本。因此，整个软件生存 期的软件配置就象一部不断演变的电影，而某一时刻的配置就是这部电影的一个片段。 为了方便对软件配置的各个片段，即软件配置项进行控制和管理，不致造成混乱，首先 应给它们命名，这就是配置标识的任务。 我们可以用面向对象的方法进行标识。通常需标识两种类型的对象：基本对象和复合对 象。基本对象是由软件人员在分析、设计、编码和测试时所建立的“文本单元”。例如，基 本对象可能是需求规格说明中的一节，一个源程序清单、一组用来测试一个等价类的测试用 例。复合对象则是基本对象或其它复合对象的一个集合。如图 10.6 所示，“设计规格说明” 是一个复合对象，它是一些基本对象，如“数据模型”、“模块 N”的集合。 每个对象可用一组信息来唯一地标识它，这组信息包括： （名字、描述、一组“资源”、“实现”） 对象的名字是一个字符串，它明确地标识对象。对象描述是一个表项，它包括：对象所 表示的配置项类型(如文档、程序、数据)、项目标识、变更和／或版本信息。资源是“由对 象所提供的、处理的、引用的或其它所需要的一些实体”。例如，数据类型，特定函数，甚 至变量名都可以看做是对象资源。而“实现”对于一个基本对象来说，是指向“文本单元” 的指针，而对于复合对象来说，则为 null。 配置对象的标识还需考虑在命名对象间存在的联系。对象可以是一个复合对象的组成部 分，用联系<part of>进行标识。这个联系定义了对象的层次。在对象层次中，对象之间的联 系不仅存在于层次树的路径中，而且可跨越对象层次的分支相互关联。例如，数据模型与数 据流图是相互关联的，而且它又与一个特定等价类的测试用例组相互关联。 (5) 版本控制 整个软件工程过程中所涉及的软件对象都必须加以标识。在对象成为基线以前可能要做 多次变更，在成为基线之后也可能需要频繁地变更。这样对于每一配置对象都可以建立一个 演变图，这个演变图记叙了对象的变更历史。以图 10.9 为例，配置对象 1.0 经过修改成为对 象 1.1，又经历了小的修改和变更，产生了版本 1.1.1 和 1.1.2。紧接对版本 1.1 做了一次更新， 产生对象 1.2，又持续演变生成了 1.3 和 1.4 版本。同时对对象 1.2 做了一次较大的修改，引 出一条新的演变路径：版本 2.0。 已经开发出来许多工具来辅助标识工作。在某些工具中，当前保持的只是最后版本的完 全副本。为了得到较早时期(文档或程序)的版本，可以从最后版本中“提取”出(由工具编目 的)变更，使得当前配置直接可用，并使得其它版本也可用。 图 10.8 基线 SCI 和项目数据库
在图10.9所示的演变图中,各结点都是聚合对象。软件的每一版本都是软件配置项(源 代码、文档、数据)的一个集合,且各个版本都可能由不同的变种组成。例如,有一个简单的 程序版本:它由1、2、3、4和5等部件组成,其中部件4在软件使用彩色显示器时使用,部 件5在软件使用单色显示器时使用。因此,可以定义版本的两个变种 ①部件1、2、3、4:②部件1、2、3、5 版本 版本 版本 版本 1.0 演变图显示 2.0 了软件的修 改情况 版本 1.1.11 变种 14_[5 图10.10版本的演变图和版本的变种 版本控制的主要功能有: ①集中管理档案,安全授权机制:版本 工作站 LAN 管理的操作是将开发组的档案集中存放在服 1.4 务器上,经系统管理员授权给各个用户。用户 通过登入( check in)和检出( check out)的方式 check in 访问服务器上的文件,未经授权的用户则无法 访问服务器上的文件。如图10.10所示 filename. cpp ②软件版本升级管理:每次登入时,在 服务器上都会生成新的版本,软件版本的管理 filename. cpv 采取增量存储的方式。任何版本都可以随时检 图10.10档案的登入 出编辑,同一应用的不同版本可以像树枝一样 向上增长。如图10.1所示 大型 ⅤMS 初始系 DEC 充版本 UNIX SUN 版 图10.1软件版本升级管理 ③加锁功能:为了在文件更新时保护文件,避免不同的用户更改同一文件时发生冲突 某一文件一旦被登入,锁即被解除,该文件可被其它用户使用。在更新一个文件之前锁定它 避免变更没有锁定的项目源文件
12 在图 10.9 所示的演变图中，各结点都是聚合对象。软件的每一版本都是软件配置项(源 代码、文档、数据)的一个集合，且各个版本都可能由不同的变种组成。例如，有一个简单的 程序版本：它由 1、2、3、4 和 5 等部件组成，其中部件 4 在软件使用彩色显示器时使用，部 件 5 在软件使用单色显示器时使用。因此，可以定义版本的两个变种： ① 部件 1、2、3、4； ② 部件 1、2、3、5。 版本控制的主要功能有： ① 集中管理档案，安全授权机制：版本 管理的操作是将开发组的档案集中存放在服 务器上，经系统管理员授权给各个用户。用户 通过登入(check in)和检出(check out)的方式 访问服务器上的文件，未经授权的用户则无法 访问服务器上的文件。如图 10.10 所示。 ② 软件版本升级管理：每次登入时，在 服务器上都会生成新的版本，软件版本的管理 采取增量存储的方式。任何版本都可以随时检 出编辑，同一应用的不同版本可以像树枝一样 向上增长。如图 10.11 所示。 图 10.11 软件版本升级管理 ③ 加锁功能：为了在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。 某一文件一旦被登入，锁即被解除，该文件可被其它用户使用。在更新一个文件之前锁定它， 避免变更没有锁定的项目源文件。 图 10.10 版本的演变图和版本的变种 工作站 LAN 图 10.10 档案的登入 filename.cpp 1.4 1.3 ▲ 1.2 ▲ 1.1 ▲ 1.0 ▲ filename.cpv check in 初始系 统版本 PC 版 DEC 版 SUN 版 VMS 版 UNIX 版 大型 机版 工作 站版
④提供不同版本源程序的比较:在文件登入和检出时,需要注意检入和检出的使用。 当某个时刻需要修改某个小缺陷或特征,应只检出完成工作必需的最少文件; 当需要对文件变更时,应登入它并加锁。这样可保留对每个变更的记录 应避免长时间地锁定文件。如果需要长时间工作于某个文件,最好能创建一个分支, 并在分支上做工作。这样别人可以地做缺省的“小”修改以更改较小的缺陷。稍后可通过合 并,把所有操作结果集成在一起 如果需要做较大的变更,可有两种选择 i)将需要的所有文件检出并加锁,然后正常处理 为需要修改的版本创建分支,把变更与主干“脱离”,然后把结果合并回去 (6)变更控制 软件生存期内全部的软件配置是软件产品的真正代表,必须使其保持精确。软件工程过 程中某一阶段的变更,均要引起软件配置的变更,这种变更必须严格加以控制和管理,保持 修改信息,并把精确、清晰的信息传递到软件工程过程的下一步骤 变更控制包括建立控制点和建立报告与审查制度 对于一个大型的软件来说,不加控制的变更很快就会引起混乱。因此变更控制是一项最 重要的软件配置任务。图10.12给出了变更控制的过程 匚识别变更要求」 用户提交变更请求 开发人员进行评价 匚产生变更报告 变更控制负责人做出决定 对请求排队,生成工程变更顺序 产生变更报告 「把变更分配给配置对象 匚“检出”配置对象(SC 变更方式(mde) “促成”把变更包括在下一修正版中 变更复审(审计) 匚重建适用的软件版本 登入”变更后的配置项 匚针对所有配置项复审(审计)变更 建立测试基线 把变更包括到新版本中 [执行质量保证和测试活动 发布新版本 图10.12变更控制过程 在此过程中,首先用户提交书面的变更请求,详细申明变更的理由、变更方案、变更的 影响范围等。然后由变更控制杋构确定控制变更的机制、评价其技术价值、潜在的副作用、 对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式 提交给变更控制负责人(最终决定变更状态和优先权的某个人或小组)。对每个批准了的变更 产生一个工程变更顺序(ECO),描述进行的变更、必须考虑的约束、评审和审计的准则等。 要做变更的对象从项目数据库中检出,对其做出变更,并实施适当的质量保证活动。然后再 把对象登入到数据库中并使用适当的版本控制机制建立软件的下一版本
13 ④ 提供不同版本源程序的比较：在文件登入和检出时，需要注意检入和检出的使用。 ▪ 当某个时刻需要修改某个小缺陷或特征，应只检出完成工作必需的最少文件； ▪ 当需要对文件变更时，应登入它并加锁。这样可保留对每个变更的记录； ▪ 应避免长时间地锁定文件。如果需要长时间工作于某个文件，最好能创建一个分支， 并在分支上做工作。这样别人可以地做缺省的“小”修改以更改较小的缺陷。稍后可通过合 并，把所有操作结果集成在一起。 ▪ 如果需要做较大的变更，可有两种选择： ⅰ）将需要的所有文件检出并加锁，然后正常处理； ⅱ）为需要修改的版本创建分支，把变更与主干“脱离”，然后把结果合并回去。 (6) 变更控制 软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。软件工程过 程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持 修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。 变更控制包括建立控制点和建立报告与审查制度。 对于一个大型的软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最 重要的软件配置任务。图 10.12 给出了变更控制的过程。 图 10.12 变更控制过程 在此过程中，首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的 影响范围等。然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、 对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式 提交给变更控制负责人(最终决定变更状态和优先权的某个人或小组)。对每个批准了的变更 产生一个工程变更顺序(ECO)，描述进行的变更、必须考虑的约束、评审和审计的准则等。 要做变更的对象从项目数据库中检出，对其做出变更，并实施适当的质量保证活动。然后再 把对象登入到数据库中并使用适当的版本控制机制建立软件的下一版本
“检出”和“登入”处理实现了两个重要的变更控制要素,即存取控制和同步控制。存 取控制管理人们存取或修改一个特定软件配置对象的权限;同步控制可用来确保由不同的人 所执行的并发变更不会产生混乱。 存取和同步控制流如图10.13所 示。根据经批准的变更请求和ECO,软 检出 件人员从项目数据库中检出要变更的配配置对象锡取酸定置对基线版 置对象。同步控制功能则封锁了项目数 存取权信息 据库中的这个对象,使得当前检出的版 软件工 存取 项目数据库 本在没有被置换前不能再更新它。当然, 对这个对象还可以检出另外的副本,但 這息|modk置对象(基线版本) 对其也不能更新。人们在对这种成为基 配置对 线的对象做了变更,并经过适当的软件 (修改版本)(登入 质量保证和测试之后,把修改版本登入 项目数据库,再解除封锁。 图10.13存取和同步控制 软件的变更通常有两类不同的情况 为改正小错误需要的变更。通常不需要从管理角度对这类变更进行审查和批准。但如 果发现错误的阶段在造成错误的阶段的后面,例如在实现阶段发现了设计错误,则必须遵照 标准的变更控制过程,把这个变更正式记入文档,并修改所有受这个变更影响的文档 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类 变更必须经过某种正式的变更评价过程,以估计变更需要的成本和它对软件系统其它部分的 影响。 应该把所做的变更正式记入文档,并相应地修改所有有关的文档。这种变更报告和审查 制度,对变更控制来说起了一个安全保证作用。需要注意的是,必须对每一项变更进行评价 并对所有的变更进行跟踪和复审 (7)配置状态报告 为了清楚、及时地记载软件配置的变化,不致于到后期造成贻误,需要对开发的过程做 出系统的记录,以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录,并产生配置状态报告。报告对于每一项变更, 记录以下问题:发生了什么?为什么会发生?谁做的?什么时侯发生的?会有什么影响? 图10.14描述了配置状态报告的信息流 配置标识 软件配置项 配置状态报告 朕机数据库 配置控制一变更 状态报告 配置审核 缺陷 配置状态报告 图10.14配置状态报告 每次新分配一个软件配置项或更新一个已有软件配置项的标识,或者一项变更申请被变 更控制负责人批准,并给出了一个工程变更顺序时,在配置状态报告中就要增加一条变更记 录条目。一旦进行了配置审核,其结果也应该写入报告之中。配置状态报告可以放在一个联 14
14 “检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存 取控制管理人们存取或修改一个特定软件配置对象的权限；同步控制可用来确保由不同的人 所执行的并发变更不会产生混乱。 存取和同步控制流如图 10.13 所 示。根据经批准的变更请求和 ECO，软 件人员从项目数据库中检出要变更的配 置对象。同步控制功能则封锁了项目数 据库中的这个对象，使得当前检出的版 本在没有被置换前不能再更新它。当然， 对这个对象还可以检出另外的副本，但 对其也不能更新。人们在对这种成为基 线的对象做了变更，并经过适当的软件 质量保证和测试之后，把修改版本登入 项目数据库，再解除封锁。 软件的变更通常有两类不同的情况： ▪ 为改正小错误需要的变更。通常不需要从管理角度对这类变更进行审查和批准。但如 果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照 标准的变更控制过程，把这个变更正式记入文档，并修改所有受这个变更影响的文档。 ▪ 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类 变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的 影响。 应该把所做的变更正式记入文档，并相应地修改所有有关的文档。这种变更报告和审查 制度，对变更控制来说起了一个安全保证作用。需要注意的是，必须对每一项变更进行评价 并对所有的变更进行跟踪和复审。 (7) 配置状态报告 为了清楚、及时地记载软件配置的变化，不致于到后期造成贻误，需要对开发的过程做 出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录，并产生配置状态报告。报告对于每一项变更， 记录以下问题：发生了什么？为什么会发生？谁做的？什么时侯发生的？会有什么影响？ 图 10.14 描述了配置状态报告的信息流。 图 10.14 配置状态报告 每次新分配一个软件配置项或更新一个已有软件配置项的标识，或者一项变更申请被变 更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记 录条目。一旦进行了配置审核，其结果也应该写入报告之中。配置状态报告可以放在一个联 图 10.13 存取和同步控制 配置标识 配置控制 配置审核 状态报告 软件配置项 变更 缺陷 配置状态报告 配置状态报告 联机数据库 项目数据库 存取权信息 检出 登入 lock unlock 软件工 程人员 存取 控制 配置对象(提取版本) 配置对象(基线版本) 配置对象(基线版本) 审核信息 配置对象 (修改版本)
机数据库中,以便软件开发人员或者软件维护人员可以对它进行査询或修改。此外在软件配 置报告中新登录的变更应当及时通知给管理人员和软件人员 配置状态报告对于大型软件开发项目的成功起着至关重要的作用。它提高了所有开发人 员之间的通信能力,避免了可能出现的不一致和冲突 (8)配置审核 软件的完整性,是指开发后期的软件产品能够正确地反映用户所提出的对软件的要求。 软件配置审核的目的就是要证实整个软件生存期中各项产品在技术上和管理上的完整性。同 时,还要确保所有文档的内容变动不超出当初确定的软件要求范围。使得我们的软件配置具 有良好的可跟踪性。这是软件变更控制人员掌握配置情况、进行审批的依 软件的变更控制机制通常只能跟踪到工程变更顺序产生为止,那么如何知道变更是否正 确完成了呢?一般可以用以下两种方法去审查:正式技术评审和软件配置审核。 正式的技术评审着重检查已完成修改的软件配置对象的技术正确性,评审者评价软件配 置项,决定它与其它软件配置项的一致性,是否有遗漏或可能引起的副作用。正式技术评审 立对所有的变更进行,除了那些最无价值的变更之外。 软件配置审核作为正式技术评审的补充,评价在评审期间通常没有被考虑的软件配置项 的特性。软件配置审核提出并解答以下问题: 在工程变更顺序中规定的变更是否已经做了?每个附加修改是否已经纳入? 正式技术评审是否已经评价了技术正确性? ■是否正确遵循了软件工程标准? 在软件配置项中是否强调了变更?是否说明了变更日期和变更者?配置对象的属性是 否反映了变更? 是否遵循了标记变更、记录变更、报告变更的软件配置管理过程? 所有相关的软件配置项是否都已正确地做了更新? 在某些情形下,这些审核问题是作为正式技术评审的一部分提出的。但是当软件配置管 理成为一项正式活动时,软件配置审核就被分开,而由质量保证小组执行了 5.软件工程标准化 (1)软件工程标准化的意义 在开发一个软件时,需要有许多层次、不同分工的人员相互配合;在开发项目的各个部 分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把这些错综复杂的关系协调好 需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时,还需要进行 阶段评审和验收测试。投入运行的软件,其维护工作中遇到的问题又与开发工作有着密切的 关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行为 规范和衡量准则,使得各种工作都能有章可循 软件工程的标准化会给软件工作带来许多好处,比如 可提高软件的可靠性、可维护性和可移植性 可提高软件的生产率 可提高软件人员的技术水平 可提高软件人员之间的通信效率,减少差错和误解 有利于软件管理:有利于降低软件产品的成本和运行维护成本 有利于缩短软件开发周期 随着人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写 程序,扩展到整个软件生存期。诸如软件概念的形成、需求分析、设计、实现、测试、安装 和检验。运行和维护,直到软件淘汰(为新的软件所取代)。同时还有许多技术管理工作(如过
15 机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配 置报告中新登录的变更应当及时通知给管理人员和软件人员。 配置状态报告对于大型软件开发项目的成功起着至关重要的作用。它提高了所有开发人 员之间的通信能力，避免了可能出现的不一致和冲突。 (8) 配置审核 软件的完整性，是指开发后期的软件产品能够正确地反映用户所提出的对软件的要求。 软件配置审核的目的就是要证实整个软件生存期中各项产品在技术上和管理上的完整性。同 时，还要确保所有文档的内容变动不超出当初确定的软件要求范围。使得我们的软件配置具 有良好的可跟踪性。这是软件变更控制人员掌握配置情况、进行审批的依据。 软件的变更控制机制通常只能跟踪到工程变更顺序产生为止，那么如何知道变更是否正 确完成了呢? 一般可以用以下两种方法去审查：正式技术评审和软件配置审核。 正式的技术评审着重检查已完成修改的软件配置对象的技术正确性，评审者评价软件配 置项，决定它与其它软件配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审 应对所有的变更进行，除了那些最无价值的变更之外。 软件配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的软件配置项 的特性。软件配置审核提出并解答以下问题： ▪ 在工程变更顺序中规定的变更是否已经做了? 每个附加修改是否已经纳入? ▪ 正式技术评审是否已经评价了技术正确性? ▪ 是否正确遵循了软件工程标准? ▪ 在软件配置项中是否强调了变更? 是否说明了变更日期和变更者? 配置对象的属性是 否反映了变更? ▪ 是否遵循了标记变更、记录变更、报告变更的软件配置管理过程? ▪ 所有相关的软件配置项是否都已正确地做了更新? 在某些情形下，这些审核问题是作为正式技术评审的一部分提出的。但是当软件配置管 理成为一项正式活动时，软件配置审核就被分开，而由质量保证小组执行了。 5. 软件工程标准化 (1) 软件工程标准化的意义 在开发一个软件时，需要有许多层次、不同分工的人员相互配合；在开发项目的各个部 分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把这些错综复杂的关系协调好， 需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，还需要进行 阶段评审和验收测试。投入运行的软件，其维护工作中遇到的问题又与开发工作有着密切的 关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行为 规范和衡量准则，使得各种工作都能有章可循。 软件工程的标准化会给软件工作带来许多好处，比如： ▪ 可提高软件的可靠性、可维护性和可移植性； ▪ 可提高软件的生产率； ▪ 可提高软件人员的技术水平； ▪ 可提高软件人员之间的通信效率，减少差错和误解； ▪ 有利于软件管理；有利于降低软件产品的成本和运行维护成本； ▪ 有利于缩短软件开发周期。 随着人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写 程序，扩展到整个软件生存期。诸如软件概念的形成、需求分析、设计、实现、测试、安装 和检验。运行和维护，直到软件淘汰(为新的软件所取代)。同时还有许多技术管理工作(如过