软件开发过程讲课教案.doc

软件开发过程

精品文档
软件开发的过程
信息工程学院 0802班 王勇（2008011728）

摘要：什么是软件工程

软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
1 软件开发的流程概要
需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试
——维护

2 需求调研
① 调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。
　　② 调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。
　　③ 对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层和决策层的需求既联系，又区分开来，形成一个金字塔，使下层满足上层的需求。
　　④ 对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。
　　⑤ 若基线符合要求，则需求分析完毕；反之返回到第1步或第2或第3步。如此循环多次，直到需要分析使双方满意为止。

3 可行性分析和需求分析
可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么，不做什么”。
3.1 可行性分析
3.1.1 经济
经济可行性分析主要包括：“成本——收益”分析和“短期——长远利益”分析。
3.1.1.1 成本——收益
（1）办公室房租。(￥)
（2）办公用品，如桌、椅、书柜、照明电器、空调等。(￥)
（3）计算机、打印机、网络等硬件设备。(￥)
（4）电话、传真等通讯设备以及通讯费用。(￥)
（5）资料费。(￥)
（6）办公消耗，如水电费、打印复印费等。(￥)
（7）软件开发人员与行政人员的工资。(￥)
（8）购买系统软件的费用，如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件，却按市场价算成本，可从美国佬那里赚一笔。(￥)
（9）做市场调查、可行性分析、需求分析的交际费用。(￥)
（10）公司人员培训费用。(￥)
（11）产品宣传费用。如果用Internet作宣传，则要考虑建设Web站点的费用。(￥)
（12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿的费用。(￥)
（13）如果公司的风水不好，会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。(￥)
3.1.1.2 短期——长远利益
人们喜欢吃着碗里的、看着锅里的，还想着别人家里的。短期利益和长远利益兼得是人们梦寐以求的事。在商业上，这等好事可不会轻易降临。
短期利益容易把握，风险较低。但收益有限，做的是项目。
长远利益难以把握，风险较大。但收益可能巨大，做的是企业。

3.1.2 技术
技术可行性分析至少要考虑以下几方面因素：
（1）在给定的时间内能否实现需求说明中的功能。
（2）软件的质量如何？主要考虑在网络、硬件、市场竞争等上面的分析。
（3）软件的生产率如何？主要是开发的周期、移植性、维护、扩展方面的考虑。

技术可行性分析可以简单地表述为：做得了吗？做得好吗？做得快吗？
3.1.3 社会环境
社会环境的可行性至少包括两种因素：市场与政策。
3.1.3.1 市场
市场又分为未成熟的市场、成熟的市场和将要消亡的市场。
涉足未成熟的市场要冒很大的风险，要尽可能准确地估计潜在的市场有多大？自己能占多少份额？多长时间能实现？
挤进成熟的市场，虽然风险不高，但油水也不多。如果供大于求。收入稳定
将要消亡的市场就别进去了。如DOS时代编程现在不可能有人去做了。
3.1.3.2 政策
政策对软件公司的生存与发展影响非常大。需要考虑：国家的网络法律的发展、与对项目的限制，是否有鼓励机制，新的网络技术等先进科技的引进等
3.1.4 人的因数
技术人员的水平如何，时间安排是否可以到位，特殊情况（如病假等）等对项目开发的进度和质量的影响。如何合理安排人手，对各个计划（小功能块）的开发时限分析等，对于项目开发是非常重要的。
3.2 需求分析
有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。
3.2.1 客户说不清楚需求
也可以理解为市场人员和初级策划要给出整个软件开发的目的，消费人群，市场等内容。

3.2.2 需求自身经常变动
首先先接受“需求会变动”这个事实，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在文档中一定要说清楚“做什么”和“不做什么”。
3.2.3 分析人员或客户理解有误
不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。
所以在具体的项目开发过程中，程序员和策划还有市场要随时沟通，不断交流。
3.2.4 业务需求
业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同产品可能会有不同的侧重点。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购卖者带来的利益。
3.2.4.1 背景
在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。
3.2.4.2 业务机遇
描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。
3.2.4.3 业务目标
用一个定量和可测量的合理方法总结产品所带来的重要商业利润。关于给客户带来的价值在后面阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。
3.2.4.4 客户或市场需求
描述一些典型客户的需求，包括不满足现在市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写到列表中，可以反过来跟踪调查特殊用户和功能需求。
3.2.4.5 提供给客户的价值
确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：
1.提高生产效率，减少返工；
2.节省开支；
3.业务过程的流水线化；
4.先前人工劳动的自动化；
5.符合相关标准和规则；
6.与目前的应用产品相比较，提高了可用性或减少了失效程度。
3.2.4.6 业务风险
总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。
3.2.4.7 项目视图
文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中做出决策提供了相关环境背景。这部分不包括详细的功能需求和项目计划信息。
3.2.4.7.1 项目视图陈述
编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场企业框架。组织的战略方向和资源局限性为基础。
3.2.4.7.2 主要特征
包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。
包括拥有的功能，用户对象，优势等内容。
3.2.4.7.3 假设和依赖环境
在构思项目和编写项目视图和范围文档时，要记录所做出的任何假设。通常一方所持的假设应与另一方不同。如果你把它们都记录下来，并加以评论，就能对项目内部隐含的基本假设达成共识。（该产品的市场定位，和依赖环境）
3.2.4.8 范围和局限性
项目范围定义了所提出的解决方案和概念和适用领域，而局限性则指出产品所不包括的某些性能。如果一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。记录这些需求以及拒绝它们的原因，以待查。
3.2.4.8.1 首次发行的范围
总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。应当避免将想到的每一个特性都包括到1.0版本产品中去。开发者应把重点放在能提供最大价值、花花费最合理的开发费用及普及率最高的产品上。
3.2.4.8.2 随后发行的范围
如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。
3.2.4.8.3 局限性和专用性
明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
3.2.4.9 业务环境
这一部分总结了一些项目的业务问题。
3.2.4.10 客户概貌
客户概述明确了这一产品的不同类型客户的一些本质特点，以及目标市场部门和在这些部门中的不同客户的特征。对于每一种客户类型，概述要包括：
Ø 各种客户类型将从产品中获得的主要益处；
Ø 它们对产品所持的态度；
Ø 感兴趣的关键产品的特性；
Ø 哪一类型客户能成功使用；
Ø 必须适应任何客户的限制。
3.2.4.11 项目的优先级
一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。
3.2.4.12 产品成功的因素
明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括我部素。如果可能，可建立测量的标准，用于评价是否达到业务目标，如：市场股票、销售量及收入、客户满意度、交易处理量和准确度。

4 系统设计（策划与程序员完成）
系统设计是新系统的物理设计阶段。根据系统分析阶段所确定的新系统的逻辑模型、功能要求，在用户提供的环境条件下，设计出一个能在计算机网络环境上实施的方案，即建立新系统的物理模型。
这个阶段的任务是设计软件系统的模块层次结构，设计数据库的结构以及设计模块的控制流程，其目的是明确软件系统"如何做"。
这个阶段又分两个步骤：概要设计和详细设计。概要设计解决软件系统的模块划分和模块的层次机构以及数据库设计；详细设计解决每个模块的控制流程，内部算法和数据结构的设计。这个阶段结束，要交付概要设计说明书和设计说明，也可以合并在一起，称为设计说明书。

4.1 架构设计
架构设计也被认为是体系结构设计，重点在于将系统分层并产生层次内的模块、阐明模块之间的关系。主要工作是根据架构分析和设计思想产生系统的架构图，并对架构图进行描述，说明分层的原因、层次的职责，并根据架构图绘制系统的物理部署图，描述系统的部署体系。根据架构图进行模块的划分并阐明模块划分的理由，绘制模块物理图以及模块依赖图。
体系结构是软件系统中最本质的东西：
（1）体系结构是对复杂事物的一种抽象。良好的体系结构是普遍适用的，它可以高效地处理多种多样的个体需求。
（2）体系结构在一定的时间内保持稳定。只有在稳定的环境下，人们才能干点事情，社会才能发展。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失败的。
良好的体系结构意味着普适、高效和稳定。

4.2 概要设计
概要设计的主要任务是把需求分析得到的数据流图（DFD）转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，总体设计建立的是目标系统的逻辑模型，与计算机无关。

概要设计重点在于将模块分解为对象并阐明对象之间的关系，引用架构设计说明书中的模块图，并阐述对于模块进行设计的大致思路。主要工作是根据该模块的职责对模块进行概要设计(分解模块为对象、描述对象的职责以及声明对象之间的接口)，绘制模块的对象图、对象间的依赖图以及模块主要功能的序列图，分别加以描述并相应的描述模块异常的处理方法。如果需要并描述数据视图。
在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。
4.2.1 概要设计的任务
制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
总体结构设计：
功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
模块层次结构：某个角度的软件框架视图；
模块间的调用关系：模块间的接口的总体描述；
模块间的接口：传递的信息及其结构；
处理方式设计：满足功能和性能的算法
用户界面设计；
数据结构设计：
详细的数据结构：表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
接口控制表的数据结构和使用规则
其他性能设计。
4.2.2 概要设计写什么
结构化软件设计说明书结构
任务：目标、环境、需求、局限；
总体设计：处理流程、总体结构与模块、功能与模块的关系；
接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）
数据结构：逻辑结构、物理结构，与程序结构的关系；
模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
运行设计：运行模块组合、控制、时间；
出错设计：出错信息、处错处理；
其他设计：保密、维护；
4.2.3 概要设计的模板
1引言
1.1编写目的
说明编写这份概要设计说明书的目的，指出预期的读者。
1.2背景
说明：
a. 待开发软件系统的名称；
b. 列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考文件，如：
a. 本项目的经核准的计划任务书或合同，上级机关的批文；
b. 属于本项目的其他已发表文件；
c. 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 （序号 资料名 文件编号 发表日期 出版单位 ）
2总体设计
2.1需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求（可以参考需求说明书）
2.1.1功能描述
2.1.2性能要求
2.2运行环境
简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定（可以参考需求说明书）
2.3基本设计概念和处理流程
说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
注：可以使用word绘制流程图（示意图），也可以使用专业的MS Visio或者Rational Rose绘制
2.4结构
用一览表及框图或者树状图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。
2.5功能需求与程序的关系
本条用一张如下的矩阵图说明各项功能需求的实现是处于哪个模块中的：

模块1
模块2
……
模块n
功能需求1
√

功能需求2
√

……

功能需求n
√
√

如：

模块1
模块2
……
模块n
用户名、密码验证
√

修改用户个人信息

√

2.6人工处理过程
说明在本软件系统的工作过程中不得不包含的人工处理过程（如果有的话）。
2.7尚未问决的问题
说明在概要设计过程中尚未解决、而设计者认为在系统完成之前必须解决的各个问题。
3接口设计
3.1用户接口
说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。
3.2外部接口（硬件接口）
说明本系统同外界的所有接口的安排，包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系，比如需要从外界系统接收哪些数据，或者需要输出哪些数据给外部系统等
3.3内部接口（软件接口）
说明本系统之内的各个系统元素之间的接口的安排（可暂时先省去）
4运行设计
4.1运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。
模块集合 运行条件 支持软件

4.2运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
运行名称 控制方法 操作步骤

4.3运行时间
说明每种运行模块组合将占用各种资源的时间。
运行名称 所占资源 时间

5系统数据结构设计
5.1逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
5.2物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。
补充说明：5.1和5.2可以合并为列出数据库中的所有表的设计结构
5.3数据结构与程序的关系
说明各个数据结构（表）与访问这些数据结构的模块的关系：

模块1
模块2
……
模块n
数据库表1
√

数据库表2
√

……

数据库表n
√
√

6系统出错处理设计
6.1出错信息
用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。
出错情况 提示信息 发生条件 解决办法

6.2补救措施
说明故障出现后可能采取的变通措施，可能包括：
a. 后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；
b. 降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；
c. 恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6.3系统维护设计
说明为了系统维护的方便而在程序内部设计中做出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系
4.3 详细设计
详细设计重点在于对每个模块进行实现，将模块的对象分解为属性和方法，并阐述如何实现。主要工作视根据模块概要设计详细描述对于模块内对象的实现，包括对象的职责、属性、方法、对象内功能的流程图、对象关联的类、对象的异常。(需要绘制的主要为类图)
详细设计的目标有两个：实现模块功能的算法要逻辑上正确和算法描述要简明易懂。
主要任务：
　　1．为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述；
　　2．确定每一模块使用的数据结构；
　　3．确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及模块输入数据、输出数据及局部数据的全部细节。
　　在详细设计结束时，应该把上述结果写入详细设计说明书，并且通过复审形成正式文档。交付给下一阶段（编码阶段）的工作依据。
　　4．要为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试，模块的测试用例是软件测试计划的重要组成部分，通常应包括输入数据，期望输出等内容。
5 编码（主要为程序员完成）
对具体软件的编写与实现。
　软件编码是将上一阶段的详细设计得到的处理过程的描述转换为基于某种计算机语言的程序，即源程序代码。
　　需注意根据项目的应用领域选择适当的编程语言、编程的软硬件环境以及编码的程序设计风格等事项
6 测试（主要为程序员完成）
“白盒测试”是指开发人员从程序内部对上述内容进行测试，而“黑盒测试”是指独立的测试人员从程序外部对上述内容进行测试。
6.1 单元测试
对单个模块进行测试
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
6.2 集成测试
对整个软件或工程进行测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
6.2.1 集成测试方法
　　集成测试应该考虑以下问题：
　　1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
　　2、各个子功能组合起来，能否达到预期要求的父功能；
　　3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
　　4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
6.2.2 集成测试的实施
　　集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
　　1、是采用何种系统组装方法来进行组装测试；
　　2、组装测试过程中连接各个模块的顺序；
　　3、模块代码编制和测试进度是否与组装测试的顺序一致
4、测试过程中是否需要专门的硬件设备；
6.2.3 集成测试完成标准
　　怎样判定集成测试过程完成了, 可按以下几个方面检查:
　　1、成功地执行了测试计划中规定的所有集成测试；
　　2、修正了所发现的错误；
　　3、测试结果通过了专门小组的评审。
7 系统测试
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。
8 维护（主要为程序员完成）
软件维护一般划分为主要的三类：纠错性维护（Corrective maintenance）、适应性维护（Adaptive maintenance）和完善性维护（Perfective maintenance）：
（1）纠错性维护。由于前期的测试不可能揭露软件系统中所有替在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。
（2）适应性维护。由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护。
（3）完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。

参考文献：《软件工程——理论，方法与实践》孙家广主编
收集于网络，如有侵权请联系管理员删除