网上购物系统-软件项目管理大作业
《网上购物系统》项目管理目录
1.合同 (1)
1.1合同双方 (1)
1.2供应的商品和服务 (1)
1.3时间地点 (1)
1.4专利成果分配 (1)
1.5验收标准 (1)
1.6报酬计算 (1)
1.7违约处理 (1)
2. 生存期 (2)
3.需求管理 (3)
3.1 功能需求 (4)
3.2确定用例 (4)
3.3用例文档 (5)
3.4非功能需求 (6)
3.4.1 性能需求 (6)
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人天。
任务名称工时成本估算
网上购物系统151人天￥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 工作日2016-6-15 2016-7-15
R000 000 2 工作日2016-6-15 2016-6-16 2人
P000 000 2 工作日2016-6-17 2016-6-18 全体开发人员
P100 000 1 工作日2016-6-17 2016-6-17 2人
P200 000 1 工作日2016-6-18 2016-6-18 全体开发人员
M000 000 4 工作日2016-6-19 2016-6-22 全体开发人员
M100 000 1 工作日2016-6-19 2016-6-19 1人
M200 000 1 工作日2016-6-19 2016-6-19 2人
M300 000 1 工作日2016-6-20 2016-6-20 1人
M400 000 1 工作日2016-6-21 2016-6-21 1人
M500 000 1 工作日2016-6-22 2016-6-22 全体开发人员
D000 000 4 工作日2016-6-23 2016-6-26 全体开发人员
D100 000 2 工作日2016-6-23 2016-6-24 全体开发人员
D200 000 1 工作日2016-6-25 2016-6-25 全体开发人员
D300 000 1 工作日2016-6-26 2016-6-26 全体开发人员 C000 000 13 工作日2016-6-27 2016-7-9 全体开发人员 C100 000 6 工作日2016-6-27 2016-7-2 全体开发人员 C100 100 4 工作日2016-6-27 2016-6-30 全体开发人员 C100 200 2 工作日2016-7-1 2016-7-2 全体开发人员 C100 300 4 工作日2016-6-27 2016-6-30 全体开发人员 C100 400 2 工作日2016-7-1 2016-7-2 全体开发人员 C200 000 11 工作日2016-6-27 2016-7-7 全体开发人员 C200 100 5 工作日2016-7-1 2016-7-5 全体开发人员 C200 200 5 工作日2016-7-1 2016-7-5 全体开发人员 C200 300 3 工作日2016-7-6 2016-7-8 全体开发人员 C300 000 8 工作日2016-7-1 2016-7-8 全体开发人员 C300 100 5 工作日2016-7-1 2016-7-5 全体开发人员 C300 200 5 工作日2016-7-1 2016-7-5 全体开发人员 C300 300 3 工作日2016-7-6 2016-7-8 全体开发人员 C300 310 3 工作日2016-7-6 2016-7-8 全体开发人员 C300 320 3 工作日2016-7-6 2016-7-8 全体开发人员 C400 000 12 工作日2016-6-27 2016-7-8 全体开发人员 C500 000 1 工作日2016-7-9 2016-7-9 全体开发人员 T000 000 5 工作日2016-7-10 2016-7-14 全体开发人员 T100 000 3 工作日2016-7-10 2016-7-12 全体开发人员 T200 000 1 工作日2016-7-13 2016-7-13 全体开发人员 T300 000 1 工作日2016-7-14 2016-7-14 全体开发人员 V000 000 1 工作日2016-7-15 2016-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.5进度风险
功能是否无限追加。
计划是否过于乐观。
是否缺乏计划。
在压力下是否放弃计划。
是否追赶计划。
1.实施和跟踪风险管理计划，保证风险计划的执行，评估削减风险的有效性。
2.针对一个预测的风险事实上是否发生了，确保针对某个风险而制定的风险消除步骤正在合理使用。
3.监视剩余的风险和识别新的风险。
4.收集可用于将来的风险分析信息。
8.2.1风险的化解
避免风险（即：不要做冒险的活动）
将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）
购买关于风险的信息（例如：做实验性项目，请咨询专家等）
消除风险的根源
接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径）发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户{特别注意策略}）
8.3风险监控
周例会检查风险
在周工作例会上，项目经理需要跟踪项目的风险。
根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；
如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。统计每项风险的停留时间(周数)。周例会检查风险
在周工作例会上，项目经理需要跟踪项目的风险。
根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；
如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。
如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。统计每项风险的停留时间(周数)。周例会检查风险
在周工作例会上，项目经理需要跟踪项目的风险。
根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；
如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。