易游

2 正在处理的故障 [错误名 2] [日期 1] 状态： [状态 ] 〖状态的解释〗 { 状态有下面几种：  知道情况  查明原因  正在修改  测试通过  修改完毕 } 估计几天可以完成： [天数 ] 目前是第几天： [天数 ] 情况： 〖解释〗 { 在这一天中为错误

后需要对《详细设计说明书》进行评审。 评审会应包括：项目经理、项目组的技术骨干，如果项目为重大项目，还应包括技术总监和有关专家。 编码阶段：在编码阶段结束时，需要对程序代码进行评审。 评审会应包括：项目经理、项目组的技术骨干。 测试阶段：在系统测试阶段开始之前，系统测试部应完成对《测试计划》的评审。 评审会应包括：测试部与本项目有关人员、项目经理、项目组的技术骨干，如果项目为重大项目，还

5 详 细设计控制程序 设计部 袁仁顺 10 CSI/QP 0706 编码控制程序 开发部 扬小江 11 CSI/QP 0707 设计评审控制程序 项目管理办公室 邓戈 12 CSI/QP 0708 采购控制程序 管理办公室 章玮 13 CSI/QP 0709 配置管理控制程序 项目管理办公室 邓戈 14 CSI/QP 0710 生产制作控制程序 开发部 扬小江 程序文件 文件编号 CSI/QP

E. 数据库 E1. informix F. 杀毒软件 G. 测试工具 G1. Purify H. Corba I. 开发工具 I1. Tcl Pro J. 公司软件产品 . D 7 D8 D9表示每年每类软件的流水编号 按软件购买时间顺序编号，范围为 001~999。 注： 1. 为了解决以前软件不知购买年限问题，设定未知购买年限均为 1997 年。 2. 若软件出现新的分类

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2. 任务概述 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。 解释被开发软件与其他有关软件之间的关系。 如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。 如果所定义的产品是一个 更大的系统的一个组成部分

件开发方法和使用的软件辅助开发工具； c. 制定需求分析阶段，设计阶段，编程阶段中文档编写规则，模型表示规则，命名约定 等在开发过程中需协调一致的规则。 5． 2． 3 《 XXX系统开发规范 》 中的一些详细规则可在开发过程中不断完善。 5． 3 需求分析 5． 3． 1需求分析员应通过各种方式收集和获得所开发项目的业务需求，并对获取的需求 和系统应具有的隐含需求进行分析，以建立系统的软件需求

0402 版 号 A/0 标题 : 质量控制程序 页 码 共 2 页 第 1 页 5． 5 质量记录的标识，收集，编目，归档 5． 5． 1 各部门设专人负责对质量记录进行收集、整理、标识、编目，放于指定目录下。 质管部每月对全公司质量记录进行审查入库，统一归档存储质量记录。 5． 6 质量记录的查阅和维护 质量记录的维护由质管部统一管理，包括定期备份、设置使用权限。 各相关部门按《文件

软件产品交付给拥护的验收规程 软件库的操作，包括准备、存储和更新模块的方法； 软件配置管理活动的检查； 问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响； 软件进入配置管理之前的测试级别； 质量保证级别，例如：在进入配 置管理之前，验证软件满足有关基线的程度。 3 软件配置管理活动 描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等 4 方面的软件配置管理活动的需求。

的具体程序参见《设计评审控制程序》。 软件配置标识 确定软件配置项：在软件开发过程中产生的大量文档中，做出选择，确定哪些内容需要受控。 用“版本”来定义配置项的演化阶段。 制定命名规则。 本公司的配置项的命名规则的实现方法详见《文件和资料编号规则》。 配置项应该反映基线的建立。 配置项标识内容：  名字：一个字符串，明确地标识配置项；  描述：描述配置项类型（如文档、程序、数据、环境配置等）

《需求分析实例》组织评审。 《需求规格说明书》的编制 当需求分析过程结束后，需求阶段负责人依据《需求规格说明书编写指南》编写《需求规格说明书》。 编制《需求规格说明书》的依据可以是合同文本、用户提供的功能要求、《需求分析实例》、《业条需求说明书》等。 《需求规格说明书》的编制工作可以由项目经理或其指定的需求人员负责，必要时，编制成员可以包括相关销售人员和用户代表。