《学生成绩管理系统-软件项目管理大作业(共50页).docx》由会员分享，可在线阅读，更多相关《学生成绩管理系统-软件项目管理大作业(共50页).docx（50页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选优质文档-倾情为你奉上学生成绩管理系统-软件项目管理大作业专心-专注-专业学生成绩管理系统项目管理文档目录一.合同管理1.1签订须知 1. 该合同为某某局合同范本，原则上不得改动，如一定要进行修改，请附上修改前后对比表。为列入修改前后对比表的修改部分，视为恶意篡改，我局不予以承认。1.2 需方合同环境1.2.1合同准备1.招标文件 河北省教育部需要引入一套“学生成绩管理系统”应用程序，现向个大学进行公开招标，欢迎有资格的投标大学参加。 一招标项目名称：“学生成绩管理系统”应用软件 二招标内容：河北省学生“学生成绩管理系统”应用程序的设计，开发，安装、调试、使用教学及相应的后期维护升级。 三
2、资质要求：具有省级政府项目投标资格的企业或个人，详细要求见投标须知（投标须知略）四投标、开标有关说明： 1.投标文件发售时间：2016年6月18日至2012年6月20日工作时间内 2.投标文件发售地点：北京交通大学海滨学院 3.投标文件售价：￥10,000 （售后不退，不接受邮购） 4.投标地点：北京交通大学海滨学院报告厅 5.投标截止时间：2016年6月30日北京时间10:00时 6.开标时间：2016年7月1日北京时间14:00时 7.开标地点：北京交通大学海滨学院报告厅 五有关规定： 1.超过投标截止时间、不按规定密封的投标或不按招标文件规定提交有效足额投标保证金（以汇票、支票、现金支付
3、）的投标，恕不接受。 2.提交投标保证金户名：北京交通大学海滨学院财务处 3.开户行：XX市渣打银行XXX路分行 4.账号：2345 六联络： 北京交通大学海滨学院 详细地址：略 联系人：略 邮编： 电话：（02X） 传真：（02X） 1.2.2合同签署河北省教育部与北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院承担设计、开发、安装调试等一系列工作，内部部门人员配臵同软件企业相同，借用大连理工大学之名而已。即北京交通大学海滨学院为供方）以河北省委省政府提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、
4、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海滨学院全权负责软件的设计开发）1.2.3合同管理1.验收过程 河北省教育部政府依据合同准备和合同签署时确定的需求资料及合同文本制定验收清单。对验收清单评审后制定验收计划，并按验收计划执行，得到验收报告。对发现的问题制定验收问题处理计划，最终确认验收报告。 2.违约事件处理过程 在合同执行期内，如果合同双方河北省教育部政府或北京交通大学海滨学院有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约
5、事件处理报告。1.2.4合同终止过程河北省教育部政府与北京交通大学海滨学院根据合同及相关文档，发布合同终止通知、项目执行总结1.3供方合同环境1.3.1 合同准备1.项目分析 北京交通大学海滨学院根据招标书安排项目分析任务。经过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实施规划、初步实施规划评审，最终得到需求分析报告和项目初步规划。 2.竞标 北京交通大学海滨学院按照需求分析报告和项目规划进行竞标，通过技术能力要求确定、人力资源要求确定、实现环境要求确定、资金管理要求确定、能力判定、评估结果审评等评定，并进行需求成熟度评估、用户支持保证评估、用户资金保证评估、
6、可行性分析、项目决策、编写项目建议书等步骤，根据项目建议书参加竞标。1.3.2 合同签署河北省教育部政府与北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院承担设计、开发、安装调试等一系列工作，内部部门人员配臵同软件企业相同，借用大连理工大学之名而已。即北京交通大学海滨学院为供方）以河北省委省政府提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海
7、滨学院全权负责软件的设计开发）1.3.3 合同管理1.合同执行跟踪管理过程 北京交通大学海滨学院以项目计划为基础，进行项目计划审批和合同执行管理规划。按计划完成项目进展报告、合同责任落实、需求变更处理和产品验收。 2.合同修改控制 如果需方即河北省省教育部提出变更请求，假设提出的是要求添加不用登录网页直接通过“学生成绩管理系统”应用程序即可向网内用户发送邮件，并根据不同层级用户的权限显示网内在线用户。则北京交通大学海滨学院需依据合同和变更请求进行变更评估，并提出合同修改建议，确定修改策略。对当前计划进行调整，并需得出处理报告。 3.违约事件处理过程 在合同执行期内，如果合同双方河北省教育政府或
8、北京交通大学海滨学院有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约事件处理报告。4.产品提交过程 在产品的开发测试结束后向河北省教育部提交产品，经过审查后正式提交给河北省教育部政府。最终相方签字认可，通知相关各方。 5.产品维护过程 根据合同中的维护需求，制定维护需求记录。1.3.4 合同终止过程河北省教育部政府与北京交通大学海滨学院根据合同及相关文档，发布合同终止通知、项目执行总结1.4 内部环境 北京交通大学海滨学院内部确定任务范围，使相关各方有效的配合。 1.5 合同 1.合同双方 甲方：河北省教育部 乙方：北京交通大学海滨学院2.协议形式
9、 协议形式：技术合同 3.供应的商品和服务 供应的软件：乙方为甲方提供所需的“学生成绩管理系统”应用程序 提供的服务：乙方为甲方提供所需的日常维护和服务器管理。同时对甲方用户提供使用教学。 提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。 安装服务： 乙方为甲方提供软件的安装。 公文处理： 乙方负责将甲方提供的公文资料加载入系统并进行分类 维护协议： 当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部
10、分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。 4.软件所有权 该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。 5.环境 乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。 6.客户承诺 乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员主要参与项目的规划设计和需
11、求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。 7.验收规程 2016年7月25日，乙方为甲方安装所需套数的软件。7月25日至7月31日甲方代表对产品进行验收测试，并根据需求在8月30日前对产品提出更正请求。测试通过后，双方带白哦进行软件交付签字。乙方对甲方进行软件使用培训。 8.标准 乙方在开发过程中必须遵守ISO 12207关于软件生命周期和文档的标准。 9.项目和质量管理 甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。甲方根据演
12、示提出相应的整改意见，并对下一步工作进行提出意见和建议。 10.价格和付款方式 软件总价为230W。合同签订后，甲方向乙方支付50万元定金。项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付80万元。该系统完成后，甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。11.其他法律要求 由任何一方的过失导致出现损失后的赔偿由双方协商决定。二.生存期2.1 增量式模型如图1所示：理由如下： 1）学生成绩管理系统的全部功能分成查询功能和添加功能两大类，因此可以先基于查询功能做出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小
13、版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2）在学生成绩管理系统需求中，要求系统具有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。 3）“系统要求有可扩充性，可以再现有系统的基础上，可以在增加其他功能模块”-也说明用户可能会增加新的需求。 4）应该从最基础的应用做起，逐步扩充其应用，所以选用增量模型来学生成绩管理系统。 5）本项目具备增量式模型的其他特点
14、：项目复杂程度为中等；预计开发软件的成本为中等；产品和文档的再使用率会很高；项目风险较低。生存期中各阶段的定义如下：项目规划阶段 阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。输入：合同文本、SOW 过程：项目规划，计划确认 输出：项目计划 需求分析阶段 阶段目标：确定客户的需求 输入：项目计划，SOW 过程：需求获取，需求分析，需求控制 输出：原型系统，需求规格 设计阶段 阶段目标：总体系统结构设计 输入：原型系统，需求规格 过程：总体设计 输出：系统设计说明书、数据库结构定义 增量1实现 阶段目标：实现系统的通用功能 输入：系统设计说明书、数据库结构定义 过程：详细
15、设计，编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本-1 增量2实现 阶段目标：实现系统的管理员模块管理功能 输入：系统设计说明书、数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本-2 增量3实现 阶段目标：实现系统教师模块管理功能 输入：系统设计说明书、数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本-3 增量4实现 阶段目标：实现系统的学生模块管理功能 输入：系统设计说明书、数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试
16、输出：详细设计说明书，源代码，可运行版本-4 增量5实现 阶段目标：实现系统的学生自助预约功能 输入：系统设计说明书、数据库结构定义 过程：详细设计，编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本-5 集成测试 阶段目标：通过集成环境下的系统测试 输入：测试计划、测试案例 过程：集成测试，系统测试 输出：系统软件包，测试报告，产品说明书 产品提交三.需求管理3.1 软件需求管理过程3.1.1 软件需求说明书 随着在校大学生人数的不断增加，教务系统的数据量也不断的上涨。学校工作繁杂、资料重多，虽然各类管理信息系统已进入高校，但还未普及，而对于学生成绩管理来说，目前还
17、没有一套完整的、统一的系统。因此，开发一套适和大众的、兼容性好的系统是很有必要的。3.1.2 可行性分析目前，随着办公信息化的开展，高校的扩招，新生入学以及期末考试结束后，学校都需要对一些繁琐的流程进行管理，通过一个基于B/S架构的管理系统，可以很好的将这一个过程进行化繁为简。此项目具有普遍性，能够应用于很多学校。因此，该类型系统可以大量投入使用。3.1.3 对功能的规定 从程序的结构中可以看出，学生的信息输入输出功能是由学生管理系统进行的。课程的输入输出是由课程管理系统进行的，而班级的信息流动则是班级管理系统进行的。学生成绩管理信息系统的几个基本功能： （1）学生的基本信息管理：学号、姓名、
18、系别、班级等。 （2）课程的基本信息管理：课程号码、课程名称、任课教师、学分、学时、课程内容简介等。 （3）登陆管理：要求使用者提供合法的用户名、密码和相关权限。 （4）成绩的录入：由老师（管理员）录入成绩、要用到前面的学生信息、课程的信息等。 （5）成绩查询：学生进行成绩查询、要用到前面的学生信息、课程信息等。 （6）汇总功能：系统管理员、教务处对成绩进行分类汇总，比较各个系院的成绩，为制定以后教学管理计划提供数据基础。3.1.4 数据流图 图1.总体数据流图 图2. 学生信息数据流图 图3. 成绩信息数据流图图4.信息操作数据流图图5.成绩操作结果数据流四.项目任务分解4.1 系统设计思想
19、采用现有的资源，先进的管理系统开发方案，充分利用学校现有的资源和财力、物力、提高系统开发的水平和应用效果。系统就满足学校的需求，例如学生信息的录入、查询、更新等。学生录入与排名。系统就具备数据库维护功能，及时根据用户需求进行数据添加、删除、修改等操作。4.2 系统数据流程图设计 其中系统的主要业务流程图如图4-2所示。 图4-2 系统流程此图是显示学生成绩信息管理系统对信息管理的业务流程图输入信息处理的一个过程。4.2.1 系统数据流程图顶层图如图4-2-1所示。图4-2-1 数据流程-此图是学生成绩信息管理系统中管理员对系统中信息的处理过程的流程图，通过此图可以大概了解本系统对学生成绩信的处
20、理过程。信息管理图如图4-2-2所示。图4-2-2 信息管理此图是学生成绩管理系统中对学生成绩信的管理图来对该系统中的信息管理情况。4.2.2 学生成绩管理系统的描述1.“学生成绩管理系统”主要分为浏览和后台管理两个子系统。 2.学生信息包括学生的学号、姓名、地址、电话等的信息。 3.教师信息包括教师的姓名、帐号、地址、电话等的信息。 4.教务员信息包括教务员的姓名、帐号、地址、电话等的信息。 5.成绩信息包括课程代号、学号及成绩。 6.课程信息包括课程名称、任课教师、课程类别、学分、学期等信息。4.3 模块设计1.用户登录模块：填写已分配的用户名称，填写正确的密码，进入主控制页面。 2.显示
21、模块：显示要求的内容。 3.查询模块：提供多种查询条件，可按需要进行查询。 4.录入模块：向数据库中添加记录。 5.修改模块：可以找到指定信息并对其进行修改。 6.删除模块：找到要删除的记录，并将其删除。五.项目估算5.1 声明项目规模估算使用Delphi法进行估算，具体步骤如下：协调人向小组成员提供项目规格和估计表格；协调人召集小组讨论与规模相关的因素；小组成员匿名填写迭代表格；协调人整理出一个估计总结，以迭代表的形式返回各成员；协调人召集小组会，讨论较大的估计差异；成员复查估计总结并在迭代表上提交另一个匿名估计；重复4-6， 直到达到一个最低和最高估计的一致。附Delphi法规模估计迭代表
22、。Delphi法规模估计迭代表项目名称：估计日期：估计者：估计轮次：结果：代码行（LOC）周期（月）工作量（人月）费用（元）理由：5.2 项目规模估算经过小组内部讨论得出项目规模估算如下：项目名称：学生成绩管理系统规模预测： 代码行：15,000 LOC 周期：1 月 工作量：6 人月 费用：￥5530 元5.3 项目成本估算声明 由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准，因此在这里采用统一的￥30.00 人天。成本估算任务名称工时成本估算学生成绩管理系统111 人天￥5530.00设备损耗31 工作日￥1000.00 需求讨论2*2 人天￥120.00 软件规
23、划6*2 人天￥360.00 需求开发6*4 人天￥720.00 设计4*4 人天￥480.00 实施6*13 人天￥2340.00 测试3*5 人天￥450.00 部署2*1 人天￥60.00六.进度计划项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。是在规定的时间内，拟定出合理且经济的进度计划（包括多级管理的子计划），在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。 项目进度管理是根据工程项目的进度
24、目标，编制经济合理的进度计划，并据以检查工程项目进度计划的执行情况，若发现实际执行情况与计划进度不一致，就及时分析原因，并采取必要的措施对原工程进度计划进行调整或修正的过程。工程项目进度管理的目的就是为了实现最优工期，多快好省地完成任务。 项目进度管理是项目管理的一个重要方面，它与项目投资管理、项目质量管理等同为项目管理的重要组成部分。它是保证项目如期完成或合理安排资源供应，节约工程成本的重要措施之一。6.1 项目进度任务名称起止时间负责人资源工作量需求讨论2016.6.15-2016.6.16张三2开发人员参与2人/天*2项目规划2016.6.17-2016.6.18李四全体人员参与6人/天
25、*2需求确定2016.6.19-2016.6.22王五全体人员参与6人/天*4设计2016.6.23-2016.6.26张三3开发人员参与3人/天*4项目实施2016.6.27-2016.7.9王五全体人员参与6人/天*13测试2016.7.10-2016.7.14李四3开发人员参与3人/天*5部署2016.7.15张三2开发人员参与2人/天*1交付2016.7.16王五6.2 甘特图七.质量计划7.1 项目测试根据企业的质量方针和质量目标，结合本项目特点,制定项目的总体质量目标：1） 基于需求的测试覆盖率为100%；2） 软件功能测试用例通过率不低于95；3） 每个阶段评审中发现的问题都已经
26、解决或得到适当处理。4） 产品发布时不存在严重及其以上的缺陷。注：严重问题指导致系统或模块不能正常工作的问题。7.1.1 系统登录测试测试方法是，输入不正确的账号或密码，选择错误的角色，看能否登录系统，确保系统的安全性。如表5-6-1所示。 表5-6-1 系统登录测试测试事件测试效果输入错误账号登录失败输入错误密码登录失败选择角色错误登录失败输入正确账号密码选择正确角色登录成功测试结果：只有输入正确账号密码和选择正确角色才能登录系统。7.1.2 学生成绩信息的录入测试 测试方法是，信息漏输，看能否录入成功，以确保学生信息的完整性。如表5-6-2 所示。 表5-6-2 学生成绩信息的录入测试测试
27、事件测试效果学号漏输录入失败姓名漏输录入失败课程号漏输录入失败课程名漏输录入失败分数漏输录入失败学分漏输录入失败专业漏输录入失败输入信息完整录入成功测试结果：输入完整的信息，才能录入成功。 7.1.3 学生成绩的查询测试 测试方法是输入错误的学号，看能否查询成绩，以确保查询的正确性。如表5-6-3所示。 表5-3 学生成绩的查询测试测试事件测试效果输入错误学号查询失败输入正确学号查询成功测试结果：只有输入正确的学号，才能查询学生的成绩。7.1.4 确认测试它是检验软件的功能和性能及其他特性是否与用户所合理期待的要求一致。它又可称为有效性测试。它依据需求分析，使用黑盒法进行测试。7.1.5系统测
28、试 它是将一个已经过确认测试的软件与计算机的硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，进行 一系列的整体、有效性的测试。7.1.6 故障对策 测试过程中的故障推测： 测试中可能出现数据信息不能保存、 查询信息时候出现死机的现象 措施： 1信息不能保存的原因可能是数据类型不一致 2查询信息时候死机可能是查询方式不正确7.1.7 测试结果的评价系统功能评价：此系统各模块都能实现各自的功能，符合学校对系统的要求，系统运行稳定。 结论：该系统可运用于实际当中。7.2 系统维护 我们所开发的学生成绩管理系统力求适应各大学院的成绩管理，所以在开发上应具有通用性以及可移
29、植性，所以对系统的要求很高。因此系统在维护上应做到可维护性强，在功能上具有可扩充性。为了便于功能扩充和修改，可对软件进行周期性的维护，跟踪软件的质量变化。为了改善软件的可维护性，应逐步提高软件的技术和工具。软件应采用模块化技术进行开发。模块开发时候，各个模块应该并行开发，以提高软件开发效率。系统在第一阶段开发的时，备好软件系统的文档，以便二次开发时候便于修改，并做好文档的及时更新。管理任务：其实测试工作和运营可以同时进行，运营主要看这个项目需要什么样的运营方案进行支持。质量保证任务：维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入
30、到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。 维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。基线产品：用户手册，操作手册，项目开发总结，维护记录。7.3 S
31、QA活动图7.4 不符合性问题处理1.将不符合性问题写入审计报告，并与项目经理一起协商加以解决（纠正措施、解决期限和复审时间），将不符合性问题、纠正措施等事宜写入SQA审计报告，报告给项目经理，并抄送SQA主管；2.SQA组针对上述不符合性问题进行复审，验证不符合性问题是否得到纠正。如果所有问题已纠正，SQA组在审计报告上签字确认，本过程结束；3.有些不符合性问题在不能和项目经理一起协商加以解决的（特指不能与项目经理形成一致的解决方案和期限的；或项目经理不能提供相关证据证明SQA指出的不符合性问题是错误的），SQA组将不符合性问题及情况说明写入SQA审计报告，报告给开发部部门主管，并抄送SQA
32、主管和项目经理；4.SQA组针对上报给部门主管的不符合性问题进行复审，验证不符合性问题是否得到纠正。如果所有问题已纠正，SQA组在审计报告上签字确认，本过程结束；如果仍有问题没有解决，SQA组将没有解决的不符合性问题及情况说明写入SQA审计报告，上报给中央研究院院长，并抄送开发部部门主管、项目经理和SQA主管；5.追踪上报的不符合性问题，直至不符合性问题解决；6.SQA组根据不符合性问题的严重程度，有权直接将审计报告汇报给CTO；7.将审计报告纳入项目SCM并提交到组织的过程数据库中。7.5记录的收集、维护和保存项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录、对于
33、项目中问题的处理也需要形成记录保存。每周由质量保证人员根据任务清单的审计任务进行审计活动，并收集各活动的过程数据。八项目风险管理8.1项目风险管理的目的风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。8.2项目风险管理的组成8.3 风险的种类分清风险的种类有利于更好的对项目进行风险管理。8.3.1资源风险1.组织对该项目是否有足够的支持（包括管理人员、测试员、QA 和其他外部的相关各方）。 这是否是该组织尝试过的最大项目。 软件工程是否有明确定
34、义的流程？需求记录和管理。2.资金完成项目所需的资金是否到位。是否为培训和指导分配了资金。 是否有预算限制使得系统必须以固定的成本交付，否则将被取消。 成本估算是否准确3.人员是否可以获得足够的项目工作人员。 他们是否具备合适的技能和经验。 他们以前是否在一起工作过。他们是否相信项目会成功。 是否可以找到用户代表来担任复审员。 是否可以找到领域专家。 4.时间时间表制定得是否现实。 是否可以为了满足时间表而对功能进行规模管理。 对交付日期的要求有多严格。 是否有时间“把工作做好”。8.3.2 业务风险如果竞争对手抢先将产品推向市场怎么办。 如何确保有足够的资金。系统的预计价值是否大于预计成本？
35、（考虑货币的时间价值和资金的成本）。 如果无法同关键的供应商签定合同怎么办。8.3.3 技术风险1.规模风险成功是否能够被评测。是否有关于如何评测成功的协议。需求是否相当稳定并得到了充分的了解。项目规模是固定不变还是在不断扩展。项目开发的时间范围是否太短、不够灵活。2.技术风险技术是否已经过证明。重复使用目标是否合理。工件必须要使用一次后才能被重复使用。 构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。 需求中的事务量是否合理。事务比率的估计值是否可靠？这些估计是否过于乐观。数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一
36、部分，那么是否能够在这些地方合理地保存数据。 是否有特殊或苛刻的技术需求。成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术。对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们 。是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障”）。系统的用户是否对正在开发的系统类型没有经验。 应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加。是否存在对国家语言支持的需求。是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。 3.外部依赖性风险该项目是否依赖于其他（平行的）开
37、发项目。成功是否依赖于市售产品或外部开发的构件。成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下交付项目。8.3.4进度风险功能是否无限追加。计划是否过于乐观。是否缺乏计划。在压力下是否放弃计划。是否追赶计划。8.4 定义风险参数风险参数可用于评估、分类和划分风险的优先级；该项目将发生的可能性的等级划分为：非常可能发生，可能发生，几乎不可能发生3个级别。将对项目的影响程度划分为：非常严重影响，严重影响，中等影响，微弱影响4个级别。相应的表格如下：发生的可能性对项目的影响程度名称等级名称等级非常可
38、能发生3非常严重影响4可能发生2严重影响3几乎不可能发生2中等影响2微弱影响18.5 风险管理策略有三种主要的策略：*风险规避：使其不再受到该风险的影响。 *风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。*风险接受：决定将该风险当作意外事件来接受。监测风险征兆，并制定应急计划，以确定在风险发生时将采取何种行动。8.6 风险管理角色及职责（1）项目经理项目经理对风险管理工作负全部责任。（2）项目组开发人员项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并整理成书面材料。（3）SQASQA经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理
39、工作符合组织的要求。8.7 学生成绩管理项目中风险的识别根据风险识别的分类标准可以识别出学生成绩管理项目中存在的风险，如下：资源风险完成该项目所需的资金受到一定的限制，人员的培训指导资金不到位，存在一定资金风险；参与项目的部分人员没有一起工作过，也存在着一定的人员风险；此外，交付日期的严格要求导致项目存在时间风险。业务风险由于软件行业的飞速发展，竞争对手可能抢先将产品推向市场，故存在着业务风险。技术风险客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风险。进度风险功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。8.8 风险的控制1控制方
40、法（1）风险管理计划重点是制定一个计划，以处理在排位靠前的高风险项。风险管理计划每阶段/迭代重新评估一次。风险监控时选取风险管理计划中没有关闭的前10大风险进行监控即可。每阶段/迭代启动时，选取“风险管理计划”中处于“监控”状态的前10大风险，用于本阶段/迭代的周例会上进行跟踪和监控（注意：周例会时只监控阶段/迭代启动时监控的前10大风险）。（2）风险的化解避免风险（即：不要做冒险的活动）将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）购买关于风险的信息（例如：做实验性项目，请咨询专家等）消除风险的根源接受风险（如果风险后果较小，而处理它可能代价很大，
41、滚动处理可能是最有效的途径）发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户特别注意策略等）（3）控制风险制定风险无法化解时的“风险应急计划”分配额外的资源来处理风险为处理风险留出额外的时间记住风险（为将来的项目积累）8.9 风险监控周例会检查风险在周工作例会上，项目经理需要跟踪项目的风险。根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。统计每项风险的停留时间(周数)。