全国咨询热线：136-9172-9932
实际中项目立项相关事宜
介绍项目情况,目前立项阶段情况,项目市场预估,项目时间讨论
资源情况:需要人力,物力,技术,工具,一般使用的开发语言,工具,测试工具,在系统运行中需要的工具
部门情况:参与的部门,主要负责人,部门只要职责,后期主要工作内容
与项目相关的文件:指示文件,技术文件,项目介绍文件等
项目里程碑:开发开始结束时间,测试开始结束时间,发布时间,详细可能会有分期时间等
二.小程序项目立项会议
项目介绍:项目简介文档
测试团队人员介绍:开发人力,多少,测试人力多少
测试团队模块分配:模块指派到人
测试团队测试相关事宜的准备工作:工具准备,设备准备,招聘人员等
三.项目规则
根据不同的项目制定不同的规则如:
1.邮箱配置:便于工作中与不同的部门,同事进行沟通并记录
2.在项目中遇到问如何处理,如找什么部门,负责人介绍,开发相关人员的联系方式
3.项目中的时间安排
4.邮箱使用规则:如发邮件的注意事项,标题,请假,附件命令等规则
四.此时项目测试团队的任务
准备测试相关设备,工具,人力安排;
在产品出来的情况下进行熟悉系统,如画功能模块图.没有出来的情况下,研读项目相关说明文档,如项目简介;
完成立项中的相关任务,如完成邮箱配置,确认邮箱可以正常使用.包括显示名称,发件人姓名设置。
1.评审概念
需求评审，是对产品需求文档的评审。需求文档是根据用户的需求，抽象、细化成产品需求，对我们技术人员来说也是比较直观的需求文档，通过这份文档技术人员可以了解到用户想要得到的是一个什么样的产品，它是用户和技术人员沟通的桥梁，所以它的评审至关重要。
从规范的流程来说,项目中任何提交的文档都要经过评审,但是在实际工作中,有些文档会不经过评审而直接使用,在使用进行修改,更新,维护.
评审中使用的方法一般是同行评审
2.评审目标:
第一：产品需求文档可以全面、清晰的描述产品的功能和性能;
第二：项目组成员对用户需求的理解达到一致;
第三：形成一份最终的，对研发具有指导作用的文档，后续的工作都要以这份文档为基础而开展。
3.评审流程
准备>>审批>>预审>>审查会议>>修改>>验证>>总结
4.评审的对象包括:
概念阶段：产品需求说明书
计划阶段：系统方案、项目计划
开发阶段：详细设计、单元测试用例(方案)、集成测试用例(方案)、代码、数据库脚本等。一般而言，在开始编码之前，先要进行详细设计评审，以确保程序的正确性，减少后续修改带来的不良影响
验证阶段：系统测试计划、系统测试方案、系统测试用例
发布阶段：安装文档、使用文档
5.评审中的原则:
在预审期间要使用检查单，以避免发现缺陷不知道记录在哪里的情况发生。
避免过度依赖检查单。
审查会议要限制在2小时之内，以避免长时间讨论而偏离了审查会议的主题。
审查的对象是产品而非生产者(作者)，因此要避免对作者本人进行人身攻击。
“磨刀不误砍柴工”，要给评审员提供足够的预审时间，一般以提前两天为佳。
