软件开发流程制度.docVIP

开发标准化制度 适用人群： 日期： 目录 1. 如何分析客户需求 3 1.1. 整体阅读 3 1.2. 分析需求可行性 3 1.3. 确定需求的优先级别 3 1.4. 绘制系统关联图 3 1.5. 充分挖掘潜在需求? 3 1.6. 列出需求功能列表 3 1.7. 编写计划?? 4 2. 系统架构说明 4 3. 开发规范 4 3.1. 编码规范 4 3.2. 界面设计规范 4 3.3. 限定条件规范 4 3.4. 文档命名规范 4 3.5. 数据库命名规范 5 4. 开发管理 5 4.1. 开发改动记录 5 4.2. Bug修改记录 5 4.3. 后期维护说明 6 如何分析客户需求 整体阅读 整体阅读，明确当前整体业务需求的目的 分析需求可行性 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。?? 确定需求的优先级别 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。?? 绘制系统关联图 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。? 充分挖掘潜在需求? 由于分析人员对软件技术非常熟悉，一些由于技术所带来的潜在需求对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么实质性的影响；实现这些需求，则会锦上添花。? 对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。? 这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。?? 列出需求功能列表 总结业务功能点。列出需求功能列表 编写计划?? 根据当前情况，编写需求分析计划，明确正式开始日期，中间阶段性日期（时间段可多个），结束时间，人员名单，分工情况。 系统架构说明 了解软件开发平台的架构层次 开发规范 编码规范 界面设计规范 名词，多个单词用下划线分隔，要求能说明显示内容的信息，为避免冲突，可加上?“_list”。 命名格式：名词_下划线_动词， 限定条件规范 命名规范 Package?的名字应该都是由一个小写单词组成 对于包名我们做如下约定：? 工具函数类包名前缀为.util? Servlet类包名前缀为.servlet? test?case类包名前缀为.test Class?的名字必须由大写字母开头而其他字母都小写的单词组成 变量的名字必须用一个小写字母开头。后面的单词用大写字母开头 源文件的头部需要一个history段，对于每次对源文件的重大改动，都需要在history段中注明。该段定义在package和import之间。 文档命名规范 文档务必保持段落格式整齐，文字字体，颜色，大小统一。? ? 如果需要摘引html页面中的内容，不能直接从html中粘贴过来（会在word文档中留下html格式），而必须先去除格式，例如：先粘贴到notepad中。? ? 务必注意中英文标点符号，文档正文一概使用中文标点符号。?? 如果需要在文档中插图，不要使用word自带的绘图工具。可以选择使用PowerPoint或visio。 使用PowerPoint，选择“插入”-“对象”-“Microsoft?PowerPoint?幻灯片”。使用visio，需要另外建立visio文档，绘制完以后粘贴到word中。?? 数据建模使用ERwin工具，文档中仅需要粘贴数据模型的逻辑视图（logical?view），另外还要附上表结构描述。?? 修改他人文档务必使用修订模式，以便保留备修改的内容。使用修订模式，选择“工具”- “修订”-“突出显示修订”，勾上“编辑时标记修订”。 数据库命名规范 数据库表命名均遵循以下规范：? 模块名_存储信息名词(多个单词用下划线分隔)，全部小写，例如：ebwebmail_message。?? 数据库字段命名遵循以下规范：? 存储信息名词(多个单词用下划线分隔)，全部小写，例如：message_id。 开发管理 开发改动记录 每次改动的记录都应该记录下来，保存成wpx的格式。 Bug修改记录 Bug的优先级，如果bug比较多，就看缺陷优先级，严重的就必须马上解决，不紧急的bug可以留在时间空闲的时候再修改 把要修复的bug列成一个清单 把修复好的bug也列成一个清单记录下来 后期维护说明 用户通过使用感觉需要对部分地方改动维护结束后，整理完善整个维护过程中相应