需求工程计划

《需求工程计划》由会员分享，可在线阅读，更多相关《需求工程计划（27页珍藏版）》请在装配图网上搜索。

1、软件工程课程网站系统需求工程计划V1.0组长：胡琼英组员：宋心怡、林蔡勇、邵一哲、杜玲炯、杜逸先日期：2014.10.15目录目录 II第1 章 引言 11.1 编写目的 11.2 业务机遇 11.3 业务目标 11.4 参考资料 2第2 章 项目概述 32.1 工作内容 32.2 开发人员 32.3 产品 32.3.1 需要移交用户的文件 42.3.2 服务 42.3.3 非移交的产品 42.4 验收标准 52.5 项目相关信息 52.6 系统运行环境 6第3 章 时间管理计划 73.1 工作任务的分解 7第4 章 范围管理计划 8第5 章 成本管理计划 10第6 章 质量管理计划 116.

2、1 教师（助教）需求 116.2 管理员需求 126.3 学生需求 126.4 网站游客需求 136.5 系统功能需求 13第 7 章 沟通管理计划 147.1 开发者与客户沟通计划 147.2 开发者内部沟通计划 14第 8 章 风险管理计划 158.1 风险评估 158.1.1 需求获取方面的风险 158.1.2 需求分析方面的风险 158.1.3 编写需求规格说明方面的风险 158.1.4 需求确认方面的风险 158.1.5 需求管理方面的风险 158.2 风险控制 168.2.1 需求获取方面的控制 168.2.2 需求分析方面的控制168.2.3 编写需求规格说明方面的控制 168.

3、2.4 需求确认方面的控制 178.2.5 需求管理方面的控制 17第 9 章 配置系统管理指南 189.1 配置标志 189.2 版本管理 189.3 变更控制 189.3.1 微小改正时的变更控制 189.3.2 较大变动时的变更控制 199.4 配置状态报告 199.5 配置审核 20第1章 引言1.1 编写目的项目管理与软件需求，作为软件工程当中最为重要的组成几个部分，已经引起了业内 人士的高度重视。项目管理和需求工程概念的提出，就是为了把软件工程化，以更有效地 开发需求，开发软件并实现有效的管理。为了让教师能把最新、最前沿的关于项目管理和 需求工程的信息传播给学生，为了让学生能够利用

4、网络得到老师帮助，为了师生之间、同 学之间能够充分交流，沟通心得，这个软件工程课程网站系统将提供这样一个教学、学习、 交流的平台，为教师和同学服务，也为项目管理、需求工程、统一建模等软件工程化课程 的教学方法提供试验基地。1.2 业务机遇21 世纪是以网络的全面深入运用为特征的世纪。网络环境下的教育不仅是教育信息化 的必然产物，也是教育改革发展的必然走向。通过因特网或其他数字化内容进行学习交流 与教学的活动即网络化学习(e-learning),可以充分利用现代信息技术所提供的、具有全新沟 通机制与丰富资源的学习环境，实现一种全新的学习交流方式。这种学习交流方式将改变 传统教学中教师的作用和师生

5、之间的关系,从而根本改变教学结构和教育本质。美国教育 部 2000 年 12 月向国会递交的“国家教育技术计划”中打算以网络化学习作为提高年青一 代“21 世纪能力素质”的根本措施。技术的教育应用成为教育改革和人才培养的重要途径 之一。在这一大背景下,教学、学习、交流网站应运而生。超文本特性可实现对教学信息最 有效的组织与管理。网络化的学习有利于充分实现交互与共享,有利于激发学生的学习兴 趣和充分体现学习主体作用,有利于培养学习者的信息素养和信息能力。另一方面教师利 用教学、学习、交流网站可以充分发挥网络特性,对教学进行更为有效的管理,同时也有 了更为便利的信息发布手段。1.3 业务目标虽然如

6、今有很多教学网站,但是专门针对一门新开的大学课程和一位专门的教师,又 为学生之间提供交流平台的网站为数不多。这个网站作为一个开课的辅助工具，将有利于 教师的教学和学生的学习；也为软件工程系列课程的成熟记录下足迹。这个网站的主要目的就是为教师和学生提供交流的平台，方便教师，方便学生。这个 网站还为一些对这门课程感兴趣的人士提供一个了解的机会。 教师能够更好，更容易地得到学生的反馈，调整自己的进度或方法 教师可以方便地点评学生作业 有助于提高教师知名度和影响力，方便同学了解教师 学生的获得资料更加容易，更加丰富 学生能够有针对性地进行补课，如果有缺课的话 学生可以方便地向老师提出疑问 并且可以迅速

7、的得到解答 游客可以有机会了解这门课的情况，教师的情况这个网站预计会在学期结束时完成最终版本。表 1 任务简略图软件名称软件工程课程网站系统提出者软件需求分析与设计课程组开发团队组长：胡琼英组员：宋心怡、邵一哲、林蔡勇、杜玲炯、杜逸先1.4 参考资料1、项目描述 141011.pdf2、课程的 PPT3、用户沟通交流第2章 项目概述2.1 工作内容软件开发的流程为：沟通、策划、建模、构件以及部署，根据不同的模型可以采用不 同的开发方法。由于此系统较为小型，且需求较为详细明确，故采用最传统的经典生命周 瀑布模型。在项目开发初期，需求的获取十分重要，需要定义需求开发过程，编写前景和范围文 档，确定

8、用户群和他们的特点，为每类用户选择代言人，建立典型用户的中心小组，与用 户代表沟通以确定用例，确定系统事件和响应，召开专门的需求获取讨论会，观察用户工 作的过程，检查当前系统的问题报告来进一步完善需求，跨项目重用需求。由于此课程重点在于需求的获取，因此这一部分会尤其详细些，当获取需求后，开始 进行项目估算，进度计划，项目跟踪，完成策划这一部之后，开始进行建模分析与设计， 接着构建项目，包括编码与测试，最后进行项目的最终部署，包括交付给客户，以及进行 反馈。2.2 开发人员表 2 开发人员信息表开发人员学院专业组内地位技术水平胡琼英计算机科学与技术学院软件工程组长中等宋心怡计算机科学与技术学院软

9、件工程组员中等邵一哲计算机科学与技术学院软件工程组员中等林蔡勇计算机科学与技术学院软件工程组员中等杜玲炯计算机科学与技术学院软件工程组员中等杜逸先计算机科学与技术学院软件工程组员中等2.3 产品2.3.1 需要移交用户的文件表 3 需移交的文件表项目章程可行性分析报告总体项目计划需求工程计划-初步前景与范围质量保证计划需求工程计划软件需求规格说明书系统设计计划需求变更控制文档用户手册软件概要设计说明系统编码与实现计划测试计划工程部署计划培训计划系统维护计划项目总体报告2.3.2 服务表 4 开发者向服务名称服务内容服务期限人员培训当面培训系统使用方法一周系统安装上门安装一天维护远程在线或者上门

10、服务一年2.3.3 非移交的产品软件开发结束后，以下文档开发人员不需要移交给客户：人员分组表，概要设计说明书，数据库设计手册，代码与文档调整意见书，源代码文档，例会纪要。2.4 验收标准表 5 验收标准表格项目章程验收标准可行性分析报告文档规范，内容翔实总体项目计划文档规范，内容翔实需求工程计划-初步文档规范，内容翔实前景与范围文档规范，内容翔实质量保证计划文档规范，内容翔实需求工程计划文档规范，内容翔实软件需求规格说明书文档规范，内容翔实系统设计计划文档规范，内容翔实需求变更控制文档文档规范，内容翔实用户手册文档规范，内容翔实软件概要设计说明文档规范，内容翔实系统编码与实现计划文档规范，内容

11、翔实测试计划文档规范，内容翔实工程部署计划文档规范，内容翔实培训计划文档规范，内容翔实系统维护计划文档规范，内容翔实项目总体报告文档规范，内容翔实2.5 项目相关信息项目批准者：软件需求分析与设计课程老师 项目批准日期：2014 年 9 月 22 日 项目截止日期：2015 年 1 月 17 日考试周前2.6系统运行环境本网站要求提供对外服务的能力，保证至少 300 名同学上课辅助服务的要求。包括数 据存储能力，网络服务吞吐能力，数据安全特性等。服务器选用Intel CPU，可以选择Windows或者Linux。开发平台可以选择 IIS,， .NET 或者 apache,， tomcat/jb

12、oss 平台。 请提供对外服务所要求的相应的安全保障。第3章 时间管理计划3.1 工作任务的分解表 6 任务人员分工表项目任务（及里程碑）截止日期分组，建立通讯录、角色分工、例会制度、日报制度等完成人员分组表Oct 10撰写项目章程Oct 11撰写项目可行性报告撰写项目总体计划撰写需求工程计划-初步Oct 18撰写前景与范围Oct 25撰写质量保证计划Nov 1撰写需求工程计划Nov 8第4至8周小组例会纪要Nov 20撰写软件需求规格说明书Dec 13撰写系统设计计划撰写需求变更控制会规程Dec 20撰写系统编码与实现计划撰写测试计划Dec 27撰写需求变更控制文档撰写用户手册Jan 3撰写

13、软件概要设计说明撰写工程部署计划 撰写培训计划撰写系统维护计划 撰写项目总结报告Jan 10全部小组例会纪要Jan 17第4章范围管理计划网站的范围：1.信息发布 2.资料上传下载 3.交流互动表 7 需求工程范围管理表开发阶段具体内容知识技能培训培训需求分析员培训用户代表和管理者培训开发人员创建项目术语表需求获取定义需求开发过程 撰写前景和范围文档 确定用户群和他们的特点 为每类用户选择代言人 建立典型用户的中心小组 与用户代表沟通以确定用例 确定系统事件和响应 召开专门的需求获取讨论会 观察用户工作的过程 检查当前系统的问题报告来进一步完善需求 跨项目重用需求需求分析绘制关联图创建用户界面

14、和技术原型 分析需求的可行性确定需求优先级为需求建模创建数据字典将需求分解到子系统 应用质量功能调配规格说明采用SRS模板确定需求来源为需求分配唯一标号记录业务规则定义质量属性需求验证申查需求文档 测试需求 定义合格标准需求管理定义需求变更控制过程成立变更控制委员会 分析需求变更的影响 建立基线和控制需求文档的版本 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求的稳定性 使用需求管理工具 创建需求跟踪矩阵项目管理选择合适的软件开发生命周期根据需求制订项目计划需求变更时更新讨论项目承诺管理与需求相关的风险以及编写风险文档跟踪需求工程的投入从其他项目的需求工程中积累经验第5章 成本管理计划开

15、发者人数：5人 开发时间：4 个月 需求工程经费预算表 8 需求工程经费预算表开发阶段经费（元）知识技能培训100需求获取50需求分析200规格说明50需求验证50需求管理100项目管理100总价650第6章 质量管理计划软件工程课程网站系统是用于教学、学习、交流的网站，因此对其的客户需求分析可 以分为教师、助教、管理员、学生与普通的网站游客。6.1 教师（助教）需求1、网站上可以发布系统的课程介绍，包括项目管理与案例分析、软件需求分析与设计等 几门课的课时安排、教学计划、使用教材、国际国内背景、考核方式、和学生选这门 课所需要的知识背景，以及大作业的介绍，并可以在以后增加另外课程的时候可以定

16、 制。2、网站要有教师介绍，对任课老师的以往教学、科研成果、及其教学风格，出版书籍,所 获荣誉的详细介绍，但此项信息只有管理员可以修改，教师不能修改。3、网站要有助教介绍，对助教的以往助教经历、能力以及学生评价等的介绍，但此项信 息只有管理员可以修改，助教不能修改。4、教师能够进行课件、模板、参考资料、以往优秀作业、教学视频、音频资料下载、上 传与删除操作，并且可以及时更新。教师上传资料时可以选择资料类别，该类别用于 在显示上传的资料时按照该类别进行显示，教师上传资料不限大小，教师删除的资料 进入回收站。5、教师或者助教对作业的批改采用线上批改而非线下批改。6、教师消息发布栏用于教师发布作业点

17、评、临时课程变更等通知。通知按照时间进行排 序，另设一栏专门用于发布重要通知或者置顶重要通知。7、重要信息：按照上传时间排序，最新的重要信息置于最上面。8、最新信息:公布老师最近的一些教学或外出交流的心得,以及网站一些资料与课件等的 最近更新信息的介绍。最新信息按照上传时间排序排在重要信息后面，最新信息不超 过 5 条，超过 5 条后系统自动删除最旧的信息。9、友情连接（如网上选课主页）有老师要求管理员实时更新。10、在批改作业界面提供教师与助教的专门的作业点评栏目，作业完成情况跟踪的功能， 对学生的作业和课后作业讨论进行点评。11、提供专门的课程作业评分，平时成绩评分，期末考试或论文考核的评

18、分，最终成绩的 各项组成的比例的调整，以及根据每项的成绩统计出每个学生的最终成绩。12、网站上要有网站向导即使用指南。6.2管理员需求1、网站上可以管理相关课程信息，包括每门课的任课老师，每门课的选课学生名单，同 时可以管理每个人的网站权限。2、网站上可以管理课程页面的所有信息，包括课程介绍、教师介绍、助教介绍、课件、 模板、参考资料、以往优秀作业、教学视频、作业点评，具体的管理措施可以是下载、 上传、发布、删除。3、管理员不可修改除自己外的用户密码，但可在用户忘记密码时经用户同意重置用户密 码（随机数）并将用户新密码发送到用户邮箱。4、对友情连接（如网上选课主页）的实时更新。5、管理员可管理

19、回收站，可对回收站内的资料进行永久清除资料操作或者恢复资料操作。6、管理员可设置多人担任。6.3 学生需求1、能下载老师提供的课件，包括以往的旧版本课件，以及最新的课件。2、能下载老师提供的参考资料（含电子教材、历年试卷、补课资料,以及老师的教学交流 文章）并且网站能及时更新这些资料。下载的速度能够得到保证:要求同时可容纳10人 下载,并且人均速度能达到50kb/s。3、能上传对课程有用的资料，但教师助教以及管理员有权删除这些资料。4、能及时看到老师的通知（含课程相关通知及作业点评）。5、如果教师提供的是多媒体资料,网站能提供下载及在线观看功能（如课堂录像）。6、网站界面要求简洁大方，有网站导

20、航、相关链接（含学校选课系统、学院网页、需求相 关主题网站）。文件的排序方式可选，增加一个选择框，学生可根据自己的不同需求来 选择按照不同的方式来进行网站显示文件的排序。7、网站提供通过提问方式的密码取回功能。假如用户未设置问题，则可通过向用户申请 账号时绑定的邮箱或者短信发通知来取回密码。8、网站能提供让分组的各个团队能有团队内部的交流工具（如论坛,不同团队可以申请认 证板块，非团队成员不能浏览使用,但教师或者助教可以进入各个板块进行一定的指导 而网站管理人员也可管理认证板块）。同时，内部交流工具要支持文件上传功能，可以 不仅仅支持文字交流，也可以增加图片，音频等交流。9、网站能提供一定资料

21、共享功能（如论坛有上传下载附件功能，也可支持批量上传与下载但对附件大小有限制，每个附件大小不得大于2M）。10、网站能较醒目地提供教师的联系方式 （尽量详细）。11、网站可以提供站内文章标题搜索功能。12、网站能够提供学生自身作业提交功能,并可以跟踪作业的批复情况（包括评分评语等）。学生提交作业的格式只能是PDF与压缩包格式，且作业大小不能超过10M,网站支持学 生多次提交作业，每次提交均自动覆盖上一次提交，学生也可以下载最近一次提交的 作业，超过设定的截止时间后，学生将不能再通过网站提交作业。13、当教师或者助教发布一次作业时，会向每个学生发一封邮件提醒，邮箱地址为注册账号时的邮箱地址，同时

22、，网站提供优秀作业展示功能。14、网站可以查看学生自己的每项成绩以及最终成绩，但不能看到其他同学的成绩。15、学期结束后，学生可以对教师的教学方式，教学质量等进行反馈与评价，也可以对助教的助教方式与质量进行评价与反馈，也可以对本课程的教学方式与质量进行反馈与 评价。6.4 网站游客需求1、能看到老师提供的参考资料（含电子教材、历年试卷、补课资料,以及老师的教学交流 文章），但只能看到部分内容，比如PPT的前5页，且不能下载。2、如果老师提供的多媒体资料，能够在线观看部分内容，比如前5分钟，但不能下载。3、游客能看到历年学生对本课程，任课老师以及助教的评价与反馈。4、网站界面要求简洁大方，有网站

23、导航、相关链接（含学校选课系统、学院网页、需求相 关主题网站）。5、网站能提供一定资料共享功能（如论坛有上传下载附件功能、但对附件大小有限制，不 得大于2M）。6.5 系统功能需求本网站要求提供对外服务的能力，保证至少300名同学上课辅助服务的要求，包括数 据存储能力，网络服务吞吐能力，数据安全特性等。服务器建议选用Intel CPU，可以选择Windows或者Linux。开发平台可以选择IIS, NET或者apache，tomcat/jboss平台，请提供对外服务所要 求的相应的安全保障。第7章沟通管理计划7.1 开发者与客户沟通计划在此系统中，客户为老师，与客户的沟通计划为进行至少两次的谈

24、话，谈话的时间与 地点可以通过电子邮件或者电话短信来确定。其他沟通途径可以通过电子邮件与短信电话 来进行。7.2 开发者内部沟通计划开发者内部的沟通可以通过开会议、qq联系、微信联系、电话联系、短信联系、邮件 联系、网盘资源的共享来进行。其中会议包括现实面对面会议以及网上视频会议，语音会 议。第8章 风险管理计划8.1 风险评估8.1.1 需求获取方面的风险1、产品前景和项目范围没有达成明确的共识引发的风险2、需求开发所需的时间分配不合理引发的风险3、需求规格说明的不完整性和不正确性引发的风险4、创新产品的需求不完全引发的风险5、忽视非功能需求引发的风险6、客户对产品需求意见不一致引发的风险7

25、、未加说明的需求引发的风险8、对已有的产品作为需求基线来源引发的风险9、根据用户提议的解决方案引发的风险8.1.2 需求分析方面的风险1、设定需求优先级引发的风险2、技术上难以实现的特性引发的风险3、不熟悉的技术、方法、语言、工具或者硬件引发的风险8.1.3 编写需求规格说明方面的风险1、需求理解引发的风险2、尽管问题待确定但迫于时间压力而继续向前引发的风险3、具有二义性的术语引发的风险4、需求中包括设计引发的风险8.1.4 需求确认方面的风险1、未经确认的需求引发的风险2、审查熟练程度引发的风险8.1.5 需求管理方面的风险1、变更需求引发的风险2、34、需求变更过程引发的风险 为实现的需求

26、引发的风险 扩大目标范围引发的风险8.2 风险控制8.2.1 需求获取方面的控制1、在项目早期编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和 修改现有需求的指导2、合理安排需求开发所需的时间，需求开发活动的工作量应占项目总工作量的 10%-15%。3、强调市场调研、构建原型并成立客户小组，小组负责今早并经常获取对新产品前景的 反馈信息4、向客户询问以获得相应的质量特性需求，例如性能、易使用性、完整性和可靠性需求。 尽可能精确的在软件需求规格说明中，对这些非功能性需求及其验收标准编写文档。5、确定主要客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与，确保 由合适的人

27、对需求做出权威性的决策。6、尽量识别客户可能做出的任何假设。提出自由回答的问题来鼓励客户分享更多的想法 期望、主意、信息和关注点，而不是我们以其他方式所听到的。7、通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确定和相关 性。8、分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。8.2.2 需求分析方面的控制1、要确保每个功能需求、特性或用例都设定了优先级，并安排在一个特定的系统版本或 迭代中实现它们。2、评估每个需求的可行性，确定哪些需求的实现时间可能比预期长，尽早采取措施。3、为满足某些需求而采取新技术时，要考虑到学习曲线的问题，只有通过一定的学习时 间才能达到适

28、当的熟练程度。要尽早确认那些高风险的需求，并留出足够的时间用户 从错误中学习经验，实验以及制作原型。8.2.3 编写需求规格说明方面的控制1、对需求文档进行正式评审的团队应该包括开发人员、测试人员和客户，以减小需求的 不同理解造成的风险。2、应该记录下负责最终解释每个TBD的负责人的姓名和解决的截止日期。3、创建一个数据字典来定义一些术语的条目和结构，对软件需求说明的评审可以帮助参与者对关键术语和概念达成一致的理解。4、对需求的评审，可以确保强调的是需要解决的业务问题是什么，而不是规定如何解决。8.2.4 需求确认方面的控制1、在构造设计开始之前，确认需求的正确性和质量，应该为质量保证活动预留

29、出一定的 时间并提供资源，要确保客户参与需求审查活动。2、要对参与需求文档审查的所有团队成员进行培训，请组织内部有经验的审查人员或者 外界的咨询顾问来评述早先的审查。8.2.5 需求管理方面的控制1、应该推迟实现那些很可能还要发生变更的需求，待确定之后再实现，并在设计时要考 虑到应该使系统易于修改。2、需求变更过程要包括对提议的变更进行影响分析，组建变更控制委员会作出决策，使 用工具支持预定义的过程。3、需求跟踪矩阵有助于在设计、构造或者测试期间避免遗漏任何需求4、应该制定分阶段或者增量的交付产品的实现计划。在初始版本中先实现核心功能，在 以后的迭代中再逐步增加系统功能第9章 配置系统管理指南

30、9.1 配置标志软件项的标识基本按照软件配置标识命名规则进行。要通过标识能够确定软件项 之间的相互联系。9.2 版本管理1. 首先在服务器上建立一个目录，作为项目配置数据库。在此目录下按照每个项目组 建一个分目录，项目组代码及项目组名构成目录名，然后在此项目组目录下按照所属每个 项目建一个子目录，同一项目的开发文档存放在一个目录下，项目编号紧跟项目名就是目 录名。在一个项目分目录下可按非受控文档与受控文档建立一级次目录，然后在一级次目 录下按文档的不同类型建立二级次目录，使得所有开发文档能分门别类的组织存放，便于 查询。目录结构可见下图的示例。2. 项目子目录的受控文档一般只有项目经理和属于该

31、项目的开发人员和配置管理员能 够访问到。配置管理员负责分配访问权限，一般项目经理对该目录具有较大的权限读 取、添加和更改；一般开发人员只有读取的权限。3. 在项目开发的某一阶段结束时，通过了该阶段评审的这些开发文档交配置管理员保 存到项目数据库，做为正式版本的第一版1.0 版本。4. 在以后的开发中，如果软件需要修改，那修改后的软件可用多级编号来表示新版本 1.1、1.2 等加以区别标识。5. 在各个评审阶段产生的所有评审报告和修改报告都要进行编号保存，编号与相应文 档的编号要对应。9.3 变更控制9.3.1 微小改正时的变更控制1.在评审或测试后发现的问题由评审组组长或项目经理形成软件问题报

32、告单或源 代码修改记录单，并通知配置管理员。2. 由配置管理员将需要修改的软件的备份从项目配置数据库中检出，开发人员执行修 改。3. 修改完毕后进行修改测试，编程错误累计到了一定的量或者测试时间已满一个月（从 上一次入配置库后算起），凭源代码修改记录单及修改后的源代码，通知配置管理员， 配置管理员确定测试报告的完备性，并在核对软件修改内容和修改人员填写的软件修改 报告单或源代码修改记录单中的修改描述一致后，将文件登入项目配置数据库中， 生成新版本。4. 配置管理员修改软件配置状态表和软件变更记录表，以使其他相关开发人员 及时了解软件变化情况。9.3.2 较大变动时的变更控制1.开发人员或用户提

33、出影响较大的修改要求（这是指要增加或删除某些功能或者是发 现错误的阶段在造成错误的阶段的后面等）。2.配置管理员在收到这类修改要求时，必须组织有项目经理以及开发人员参加的修改 评审会，讨论修改的影响范围，修改的必要性、可行性以及修改方法、步骤和实施计划。3. 在修改方案通过并经项目经理审核后，要由产品开发部经理签字批准。涉及重大技 术方案的修改时，修改方案必须由总工程师或技术总监签字批准。以决断修改工作中各项 活动的先后顺序及各自的完成日期，以保证整个开发工作按原定计划日期完成。4. 配置管理员在接到修改批准由项目经理或产品开发部经理或总工程师或技术总 监签字同意的软件问题报告单后才可将需修改

34、的软件的备份从项目数据库中检出，开 发人员执行修改。5. 修改完毕后，交客户服务部进行测试和评审，测试和评审都通过后，交配置管理员 处理。6. 配置管理员检查测试报告和评审报告是否完备，核对软件修改报告单中的修改 描述和修改后的软件是否相符。核查结果符合要求，配置管理员将修改后的软件登入项目 数据库中，生成新版本。7. 配置管理员修改软件配置状态表和软件变更记录表，以使其他相关开发人员 及时了解软件变化情况对受影响的软件做出相应的修改。9.4 配置状态报告1.两份配置状态报告软件配置状态表和软件变更记录表分别以电子表格 的形式存放在项目分目录下，以便项目开发人员随时查询，了解软件的修改变化情况。2.软件配置状态表由配置管理员负责填写，主要反映项目中各软件项的配置情况。 开发人员通过查阅该表可及时全面的了解项目中软件项的配置使用情况。3. 软件变更记录表由配置管理员负责填写，主要记录软件开发过程中所有的修改 情况，该表以修改时间排序，以便开发人员及时了解软件项最新的变化。9.5 配置审核为保证各项产品在技术上和管理上的完整性，总经理室在软件开发过程中的详细设计 阶段和测试阶段完成时，对配置情况进行抽查。总经理室先提出要审核的内容和各项指标， 逐项审核完成后要作好记录，形成配置审核报告。