软件需求分析案例资料

《高校课程调度系统》 软件需求规格说明书

a.引言

a. 1目的

高校教务管理工作是高等教育中的一个极为重要的环节,是整个院校管理的核心和基础。面对种类繁多的数据和报表，面对手工处理方式已经很难跟上现代化管理的步伐。随着计算机及通讯技术的飞速发展，高等教育对教务管理工作提出了更高的要求。尽快改变传统的管理模式，运用现代化手段进行科学管理，已经成为整个教育系统亟待解决的课题之一。

根据全国高校教学管理软件市场的需求，开发完成教学管理系统尤其是课程调度管理系统迫在眉睫，为计算机管理课程调度工作提供全面的解决方案。

a. 2预期的读者和阅读建议

本需求分析说明书适用于该项目客户、业务或需求分析人员，用户文档编写者，项目管理人员，项目产品开发人员，产品测试人员，技术支持人员。

a. 3产品的范围

高校课程调度系统，是一个集先进的关系和文档数据库技术、多媒体技术于一身的课程调度管理系统的解决方案。

本系统结构清晰、自动化程度高、运行速度快、用户界面友好、课程调度工作味道浓厚、使用灵活方便，可大大提高高校教务管理部门的工作效率，规范各类课程调度管理工作的业务流程。

本系统适合各类高等院校的各级教学、教辅管理部门使用（包括：教育处、教研科、教务科、基础课程科等），也适用于各类中专及职业技术学校。

a. 4参考文献

《普通高等学校本科专业设置规定》、

《教育部关于高等学校学籍方面一些名称的提法》、

《湖南省教委关于普通高等学校教学管理制度和学生学籍管理有关问题的暂行规定》、

《教学一览》、

1

《课程编号一览》、 《软件工程》、

《 计算机系统导论》、 《 数据库原理与方法》、 《 SoftWare Requirement 》

b.综合描述

b. 1产品的前景

各级教学管理部门作为各个高等学府的一个重要职能部门，管理、制定、执行与学校头等大事——教学工作有关的各项工作及政策。其中，教学计划的实施是一个重要的环节。每学期管理人员都要制定、整理教学计划，根据教学计划下达教学任务书，然后根据教学任务书编排课程表。在这些课程调度工作中，既有大量繁琐的数据整理工作，也有严谨思维的脑力劳动。此外，还有种类繁多的数据和报表。为了提高教学管理部门的工作效率，其管理工作的计算机化已刻不容缓。

通过大量的调查研究发现，目前，教学管理部门的管理模式存在以下主要问题：

业务流程不规范

数据资料分散、重复、易遗漏 数据信息不全面 数据查询困难

统计、排课工作耗时、费力、不准确等 针对目前存在的各种问题，使我们意识到，必需通过计算机管理辅助教学管理部门日常工作，优化管理模式，才能达到业务流程规范化、业务数值化、资料数据库化以及决策模拟化的管理水准。为此，研制和开发高校课程调度系统已刻不容缓，具有广泛的使用和推广前景。

b. 2产品的功能

功能表述图：

2

基础数据库

教务管理 院系数据 教师数据 课程数据 专业数据 学生班级数据 教室数据 教学计划管理 教学任务管理 时间片管理 排课预处理 高校课程 调度 系统

课程调度管理 教学管理 排课管理 教室分配 查询修订课表 检验课表 课表数据拷贝 课表生成 课表打印 生成课表网页 b. 3用户类和特征

“高校课程调度系统”的用户类

课务管理员管理着全校的教学任务以及排课工作。他们是排课管理的唯一使用者，将处理来自教务管理员的时间约束并提供完全课表；向教室管理

课务管理员

员请求排课可用教室并提供教室的课表清单；获取任课教师的任课课程和可用时间并提供教师的个人课表。 教务管理员是教务科科长甚至教育处处长。他们使用系统是为了获得符合学校教学管理、安排的完全课表，进行宏观管理、保证教学工作正常开展。

教务管理员

教务管理员提供学校统一的时间要求。教务管理员需要在生成的课表中得到一系列课表，包括总课表，班级、教师、教室课表，并进行修订。 教室管理员将使用系统来查询所管辖教室的课表。教室管理员提供上课可

教室管理员 用的教室类型、教室数量、以及教室的名称和容纳人数。教室管理员需要

在生成的课表中查找每间教室的使用时间以及班级。

任课教师将使用系统来查询个人的上课课表。任课教师提供自己本学期可上的课程和可用的排课时间做为教学任务的一部分。任课教师需要在生成的课表中查找自己上课的课程、班级、时间以及教室。

任课教师

3

b. 4运行环境

硬件平台：Pentium以上PC；内存16M及以上；

VGA及以上显示器；

Microsoft鼠标或其它兼容鼠标； Windows支持的各种打印机。

操作系统： Windows Win98/XP/2000 数据库系统： SQL Server等常用数据库

b. 5设计和实现上的限制

所使用的设计符号表示必须符合高等学校教学管理的规范。

b.6假设和依赖

本软件在开发的过程中，分为技术实现与软件工程两大部分，两部分都有侧重点，若技术支持出现故障或疑难问题无法解决、程序开发出现偏差，会延误工程进度，影响工程的按期完工。若软件工程陈述出现问题，部分描述含混不清，则会影响系统的完整性与可继承性。在管理方面，如管理者没有预见性，对出向的问题无法采用可行的解决手段，都会影响开发模块之间的互动，从而影响工程的顺利开展，导致工程无法按期完工。

c.外部接口需求

c. 1用户界面

根据高校课程调度系统的特点，用户界面采用桌面应用程序方式实现。

c.2硬件接口

硬件环境是高校课程调度系统运行的物质基础，它必须有较高的性能，必须是稳定可靠的，同时还应该是可以扩充的。

c.3软件接口

计算机信息系统之间的信息交换，除了有硬件要求之外，还必须遵守共同的软件接口标准。高校课程调度系统必须能够提供数据转换接口。

高校课程调度系统的软件接口由WINDOWS操作系统（Windows 98/Windwos 2000/Windows XP）、SQL Server组成。

4

c.4通信接口

本产品的没有特殊的通讯接口，通讯接口由所使用的PC机决定。

d.系统特性

d. 1排课管理

1．说明和优先级

排课的优先级为高。要求将学校的课表按教学任务无冲突的排好，并尽量满足课元组提出的特殊请求（如：教室请求、排课时间请求等）。但是，不保证是最优方案。

2．激励/响应序列

读取教学计划生成教学任务，进行排课预处理。 输入或修改教学任务，进行排课预处理。

输入任课教师和上课班级的特殊时间请求，分配上课时间。 输入开设课程的特殊教室请求，分配上课教室。 3．功能需求

? 管理排课时间片：管理影响排课的各种时间片，包括本学期排课周数、

每周排课天数、每天排课节数、排课开始节次、班级可用时间、任课教师可用时间、排课时间模式等

? 排课预处理：读取教学任务及排课时间片，进行数据处理，优先为在教

学任务中提出特殊请求的课元组分配时间

? 教室分配：为排课预处理后的课元组分配教室，优先为在教学任务中提

出特殊请求的课元组分配教室

? 修订、检验课表：对在排课处理里中发生的冲突（时间冲突、教室冲突）

进行修订，校正至没有冲突及空缺。 ? 生成课表

d.2按分类打印课表管理

1．说明和优先级

按分类打印课表的优先级为中。要求将排好的课表按各种用户的要求分类打印，满足不同的用途。 2．激励/响应序列

输入院系、专业、班级，打印总课表。 输入任课教师姓名，打印教师课表。 输入教室编号，打印教室课表。 3．功能需求

? 打印总课表：打印学校的总课表，内容包括所在院系、所在专业的所有

班级的上课课程、任课教师、上课时间、上课的教室。

5

? 打印教师课表：打印每位任课教师的个人课表，内容包括教师所上的课

程、上课班级、上课时间和上课的教室。

? 打印教室课表：打印每间教室的教室课表，内容包括教室使用的时间、

所上的课程和上课班级。

d.3课表查询

1．说明和优先级

课表查查询的优先级为低。只要能够在系统中查询、能拷贝课表数据、能在网上查询。 2．功能需求

? 课表查询：使用本系统按不同的条件查询课表（如：按班级、课程、教

师、教室等）

? 课表数据拷贝：将生成的课表文件拷贝到其他安装该系统的计算机上进

行查询

? 生成课表网页：在生成课表的同时生成按教师分类的课表网页，供用户

及其他人员（院系领导、学生）查询课表。

e.其它非功能需求

e.1性能需求

高校课程调度系统性能需求见下表：

精度 在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数时，要求输入数准确。 a. 响应时间应在人的感觉和视觉事件范围内； b. 更新处理时间，随着系统的版本升级，课程调度系统将相应的进行更新。 当需求发生某些变化时，课程调度系统软件操作方式、数据结构、运行环境基本不会发生变化，变化只是将对应的数据库文件内的记录改变，或将筛选条件改变即可。 时间特性 灵活性 本系统数据库的管理能力取决于SQL server对数据的管理能力，SQL Server是一个较成熟的大型数据库系统，能满足本数据管理能力 Microsoft 系统的要求。 故障处理 故障几率小，排除简单（只需拷贝动态库文件，不需重新安装）。 6

e.2安全性需求

? 保证应用系统信息安全。

? 防止内部机密或敏感信息的泄漏以及外部不良信息的侵入。

? 提供必要的冗余和备份措施。当系统发生故障时能够立即恢复，保证系

统可靠运行；系统备份、数据库备份：定时后备，快速恢复。

e.3软件质量属性

? 可靠性：由于软件失效引起排课出错的概率应不超过5‰ 。

? 健壮性：所有的排课参数都要指定一个缺省值，当输入数据丢失或无效

时，就使用缺省值数据。 ? 可用性：在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Alt

键和其它键组合实现的。

e.4业务规则

? ? ? ? ?

只有在输入了教学计划之后，才能在新建教学任务时读取教学计划。 只有在输入了教学任务之后，才能进行排课。 只有在设置了时间片之后，才能进行排课。 排课时，要同时安排任课教师和上课教室。

使一周的课程尽量均匀分布到每天，不能有班级出现有一天或半天完全没有课。

e.5用户文档

编号：1

《高校课程调度系统软件需求规格说明书》 编号：2

《系统分析模型》 编号：3

《数据字典》 编号：4

《风险管理计划》 编号：5

《概念测试用例》 编号：6

《变更控制的过程》

7

系统分析模型

顶层图:

教 务管理员

课务管理员 完教全学课任表务 时间片约束

高校教室信息

教课程调 室管完全课表

度系统 教室课表

理员 任可个课用人课时课程间表 任课教师 8

0层图：

课务管理员 课程信息 基础 数据 任课教师 任课课程 教务管理员 上课周、天数 开课班级 可用时间 日上课节数 上班课级节时次间 教学计划 教室管理员 教学楼信息 1 下达教学任务 教学任务信息完全课表 教室名称 容教纳室人类数型 教室课表 个人课表 3 排课时间管理 排课时间信息完全课表 2 提供教室信息 教室数据 教学任务 教学任务 时间约束 时间片约束 教室信息 教室信息 4 排课 处理 数据 合成 5 生成 课表 9

系统数据字典

院 系

院系编号 院 系 名 教 师

教师编号

＝ 院系编号 ＋ 院系名

＝ *2位正整数，并能唯一标识每个院系或单位* ＝ *小于13位字符（包括中文、字母、数字）* ＝ 教师编号 ＋ 教师姓名 ＋ 出生年 ＋ 性别

＝ *6位数字，头2位数字为该教师所在系号,并能唯一标识每个教师；若用户学校以教研室为单位管理, 头4位应是教研室编号*

教师姓名 ＝ *小于9位字符（包括中文、字母、数字）* 出 生 年 ＝ *4位数字*

性 别 ＝ [“男“| “女”] 课 程 ＝ 课程编号 ＋ 课程名称 课程编号 ＝ *小于11位字符, 头2位是课程开课系的编号, 并能唯一标识每

门课程*

课程名称 ＝ *小于21位字符（包括中文、字母、数字）* 专 业 ＝ 专业编号 ＋ 专业名称 专业编号 ＝ *小于5位字符, 头2位为该专业所属的系号, 并能唯一标识每

个专业*

专业名称 ＝ *小于13位字符（包括中文、字母、数字）* 教 学 楼 ＝ 教学楼编号 ＋ 教学楼名称

教学楼编号 ＝ *4位数字，第1位是校区码，并能唯一标识每个教学楼* 教学楼名称 ＝ *小于17位字符（包括中文、字母、数字）* 教室 ＝ 教学楼编号 ＋ 教室名称 ＋ 容纳人数 ＋ 教室类型 教室名称 ＝ *小于7位个字符，（包括中文、字母、数字）* 容纳人数 ＝ *3位正整数*

教室类型＝[“-1”|“0”|“1”|“2”|“3”|“4”|“5”|“6”|“7”|“8”|“9”] * -1表示不分教室； 0 表示一般的上课教室； 1和2均表示制图室； 3—9为自定义小于5位字符* 学生班级 ＝ 班级编号 ＋ 年级 ＋ 班名

10

＋ 人数 ＋ 固定教学楼 ＋ 固定教室 编 号 ＝ *4位字符, 是该班所在专业的编号* 年 级 ＝ [“1”|“2”|“3”|“4”] 班 名 ＝ 标识符 ＋ 序号

标识符 ＝ *小于7位字符*

序 号 ＝ *2位字符，允许为空* 人 数 固定教学楼固定教室 教学计划 学 期 学 时 学 分 周 学 时 是否必修 是否考试 起 周 次 末 周 次 教学任务

＝ *3位数字*

＝ *小于13位字符（包括中文、字母、数字），允许为空* ＝ *小于7位字符（包括中文、字母、数字），允许为空* ＝ 编号 ＋ 年级 ＋ 学期 ＋ 课程编号 ＋ 课程名称 ＋ 学时 ＋ 学分 ＋ 周学时 ＋ 是否必修 ＋ 是否考试 ＋ 起周次 ＋ 末周次 ＝ [“1”|“2”|“3”] ＝ *3位正整数* ＝ *2位正整数, 1位小数* ＝ *2位正整数, 1位小数* ＝ [“0”|“1”|“2”] * 选修为2, 必修为1,限选为0* ＝ [“0”|“1”] * 考查为1, 考试为0* ＝ *2位正整数，允许为空* ＝ *2位正整数，允许为空* ＝ 课程编号 ＋ 课程名称 ＋ 学时 ＋ 周学时 ＋ 是否必修 ＋ 是否考试 ＋ 主讲 ＋ 助课 ＋ 上课班级 ＋ 合班数

11

合 班 数连上节数 6 排课模式 联合课码 讲课课程 容 纳 数 ＋ 人数 ＋ 起周次 ＋ 末周次 ＋ 连上节数 ＋ 时间要求 ＋ 排课模式 ＋ 教室类型 ＋ 教学楼 ＋ 教室 ＝ *2位正整数* ＝ [“1”|“2”|“3”|“4”|“5”|“6”|“7”|“8”] * 0－4 表示该课每次上课的节数, 0 也表示连上 2 节； 5 表示上午2节，下午4节； 表示排2个下午； 7 表示1天；

8 表示1个上午2节，2个下午* * 连上节数是5--8时周学时对排课不起作用* ＝ [“1”|“2”|“3”|“4”|“5”|“6”|“7”] * 0表示上、下午排课； 1表示单周上午、双周下午排课； 2表示双周上午、单周下午排课； 3表示上、下午排课，并均匀分布课时； 4表示下午、晚上排课，并均匀分布课时； 5表示下午排课； 6表示晚上排课； 7表示上、下午、晚上均排课* ＝ *小于6位字符，在一种联合课中, 主行课的联合课码是正整数,

并行课的联合课码是该数的负数*

＝ 课程编号 ＋ 课程名称 ＋ 容纳数 ＋ 固定教学楼 ＋ 固定教室 ＋ 教室类型 ＝ *2位正整数, 表示该课每个时间片可容纳课元组的数目*

12

风险管理计划

有关概念：

风险（Risk）是在规定的费用、进度和技术的约束条件下不能实现整个项目目标的可能性的一种度量。风险包括两个方面：(1)不能实现具体目标的概率；(2)因不能实现该目标所导致的后果/影响。

风险事件（Risk event）即可能导致某个项目或系统发生问题，需要作为采办项目要素加以评估以确定风险水平的事件。风险事件的定义应使人们易于理解其潜在影响和致因。可能会有一系列潜在的风险事件，这需要有关专家进行筛选、考察和评估。

风险的概率和后果之间的关系比较复杂。为避免评估结论含糊不清，与某个事件有关的风险应以概率和后果这两个参量表征。作为评估的一部分需要含有支持数据和评估理由的背景材料。

风险管理（ Risk management）是指控制风险的行动或实践。它包括进行风险规划、评估风险域，拟定风险处理备选方案，监控风险变化情况和记录所有风险管理情况。

风险规划（Risk Planning）是指研究一套有组织的、全面的和相互作用的策略和方法并将其形成文件的过程，这套策略和方法用于辨识和跟踪风险域；拟定风险缓解方案；进行持续的风险评估，从而确定风险变化情况并配置充足的资源。

风险评估（Risk assessment）指对项目各个方面的风险和关键性技术过程的风险进行辨识和分析的过程，以增加满足性能、进度和费用目标的可能性。风险辨识指对项目各个方面和各个关键性技术过程进行调查研究，从而辩识并记录有关风险的过程。风险分析是指调查研究已辨识出的风险域或过程以进一步细化风险描述，隔离风险的原因和确定风险影响的过程。它包括风险等级评定和优先次序排序， 风险事件的等级和排序是根据风险发生的概率、后果的严酷度以及

13

与其他风险域或技术过程的相互关系来确定的。

风险处理（Risk handling）是指对风险进行辩识、评价、选定并实施应对方案的过程，目的是在给定项目约束条件和目标下使风险保持在可接受水平上。它包括详细说明应当做些什么，应于何时完成，由谁负责，以及有关的费用和进度等具体问题。要从这些应对方案中选取最恰当的策略。风险处理是一个包罗万象的术语，而风险缓解和风险控制则是它的子集。

风险监控（Risk monitoring）是指在整个采办过程中，按既定的衡量标准对风险处理活动的效果进行系统跟踪和评价的过程，必要时还要进一步研究风险处理备选方案。它还反馈信息给风险规划、风险评估和风险处理等其它的风险管理活动。

风险文档（Risk documentation）是指记录、维护和报告风险的评估、处理分析方案以及监控结果的文件，包括所有的计划、给项目经理和决策者的报告以及项目管理办公室的内部报表。 风险管理的组织结构

执行风险管理功能的主要是项目开发人员。开发人员由项目经理负责，他是风险管理的最终负责人。 风险管理既是整个项目管理的一个有机组成部分，也是项目管理的一种有力手段和方法。它的任务是要弄清费用风险、进度风险和性能风险的相互关系。其目的是使参与项目工作的一切人员都能建立风险意识，在设计、研制和部署系统时考虑风险问题。

本系统风险管理的组织形式，为在集中式风险管理，项目经理要组建一个专门的风险管理组，来负责风险管理的所有工作，如编写计划、进行评估、评价风险处理备选方案和监控风险管理工作的进展情况等。

项目经理是进行规划、分配资源和执行风险管理的最终负责人，因此要求项目经理检查和参与风险管理过程。

项目经理必须最佳地使用可用资源，即人力、组织和资金。

14

风险管理是一项团队功能。这是因为风险的广泛性和风险处理计划要影响到项目的其他计划和行动。总的来说，风险评估、风险处理和风险监控对所有的项目活动和组织都有影响。任何企图实施积极主动向前看的风险管理计划，而没有项目经理参与，都将导致混乱、迷失方向和资源浪费。 人 员 项目经理 报告项目风险和建议缓解措施。 制定和维护风险管理计划； 提供风险管理培训； 风险管理 协调员 定义项目使用的风险报告的范围； 建立和维护风险管理信息系统； 准备风险管理报告； 向项目经理提出有关使用独立风险评估员的建议。 对项目经理指定的关键风险域进行独立风险评估； 独立风险 报告这些评估的结果给项目经理； 评估员 和风险管理协调员共同工作。 工作职责 风险管理的计划、组织、领导和控制； 风险管理工作步骤如下：

? ?

在项目计划和项目进度（如果适用）中，标识出风险。

根据项目定义的软件过程，建立补救措施计划文档。此计划将贯穿整个项目软件生命周期。补救措施计划应包括以下方面的工作：可选项识别、可选项影响度评估、可选项的技术可行性，和可选项使用时机的决定标准。 为每一风险定义出可供选择的补救措施，如果有可能，也要列出这些补救措施的选择标准。

软件计划的最初版本和主要的修订版，要经过同行评审后才可发行。 管理并控制软件计划。

在有选择的项目里程碑处、在指定的风险检查阶段点、和在对软件项目有影响的计划重大变更过程中，都应对风险进行跟踪、再评估，和重新计划。

15

?

? ? ?

? ?

检讨并修正风险级别。

利用风险监控所获得的信息，进一步精化风险评估和软件计划。

16

风险检查表：

提示：请使用者根据机构和项目的实际情况完善本检查表。

商业风险 风险类型 政治 法律 市场 检查项 政府或者其它机构对本项目的开发有限制吗？ 有不可预测的市场动荡吗？ 有不利于我方的官司要打吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？ 竞争对手有不正当的竞争行为吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？ 是否在开发很少有人真正需要却自以为很好的产品？ 是否在开发可能亏本的产品？ 客户 客户的需求是否含糊不清？ 客户是否反反复复地改动需求？ 客户指定的需求和交付期限在客观上可行吗？ 客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？ 客户的合作态度友善吗？ 与客户签的合同公正吗？双方互利吗？ 客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。 子承包商 供应商 与子承包商、供应商签订的合同公正吗？双方互利吗？ 子承包商、供应商的信誉好吗？ 子承包商、供应商有可能倒闭吗？ 子承包商、供应商能及时交付质量合格的产品（或部件）吗？ 子承包商、供应商有能力做好售后服务吗？ 管理风险 风险类型 项目计划 检查项 对项目的规模、难度估计是否比较正确？ 人力资源（开发人员、管理人员）够用吗？合格吗？ 项目所需的软件、硬件能按时到位吗？ 项目的经费够用吗？ 进度安排是否过于紧张？有合理的缓冲时间吗？ 进度表中是否遗忘了一些重要的（必要的）任务？ 进度安排是否考虑了关键路径？ 是否可能出现某一项工作延误导致其它一连串的工作也被延误？ 任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能） 是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？ … 项目团队 项目成员团结吗？是否存在矛盾？ 是否绝大部分的项目成员对工作认真负责？ 绝大部分的项目成员有工作热情吗？ 团队之中有“害群之马”吗？ 技术开发队伍中有临时工吗？ 17

本项目开发过程中是否会有核心人员辞职、调动？ 是否能保证“人员流动基本不会影响工作的连续性”？ 项目经理是否忙于行政事务而无暇顾及项目的开发工作？ 上级领导 行政部门 合作部门 本项目是否得到上级领导的重视？ 上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？ 上级领导是否过多地介入本项目的事务并且瞎指挥？ 行政部门的办事效率是否比较底，以至于拖项目的后腿？ 行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？ 机构是否能全面、公正地考核员工的工作业绩？ 机构是否有较好的奖励和惩罚措施？ 本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？ 技术风险 风险类型 需求开发 需求管理 检查项 需求开发人员懂得如何获取用户需求吗？效率高吗？ 需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？ 需求文档能够正确地、完备地表达用户需求吗？ 需求开发人员能否与客户对有争议的需求达成共识？ 需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？ 综合技术 开发能力 包括设计 编程、测试等 开发人员是否有开发相似产品的经验？ 待开发的产品是否要与未曾证实的软硬件相连接？ 对开发人员而言，本项目的技术难度高吗？ 开发人员是否已经掌握了本项目的关键技术？ 如果某项技术尚未实践过，开发人员能否在预定时间内掌握？ 开发小组是否采用比较有效的分析、设计、编程、测试工具？ 分析与设计工作是否过于简单、草率，从而让程序员边做边改？ 开发小组采用统一的编程规范吗？ 开发人员对测试工作重视吗？能保证测试的客观性吗？ 项目有独立的测试人员吗？懂得如何进行高效率地测试吗？ 是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？ 开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？ 开发人员重视质量吗？是否会在进度延误时降低质量要求？ 18

已识别的风险：

风险管理报告

风险编号 风险名称 风险描述 1 风险识别人 风险识别日期 项目经理 开发人员不够，造成开发时间增加 风险可能性 风险危害值 风险减缓措施 0.5 4.0 风险影响 风险处理人 8 1. 聘请有开发类似系统的开发人员参与系统开发 2. 聘请资深程序员作为技术指导 3. 规划开发进程，设定标志性任务，一旦发现超过规定时间未完成任务，考虑增加 人手 跟踪记录 （1）记录何人在何时做了什么事情 （2）记录当前风险状态（正在处理，已经解决，不作处理） 19

风险编号 风险名称 风险描述 2 风险识别人 风险识别日期 项目经理 用户需求不断扩大，造成开发难以进行 风险可能性 风险危害值 风险减缓措施 0.8 6.4 1. 在早期多收集用户需求 风险影响 风险处理人 8 2. 与用户代表一起召开会议以确定开发需求 3. 开发一个包括核心功能的用户界面原型。让用户代表来评审此原型 跟踪记录 （1）记录何人在何时做了什么事情 （2）记录当前风险状态（正在处理，已经解决，不作处理） 风险编号 风险名称 风险描述 3 风险识别人 风险识别日期 项目经理 程序员语言开发环境不同，协调工作困难 风险可能性 风险危害值 风险减缓措施 0.8 4.0 风险影响 风险处理人 5 1. 尽量要求程序员使用同一种语言作为开发语言 2. 建议使用Borland c++ 作为开发环境 （1）记录何人在何时做了什么事情 （2）记录当前风险状态（正在处理，已经解决，不作处理） 跟踪记录 20

变更控制的过程

角色和责任

建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。

角 色 变更控制委员会主席 CCB 评估者 修改者 建议者 验证者 人 员 开发小组负责人 责 任 在CCB意见不一致的情况下可以独自作出决定 决定采纳或拒绝针对本系统所全体开发小组人员 建议的变更请求 开发小组负责人 分析变更对本项目带来的影响 全体开发小组人员 对已认可的变更请求按时更新 全体开发小组人员 提交变更请求 用户代表 开发小组负责人 确认更改是否正确执行 用户代表

变更注意事项

1) 没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处是可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。

2) 对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如案例中提到的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。

3) 对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道你为变更付出的代价，对你的辛苦便难以体会。

4) 应该让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过

26

程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。

变更请求状态

开始条件

用户必须通过合适的渠道接受一个合法的变更请求，本项目通过书面、web表单以及电子邮件申请变更，申请变更请填写《需求变更控制报告》，不接受任何口头通知。

任务

进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供

27

对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出是修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。

验证

无论需求变更的程度如何，只要需求变化了就必须进行验证，这是基本的原则。本项目组中明确定义验证员，确保在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致，受影响的其它组也必须与客户协商一致。

28

需求变更控制报告 需求变更申请 申请变更的 需求文档 变更的内容 及其理由 评估需求变更将对项目造成的 影响 申请人签字 变更申请的审批意见 审批意见： 项目经理签字 签字： 年 月 日 审批意见： 客户签字 （合同项目） 签字： 年 月 日 更改需求文档 变更后的 输入名称，版本，完成日期等信息 需求文档 更改人签字 重新评审需求文档 审批意见： 需求评审 小组签字 签字： 年 月 日 变更结束 项目经理签字 签字： 年 月 日 输入名称，版本，日期等信息

29

本文来源：https://www.bwwdw.com/article/bx8.html