5 软件文档评审
为什么要评审
提高项目的生产率,减少开发时间,加快开发进度。
改善软件质量,改进开发过程。
在评审过程中,使开发团队的其他成员更熟悉产品和开发过程。
通过评审,标志着软件开发的一个阶段的完成。
生产出更以维护的软件。
参与评审的角色
评审组长
评审的组织者,确保评审入口准则得到满足确保遵循评审的流程,指明评审的关注点,确保所有评审软院已经充分检视。确保评审的进度,确保发现、整理、修正问题。
宣读员
在评审会议上通过讲解来引导评审团队浏览工作产品
记录员
记录会议上的信息
作者
确保工作产品已经准备好,在评审会议上详解工作产品。在评审会议结束后修改所有已经确认的缺陷。
评审员
寻找被评审工作产品中的缺陷,填写评审表单并上交。参加评审会议,就评审出的缺陷提出建设性建议。
评审的内容
管理评审——组织的最高管理者就管理体系就现状、适宜性、充分性和有效性以及方针和目标的贯彻落实及实现情况进行正式的评价。
技术评审——发现软件在功能、逻辑、实现上的错误,验证软件符合他的需求规格。确认软件符合预先定义的开发规范和标准。保证软件在同一模式下进行开发。
过程评审——评估主要的质量保证流程;卡利率如何处理和解决评审过程中发现的不符合问题;总结和共享好的经验;支出需要进一步完善和改进的部分。
文档评审——对象有:需求文档评审、设计文档评审、测试文档评审。
需求文档评审
分层次评审
正式评审与非正式评审结合
分阶段评审
充分准备评审
精心挑选评审员
对评审员进行培训
充分利用需求评审检查单
做好评审后的跟踪工作
设计文档评审
- 概要设计说明书是否与软件需求说明书要求一致
- 概要设计说明书是否正确完整、一致。
- 系统的模块划分是否合理
- 接口定义是否明确
- 文档是否符合有关标准规定
测试文档评审
- 软件测试计划评审
- 软件测试说明评审
- 软件测试报告评审
- 软件测试记录评审
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Estom的博客!




