项目组软件开发行为规范仅供信息化部使用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、是否所有的接口都能描述了...
