山东大学软件学院软件项目管理期末复习

第一章软件项目管理概述

一、项目与软件项目

1、项目

是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力；是以一套独特而相互联系的任务为前提，有效利用资源，在一定时间内满足一系列特定目标的多项相关工作的总称

2、项目的特征

目标性、相关性、临时性、独特性、资源约束性、不确定性

3、项目与日常工作的区别

项目是一次性的，日常运作是重复进行的
项目是以目标为导向的，日常运作是通过效率和有效性体现的
项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线性管理
项目存在大量的变更管理，而日常运作基本保持持续的连贯性的

4、项目的分类

1)封闭性项目和开放式项目
2)业务项目和自我开发项目
3)企业项目、政府项目和非盈利机构的项目
4)盈利性项目和非盈利性项目
5)项目的层次分解：项目组合->项目集->项目->子项目（->任务->活动）

5、项目目标实现的制约因素

四因素：项目范围、成本、进度计划、客户满意度
衡量项目是否成功，应该看该项目是否在工程允许范围内按照成本预算和进度计划，生产出客户满意的产品

6、软件项目的特殊性

除具有项目的基本特征之外：
抽象性：软件是逻辑实体
复杂性
经验在软件项目中起很大作用
变更是软件项目中常见现象，需求，设计，技术，社会
项目的独特性和临时性决定项目是渐进明细的

7、软件项目要素的组成

软件开发的过程
软件开发的结果
软件开发赖以生存的资源
软件项目的特定委托人（客户）：需求者、资金提供者

二、项目管理

1、项目管理

指在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人(stakeholder)的需要和期望

2、项目干系人

指参与项目和受项目活动影响的人，包括项目发起人、项目组、协助人员、客户、使用者、供应商，甚至是项目的反对者

3、项目管理包括

项目范围，进度，成本，质量，人力资源，沟通，风险，变更管理

4、项目管理主要内容：

1）从管理职能角度划分，项目管理包括项目计划、组织、人事安排、控制、协调等方面的内容
2）从项目获得的全过程划分，项目管理包括项目决策、项目规划与设计、项目的招投标、项目实施、项目终结与后评价等方面的内容
3）从项目投入资源要素角度划分，项目管理包括项目资金财务管理、项目人事劳动管理、项目材料设备管理、项目技术管理、项目信息管理、项目合同管理等方面的内容
4）从项目目标和约束角度划分，项目管理包括项目进度管理、项目成本管理、项目质量管理等方面的内容

5、项目管理的特征

①项目管理具有创造性。项目的一次性特点，决定了每实施一个项目都要具有创新性。
②项目管理是一项复杂的工作，具有较强的不确定性。项目一般由多个部分组成，工作跨越多个组织、多个学科、多个行业，可供参考的经验很少甚至没有
③项目管理需要专门的组织和团队。项目管理通常要跨越部门的界限，在工作中将会遇到许多不同部门的人员
④项目经理的作用非常重要。项目经理要在有限的资源和时间的约束下，运用系统的观点、科学合理的方法对与项目相关的所有工作进行有效的管理，因此项目经理对项目的成败起着非常重要的作用。

6、软件项目管理的特征

①软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保障。需求在开始难以明确，与过早签订合同是矛盾的
②周期长，复杂度高，变数多
③软件需要满足一群人的期望，其对项目的关注点不同，利益也不同
④软件项目管理的目的是让软件项目能在控制之下，以预定成本，按质完成

三、项目管理知识体系PMBOK

四个生命周期：启动项目、组织和准备、执行项目工作、完成项目
PMBOK是项目管理的知识框架，9个知识领域，5个标准化过程组

1、九个知识领域

知识领域指项目经理必须具备的一些重要的知识和能力
四大核心知识领域：范围、时间、成本、质量
四大辅助知识领域：人力资源、沟通、风险、采购
项目整体管理：要求发挥项目管理整体上的支撑作用，它与其他项目管理知识领域相互影响

2、五个标准化过程组

(1)项目启动：确定项目目标、范围，制定项目章程、任命项目经理，对项目进行可行性研究与分析，包括经济性、风险性论证等
(2)项目计划：明确项目目标、分解项目目标，确定项目方案，制定完成项目的工作计划
(3)项目执行：项目执行即项目的实施，是协调人员、资源具体执行项目计划的过程，包括项目的详细设计与实施
(4)项目控制：项目管理的过程控制，通过定期监控和评估项目进度，确保项目的有序进行和目标的实现
(5)项目收尾：项目收尾过程是对项目完成后结果的验收，确认是否达到项目目标，形成完整的项目验收文档

3、项目管理的范围

五要素：技术，方法，团队建设，信息，沟通
项目经理主要工作时沟通
战术上：关注产品规格（满足质量要求），成本，进度
战略上：关注3P（人员、问题、过程）

四、过程管理与软件项目管理的关系

过程就是人们做事情的一种固有方式
过程管理目的在于让过程能共享、重用且不断改进

1、软件过程

软件过程包括：流程、技术、产品、活动间关系、角色、工具等，是软件开发过程的各个方面因素的有机结合
从做过的项目中总结出的一些完善的过程，称为最佳实践

2、过程管理

软件过程管理就是对最佳实践进行有效积累，形成可重复的过程，使最佳实践可以在机构内共享
过程管理的内容包括过程定义和过程改进
·过程定义：对最佳实践进行总结，形成一套稳定的可重复的软件过程
·过程改进：根据实践中对过程的使用情况，进行优化

3、过程管理和项目管理关系

项目管理用于保证项目的成功
过程管理用于管理最佳实践
这两项管理不是相互独立的，而是有机地紧密的结合的
过程管理的成果即软件过程可以在项目管理中付诸于项目管理工作

4、软件项目管理过程

项目初始：项目确立、生存期模型
项目计划：范围计划、成本计划、进度计划、质量计划、配置管理计划、人员与沟通计划、风险计划、合同计划、集成计划
项目执行控制：集成计划执行控制、核心计划执行控制、辅助计划执行控制
项目结束

第二章项目确立

第一篇项目初始

一、项目立项

明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可。这个阶段称为立项阶段。
立项流程：

1.1合同项目

甲方招标书定义—>乙方项目分析—>招标与竞标—>合同签署
1、甲方合同环境（甲方任务）
1）招标书定义
2）供方选择
3）合同签署
2、乙方合同环境（乙方任务）
乙方主要任务是进行项目选择
1）项目分析
2）提交建议书
3）合同签署

1.2内部项目

企业内部项目实施的核心是确定任务范围和相关各方进行有效地配合。这将通过相关各方之间的协议来调整。因此，在内部项目实施中，仅仅在合同签署过程中定义了一个协议签署过程。此处协议可视作为“合同”，但无特别的商业约束。其它方面可参考甲乙方的过程。

二、授权项目

对项目进行授权和初始化，以便确认相关的人知晓这个项目
形式
文档化输出，主要是项目章程
项目章程
确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等
项目经理的责任：
1）开发计划
2）组织实施
3）项目控制

三、初始项目范围分析

项目范围的主要内容

1. 项目的合理性说明
2. 项目目标
3. 项目可交付成果
   项目范围的依据
   合同
   规范
   SOW：客户份额（工作说明书）
   明确项目范围的重要性
   后期维护是否属于软件开发项目范围必须在项目责任书里明确

四、生存期模型

定义：描述了开发的主要阶段；定义了每个阶段药完成的主要过程和活动；确定了每个阶段的输入和输出

4.1 瀑布模型

适合的项目：在项目开始前，项目的需求、解决方案很明确
例如：公司的财务系统、库存管理系统、短期项目

4.2 V模型

适合的项目：在项目开始前，项目的需求、解决方案很明确；对系统的性能安全很严格
例如：航天飞机、公司的财务系统

4.3 Prototype原型模型

从最核心的方面开始，向用户展示完成的部分，然后根据用户的反馈信息继续开发原型，并重复这一过程。直到开发者和用户都认为原型已经足够好，然后在此基础上开发客户满意的软件产品
适合的项目：在项目开始前,项目的需求不明确；需要减少项目需求的不确定性
例如：确定显示界面；第一次开发的产品，验证可行性

4.4 增量式模型

适合的项目：项目开始，明确了需求的大部分，但是需求可能会发生变化；对于市场和用户把握不是很准，需要逐步了解；对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的

4.5 螺旋式模型

在四个象限上分别表达了四个方面的活动，即：
制定计划──确定软件目标，需求和选定实施方案，弄清项目开发的限制条件
风险分析──评估所选方案，考虑如何识别和消除风险
实施工程──实施软件开发，编码，测试等
客户评估──评价开发工作，提出修正建议，规划下期任务
适合的项目
风险是主要的制约因素
不确定因素和风险限制了项目进度
用户对自己的需求也不是很明确
需要对一些基本的概念进行验证
可能发生一些重大的变更
项目规模很大
项目中采用了新技术

4.6 渐进式阶段模型——最常用

综合了增量模型和螺旋式模型的一个实用模型：渐进式前进；阶段式提交
特点：
阶段式提交一个可运行的产品,每个阶段提交的产品是独立系统
关键的功能更早出现，可提高开发人员和客户信心
早期预警问题，避免软件缺陷不知不觉的增长
阶段式提交产品说明进展，减少报告负担
阶段性完成可以降低估计失误
阶段性完成均衡了弹性与效率
适合的项目：可以适合任何规模的项目，主要是中型或大型项目；希望随时看到未来的项目

4.7 选择生存期的步骤

熟悉各种生存期模型
评审、分析项目的特性
选择适合项目的生存期模型
标识生存期模型与项目不一致地方,并进行裁减

生存期模型总结：

1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付准则

第三章 项目范围管理

一、项目范围管理概述

项目范围管理是指对项目包括什么与不包括什么的定义与控制过程
这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产(开发)这些产品所用到的过程有共同的理解
项目范围管理包括确保项目做且只做完成项目所需的全部工作的过程

1.1概念

范围：“范围” 一词指作为一个项目所提供的产品和服务的总和。
产品范围：根据产品的需求确定产品范围的完成情况，即一个产品或一项服务应该包含的特征和功能
项目范围：根据项目计划来确定项目范围的完成情况，即为了交付具有特定特征和功能的产品所必须要做的工作

1.2项目范围

项目范围指为了成功达到项目的目标，项目所规定要做的。即定义项目管理的工作边界，确定项目的目标和主要的项目可交付成果，所必须完成的、而且仅限于必须要做的全部项目工作
它的基本思路就是首先明确要做什么，然后利用分解技术将项目工作细化，核实范围并在全过程对范围的变化进行控制
它的核心是工作分解结构（Work Breakdown Structure ，WBS）
产品范围的完成是对照产品质量性能要求进行衡量的。
项目范围的完成是对照项目计划进行衡量的。
确定项目范围的意义：
(1)保证了项目的可管理性
(2)提高费用、时间和资源估算的准确性
(3)确定进度测量和控制的基准
(4)有助于清楚地分派责任
(5)可作为评价项目成败的依据
项目范围管理的内容：
（1）范围规划
（2）范围定义
（3）制定工作分解结构（WBS）
（4）范围确定
（5）范围控制

二、范围规划

2.1 概念

制定项目范围管理计划，记载如何确定、核实与控制项目范围以及如何制定与定义工作分解结构(WBS)

2.2 项目范围管理计划

项目范围管理计划是项目管理团队确定、记载、核实、管理和控制项目范围的指南
项目范围管理计划的内容有:
编制详细项目范围说明书；
制作工作分解结构，
确定如何维持与批准工作分解结构；
如何正式验收项目已完成可交付成果;
控制详细项目范围说明书变更请求。

三、收集需求

3.1 收集需求

访谈、问卷调查、群体创新技术、头脑风暴

3.2 需求工程

四、定义范围

范围定义是详细描述项目和产品的过程，并把结果写进详细的项目范围说明书中，作为将来项目决策的根据

4.1 项目范围说明书

项目范围说明书详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。项目范围说明书也表明项目干系人就项目范围所达成的共识。描述项目要做和不要做的工作详细程度，决定着项目管理团队控制项目范围的有效程度。
主要内容：
（1）项目名称及描述——项目要要解决的问题、背景等
（2）项目论证情况
（3）项目目的——为配置资源、衡量利弊关系提供依据
（4）项目目标——项目成功完成所必须满足的定量标准
（5）项目产品或服务的描述——产品或服务的描述在项目的早期一般都不很详细，而在后续阶段随着产品或服务特性的逐步详尽而细化
（6）可交付结果清单——项目完成后以及在执行过程中的子产品的总和，它们各自得到完整并满意的完成后，才标志着项目的完成
（7）制约因素
·项目是否受到特别的限制来制约项目经理的各种选择。
·这些限制因素可能是环境决定的，如地形、气候情况，也可能是由政府机构、客户决定的，或可能是设备、技术、资金、时间等方面的限制。这些都要在项目一开始就摆到桌面上来，以便你有机会反复权衡并寻求可替换解决的办法。
（8）假设前提
·指为了制定项目计划，对那些暂时无法确定或以后极有可能变化的因素做出某些假设。
·例如，在编制人力资源计划时，其中某一职位的人员暂时还没有，于是项目小组便假设一个日期，作为该岗位人员的到位时间，这就是一种假设。显然，假设往往包含一定程度的风险。
项目目标：
目标必项符合SMART原则，明确、可行、具体和可以度量
目标确定：
1、项目目标是项目预期的结果或最终产品，应明确具体，并尽量定量化，主要涉及：
时间——约束性目标
费用——约束性目标
技术——Product requirements specification
产品——满足特定需求、个性化的可交付性成果
2、项目目标遵循的原则：SMART
明确的、可度量的、可达到的、结果驱动的、时间性
3、项目目标三要素：时间、成本和质量

五、制定工作分解结构

项目范围定义就是把项目的主要可交付成果分为较小的、更易管理的单元。
项目范围定义的输出（结果）就是工作分解结构（WBS）。
WBS(Work Breakdown Structure)主要是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素。
它是一种在项目全范围内分解和定义各层次工作包的方法，WBS按照项目发展的规律，依据一定的原则和规定，进行系统化的、相互关联和协调的层次分解。
结构层次越往下层则项目组成部分的定义越详细，WBS最后构成一份层次清晰，可以具体作为组织项目实施的工作依据。

六、范围确认

范围确认是正式验收项目已完成的可交付成果的过程

范围核实是指项目干系人（利益相关者）对项目范围（已界定的）的正式承认

核实项目范围：项目范围说明书的核实；项目交付结果的核实
范围确认的难点在于：与用户沟通，尤其是定制系统
项目利益相关人进行范围确认时，要检查：
⑴可交付成果是确实的，可核实的；
⑵每个交付成果有明确的里程碑，且里程碑明确、可辨别的
⑶有明确的质量标准；
⑷项目范围覆盖了需要完成的产品或服务进行的所有活动；
⑸项目范围风险要可控
⑹项目范围所能产生的收益大于成本
各方对范围确认的关注点：
管理层：对进度、资金、资源的影响
客户：产品
项目管理者：可交付物是否足够和必须完成？事件、资金、资源是否足够？主要的潜在风险、预备解决的方法
项目组成员：自己参与和负责的元素、自己的工作时间
范围变更原因：
外部环境
新的技术、手段和方案的出现
项目实施组织
项目业主的要求
对范围变更进行控制时，要以工作分解结构、项目进展报告、变更请求、范围管理计划为依据。必须经过范围变更控制系统。
1、范围确认是取得利害关系者对已完成的项目范围与相应的可交付成果正式验收的过程。
2、确认项目范围包括审查可交付成果，确保每一项结果都令人满意。
3、范围确认与质量控制的不同之处在于，此过程主要关心验收可交付成果，而质量控制主要关心满足为可交付成果规定的质量要求。
范围核实贯穿项目的始终，质量控制一般先于范围核实进行

七、控制范围

范围变更
范围变更就是对原先已经达成一致的工作分解结构中定义的项目范围所做的任何修改。
范围变更控制
范围变更控制就是对范围变更进行管理。为尽量减轻范围变更
控制工作，关键是要做好项目的范围核实的工作。

第三章软件项目需求管理

一、软件需求定义

软件需求是指用户对软件的功能和性能的要求
软件需求三个层次：业务需求；用户需求；功能需求
需求定义：
业务需求：组织机构或客户对系统，产品高层次的目标要求，由管理人员或市场分析人员确定
用户需求：用户通过使用本软件产品必须完成的任务，用户协助提供
功能需求：开发人员必须实现的软件功能
软件需求规格：描述了软件系统应具有的外部行为，即系统展现给用户的行为和执行的操作
约束：对开发人员在软件产品设计和构造上的限制
需求类型：
功能需求：系统必须执行的功能
非功能需求：对实际使用环境所做的要求，如性能要求，可靠性，安全性
非功能需求比功能需求要求更严格，更不易满足
需求开发和需求管理的界限：

二、需求管理的过程：

2.1 需求获取

将用户要求变成项目需求
主要任务：和用户方的领导层，业务层人员的访谈式沟通
目的：
从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构，业务流程，硬件环境，软件环境，现有运行系统
步骤：
1、了解客户的所有用户类型以及潜在的类型，根据他们的要求来确定系统的整体目标和系统的工作范围
2、对用户进行访谈和调研
形式：会议、电话、电子邮件、小组讨论、模拟演示。要有记录
3、对收集到的用户需求做进一步的分析和整理
了解需求的本意，判断提出需求的理由
描述“实现什么”，“做什么”
识别和分析用户没有明确提出来的隐含需求
4、需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。
明确标识出那些未确定的需求项
是需求符合系统的整体目标
保证需求项之间的一致性，解决需求项之间可能存在的冲突
需求获取：
确定需求开发过程
将需求分组管理具有很重要的意义
编写项目视图和范围文档
用户群分类 - 应该建立干系人联系册
选择产品代表
建立（用户）核心队伍
确定使用实例
召开应用程序开发联系会议
分析用户工作流程
确定质量属性
检查问题报告
需求重用

2.2需求分析

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述
也称需求建模，为最终用户所看到的系统建立一个概念模型
与获取的区别：使用模型描述，以获取用户更明确的需求
图形描述整体结构
原型，页面流或其他方式提供可视化界面
模型描述系统功能项，数据实体，外部实体，实体关系及状态转换
基本策略：头脑风暴，专家评审，焦点会议组等方式进行具体的流程细化，数据项的确认
需求分析：
绘制关联图
创建用户接口原型
分析可行性
确定需求优先级
建立需求模型
编写数据字典
应用质量功能调配

2.3 需求规格编写

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书(SRS)
目的：使用户和软件开发者双方对软件的初始规定有一个共同理解，使之成为整个开发工作的基础

2.4 需求验证

需求验证过程
审查需求文档
依据需求文档编写测试用例
编写用户手册
确定产品验收合格的标准
需求验证的内容
有效性检查
一致性检查
完备性检查
其他
需求验证：
以需求规格说明为输入，通过符号执行、模拟或快速原型等途径
正确性
一致性
完整性
可行性：必须在已知系统和环境的权能和限制范围内可以实施
必要性
可检验性：能写出测试用例满足需求
可跟踪性：在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接
最后的签字

2.5 需求变更

需求变更管理：
①确定需求变更控制过程
②建立变更控制委员会(SCCB)
③进行需求变更影响分析
④跟踪所有受需求变更影响的工作产品
⑤建立需求基准版本和需求控制版本文档
⑥维护需求变更的历史记录
⑦跟踪每项需求的状态
⑧衡量需求稳定性
需求变更成本可以占项目总成本的40％。根据变更输入，按照变更控制系统规定的审批程序执行，通过严格审查变更申请后，决定项目变更是否应得到批准或拒绝
需求变更控制流程

三、需求建模的基本方法

3.1 原型方法

3.2 结构化分析法

结构化分析方法-技术
数据流图(DFD)
数据字典(DD)
系统流程图

3.3 面向对象——用例图、顺序图、状态图、活动图

用例分析法
一个用例（use case）就是系统向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求。
所有用例结合起来就构成了“用例模型”，描述系统的全部功能
优点：
用户导向的
可以方便地得到系统功能的测试用例
·一个系统往往可以从不同的角度进行观察，从一个角度观察到的系统，就构成系统的一个视图（view）
·识别出系统的Actor
·描述主要的Use case
·实现用例视图 （Use case Diagram）
·实现顺序视图（Sequence Diagram）
·实现活动视图（Activity Diagram）
·状态视图（State Diagram）等

3.4 功能列表法

功能列表（feature list）方法是对项目的功能需求进行详细说明的一种方法
是基于功能特性及其层次关系来描述需求的方法

第五章 软件项目任务分解

一、任务分解定义

任务分解过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作
任务分解结果：WBS（图表形式、清单形式）
WBS:
WBS是对项目由粗到细的分解过程，是分级的树形结构。
是面向交付成果的
WBS它组织并定义了整个项目范围
工作包：
WBS的最低层次的可交付成果
工作包应当由唯一主体负责

二、任务分解方法

·类比
利用项目在某种程度上的相似性
使用类似项目的wbs作为参考
使用项目管理工具提供的一些wbs实例
·模版参照

·自上而下（一般到特殊）

·自下而上（特殊到一般）

三、任务分解的基本步骤

①确认并分解项目的组成要素(WBS编号)
②确定分解标准（分解的标准要统一）
按照生存期阶段分解
按照产品组成分解
不能同时使用两种标准进行分解
③确定分解是否详细（是否可以作为费用和时间估计的标准）
④确定项目交付成果（可以编制WBS字典）
⑤验证分解的正确性
检验分解结果的标准；
最底层的要素是否是实现目标的充分必要条件
最底层要素是否有重复的
每个要素是否清晰完整定义
最底层要素是否有定义清晰的责任人
是否可以进行成本估算和进度安排
WBS任务分解建议
最低层是可控的和可管理的，但是不必要的过细
每个Work package必须有一个提交物
定义任务完成的标准
有利于责任分配
推荐任务分解到40小时以内

第六章软件项目成本计划

一、成本估算概述

成本估算是对完成项目所需费用的估计和计划
重要性和意义
软件成本估算是成本管理的核心
成本估算是项目计划中的一个重要组成部分
要实行成本控制，首先要进行成本估算
软件成本估算，一直是软件工程和软件项目管理中最具挑战、最为重要的问题
直接成本
指与项目有直接关系的成本费用，是与项目直接对应的，包括人员的工资、材料费用、外包外购成本等，包括开发成本、管理成本、质量成本等。
间接成本
（如房租、水电、员工福利、税收等） 不能归属于一个具体的项目，是企业的运营成本，可以分摊到各个项目中。
软件项目规模与成本的关系
·软件项目规模即工作量（规划 管理 需求 设计 编码 测试 维护）
是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务。
·软件成本估算，预测开发一个软件系统所需要的总工作量的过程。
软件项目成本，指软件开发过程中所花费的工作量及相应的代价。
·代价是待开发的软件项目需要的资金
软件规模单位
LOC (Lines of Code) 代码行：源代码长度的测量
FP (Function Point) 功能点：用系统的功能数量来测量
人月
人天
人年
成本估算
规模是成本估算的主要因素，是成本估算的基础
人的劳动的消耗所需要的代价是软件产品的主要成本，即开发成本。是以一次性开发过程所花费的代价来计算的。
开发成本的估算，应以软件项目管理，需求分析，设计，编码，测试，等这些过程所花费的代价作为依据。
成本估算贯穿于软件的生存期。

1.1软件项目成本

影响IT项目成本的因素
⑴ 耗用资源的数量和价格
·中间产品和服务、市场人力资源、硬件、软件的价格也对成本产生直接的影响。价格对项目预算的估计影响很大。
⑵ 项目工期
·项目的费用由直接费用和间接费用组成，一般工期越长，项目的直接费用越低，间接费用越高；工期越短，直接费用越高，间接费用越低。
⑶ 项目质量
·质量总成本由质量故障成本和质量保证成本组成。
质量故障成本指为了排除产品质量原因所产生的故障，保证产品重新恢复功能的费用。
质量保证成本指为了保证和提高产品质量而采取的技术措施所消耗的费用。
·项目产品的质量越低，由于质量不合格引起的损失就越大，即故障成本增加。
·质量越高，相应的质量保证成本也越高，故障就越少，由故障引起的损失也相应减少。
·因此需要建立一个动态平衡关系。
⑷ 项目管理水平
·高的管理水平可以提高预算的准确度，加强对项目预算的执行和监管，对工期的控制严格限制在计划许可的范围之内，对设计方案和项目计划更改造成的成本增加、减少和工期的变更，可以较为有效地控制，减少风险的损失等。

二、估算过程

成本管理是确保项目在预算范围之内的管理过程，包括成本估算、成本预算、成本控制等过程

2.1 估算输入

主要依据包括：
项目需求
工作分解结构WBS
资源计划
资源单位价格
进度计划
历史信息

2.2 估算处理

代码行估算法、功能点估算法、用例点估算法、类比 (自顶向下)估算法、自下而上估算法、参数估算法、专家估算法
成本分为直接成本和间接成本

2.3 估算输出

规模成本估算的结果可以以简略或详细的形式表示。
估算通常以货币单位表达，如元、法郎、美元等，这个估算便是成本估算的结果；也可用人月、人天 或人小时这样的单位，这个估算结果便是项目规模估算的结果。有时用复合单位。
成本估算是一个不断优化的过程。
估算说明 ①工作范围的描述 ②说明估算的基础和依据

三、估算方法

估算基本方法：
代码行估算法
功能点估算法
用例点估算法
类比 (自顶向下)估算法
自下而上估算法
参数估算法
专家估算法

3.1代码行估算法（LOC）

面向规模的度量
从软件程序量的角度定义项目规模
与具体的编程语言有关；分解足够详细；有一定的经验数据（类比和经验方法）
优点
代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。
缺点
对代码行没有公认的可接受的标准定义。
代码行数量依赖于所用的编程语言和个人的编程风格。
在项目早期，需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
代码行强调编码的工作量，只是项目实现阶段的一部分。

3.2功能点估算法（FP）

面向功能点的度量
与实现的语言和技术没有关系；用系统的功能数量来测量其规模；通过评估、加权、量化得出功能点

计算步骤：
1）确定应用程序必须包含的功能。一个功能等价于处理显示器上的一屏显示或者一个表单
2）对每一项功能，通过计算4类系统外部行为或事务的数目，以及1类内部逻辑文件的数目来估算由一组需求所表达的功能点数目。
功能计数项：外部输入EI 外部输出EO 外部查询EQ 外部接口文件EIF 内部逻辑文件ILF
·外部输入(External Inputs EI) ：外部输入给软件提供面向应用的数据项。在这个过程中，数据穿越外部边界进入到系统内部
·外部输出(External Outputs EO) ：外部输出是程序生成供最终用户或其他程序使用的屏幕、报表（report）、图表（graph） 或控制信号等。派生数据由内部穿越边界传送到外部
·外部查询(External Inquiry EQ) ：外部査询是输入/输出组合，其中一个输入引出一个即时的简单输出，没有处理过程。
·外部接口文件（External Interface Files EIF’s）：外部接口文件是受其他程序控制的文件，是用户可以识别的一组逻辑相关数据，这组数据只能被引用。数据完全存在于应用的外部，并且由另一个应用维护。外部接口文 件是另外一个应用的内部逻辑文件
·内部逻辑文件 (Internal Logical Files ILF’S)：内部逻辑文件是用户可确认的、在应用程序内部维护的、逻辑上相关联的最终用户数据或控制信息。完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目
3）在估算中对 5类功能计数项 中的每一类功能计数项按其复杂性的不同分为简单（低）、一般（中）和复杂（高）3个级别。产品中所有功能计数项加权的总和，就形成了该产品的未调整功能点计数（UFC）

4）这一步是计算项目中14个技术复杂度因子（TCF）。下表是14个技术复杂度因子，每个因子的取值范围是0~5

技术复杂度因子 TCF=0.65+0.01×∑Fi
5）根据功能点计算公式FP=UFC×TCF计算出调整后的功能点总和

常数和参数的加权因子是根据经验确定的。
调整系数一般在0.65~1.35之间变化

！！！记得看ppt上的例子

3.3用例点估算法

步骤：
1、计算未调整的角色的权值UAW;

C={simple, average, complex}；aCardinality©是参与的角色数目

2、计算未调整的用例的权值UUCW ;

uCardinality©是参与的用例数目

3、计算未调整的用例点UUCP;

4、计算技术和环境因子TEF;

技术复杂度因子TCF——13个

环境因子ECF——8个

5、计算调整的用例点UCP ;

6、计算工作量(man-hours)

PF是Productivity Factor，是项目生产率，其默认值为20

3.4类比（自顶向下）估算法

估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中
特点：
类比估算法通常比其他方法简便易行，成本低。
这种估算是基于实际经验和实际数据的。
有两种情况可以使用这种方法：其一是以前完成的项目与新项目非常相似，其二是项目成本估算专家或小组具有必需的专业技能。
这种方法的局限性在于很多时候没有真正类似项目的成本数据，因为项目的独特性和一次性使多数项目之间不具备可比性
使用情况：
有类似的历史项目数据
信息不足（例如市场招标）的时候
要求不是非常精确估算的时候
类比估算中，需要评价不同项目间的相似程度。两种常用求距离方式来度量差距
不加权的欧氏距离
加权的欧氏距离
由于相似度计算比较麻烦，类比估算基本上采用主观推断，很少采用相似度计算方法

3.5 自下而上估算

利用任务分解图(WBS),对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。
通常是在项目开始以后，或者WBS已经确定的项目，需要进行准确估算的时候釆用。
优点：
准确度较好
缺点：
需要花费一定的时间
估算本身也需要成本支持
可能发生虚报现象

3.6 参数估算法——COCOMO / Walston-Felix

也称为算法模型或经验导出模型，是一种使用项目特性参数建立数学模型来估算成本的方法，是通过大量的项目数据进行数学分析导出的模型，是一种统计技术。
一般来说，参数模型提供工作量（规模）的直接估计。
典型的参数模型是通过过去的项目数据进行回归分析得出的回归模型。
基本思想
找到软件工作量的各种成本影响因子，并判定它对工作量所产生影响的程度是可加的、乘数的还是指数的，以期得到最佳的模型算法表达形式。
·当某个因子只影响系统的局部时，一般认为它是可加的
如：给系统增加源指令、功能点 实体、模块、接口等，大多只会对系统产生局部的可加的影响。
·当某个因子对整个系统具有全局性的影响时，则认为它是乘数的或指数的
如增加服务需求的等级或者不兼容的客户等。
规模（成本）模型
基于回归分析的模型分为两类
1、静态单变量模型
2、动态多变量模型
静态单变量模型
整体公式：

E:以人月表示的工作量
a,b,c:经验导出的系数
S:主要的输入参数(通常是LOC,FP等)
面向FP驱动的静态单变量模型
面向LOC驱动的静态单变量模型：Walston-Felix(IBM)；COCOMO
1、IBM模型 Walston-Felix模型

该模型是静态单变量模型
在此模型中，一般指一条机器指令为一行源代码
源代码行数一般不包括程序注释、作业命令、调试程序在内
对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑
定义: 转换系数＝机器指令条数／非机器语言执行步数。
2、COCOMO模型
结构化成本模型
是目前应用最广泛的参数型软件成本估计模型
基本原理：
将开发所需要的工作量表示为KLOC软件规模和一系列成本因子的函数,基本估算公式:

effort即开发软件所需要的人力（人月PM）
PM是工作量，通常表示为人月
A可以校准的常量;
S为KLOC软件规模;
E为规模的指数,说明不同规模软件具有的相对规模经济和不经济性;
EM为工作量乘数,反映某个项目特征对完成项目开发所需工作量的影响程度;
n为描述软件项目特征的成本驱动因子的个数。
模型的等级，级别越高，模型的参数约束越多：
基本COCOMO：

相关信息极少情况下使用。静态单变量模型，它用一个以已估算出来的源代码行数为自变量的函数来计算软件开发工作量
中等COCOMO：

需求确定之后使用。在LOC为自变量函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算
高级COCOMO：
设计完成后使用。包括中级COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对项目过程中分析、设计等各步骤的影响
项目的模式
有机: Organic(组织)
各类应用程序，例如数据处理、科学计算 等
受硬件的约束比较小，程序的规模不是很大
半有机: Semidetached（半分离）
各类实用程序，介于上述两种软件之间，例如编译器（程序）
规模和复杂度都属于中等或者更高
嵌入式: Embedded
系统程序，例如实时处理、控制程序等
紧密联系的硬件、软件和操作的限制条件下运行，软件规模任意
基本COCOMO模型

组织模式指规模较小的、简单的软件项目
半分离模式指规模和复杂性处于中等程度的软件项目
嵌入模式指必须要求在一组紧密联系的硬件、软件及操作约束下开发的软件项目
中等COCOMO模型

F为乘法因子，是根据成本驱动属性打分 的结果，是对公式的校正系数
ab取值：

Di为15个成本驱动因子的取值。产品属性、平台属性、人员属性、过程属性

高级（详细）COCOMO
高级COCOMO模型的工作量及进度估算公式与中级COCOMO模型一致
高级COCOMO 模型引入了两种主要功能：
·阶段敏感工作权数：某些阶段（设计、编码、调试）比其他阶段有关因素的影响可能更大。高级COCOMO 模型为每个因素提供了一个“阶段敏感工作权数”。
·三层产品分级结构：3个产品层次是模块、子系统和系统

AEXP应用影响因子
3、COCOMO Ⅱ
3个层次的软件开发工作量估算模型：
（1）应用组装模型—规划阶段
主要用于估算构建原型的工作量
模型名称暗示在构建原型时大量使用已有的构件
（2）早期设计模型—设计阶段
这个阶段设计了基本的软件结构，基于功能点(function point, FP)或可用代码行
5个规模指数因子、7个工作量乘数因子

（3）后体系结构模型—开发阶段
用于完成顶层设计和获取详细项目信息阶段
该模型与早期设计模型基本是一致的，不同之处在于工作量系数不同。后体系结构模型中的工作量系数（即成本因素）划分成产品因素、平台因素、人员因 素和项目因素4类，共17个属性。

4、参数估算法总结
使用条件
具有良好的项目数据为基础
存在成熟的项目估算模型
特点
比较简单,而且也比较准确
如果模型选择不当或者数据不准,也会导致偏差

3.7 专家估算法

1、组织者确定专家，这些专家互相不见面
2、组织者发给每位专家一份软件规格说明
3、专家以无记名对该软件给出3个规模的估算值
①最小值 ai
②最可能的值 mi
③最大值 bi
4、组织者计算每位专家的平均值 Ei=(ai+4mi+bi)/6
5、综合结果后，再组织专家无记名填表格，比较估算偏差，并査找原因
6、重复多次，最终可以获得一个多数专家共识的软件规模，即E=（E1+E2+…En）/n
3.8 实用软件估算步骤
是一种自下而上和参数法的结合模型,步骤如下:
1、对任务进行分解:1,2,…,I,…n
2、估算每个工作包的成本Ei
·直接估算成本Ei
·先估算规模Qi，然后估算成本Ei= Qi 人力成本参数
3、直接成本=E1+E2+……+ Ei+……+ En
·开发成本
·管理成本
·质量成本
4、间接成本估算
·按照企业模型直接估算
·简易算法（没有成熟企业模型）：间接成本=直接成本间接成本系数
5、项目总估算成本= 直接成本+间接成本
·估算成本=直接成本+间接成本
·估算成本=直接成本+直接成本*间接成本系数
·估算成本=直接成本(1+间接成本系数)

四、成本预算

成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去
目的：产生成本基线，作为度量项目成本性能的基础
分配项目成本预算包括三种情况：
·给任务分配资源成本：根据每个任务的资源分配情况来计算任务的成本预算
·给任务分配固定资源成本：当一个项目的资源需要固定数量的资金时，可以向任务分配固定资源成本
·给任务分配固定成本：有些任务是固定成本的类型的任务，也就是说，管理者知道某项任务的成本不变，不管任务的工期有多长，或不管任务使用了那些资源。在这种情况下，管理者向任务直接分配成本
成本基线：
成本基线是每个时间阶段内的成本。是项目管理者度量或监控项目的依据

第七章软件项目进度计划

一、进度管理基本概念

1.1 进度

进度是对执行的活动和里程碑制定的工作计划日期表
进度计划的重要性
按时完成项目是项目经理最大的挑战之一
时间是项目规划中灵活度最小的因素
进度问题是项目冲突的主要原因
主要过程：
任务定义：根据WBS分解出主要的任务（活动）；
任务关系：确立任务（活动）之间的关联关系；
历时估算：然后估计每个任务（活动）需要的资源、时间；
项目进度编排：最后编制出项目的进度计划。

1.2任务定义

WBS的每个工作包需要被划分成所需要的活动（任务），每个被分配的活动（任务）都应该与一个工作包相关，通过任务（活动）定义这一过程可使项目目标体现出来。
任务定义：确认和描述一些特定的活动的过程，WBS分解的结果

1.3项目任务的关联关系

项目各项任务之间存在相互联系与相互依赖关系
根据这些关系安排任务之间的顺序
任务（活动）间关系的依据
硬逻辑关系（强制性依赖关系）：固有的、不可违背的
软逻辑关系：人为的、主观的
外部依赖关系：项目活动与非项目活动之间

1.4进度管理图示

1、网络图
网络图是活动排序的一个输出，展示项目中各个活动以及活动之间的逻辑关系
PDM优先图法，节点法（单代号）网络图
节点表示活动（任务）
箭线表示各活动（任务）之间的逻辑关系
ADM箭线法（双代号）网络图
节点表示前一个任务的结束以及后一个的开始
箭线表示任务
双代号表示网络图中两个带好唯一确定的一个任务
虚活动（虚线表示）
为了定义活动
为了表示逻辑关系
不消耗资源
2、甘特图
显示基本的任务信息
可以查看任务的工期、开始时间和结束时间以及资源的信息
只有时标，没有活动的逻辑关系

3、里程碑图
是由一系列的里程碑事件组成的
里程碑图显示项目进展中的重大工作完成
里程碑不同于活动：活动需要消耗资源；里程碑仅仅表示事件的标记
4、资源图

二、任务历时估算

估计任务的持续时间
基本方法：
定额估算法
经验导出模型
PERT（工程评估评审技术）
基于承诺的进度估计
Jones的一阶估算准则

2.1 定额估算法

方法简单，容易计算
适合项目的规模较小

2.2 经验导出模型

2.3 PERT工程评估评审技术

利用网络顺序图的逻辑关系和加权算法估算任务历时
加权算法
它是基于对某项任务的乐观，悲观以及最可能的概率时间估计

标准差σ = （最大估算值P-最估算值O）/6
方差σ2 = [(最大估算值P-最小估算值O)/6]2

2.4 基于承诺的进度估计法

基于开发人员做出的进度承诺进行，不进行中间的工作量（规模）估计
优点：
有利于开发者对进度的关注
有利于开发者在接受承诺之后的士气高昂
缺点：
容易产生大的估算误差

2.5 Jones的一阶估算准则

基于估算项目功能点
从幂次表中选择合适的幂次将功能点升幂

三、进度计划编排

进度计划编制时决定项目开始和结束日期的活动
主要目的：控制和节约项目的时间，保证项目在规定的时间内能够完成
最终目标：建立一个现实的项目进度计划，为监控项目的进度进展情况提供一个基础
项目进度计划过程反复多次，最后才能确定项目进度计划
基本方法：
关键路径法 正推法/逆推法
时间压缩法 应急法/平行作业法
资源平衡
管理预留
敏捷计划

3.1 关键路径法

根据指定的网络图逻辑关系进行的单一的历时估算
计算每个活动单一的、确定的最早和最晚开始和完成日期；计算网络图中的最长路径，从而确定项目完成时间的估计
关键路径是网络图中最长的路径
术语：
最早开始时间(Early Start, ES) 表示一项任务（活动）的最早可以开始执行的时间
最晚开始时间(Late Start, LS) 表示一项任务（活动）的最晚可以开始执行的时间
最早完成时间(Early Finish, EF) 表示一项任务（活动）的最早可以完成的时间
最晚完成时间(Late Finish, LF) 表示一项任务（活动）的最晚可以完成的时间
超前(Lead) 表示两个任务的逻辑关系所允许的提前后置任务的时间
滞后(Lag) 表示两个任务的逻辑关系所允许的推迟后置任务的时间
浮动(Float) 表示一个任务的机动性，是其在不影响项目完成的情况下可以推迟的时间量
自由浮动(Free Float, FF) 在不影响后置任务最早开始时间，本任务可以延迟的时间
总浮动(Total Float, TF) 表示在不影响项目最早完成时间，本任务可以延迟的时间

关键路径 (Critical Path)
·时间浮动为0（Float=0）的路径 TF=LS-ES / TF=LF-EF
·网络图中最长的路径
·关键路径是决定项目完成的最短时间
·关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟
·关键路径可能不止一条
正推法：按照时间顺序计算各个任务（活动）的最早开始时间和最早完成时间的方法

逆推法：按照时间顺序计算各个任务（活动）的最晚开始时间和最晚完成时间的方法

优点：

1. 利用网络图模型，明确表达各项工作的逻辑关系。按照网络计划方法，在制订工程计划时，首先必须清楚该项目内的全部工作和它们之间的相互关系，然后才能绘制网络图模型。
   2)通过网络图时间参数计算，确定关键工作和关键线路。
2. 掌握机动时间，进行资源合理分配。
3. 运用计算机辅助手段，方便网络计划的调整与控制
   缺点：
   是理论上计算所有活动各自的最早和最晚开始日期和结束日期，但计算时没有考虑资源限制，这样算出的并不是实际进度，而是表示所需的时间长短

3.2 时间压缩法

是在不改变项目范围的前提下缩短项目工期的方法，是一种数学分析方法

1、应急法
不改变任务之间的逻辑
（1）时间成本平衡方法是一种线性关系方法，进度压缩与成本的增长是成比例的
假设：
每个任务存在一个正常进度和可压缩进度、一个正常成本和可压缩成本。
通过增加资源，每个任务的历时可以从正常进度压缩到可压缩进度。
每个任务无法在低于可压缩进度内完成。
有足够需要的资源可以利用。
在“正常”与“可压缩”之间，进度压缩与成本的增长是成正比的。

线性关系，所以可以通过计算任务的单位进度压缩的成本来计算在压缩范围之内的进度压缩产生的压缩费用。
（2）压缩进度因子方法

2、平行作业法
又称快速跟进法，改变活动之间的逻辑关系，并行开展活动，增加返工并且增加风险

应急法不改变活动间的逻辑关系。
平行作业法则可改变活动间的逻辑关系，并行开展某些活动。
平行作业法常导致返工和增加风险。

3.3 资源平衡法

将资源与任务联系起来。每项任务需要的资源包括人力资源、设备资源等
目的：形成平稳连续的资源需求，最有效的利用资源，柿子园限制的时间最小化，同时尽量避免超出资源能力

3.4 管理预留

管理预留是一项加在项目末端的人为任务，不是加在每一个任务间隔上，而是给项目增加一个储备时间。是将每一项任务的预留时间累加在一起放在关键路径末端，而不要增加每一项任务时间

3.5 敏捷计划

Scrum模型是迭代式增量软件开发过程，通常用于敏捷软件开发
两层计划——远粗近细，渐进明细的特点
·产品待办事项
产品待办事项列表存在于产品的整个生命周期，它是产品的路线图。
任何时候，产品待办事项列表都是团队依照优先排列顺序完成工作的唯一、最
终的概括。
一个产品只有一个产品待 办事项列表，这意味着产品负责人必须纵观全局做出
优先级排列的决策，以体现利益相关人（包括团队）的意愿。
·Sprint待办事项
设定了 Sprint目标并挑选出这个Sprint要完成的产品待办列表项之后，开发团
队将决定如何在Sprint中把这些功能构建成“完成”的产品增量。
这个Sprint中所选出的产品待办列表项以及交付它们的计划统称为Sprint待办
事项列表。
敏捷开发把软件设计分成3个部分：特性、用例、任务：
特性：对最终用户有意义的一个功能，在每一个发布过程中， 我们完成需求特性。
用例：由特性分解而来的一个可以用来做功能测试的小情节，在每一个迭代周期中，我们实现用例。
任务：由用例分解而来，开发人员需要完成的一个最小的工作单元，每一天，我们都要完成多个任务

四、项目进度问题（SPSP）模型

软件项目进度问题（Software Project Scheduling Problem，SPSP）模型是在给定的项目任务工作量及其关系和资源限制下，对项目确定合适的人员安排，以保证项目的时间最短、成本最小。
最主要的资源是人力资源。人员需要具备项目需要的相应技能。

4.1 项目需要的技能

人员技能(skills of employees)是完成项目需要的能力，项目人员需要具备这些技能。

4.2 项目中的任务

任务是完成软件项目需要的所有活动，如分析、设计、编码、测试、写文档等活动。

4.3 项目中的人员

软件项目中的人员是软件工程师，他们具备的技能是软件工程技能

4.4 SPSP模型解决方案

针对现有的项目任务、项目需要的技能、想爱你有的人员、每个人员具备的技能、每个人员的成本，做到最合适的人员任务安排，以求达到项目进度最短、总成本最小

第八章质量计划

一、软件质量基本概念

1、质量定义

质量：质量是产品或服务满足明确和隐含需要能力的性能特性的总体
软件质量：与软件产品满足规定和隐含的需求能力有关的特性或特性的全体
软件质量是软件满足明确说明或者隐含的需求的程度
质量形成于产品或服务的开发过程中，而不是事后的检查（测试）把关等

在项目管理中，质量管理的既定方向就是通过项目范围界定管理体制，将暗示的需求变为明示的需求。

2、质量与等级

等级：是对具有相同功能的实体按照不同技术特征进行分类或者分级
质量：无论产品釆用任何等级标准，它都应该具备能满足相应功能要求的各种特征, 这些特征的总和就是质量
低等级不代表低质量

3、软件质量模型

Boehm质量模型
McCall质量模型
ISO/IEC 9216质量模型
ISO/IEC 25010 质量模型

1.1Boehm模型

一种由纵向软件特征构成的层次模型
包括McCall模型没有的硬件领域的质量要素

1.2McCall质量模型

与Boehm模型唯一的差别在于特征的种类
McCall模型的最大贡献在于，它建立了软件质量特征和软件度量项之间的关系

1.3ISO/IEC9126模型

“质量特征—质量子特征—度量因子”三层结构模型

二、软件质量管理过程

质量管理：保证项目满足其目标要求所需要的过程，监控项目的交付物和执行过程
关键：预防重于检查，实现计划好质量而非事后检查
对象：过程（的质量）、产品（的质量）
目的：确保项目工期，实现系统功能，达到系统的性能指标以及系统运行的可靠性，规定质量保证措施，资源及活动具有的顺序，确保产品的实现过程受控有效，完成的项目满满足用户的要求

2.1 软件质量计划

确定项目应达到的质量标准(目标)，以及决定如何满足质量标准的计划安排和方法
首先确定项目质量目标，根据wbs将目标分解到工作包，并按职责分工将工作包的质量目标落实到每个小组成员
对于一个项目，可建立项目的质量模型，以此确定项目的质量目标，或质量标准

2.2 质量保证QA

验证开发过程中是否遵循了合适的过程和标准
贯穿于整个项目的始终
要点：
对项目进行评价、推测能否达到质量指标、建立对项目的信心
质量保证的主要方法 - 质量审计
审计(Audit) 是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较，目的是确保真正的遵循了这一个过程，产生合适的文档和精确反映实际项目的报告
项目审计可以事先规划，也可以是临时决定的
·项目产品审计:根据质量保证计划对项目过程中的工作产品进行质量审计
·项目执行过程审计:对执行过程进行检查, 目的是确定所得到的经验教训, 从而提高组织对这个项目或其他项目的执行水平

2.3 质量控制QC

确定项目结果与质量标准是否相符，同时确定不符的原因和消除方法，控制产品的质量，及时纠正缺陷的过程
软件质量控制主要是发现和消除软件产品的缺陷
要点：
检查工作结果、按照标准跟踪检查、确定错误消灭质量问题
方法：
技术评审、走查、测试、返工

2.4 质量保证与质量控制

质量保证：
·是审计产品和过程的质量，保证过程被正确执行，确认项目按照要求进行
·质量保证人员，管理职能
·“Is it done right?” （完成的是否正确?）这个任务本身并不直接提高本版本产品的质量
质量控制：
·检验产品的质量，保证产品符合客户的需求，是产品质量检查者
·开发人员，检查职能
·“Is it right done?”（是否正确完成?）可直接提高产品的质量

三、软件质量计划

质量是在开发过程中形成的，高质量的开发才能产生高质量的软件产品。预防胜于检验。

3.1 质量成本

质量成本是由于产品的第一次工作不正常而衍生的附加花费，包括两部分
·预防成本，为了确保质量而进行的预防工作的消耗
评估费用：使项目符合所提要求（第一次）检测缺陷所衍生成本，如质量审计，测试等
预防费用：使项目符合所提要求预防失败所衍生成本，如用户满意确定，过程评审，改进等
·缺陷成本，为了确保质量而修复缺陷所消耗的成本
内部费用：对于不能符合所提要求，尚未发行的软件（返工）所衍生的费用，如返工，重新测试
外部费用：对于已经发布但是不符合要求的软件所衍生的费用，如技术支持，修正，索赔等
预防重于事后检查，预防成本应该大于缺陷成本
·质量成本还包括：项目返工的管理时间，丧失的信誉，商机和客户好感等

3.2 质量计划的方法

1、试验设计
统计学方法，确定哪些因素可能会对特定变量产生影响
2、基准对照
寻找最佳实践的方法，用其他项目的实施情况作为当前项目性能衡量的标准
3、质量成本分析
当不合格项需要返工、需要浪费资源时，这个成本是最明显的。所以，质量计划必须进行质量成本的综合分析，以便决定质量活动
4、流程图法
可以显示系统的各种成分之间的相互关系
5、因果分析图
对于复杂的项目，编制质量计划时可以采用

3.3 质量计划的编写

质量计划目的：规划出哪些是需要被跟踪的质量工作，并建立文档
质量计划应满足要求：
·应达到的质量目标和所有特性的要求
·确定质量活动和质量控制程序
·确定项目不同阶段的职责，权限，交流方式以及资源分配
·确定采用的控制手段，合适的验证手段和方法
·确定和准备质量记录

四、软件质量改善的建议

为了更好地进行软件质量的改善，有如下的建议：
·不但要主观认识到质量的重要性，而且要落实到行动中。把想法落实到实际工作中是做好软件质量管理的第一原则。
·软件质量活动必须经过规划，必须明文规定。
·树立提高质量就是尊重客户的思想。
·质量活动必须尽早开始。
·质量小组尽可能独立存在。
·质量小组的人应该经过必要的培训。