学生成绩综合管理系统软件优质项目管理大作业.docx

《学生成绩管理系统》项目管理文档
目录
一.合同管理 1
1.1签订须知 1
1.2 需方合同环境 1
1.2.1合同准备 1
1.2.2合同签署 1
1.2.3合同管理 2
1.2.4合同终止过程 2
1.3供方合同环境 2
1.3.1 合同准备 2
1.3.2 合同签署 2
1.3.3 合同管理 3
1.3.4 合同终止过程 3
1.4 内部环境 3
1.5 合同 3
二.生存期 4
2.1 增量式模型 4
三.需求管理 6
3.1 软件需求管理过程 6
3.1.1 软件需求说明书 6
3.1.2 可行性分析 6
3.1.3 对功能的规定 6
3.1.4 数据流图 7
四.项目任务分解 9
4.1 系统设计思想 9
4.2 系统数据流程图设计 9
4.2.1 系统数据流程图 9
4.2.2 学生成绩管理系统的描述 10
4.3 模块设计 10
五.项目估算 10
5.1 声明 10
5.2 项目规模估算 11
5.3 项目成本估算 11
六.进度计划 12
6.1 项目进度 12
6.2 甘特图 13
七.质量计划 13
7.1 项目测试 13
7.1.1 系统登录测试 13
7.1.2 学生成绩信息的录入测试 13
7.1.3 学生成绩的查询测试 14
7.1.4 确认测试 14
7.1.5系统测试 14
7.1.6 故障对策 14
7.1.7 测试结果的评价 14
7.2 系统维护 14
7.3 SQA活动图 15
7.4 不符合性问题处理 16
7.5记录的收集、维护和保存 17
八．项目风险管理 17
8.1项目风险管理的目的 17
8.2项目风险管理的组成 18
8.3 风险的种类 18
8.3.1 资源风险 18
8.3.2 业务风险 19
8.3.3 技术风险 19
8.3.4 进度风险 20
8.4 定义风险参数 20
8.5 风险管理策略 20
8.6 风险管理角色及职责 20
8.7 学生成绩管理项目中风险的识别 20
8.8 风险的控制 21
8.9 风险监控 21

一.协议管理
1.1签署须知
1. 该协议为某某局协议范本，标准上不得改动，如一定要进行修改，请附上《修改前后对比表》。为列入《修改前后对比表》修改部分，视为恶意篡改，本局不给予认可。
1.2 需方协议环境
1.2.1协议准备
1.招标文件
河北省教育部需要引入一套“学生成绩管理系统”应用程序，现向个大学进行公开招标，欢迎有资格投标大学参与。
一．招标项目名称：“学生成绩管理系统”应用软件
二．招标内容：河北省学生“学生成绩管理系统”应用程序设计，开
发，安装、调试、使用教学及对应后期维护升级。
三．资质要求：含有省级政府项目投标资格企业或个人，具体要求见投标
须知（投标须知略）
四．投标、开标相关说明：
1.投标文件发售时间：6月18日至6月20日工作时
间内
2.投标文件发售地点：北京交通大学海滨学院
3.投标文件售价：￥10,000 （售后不退，不接收邮购）
4.投标地点：北京交通大学海滨学院汇报厅
5.投标截止时间：6月30日北京时间10:00时
6.开标时间：7月1日北京时间14:00时
7.开标地点：北京交通大学海滨学院汇报厅
五．相关要求：
1.超出投标截止时间、不按要求密封投标或不按《招标文件》要求提
交有效足额投标确保金（以汇票、支票、现金支付）投标，恕不接收。
2.提交投标确保金户名：北京交通大学海滨学院财务处
3.开户行：XX市渣打银行XXX路分行
4.账号：345
六．联络：
北京交通大学海滨学院 具体地址：略
联络人：略 邮编：000000
电话：（02X）10000000 传真：（02X）10000000
1.2.2协议签署
河北省教育部和北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院负担设计、开发、安装调试等一系列工作，内部部门人员配臵同软件企业相同，借用大连理工大学之名而已。即北京交通大学海滨学院为供方）以河北省委省政府提出协议草案为基础，经过确定谈判日程、协议草案提交、协议条款协商、确定协议签署文本、协议签署文本审阅、协议签署步骤完成协议签署。最终形成协议签署文本和任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海滨学院全权负责软件设计开发）
1.2.3协议管理
1.验收过程
河北省教育部政府依据协议准备和协议签署时确定需求资料及协议文本制订验收清单。对验收清单评审后制订验收计划，并按验收计划实施，得到验收汇报。对发觉问题制订验收问题处理计划，最终确定验收汇报。
2.违约事件处理过程
在协议实施期内，假如协议双方河北省教育部政府或北京交通大学海滨学院有违约事件。需依据违约事件汇报进行违约事件通告，确定处理方法后按计划处理违约事件。以后形成违约事件处理汇报。
1.2.4协议终止过程
河北省教育部政府和北京交通大学海滨学院依据协议及相关文档，公布协议终止通知、项目实施总结
1.3供方协议环境
1.3.1 协议准备
1.项目分析
北京交通大学海滨学院依据招标书安排项目分析任务。经过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实施计划、初步实施计划评审，最终得到需求分析汇报和项目初步计划。
2.竞标
北京交通大学海滨学院根据需求分析汇报和项目计划进行竞标，经过技术能力要求确定、人力资源要求确定、实现环境要求确定、资金管理要求确定、能力判定、评定结果审评等评定，并进行需求成熟度评定、用户支持确保评定、用户资金确保评定、可行性分析、项目决议、编写项目提议书等步骤，依据项目提议书参与竞标。
1.3.2 协议签署
河北省教育部政府和北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院负担设计、开发、安装调试等一系列工作，内部部门人员配臵同软件企业相同，借用大连理工大学之名而已。即北京交通大学海滨学院为供方）以河北省委省政府提出协议草案为基础，经过确定谈判日程、协议草案提交、协议条款协商、确定协议签署文本、协议签署文本审阅、协议签署步骤完成协议签署。最终形成协议签署文本和任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海滨学院全权负责软件设计开发）
1.3.3 协议管理
1.协议实施跟踪管理过程
北京交通大学海滨学院以项目计划为基础，进行项目计划审批和协议实施管理计划。按计划完成项目进展汇报、协议责任落实、需求变更处理和产品验收。
2.协议修改控制
假如需方即河北省省教育部提出变更请求，假设提出是要求添加不用登录网页直接经过“学生成绩管理系统”应用程序即可向网内用户发送邮件，并依据不一样层级用户权限显示网内在线用户。则北京交通大学海滨学院需依据协议和变更请求进行变更评定，并提出协议修改提议，确定修改策略。对目前计划进行调整，并需得出处理汇报。
3.违约事件处理过程
在协议实施期内，假如协议双方河北省教育政府或北京交通大学海滨学院有违约事件。需依据违约事件汇报进行违约事件通告，确定处理方法后按计划处理违约事件。以后形成违约事件处理汇报。
4.产品提交过程
在产品开发测试结束后向河北省教育部提交产品，经过审查后正式提交给河北省教育部政府。最终相方签字认可，通知相关各方。
5.产品维护过程
依据协议中维护需求，制订维护需求统计。
1.3.4 协议终止过程
河北省教育部政府和北京交通大学海滨学院依据协议及相关文档，公布协议终止通知、项目实施总结
1.4 内部环境
北京交通大学海滨学院内部确定任务范围，使相关各方有效配合。
1.5 协议
1.协议双方
甲方：河北省教育部 乙方：北京交通大学海滨学院
2.协议形式
协议形式：技术协议
3.供给商品和服务
供给软件：乙方为甲方提供所需“学生成绩管理系统”应用程序
提供服务：乙方为甲方提供所需日常维护和服务器管理。同时对甲方用户提供使用教学。
提供文档：乙方在交付软件时提供具体软件规格说明书和使用文档。
安装服务： 乙方为甲方提供软件安装。
公文处理： 乙方负责将甲方提供公文资料加载入系统并进行分类
维护协议： 当甲方在使用该产品时，在正常操作情况下出现BUG或系统错误，乙方无偿为甲方提供修复服务以保障软件正常使用。当因为甲方错误使用等非软件原因造成出现故障，乙方一样提供修复服务。因为甲方拥有该软件源代码全部权，所以甲方需要负担部分维修和深入开发责任。当软件需要新功效拓展或改版升级时，由双方共同协商决定。
4.软件全部权
该软件是由甲方向乙方定制，甲方拥有该软件版权，乙方不能将该软件任何版本卖个其它用户。软件提交时，项目源代码全部权自动移交到甲方，乙方不得私自对源代码进行修改。
5.环境
乙方为甲方安装软件和进行职员培训时，需要由甲方提供住宿和膳食，乙方在要求时间内完成任务。甲方要确保安装软件硬件设备和协议初始要求一致，乙方只确保软件和要求硬件兼容。由任何一方单方面原因造成延期产生费用，由该方面支付。
6.用户承诺
乙方开发软件过程中，甲方经过人员协同乙方进行开发。该人员关键参与项目标计划设计和需求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行具体叙述说明。乙方不负责这些人员提供食宿和联络设备。
7.验收规程
7月25日，乙方为甲方安装所需套数软件。7月25日至7月31日甲方代表对产品进行验收测试，并依据需求在8月30日前对产品提出更正请求。测试经过后，双方带白哦进行软件交付签字。乙方对甲方进行软件使用培训。
8.标准
乙方在开发过程中必需遵守ISO 12207相关软件生命周期和文档标准。
9.项目和质量管理
甲乙双方前四个月每个月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度掩饰和下一阶段工作安排和计划。甲方依据演示提出对应整改意见，并对下一步工作进行提出意见和提议。
10.价格和付款方法
软件总价为230W。协议签署后，甲方向乙方支付50万元定金。项目标第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统基础框架后，甲方向乙方支付80万元。该系统完成后，甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。
11.其它法律要求
由任何一方过失造成出现损失后赔偿由双方协商决定。
二.生存期
2.1 增量式模型
图1所表示：

理由以下：
1）学生成绩管理系统全部功效分成查询功效和添加功效两大类，所以能够先基于查询功效做出一个最小使用版本，再逐步添加其它功效。这么一来，用户能够先试用最小版本同时，提出更多明确需求，这有利于下一阶段开发，大大减小了开发风险。
2）在学生成绩管理系统需求中，要求系统含有可扩充性。若使用增量模型，能够确保系统可扩充性。用户明确了需求大部分，但也存在不很详尽地方。这么只有等到一个可用产品出来，经过用户使用，然后进行评定，评定结果作为下一个增量开发计划，下一个增量公布部分新增功效和特征，直至产生最终完善产品。
3）“系统要求有可扩充性，能够再现有系统基础上，能够在增加其它功效模块”----也说明用户可能会增加新需求。
4）应该从最基础应用做起，逐步扩充其应用，所以选择增量模型来学生成绩管理系统。
5）本项目含有增量式模型其它特点：项目复杂程度为中等；估计开发软件成本为中等；产品和文档再使用率会很高；项目风险较低。
生存期中各阶段定义以下：
项目计划阶段
阶段目标：依据协议和初步需求分析确定项目标规模、时间计划和资源需求。
输入：协议文本、SOW 过程：项目计划，计划确定 输出：项目计划 需求分析阶段
阶段目标：确定用户需求 输入：项目计划，SOW
过程：需求获取，需求分析，需求控制 输出：原型系统，需求规格 设计阶段
阶段目标：总体系统结构设计 输入：原型系统，需求规格 过程：总体设计
输出：系统设计说明书、数据库结构定义 增量1实现
阶段目标：实现系统通用功效
输入：系统设计说明书、数据库结构定义
过程：具体设计，编码，代码走查，代码评审，单元测试 输出：具体设计说明书，源代码，可运行版本-1 增量2实现
阶段目标：实现系统管理员模块管理功效 输入：系统设计说明书、数据库结构定义
过程：具体设计，编码，代码走查，代码评审，单元测试 输出：具体设计说明书，源代码，可运行版本-2 增量3实现
阶段目标：实现系统老师模块管理功效 输入：系统设计说明书、数据库结构定义
过程：具体设计，编码，代码走查，代码评审，单元测试 输出：具体设计说明书，源代码，可运行版本-3 增量4实现
阶段目标：实现系统学生模块管理功效 输入：系统设计说明书、数据库结构定义
过程：具体设计，编码，代码走查，代码评审，单元测试 输出：具体设计说明书，源代码，可运行版本-4 增量5实现
阶段目标：实现系统学生自助预约功效 输入：系统设计说明书、数据库结构定义
过程：具体设计，编码，代码走查，代码评审，单元测试 输出：具体设计说明书，源代码，可运行版本-5 集成测试
阶段目标：经过集成环境下系统测试 输入：测试计划、测试案例 过程：集成测试，系统测试
输出：系统软件包，测试汇报，产品说明书 产品提交
三.需求管理
3.1 软件需求管理过程
3.1.1 软件需求说明书
伴随在校大学生人数不停增加，教务系统数据量也不停上涨。学校工作繁杂、资料重多，即使各类管理信息系统已进入高校，但还未普及，而对于学生成绩管理来说，现在还没有一套完整、统一系统。所以，开发一套适和大众、兼容性好系统是很有必需。
3.1.2 可行性分析
现在，伴随办公信息化开展，高校扩招，新生入学和期末考试结束后，学校全部需要对部分繁琐步骤进行管理，经过一个基于B/S架构管理系统，能够很好将这一个过程进行化繁为简。此项目含有普遍性，能够应用于很多学校。所以，该类型系统能够大量投入使用。
3.1.3 对功效要求
从程序结构中能够看出，学生信息输入输出功效是由学生管理系统进行。课程输入输出是由课程管理系统进行，而班级信息流动则是班级管理系统进行。
学生成绩管理信息系统多个基础功效：
（1）学生基础信息管理：学号、姓名、系别、班级等。
（2）课程基础信息管理：课程号码、课程名称、任课老师、学分、课时、课程内容介绍等。
（3）登陆管理：要求使用者提供正当用户名、密码和相关权限。
（4）成绩录入：由老师（管理员）录入成绩、要用到前面学生信息、课程信息等。
（5）成绩查询：学生进行成绩查询、要用到前面学生信息、课程信息等。
（6）汇总功效：系统管理员、教务处对成绩进行分类汇总，比较各个系院成绩，为制订以后教学管理计划提供数据基础。
3.1.4 数据流图
图1.总体数据流图

图2. 学生信息数据流图

图3. 成绩信息数据流图

图4.信息操作数据流图

图5.成绩操作结果数据流

四.项目任务分解
4.1 系统设计思想
采取现有资源，优异管理系统开发方案，充足利用学校现有资源和财力、物力、提升系统开发水平和应用效果。系统就满足学校需求，比如学生信息录入、查询、更新等。学生录入和排名。系统就含有数据库维护功效，立即依据用户需求进行数据添加、删除、修改等操作。
4.2 系统数据步骤图设计
其中系统关键业务步骤图图4-2所表示。

图4-2 系统步骤
此图是显示学生成绩信息管理系统对信息管理业务步骤图输入信息处理一个过程。
4.2.1 系统数据步骤图
顶层图图4-2-1所表示。

图4-2-1 数据步骤-
此图是学生成绩信息管理系统中管理员对系统中信息处理过程步骤图，经过此图能够大约了解本系统对学生成绩信处理过程。
信息管理图图4-2-2所表示。

图4-2-2 信息管理
此图是学生成绩管理系统中对学生成绩信管理图来对该系统中信息管理情况。
4.2.2 学生成绩管理系统描述
1.“学生成绩管理系统”关键分为浏览和后台管理两个子系统。
2.学生信息包含学生学号、姓名、地址、电话等信息。
3.老师信息包含老师姓名、帐号、地址、电话等信息。
4.教务员信息包含教务员姓名、帐号、地址、电话等信息。
5.成绩信息包含课程代号、学号及成绩。
6.课程信息包含课程名称、任课老师、课程类别、学分、学期等信息。
4.3 模块设计
1.用户登录模块：填写已分配用户名称，填写正确密码，进入主控制页面。
2.显示模块：显示要求内容。
3.查询模块：提供多个查询条件，可按需要进行查询。
4.录入模块：向数据库中添加统计。
5.修改模块：能够找到指定信息并对其进行修改。
6.删除模块：找到要删除统计，并将其删除。
五.项目估算
5.1 申明
项目规模估算使用Delphi法进行估算，具体步骤以下：
协调人向小组组员提供项目规格和估量表格；
协调人召集小组讨论和规模相关原因；
小组组员匿名填写迭代表格；
协调人整理出一个估量总结，以迭代表形式返回各组员；
协调人召集小组会，讨论较大估量差异；
组员复查估量总结并在迭代表上提交另一个匿名估量；
反复4-6， 直抵达成一个最低和最高估量一致。
附Delphi法规模估量迭代表。
Delphi法规模估量迭代表
项目名称：

估量日期：

估量者：

估量轮次：

结果：
代码行（LOC）

周期（月）

工作量（人月）

费用（元）

理由：

5.2 项目规模估算
经过小组内部讨论得出项目规模估算以下：
项目名称：《学生成绩管理系统》
规模估计：
代码行：15,000 LOC
周期：1 月
工作量：6 人月
费用：￥5530 元
5.3 项目成本估算
申明
因为包含到小组组员没有实际开发经验，在薪酬结算方面没有可供参考标准，所以在这里采取统一￥30.00 人天。
成本估算

任务名称
工时
成本估算
学生成绩管理系统
111 人天
￥5530.00
设备损耗
31 工作日
￥1000.00
需求讨论
2*2 人天
￥120.00
软件计划
6*2 人天
￥360.00
需求开发
6*4 人天
￥720.00
设计
4*4 人天
￥480.00
实施
6*13 人天
￥2340.00
测试
3*5 人天
￥450.00
布署
2*1 人天
￥60.00

六.进度计划
项目进度管理是指在项目实施过程中，对各阶段进展程度和项目最终完成期限所进行管理。是在要求时间内，确定出合理且经济进度计划（包含
多级管理子计划），在实施该计划过程中，常常要检验实际进度是否按计划要求进行，若出现偏差，便要立即找出原因，采取必需补救方法或调整、修改原计划，直至项目完成。其目标是确保项目能在满足其时间约束条件前提下实现其总体目标。
项目进度管理是依据工程项目标进度目标，编制经济合理进度计划，并据以检验工程项目进度计划实施情况，若发觉实际实施情况和计划进度不一致，就立即分析原因，并采取必需方法对原工程进度计划进行调整或修正过程。工程项目进度管理目标就是为了实现最优工期，多快好省地完成任务。
项目进度管理是项目管理一个关键方面，它和项目投资管理、项目质量管理等同为项目管理关键组成部分。它是确保项目准期完成或合理安排资源供给，节省工程成本关键方法之一。
6.1 项目进度
任务名称
起止时间
责任人
资源
工作量
需求讨论
.6.15-.6.16
张三
2开发人员参与
2人/天*2
项目计划
.6.17-
.6.18
李四
全体人员参与
6人/天*2
需求确定
.6.19-
.6.22
王五
全体人员参与
6人/天*4
设计
.6.23-
.6.26
张三
3开发人员参与
3人/天*4
项目实施
.6.27-
.7.9
王五
全体人员参与
6人/天*13
测试
.7.10-
.7.14
李四
3开发人员参与
3人/天*5
布署
.7.15
张三
2开发人员参与
2人/天*1
交付
.7.16
王五

6.2 甘特图

七.质量计划
7.1 项目测试
依据企业质量方针和质量目标，结合本项目特点,制订项目标总体质量目标：
1） 基于需求测试覆盖率为100%；
2）  软件功效测试用例经过率不低于95％；
3）  每个阶段评审中发觉问题全部已经处理或得到合适处理。
4）  产品公布时不存在严重及其以上缺点。

注：严重问题指造成系统或模块不能正常工作问题。

7.1.1 系统登录测试
测试方法是，输入不正确账号或密码，选择错误角色，看能否登录系统，确保系统安全性。如表5-6-1所表示。
表5-6-1 系统登录测试
测试事件
测试效果
输入错误账号
登录失败
输入错误密码
登录失败
选择角色错误
登录失败
输入正确账号密码选择正确角色
登录成功
测试结果：只有输入正确账号密码和选择正确角色才能登录系统。
7.1.2 学生成绩信息录入测试
测试方法是，信息漏输，看能否录入成功，以确保学生信息完整性。如表5-6-2 所表示。
表5-6-2 学生成绩信息录入测试
测试事件
测试效果
学号漏输
录入失败
姓名漏输
录入失败
课程号漏输
录入失败
课程名漏输
录入失败
分数漏输
录入失败
学分漏输
录入失败
专业漏输
录入失败
输入信息完整
录入成功
测试结果：输入完整信息，才能录入成功。
7.1.3 学生成绩查询测试
测试方法是输入错误学号，看能否查询成绩，以确保查询正确性。如表5-6-3所表示。
表5-3 学生成绩查询测试
测试事件
测试效果
输入错误学号
查询失败
输入正确学号
查询成功
测试结果：只有输入正确学号，才能查询学生成绩。
7.1.4 确定测试
它是检验软件功效和性能及其它特征是否和用户所合理期待要求一致。它又可称为有效性测试。它依据需求分析，使用黑盒法进行测试。
7.1.5系统测试
它是将一个已经过确定测试软件和计算机硬件、外设、一些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，进行
一系列整体、有效性测试。
7.1.6 故障对策
测试过程中故障推测：
测试中可能出现数据信息不能保留、 查询信息时候出现死机现象
方法：
1．信息不能保留原因可能是数据类型不一致
2．查询信息时候死机可能是查询方法不正确
7.1.7 测试结果评价
系统功效评价：此系统各模块全部能实现各自功效，符合学校对系统要求，系统
运行稳定。
结论：该系统可利用于实际当中。
7.2 系统维护
我们所开发学生成绩管理系统努力争取适应各大学院成绩管理，所以在开发上应含有通用性和可移植性，所以对系统要求很高。所以系统在维护上应做到可维护性强，在功效上含有可扩充性。为了便于功效扩充和修改，可对软件进行周期性维护，跟踪软件质量改变。为了改善软件可维护性，应逐步提升软件技术和工具。软件应采取模块化技术进行开发。模块开发时候，各个模块应该并行开发，以提升软件开发效率。系统在第一阶段开发时，备好软件系统文档，方便二次开发时候便于修改，并做好文档立即更新。
管理任务：其实测试工作和运行能够同时进行，运行关键看这个项目需要什么样运行方案进行支持。
质量确保任务：维护小组任务首先是确保对项目用户跟踪服务，其次是确保该项目其它开发人员从项目中立即解脱出来方便投入到下一个项目标开发中。所以通常项目维护小组组员关键由项目组少部分开发人员负担完成。她们不仅了解软件关键内容，而且和用户也不陌生，方便能够以最快速度修正错误。对于通常性错误，如操作不妥等引发问题，全部由维护小组实施完成，但需要用户测试确定上线。假如较大修改则需要走变更控制步骤，用户或维护人员填写变更申请，经教授会议讨论分析可行方案在由维护小组实施，经过测试后方可提交用户。
维护小组人员基础上是按项目跟进。当一个项目刚刚交付用户时，在维护小组有较多人员进行跟进，随软件稳定，跟进人逐步降低，并转移到其它项目中去。
基线产品：用户手册，操作手册，项目开发总结，维护统计。
7.3 SQA活动图

7.4 不符合性问题处理
1. 将不符合性问题写入审计汇报，并和项目经理一起协商加以处理（纠正方法、处理期限和复审时间），将不符合性问题、纠正方法等事宜写入SQA审计汇报，汇报给项目经理，并抄送SQA主管；
2. SQA组针对上述不符合性问题进行复审，验证不符合性问题是否得到纠正。假如全部问题已纠正，SQA组在审计汇报上签字确定，本过程结束；
3. 有些不符合性问题在不能和项目经理一起协商加以处理（特指不能和项目经理形成一致处理方案和期限；或项目经理不能提供相关证据证实SQA指出不符合性问题是错误），SQA组将不符合性问题及情况说明写入SQA审计汇报，汇报给开发部部门主管，并抄送SQA主管和项目经理；
4. SQA组针对上报给部门主管不符合性问题进行复审，验证不符合性问题是否得到纠正。假如全部问题已纠正，SQA组在审计汇报上签字确定，本过程结束；假如仍有问题没有处理，SQA组将没有处理不符合性问题及情况说明写入SQA审计汇报，上报给中央研究院院长，并抄送开发部部门主管、项目经理和SQA主管；
5. 追踪上报不符合性问题，直至不符合性问题处理；
6. SQA组依据不符合性问题严重程度，有权直接将审计汇报汇报给CTO；
7. 将审计汇报纳入项目SCM并提交到组织过程数据库中。
7.5统计搜集、维护和保留
项目组应该保留项目实施过程中形成各类文档、多种统计、各级周报、各级会议统计、对于项目中问题处理也需要形成统计保留。每七天由质量确保人员依据任务清单审计任务进行审计活动，并搜集各活动过程数据。
八．项目风险管理
8.1项目风险管理目标
风险是指在项目进行过程中可能发生事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。风险管理目标是在潜在问题发作以前就标志它们，这么就能够在生命周期中能够适时地计划和启用风险处理活动。
8.2项目风险管理组成

8.3 风险种类
分清风险种类有利于愈加好对项目进行风险管理。
8.3.1资源风险
1.组织
对该项目是否有足够支持（包含管理人员、测试员、QA 和其它外部相关各方）。
这是否是该组织尝试过最大项目。
软件工程是否有明确定义步骤？需求统计和管理。
2.资金
完成项目所需资金是否到位。
是否为培训和指导分配了资金。
是否有预算限制使得系统必需以固定成本交付，不然将被取消。
成本估算是否正确
3.人员
是否能够取得足够项目工作人员。
她们是否含有适宜技能和经验。
她们以前是否在一起工作过。
她们是否相信项目会成功。
是否能够找到用户代表来担任复审员。
是否能够找到领域教授。
4.时间
时间表制订得是否现实。
是否能够为了满足时间表而对功效进行规模管理。
对交付日期要求有多严格。
是否有时间“把工作做好”。
8.3.2 业务风险
假如竞争对手抢先将产品推向市场怎么办。
怎样确保有足够资金。
系统估计价值是否大于估计成本？（考虑货币时间价值和资金成本）。
假如无法同关键供给商签定协议怎么办。

8.3.3 技术风险
1.规模风险
成功是否能够被评测。
是否有相关怎样评测成功协议。
需求是否相当稳定并得到了充足了解。
项目规模是固定不变还是在不停扩展。
项目开发时间范围是否太短、不够灵活。
2.技术风险
技术是否已经过证实。
反复使用目标是否合理。
工件必需要使用一次后才能被反复使用。
构件可能要在若干次公布后才能变得稳定，以致无需重大变更即可复用。
需求中事务量是否合理。
事务比率估量值是否可靠？这些估量是否过于乐观。
数据量是否合理？目前可用框架是否能够保留这些数据，或，假如需求使您相信工作站或部门系统将成为设计一部分，那么是否能够在这些地方合理地保留数据。
是否有特殊或苛刻技术需求。
成功是否依靠于新或未经试验产品、服务或技术？是否依靠于新或未被证实硬件、软件或技术。
对于和其它系统（包含企业以外系统）接口是否存在外部依靠性？是否存在必需接口或必需创建它们 。
是否存在极不灵活可用性和安全性需求（比如“系统必需永远不出现故障”）。
系统用户是否对正在开发系统类型没有经验。
应用程序大小或复杂性，或技术新奇性是否造成了风险增加。
是否存在对国家语言支持需求。
是否可能设计、实施和运行该系统？一些系统只因为太大或太复杂而无法正常工作。
3.外部依靠性风险
该项目是否依靠于其它（平行）开发项目。
成功是否依靠于市售产品或外部开发构件。
成功是否依靠于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）成功集成。您是否有替换计划，能够在没有这些技术情况下交付项目。
8.3.4进度风险
功效是否无限追加。
计划是否过于乐观。
是否缺乏计划。
在压力下是否放弃计划。
是否追赶计划。
8.4 定义风险参数
风险参数可用于评定、分类和划分风险优先级；该项目将发生可能性等级划分为：很可能发生，可能发生，几乎不可能发生3个等级。将对项目标影响程度划分为：很严重影响，严重影响，中等影响，微弱影响4个等级。对应表格以下：

发生可能性
对项目标影响程度
名称
等级
名称
等级
很可能发生
3
很严重影响
4
可能发生
2
严重影响
3
几乎不可能发生
2
中等影响
2

微弱影响
1

8.5 风险管理策略
有三种关键策略：
*风险规避：使其不再受到该风险影响。
*风险转移：让其它方（用户、厂商、银行、其它主体等）负担该风险。
*风险接收：决定将该风险看成意外事件来接收。监测风险征兆，并制订应急计划，以确定在风险发生时将采取何种行动。
8.6 风险管理角色及职责
（1）项目经理
项目经理对风险管理工作负全部责任。
（2）项目组开发人员
项目组开发人员将被要求作为项目风险分析组组员，对项目工作中存在风险进行分析，并整理成书面材料。
（3）SQA
SQA经理将定时对风险管理工作开展情况进行评审，确保所开展风险管理工作符合组织要求。
8.7 学生成绩管理项目中风险识别
依据风险识别分类标准能够识别出学生成绩管理项目中存在风险，以下：
资源风险
完成该项目所需资金受到一定限制，人员培训指导资金不到位，存在一定资金风险；参与项目标部分人员没有一起工作过，也存在着一定人员风险；另外，交付日期严格要求造成项目存在时间风险。
业务风险
因为软件行业飞速发展，竞争对手可能抢先将产品推向市场，故存在着业务风险。
技术风险
用户可能随时提出需求和对项目标改善，需求不稳定性和项目规模不停扩展，可能造成项目存在规模风险。
进度风险
功效无限追加，在强大压力下放弃计划全部造成了项目标进度风险。
8.8 风险控制
1．控制方法
（1）风险管理计划
关键是制订一个计划，以处理在排位靠前高风险项。
风险管理计划每阶段/迭代重新评定一次。风险监控时选择风险管理计划中没相关闭前10大风险进行监控即可。每阶段/迭代开启时，选择“风险管理计划”中处于“监控”状态前10大风险，用于本阶段/迭代周例会上进行跟踪和监控（注意：周例会时只监控阶段/迭代开启时监控前10大风险）。
（2）风险化解
避免风险（即：不要做冒险活动）
将风险从系统一部分转移到另一部分（可能对于系统其它部分此风险不会发生或发生时影响不大）
购置相关风险信息（比如：做试验性项目，请咨询教授等）
消除风险根源
接收风险（假如风险后果较小，而处理它可能代价很大，滚动处理可能是最有效路径）
公布风险（将风险公布给相关涉众，如：管理者、市场人员、用户{尤其注意策略}等）
（3）控制风险
制订风险无法化解时“风险应急计划”
分配额外资源来处理风险
为处理风险留出额外时间
记住风险（为未来项目积累）
8.9 风险监控
周例会检验风险
在周工作例会上，项目经理需要跟踪项目标风险。
依据风险列表，逐一分析前10大风险，确定已经风险状态是否“发生”或“关闭”；
假如风险发生则开启“风险应急计划”或项目组协商处理措施，必需时PM请求相关高级管理者处理已发生风险，而且PM负责在风险管理计划中将此条风险标示为“发生”。
假如风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。
统计每项风险停留时间(周数)。