软件项目管理大作业在线书店管理程序

目录 第一部分 合同管理 4 1.1需方合同环境 4 1.1.1 合同准备 4 1.1.2 合同签署 4 1.1.3 合同管理 4 1.1.4 合同终止过程 5 1.2供方合同环境 5 1.2.1合同准备 5 1.2.2合同签署 5 1.2.3合同管理 5 1.2.4合同终止过程 5 1.3内部环境 .............................................................................................................................6 1.4合同 6 第二部分 生存期 7 第三部分 需求管理 8 3.1软件需求管理过程 8 3.1.1 需求规格 9 3.1.2需求管理图 9 3.1.3需求变更管理 10 第四部分 任务分解 10 4.1任务清单 10 4.1.1功能分解清单 10 4.2 WBS 12 第五部分 项目估算 10 5.1成本估算 14 5.1.1直接成本估算 14 5.1.2间接成本估算 14 5.1.3估算的误差 15 第六部分 项目进度 15 6.2活动排序 16 6.3活动时间估计 17 6.4项目进度安排 17 6.5工具使用 19 第七部分 质量计划 19 7.1质量计划编制 19 7.2质量保证活动 20 7.3产品审计 20 7.4过程评审 21 7.5测试计划 21 第八部分 配置计划 21 8.1配置管理人员组成 21 8.2配置控制 22 8.3配置审核和审计 22 第九部分 风险计划 22 9.1风险识别,评估与风险规划 22 9.2风险分析表 23 9.3风险应对措施 24 第十部分 团队管理 25 10.1软件团队管理概述 25 10.2IT软件项目管理团队 26 10.3沟通时间安排 26 第十一部分 项目度量 27 11.1度量指标 27 11.2数据收集 28 第十二部分 集成项目 28 12.1项目集成计划 28 12.1.1项目概述 29 12.1.2项目任务范围 29 12.1.3项目目标 29 第十三部分 跟踪控制 29 13.1项目分析 29 13.2阶段评审报告模板 29 第十四部分 项目结束 31 14.1项目终止 31 14.1.1项目终止的条件 31 14.1.2成功与失败的标准 31 14.2收尾工作 31 14.3最后评审 31 14.4项目总结 32 第一部分 合同管理 1.1需方合同环境 1.1.1 合同准备 蓝鲸书店信息有关重要文件 需要提供书店的基本重要信息，比如书店管理人信息，投资人信息，法人代表信息，工作人员信息，书店所属土地信息，书店地址，书店存书所有信息，进货信息等基本信息。

·供方选择 供方根据项目此项目整理的工作人员名单、最终供方确定的程序、确定最终的供方名单及其提供的建议书。

·合同文本准备 蓝鲸书店根据资料进行合同草案指定、草案评审、修订等程序，最终确定合同草案（合同草案略）。

1.1.2 合同签署 蓝鲸书店与IT项目团队以蓝鲸书店提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给IT项目团队的管理人及其各部门工作人员。

1.1.3 合同管理 ·验收过程 蓝鲸书店依据合同准备和合同签署时确定的需求资料及合同文本制定验收清单。对验收清单评审后制定验收计划，并按验收计划执行，得到验收报告。对发现的问题制定验收问题处理计划，最终确认验收报告。

·违约事件处理过程 在合同执行期内，如果合同双方蓝鲸书店或IT项目管理团队有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约事件处理报告。

1.1.4 合同终止过程 蓝鲸书店与IT项目团队根据合同及相关文档，发布合同终止通知、项目执行总结。

1.2供方合同环境 1.2.1合同准备 ·项目分析 IT项目管理团队根据合同安排项目分析任务。经过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实施规划、初步实施规划评审，最终得到需求分析报告和项目初步规划。

·合同文本准备 IT项目管理团队根据蓝鲸书点提出的资料制定合同草案。在经评审和修订后确定己方的合同草案。

1.2.2合同签署 同需方，此处略。

1.2.3合同管理 ·合同执行跟踪管理过程 IT项目管理团队以项目计划为基础，进行项目计划审批和合同执行管理规划。按计划完成项目进展报告、合同责任落实、需求变更处理和产品验收。

·合同修改控制 如果需方即蓝鲸书店提出变更请求，假设提出的是要求添加不用登录网页直接通过“在线书店”应用程序即可向网内用户发送邮件，并根据不同层级用户的权限显示网内在线用户。则IT项目管理团队需依据合同和变更请求进行变更评估，并提出合同修改建议，确定修改策略。对当前计划进行调整，并需得出处理报告。

·违约事件处理过程 同需方，此处略。

·产品提交过程 在产品的开发测试结束后向蓝鲸书店提交产品，经过审查后正式提交给蓝鲸书店。最终相方签字认可，通知相关各方。

·产品维护过程 根据合同中的维护需求，制定维护需求记录。

1.2.4合同终止过程 同需方，此处略。

1.3内部环境 IT项目管理团队内部确定任务范围，使相关各方有效的配合。详细任务分解在第四部分任务分解中会有详细阐述。

1.4合同 ·合同双方 甲方：蓝鲸书店 乙方：IT项目管理团队 ·协议形式 协议形式：技术合同 ·供应的商品和服务 供应的软件：乙方为甲方提供所需的“在线书店”应用程序 提供的服务：乙方为甲方提供所需的日常维护和服务器管理。同时对甲方用户提供使用教学。

提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。

安装服务：
乙方为甲方提供软件的安装。

公文处理：
乙方负责将甲方提供的公文资料加载入系统并进行分类 维护协议：
当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。

·软件所有权 该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。

·环境 乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。

·客户承诺 乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员主要参与项目的规划设计和需求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。

·验收规程 2016年6月15日，乙方为甲方安装所需套数的软件。6月15日至6月31日甲方代表对产品进行验收测试，并根据需求在6月30日前对产品提出更正请求。测试通过后，双方进行软件交付签字。乙方对甲方进行软件使用培训。

·标准 乙方在开发过程中必须遵守ISO 12207关于软件生命周期和文档的标准。

·项目和质量管理 甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的展示和下一阶段的工作安排和计划。甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。

·时间表 详细时间表见项目进度。此处略。

·价格和付款方式 软件总价为200 万元。合同签订后，甲方向乙方支付50万元定金。项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付80万元。该系统完成后，甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。

·其他法律要求 由任何一方的过失导致出现损失后的赔偿由双方协商决定。

甲方法人代表：SSS 乙方法人代表：XXX 第二部分 生存期 确定该项目的生存期模型按如下步骤进行分析：评审、分析项目的特性；
选择适合项目的生存期模型；
标识生存期模型与项目不一致地方,并进行裁减。

“在线书店”应用程序涉及到用户的使用感受，需保障产品能保持稳定运行，不会因为一定数量的用户共同使用等操作时挂机，以致用户的浏览保存记录丢失和降低用户使用感。总而言之该项目可操作性和界面美观度为主。

项目生存期模型如下：
该生存期模型将V模型除最后的项目规划和验收测试以外的过程做一复制，套用增量模型在首先完成基本功能的基础上增加功能。

第三部分 需求管理 3.1 软件需求管理过程 蓝鲸书店提出需求如下：
设计开发、安装调试并后期维护满足需求的“在线书店”应用程序。需要该程序有前台程序，进入程序后需要弹出书单界面，也需要有后台程序，方便管理。

主要有前台（客户购买）和后台（管理员管理）2个主要功能，每个功能需在办公界面中有独立的快捷方式。每个功能的具体要求如下：
（1）前台（客户购买）部分：
1.用户管理：注册会员、登录、激活、退出、修改密码；

2.分类显示：显示所有1级和2级分类；

3.图书显示：按分类查询图书、通过关键字搜索图书、高级搜索图书、查看某本图书的详细等；

4.购物车管理：向购物车中添加图书、修改购物车中图书数量、删除除购车中图书、我的购物车；

5.订单管理：通过购物车中图书生成订单、查看我的订单、查看某个订单的详细、订单支付、确认收货、取消未付款订单。

（2）后台（管理员管理）部分：
1.管理员：管理员登录；

2.分类管理：查看所有分类、添加1级分类、添加2级分类、修改1级分类、 修改2级分类、删除1级分类、删除2级分类；

3.图书管理：按分类搜索图书、高级搜索图书、添加新图书、查看图书详细信息、编辑图书、删除图书；

4.订单管理：按状态搜索订单、查看订单详细信息、取消订单、发货；

3.1.1 需求规格 ·需求规格说明书（简略版）
系统定义：“在线书店”应用程序 应用环境：
Windows2000；
Windows XP；
Windows Vista；
Windows 7；
LINUX；
IOS etc. 功能规格：前台（客户购买）、后台（管理员管理）
性能需求：
保证所有人员同时登录服务器时也不会因处理的信息量过大而导致系统瘫痪。另必须保证系统的安全性，对账户有足够的保护措施以防账户被盗。操作简单明了，提示明显，容易上手，界面整洁大方。

产品提交：略 实现约束：用户管理、分类显示、图书显示、购物车管理、订单管理、管理 员、分类管理、图书管理、订单管理 质量描述：
如需求所述的足够用户承载量；
可靠的系统安全性；
操作简单易学。界面整洁大方 其他：略 签字认证：甲方（需方）：蓝鲸书店 乙方（供方）：IT项目管理团队 3.1.2需求管理图 需求管理包含5个特定实践，如图1所示。

①获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。

②获取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。

③管理需求变更。维护变更历史，为调整与控制提供数据。

④在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。

⑤标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性，即启动纠正措施。

3.1.3需求变更管理 ·需求变更 假设蓝鲸书店向IT项目管理团队提出如下需求变更：
在办公界面做一个可收缩的列表，显示当前系统在线的工作人员，。

·软件基线产品修改提交单 申请人：XXX 申请日期：2016年7月6日 项目名称：“在线书店”应用程序 阶段名称：—— 文件名称：—— 修改内容：增加功能“可收缩的在线工作人员显示列表” 验证意见：同意变更，邮箱功能随之变更 验证人：YYY 验证日期：2016年9月8日 SCCB：SSS、CCC、BBB 填表人：ZZZ 第四部分 任务分解 4.1 任务清单 4.1.1 功能分解清单 1．“在线书店”应用程序 1.1用户管理 1.1.1 注册会员 1.1.2 登录 1.1.3 激活 1.1.4 退出 1.1.5 修改密码 1.1.6 单元测试 1.2 分类显示 1.2.1 显示一级分类 1.2.2 显示二级分类 1.2.3 界面 1.2.4 单元测试 1.3 图书显示 1.3.1 按分类查询图书 1.3.2 通过关键字搜索图书 1.3.3 高级搜索图书 1.3.4 查看某本图书的详细 1.3.5 单元测试 1.4 购物车管理 1.4.1向购物车中添加图书 1.4.2修改购物车中图书数量 1.4.3删除购物车中图书 1.4.4我的购物车 1.4.5单元测试 1.5订单管理 1.5.1通过购物车中图书生成订单 1.5.2查看我的订单 1.5.3查看某个订单的详细 1.5.4订单支付 1.5.5确认收货 1.5.6取消未付款订单 1.5.7单元测试 1.6 管理员 1.6.1管理员登录 1.7分类管理 1.7.1查看所有分类 1.7.2添加1级分类 1.7.3添加2级分类 1.7.4修改1级分类 1.7.5修改2级分类 1.7.6删除1级分类 1.7.7删除2级分类 1.77.8单元测试 1.8图书管理 1.8.1按分类搜索图书 1.8.2高级搜索图书 1.8.3添加新图书 1.8.4查看图书详细信息 1.8.5编辑图书 1.8.6删除图书 1.8.7单元测试 1.9订单管理 1.9.1按状态搜索订单 1.9.2查看订单详细信息 1.9.3取消订单 1.9.4发货 4.2 WBS (1) WBS的定义
WBS（工作分解结构）是Work Breakdown Structure的英文缩写，是项目管理重要的专业术语之一。WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。

(2)WBS字典 　 管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；
工作成果的描述和相应规范标准；
元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与者（如承包商）接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。

(3)WBS的分层 WBS是进行计划，人员分配，预算计划的基础，没有WBS工作，后面的一切工作都没有依据。WBS的分层分解图如图2所示 (4)系统的WBS 前台：用户购书功能WBS图如图3所示 第五部分 项目估算 5.1成本估算 5.1 .1直接成本估算 项目开发工作量估算表 单位：人天 编号 任务名称 估计值 小计 前台设计：
53 1 用户管理模块 8 2 分类显示模块 10 3 图书查询模块 10 4 购物车管理模块 10 5 订单管理模块 15 后台管理：
52 6 分类显示模块 10 7 图书查询模块 24 8 订单管理模块 18 表1 从上图得知项目工作量是105/人天，假设开发人员开发成本参数=500/人天，则内部开发成本=500*105=52500元。管理和质量成本可以根据以往的经验，管理和质量成本约为开发成本的30%，即：52500*30%=15750元。则直接开发成本=开发成本+管理和质量成本=68250元。

5.1.2 间接成本估算 项目名称 在线书店管理系统 项目经理 梁某 估算小组成员 张三，李四，王五 估算阶段与日期 2014.6.10 工作分解结构 项目规模 系统模块 新代发模块的规模（代码行、类、文档页数）
复用或自动生成的组件（代码行、类、文档页数）规模 模块1 10 25 模块2 20 30 模块3 25 20 模块4 15 15 模块总和 70 90 工作量估计 项目研发工作量 估计项目研发的工作量=100 新开发组件的规模 难度系数 人均生产率 100 5 8 需求开发工作量 25 系统设计工作量 15 编程工作量 30 测试工作量 25 研发总工作量 95 项目管理工作量 估计项目管理的工作量=75 比例系数 0.75 项目规划工作量 16 项目监控工作量 22 需求管理工作量 21 管理工作量 14 项目支撑工作量 估计项目支撑的工作量=30 比例系数 0.25 配置管理工作量 5 质量保证工作量 5 外包与采购工作量 4 培训管理工作量 6 支撑总工作量 20 成本估计 类别 细分、说明 金额 人力资源成本 20000 50000 表2 5.1.3估算的误差 任务编号 里程碑 计划工作预算成本 已完成工作预算成本 实际成本 变量（%）
计划 成本 1 已完成 100 100 100 0 0 2 已完成 50 50 55 0 -10 3 已完成 50 50 40 0 20 4 未开工 70 0 0 -100 -- 5 已完成 90 90 140 0 -55.5 6 未开工 70 0 0 -100 -- 7 已完成 40 50 25 0 50 8 未开工 50 0 0 -- -- 总计 450 340 360 -24.4 -5.9 表3 EAC = （360/340）* 579000 = 613059（元）
超支 = 613059 - 579000 = 34059（元）
第六部分 项目进度 项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。是在规定的时间内，拟定出合理且经济的进度计划（包括多级管理的子计划），在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。

6.1定义活动 定义活动是一过程，它涉及确认和描述一些特定的活动，完成了这些活动意 味着完成了WBS结构中的项目细目和子细目。

通过定义活动体现项目工作内容的完成，定义活动的输入输出图如图5所示 6.2活动排序 活动排序过程包括确认且编制活动间的相关性。实际上，这是一个开发网络图的过程。网络图是一种示意图，描绘项目中各项活动以及它们的时序关系。活动必须被正确地加以排序以便今后制定实现的可行的进度计划，可用手工进行排序，大型项目也可以用专门的软件。排序还因为存在的特定的约束，包括：
1.技术需求和规范 2.安全性与效率 3.企业政策与偏好 4.资源可用性 活动排序过程包括编制活动间的三种相关性: 1.内在的相关性（强制依赖关系）
2.指定性的相关性（资源依赖关系）
3.与外部相关性（外部依赖关系）
活动间有四种相关依赖的关系：
结束—>开始：某活动必须结束，然后另一个活动才能开始。

结束—>结束：某活动结束前，另一活动必须结束。

开始—>开始：某活动必须在另一活动开始时开始。

开始—>结束：某活动结束前另一活动必须开始。

活动排序的结果（输出）是项目网络图。

项目网络图是项目所有活动以及它们之间逻辑关系（相关性）的一个图解表示， 6.3活动时间估计 活动时间估计指预计完成各活动所需时间长短，在项目团队中熟悉该活动特性的个人和小组可对活动所需时间做出估计。

活动时间估计的输入包括活动目录，结束和假设，还有：
1.资源需求 2.资源数量 活动所需时间估计的工具和方法：
1.专家判断 2.类推估计 6.4项目进度安排 工作集 子工作 完成时间 负责人 最终交付物 描述 项目计划 确定负责人 以及组长 第二周 小小 负责人以及 组长名单 完成在线书店管理系统开发团队的工作分配 确定小组 第三周 王二 小组成员名单 成立系统开发团队小组 搭建环境 第三周 各组组长 开发环境运行 说明文档 确定项目 开发的工具及语言 制定项目管理计划书 第四周 熊宝 《项目管理计划书初稿》
制定软件开发过程管理计划 初步完成需求规格说明书 采集用户需求 第五周 小小、熊宝 需求规格说明书 通过与用户沟通以及查阅相关资料了解和采集用户的需求。对需求进行汇总，制定需求规格说明初稿 分析用户需求及制定需求规格说明原型 第五周 需求规格说明的进一步完善与修改 第六周 需求规格说明的最后确认 第七周 系统设计 系统总体设计 第八周 张三 软件设计报告初稿 制定系统总体的设计方案，并根据需求说明联系实际进行相应的修改 系统详细设计 第九周 系统模型及架构最后确定 第十周 开发系统源代码及源码测试 系统源码开发 第十一周 李四 交付源代码 掌握开发工具的使用 系统源码测试 第十二周 王五 测试文档 根据测试要求严格测试 系统源码复查 第十三周 吴倩 无 对代码进行复查，尽量减少bug 进行整个在线书店滚轮系统的集成 进行整个网上教学系统的集成 第十四周 梁冰 无 与其他小组长无间协作 完成整个系统的集成 对整个集成后的系统进行测 试检查 运行情况 第十四周 张梦 无 配置好IIS服务，搭建整个系统的运行平台测试整个系统的发布情况 系统交付 系统交付 第十五周 张斌 系统能够运行以及 以及把相关技术文归类存档 各组之间可以交流各自的开发经验和心得体会 表4 6.5工具使用 Microsoft Project是国际上最为盛行与通用的项目管理软件，适用于新产品研发、IT、房地产、工程、大型活动等多种项目类型。经过微软多年研发，Project包含了经典的项目管理思想和技术以及全球众多企业的项目管理实践。在企业内部使用和推广Project，在提升项目管理人员能力的同时也实现了项目管理专业化与规范化的过程。

第七部分 质量计划 项目质量计划是指为确定项目应该达到的质量标准和如何达到这些项目质量标准而做的项目质量的计划与安排。项目质量计划是质量策划的结果之一。它规定与项目相关的质量标准，如何满足这些标准，由谁及何时应使用哪些程序和相关资源。

项目质量计划工作的成果：项目质量计划、项目质量工作说明、质量核检清单、可用于其它管理的信息。

7.1质量计划编制 编制项目的质量计划，首先必须确定项目的范围、中间产品和最终产品，然后明确关于中间产品和最终产品的有关规定、标准，确定可能影响产品质量的技术要点，并找出能够确保高效满足相关规定、标准的过程方法。编制质量计划通常采用流程图、因果分析图等方法对项目进行分析，确定需要监控的关键元素，设置合理的见证点（W点）、停工待检点（H点），并制定质量标准：
1.流程图：
显示系统的各种成分是如何相互关系的，帮助我们预测在何处可能发生各种质量问题，并由此帮助开发处理他们的办法。

2.因果分析图（也称鱼刺图）如图7所示：
人员 参考资料 设备 质量问题 环境 方法 对于本项目，编制质量计划时采用因果分析图，描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。其次，质量计划中还必须确定有效的质量管理体系，明确质量监理人员对项目质量负责和各级质量管理人员的权限。戴明环（又名PDCA循环法）作为有效的管理工具在质量管理中得到广泛的应用，它采用计划——执行——检查——措施的质量环，质量计划中必须将质量环上各环节明确落实到各责任单位，才能保证质量计划的有效实施。

7.2质量保证活动 质量保证的只要活动包括过程评审和产品审计，过程评审和产品审计的目的是确保在项目进展过程中的各个阶段和各个方面采取各项措施来保证和提高提交给用户的产品质量。

每一次过程评审和产品审计都应填写相应的报告或活动记录。

如下表9为质量计划标准 项目 具体描述 计划 实际 需求检查 5 2 系统总体设计检查 2 1 缺陷排除率（缺陷数/KLOC）
详细设计复核 32 27 详细设计检查 10 7 代码复核 61 56 代码检查 20 18 编译 21 15 单元测试 15 14 系统集成 5 4 系统测试 5 5 表5 7.3产品审计 产品审计由质量保证人员来进行，检查项目产品是否达到质量目标。

质量保证人员可以有选择性地审计项目生存期中创建工作产品，以验证是否符合适当的标准，是否进行了质量检查，质量审计一览表见表10所示 项 审计对象 审计阶段 参照的标准 1 软件项目计划 计划结束 企业质量体系 2 软件配置管理计划 计划结束 企业质量体系 3 软件质量保证计划 计划结束 企业质量体系和项目规划 4 总体设计文档 设计结束 企业质量体系和项目规划 5 详细设计文档 计划结束 企业质量体系和项目规划 6 数据库表和编码规范 计划结束 企业质量体系和项目规划 7 产品代码 每个阶段实施结束 企业质量体系和项目规划 8 测试报告 测试结束 企业质量体系和项目规划 9 系统计划 设计结束 企业质量体系和项目规划 10 用户文档 测试结束 企业质量体系和项目规划 表6 7.4过程评审 项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。

7.5测试计划 1.建立每个测试阶段的目标。

2.确定没项测试活动的进度和职责。

3.确定工具、设备和测试库的可用性。

4.建立用于计划和进行测试以及报告测试结果的规程和标准。

5.制定衡量测试成功与完成的准则。

第八部分 配置计划 项目质量计划是指为确定项目应该达到的质量标准和如何达到这些项目质量标准而做的项目质量的计划与安排。项目质量计划是质量策划的结果之一。它规定与项目相关的质量标准，如何满足这些标准，由谁及何时应使用哪些程序和相关资源。

项目质量计划工作的成果：项目质量计划、项目质量工作说明、质量核检清单、可用于其它管理的信息。

8.1配置管理人员组成 根据本项目计划的角色分配，可以确定配置管理人员，配置管理人员的角色和职责见表11：
角色 人员 职责、工作范围 配置管理者 张三 1.制定《配置管理计划》
2.创建和维护配置库 项目经理 李四 1.审批《配置管理计划》
2.审批重大的变更 项目组成员 项目经理：张晓 质量保证人员：王五 配置管理者：吴天 审批某些配置项或基线的变更 表7 8.2配置控制 配置控制活动请求、评估、认可或拒绝、实现对基线CI的配置变更。变更包括错误的改正和可靠性增强。为变更过程所需的必须手续的复杂程度依靠在配置结构中变更对基线的影响。

计划必须描述在基线CI的变更控制影响。计划必须定义下列的详细步骤：
1.变更所需的标识和文档；

2.变更需求的分析和评估；

3.需求的认可或否决；

4.变更的确认、执行和发布；

计划必须标识用来追踪和记录每个变更的执行序列的记录。在处理原始需求的变更的每个不同必须被明确的记录下来。

8.3配置审核和审计 配置审核决定事实上CI影响的所需的物理和功能的广度。配置审阅时建立基线的管理工具。计划必须为项目标识配置审核和审计。至少，一个配置审核必须在CI发布前审核。

对每个计划的配置审核和审计，计划必须定义以下方面：
1.它的目标；

2.处于审核和评审CI；

3.审核和评审任务的时间表；

4.实施审核和评审的过程；

5.工作标题的参与者；

6.为回顾或支持审核和评审需要用到的文件；

7.记录不足和报告纠正行动的过程；

8.对认可之外的认可标准和特定行动。

第九部分 风险计划 项目风险管理是指通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法技术和手段，对项目的风险实行有效的控制，妥善的处理风险事件造成的不利后果，以最少的成本保证项目总体目标实现的管理工作。

9.1风险识别,评估与风险规划 （1）风险识别 风险识别是理解某特定项目有哪些可能令人满意的结果的过程。就是采用系统化的方 法，识别某特定项目已知的和可预测的风险。

（2）风险评估 风险评估是指，在风险事件发生之前或之后（但还没有结束），该事件给人们的生活、生命、财产等各个方面造成的影响和损失的可能性进行量化评估的工作。即，风险评估就是量化测评某一事件或事物带来的影响或损失的可能程度。

（3）风险规划 针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件。通常采取的措施有：
回避风险。

转移风险。

3.损失控制。

4.自留风险。

9.2风险分析表 根据风险识别，风险评估，风险规划可以制定了如下风险分析表 排序 输入 风险事件 可能性 影响 风险值 风险应对措施 1 最终用户抵制该系统 投资方可能会由于某个细节的问题对整个系统产生反感。

80% 70% 40% 1.尽力满足用户提出的需求。

2.界面尽可能的美观，方便。

3.需求分析阶段派出专门的系统分析员去了解用户的性格，爱好，工作习惯。

2 项目期间，投资方举棋不定 网上购物系统众多，投资方浏览后可能会经常要求更改需求 60% 70% 40% 1.软件详细设计阶段注意增加软件的可重用性。提高复用水平。

2.沟通和协调。

3 客户的需求规格说明 需求不明确，增加需求，导致需求蔓延，由于本软件是不太了解计算机的用户使用，变更需求可能性很大。

70% 50% 35% 1.采取加班的方法。

2.修改计划去掉一些任务。

3.与客户商量延长一些时间。

4.当出现影响重大的变更需求时与客户协调，这个版本的不做改动，在下一个版本中进行功能的提升。

4 合同带来的限制 进度要求紧，合同金额有限。

  30% 50% 15% 可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度。

5 交付期限紧缩。

需方存在紧缩交付期限的可能。导致项目吃紧。

20% 60% 10% 1.加班。

2.临时雇佣员工。

3.调整结构。

6 历史项目信息。

开发人员的流动。

15% 60% 9% 1.注意项目团队的沟通，及时了解开发人员的动态。

2.控制好项目过程中的文档。

3.从其他的项目组借调人员。

4.从外部招聘有过此类开发经验员。

  7 人员缺乏经验。

由于本项目中的一些员工是刚刚招聘来的，可能会缺乏经验。

15% 30% 10% 1.采取一帮一，让有经验的程序员带着相对经验少的程序员进行开发。

2.开发之前适当的培训。

8 用户数量超出计划。

由于该网站可能销售商品特别，导致访问激增。

20% 20% 20% 1.防患于未然，数据库上采用数据池的技术在，增加并发访问量。

9 技术达不到预期效果。

可能有一些技术达不到预期的效果，不能使需方满意。如访问速度，一些特效等等。

10% 10% 10% 1.找懂得这种技术的人帮忙。

2.向老师请教。

表8 9.3风险应对措施 （1）风险规避 风险规避是改变项目计划来消除特定风险事件的威胁。通常情况下我们可以采用多种方法来规避风险。例如，对于软件项目开发过程中存在的技术风险，我们可以采用成熟的技术，团队成员熟悉的技术或迭代式的开发过程等方法来规避风险;对于项目管理风险我们可以采用成熟的项目管理方法和策略来规避不成熟的项目管理带来的风险;对于进度风险我们可以采用增量式的开发来规避项目或产品延迟上市的风险。对于软件项目需求不确定的风险我们可以采用的原型法来规避风险。

（2）风险转移 风险转移是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。可以采用外包的形式来转移软件开发的风险，例如发包方面对一个完全陌生领域的项目可以采用外包来完成，发包方必须有明确的合同约定来保证承包方对软件的质量，进度以及维护的保证。否则风险转移很难取得成功。

（3）风险减轻 风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。例如，软件开发过程中人员流失对于软件项目的影响非常严重，我们可以通过完善工件，配备后备人员等方法来减轻人员流失带来的影响。

（4）风险接受 准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。

对于不可预见的风险，例如不可抗力;或者在风险规避，风险转移或者风险减轻不可行，或者上述活动执行成本超过接受风险的情况下采用。

第十部分 团队管理 项目团队是软件项目项目中最重要的因素，成功的团队管理是软件项目顺利实施的保证。

10.1软件团队管理概述 软件项目团队管理工作结构如图8所示 软件项目团队管理 团队人员获取 输入：
1. 人员配置管理计划 2. 人员库说明 3. 招募规则 工具和技术：
1.谈判 2.预分配 3.采购 输出：
1.已分配的项目人员 2.项目团队名录 团队建设 输入：
1. 项目人员 2. 项目计划 3.人员配置管理计划 4.执行情况报告 5.外部反馈 措施：
1.团队建设活动 2.一般管理技能 3.奖励和承认系统 4.集中 5.培训 输出：
1.团队效能改进 2.绩效评估输入 团队组织计划 输入：
1. 组织界面 2. 人员配置要求 3. 制约 方法和技术：
1. 样板 2. 人力资源惯例 3. 组织理论 4. 项目干系人分析 输出：
1. 组织结构图 2. 角色和职责分配 3. 人员配备管理计划 4. 支持细节 图8 10.2IT软件项目管理团队 1.IT软件管理团队是通过将不同的个体组织在一起，形成一个具有团队精神的高效率队伍来进行软件项目的开发。

2.软件项目包括所有的项目干系人。

项目干系人是指参与项目和受项目活动影响的人，包括：
.项目发起人 .资助者 .供应商 .项目组成员 .协助人员 .客户 .使用者 .项目的反对人 10.3沟通时间安排 1. 小组交流 （1）每周例会 每周例会时间由小组负责人自己拟定，因为要满足各成员在场，所以时间弹性比较大，但确定每周例会时必须的。

（2）每天交流 项目小组成员之间要每天进行交流，使用电话、QQ等进行讨论有问题及时解决。

2. 团队交流 （1）每两周例会（时间固定）
每两周四下午14：30到17：30进行整个团队的项目交流。

（2）每天交流 每天项目组成人员用电话或者QQ来进行讨论，了解项目的进度，交流所遇到的困难并及时解决。

第十一部分 项目度量 软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等。度量取向要依靠事实、数据、原理、法则；
其方法是测试、审核、调查；
其工具是统计、图表、数字、模型；
其标准是量化的指标。

11.1度量指标 度量指标如表9所示 度量指标 分析方法 决策准则 里程碑进度偏差 1.统计项目各个里程碑进度偏差值，画出对应的控制图 如果里程碑进度相对偏差超出+/-5%，则项目经理需要调查原因并采取措施。如果里程碑进度相对偏差超出+/-15%，进行正式的计划变更 项目生产率 1.统计项目的总工作量和产品实际规模 2.计算出项目生产率 若项目生产率高于或者低于公司平均生产率10%，则要求评价项目，检查项目的实际过程是否与组织的标准过程符合 项目软件开发 生产率 1.统计各项目每周的软件开发生产率画出趋势图 如果该生产率低于或高于公司平均水平10%时，需分析原因，采取相关措施调整 项目按时完成率 项目按时完成率的控制图 对项目按时完成比率低于90%的时候，分析其原因，并制定整改措施。相对偏差低于等于10%为按时完成，反之为未按时完成。

软件产品的遗留 缺陷密度 1.统计软件产品遗留缺陷和产品实际规模，使用柱状图表示软件产品遗留缺陷密度 软件产品的遗留缺陷密度如果高于1，则必须调查其根本原因 顾客满意度 1.根据顾客满意度的分数，可以将产品或者服务的满意度分为：不满意、非常不满意、非常满意、较满意、满意，而后用柱形图表示满意度的情况 顾客满意度低于85，则必须调查其根本原因。

需求稳定度 参见《度量构造指南》
需求稳定度低于90%，则必须调查其根本原因 任务工作量分布 1.统计各类型任务工作量之和并使用饼图显示各类型任务工作量分布情况 如果各类型任务工作量所占项目总工作量的比例比公司度量库中值偏差10%，则必须调查其根本原因。

阶段工作量分布 1.统计各阶段任务工作量之和并使用饼图显示各阶段任务工作量分布情况 如果各阶段任务工作量所占项目总工作量的比例比公司度量库中值偏差10%，则必须调查其根本原因。

表 9 11.2 数据收集 数据的收集如表10：
目 标 度量 指标 数据定义 责任 提高项目化产率 功能点／l时 项目实施过程中计 算出功能点数。

功能点负责人用电子 表格记录数据。

项目开发周期内记 录工作时间量。

开发人员随时 记录数据。

提高顶目质量 缺陷 功能点 项目实施过程中计 算出功能点数。

功能点负责人用电子 表格记录数据。

计算用户使用三个 月后的缺陷数。

服务台的人员在接到 用户的报告后采用缺陷 跟踪系统记录数据。

降低项目成本 成本 功能点 项目实施过程中计 算出功能点数。

功能点负责人用电子 表格记录数据。

按工作量计算出劳动成本。

项目经理在项目进行过程中记录并计算。

项目周期内记录非芳动成本。

第十二部分 集成项目 项目集成管理是为了实现项目目标，确保项目范围内的各项工作能够顺利协调地配合进行，消除项目管理中的局部性，平衡项目各个目标之间的冲突，保证项目过程各阶段的正确实施，所开展的以整体思想为指导，从全局出发，以项目总体利益最大化为目标，以统一协调各方面管理为内容进行的全面管理的过程。它具有综合性、全局性和内外兼顾性的特征。集成项目计划的完成是项目经理完成项目计划的标志。项目集成管理包括对计划的集成管理和对项目跟踪控制的集成管理，它保证项目各要素相互协调，在相互影响的项目目标和方案中做出权衡，以满足或者超出项目干系人的需求和期望。

12.1项目集成计划 12.1.1项目概述 网上购书的优势在于选择面大、价格便宜、交易方便、节省时间和精力等。整个图书市场一片繁荣，在这种情况下，网上书店的加入无疑将使得竞争更加激烈，但从另一个方面看，只有在这种激烈的竞争下，网上书店的优势才能得以体现。在中国，网上书店有发展的必要，也有发展的基础，发展网上书店的各方面条件也日趋成熟，但是还存在一些问题，只有把问题解决好了，才能保证网上书店的蓬勃发展。网上在线书店是以当前商务的网络化、快速化实际需求为背景，实现图书购买的方便、快捷、送货上门等服务为前提综合信息服务系统的设计；
实现通过Internet互联网对图书购买的相关信息进行发布及图书查询、图书介绍、图书内容浏览等功能。消费者通过网络在线进行图书的网上购物和网上支付等活动，这样即方便了消费者，又减少了企业成本。倡导“用户是伙伴，多为用户着想”的新型客户服务理念。因此，在网络在线书店系统实现显示其它用户购买情况和浏览产品情况。这些新型客户服务，具有与众不同的优势和特点，将成为和用户沟通、联系、发展的有效的方法。

12.1.2项目任务范围 在线书店管理项目需要完成的任务主要包括会员注册、订单管理、购物车、搜索、支付等基本功能。此外，本系统也将实现在线图书销售系统的后端管理，包括图书的添加、订单的处理等功能。本系统完全基于JSP技术，在系统的设计与开发过程中严格遵守软件工程的规范，运用软件设计模式，从而减少系统模块间的偶合，力求做到系统的稳定性、可重用性和可扩充性。

12.1.3项目目标 本系统完全基于JSP技术，在系统的设计与开发过程中严格遵守软件工程的规范，运用软件设计模式，从而减少系统模块间的偶合，力求做到系统的稳定性、可重用性和可扩充性，与传统利用书店进行销售的方式相比拥有许多优势：一是降低了销售成本；
二是利用网络作为交易平台，改变传统的交易方式，使得交易活动不受空间和时间的限制；
三是信息的传递更迅速灵活，新书信息上传后，客户可以立即看到，交易马上可以从网上进行，从而大大提高了交易的效率。

第十三部分 跟踪控制 13.1项目分析 在线书店管理系统这个项目的负责人每天都需要审核项目的实际情况，对比项目的规模估算，项目进度，质量计划，配置计划，风险计划来判断实际项目是否得到了有效的完成。同时在上面说明的的每周五的团队沟通例会中进行进一步的审核与交流。每个基线结束后，进行阶段评审，给出阶段评审报告。该报告具对本项目的完成，和对未来项目的经验积累都有重大的意义。这个报告可以给需求方，使他们也能够了解项目的进度。

13.2阶段评审报告模板 本项目阶段评审报告表如表11所示 项目名称 政府公文审批及工作通告系统 项目标识 部门/组织名 阶段名称 总体设计 主持人 丁锋 会议地点 A401 评审时间 2014年10月24日 评审次数 2 评审人 张三，李四，王五 评审项与结论 评审要募 评审结果 问题和对策 详细设计实施结果 满足需求规格的要求 开发人员与用户一起评审，用户对本阶段的提交结果很满意。

计划执行 通过 基本按计划执行 质量情况 通过 满足质量计划的要求 配置管理 通过 开发人员对配置工具的使用技巧学习有待提高 其他问题 通过 开发人员增强政府工作业务学习，以便保证开发顺利进行。同时要进一步了解操作者的习惯 计划调整 完成 根据本阶段的计划执行情况调整下一阶段的计划 提交产品 R 项目计划 R 计划跟踪数据 R 源码 R 评审报告 阶段统计数字 数据项目 计划 实际 偏差 工期（日）
30 33 3 规模（人时）
720 792 +72 人力投入（M/D/QA/SCM）
l211 12l3 2 成本（元）
43000 42000 +5000 阶段日期 2016/6/3-2016/6/13 2013/6/3-2013/6/19 正常开始，延后6天结束 阶段评语 本阶段的成本和进度基本在控制的范围之内，而且进度略有延后。在完成本阶段目标的基础上，开发人员更加深入地熟悉技术和业务，为确定下阶段目标打下了一定的基础。从管理上，体现在生存期的定义、项目计划的细化和确认、项目跟踪日常化等方面。可以为今后类似项目的管理提供宝贵的经验。所以，本阶段除较好地完成了规定的目标之外，还进行了许多有益的尝试，本阶段结束后，项目进展及完成情况属正常 表11 第十四部分 项目结束 14.1项目终止 14.1.1项目终止的条件 当项目出现下列条件之一时可以终止项目：
1.项目计划中确定的可交付成果已经出现，项目的目标已经成功实现。

2.项目已经不具备实用价值。

3.由于各种原因导致项目无限期拖长。

4.项目出现了环境的变化，它负面影响项目的未来。

5.项目所有者的战略发生了变化，项目与项目所有者组织不再有战略的一致性。

6.项目已没有原来的优势，同其他更领先的项目竞争难以生存。

14.1.2成功与失败的标准 1.项目最后执行的结果只有两个状态：成功与失败 2.评定项目成功与失败的标准主要看三项：
3.可交付成果如何 4.是否实现目标 5.是否达到项目业主的期望 14.2收尾工作 1.范围确认：项目接收前，重新审核工作成果，检验项目的各项工作范围是否完成，或者完成到何种程度，最后，双方确认签字。

2.质量验收：质量验收是控制项目最终质量的重要手段，依据质量计划和相关的质量标准进行验收，不合格不予接收。

3.费用决算：费用决算是指对从项目开始到项目结束全过程所支付的全部费用进行核算，编制项目决算表的过程。

4.合同终结：整理并存档各种合同文件。

5.资料验收：检查项目过程中的所有文件是否齐全，然后进行归档。

14.3最后评审 在对许多网络在线书店做了详细的调查后，以及根据前期做的需求分析，基本可以准确的把握网络在线书店的需要，把握怎样才能满足在线书店的需求。通过可行性分析，了解到无论在技术，资金还是在安全管理上都能够顺利的对系统进行设计。  在具体的设计过程中，要严格按照详细调查的结果来设计系统。但是还要照顾特殊情况。对于具体的书店特设的需求，我们可以适当的考虑做一些改进。在业务流程图中，要依据网络在线书店的具体业务来往设计。保证业务的准确。需求分析是这个系统设计的关键。只有这一步做好了我们才可以放心地做以后的工作。  对于设计的这个在线书店管理系统，可以实现一些网络在线书店的基本功能，能够满足一般的在线书店管理需求。例如：前台（客户购买）部分：实现了以下功能：用户管理：注册会员、登录、激活、退出、修改密码；
分类显示：显示所有1级和2级分类；
图书显示：按分类查询图书、通过关键字搜索图书、高级搜索图书、查看某本图书的详细等；
购物车管理：向购物车中添加图书、修改购物车中图书数量、删除购物车中图书、我的购物车；
订单管理：通过购物车中图书生成订单、查看我的订单、查看某个订单的详细、订单支付、确认收货、取消未付款订单。后台（管理员管理）部分：实现了管理员：管理员登录；
分类管理：查看所有分类、添加1级分类、添加2级分类、修改1级分类、修改2级分类、删除1级分类、删除2级分类；
图书管理：按分类搜索图书、高级搜索图书、添加新图书、查看图书详细信息、编辑图书、删除图书；
订单管理：按状态搜索订单、查看订单详细信息、取消订单、发货；
对于这个在线书店系统，基本上可以满足用户操作需求。所以，这个系统应该算是成功的。

14.4项目总结 在本系统的开发过程中，由于是初次开发软件，在知识、经验方面都存在着不足。另外，在整个开发的过程中，时间也比较仓促。因此，该系统必然会存在一些缺陷和不足。也由于团队之间沟通相对较少，以及缺少与用户之间的沟通，导致在某些模块开发过程中有延期现象，所以对于整个项目的实施，我们应该增加一点执着个亲和力，更多的和其他组员沟通，这样才能更有效的完成整个项目。

最后，在对软件项目过程文件进行总结之后，应将项目中的有用信息进行总结分类，放入信息库。并且无论项目是成功还是失败，项目结束后可以根据项目的规模大小，适当地款待项目成员！比如可以设宴款待项目团队、给他们放假等。