管理制度-某IT公司产品部工作质量规范 精品.doc

《管理制度-某IT公司产品部工作质量规范 精品.doc》由会员分享，可在线阅读，更多相关《管理制度-某IT公司产品部工作质量规范 精品.doc（5页珍藏版）》请在第一文库网上搜索。

1、产品部工作质量规范（草稿）版本号： 撰写人： 撰写日期 审核人：_ 审核日期 1 产品部工作定义产品部日常工作包括：q 产品设计工作相关输出：需求规格说明书、UI图形原文件q HTML代码输出相关输出：UI的HTML代码q 产品测试工作相关输出：测试计划（含测试用例）、测试报告（含BUGLIST）q 产品开发阶段的沟通工作相关输出：工作日报q 产品设计相关的用户调查工作相关输出：调查计划、调查报告q 相关评审工作相关输出：评审记录q 其他相关日常工作计划、会议纪要、工作报告等2 产品设计工作工作目标：根据公司产品战略阶段规划和可行性研究，明确该阶段“产品必须做什么”，对目标系统提出完整、准确、

2、清晰、具体的功能要求。工作内容包括需求规格说明书文档设计、UI设计。主要输出：需求规格说明书、UI图形原文件2.1 需求规格说明书：q 定义：1、 需求规格说明书必须清楚的描述软件的每一个基本需求（功能、设计约束和属性）和外部界面。2、 必须把每一个需求规定成能够通过预先定义的方法（例如检查、分析、演示或测试等）被客观地验证与确认形式。q 需求规格说明书标准在软件需求分析阶段结束后必须由产品委员会进行软件需求评审，以确保在软件需求规格说明书中规定的各项需求的合适性。评审过程一般包括以下四个方面的验证：1 完整性需求必须是完整的，需求规格书应该包括产品规划书所定义的产品战略阶段需要的每一个功能需

3、求及性能性能约定。2 一致性所有需求是一致的，任何一条需求都不能与其他需求相互矛盾。3现实性保证需求设计是用现有的硬件技术和软件技术基本上可以实现的，基本适应公司的开发技术资源水平的。4有效性需求正确有效，确实吻合产品战略方向、市场方向所需，避免做超出市场需求规划范围的无用设计。5 可用性需求说明书必须使用清晰易懂的描述语言，逻辑清晰，准确描述每一个需求的细节。以保障在无人职守的情况下能被阅读对象正确理解。2.2 UI设计q 输出UI设计输出为符合下述评审要求PNG或PSD图形文件，并合理组织输出相关“层”、“帧”、“按钮”等界面元素。q UI设计评审标准：1、 主题定位：主题表现鲜明，展现产

4、品阶段性定位特点，具有适当个性的设计风格，表现手法新颖；2、 功能容纳：所容纳功能符合产品需求设计；3、 布局要求：符合用户体验规则，方便浏览和操作；整体布局均衡合理，轻重层次合理，符合产品定位要求；风格一致；4、 色彩要求：整体色彩要符合产品定位，协调和谐，符合美感；5、 可修改性：方便进行更新，修改；6、 技术含量：整体的技术难度和技术的恰当使用；3 HTML代码输出工作工作目标：根据评审通过的需求设计，将已确定的UI图形生产为可供开发部门应用的HTML代码。主要输出：HTML代码（含图形切片、HTML文件、CSS文件、XML模板文件等）。q HTML代码评审标准：1、 HTML代码与需求

5、规格设计的UI界面一致。2、 HTML代码符合W3C规范。3、 相关代码具有可扩展性、可修改性，即可方便地进行更新和修改4、 相关CSS样式等代码规划合理，全套HTML间无代码冲突造成的错误。4 产品测试工作工作目标：测试工作的定义是：为了发现程序中的错误而执行程序的过程。测试工作包含从开发开始的模块测试到验收测试（Release测试）的整个过程的测试规划、测试设计、测试实施、测试报告等内容。产品测试工作用来验证软件需求规格说明书中的需求是否已经正确开发实现。已经实现的产品是否满足潜在的或预先定义的质量要求。工作范围：产品部门目前负责的测试包括：模块黑盒测试、系统联调黑盒测试、Release黑

6、盒测试；可参与的测试包括：系统压力测试、安全性测试。输出：测试计划（含测试用例）、测试报告（含BUGLIST）4.1 测试用例q 测试用例内容撰写标准：1所有测试用例都应该能够追溯到需求设计2覆盖需求中所提及的测试要求；3. 覆盖需求中的所有可测试功能和性能；4. 覆盖需求中所提及的所有算法、条件约定等；5. 测试用例中数值设计的合理性；6. 测试用例测试重点把握准确；q 测试用例评审标准：1完整性：完整性是指有明确的目的、输入、输出，提供必要的备注信息；2. 可执行性：可执行性指测试人员根据测试用例能够独立执行测试；3. 代表性：指能用最简单的数据，最简捷的路径达到测试的目的；4. 唯一性：

7、指在各个测试用例没有重复交叉的现象；5. 可读性：指测试用例描述清晰，逻辑正确，拆分合理；6. 涉及到数值计算，必须精确到具体数值的输入及输出；7. 涉及到业务流程，必须体现流程的每个节点及输出。4.2 测试报告q 测试报告（含BUGLIST）标准：1测试报告必须与测试计划相吻合，完整描述软件测试计划（用例）执行的结果。2. BUGLIST必须符合规定格式，对BUG的表现情况描述清晰准确，可读性好，保障开发人员能正确理解。注：相关格式见BUGLIST编写指南3测试报告必须对BUG等级进行准确的结论描述。注：BUG划分五个等级，见BUG等级分类标准4测试报告必须对软件产品是否合格进行标识。注：包

8、括验收合格、让步接收、不合格三个标准，见产品Release验收标准5 开发过程的沟通工作工作目标：将评审通过的需求设计准确传达给开发人员，了解并及时反馈开发部门工作情况，以保障产品开发编码符合产品设计规格。输出：产品开发情况日报表。工作标准：保障产品编码实现过程中不偏离需求设计，即在产品Release测试时发现的与功能设计不符的功能性BUG低于5。精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精

9、品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐精品推荐