点击查看 软件需求工程 高校教学平台 卷首语

项目章程介绍

项目名称

面向全日制高校的教学平台

项目背景与重要性

在2020年发生的新冠疫情更是将在线教学成为教学的刚性需求。在线教学平台需要让老师和学生在线上进行高效率、高质量的教学、学习和交流等活动。

而21世纪是以互联网的全面深入运用为特征的世纪。网络环境下的教育不仅是教育信息化的必然产物，也是教育改革发展的必然走向。通过因特网或其他数字化内容进行学习交流与教学的活动即网络化学习（E-Learning），可以充分利用现代信息技术所提供的具有全新沟通机制与丰富资源的学习环境，实现一种全新的学习交流方式。从21 世纪开始， 我们的生活就全面的迈入了全新的信息化时代，教育行业也不例外，逐渐的信息技术开始成为教学与学习的重要工具，从初期的投影仪、电脑教室逐渐发展至互动课堂、在线教育。信息技术日益融入教与学的过程，开始引发教学方式和学习方式的深刻变革。华秦教育表示随着教育信息化的大浪潮下，教育信息化将会越来越深刻的影响到教育的发展，势必影响教育变革。

在这一大背景下，教学、学习、交流网站应运而生。超文本特性可实现对教学信息最有效的组织与管理。网络化的学习有利于充分实现交互与共享，有利于激发学生的学习兴趣和充分体现学习主体作用，有利于培养学习者的信息素养和信息能力。另一方面教师利用教学、学习、交流网站可以充分发挥网络特性，对学生，教学进行更为有效的管理，同时也有了更为便利的信息发布手段。

面向全日制高校的教学平台推进教育信息化改革，顺应当代信息共享、共创、充分流通的潮流趋势，对于日常的教学教育工作有重要意义。

项目目标

为教学双方提供教学任务管控和线上交互的平台，便利教学。使得：

• 学生可以方便地获得关于课程与教师的信息（如联系方式等）

• 学术可以随时随地地进行在线课程的学习

• 学生可以方便地获得课程的相关资料和课程通知（如作业发布情况等）

• 学生可以获取最近更新的教学计划

• 学生可以快速知悉课程进展和作业、测试成绩等

• 学生可以方便快捷地参加平台上的在线实验（如FPGA仿真实验等）

• 学生和教师之间可以更方便地交流答疑

• 学生的获得资料更加容易，更加丰富

• 学生能够更及时的接收通知

• 学生可以通过网站进行线上实验、提交作业与测试

• 教师可以更方便的展示自己的教学信息

• 教师可以添加更多的教学资源

• 教师可以调控教学任务（作业）的进程并且进行相关操作

• 教师可以发布测试等

• 教师可以随时发布临时修改的教学计划

• 多个教师之间可以协同教学

• 教师可以方便地收集、点评学生作业

• 师生均可以快捷、方便地加入课时相关的学术论坛中、

• 教师可以进行更加丰富的课堂活动

• 游客能够有机会了解课程信息（如课程介绍、教师介绍，浏览简化版课件等），同时可以免费试看部分课程

实施策略

• 准确把握各方的需求

• 整体规划，分步实施

• 注重数据准备和测试贯穿于项目每个阶段

• 各方用户的提前参与

• 对已经完成的模块提前测试，测试与开发同步，找出其中的不足之处并加以改进

项目范围

版本范围

FE-0：拥有教师信息、课程介绍、友情链接等基本显示

FE-1：允许老师上传课件，视频等学习资源

FE-2：允许老师对学生的信息进行查询与管理

FE-3：允许学生在线浏览和下载课程老师所发布的学习资源

FE-4：允许学生查看作业内容并上传作业报告

FE-5：允许老师在线批改作业或下载学生作业

FE-6：允许师生在讨论区，发表问题、回答问题以及讨论学习心得等

FE-7：允许教师发布通知，删除通知，学生查看通知

FE-8：允许学生查看 自己历次作业的完成情况，老师反馈情况，其他同学完成情况

FE-9：可以自动统计出，每次上交作业的学生名单以及未上交的名单

FE-10：教学辅助系统可以访问学校内的数据库

FE-11：允许学生在该平台进行线上测试，同时教师可以监控到学生的电脑屏幕以及摄像头防止作弊

FE-12：允许该教学平台嵌入线上实验系统

FE-13：实现游客浏览模式，实现可以在线浏览简化版课件等功能

表3-1 范围版本计划表

特征	版本1	版本2	版本3
FE-0	完全实现
FE-1	完全实现
FE-2	完全实现
FE-3	完全实现
FE-4	完全实现
FE-5	暂不实现	完全实现
FE-6	暂不实现	完全实现
FE-7	暂不实现	暂不实现	完全实现
FE-8	暂不实现	暂不实现	完全实现
FE-9	暂不实现	暂不实现	完全实现
FE-10	暂不实现	暂不实现	完全实现
FE-11	暂不实现	暂不实现	完全实现
FE-12	暂不实现	暂不实现	完全实现
FE-13	暂不实现	暂不实现	完全实现

实体范围

个人终端机与公网 IP的云服务器与外网服务器

技术范围

客户化开发范围和软件升级

在系统开发期间不要求进行复杂的客户化开发工作

技术范围

需要在本地安装搭建技术基础设施的来支持课程网站系统的实施，这将包括：

• 管理网络结构

• 管理和维护及建立一个原型系统、系统测试、培训

• 提供一个稳定的生产环境以提供系统实施，包括管理和维护数据库和应⽤服务器，在定期备份，重新启动/恢复和性能监控方面提供恰当的支持

• 确保运行环境的适当的系统性能水准

表3-2 技术配置说明表

软硬件资源名称	级别	详细配置	获取方式与时间	使用说明
开发应用服务器	关键	CPU：i5-8350U 20GB RAM Windows 10 Pro	已经存在	开发阶段使用
测试服务器	关键	CPU：4 Core 8GB RAM Ubuntu 20.04	已经存在	测试阶段使用
开发工具	关键	PyCharm, Vue.js, Nginx, Docker	已经存在	开发阶段使用
性能测试工具 LoadRunner	关键	版本：8.0	已经存在	测试阶段使用
功能测试工具 WinRunner	普通	版本：8.0	已经存在	测试阶段使用
测试管理工具TD	关键	版本：7.6	已经存在	测试阶段使用
配置管理工具Git	关键	版本：2.19.0	已经存在	贯穿所有阶段

限制与排除

LI-1：该系统仅适用于个别个性课程，不能对所有课程服务

LI-2：该套系统还在试验中，主要应用于浙江大学的部分课程，不对外开放

文档

在开发过程中提供详尽的开发文档，并对撰写特殊需求文档进行必要的指导。

项目组织结构

表4-1 项目角色分配

角色	职责	人员
项目经理	在预算范围内按时优质地领导项目小组完成全部项目工作内容，并使客户满意。	xxx
产品经理	负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等，根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略。	xxx
设计总监	建立系统框架；数据库设计；概要设计； 参加技术评审；	xxx
测试经理	组织编写测试计划和测试方案，组织系统测试；参加技术评审；	xxx
美工	设计网站原型	xxx
质量经理	带领软件质量监督组成员制定质量保证计划，对监督组反映的质量问题进行汇总与产品经理、项目经理进行交流，当新的问题出现时最终由质量经理决定处理方式。	xx x
开发人员	负责进行编码工作与单元测试，进行系统集成，及时解决测试时出现的问题	全体成员
测试人员	编写测试方案和测试用例，进行系统测试，向开发组反馈 BUG。	全体成员
软件质量监督	实时对质量经理以及项目经理提供项目进度与项目实际开发时的差异提出报告，指出差异原因和改进方法。	xxx

项目计划

项目阶段划分及关键任务

表5-1 项目阶段划分及关键任务

项目阶段	持续时间	负责人	主要工作	输出内容
项目启动	2020.09.23-2020.10.07	xxx	进行项目可行性分析，制定项目计划	完成《项目可行性分析报告》《项目章程》《项目计划》
需求分析	2020.10.08-2020.11.20	xxx	确定系统运行环境，确定系统功能及性能，建立系统逻辑模型	完成**《前景与范围》《质量保证计划》《需求工程计划》《软件需求规格说明书》**
系统设计	2020.11.20-2020.12.01	xxx	进行系统设计	完成《系统设计计划》《系统编码实现计划》《软件概要设计说明书》《测试计划》
编程实现	2020.12.02-2020.12.22	xxx	进行系统编码	实现并部署网站，完成《用户手册》《工程部署计划 》《培训计划》
需求维护	2020.11.30-2020.12.29	xxx	进行需求变更控制	完成**《需求变更控制会规程》《需求变更控制文档》** ，更新**《软件需求规格说明书》**
系统测试	2020.12.22-2021.01.10	xxx	进行系统测试，项目总结	完成《测试报告》《系统维护计划 》《项目总结报告》

项目计划执行和报告

项目经理对监控项目进展负主要责任，项目计划是用于通报项目进展和当前状态的关键性文件。项目计划包括项目阶段，任务，任务期限，资源，任务的计划开始和结束日期，里程碑，责任人和可交付成果等。

项目计划执行和报告应按照流程进行。每个项目组成员将负责按照项目计划更新实际进展情况并估算自己分配到的任务距离完成还需多少时间，这些工作是每周项目报告例会的一部分。项目组每周五会晤一次，参照项目计划审查项目进展情况，审查工作以考察拖延情况为基础，集中精力查找现存的或潜在的任务拖延，评估对项目造成的影响，并对要采取的减轻影响的行动计划达成一致意见。对于那些存在拖延可能的任务，项目经理加以突出表示。该任务的负责人应制定出一个应对潜在拖延的行动计划以减少对其他项目工作造成的影响。

项目文档管理

项目文档管理的重要性

项目文档管理常见问题

• 文档存储分散，难以统一控制，易丢失
  大部分的文档都分散于不同员工的电脑里，丢失风险大。项目组成员获取相关文档信息不便，影响工作效率。
  

图6-1 文档的分散性

• 重要文件修改没有留痕，找不到责任人
  重要的项目文件被修改，查询不到文档操作记录，找不到相关责任人，文档安全难以保障。

• 文档版本多次被修改，无法确定最终版本
  项目文件被多人进行校阅，修改，导致最终版本混乱，无法区分最新版本，一旦看错文件，将会对项目进度及项目质量造成重大损失。

• 流程审批过程繁琐，异地难审批
  使用传统的纸质流程，或者PC端线上审批流程，审批节点冗长而繁复，完成一个流程的审批需花费大量时间，未能及时获得审批信息，导致延误工期，造成损失。

• 大文档传输不便，文档搜索查找困难
  电脑硬盘存储了非常多的文件，随着文件越来越多，查找所需要的文件就会变得越来越困难。

重要性

项目文档管理，是指在一个系统项目开发进程中将提交的文档进行收集管理的过程。大部分开发者通常并不注重项目的文档管理，而是在项目管理产生混乱后，才意识到其重要性。

作为管理完善的项目文档，管理者完全可以依顺它的轨迹看清整个项目进展的脉络，同时通过对阶段性文档的把握使整个项目质量得到很好的掌控。制定一套完整有序的项目文档管理规定十分必要，其作用有以下6个方面。

1. 它是项目管理者了解开发进度、存在的问题和预期目标的管理依据。

2. 大多数软件开发项目会被划分成若干个任务，并由不同的组去完成。文档管理则是不同小组任务之间联系的重要凭证。

3. 可提供完整的文档，保证了项目开发的质量。

4. 项目文档是系统管理员、操作员、用户、管理者和其他相关人员了解系统如何工作的培训与参考资料。

5. 项目文档将为系统维护人员提供维护支持。

6. 项目文档作为重要的历史档案将成为新项目的开发资源。

现在大多数金融、通信企业为了更好的服务客户、准确掌握自身数据，都在不遗余力地建立数据仓库系统。企业数据仓库（EDW）从筹建项目组到软件开发建设再到系统上线维护，基本涉及了软件项目建设的所有环节，对文档管理提出了比较全面的要求。以下就EDW建设为例做作进一步探讨。

首先要借助VSS软件建立项目文档管理服务器以保存所有的项目文档。其次，项目保存的文档要涵盖项目管理、项目调研、项目开发、项目应用、系统管理、系统测试验收、项目培训、版本控制、数据质量管理、用户手册、系统上线等整个项目周期。然而从项目管理者的亲身体会来讲，这些文档的保存往往是混乱无序，无法快捷地获得所需信息。究其原因，项目组在系统开发过程中虽然重视了文档的保存，但却忽视了文档的管理。文档归档没有正式的管理要求，缺少文档提交的依据和规则。最后是建立文档管理规定。

通过对项目的文档进行管理，项目地开发者和管理者能够很好地对整个项目的进展情况进行把握；不同的开发人员之间也能够通过文档保持模块之间的联系；系统维护人员也能够通过文档便捷地找到问题所在之处并进行维护；此外，文档作为整个项目的重要组成部分，
能够全面地反映出整个项目的架构和设计思路，可以为项目的重用、重构等提供借鉴价值。

实现高校教学平台系统是一个比较复杂的工作，而项目的文档是整个软件开发过程中的指南和规范约束，因此项目文档编写在软件开发过程中具有举足轻重的地位。所以我们会在项目开发过程中使用工程化的原理和方法来指导软件的开发，充分注意软件文档的编制和管
理，提高项目管理水平和项目的实施效率。

在本章程中，我们将对整个项目开发流程中的需求分析、设计分析、项目测试、使用说明等文档进行了规范和约束。另外，我们还将对文档的内容和具体格式进行了规定，项目组的每位成员都将严格按照要求进行工作，并且所有文档都需经过小组组长审核确认。

项目文档体系

表6-1 项目文档体系

文档名称	项目阶段	文件格式	完成日期
《项目可行性报告》	项目准备	Word 文档	2020.10.07
《项目章程》	项目准备	Word 文档	2020.10.07
《项目总体计划》	项目准备	Word 文档	2020.10.07
《前景与范围》	项目准备	Word 文档	2020.10.18
《质量保证计划》	项目准备	Word 文档	2020.10.18
《需求工程计划》	项目准备	Word 文档	2020.10.07
秋学期小组例会纪要 （第4至第9周）	项目准备	Word 文档	2020.11.15
《软件需求规格说明书》	项目准备	Word 文档	2020.12.13
《系统设计计划》	蓝图设计	Word 文档	2020.12.20
《需求变更控制会规程》	蓝图设计	Word 文档	2020.12.20
《系统编码与实现计划》	系统实现	Word 文档	2020.12.27
《测试计划》	系统实现	Word 文档	2020.12.27
《需求变更控制文档》	系统实现	Word 文档	2021.01.03
《用户手册》	系统实现	Word 文档	2021.01.03
《软件需求规格书》更新	系统实现	Word 文档	2021.01.10
《测试报告》	系统实现	Word 文档	2021.01.10
《工程部署计划》	系统实现	Word 文档	2021.01.10
《培训计划》	系统实现	Word 文档	2021.01.10
《系统维护计划》	验收交付	Word 文档	2021.01.10
《项目总结报告》	验收交付	Word 文档	2021.01.10
《全部小组例会纪要》	验收交付	Word 文档	2021.01.13

管理方法

从各行业以及每个项目的个性出发，需要管理者结合实际情况制订出适合自身的文档管理规定。《软件文档管理指南》和《计算机软件产品开发文件编制指南（GB 8567-88）》（以下统称《指南》）为我们提供了相关的指导。首先要明确关于软件项目文档的具体分类。《指南》中提出文档从重要性和质量要求方面可以分为非正式文档和正式文档；从项目周期角度可分为开发文档、产品文档、管理文档；更细致一点还可分为l4类文档文件，具体有：可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发卷宗、测试计划、测试分析报告、开发进度月报、项目开发总结报告。这样的分类细化了项目进度中各个阶段所需管理的文档。

其次需要将项目文档进行归类整理。下面以EDW项目组文档情况与软件文档管理指南作为例子进行对比分析。通过对比可以看出，没有规范管理的EDW项目组文档存在以下4方面的问题：

1. 项目组在开发初期针对业务部门和科技部门进行了需求及信息调研，可以覆盖部分软件需求和数据需求说明书的内容，但却缺少业务部门对项目需求描述和变更的文档记录。这部分文档需建立相应目录予以保存。

2. 对于设计说明，在系统比较复杂的情况下，设计阶段应分解成概要设计和详细设计两个步骤。EDW项目组只对ETL模块提供了概要设计说明书，并没有单独的存放目录，而是同其他设计文档混乱地放在一起。对于比较复杂的应用开发项目，应将这两种设计说明文档分目录管理。

3. 在项目测试验收中，项目组没有要求将测试计划文档和测试结果报告进行规档，而只重视了测试过程中的问题文档，因此无法掌控测试进度与质量。

4. EDW项目组的工作分为模型设计、ETL、集市应用3个工作小组，对应的文档管理需要围绕这3个主题进行。其中模型设计和ETL都是数据仓库项目实施的模块，而集市应用则包括了建立在数据仓库基础上的小项目开发。因此，文档管理也应该针对这3个部分不同的性质制定管理规则。

通过表l中的对比分析，针对EDW文档管理存在的问题，EDW项目组最终依据通用规则建立了正式的项目文档管理规定。具体规定有以下5点：

1. 将文档分为两大部分提交管理：项目常规文档和项目归档文档。常规文档的提交和使用根据项目组内部小组成员任务的不同进行权限划分；项目归档文档由项目管理主管（或项目文档管理员）将项目中的重要文档从常规文档中进行分类归档。

2. 常规文档管理目录分为项目日常管理文档和项目流程管理文档。

3. 日常管理文档包括项目报告、会议纪要、项目管理模板、重大问题跟踪、数据质量管理。项目报告又可分为个人周报、小组周报、项目周报、项目简报，项目简报。并都按照不同目录进行分类管理。

4. 提交完整的项目开发、应用开发流程文档。一般包括：项目计划、业务需求说明书、数据需求说明书、模块、应用开发文档、系统测试文档、详细设计文档、系统测试文档、用户手册、上线文档、培训资料、系统运行维护等。

5. 所有项目组成员均建立VSS软件环境下的对应用户，各自拥有对以上各类文档的读、写、增加、删除权限。由各项目小组长保证提交已保存文档的质量；由文档管理员或项目经理整体把握项目文档在各阶段的提交情况。

项目文档管理规范制定好之后，关键在于大家要“依规执行”，使杂乱无章的存放模式变得井井有条。

文档管理环境

整个项目的文档统一在Git仓库中进行管理，小组成员每次在对文档进行修改后，统一推送到Git仓库中进行合并，并通知其他小组成员及时更新。最终由组长核验文档并打包发送给助教（或老师）。其他的代表管理软件有：

• edoc2文档管理系统

  edoc2为企业提供了一个易用，安全，高效的文档管理系统。通过edoc2，企业可以集中存储和管理海量文档和各类的数字资产（如Office文档，电子邮件，多媒体文档，工程设计文档等等）。edoc2采用了领先的文档权限控制和加密技术，以保障文档的安全。通过edoc2企业可以更高效地管理文档的整个生命周期：创建、修改、版本控制、审批程序、存储、查询、重用以及归档。edoc2完整的产品线可以适应任何规模和复杂程度的公司体系。

• 凌云文档管理系统

  凌云文档管理系统，包含企业网盘、企业文控、证照管理、项目文档管理、档案管理、合同管理等众多具体业务解决方案。系统基于Alfresco，是国内目前领先的Alfresco传播与推广者，系统支持企业内部部署，并提供源代码、二次开发手册及开发培训服务，助力企业搭建ECM（企业内容管理）平台，有效管理非结构化数据。

• SecGateway文档管理系统

  是一款专用于企业数据中心与办公网络有效隔离的嵌入式专用设备。采用链路加密的方式，实现客户端的准入，从文件在企业的使用流程入手，将数据泄露防护与企业现有
  OA 系统、文件服务系统、ERP 系统、CRM
  系统等企业应用系统完美结合，对通过网关的文档数据进行透明加解密工作，有效解决文档在脱离企业应用系统环境后的安全问题。为企业部署的所有应用系统提供有效的安全保障。

• HOLA企业内容管理系统

  HOLA企业内容管理系统，可以实现标准企业级的文档管理功能，还提供超过200种格式的文档与图纸的阅读与红线标注、纸质文档的电子化、文档相关的日期提醒与任务管理、以及在海量数据中快速查询功能。

项目沟通管理

项目决策流程

在日常的项目开发中，常常会因为项目的范围、时间规划和成本等因素对项目进行调整，因此整个项目开发小组需要对这些事物进行决策。本章节将对项目决策的流程做出一般性地指导方案。

对于那些会造成项目范围、项目资源、项目时间变更的决策：需要利用变更管理中描述的变更控制流程进行处理；

对于不会造成项目范围、项目资源、项目时间变更的决策：则由小组成员自行决定，并及时上报小组长进行备注，对于小组成员难以决策的问题，则通过小组会议进行商讨解决。

开发者与用户的沟通计划

在高校教学平台系统中，系统的目标用户为教师、学生和游客。为了方便了解各类用户对于系统的需求，开发者应当与每个不同用户群体的代表进行至少两次的项目交流，交流可以通过线上交流（线上电话、聊天软件等）或是线下交流（具体时间和地点可以通过电子邮件或者电话短信来确定）的方式进行。每次沟通最好能够进行录音并做相应的记录。

项目例会

小组开发者之间平时的沟通可以通过聊天软件、电话短信、电子邮件和云盘等途径来进行，而小组例会目前暂定于每周五中午举行，由小组长主持，每位项目开发者都需要参加，由于特殊情况请假需要事先登记。

若请假人数超过全组 1/3 则需要对会议时间进行调整或是以线上电话会议替代。

每次会议需要讨论的内容有：上周会议中为解决问题的反馈；本周项目进展情况汇报；下周需要完成的工作与时间安排；项目进展过程中遇到的问题等等。如果这些问题难以在会议上快速解决，小组长需对问题进行记录，并终止该话题的讨论，以确保会议时在计划时间内完成，该问题将通过另外的线上途径进行解决并于下周例会反馈。

项目风险管理

实施周期延期的风险

对于由小组内部制定的时间规划表完成日期的不确定性产生的实施周期延期的风险，可以通过小组例会及时跟进项目进度、监督项目按计划实施的方式来确保项目的顺利进行。而因课程安排（如节假日、校运会或是大型比赛而造成的调课）导致的时间拖延的风险，可以由小组成员统一协调并向指导老师说明原因，确保进度的进行。

实施范围的风险

在项目的开发过程中，如果开发者在某一实施分步内实施的主体范围过多，可能会导致项目延期，解决的办法是对整个项目按照实施计划分步实施。对于过分关注细节而导致项目耗费了过多的时间在开会上的情况，则需要以实施目标为重点，采取先完成基本功能，后推进改进的策略。此外需要按照实施计划建立各个步骤的实施目标值，以防止在某一实施分步内实施模块过多导致项目延期的情况发生。

人员的风险

一方面，有些项目开发者可能会存在因为身体状况、情绪变动或是其他因素而导致消极怠工的情况，另一方面有些项目开发者可能存在经验、开发水平不足的情况而难以胜任某一模块的开发任务。对于以上两种情况的解决方案是，根据个人能力，分配合适的开发任务，同时要求小组成员在课余时间积极学习开发技术，遇到问题及时提出；项目组长也应该定期与每位开发者进行工作情况的交流。此外，还要建立有效的奖惩措施，以提高开发者开发项目的热情和积极性。

项目变更管理

微小改正时的变更控制

表9-1 微小更正时的变更控制

人员	流程
项目经理	在评审或测试后发现的问题由评审组组长或项目经理形成《软件问题报告单》或《源代码修改记录单》，并通知配置管理员。
配置管理员	由配置管理员将需要修改的软件的备份从项目配置数据库中检出，分配给开发人员执行修改。
开发人员 测试员	开发人员执行修改，完毕后进行修改测试，编程错误累计到了一定的量或者测试时间已满一个月（从上一次入配置库后算起），凭《源代码修改记录单》及修改后的源代码，通知配置管理员。
配置管理员	配置管理员确定测试报告的完备性，并在核对软件修改内容和修改人员填写的《软件修改报告单》或《源代码修改记录单》中的修改描述一致后，将文件登入项目配置数据库中，生成新版本。
配置管理员	配置管理员通过修改《软件配置状态表》和《软件变更记录表》，以使其他相关开发人员及时了解软件变化情况。

较大变动时的变更控制

表9-2 较大变动时的变更控制

人员	流程
开发人员/用户	开发人员或用户提出影响较大的修改要求（这是指要增加或删除某些功能或者是发现错误的阶段在造成错误的阶段的后面等）。
配置管理员 项目经理 开发人员	配置管理员在收到这类修改要求时，必须组织有项目经理以及开发人员参加的修改评审会，讨论修改的影响范围，修改的必要性、可行性以及修改方法、步骤和实施计划。
开发经理 技术经理	在修改方案通过并经项目经理审核后，要由产品开发部经理签字批准。涉及重大技术方案的修改时，修改方案必须由总工程师或技术总监签字批准。以决断修改工作中各项活动的先后顺序及各自的完成日期，以保证整个开发工作按原定计划日期完成。
配置管理员	配置管理员在接到修改批准——由项目经理或产品开发部经理或总工程师或技术总监签字同意的《软件问题报告单》后才可将需修改的软件的备份从项目数据库中检出，分配给开发人员执行修改。
开发人员 测试员	开发人员进行修改，完毕后，交客户服务部进行测试和评审，测试和评审都通过后，交配置管理员处理。
配置管理员	配置管理员检查测试报告和评审报告是否完备，核对《软件修改报告单》中的修改描述和修改后的软件是否相符。核查结果符合要求，配置管理员将修改后的软件登入项目数据库中，生成新版本。
配置管理员	配置管理员通过修改《软件配置状态表》和《软件变更记录表》，以使其他相关开发人员及时了解软件变化情况对受影响的软件做出相应的修改。

质量控制

• 项目章程由教师和学生双方进行审阅、批准。

• 业务蓝图由教师和学生双方进行审阅、批准。

• 用户文件和培训计划由项目小组进行审阅、指定。

验收标准

总则

本章为本项目所需要的管理和技术两方面的评审检查工作，同时提出了项目评审与检查流程，以及相应通过判断的技术准则。对于新建立的开发任务，或正在开发当中的系统，我们将应用GB8567的标准进行各项阶段性的评审任务。面向完整的开发过程，我们应进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等，至少八个方面的评审和检查工作。

第一次评审

本阶段的评审将包括软件需求评审、概要设计评审以及软件验证与确认评审。

• 软件需求评审：确保在软件需求规格说明书中，合理规定各项需求。

• 概要设计评审：评价软件设计说明书中，软件概要设计等技术的合适性。

• 软件验证和确认评审：评价软件验证与确认计划中，已经确定的验证和确认方法的合适性与完整性。

第二次评审

本次评审包括详细设计评审、功能测试与演示评审，并对之前第一次评审的结果进行复核。如果在项目的开发过程中，发现需要对第一次评审的结果进行修改，则应按照《软件配置管理计划》的规定处理。

• 详细设计评审：确定软件设计说明书中的详细设计，满足软件需求规格说明书中所描述的详细设计，并在功能、算法和过程描述等方面具有合适性。

• 测试评审：对所有的程序结构单元进行静态分析，检查程序的总体结构（即模块和函数的调用关系和调用序列）和变量使用是否正确。在通过静态分析后，需进行结构测试和功能测试。在结构测试中，所有程序单元结构测试的语句覆盖率（C0）
  必须为100%，分支覆盖率（C1）
  必须大于或等于85%。要给出每个单元的输入和输出使用变量的变化范围。对于各个子系统，只进行功能测试，不单独进行结构测试，因而要登录程序单元之间会话等接口的变量值，力争满足单元测试的C1与C0准则所用到的测试用例能够在子系统功能测试时，重新复现。测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时，不仅要运行变量的等价值，而且要运行变量的边界值；不仅要运行测试组给出的测试用例，而且要允许运行其他相关开发人员、评审人员选定的采样用例。

第三次评审

本次评审要进行功能检查、物理检查和综合检查。这些评审工作应在集成测试阶段结束后进行。

• 功能检查：确认所开发的项目已满足在软件需求规格说明书中规定的所有需求。

• 物理检查：验证程序实现和文档已经一致、并已做好了交付的准备。

• 综合检查：验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

验收与答辩

该项目由教师完成集成后系统的最终验收，小组内同学对项目成果进行展示和答辩。