网上购物系统软件项目管理大作业样本.doc

《网上购物系统》项目管理目录
1.合同 1
1.1合同双方 1
1.2供应商品和服务 1
1.3时间地点 1
1.4专利成果分派 1
1.5验收原则 1
1.6报酬计算 1
1.7违约解决 2
2. 生存期 2
3.需求管理 4
3.1 功能需求 4
3.2拟定用例 4
3.3用例文档 5
3.4非功能需求 7
3.4.1 性能需求 7
3.4.2安全性需求 7
3.4.3故障解决 7
4.任务分解 7
5.项目估算 9
5.1直接成本 9
5.2间接成本 9
5.3网上购物系统总成本 10
6. 进度筹划 10
7.质量筹划 12
7.1组织机构 12
7.2职责 14
7.2.1项目负责人职责  14
7.2.1质量保证人员职责 14
7.3质量目的 14
7.4质量方略 15
7.5软件质量保证活动 15
7.5.1审计 15
8. 风险筹划 15
8.1风险种类 16
8.1.1资金风险 16
8.1.2人员风险 16
8.1.3时间风险 16
8.1.4技术风险 17
8.1.5进度风险 17
8.2风险控制 18
8.2.1风险化解 18
8.3风险监控 18
9.团队管理 19
9.1项目组织构造 19
9.2团队沟通管理 19
10.项目结束 20
14.1项目终结  20
14.2结束筹划  20
14.3项目收尾  20

1.合同
1.1合同双方
甲方：胡某某
乙方：盛某某
1.2供应商品和服务
供应软件：乙方为甲方提供所需网上购物系统
提供服务：乙方为甲方提供所需寻常维护和服务器管理。
提供文档：乙方在交付软件时提供详细软件规格阐明书和使用文档。 
安装服务：乙方为甲方提供软件安装。 
公文解决：乙方负责将甲方提供公文资料加载入系统并进行分类。 
维护合同：当甲方在使用该产品时，在正常操作状况下浮现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件正常使用。当由于甲方错误使用等非软件因素导致浮现故障，乙方同样提供修复服务。由于甲方拥有该软件源代码所有权，因而甲方需要承担某些维修和进一步开发责任。当软件需要新功能拓展或改版升级时，由双方共同协商决定。
1.3时间地点
6月10日上午9:00在河北省沧州市黄骅市
1.4专利成果分派
该软件是由甲方向乙方定制，甲方拥有该软件版权，乙方不能将该软件任何版本卖个其她客户。软件提交时，项目源代码所有权自动移送到甲方，乙方不得擅自对源代码进行修改。
1.5验收原则
乙方在开发过程中必要遵守ISO 12207关于软件生命周期和文档原则。
1.6报酬计算
软件总价为2万元。合同订立后，甲方向乙方支付1万元定金。项目第二个月，乙方按筹划时间表完毕需求分析、系统分析、设计和完毕系统基本框架后，甲方向乙方支付0.5万元。该系统完毕后，甲方进行验收测试，在签字验收后完毕后，甲方向乙方支付全款。
1.7违约解决
任何一方违背本合同导致本合同无法继续履行，违约方需补偿守约方违约金人民币2万元，该违约金局限性以弥补守约方实际损失，违约方应补偿守约方所有实际损失。
甲办法人代表：胡某某
乙办法人代表：盛某某
2. 生存期
针对本项目开发特点，参照公司生存期模型阐明和软件过程体系，决定采用增量式模型如下图，理由如下： 
1．网上购物系统所有功能提成管理员和顾客功能两大类，因而可以先基于通用功能作出一种最小使用版本，再逐渐添加别的功能。这样一来，顾客可以先试用最小版本同步，提出更多明确需求，这有助于下一阶段开发，大大减小了开发风险。 
2．在网上购物系统需求规格中，规定系统有可扩充性。若使用增量模型，可以保证系统可扩充性。顾客明确了需求大某些，但也存在不很详尽地方。如：“关于管理员档案，比照所提供资料设计，当前也没有一种成形东西”；资源库系统只提到“应提供一种原则资源库解决方案。”这样只有等到一种可用产品出来，通过客户使用，然后进行评估，评估成果作为下一种增量开发筹划，下一种增量发布某些新增功能和特性。直至产生最后完善产品。 
3．“系统规定有可扩充性，可以在既有系统基本上，通过前台就可加挂其他功能模块”。也阐明顾客也许会增长新需求。 

生存期中各个阶段如下：
阶段
项目规划阶段
目的
依照合同和初步需求分析，拟定项目规模、时间筹划和资源需求
输入
合同文本，SOW
过程
项目规划，筹划确认
输出
项目筹划

阶段
需求分析阶段
目的
拟定客户需求
输入
项目筹划，SOW
过程
需求获取，需求分析，需求控制
输出
原型系统，需求规格

阶段
设计阶段
目的
总体系统构造设计
输入
原型系统，需求规格
过程
总体设计
输出
系统设计阐明书，数据库构造定义

阶段
增量1实现
目的
实现系统通用功能
输入
系统设计阐明书，数据库构造定义
过程
详细设计，编码，代码走查，代码评审，单元测试
输出
详细设计阐明书，源代码，可运营版本--1

阶段
增量2实现
目的
实现系统顾客管理功能
输入
系统设计阐明书，数据库构造定义
过程
详细设计，编码，代码走查，代码评审，单元测试
输出
详细设计阐明书，源代码，可运营版本--2

阶段
增量3实现
目的
实现系统商品管理功能
输入
系统设计阐明书，数据库构造定义
过程
详细设计，编码，代码走查，代码评审，单元测试
输出
详细设计阐明书，源代码，可运营版本--3

阶段
增量4实现
目的
实现系统个人信息管理功能
输入
系统设计阐明书，数据库构造定义
过程
详细设计，编码，代码走查，代码评审，单元测试
输出
详细设计阐明书，源代码，可运营版本--4

阶段
集成测试
目的
通过集成环境下软件测试
输入
测试筹划，测试用例
过程
集成测试，系统测试
输出
系统软件包，测试报告，产品阐明书

阶段
产品提交
目的
产品可投入使用
输入
系统软件包
过程
产品提交
输出
验收报告

3.需求管理

.3.1 功能需求
需求概述：
目的：
“网上购物系统”重要提供物品信息和对读者基本信息维护以及购买等功能。该系统针对顾客是网上购物者，物品种类和数量较多，系统需要操作以便，以便管理员对整个系统管理和顾客对于购买以便。
顾客类和特性：
最后顾客是管理员和顾客，管理员需要进行会员管理，更新物品信息等工作，规定具备计算机知识，如权限管理等。购买者是普通顾客，具备一定计算机操作知识即可。

本系统相应需求有：
（1）可以存储大量商品信息,并以便有效进行相应商品数据操作和管理，这重要涉及：
ü 商品信息添加、删除及修改。
ü 商品信息多核心字检索查询。
ü 商品出货、退货和资料记录。
ü 订单信息管理：查看订单清单、更新订单付款、删除订单。
（2） 可以对一定数量顾客进行相应信息存储与管理，这其中涉及：
ü 顾客信息登记、删除及修改。
ü 顾客资料，顾客订单信息记录与查询。
ü 可以提供一定安全机制，提供数据信息授权访问。
需求补充阐明：
（1）数据保存：需要长期保存在数据库数据有：
ü 物品信息：物品基本信息；
ü 顾客信息：顾客基本信息；
ü 下单信息：物品订单信息；
ü 帐号信息：管理员和顾客登录帐号；
（2）系统顾客：管理员、购物者。
ü 管理员：对物品和顾客数据可执行添加、修改、删除以及查询等操作。
ü 顾客：可查询物品，查看商品详细状况，商品选购以及查询与本人有关订单信息。

3.2拟定用例
用例描述了一种完整系统事件流程，其重点在于执行者与系统之间交互而不是内在系统活动，并对执行者产生有价值可观测成果。
拟定用例可以通过提出如下问题得到：
–参加者需要从系统中获得什么功能？参加者需要做什么？
–参加者读取、产生、删除、修改或存储系统某些信息吗？
–系统中发生事件需要告知参加者吗？参加者需要告知系统某件事情吗？
–系统输入/输出信息是什么？这些信息从哪儿来到哪儿去？
–采用什么实现办法满足某些特殊规定？

用例图
3.3用例文档
用例图不能提供用例所具备所有信息，因而需要使用文字描述那些不能放映在图形上信息。
1.物品信息维护用例
用例名：物品信息维护
参加执行者：管理员
入口条件：管理员已经登陆到该系统中。
事件流：当有新物品入库时，管理员在录入页面输入物品信息，点击提交按钮，系统将物品信息保存到数据库中；当某一种物品信息需要修改时，管理员通过输入查询条件，搜索出该物品时，点击修改按钮，系统在可编辑状态显示物品当前信息，管理员修改详细信息，点击保存按钮，系统将更新数据库中该物品信息，反之，则不进行任何操作。
出口条件： 系统将数据库中信息进行相应操作：添加物品信息时，将新物品信息保存在数据库中；修改物品信息时，将数据库中该物品信息做相应更新操作。
异常事件：在物品进行修改时，先查出需要进行解决物品记录，如果数据库中不错在符合条件记录，查询无成果时，则无法进行修改操作。
2.顾客信息维护用例
用例名：会员信息维护
参加执行者：管理员
入口条件：管理员已经登陆到该系统中。
事件流：当有新会员时，管理员在录入页面输入会员信息，点击提交按钮，系统将会员信息保存到数据库中；当某一会员信息需要修改时，会员通过输入查询条件，搜索出该信息时，点击修改按钮，系统在可编辑状态显示当前信息，会员修改详细信息，点击保存按钮，系统将更新数据库中该会员信息，反之，则不进行任何操作。
出口条件： 系统将数据库中会员信息进行相应操作：添加会员信息时，将新会员信息保存在数据库中；修改会员信息时，将数据库中该会员信息做相应更新操作。
异常事件：在进行修改会员信息时，先查出需要进行解决会员记录，如果数据库中不错在符合条件记录，查询无成果时，则无法进行修改操作。
3.物品信息查询用例
用例名：物品信息查询
参加执行者：管理员、购物者
入口条件：无
事件流：通过交互界面输入查询条件(如物品名，产地名等)搜索物品记录。
出口条件：若有符合条件物品信息，则系统显示这些物品信息。否则系统提示顾客重新输入查询条件。
4.会员信息查询用例
用例名：会员信息查询
参加执行者：管理员
入口条件：顾客已经登陆到该系统中。
事件流：通过查询界面输入查询条件(如会员ID，会员名称等)搜索待会员记录。
出口条件：若有符合条件会员信息，则系统显示会员信息。否则系统提示顾客重新输入查询条件。
5.查询个人基本信息用例
用例名：查询个人基本信息
参加执行者：会员
入口条件：顾客已经登陆到该系统中。
事件流：点击查询个人基本信息按钮。
出口条件：系统显示会员本人信息。
6.查询个人订单信息用例
用例名：查询个人订单信息
参加执行者：会员
入口条件：顾客已经登陆到该系统中。
事件流：点击查询个人订单信息按钮。
出口条件：系统显示读者订单信息。
7.下单用例
用例名：下单
参加执行者：管理员、会员
入口条件：管理员已经登陆到该系统中。
事件流：管理员在下单页面，输入物品编号和会员ID，点击保存。
出口条件：系统将这条下单记录保存到数据库中。
异常事件：如果该物品未入库，数据库中不存在该物品编号，提示“该物品没有库存”；如果数据库中不存在该会员ID，也相应做出提示。
8.退货用例
用例名：退货
参加执行者：管理员、会员
入口条件：管理员已经登陆到该系统中。
事件流：管理员在退货页面，输入物品编号，点击退货。
出口条件：系统将记录数据库中这条退货记录。
异常事件：如果该物品退货时间已过期，提示“该物品不能退货”。
9.口令管理用例
用例名：口令管理
参加执行者：管理员、会员
入口条件：会员已经登陆到该系统中。
事件流：顾客点击“修改密码”按钮，在口令修改页面输入新密码，点击保存按钮。
出口条件：数据库中密码被修改成最新密码。
3.4非功能需求
3.4.1 性能需求
网上购物系统使用者是管理员和购物者。对于管理员管理工作，性能规定不是很严格，但需要以便物品信息更新等操作。对于购物者物品下单、查询等功能，对性能规定较高，普通需要达到并发数200以上。
3.4.2安全性需求
由于网上购物系统商品量会非常大，所有在对这些商品添加和查询时要保证速度。在对物品下单过程中又要保证事务完整性。对于整个系统，需要完整权限控制，防止某些人恶意袭击系统，修改原始记录。同步对于数据库中数据需要定期备份，防止系统数据丢失。此外，系统规定顾客在登陆时需要身份验证。
3.4.3故障解决
在正常状况下，应不出错。一旦发生意外，例如掉电、网络不通等，应保证系统数据不会丢失。

4.任务分解
项目任务分解编码表
编码
任务名称
备注
R000 000
需求讨论
初步拟定需求
P000 000
软件规划
制定项目筹划

P100 000
项目规划

P200 000
筹划评审

M000 000
需求开发
细化需求

M100 000
顾客界面设计

M200 000
顾客需求评审

M300 000
修改需求、界面

M400 000
编写需求阐明

M500 000
需求验证

D000 000
设计
完毕项目设计工作

D100 000
概要设计

D200 000
数据库ER图编制、建库

D300 000
设计评审

C000 000
实行
实际开发

C100 000
顾客管理

C100 100
顾客注册

C100 200
顾客注销

C100 300
账号登陆

C100 400
个人信息管理

C200 000
物品管理

C200 100
更新物品信息

C200 200
删除过期物品信息

C200 300
查看物品信息

C300 000
会员管理

C300 100
新增会员

C300 200
删除注销会员

C300 300
查看既有会员

C300 310
查看会员信息

C300 320
查看会员购物信息

C400 000
界面实现

C500 000
整合

T000 000
测试
对项目进行测试

T100 000
功能模块测试

T200 000
系统集成测试

T300 000
环境测设

V000 000
布置
发布并交付

5.项目估算
5.1直接成本
由于涉及到小构成员没有实际开发经验，在薪酬结算方面没有可供参照原则，因而在这里采用统一￥100.00人天。

任务名称
工时
成本估算
网上购物系统
10人天
￥15100.00
需求讨论
2*2 人天
￥400.00
软件规划
6*2 人天
￥1200.00
需求开发
6*4 人天
￥2400.00
设计
4*4 人天
￥1600.00
实行
6*13 人天
￥7800.00
测试
3*5 人天
￥1500.00
布置
2*1 人天
￥200.00

5.2间接成本

任务名称
工时
成本估算
设备损耗
31 工作日
￥800.00
其她费用
31 工作日
￥200.00
总计

￥1000.00

5.3网上购物系统总成本

任务名称
工时
成本估算
网上购物系统总成本
31 工作日
￥16100.00
6. 进度筹划
项目进度管理控制是对项目在实行阶段作业程序和作业时间进行规划、实行、检查、调查等一系列活动总称，即在项目实行过程中，按照已经核准进度筹划，采用科学办法定期追踪和检查项目实际进度状况，并参照项目先期进度筹划，找出两者之间偏差，并对产生偏差各种因素及影响工期限度进行分析与评估；而后组织、指引、协调和监督监理单位及有关单位三方，协助其及时采用有效办法调节项目进度，使工期在筹划执行中不断循环往复，直至该项目按合同商定工期如期竣工，或在保证项目质量和不增长原先预算条件下，使该项目提前竣工并交付使用。项
项目进度筹划：

任务代码
工期
开始时间
结束时间
资源
个人微薄系统
31 工作日
-6-15
-7-15

R000 000
2 工作日
-6-15
-6-16
2人
P000 000
2 工作日
-6-17
-6-18
全体开发人员
P100 000
1 工作日
-6-17
-6-17
2人
P200 000
1 工作日
-6-18
-6-18
全体开发人员
M000 000
4 工作日
-6-19
-6-22
全体开发人员
M100 000
1 工作日
-6-19
-6-19
1人
M200 000
1 工作日
-6-19
-6-19
2人
M300 000
1 工作日
-6-20
-6-20
1人
M400 000
1 工作日
-6-21
-6-21
1人
M500 000
1 工作日
-6-22
-6-22
全体开发人员
D000 000
4 工作日
-6-23
-6-26
全体开发人员
D100 000
2 工作日
-6-23
-6-24
全体开发人员
D200 000
1 工作日
-6-25
-6-25
全体开发人员
D300 000
1 工作日
-6-26
-6-26
全体开发人员
C000 000
13 工作日
-6-27
-7-9
全体开发人员
C100 000
6 工作日
-6-27
-7-2
全体开发人员
C100 100
4 工作日
-6-27
-6-30
全体开发人员
C100 200
2 工作日
-7-1
-7-2
全体开发人员
C100 300
4 工作日
-6-27
-6-30
全体开发人员
C100 400
2 工作日
-7-1
-7-2
全体开发人员
C200 000
11 工作日
-6-27
-7-7
全体开发人员
C200 100
5 工作日
-7-1
-7-5
全体开发人员
C200 200
5 工作日
-7-1
-7-5
全体开发人员
C200 300
3 工作日
-7-6
-7-8
全体开发人员
C300 000
8 工作日
-7-1
-7-8
全体开发人员
C300 100
5 工作日
-7-1
-7-5
全体开发人员
C300 200
5 工作日
-7-1
-7-5
全体开发人员
C300 300
3 工作日
-7-6
-7-8
全体开发人员
C300 310
3 工作日
-7-6
-7-8
全体开发人员
C300 320
3 工作日
-7-6
-7-8
全体开发人员
C400 000
12 工作日
-6-27
-7-8
全体开发人员
C500 000
1 工作日
-7-9
-7-9
全体开发人员
T000 000
5 工作日
-7-10
-7-14
全体开发人员
T100 000
3 工作日
-7-10
-7-12
全体开发人员
T200 000
1 工作日
-7-13
-7-13
全体开发人员
T300 000
1 工作日
-7-14
-7-14
全体开发人员
V000 000
1 工作日
-7-15
-7-15
全体开发人员

7.质量筹划
7.1组织机构
在项目实行期间成立项目质量保证组织，该组织由质量保证人员和项目负责人构成，项目负责人负责质量监督工作及项目进展过程中各环节质量把关，开发负责人负责质量控制工作，质量保证人员负责质量保证工作。

7.2职责
7.2.1项目负责人职责 
1.评审质量筹划。 
2.与质量保证人员一起协商不符合项问题纠正办法，并安排资源实行纠正办法。 
3.定期或事件驱动地评审质量保证活动和成果。
7.2.1质量保证人员职责 
1.负责项目实行过程中对项目实行状况进行监督，涉及对项目实行过程和工作产品进行监督检查。 
2.实行项目构成员质量保证培训。 
3.制定质量保证筹划。
4．按筹划实行审计活动，依照质量保证筹划执行评审/审计，并记录执行中发现不符合项。 
5.对不符合问题提交不符合项报告，跟踪并验证纠正办法执行状况。 
6.对项目内不能解决不符合项问超；向高层管理提交报告。 
7.向项目经理报告项目质量工作状况和质量度量成果，定期向项目组报告质量活动成果。 
8.制定质量保证过程改进筹划，记录过程数据。
7.3质量目的
1.基于需求测试覆盖率为100%。
2.功能测试完善 
3.每个阶段评审中发现问题都已经解决或得到恰当解决。 
4.产品发布时不存在严重问题以及以上缺陷。 
5.严格满足合同规定和规格 
6.顾客领导满意 

质量筹划原则
项 目
具 体 描 述
计 划
实 际
缺陷排除率（缺陷数/页）
需求检查
4

系统总体设计检查
2

缺陷排除率（缺陷数/KLOC）
详细设计复核
30

详细设计检查
10

代码复核
65

代码检查
20

编译
20

单元测试
15

系统集成
5

系统测试
5

7.4质量方略
1. 控制产品质量，及时纠正缺陷 
2应当特别注意项目工作产品质量初期评审工作，元论是质量保证还是质量控制，采用方略都是初期防止和初期排除缺陷。
3将质量贯彻到寻常项目进展过程中；
7.5软件质量保证活动
质量保证重要活动涉及过程评审和产品审计。过程评审和产品审计目是为了保证在项目进展过程各个阶段和各个方面采用各项办法来保证和提高提交给顾客产品质量。
7.5.1审计

时间
原则
审计软件项目筹划审计软件项目筹划
筹划结束
合同规定
需求规划文档
需求制定
需求规格阐明
总体设计文档
总体设计制定
软件项目筹划
详细设计文档
详细设计制定
软件项目筹划
编码规范
详细设计制定
软件项目筹划
产品代码
编码结束
编码规范
测试文档
详细设计制定
公司质量规定
顾客手册
产品提交之前
项目筹划和需求

7. 风险筹划
风险是指在项目进行过程中也许发生事件，这些事件将会对项目按预期时间，资源和预算完毕产生重大影响。风险管理目的是在潜在问题发作此前就标志它们，这样就可以在生命周期中可以适时地筹划和启用风险解决活动。

8.1风险种类
8.1.1资金风险
1. 资金与否到位。
2. 与否有预算限制使得系统必要以固定成本交付，否则将被取消。
3. 成本估算与否精确。
8.1.2人员风险
1. 与否可以获得足够项目工作人员。
2. 她们与否具备适当技能和经验。
3. 开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺少勉励办法,士气低下,减少了生产能力。
4. 没有找到项目急需具备特定技能人。
8.1.3时间风险
1. 时间表制定得与否现实。
2. 对交付日期规定有多严格。
3.与否有时间“把工作做好”。
8.1.4技术风险
技术与否已通过证明。
重复使用目的与否合理。
工件必要要使用一次后才干被重复使用。
构件也许要在若干次发布后才干变得稳定，以致无需重大变更即可复用。
需求中事务量与否合理。
事务比率预计值与否可靠？这些预计与否过于乐观。
数据量与否合理？当前可用框架与否可以保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计一某些，那么与否可以在这些地方合理地保存数据。
与否有特殊或苛刻技术需求。
成功与否依赖于新或未经实验产品、服务或技术？与否依赖于新或未被证明硬件、软件或技术。
对于与其她系统（涉及公司以外系统）接口与否存在外部依赖性？与否存在必须接口或必要创立它们 。
与否存在极不灵活可用性和安全性需求（例如“系统必要永远不浮现故障”）。
系统顾客与否对正在开发系统类型没有经验。
应用程序大小或复杂性，或者技术新颖性与否导致了风险增长。
与否存在对国家语言支持需求。
与否也许设计、实行和运营该系统？某些系统只由于太大或太复杂而无法正常工作。
8.1.5进度风险
功能与否无限追加。
筹划与否过于乐观。
与否缺少筹划。
在压力下与否放弃筹划。
与否追赶筹划。
8.2风险控制
1.实行和跟踪风险管理筹划，保证风险筹划执行，评估削减风险有效性。 
2.针对一种预测风险事实上与否发生了，保证针对某个风险而制定风险消除环节正在合理使用。
3.监视剩余风险和辨认新风险。
4.收集可用于将来风险分析信息。
8.2.1风险化解
避免风险（即：不要做冒险活动）
将风险从系统一某些转移到另一某些（也许对于系统其她某些此风险不会发生或发生时影响不大）
购买关于风险信息（例如：做实验性项目，请征询专家等）
消除风险根源
接受风险（如果风险后果较小，而解决它也许代价很大，滚动解决也许是最有效途径）
发布风险（将风险发布给有关涉众，如：管理者、市场人员、客户{特别注意方略}）
8.3风险监控
周例会检查风险
在周工作例会上，项目经理需要跟踪项目风险。
依照风险列表，逐个分析前10大风险，确认已经风险状态与否“发生”或“关闭”；
如果风险发生则启动“风险应急筹划”或项目组协商解决办法，必要时PM祈求有关高档管理者解决已发生风险，并且PM负责在风险管理筹划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理筹划中将此条风险标示为“关闭”。记录每项风险停留时间(周数)。周例会检查风险
在周工作例会上，项目经理需要跟踪项目风险。
依照风险列表，逐个分析前10大风险，确认已经风险状态与否“发生”或“关闭”；
如果风险发生则启动“风险应急筹划”或项目组协商解决办法，必要时PM祈求有关高档管理者解决已发生风险，并且PM负责在风险管理筹划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理筹划中将此条风险标示为“关闭”。记录每项风险停留时间(周数)。周例会检查风险
在周工作例会上，项目经理需要跟踪项目风险。
依照风险列表，逐个分析前10大风险，确认已经风险状态与否“发生”或“关闭”；
如果风险发生则启动“风险应急筹划”或项目组协商解决办法，必要时PM祈求有关高档管理者解决已发生风险，并且PM负责在风险管理筹划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理筹划中将此条风险标示为“关闭”。9.团队管理
团队是一定数量个体成员组织集合，涉及自己组织人、供应商、分包商、客户等为一种共同目的工作，协调一致，高兴合伙，最后开发出来高质量产品。产品负责人在进行团队管理时要以团队成员为本，从团队成员角度去思考问题，这样可以不久增强团队凝聚力和团队效率。其详细意义可以体当前如下几种方面：
①是保证准时、按质交付项当前提;
②有助于开发出高质量软件;
③有助于充分发挥每位成员特长和创造性;
④有助于提高团队成员积极性、积极性;
⑤有助于增长开发人员知识、见识;
⑥增长成员间彼此理解，让成员坦诚相见;
⑦有助于团队成员互相学习、交流。
9.1项目组织构造
产品负责人——开发负责人、质量监管人——成员
长处：
1. 项目经理对项目可以全权负责。可以依照项目需要随意调动项目组织内部资源或者外部资源。 
2. 项目型组织目的单一，完全以项目为中心安排工作，决策速度得以加快，可以对客户规定做出及时响应，项目团队精神得以充分发挥。有助于项目顺利完毕。 
3. 项目经理对项目成员有所有权利，项目成员只对项目经理负责，避免了职能型项目组织下项目成员处在多重领导、无所适从局面，项目经理是项目真正、唯一领导者。 
4. 组织构造简朴，易于操作。项目成员直接属于同一种部门，彼此之间沟通交流简介、迅速，提高了沟通效率，同步也加快了决策速度。
缺陷：
1． 每一种项目型组织，资源不能共享，虽然某个项目专用资源闲臵，也无法应用于此外一种同步进行类似项目，人员、设施、设备重复配臵，会导致一定限度资源挥霍。 
2． 公司里各个独立项目型组织处在相对封闭环境之中，公司宏观政策、
方针很难做到完全、真正贯彻实行，也许会影响公司长远发展。 
3． 在项目完毕后来，项目型组织中项目成员或者被拍到另一种项目中去，或
者被解雇，对项目成员来说，缺少一种事业上持续性和安全感。 
4． 项目之间处在一种条块分割状态，项目之间缺少信息交流，不同项目组很
难共享知识和经验，项目成员工作会浮现忙闲不均现象。
9.2团队沟通管理
为了保证团队信息沟通制定如下沟通筹划：
1.每天午饭时间项目构成员进行口头交流。。 
2.每周五15：00-17：00召开项目周例会，  
3.及时提交问题报告，问题可以通过网络提交，项目经理睬及时获取问题信息。 
4.组内成员有任何问题可以在qq群内进行非正式讨论。

9. 项目结束
14.1项目终结 
项目筹划中拟定可交付成果已经浮现，项目目的已经成功实现，本项目成功终结。 
14.2结束筹划 
作为项目筹划一某些，与客户一同评审项目结束筹划，细化并实行项目结束筹划。    
14.3项目收尾 
1）范畴确认：项目接受前，重新审核工作成果，检查项目各项工作范畴与否完毕，或者完毕到何种限度，最后，双方确认签字。 
2）质量验收：质量验收是控制项目最后质量重要手段，根据质量筹划和有关质量原则进行验收，不合格不予接受。 
3）费用决算：费用决算是指对从项目开始到项目结束全过程所支付所有费用进行核算，编制项目决算表过程。 
4）合同终结：整顿并存档各种合同文献。 
5）资料验收：检查项目过程中所有文献与否齐全，然后进行归档。
1）范畴确认：项目接受前，重新审核工作成果，检查项目各项工作范畴与否完毕，或者完毕到何种限度，最后，双方确认签字。 
2）质量验收：质量验收是控制项目最后质量重要手段，根据质量筹划和有关质量原则进行验收，不合格不予接受。 
3）费用决算：费用决算是指对从项目开始到项目结束全过程所支付所有费用进行核算，编制项目决算表过程。 
4）合同终结：整顿并存档各种合同文献。 
5）资料验收：检查项目过程中所有文献与否齐全，然后进行归档。