学生成绩管理系统软件项目管理大作业

《学生成绩管理系统》项目管理文档目录.合同管理 签订须知 需方合同环境 合同准备 合同签署 合同管理 合同终止过程 供方合同环境 合同准备 合同签署 合同管理 合同终止过程 内部环境 合同 .生存期 增量式模型 .需求管理 软件需求管理过程 软件需求说明书 可行性分析 对功能白^规定 数据流图 .项目任务分解 系统设计思想 系统数据流程图设计 系统数据流程图 学生成绩管理系统的描述 模块设计 .项目估算 声明 项目规模估算 项目成本估算 .进度方t划 项目进度 甘特图 .质量计划 项目测试 系统登录测试 学生成绩信息的录入测试 学生成绩的查询测试 确认测试 系统测试 故障对策 测试结果的评价 系统维护 SQA活动图 不符合性问题处理 记录的收集、维护和保存 .项目风险管理 项目风险管理的目的 项目风险管理的组成 风险的种类 资源风险 业务风险 技术风险 进度风险 定义风险参数 风险管理策略 风险管理角色及职责 学生成绩管理项目中风险的识别 风险的控制 风险监控 合同管理1.1签订须知该合同为某某局合同范本，原则上不得改动，如一定要进行修改，请附上《修改前后对比表》。为列入《修改前后对比表》的修改部分，视为恶意篡改，我局不予以承认。1.2需方合同环境.招标文件河北省教育部需要引入一套“学生成绩管理系统”应用程序，现向个大学进行公开招标，欢迎有资格的投标大学参加。一．招标项目名称：“学生成绩管理系统”应用软件二．招标内容：河北省学生“学生成绩管理系统”应用程序的设计，开发，安装、调试、使用教学及相应的后期维护升级。三．资质要求：具有省级政府项目投标资格的企业或个人，详细要求见投标须知（投标须知略）四．投标、开标有关说明：投标文件发售时间：2016年6月18日至2012年6月20日工作时间内投标文件发售地点：北京交通大学海滨学院投标文件售价：¥10,000 （售后不退，不接受邮购）投标地点：北京交通大学海滨学院报告厅投标截止时间：2016年6月30日北京时间10:00时开标时间：2016年7月1日北京时间14:00时开标地点：北京交通大学海滨学院报告厅五．有关规定：超过投标截止时间、不按规定密封的投标或不按《招标文件》规定提交有效足额投标保证金（以汇票、支票、现金支付）的投标，恕不接受。提交投标保证金户名：北京交通大学海滨学院财务处开户行：XX市渣打银行XXX路分行六．联络：北京交通大学海滨学院 详细地址：略联系人：略邮编：000000河北省教育部与北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院承担设计、开发、安装调试等一系列工作，内部部门人员配谿同软件企业相同， 借用大连理工大学之名而已。即北京交通大学海滨学院为供方）以河北省委省政府提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海滨学院全权负责软件的设计开发）.验收过程河北省教育部政府依据合同准备和合同签署时确定的需求资料及合同文本制定验收清单。对验收清单评审后制定验收计划，并按验收计划执行，得到验收报告。对发现的问题制定验收问题处理计划，最终确认验收报告。.违约事件处理过程在合同执行期内，如果合同双方河北省教育部政府或北京交通大学海滨学院有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约事件处理报告。河北省教育部政府与北京交通大学海滨学院根据合同及相关文档，发布合同终止通知、项目执行总结1.3供方合同环境合同准备.项目分析北京交通大学海滨学院根据招标书安排项目分析任务。经过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实施规划、初步实施规划评审，最终得到需求分析报告和项目初步规划。.竞标北京交通大学海滨学院按照需求分析报告和项目规划进行竞标，通过技术能力要求确定、人力资源要求确定、实现环境要求确定、资金管理要求确定、能力判定、评估结果审评等评定，并进行需求成熟度评估、用户支持保证评估、用户资金保证评估、可行性分析、项目决策、编写项目建议书等步骤，根据项目建议书参加竞标。合同签署河北省教育部政府与北京交通大学海滨学院（本文假设北京交通大学海滨学院投标成功，该项目由北京交通大学海滨学院下发至北京交通大学海滨学院软件学院承担设计、开发、安装调试等一系列工作， 内部部门人员配谿同软件企业相同， 借用大连理工大学之名而已。 即北京交通大学海滨学院为供方）以河北省委省政府提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有北京交通大学海滨学院全权负责软件的设计开发）合同管理合同执行跟踪管理过程北京交通大学海滨学院以项目计划为基础，进行项目计划审批和合同执行管理规划。按计划完成项目进展报告、合同责任落实、需求变更处理和产品验收。合同修改控制如果需方即河北省省教育部提出变更请求，假设提出的是要求添加不用登录网页直接通过“学生成绩管理系统”应用程序即可向网内用户发送邮件，并根据不同层级用户的权限显示网内在线用户。则北京交通大学海滨学院需依据合同和变更请求进行变更评估，并提出合同修改建议，确定修改策略。对当前计划进行调整，并需得出处理报告。违约事件处理过程在合同执行期内，如果合同双方河北省教育政府或北京交通大学海滨学院有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约事件处理报告。产品提交过程在产品的开发测试结束后向河北省教育部提交产品，经过审查后正式提交给河北省教育部政府。最终相方签字认可，通知相关各方。产品维护过程根据合同中的维护需求，制定维护需求记录。1.3.4合同终止过程河北省教育部政府与北京交通大学海滨学院根据合同及相关文档，发布合同终止通知、项目执行总结内部环境北京交通大学海滨学院内部确定任务范围，使相关各方有效的配合。合同合同双方甲方：河北省教育部乙方：北京交通大学海滨学院协议形式协议形式：技术合同供应的商品和服务供应的软件：乙方为甲方提供所需的“学生成绩管理系统”应用程序提供的服务：乙方为甲方提供所需的日常维护和服务器管理。同时对甲方用户提供使用教学。提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。安装服务： 乙方为甲方提供软件的安装。公文处理： 乙方负责将甲方提供的公文资料加载入系统并进行分类维护协议： 当甲方在使用该产品时，在正常操作的T青况下出现 BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。软件所有权该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。环境乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。客户承诺乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员主要参与项目的规划设计和需求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。验收规程2016年7月25日，乙方为甲方安装所需套数的软件。7月25日至7月31日甲方代表对产品进行验收测试，并根据需求在8月30日前对产品提出更正请求。测试通过后，双方带白哦进行软件交付签字。乙方对甲方进行软件使用培训。标准乙方在开发过程中必须遵守 ISO12207关于软件生命周期和文档的标准。项目和质量管理甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。价格和付款方式软件总价为230W合同签订后，甲方向乙方支付 50万元定金。项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付 80万元。该系统完成后，甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。其他法律要求由任何一方的过失导致出现损失后的赔偿由双方协商决定。二.生存期增量式模型如图1所示：理由如下：1）学生成绩管理系统的全部功能分成查询功能和添加功能两大类，因此可以先基于查询功能做出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。2）在学生成绩管理系统需求中，要求系统具有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。“系统要求有可扩充性，可以再现有系统的基础上，可以在增加其他功能模块” 也说明用户可能会增加新的需求。4）应该从最基础的应用做起，逐步扩充其应用，所以选用增量模型来学生成绩管理系统。5）本项目具备增量式模型的其他特点：项目复杂程度为中等；预计开发软件的成本为中等；产品和文档的再使用率会很高；项目风险较低。生存期中各阶段的定义如下：项目规划阶段阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。输入：合同文本、SOWM程：项目规划，计划确认 输出：项目计划需求分析阶段阶段目标：确定客户的需求 输入：项目计划，SOW过程：需求获取，需求分析，需求控制输出：原型系统，需求规格设计阶段阶段目标：总体系统结构设计 输入：原型系统，需求规格过程：总体设计输出：系统设计说明书、数据库结构定义 增量1实现阶段目标：实现系统的通用功能输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本 -1增量2实现阶段目标：实现系统的管理员模块管理功能输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本 -2增量3实现阶段目标：实现系统教师模块管理功能输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本 -3增量4实现阶段目标：实现系统的学生模块管理功能输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本 -4增量5实现阶段目标：实现系统的学生自助预约功能 输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本 -5集成测试阶段目标：通过集成环境下的系统测试输入：测试计划、测试案例过程：集成测试，系统测试输出：系统软件包，测试报告，产品说明书产品提交三.需求管理软件需求管理过程软件需求说明书随着在校大学生人数的不断增加，教务系统的数据量也不断的上涨。学校工作繁杂、资料重多，虽然各类管理信息系统已进入高校，但还未普及，而对于学生成绩管理来说，目前还没有一套完整的、统一的系统。因此，开发一套适和大众的、兼容性好的系统是很有必要的。可行性分析目前，随着办公信息化的开展，高校的扩招，新生入学以及期末考试结束后，学校都需要对一些繁琐的流程进行管理，通过一个基于 B/S架构的管理系统，可以很好的将这一个过程进行化繁为简。此项目具有普遍性，能够应用于很多学校。因此，该类型系统可以大量投入使用。对功能的规定课程从程序的结构中可以看出，学生的信息输入输出功能是由学生管理系统进行的。的输入输出是由课程管理系统进行的，而班级的信息流动则是班级管理系统进行的。课程学生成绩管理信息系统的几个基本功能：（1）学生的基本信息管理：学号、姓名、系别、班级等。（2）课程的基本信息管理：课程号码、课程名称、任课教师、学分、学时、课程内容简介等。（3）登陆管理：要求使用者提供合法的用户名、密码和相关权限。（4）成绩的录入：由老师（管理员）录入成绩、要用到前面的学生信息、课程的信息等。（5）成绩查询：学生进行成绩查询、要用到前面的学生信息、课程信息等。（6）汇总功能：系统管理员、教务处对成绩进行分类汇总，比较各个系院的成绩，为制定以后教学管理计划提供数据基础。数据流图图1.总体数据流图图2.学生信息数据流图图3.成绩信息数据流图图4.信息操作数据流图图5.成绩操作结果数据流四.项目任务分解系统设计思想采用现有的资源，先进的管理系统开发方案，充分利用学校现有的资源和财力、物力、提高系统开发的水平和应用效果。系统就满足学校的需求，例如学生信息的录入、查询、更新等。学生录入与排名。系统就具备数据库维护功能，及时根据用户需求进行数据添加、删除、修改等操作。系统数据流程图设计其中系统的主要业务流程图如图4-2所示。图4-2系统流程此图是显示学生成绩信息管理系统对信息管理的业务流程图输入信息处理的一个过程。系统数据流程图顶层图如图4-2-1所示。图4-2-1数据流程-此图是学生成绩信息管理系统中管理员对系统中信息的处理过程的流程图，通过此图可以大概了解本系统对学生成绩信的处理过程。信息管理图如图4-2-2所示。图4-2-2信息管理此图是学生成绩管理系统中对学生成绩信的管理图来对该系统中的信息管理情况。学生成绩管理系统的描述.“学生成绩管理系统”主要分为浏览和后台管理两个子系统。.学生信息包括学生的学号、姓名、地址、电话等的信息。.教师信息包括教师的姓名、帐号、地址、电话等的信息。.教务员信息包括教务员的姓名、帐号、地址、电话等的信息。.成绩信息包括课程代号、学号及成绩。.课程信息包括课程名称、任课教师、课程类别、学分、学期等信息。.3模块设计.用户登录模块：填写已分配的用户名称，填写正确的密码，进入主控制页面。.显示模块：显示要求的内容。.查询模块：提供多种查询条件，可按需要进行查询。.录入模块：向数据库中添加记录。.修改模块：可以找到指定信息并对其进行修改。.删除模块：找到要删除的记录，并将其删除。五.项目估算声明项目规模估算使用Delphi法进行估算，具体步骤如下：协调人向小组成员提供项目规格和估计表格；协调人召集小组讨论与规模相关的因素；小组成员匿名填写迭代表格；协调人整理出一个估计总结，以迭代表的形式返回各成员；协调人召集小组会，讨论较大的估计差异；成员复查估计总结并在迭代表上提交另一个匿名估计；重复4-6,直到达到一个最低和最高估计的一致。附Delphi法规模估计迭代表。Delphi法规模倩计迭代表项目名称：估计日期：估U若：估计轮次：结果：代码行（LO。周期（月）工作量（人月）

费用（元）理由：项目规模估算经过小组内部讨论得出项目规模估算如下:项目名称：《学生成绩管理系统》规模预测：代码行：15,000LOC周期：1月工作量：6人月费用：¥5530元项目成本估算声明由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准，因此在这里采用统一的¥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项目进度任务名称起止时间负责人资源工作量需求讨论-2016.6.16张三2开发人员参与2人/天*2项目规划2016.6.17-李四全体人员参与6人/天*2需求确定王五全体人员参与6人/天*4设计张三3开发人员参与3人/天*4项目实施2016.6.272016.7.9王五全体人员参与6人/天*13测试2016.7.10-李四3开发人员参与3人/天*5部署张三2开发人员参与2人/天*1交付王五6.2甘特图七.质量计划项目测试根据企业的质量方针和质量目标，结合本项目特点 ，制定项目的总体质量目标:基于需求的测t覆盖率为100%?软件功能测试用例通过率不低于 95%;?每个阶段评审中发现的问题都已经解决或得到适当处理。

?产品发布时不存在严重及其以上的缺陷。注：严重问题指导致系统或模块不能正常工作的问题。系统登录测试测试方法是，输入不正确的账号或密码， 选择错误的角色，看能否登录系统，确保系统的安全性。如表5-6-1所示。表5-6-1 系统登录测试测试事件测试效果输入错误账号登录失败输入错误密码登录失败选择角色错误登录失败输入正确账号密码选择正确角色登录成功测试结果：只有输入正确账号密码和选择正确角色才能登录系统。学生成绩信息的录入测试测试方法是，信息漏输，看能否录入成功，以确保学生信息的完整性。 如表5-6-2所示。表5-6-2 学生成绩信息的录入测试测试事件测试效果学号漏输录入失败姓名漏输录入失败课程号漏输录入失败课程名漏输录入失败分数漏输录入失败学分漏输录入失败专业漏输录入失败输入信息完整录入成功测试结果：输入完整的信息，才能录入成功。学生成绩的查询测试测试方法是输入错误的学号， 看能否查询成绩，以确保查询的正确性。如表5-6-3所示。表5-3学生成绩的查询测试测试事件测试效果输入错误学号查询失败输入正确学号查询成功测试结果：只有输入正确的学号，才能查询学生的成绩。确认测试它是检验软件的功能和性能及其他特性是否与用户所合理期待的要求一致。 它又可称为有效性测试。它依据需求分析，使用黑盒法进行测试。系统测试它是将一个已经过确认测试的软件与计算机的硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，进行一系列的整体、有效性的测试。故障对策测试过程中的故障推测：测试中可能出现数据信息不能保存、查询信息时候出现死机的现象措施：．信息不能保存的原因可能是数据类型不一致2．查询信息时候死机可能是查询方式不正确.1.7测试结果的评价系统功能评价：此系统各模块都能实现各自的功能，符合学校对系统的要求，系统运行稳定。结论：该系统可运用于实际当中。系统维护我们所开发的学生成绩管理系统力求适应各大学院的成绩管理，所以在开发上应具有通用性以及可移植性，所以对系统的要求很高。因此系统在维护上应做到可维护性强，在功能上具有可扩充性。为了便于功能扩充和修改，可对软件进行周期性的维护，跟踪软件的质量变化。为了改善软件的可维护性，应逐步提高软件的技术和工具。软件应采用模块化技术进行开发。模块开发时候，各个模块应该并行开发，以提高软件开发效率。系统在第一阶段开发的时，备好软件系统的文档，以便二次开发时候便于修改，并做好文档的及时更新。管理任务：其实测试工作和运营可以同时进行，运营主要看这个项目需要什么样的运营方案进行支持。质量保证任务：维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。基线产品：用户手册，操作手册，项目开发总结，维护记录。SQA活动图不符合性问题处理将不符合性问题写入审计报告，并与项目经理一起协商加以解决（纠正措施、解决期限和复审时间），将不符合性问题、纠正措施等事宜写入 SQA审计报告，报告给项目经理，并抄送SQA^管；SQAIa针对上述不符合性问题进行复审，验证不符合性问题是否得到纠正。如果所有问题已纠正，SQA组在审计报告上签字确认，本过程结束；有些不符合性问题在不能和项目经理一起协商加以解决的（特指不能与项目经理形成一致的解决方案和期限的；或项目经理不能提供相关证据证明 SQA旨出的不符合性问题是错误的），SQA组将不符合性问题及情况说明写入 SQA审计报告，报告给开发部部门主管，并抄送SQAfe管和项目经理；SQA组针对上报给部门主管的不符合性问题进行复审，验证不符合性问题是否得到纠正。如果所有问题已纠正， SQAfi在审计报告上签字确认，本过程结束；如果仍有问题没有解决，SQAfi将没有解决的不符合性问题及情况说明写入 SQA审计报告，上报给中央研究院院长，并抄送开发部部门主管、项目经理和 SQAfe管；追踪上报的不符合性问题，直至不符合性问题解决；SQA同根据不符合性问题的严重程度，有权直接将审计报告汇报给 CTQ将审计报告纳入项目SC所提交到组织的过程数据库中。7.5记录的收集、维护和保存项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录、对于项目中问题的处理也需要形成记录保存。每周由质量保证人员根据任务清单的审计任务进行审计活动，并收集各活动的过程数据。八．项目风险管理项目风险管理的目的风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。项目风险管理的组成风险的种类分清风险的种类有利于更好的对项目进行风险管理。资源风险组织对该项目是否有足够的支持（包括管理人员、测试员、QA和其他外部的相关各方）。这是否是该组织尝试过的最大项目。软件工程是否有明确定义的流程？需求记录和管理。资金完成项目所需的资金是否到位。是否为培训和指导分配了资金。是否有预算限制使得系统必须以固定的成本交付，否则将被取消。成本估算是否准确人员是否可以获得足够的项目工作人员。他们是否具备合适的技能和经验。他们以前是否在一起工作过。他们是否相信项目会成功。是否可以找到用户代表来担任复审员。是否可以找到领域专家。时间时间表制定得是否现实。是否可以为了满足时间表而对功能进行规模管理。对交付日期的要求有多严格。是否有时间“把工作做好”。业务风险如果竞争对手抢先将产品推向市场怎么办。如何确保有足够的资金。系统的预计价值是否大于预计成本？（考虑货币的时间价值和资金的成本）。如果无法同关键的供应商签定合同怎么办。技术风险.规模风险成功是否能够被评测。是否有关于如何评测成功的协议。需求是否相当稳定并得到了充分的了解。项目规模是固定不变还是在不断扩展。项目开发的时间范围是否太短、不够灵活。.技术风险技术是否已经过证明。重复使用目标是否合理。工件必须要使用一次后才能被重复使用。构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。需求中的事务量是否合理。事务比率的估计值是否可靠？这些估计是否过于乐观。数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据。是否有特殊或苛刻的技术需求。成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术。对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们。是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障” ）。系统的用户是否对正在开发的系统类型没有经验。应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加。是否存在对国家语言支持的需求。是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。.外部依赖性风险该项目是否依赖于其他（平行的）开发项目。成功是否依赖于市售产品或外部开发的构件。成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下交付项目。.3.4进度风险功能是否无限追加。计划是否过于乐观。是否缺乏计划。在压力下是否放弃计划。是否追赶计划。定义风险参数风险参数可用于评估、分类和划分风险的优先级；该项目将发生的可能性的等级划分为:非常可能发生，可能发生，几乎不可能发生3个级别。将对项目的影响程度划分为：非常严重影响，严重影响，中等影响，微弱影响4个级别。相应的表格如下：发生的可能性对项目的影响程度名称等级名称等级非常可能发生3非常严重影响4可