软件需求工程 高校教学平台 需求工程计划
点击查看 软件需求工程 高校教学平台 卷首语
文章目录
- 引言
- 编写目的
- 业务机遇
- 业务目标
- 参考资料
- 项目概述
- 工作内容
- 开发人员
- 产品
- 需要移交用户的文件
- 非移交的文件
- 验收标准
- 项目相关信息
- 系统运行环境
- 时间管理计划
- 工作任务概要
- 总体时间分配
- 范围管理计划
- 高校教学平台的项目范围
- 需求工程范围管理表
- 成本管理计划
- 项目定义与决策工作成本
- 项目设计成本
- 项目采购成本
- 项目实施成本.
- 质量管理计划
- 机构
- 任务
- 阶段审查
- 日常检查
- 软件验收
- 职责
- 沟通管理计划
- 开发者与客户沟通计划
- 开发者内部沟通计划
- 风险管理计划
- 风险评估
- 需求获取方面的风险
- 需求分析方面的风险
- 编写需求规格说明方面的风险
- 需求确认方面的风险
- 需求管理方面的风险
- 风险控制
- 需求获取方面的控制
- 需求分析方面的控制
- 编写需求规格说明方面的控制
- 需求确认方面的控制
- 需求管理方面的控制
- 配置系统管理指南
- 配置标志
- 版本管理
- 变更控制
- 微小更正时的变更控制
- 较大变动时的变更控制
- 配置状态报告
- 配置审核
引言
编写目的
项目管理与软件需求，作为软件工程当中最为重要的组成几个部分，已经引起了业内人士的高度重视。
需求工程的作用主要表现在：增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解，增强了项目涉众对需求（尤其是复杂需求）的掌握；增进了项目涉众之间的交流，减少了可能的误解和交流偏差；需求管理能够更加有效地处理需求变更，提高了生产效率;
需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策；使得项目涉众认识到需求在项目工作中的重要性，使得需求的作用得到重视和有效发挥。良好的需求分析和管理工作，才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础。
在管理实践中，计划是其他管理职能的前提和基础，并且还渗透到其他管理职能之中，列宁指出过：“任何计划都是尺度、准则、灯塔、路标”它是管理过程的中心环节，因此，计划在管理活动中具有特殊重要的地位和作用。
因此软件需求工程计划是明确软件需求的不可缺少的前提条件。
软件开发项目组在对该教学辅助系统进行需求分析时，都应该执行本计划中的有关规定，但若确实有需要，可根据各自情况对本计划作适当剪裁，以满足特定的需求质量要求，裁剪后的计划必须经过项目组负责人批准。
业务机遇
2020年全球面临了新冠疫情的巨大挑战，在这一特殊情况下，在线教学成为了高校教学的刚性需求。在这一背景之下，高校在线教学平台应运而生。
而21世纪是以互联网的全面深入运用为特征的世纪。网络环境下的教育不仅是教育信息化的必然产物，也是教育改革发展的必然走向。通过因特网或其他数字化内容进行学习交流与教学的活动即网络化学习（E-Learning），可以充分利用现代信息技术所提供的具有全新沟通机制与丰富资源的学习环境，实现一种全新的学习交流方式。这种学习交流方式将改变传统教学中教师的作用和师生之间的关系，从而根本改变教学结构和教育本质。从而根本改变教学结构和教育本质。美国教育部2000年12月向国会递交的“国家教育技术计划”中打算以网络化学习作为提高年青一代“21世纪能力素质”的根本措施。技术的教育应用成为教育改革和人才培养的重要途径之一。
超文本特性可实现对教学信息最有效的组织与管理；网络化的学习有利于充分实现交互与共享，有利于激发学生的学习兴趣和充分体现学习主体作用，有利于培养学习者的信息素养和信息能力。另一方面教师利用教学、学习、交流网站可以充分发挥网络特性，对教学进行更为有效的管理，同时也有了更为便利的信息发布手段。
业务目标
由于2020新冠疫情的肆虐，几乎所有学校都采取了线上的教学方式，而通过类似“中国大学MOOC”的网络教学平台将为师生带来极大的便利。
而且虽然如今有很多教学网站，但是专门针对一门新开的大学课程和一位专门的教师，又为学生之间提供交流平台的网站为数不多。这个网站作为一个在线教学的工具，将有利于教师的教学和学生的学习。
这个网站的主要目的就是为教师的教学和学生的学习过程提供辅助帮助和推进，为作业提交与管理提供便利，方便教师，方便学生。这个网站还为一些对一些课程还不是很了解的人（包括外校同学甚至游客）提供了解课程的机会。
学生可以方便地获得关于课程与教师的信息
学生可以方便地获得课程的相关资料和课程通知
学生和教师之间可以更方便地交流答疑
学生的获得资料更加容易，更加丰富
学生能够更及时的接收通知
学生可以通过网站进行线上实验、提交作业与测试
教师可以方便地收集、点评学生作业
教师可以进行更加丰富的课堂活动
游客能够有机会了解课程信息，同时可以免费试看部分课程
这个网站预计会在学期结束时完成最终版本。
参考资料
《高校教学平台》课程案例
课程PPT
Software Requirements (3rd, 2013.8), Karl.E.Wiegers
Software Engineering A Practitioner’s Approach, Roger S. Pressman, Ph.D.,
Bruce R. Maxim, Ph.D.Software Engineering (Principle and Practice), Hans van Vliet
项目概述
工作内容
软件开发的流程为：沟通、策划、建模、构件以及部署，根据不同的模型可以采用不同的开发方法。由于此系统属于中小型，且需求较为详细明确，故采用最传统的经典生命周——瀑布模型。
在项目开发初期，需求的获取十分重要，需要定义需求开发过程，编写前景和范围文档，确定用户群和他们的特点，为每类用户选择代言人，建立典型用户的中心小组，与用户代表沟通以确定用例，确定系统事件和响应，召开专门的需求获取讨论会，观察用户工作的过程，检查当前系统的问题报告来进一步完善需求。
由于此课程重点在于需求的获取，因此这一部分会尤其详细些，当获取需求后，开始进行项目估算，进度计划，项目跟踪，完成策划这一部之后，开始进行建模分析与设计，接着构建项目，包括编码与测试，最后进行项目的最终部署，包括交付给客户，以及进行反馈。
开发人员
表2-1 开发人员表
| 开发人员 | 学院 | 专业 | 组内地位 | 技术水平 |
|---|---|---|---|---|
| xxx | 计算机科学与技术学院 | 软件工程 | 组长 | 中等 |
| xxx | 计算机科学与技术学院 | 软件工程 | 组员 | 中等 |
| xxx | 计算机科学与技术学院 | 软件工程 | 组员 | 中等 |
| xxx | 计算机科学与技术学院 | 软件工程 | 组员 | 中等 |
| xxx | 计算机科学与技术学院 | 软件工程 | 组员 | 中等 |
| xxx | 计算机科学与技术学院 | 软件工程 | 组员 | 中等 |
产品
需要移交用户的文件
表 2-2 移交文件表
| 文件名 |
|---|
| 《项目章程》 |
| 《可行性分析报告》 |
| 《总体项目计划》 |
| 《需求工程计划-初步》 |
| 《前景与范围》 |
| 《质量保证计划》 |
| 《需求工程计划》 |
| 《软件需求规格说明书》 |
| 《系统设计计划》 |
| 《需求变更控制文档》 |
| 《用户手册》 |
| 《软件概要设计说明》 |
| 《系统编码与实现计划》 |
| 《测试计划》 |
| 《工程部署计划》 |
| 《培训计划》 |
| 《系统维护计划》 |
| 《项目总体报告》 |
非移交的文件
软件开发结束后，以下文档开发人员不需要移交给客户：
表 2-3 非移交文件表
| 文件名 |
|---|
| 《人员分组表》 |
| 《概要设计说明书》 |
| 《数据库设计手则》 |
| 《代码与文档调整意见书》 |
| 《源代码文档》 |
| 《例会纪要》 |
验收标准
表 2-4 文件验收标准表
| 文件名 | 验收标准 |
|---|---|
| 《项目章程》 | 文档规范，内容翔实 |
| 《可行性分析报告》 | 文档规范，内容翔实 |
| 《总体项目计划》 | 文档规范，内容翔实 |
| 《需求工程计划-初步》 | 文档规范，内容翔实 |
| 《前景与范围》 | 文档规范，内容翔实 |
| 《质量保证计划》 | 文档规范，内容翔实 |
| 《需求工程计划》 | 文档规范，内容翔实 |
| 《软件需求规格说明书》 | 文档规范，内容翔实 |
| 《系统设计计划》 | 文档规范，内容翔实 |
| 《需求变更控制文档》 | 文档规范，内容翔实 |
| 《用户手册》 | 文档规范，内容翔实 |
| 《软件概要设计说明》 | 文档规范，内容翔实 |
| 《系统编码与实现计划》 | 文档规范，内容翔实 |
| 《测试计划》 | 文档规范，内容翔实 |
| 《工程部署计划》 | 文档规范，内容翔实 |
| 《培训计划》 | 文档规范，内容翔实 |
| 《系统维护计划》 | 文档规范，内容翔实 |
| 《项目总体报告》 | 文档规范，内容翔实 |
项目相关信息
项 目 批 准 者：软件需求工程课程老师 —— 邢卫、林海
项目批准日期： 2020 年 9 月 23 日
项目截止日期： 2021 年 1 月 20 日考试周前
系统运行环境
本网站要求提供对外服务的能力，保证至少 30000 名同学上课辅助服务的要求。包括数据存储能力，网络服务吞吐能力，数据安全特性等。
服务器选用阿里云ECS云服务器， 操作系统选择Linux Ubuntu-20.04 64bit，服务器配置为8G内存 4核 5M带宽。
开发平台后端选择Python的Django库，前端选择Vue.js。
提供对外服务所要求的相应的安全保障。
时间管理计划
工作任务概要
根据软件开发流程以及在完整周期内面对需求的明确、更改、落实等情况，为项目提供稳定持续性保证，我们在完整工作周期内主要完成以下工作任务：
根据5~6人的规模分组，按照组员能力特长安排组内分工，并制定小组例会规章制度。
撰写包括《项目可行性报告》、《项目章程》、《项目总体计划》等前期准备类报告。
撰写包括《需求工程计划》、《质量保证计划》、《软件需求规格说明书》等项目规程类报告。
提交秋学期小组例会纪要，并总结秋学期项目完成情况。
撰写包括《系统设计计划》、《需求变更控制会规程》、《测试计划》等中期实施类报告。
撰写包括《用户手册》、《测试报告》、《项目总结报告》等项目收尾性总结报告。
完成全部项目内容，提交小组内部全部的例会纪要，并总结项目心得体会。
在每周上课结束后，本组将根据项目进展和课堂所学，于周末召开小组例会，由组内同学轮流担任会议纪要员，最终形成例会纪要并上传至学在浙大。
总体时间分配
根据课程教学安排以及小组内部商议，本学期所有任务
表3-1 任务分配时间表
| 项目任务（及里程碑） | 截止日期 |
|---|---|
| 分组，建立通讯录、角色分工、例会制度、 日报制度等完成《人员分组表》 | 2020.09.25 |
| 《项目总体计划》 《需求工程计划》 | 2020.10.07 |
| 《项目可行性报告》 《项目章程》 | 2020.10.07 |
| 《前景与范围》 《质量保证计划》 | 2020.10.18 |
| 秋学期小组例会纪要 （第2至8周，共整理7份） | 2020.11.15 |
| 《软件需求规格说明书》 | 2020.12.13 |
| 《系统设计计划》 《需求变更控制会规程》 | 2020.12.20 |
| 《系统编码与实现计划》 《测试计划》 | 2020.12.27 |
| 《需求变更控制文档》 《用户手册》 | 2021.01.03 |
| 《软件需求规格书》 《软件概要设计说明书》 《测试报告》 《工程部署计划》 《培训计划》 《系统维护计划》 《项目总结报告》 | 2021.01.10 |
| 冬学期小组例会纪要 （第1至7周，共整理7份） | 2021.01.13 |
范围管理计划
高校教学平台的项目范围
4.1.1 课程
课程介绍：课时安排、教学计划、使用教材、国际国内背景、考核方式、学生选这门课所需要的知识背景，以及大作业的介绍，并可以在以后增加另外课程的时候可以定制。
课程学习资料：课件、模板、参考资料、以往优秀作业、教学视频、音频资料下载，并可以及时更新。
4.1.2 教师
教师介绍：对任课老师的以往教学、科研成果，及其教学风格、出版书籍、所获荣誉等的介绍。
课程学习资料上传、下载、及时更新：
通过账号上传、下载、及时更新课件、模板、参考资料、以往优秀作业、教学视频、音频资料下载，并可以及时更新。消息发布：息发布栏用于老师发布作业点评、临时课程变更等通知。
发布线上测试，应对网络通信的异常：随堂测试、期中期末考试，开卷闭卷，避免替考，避免其他作弊。对于网络通信的异常有应对责任与机制。
发布最新信息：公布最近的一些教学或外出交流的心得，以及网站一些最近更新信息的介绍。
作业评价：作业点评，作业完成情况跟踪的功能，对学生的作业和课后作业讨论进行点评。
4.1.3 学生
课程学习资料下载：通过账号下载课件（以往的旧版本课件，以及最新的课件）、模板、参考资料（含电子教材、历年试卷、补课资料，以及老师的教学交流文章）、以往优秀作业、教学视频、音频资料下载。
下载的速度能够得到保证：要求同时可容纳500人下载，并且人均速度能达到5000
Kbps。参加线上实验：嵌入的某些典线上工具或仿真引擎可以使学生线上完成实验。
参加线上测试，应对网络通信的异常：随堂测试、期中期末考试，开卷闭卷，无法替考，无法进行其他作弊。对于网络通信的异常可以走正常渠道应对。
及时与老师互动：能及时看到老师的通知（含课程相关通知及作业点评）。
在线观看和下载多媒体资料：如果教师提供的是多媒体资料，网站能提供下载及在线观看功能（如课堂录像）。
密码取回：通过提问方式或邮件认证的密码取回功能。
课程团队内部交流工具：网站能提供让分组的各个团队能有团队内部的交流工具（如论坛，不同团队可以申请认证板块，非团队成员不能浏览使用，但希望教师可以进入各个板块进行一定的指导，而网站管理人员也可管理认证板块）
，成员可以在团队内部进行资料共享（如论坛有上传下载附件功能、但对附件大小有限制，如不得大于2M） 。获取详细的教师联系方式：网站能较醒目地提供教师的联系方式
作业提交：有作业提交功能，并可以跟踪作业的批复情况。
4.1.4 其他用户（外校学生或游客等）
查阅课程和老师介绍：教学平台提供课程的相关介绍和任课老师的介绍，并放在网站显著位置。
在线浏览简化版课程学习资料：课件、模板、参考资料、以往优秀作业、教学视频、音频资料。
获取相关链接：提供相关链接（含学校选课系统，以及需求相关主题网站）。
留言：允许针对网站内容留言（如提供留言板的功能，留言者有Email可选项，用于信息反馈）；网站管理员不随便删除游客的留言。
4.1.5 向导
首页提供使用指南的链接。
有网站的导航（navigation bar）。
友情链接：如网上选课主页，由老师要求管理员实时更新含学校选课系统、学院网页、需求相关主题网站。
站内文章标题搜索功能。
4.1.6 其他教学场景
平行班教学：多位教师分头给多个平行班上相同课程的情况，各班有统一的作业或单元练习，甚至统一的在线测试。
小组教学：教学过程中，在项目或大型作业、实验等环节存在分组教学，学生按小组统一完成某项或某些任务；部分课程总评分按小组方式给出，再折算到每位同学身上。
考虑特殊使用人群：非计算机类的教师和学生，能顺畅地理解并使用这个教学系统，比如，纯文科类的专业（中文系）。考虑国际学生、留学生、旁听学生甚至成人教育学生。
添加助教角色：考虑将助教作为一类用户。
开发移动端：考虑对用户通过使用智能手机来使用教学平台的切实要求。
需求工程范围管理表
表4-1 需求工程范围管理表
| 开发阶段 | 具体内容 |
|---|---|
| 知识技能培训 | 培训需求分析员、户代表和管理者 培训开发人员 创建项目术语表 |
| 需求获取 | 定义需求开发过程 撰写前景和范围文档 确定用户群和他们的特点 为每类用户选择代言人 建立典型用户的中心小组 与用户代表沟通以确定用例 确定系统事件和响应 召开专门的需求获取讨论会 观察用户工作的过程 检查当前系统的问题报告来进一步完善需求 跨项目重用需求 |
| 需求分析 | 绘制关联图 创建用户界面和技术原型 分析需求的可行性并确定需求优先级 为需求建模 创建数据字典 将需求分解到子系统 应用质量功能调配 |
| 规格说明 | 采用 SRS 模板 确定需求来源 为需求分配唯一标号 记录业务规则 定义质量属性 |
| 需求验证 | 审查需求文档 测试需求 定义合格标准 |
| 需求管理 | 定义需求变更控制过程 成立变更控制委员会 分析需求变更的影响 建立基线和控制需求文档的版本 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求的稳定性 使用需求管理工具 创建需求跟踪矩阵 |
| 项目管理 | 选择合适的软件开发生命周期 根据需求制订项目计划 需求变更时更新讨论项目承诺 管理与需求相关的风险以及编写风险文档 跟踪需求工程的投入 从其他项目的需求工程中积累经验 |
成本管理计划
项目定义与决策工作成本
项目定义与决策成本是项目形成的第一阶段，包括进行翔实的调查研究、收集和掌握第一手信息资料、进行项目可行性研究及最终做出抉择，其消耗的人力、物力资源构成了项目定义与决策成本。
本高校教学平台的项目定义与决策成本主要包含以下几个方面：
表5-1 项目定义与决策成本
| 成本类别 | 成本内容 | 成本量化 |
|---|---|---|
| 人力成本 | 选择已有的教学平台，进行参考和分析，总结其需求、设计方面的优缺点 | 参与人数：2人 耗时：2天 |
| 调研并收集疫情需求下各高校教师与学生对教学平台的新要求与侧重点 | 参与人数：2人 耗时：2天 | |
| 进行项目可行性分析： 开发资源要求与评价 开发人员与时间要求与分析 开发技术要求与评价 风险分析 | 参与人数：2人 耗时：2天 | |
| 讨论制定项目需求规格书，包含项目描述、用户场景、数据定义、验收标准等 | 参与人数：6人 耗时：4天 | |
| 物力成本 | 需求调研花费 | 打印费：50 RMB 交通费：500 RMB |
| 讨论制定决策时所需场所耗费 | 金额：200 RMB |
项目设计成本
项目设计成本指在项目设计过程中的耗费，本项目中主要指对高校教学平台系统设计过程中的人力资源耗费。
表5-2 项目设计成本
| 成本类别 | 成本内容 | 成本量化 |
|---|---|---|
| 人力成本 | 依据项目需求计划书对教学平台的系统功能、性能、运行环境（服务器端 + 客户端）、系统结构、执行概念、接口、数据库、运行控制和系统出错做出相应设计与分析 | 参与人数：6人 耗时：7天 |
| 讨论完成项目设计说明书 | 参与人数：6人 耗时：4天 | |
| 进行项目需求回溯分析 | 参与人数：6人 耗时：2天 | |
| 物力成本 | 讨论时所需场所耗费 | 金额：200 RMB |
项目采购成本
项目采购成本指为获得项目所需的各种资源（包括设备、环境、劳务等）所需要的耗费，在正式开发中包括项目团队对所需物资商品购买的询价、供应商选择、合同谈判与履约管理、对所需劳务的谈判、签约与履约成本。由于本项目不是一个正式的开发，这里仅列出高校教学平台所需环境的获取成本与人员的组织与分工成本。
表5-3 项目采购成本
| 成本类别 | 成本内容 | 成本量化 |
|---|---|---|
| 人力成本 | 项目团队的组建 | 耗时：1天 |
| 项目团队成员的分工 | 参与人数：6人 耗时：1天 | |
| 物力成本 | 阿里云服务器购买 | 金额：2000 RMB |
项目实施成本.
项目实施成本指在项目实施过程中为完成项目可交付物所耗用的各项资源耗费，包括人力资源、物力耗费、顾问费用及不可预见费用（包括风险机制耗费）等，是项目成本的主要组成部分。项目成本管理在很大程度上是项目实施成本的管理与控制。
本高校教学平台的项目实施成本如下：
表5-4 项目实施成本
| 成本类别 | 成本内容 | 成本量化 |
|---|---|---|
| 人力成本 | 编写系统前后端 | 参与人数：6人 耗时：15天 |
| 进行系统测试： 模块功能测试 边界测试 压力测试 接口测试 安全性测试 | 参与人数：6人 耗时：5天 | |
| 进行需求变更控制、系统维护 等项目管理工作 | 参与人数：6人 耗时：3天 | |
| 完成测试报告、用户手册、 项目总结报告等文档 | 参与人数：6人 耗时：5天 | |
| 物力成本 | 讨论时所需场所耗费 | 金额：200 RMB |
| 项目管理经费 | 金额：100 RMB | |
| 知识技能培训费 | 金额：1000 RMB |
基于以上成本内容，我们采用类比估算的方法，即通过比照以及完成的类似项目的实际成本（这里指已发布的高校教学平台项目和往届学长学姐的本项目成本）估算本高校教学平台的成本，所制定的需求工程预算表如下：
表5-5 需求预算表
| 开发阶段 | 经费（元） |
|---|---|
| 知识技能培训 | 1000 |
| 需求分析与获取 | 550 |
| 规格说明 | 50 |
| 需求验证与管理 | 100 |
| 项目管理 | 100 |
| 阿里云服务器购买 | 2000 |
| 场地租用 | 600 |
| 总价 | 4400 |
| 开发者人数：6人 | |
| 开发时间：4个月 |
质量管理计划
机构
在该高校教学平台的整个开发期间，必须成立项目质量保证组负责质量保证工作。项目质量保证小组由项目的软件工程小组组长、子板块软件质量保证人员、专职配置管理人员、专职质量保证人员以及项目委托单位代表组成，由项目的软件工程小组组长代表任组长。项目质量保证组必须检查和督促本质量保证计划的实施。
各个模块的软件质量保证人员有义务向质量保证小组报告自己负责的模块的软件质量状况。各个模块的软件质量保证人员应当根据模块的具体要求制订必要的规定，以确保能遵守本质量保证计划的所有要求。
任务
软件质量保证工作涉及软件生存周期各阶段的活动，应贯彻到整个软件开发活动中。对于该高校教学平台，应按照本质量保证计划中的各项规定进行评审工作。质量保证小组应参与所有的评审和检查活动。为确保软件开发各个阶段都能认真采取措施来保证软件系统的质量，应进行以下评审和检查。
阶段审查
在整个软件系统开发过程中，应分阶段地进行三次评审：
第一次评审软件需求、概要设计、验证与确认方法；
第二次评审详细设计、功能测试与演示；
第三次评审为功能检查、物理检查和综合检查。
阶段评审工作要组织专门的评审小组，由质量保证小组组长担任评审小组组长，成员包括项目所有成员、模块质量保证人员以及项目委托单位。每一次评审工作都应当填写评审总结报告、评审问题记录、评审成员签字与软件问题报告单等表格。
日常检查
在整个软件系统的开发过程中，每个模块都要填写项目进展报表。质量保证小组通过项目进展报表检查模块的开发情况。
软件验收
软件质量保证小组负责对该高校教学平台及其所属模块进行验收。验收内容包括文档验收、程序验收、功能测试与演示等工作。验收标准参照软件需求规格说明书。
职责
在本软件质量保证小组中，各方面人员的职责如下：
组长全面负责有关软件质量保证的各项工作；
全组负责有关阶段评审、项目进展报表检查以及软件验收等三方面的质量保证工作；
各个模块的软件质量保证人员负责测试复查和文档的规范化检查工作；
用户代表反映用户的质量要求，并协助检查各类人员对软件质量保证计划的执行情况；
项目的专职配置管理人员负责有关软件配置变动、软件媒体控制以及对软件提供商的控制等三方面的质量保证活动；
项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录。
沟通管理计划
开发者与客户沟通计划
表7-1 开发者与客户沟通计划
| 干系人 | 沟通人员 | 内容 | 形式 | 频度 | 责任人 |
|---|---|---|---|---|---|
| 项目组长 客户 | 客户（老师、学生） | 项目内容和需求 | 会议 | 至少2次 | 项目组长 |
| 项目组长 客户 | 客户（老师、学生） | 项目内容和需求以及其他补充内容 | 电子邮件/短信电话 | 每周（次数较为自由） | 项目组长 |
| 项目组长 客户 | 客户（老师、学生） | 客户需求 | 电子邮件/短信电话 | 每周（次数较为自由） | 项目组长 |
| 项目成员和全体使用人群 | 全体使用人群 | 对项目的需求和建议等 | 问卷调查 | 至少1次 | 项目组长 |
开发者内部沟通计划
表7-2 开发者内部沟通计划
| 干系人 | 沟通人员 | 内容 | 形式 | 频度 | 责任人 |
|---|---|---|---|---|---|
| 项目成员 | 开发成员 | 项目进展/成果 | 会议（线下会议/线上视频/语音会议） | 每月 | 项目组长 |
| 项目成员 | 开发成员 | 项目进展/成果及项目中需要调整合作部分 | QQ/微信联系 | 每周（次数较自由） | 项目组长 |
| 项目成员 | 开发成员 | 项目进展/成果及项目中需要调整合作部分 | 电话/短信/邮件联系 | 每周（次数较自由） | 项目组长 |
| 项目成员 | 开发成员 | 项目进展/成果 | 网盘资源共享/github项目同步管理 | 每周 | 项目组长 |
| 项目成员 | 开发成员 | 研读用户提供的文档 | 线上交流 | 每周（次数较自由） | 项目组长 |
风险管理计划
风险评估
需求获取方面的风险
产品前景和项目范围没有达成明确的共识引发的风险
需求开发所需的时间分配不合理引发的风险
需求规格说明的不完整性和不正确性引发的风险
创新产品的需求不完全引发的风险
忽视非功能需求引发的风险
客户对产品需求意见不一致引发的风险
未加说明的需求引发的风险
对已有的产品作为需求基线来源引发的风险
根据用户提议的解决方案引发的风险
客户未考虑周全却又是必须的需求引发的风险
已经进入开发阶段但客户临时增加需求所引发的风险
需求分析方面的风险
设定需求优先级引发的风险
技术上难以实现的特性引发的风险
不熟悉的技术、方法、语言、工具或者硬件引发的风险
编写需求规格说明方面的风险
需求理解引发的风险
尽管问题待确定但迫于时间压力而继续向前引发的风险
具有二义性的术语引发的风险
需求中包括设计引发的风险
需求确认方面的风险
未经确认的需求引发的风险
由已确认需求衍生其他需求引发的风险
审查熟练程度引发的风险
需求管理方面的风险
变更需求引发的风险
需求变更过程引发的风险
为实现的需求引发的风险
扩大目标范围引发的风险
风险控制
需求获取方面的控制
在项目早期编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。
合理安排需求开发所需的时间，需求开发活动的工作量应占项目总工作量的10%-15%。
强调市场调研、构建原型并成立客户小组，小组负责今早并经常获取对新产品前景的反馈信息
向客户询问以获得相应的质量特性需求，例如性能、易使用性、完整性和可靠性需求。尽可能精确的在软件需求规格说明中，对这些非功能性需求及其验收标准编写文档。
确定主要客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与，确保由合适的人对需求做出权威性的决策。
尽量识别客户可能做出的任何假设。提出自由回答的问题来鼓励客户分享更多的想法、期望、主意、信息和关注点，而不是我们以其他方式所听到的。
通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确定和相关性。
分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。
对于客户未考虑周全却又是必须的需求引发的风险和已经进入开发阶段但客户临时增加需求所引发的风险，可以采用Scrum作为开发过程中的模板，利用需求池进行缓冲，直到客户不再产生新需求为止。
图8-1 Scrum开发模式
需求分析方面的控制
要确保每个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或迭代中实现它们。
评估每个需求的可行性，确定哪些需求的实现时间可能比预期长，尽早采取措施。
为满足某些需求而采取新技术时，要考虑到学习曲线的问题，只有通过一定的学习时间才能达到适当的熟练程度。要尽早确认那些高风险的需求，并留出足够的时间用户从错误中学习经验，实验以及制作原型。
编写需求规格说明方面的控制
对需求文档进行正式评审的团队应该包括开发人员、测试人员和客户，以减小需求的不同理解造成的风险。
应该记录下负责最终解释每个 TBD 的负责人的姓名和解决的截止日期。
创建一个数据字典来定义一些术语的条目和结构，对软件需求说明的评审可以帮助参与者对关键术语和概念达成一致的理解。
对需求的评审，可以确保强调的是需要解决的业务问题是什么，而不是规定如何解决。
需求确认方面的控制
在构造设计开始之前，确认需求的正确性和质量，应该为质量保证活动预留出一定的时间并提供资源，要确保客户参与需求审查活动。
在与客户确认需求时，应当与客户共同探讨是否有衍生出的需求，直到客户确认无误后再进行下一步的需求分析与确认。
要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或者外界的咨询顾问来评述早先的审查。
需求管理方面的控制
应该推迟实现那些很可能还要发生变更的需求，待确定之后再实现，并在设计时要考虑到应该使系统易于修改。
需求变更过程要包括对提议的变更进行影响分析，组建变更控制委员会作出决策，使用工具支持预定义的过程。
需求跟踪矩阵有助于在设计、构造或者测试期间避免遗漏任何需求。
应该制定分阶段或者增量的交付产品的实现计划。在初始版本中先实现核心功能，在以后的迭代中再逐步增加系统功能。
配置系统管理指南
配置标志
软件项的标识基本按照《软件配置标识命名规则》进行。要通过标识能够确定软件项之间的相互联系。
版本管理
首先在服务器上建立一个目录，作为项目配置数据库。在此目录下按照每个项目组建一个分目录，项目组代码及项目组名构成目录名，然后在此项目组目录下按照所属每个项目建一个子目录，同一项目的开发文档存放在一个目录下，项目编号紧跟项目名就是目录名。在一个项目分目录下可按非受控文档与受控文档建立一级次目录，然后在一级次目录下按文档的不同类型建立二级次目录，使得所有开发文档能分门别类的组织存放，便于查询。
项目子目录的受控文档一般只有项目经理和属于该项目的开发人员和配置管理员能够访问到。配置管理员负责分配访问权限，一般项目经理对该目录具有较大的权限读取、添加和更改；一般开发人员只有读取的权限。
在项目开发的某一阶段结束时，通过了该阶段评审的这些开发文档交配置管理员保存到项目数据库，做为正式版本的第一版1.0版本。
在以后的开发中，如果软件需要修改，那修改后的软件可用多级编号来表示新版本1.1、1.2等加以区别标识。
在各个评审阶段产生的所有评审报告和修改报告都要进行编号保存，编号与相应文档的编号要对应。
变更控制
微小更正时的变更控制
在评审或测试后发现的问题由评审组组长或项目经理形成《软件问题报告单》或《源代码修改记录单》，并通知配置管理员。
由配置管理员将需要修改的软件的备份从项目配置数据库中检出，开发人员执行修改。
修改完毕后进行修改测试，编程错误累计到了一定的量或者测试时间已满一个月（从上一次入配置库后算起），凭《源代码修改记录单》及修改后的源代码，通知配置管理员，配置管理员确定测试报告的完备性，并在核对软件修改内容和修改人员填写的《软件修改报告单》或《源代码修改记录单》中的修改描述一致后，将文件登入项目配置数据库中，生成新版本。
配置管理员修改《软件配置状态表》和《软件变更记录表》，以使其他相关开发人员及时了解软件变化情况。
较大变动时的变更控制
开发人员或用户提出影响较大的修改要求（这是指要增加或删除某些功能或者是发现错误的阶段在造成错误的阶段的后面等）。
配置管理员收到这类修改要求时，必须组织有项目经理以及开发人员参加的修改评审会，讨论修改的影响范围，修改的必要性、可行性以及修改方法、步骤和实施计划。
在修改方案通过并经项目经理审核后，要由产品开发部经理签字批准。涉及重大技术方案的修改时，修改方案必须由总工程师或技术总监签字批准。以决断修改工作中各项活动的先后顺序及各自的完成日期，以保证整个开发工作按原定计划日期完成。
配置管理员在接到修改批准
由项目经理或产品开发部经理或总工程师或技术总监签字同意的《软件问题报告单》后才可将需修改的软件的备份从项目数据库中检出，开发人员执行修改。修改完毕后交客户服务部进行测试和评审，测试和评审都通过后交配置管理员处理。
配置管理员检查测试报告和评审报告是否完备，核对《软件修改报告单》中的修改描述和修改后的软件是否相符。核查结果符合要求，配置管理员将修改后的软件登入项目数据库中，生成新版本。
配置管理员修改《软件配置状态表》和《软件变更记录表》，以使其他相关开发人员及时了解软件变化情况对受影响的软件做出相
应的修改。
配置状态报告
两份配置状态报告
《软件配置状态表》和《软件变更记录表》分别以电子表格的形式存放在项目分目录下，以便项目开发人员随时查询，了解软件的修改变化情况。《软件配置状态表》由配置管理员负责填写，主要反映项目中各软件项的配置情况。开发人员通过查阅该表可及时全面的了解项目中软件项的配置使用情况。
《软件变更记录表》由配置管理员负责填写，主要记录软件开发过程中所有的修改情况，该表以修改时间排序，以便开发人员及时了解软件项最新的变化。
配置审核
为保证各项产品在技术上和管理上的完整性，总经理室在软件开发过程中的详细设计阶段和测试阶段完成时，对配置情况进行抽查。总经理室先提出要审核的内容和各项指标，逐项审核完成后要作好记录，形成《配置审核报告》。
软件需求工程 高校教学平台 需求工程计划相关推荐
- 软件需求工程 高校教学平台 需求变更控制会规程
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 概述 目的 范围 参考文献 角色与职责 角色分配与职责 各成员联系方式 决策制定 指定决策过程规定 交流状态 重新协商原先约定 变更请求状态 开 ...
- 软件需求工程 高校教学平台 需求变更控制文档
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 描述 目的 描述 范围 定义 参考文献 角色与职责 变更请求状态 开始条件 任务 变更请求REQ-001 变更请求REQ-002 变更请求REQ ...
- 软件需求工程 高校教学平台 软件需求规格说明书 part 1 （重点！！！）
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 编写目的 项目背景 预期的读者和阅读建议 预期读者 阅读建议 参考资料 总体描述 产品基本信息 产品前景 用户类及其特征 产品功能概述 用 ...
- 软件需求工程 高校教学平台 软件需求规格说明书 part 3 （重点！！！）
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 学生查看教学班资料 学生下载教学班资料 学生查看教学班作业 学生提交教学班作业(上传资料) 学生查看教学班实验 学生提交教学班实验 学生查看教学 ...
- 软件需求工程 高校教学平台 系统维护计划
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 目的与背景 术语(名词解释) 特别约定 预期读者 参考文献 项目实施及验收简介 系统概述 项目属性 工作任务 维护周期 系统维护成果 项目 ...
- 软件需求工程 高校教学平台 用户手册
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 编写目的 背景 读者对象及阅读建议 参考资料 产品概述 概述 功能 用户管理 通用用户 管理员 教师.助教 学生 游客 课程管理 公共课程 ...
- 软件需求工程 高校教学平台 培训计划
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 目的 范围 参考文献 培训目标 培训对象 培训目标 培训课程 培训合格标准 培训对象设置 培训时间安排 培训详细计划 培训方式 培训要求 ...
- 软件需求工程 高校教学平台 软件概要设计说明书
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 编写目的 背景 定义 参考文献 总体设计 用户需求规定 教师.助教 学生 管理员 游客 其他需求规定 运行环境 基本设计概念和处理流程 结 ...
- 软件需求工程 高校教学平台 系统编码与实现计划
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 编写目的 项目简介 面向读者 设计计划 模块划分 用户管理模块 课程信息管理模块 教学班模块 教学班章节子模块 教学班资料管理子模块 教学 ...
最新文章
- 一篇文章读懂阿里云负载均衡性能保障型实例
- Django模型之数据库操作-查询
- 新冠疫苗厂商科兴成立房地产公司？网友：准备打疫苗送房子了？
- MySQL创建用户（CREATE USER）
- tensorflow随笔 -QueueRunner
- java 中如何实现多进程_在Java中可以使用哪些方法来实现Java的多进程运行模式？...
- navicate 导出批量插入语句
- 阿里巴巴与清华大学成立联合实验室，探索下一代人机自然交互
- 移动app测试流程与测试点
- 谷歌fuchsiaos和华为鸿蒙,华为鸿蒙最大的对手现身！谷歌正式推送Fuchsia OS，或替代安卓...
- linux go环境安装和基本项目结构
- python是c语言_python与c语言
- 烦人的恶意骚扰电话终于要被整治了！移动联通齐发声明...
- 常用的 T-SQL 语言
- Excel函数-数据库函数大全（Excel Database Functions）
- 常用电子元器件基本知识整理
- Google Earth影像数据破解之旅
- catia 二次开发：环境变量路径,检查路径存在,关闭文件,对象为空,获取pad对象,err,part的product,全局变量,常量，SystemService,input,选择文件 时间，函数调用
- 带你撸一台免费云服务器
- 使用Python统计股票高开后的走势