软件开发规范

项目组

软件开发行为规范

仅供信息化部使用

1 概述

1.1 编写目的

为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以到达提高系统质量的目的。在本规范中，阐述了基本的开发模式，包括需求验证、设计、编码规范、代码审查、单元测试、配置管理等，并明确开发过程中的方法、策略、工具以及环境要求，开发人员都必须遵守本软件开发规范。

1.2 读者对象

本规范读者对象为软件开发项目管理者、项目经理、开发组

2需求评审

2.1过程要求

按软件开发过程经验，问题暴露越早越好。因此，在实施设计和编码前，需对项目经理提供的需求说明文档进行充分的验证，在不明确的需求点上，需要和项目经理进一步核实，确保对每个需求点有清晰、一致的认识和理解。

在需求验证的过程中，需按以下检查点进行逐项检查（包括不限于）：

1.所有定义、实现方法是否清楚地表达了用户的原始要求？

2.是否清楚、明确地描述了所有的功能？是否没有不能理解或造成误解的

描述？

3.需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有

需求？

4.需求是否可以验证（即是否可以检验软件是否满足了需求）？

5.是否有术语定义一览表？

6.是否标识并定义了在将来可能会变化的需求？

7.各个需求之间是否一致？是否有冲突和矛盾？

8.是否定义了系统所有的输入、输出及其来源？主要为客户或者其他外部

接口，是否明确定义了输入参数和输出参数？

9.是否说明了如何进行系统输入的合法性检查？

10.功能性需求是否覆盖了所有非正常情况的处理？

11.对异常数据产生的结果是否作了精确的描述？

12.是否充分定义了关于人机界面的需求？

13.在不同情况下，是否规定了系统的响应时间？

14.界面需求是否使软硬件系统具有兼容性？

15.是否有对相关日志做明确要求？以满足稽核相关的需要。

针对开发过程中的需求变更，以上需求验证点同样适用，并同时评估需求变更给当前项目的设计和开发带来的风险，包括架构、安全、进度等方面，以便项目经理进行计划调整和安排。

2.2工具及环境

1.在此过程中，使用Excel对以上检查点进行跟踪和标记。记录文档需check-in 到svn.

2. 评审完成的需求文档需check-in到svn。

3.任何需求变更文档需check-in到svn。

4.登记相关问题，并跟踪其状态。

3 系统设计及评审

3.1 过程要求

概要设计要以软件需求规格为基础，必须保证需要实现的需求规格已经被设计。概要设计文档的需涵盖以下几方面：

1.涵盖系统的总体结构、功能。系统共包含哪些模块，以及模块之间的关

系。使阅读者对系统有了全局观。

2.明确系统使用的外部接口和资源。包括外部环境、第三方接口、第三方

技术架构等。

3.模块设计的进一步细化，包括具体的输入、输出、处理逻辑、与其他模

块之间的接口等。

4.数据结构设计，文档中明确数据的物理结构和逻辑结构，包括数据的存

储方式、缓存策略、备份策略、清理策略等。

5.容灾设计，主要指外部资源或接口不可用时，系统如何处理，包括客户

提示信息、错误现场记录等。

6.监控设计，针对系统中的关键业务，特别是对实时性、准确性要求较高

的功能，需考虑其监控指标、监控方法、业务阀值、告警通知的设计。

7.安全设计，在系统概要设计中，要充分考虑系统安全方面的设计，包括

数据传输、数据存储、网络攻击等方面的情况。

8.其他情况，未在以上提及的项目其他情况，可进行特别说明。

同时，在概要设计过程中，需遵循以下原则：

1、当需求规格发生变更时，必须修订相关概要设计文档。

2、在概要设计文档，必须记录、验证需求和概要设计的跟踪关系。

3、必须保证概要设计文档和代码的一致性。当发生设计更改时，必须

修订相应设计文档。

4、概要设计过程结束前，必须通过评审，并保存评审记录。

5、设计更改必须经过相关评审，并保存评审记录。

在概要设计评审阶段，可按以下检查点进行逐项验证（包括但不限于）：

1、是否描述了接口的功能特征?

2、接口是否便于查错?

3、接口相互之间、和其他模块、和需求说明书及接口规格书保持一致？

4、对接口的数量和复杂度进行了有效的平衡，使接口数量控制在一个较小数量，每个接口具有可接受的复杂度？

5、是否所有的接口都能描述了必要的类型、数量、质量等信息？

6、操作界面是否考虑了用户（例如：提供准确、清晰、有用的提示信息）

7、是否模块化设计？

8、模块遵循高内聚、低耦合的原则？

9、是否每一部分的设计都可以追溯到需求说明书，接口规格说明书、或其他产品文档？

10、对所继承下来的那些特别和不常用的特性对目前设计的影响是否进行了分析？

11、需求规格评审中不完整的需求是否都已经解决?

12、设计是否考虑了检错和恢复措施？（例如：输入检查，数据错误后如何恢复）

13、是否考虑了异常情况？

14、是否完全准确描述了所有的出错情况？

15、设计是否能够满足所有系统集成方面的要求？

3.3 工具及环境

1. 概要设计文档及其评审文档需check-in 到svn中。

2. 概要设计过程中的问题跟踪需记录。

4 系统实现

4.1 过程要求

编码必须以设计文档为基础，必须保证所有的设计都被编码实现。当设计发生变更时，必须修改相关代码。同时必须保证设计文档和代码的一致性。当代码的修改已经造成设计更改时，必须修订相应设计文档。

在系统实现过程中，需遵循以下规范：

1.遵照各项编码规范。

2.所有代码使用svn进行统一管理，并至少提供开发、测试、生产三种构

建脚本。

3.在系统开始之前，需在svn上创建对应的分支，开发工作统一在分支上

进行。

4.针对开发任务的分解，需要参照单人单任务在两天以内完成的标准。