软件开发过程与项目管理

1.软件及软件工程：

1.1 软件：

软件(Software)：一组对象或项目所形成的一个“配置”，由程序、文档和数据等部分构成。

1.2 软件四大特征：

1.3 软件开发方式：

1.3.1 结构化方法.

1.3.2 面向对象方法.

1.3.3 构件化方法:

软件=构件+框架。

1.3.4 SOA方法

面向服务。

1.4 软件工程：

用来开发、管理和维护软件产品的理论、方法和工具。

1.4.1 本质：

不同抽象层次之间的映射与转换。

用严格的规范和管理手段来缩小偏差，通过牺牲“时间”来提高“质量”

1.4.2 关注的目标：

1.4.3 最佳实践：

软件工程被看作一种实践的艺术：

– 做过越多的软件项目，犯的错误就越少，积累的经验越多，承接项目的成功率就越高

– 对新手来说，要通过多实践、多犯错来积累经验，也要多吸收他人的失败与教训与成功的经验

1.4.4 核心思想：

分治

复用

折中

演化：

在设计软件的初期，就要充分考虑到未来可能的变化，并采用恰当的设计决策，使软件具有适应变化的能力

2. 软件过程模型：

2.1 软件过程：

软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。

2.2 预测型：

项目开发活动通常按照固定顺序执行，前一步活动结果是后一步活动的“蓝图”，前一步对后一步结果的预期约束十分精准.

需要提前进行大量的计划工作，然后一次性执行，执行过程是一个连续的过程.

2.2.1 瀑布模型：

将各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。

上一个阶段结束，下一个阶段才能开始.

也叫做鲑鱼模型，向上一个阶段回溯非常的困难。

优点——追求效率
– 简单、易懂、易用、快速
– 为项目提供了按阶段划分的检查点，项目管理比较容易
– 每个阶段必须提供文档，而且要求每个阶段的所有产品必须进行正
式、严格的技术审查
 缺点——过于理想化
– 在开发早期，用户难以清楚地确定所有需求，需求的错误很难在开
发后期纠正，因此难以快速响应用户需求变更
– 开发人员与用户之间缺乏有效的沟通，开发人员的工作几乎完全依
赖规格说明文档，容易导致不能满足客户需求
– 客户必须在项目接近尾声的时候才能得到可执行的程序，对系统中
存在的重大缺陷，如果在评审之前没有被发现，将可能会造成重大
损失

2.2.2 V模型：

瀑布模型的一种变形，强调测试的重要性。

2.2.3 W模型：

同样强调测试，规范了完整的测试流程。

优点——开发过程重视测试/验证
– 简单易用，只要按照规定的步骤执行即可
– 强调测试或验证与开发过程的对应性和并行性； 测试方案在编码之
前就已经制定了
– 与瀑布模型相比，项目开发成功的机会更高
– 避免缺陷向下游流动
 缺点
– 比瀑布模型繁琐

2.3 增量：

软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多个相互作用的模块所形成的特定功能模块或功能模块组。

将未来系统分阶段完成，每个阶段都会产生一个可交付成果。每个阶段成果都是一个增量。

可以简单理解为模块化的预测型模型。

本质：以迭代的方式运用瀑布模型

优点：
– 在时间要求较高的情况下交付产品：在各个阶段并不交付一个可运
行的完整产品，而是交付满足客户需求的一个子集的可运行产品，
对客户起到“镇静剂”的作用
– 人员分配灵活：如果找不到足够的开发人员，可采用增量模型：早
期的增量由少量人员实现，如果客户反馈较好，则在下一个增量中
投入更多的人力
– 逐步增加产品功能可以使用户有较充裕的时间来学习和适应新产品，
避免全新软件可能带来的冲击
– 因为具有较高优先权的模块被首先交付，而后面的增量也不断被集
成进来，这使得最重要的功能肯定接受了最多的测试，从而使得项
目总体性失败的风险比较低
困难：
– 每个附加的增量并入现有软件时，必须不破坏原来已构造好的部分
– 同时，加入新增量时应简单、方便 ——该类软件的体系结构应当是
开放的
– 仍然无法处理需求发生变更的情况
– 管理人员必须有足够的技术能力来协调好各增量之间的关系

2.3.1 RAD:

快速应用开发RAD (Rapid Application Development).

通过基于构件的构建方法实现快速开发

多个团队并行进行开发，但启动时间有先后，先启动团队的提交物将作为后启动团队的输入.

缺点：
– 需要大量的人力资源来创建多个相对独立的RAD团队
– 如果没有在短时间内为急速完成整个系统做好准备，RAD项目将会
失败
– 如果系统不能被合理的模块化，RAD将会带来很多问题
– 技术风险很高的情况下（采用很多新技术、软件需与其他已有软件
建立集成等等），不宜采用RAD

2.4 迭代：

用来处理需求发生变化的情况.

允许对未完成和部分已完成的工作进行反馈。

2.4.1 快速原型法：

一开始并不知道最终成品的样子，通过沟通和迭代，得到最终的产品。

优点：
– 提高和改善客户/用户的参与程度，最大程度的响应用户需求的变化
– 克服预测型模型的缺点，减少由于需求不够明确带来的开发风险
 缺点：
– 为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维
护性，系统结构通常较差
– 可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后
可能会被直接交付给客户使用
– 额外的开发费用

2.4.2 螺旋模型：

重视风险评估。

螺旋模型沿着螺线旋转，在四个象限内表达四个方面的活动：

– 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制

– 风险分析：分析所选方案，考虑如何识别和消除风险

– 实施工程：实施软件开发

– 客户评估：评价开发工作，提出修正建议

出发点：开发过程中及时识别和分析风险，并采取适当措施以消除或
减少风险带来的危害
 优点：结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种
风险驱动型的过程模型：
– 采用循环的方式逐步加深系统定义和实现的深度，同时更好的理解、
应对和降低风险
– 确定一系列里程碑，确保各方都得到可行的系统解决方案
– 始终保持可操作性，直到软件生命周期的结束
– 由风险驱动，支持现有软件的复用
 缺陷：
– 适用于大规模软件项目，特别是内部项目，周期长、成本高
– 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将
会带来更大的风险

2.5 敏捷：

 开发过程中的“变化”是无处不在的，也是不可避免的
 在实际项目中，很难预测需求和系统何时以及如何发生变化
 对开发者来说，应将变化的意识贯穿在每一项开发活动中

应对变化、增量开发、快速反馈、快速迭代、快速交付

基于迭代的敏捷过程：每次迭代，都是针对最重要的系统功能，团队合作开发

基于流程的敏捷过程：不是按照迭代计划，而是根据团队能力，领取任务，恒速开发

2.5.1 十二条原则：

 准则1：Our highest priority is to satisfy the customer through early and 
continuous delivery of valuable software.
– 我们的最高目标是通过尽早和持续交付有价值的软件来满足客户
 准则2：Welcome changing requirements, even late in development. 
Agile processes harness change for the customer's competitive 
advantage.
– 欢迎对需求提出变更—即使是在项目开发后期；要善于利用需求变
更，帮助客户获得竞争优势
 准则3：Deliver working software frequently, from a couple of weeks to 
a couple of mouths, with a preference for the shorter timescale.
– 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
 准则4：Business people and developers must work together daily 
throughout the project.
– 项目过程中，业务人员与开发人员必须在一起工作
 准则5：Build projects around motivated individuals. Give them the 
environment and support they need, and trust them to get the job done.
– 要善于激励项目人员，给他们所需要的环境和支持，并相信他们能
够完成任务
 准则6：The most efficient and effective method of conveying 
information to and within a development team is face-to-face 
conversation.
– 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
 准则7：Working software is the primary measure of progress.
– 可用的软件是衡量进度的主要指标
 准则8：Agile processes promote sustainable development. The sponsors, 
developers, and users should be able to maintain a constant pace 
indefinitely.
– 敏捷过程提倡可持续的开发；项目方、开发人员和用户应该能够保
持恒久稳定的进展速度
 准则9：Continuous attention to technical excellence and good design 
enhances agility.
– 对技术的精益求精以及对设计的不断完善将提升敏捷性
 准则10：Simplicity--the art of maximizing the amount of work not 
done--is essential.
– 要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术
 准则11：The best architectures, requirements, and designs emerge 
from self-organizing teams.
– 最佳的架构、需求和设计出自于自组织的团队
 准则12：At regular intervals, the team reflects on how to become more 
effective, then tunes and adjusts its behavior accordingly.
– 团队要定期反省如何能够做到更有效，并相应地调整团队的行为

2.5.2 极限编程：

XP (eXtreme Programming).

2.5.3 结对编程：

Pair programming：两人一起编程，实时讨论、实时评审.

每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误；在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位；这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间
– 在开发层次上，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力
– 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感
– 在心理上, 当有另一个人在你身边和你紧密配合，做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄
– 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地应对人员流动；因为一个人的知识已经被其他人共享

2.5.4 Scrum:

一种敏捷开发框架.

2.5.4.1 燃尽图:

Burndown Chart.

2.5.4.2 任务墙:

Task Board

2.5.4.3 每日站会:

 团队成员站着开会 — 强迫在短时间(15分钟)内高效率讨论问题，保持
注意力集中
 强迫每个人向同伴报告进度, 迫使大家把问题摆在明面上，如果每日站
会定于早上开会的话，则每个团队成员应该回答下面问题：
– 我昨天做了什么(What have you done since yesterday? )
– 我今天要做什么(What are you planning to do today? )
– 我碰到了哪些问题(Do you have any problems that would prevent 
you from accomplishing your goal? )
 用简明的图表展现整个项目的进度，这个图最好放在大家工作的环境
中，或者每天传达给各个成员

2.6 其他：

2.6.1 形式化：

 优点：
– 应用数学分析方法，歧义性、不完整性、不一致性等问题更容易被
发现和改正，目的是“提供无缺陷的软件”
 缺陷：
– 形式化数学方法难以理解，可视性太差，对开发人员技能要求较高
– 构造形式化模型是一件非常耗时的工作，成本也很高
– 软件系统中的某些方面难以用形式化模型表达出来（如用户界面）
 应用场合：
– 对可靠性和安全性要求较高的一些关键系统，在真正被投入使用之
前，需要严格保证100%的正确；传统的方法靠人去验证，难以奏效

2.6.2 面向复用：

2.7 总结:

 瀑布模型：将全部需求以整体方式向前推进，无迭代
—— 基本模型
 增量模型：将需求分成多份，串行推进，无迭代
—— 串行的瀑布
 RAD模型：将需求分成多份，可并行推进，无迭代
—— 并行的瀑布
 原型模型：始终结果可见，不断迭代修正原型，直到开发完成
—— 基本模型
 螺旋模型：按瀑布阶段划分，各阶段分别迭代(原型+风险分析)
—— 原型+瀑布
 敏捷模型：将需求分成尽量小的碎片，以碎片为单位进行高速迭代
—— 增量+迭代+原型

3.软件项目管理：

软件项目管理(Software Project Management)：为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。

4.1 4P:

People：完成软件的主体是人，需要人做出非常大的努力

Process：完成软件的方式，所有活动的框架

Project：完成软件要做的事情，管理复杂性、风险和变化

Product：应用软件制品，定义目标、范围和约束，考虑备选方案

4.2 可行性分析：

4.3 任务分解：

将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作：化繁为简，分而治之。

4.3.1 WBS:

Work Breakdown Structure. 任务分解结构.

 WBS是对项目工作任务由粗到细的分解结果的表达形式
 WBS的最终结果是面向可交付的软件提交物（文档/功能模块）
 WBS组织并定义了整个项目范围

4.3.1.1 工作包：

Work Package.

 工作包是WBS的最低层次的可交付成果，即WBS中的“叶子节点”
 每个工作包应当由唯一主体负责
 项目管理的基本单位，成本估算、进度安排、跟踪控制等管理的最小对象

4.3.2 分解方法:

模板参照法.

类比法.

自顶向下方法.

 优点：非常符合人们解决问题的自然思维习惯
 缺点：对WBS开发人员的要求较高，即必须对项目充分了解，有丰
富经验，把控能力强
 适用项目：熟悉的业务领域项目，可以复用的项目

自底向上方法.

 优点：可以集思广益、头脑风暴，快速开展工作
 缺点：容易遗漏任务点，不够系统、全面
 适用项目：新业务领域项目，项目新增量，尤其适合敏捷方法

4.3.3 分解粒度:

最低层是可控的和可管理的，但是不必要过细
每个Work Package必须有一个提交物
有利于责任分配
推荐任务工作量分解到40小时以内，敏捷项目可分解到小时为单位

4.3.4 用户故事分解：

Epic（史诗故事）：
 史诗用户故事，特别大的用户故事通常被称为史诗
 在软件需求分类中，可以理解为“业务需求、愿景需求”
 可以分解为不同的细节级别的用户故事
 史诗用户故事通常太大，敏捷团队无法在一次迭代中完成，所以在进行之
前，要将它拆分为多个较小的用户故事
Feature（软件特性）：
 每个“特性”就是一组可以归类的软件需求
 一个“史诗”可以包含也可以跨越多个“特性”需求
User Story（用户故事）：
 一个“特性”可以包含多个“用户故事”
 一个“用户故事”就是一个软件功能
Task（任务）：
 一个“用户故事”开发完成需要多个“任务”
 一个“任务”就是一次“开发活动”

举个例子：

4.4 成本估算：

4.4.1 过程：

规模估算-工作量估算-成本估算.

4.4.2 代码行：

传统估算.

优点：
代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数
缺点：
1.对代码行没有公认的可接受的标准定义
2.代码行数量依赖于所用的编程语言和个人的编程风格
3.在项目早期，需求不稳定、设计不成熟、实现不确定
的情况下很难准确地估算代码量
4.代码行强调编码的工作量，只是项目实现阶段的一部
分，其他阶段无代码产生

4.4.3 功能点：

FP = UFC X TCF
FP 功能点
UFC 未调整的功能点计数
TCF 技术复杂度因子

UFC一般有下面五种：

EI:数据通过系统进入内部，如UI，表单等.

EO:向系统外界展示数据.

EQ:外部查询.内部没有数据处理.

EIF:外部接口文件;把信息传送给外部系统，或从外部系统取回接口信息,类似于多系统之间的调用接口.

ILF:内部逻辑文件，通过外部数据，改变内部存储的数据，如增删改等。

TCF由下面这个表决定：

TCF = 0.65 + 0.01 × ∑i=1 to 14 Fi

最终计算：

4.4.4 用例点：

未调整的角色权值
UAW = ∑C=c aWeight(c)×aCardinality(c)
一个为权值，一个为基数.

未调整的用例权值
UUCW = ∑C=c uWeight(c)×uCardinality(c)
一个为权值，一个为基数.

未调整的用例点
UUCP = UAW + UUCW

技术复杂因子
TCF = 0.6 + ( 0.01×∑i=1 to 13 TCF_Weighti×Valuei)
与上面相同。

环境复杂因子
ECF = 1.4 + ( -0.03×∑i=1 to 8 ECF_Weighti×Valuei)

调整的用例点
UCP = UUCP × TCF × ECF

4.4.5 类比：

估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量）。

 有类似的历史项目数据
 信息不足（例如市场招标）的时候
 要求不是非常精确估算的时候

4.4.6 自下而上:

利用任务分解图(WBS)，对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本.

 相对比较准确，它的准确度来源于每个任务的估算情况
 花费时间

4.4.7 三点估算：

基于任务成本的3种估算值(即最有可能成本、最乐观成本、最悲观成本）来加权平均计算预期成本的方法.

4.4.8 敏捷 Story Point:

采用轻量级估算方法快速生成高层级估算,短期规划可以进行详细的估算.

建立团队共同认可的估算基准值,其他 Story则以基准值做比对来定义工作量或成本.

4.4.8.1 快速故事点：

1. 团队人员排成一排
2. 第一名成员把一个用户故事放到他认为可以正确反映故事点值的那一列上
3. 第一名成员做完后排团队成员的最后一个位置
4. 下一个团队成员可以挪动已经摆好的用户故事，也可以选择另外的用户故事，
把它挪到他认为可以正确反映故事点值的那一列
5. 继续这个过程，直到所有用户故事都摆放完毕
6. 在此循环过程中，会有用户故事在不同的估值点列中来回挪动，引导师可以把
这些用户故事挪到列表的上方，最后专门讨论
7. 当大多数的故事都摆放好后，团队成员投票选择那些“问题”故事属于哪一列
8. 如果无法达成一致，把这个故事放到最高值的一列
9. 一旦团队成员对放置的故事都满意，计算每一列故事的个数，并且乘以故事点
值，从而得到所有的故事点

4.4.8.2 扑克：

 每个人独立思考出什么牌
 当每个人都表示准备就绪时，Scrum Master 喊“3，2，1-亮牌”
 每个人都同时出牌
 如果所有估算值均在三个连续数内，则取平均值
 如果所有估算值均超出了三个连续数，那么最高和最低估值的要说明理由，然后重新投票
 可以再重复投票最多两次，直到落到三个连续值内，则取平均值
 如果重复投票3次，仍然不能落在三个连续值内，去掉最高和最低估值，其余取平均值。

4.4.9 总结：

4.5 进度计划:

进度是对执行的活动和里程碑制定的工作计划日期表.

4.5.1 历时估算:

估计任务、路径、项目的持续时间.

4.5.1.1 定额估算:

4.5.1.2 经验导出:

4.5.2 管理图示:

根据项目任务的执行排序、历时估算及所需资源等进行分析，制定计划.

4.5.2.1 甘特图:

4.5.2.2 网络图:

网络图是活动排序的一个输出,展示项目中各个活动以及活动之间的逻辑关系.

4.5.2.2.1 PDM:

PDM Precedence Diagramming Method,优先图法

节点表示活动.箭线表示活动直接的逻辑关系.

4.5.2.2.2 ADM:

Arrow Diagramming Method 箭线法.双代号项目网络图.

线表示活动.

虚活动:表示逻辑关系的活动.

这个虚活动表示,只有在左边的ab活动都完成的情况下,才会进行右边的a活动.

4.5.2.2.3 里程碑:

4.5.3 进度计划编排:

针对项目开发中的所有活动进行合理的时间安排.

4.5.3.1 lag和lead:

lag表示滞后.

lead表示超前.

4.5.3.2 关键路径法:

首先明确基本概念:

 活动名称（Task）、历时时间(Duration)
 最早开始时间(Early Start，ES)
 最晚开始时间(Late Start，LS)
 最早完成时间(Early Finish，EF)
 最晚完成时间(Late Finish，LF)
 总浮动时间(Total Float，TF)
 自由浮动时间(Free Float，FF)
 调整超前量(lead)、调整滞后量(lag)
 前置活动(Predecessor，p)、后置活动(Successor，s)

浮动时间:

它是一个任务活动在不影响其它任务活动或者项目完成的情况下可以延迟的时间量.

关键路径:

网络图中时间最长的路径称为“关键路径”.

正推法:

按照时间顺序计算网络图中每个活动的最早开始时间ES和最早完成时间EF，从而找到关键路径的方法.

 EF = ES + Duration
 ES = EF(p) + Lag – Lead
 p为前置任务节点，Lag为前置节点与本节点相关的滞后量，Lead为前置节点允许当前节点的超前量
 当一个任务有多个前置任务时，选择前置任务中最EF(p)+Lag-Lead结果最大值作为当前节点的ES

4.6 团队计划:

4.6.1 组织方式:

4.6.2 组织结构类型:

4.6.2.1 职能型:

按照不同的职能进行划分.

优点
 以职能部门为主体承担项目，可充分发挥职能部门的人力优势
 职能部门内部技术专家可以被多个项目共享，节约人力资源
 同一职能部门内部专业人员便于交流、支援
 项目成员有调离时，容易在部门内部增员，保持项目技术连续性
 项目成员将项目工作与本职能部门工作融合，减少因项目临时性带来的不确定性
缺点
 客户利益与职能部门利益发生冲突，项目及客户利益往往不优先考虑
 当项目需要多个职能部门共同完成，或者部门内部承担多个项目时，资源的平衡就会出现问题
 当项目需要多个职能部门共同完成，由于权力分割不利于各部门沟通，项目经理没有足够权力控制项目进展
 项目成员在行政上隶属于各职能部门的领导，项目经理对项目成员没有足够的控制权力，沟通成本高

4.6.2.2 项目型:

按照项目进行划分.

优点：
 项目经理全权对项目负责，有权根据项目需要调配组织内部资源
 项目型组织的目标单一，完全以项目为工作中心，有利于项目完成
 项目经理对项目成员有全部权力，项目成员只需对项目负责，避免多重领导、无所是从的局面
 组织结构简单，易于操作，沟通简洁、快速，提高工作效率
缺点：
 不同项目团队的资源不能共享
 各个项目组之间无沟通机制，影响公司长远发展
 项目开发完成后，项目团队即解散，对于成员来说，缺乏事业上的连续性和安全感
 项目团队之间缺乏信息交流，跨组共享经验和技术较难

4.6.2.3 矩阵型:

前面两种类型的结合.

优点：
 专职的项目经理负责整个项目，以项目为中心，能迅速解决问题，在最短的时间内调配人员组成团队，将不同职能的人集中在一起
 多个项目可以共享各个职能部门的资源
 既有利于项目目标的实现，也有利于公司长远目标方针的贯彻
 项目结束后可以回到原来部门，项目成员顾虑减少了
缺点
 容易引起职能部门经理与项目经理权力的冲突
 资源共享可能会引起项目组之间的冲突
 项目成员有项目经理和原职能部门领导等多重领导，会有一定的焦虑和压力

4.6.3 职责计划:

4.6.3.1 责任分配矩阵:

RAM.

用来对项目团队成员进行分工的工具，明确其角色和职责.

4.6.3.2 组织结构图:

OBS.

用组织结构图来展示项目团队成员及其隶属组织关系、请示报告关系.

4.6.4 敏捷团队:

最有效的敏捷团队往往由三到九个成员组成(黄金人数5-9人).理想情况下，敏捷团队应该集中在一个工作场所工作.团队成员100%为专职成员，协同工作，自组织团队.敏捷鼓励自我管理团队.

仆人式领导
 仆人式领导是通过对团队服务来领导团队的
 注重理解和关注团队成员的需要和发展
 仆人式领导为团队赋权
 旨在使团队尽可能达到最高绩效

敏捷方法提倡高度透明
 邀请所有相关方参与项目会议和审查
 将项目信息发布到公共空间

4.7 软件演化:

4.7.1 Lehman定律:

 持续变化(continuing change)
– 现实世界的系统要么变得越来越没有价值，要么进行持续不断的变
化以适应环境的变化
– 环境变化产生软件修改，软件修改又继续促进环境变化
 复杂度逐渐增大(increasing complexity)
– 当系统逐渐发生变化时，其结构和功能将变得越来越复杂，并逐渐
难以维护并失去控制，直至无法继续演化，从而需要大量额外的资
源和维护工作来保持系统的正常运行
– 软件修改会引入新的错误，造成故障率的升高

4.8 软件维护：

在软件产品发行和投入运行使用之后对其的修改，以改正错误，改善性能或其他属性，从而使产品适应新的环境或新的需求。

 纠错性维护：修改软件中的缺陷或不足
 适应性维护：修改软件使其适应不同的操作环境，包括硬件变化、操作系统变化或者其他支持软件变化等
 完善性维护：增加或修改系统的功能，使其适应业务的变化
 预防性维护：为减少或避免以后可能需要的前三类维护而提前对软件进行的修改工作

4.8.1 遗留系统：

4.9 软件配置：

软件配置(software configuration)：由在软件工程过程中产生的所有信息项构成，它可以看作该软件的具体形态(软件配置项)在某一时刻的瞬间映像。

软件配置管理(Software Configuration Management, SCM).