软件开发规范.doc

项目组软件开发行为规范仅供信息化部使用1概述1.1编写目的为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以到达提高系统质量的目的。在本规范中，阐述了基本的开发模式，涉及需求验证、设计、编码规范、代码审查、单元测试、配置管理等，并明确开发过程中的方法、策略、工具以及环境规定，开发人员都必须遵守本软件开发规范。1.2读者对象本规范读者对象为软件开发项目管理者、项目经理、开发组2需求评审2.1过程规定按软件开发过程经验，问题暴露越早越好。因此，在实行设计和编码前，需对项目经理提供的需求说明文档进行充足的验证，在不明确的需求点上，需要和项目经理进一步核算，保证对每个需求点有清楚、一致的结识和理解。在需求验证的过程中，需按以下检查点进行逐项检查（涉及不限于）：所有定义、实现方法是否清楚地表达了用户的原始规定？是否清楚、明确地描述了所有的功能？是否没有不能理解或导致误解的描述？需求定义是否包含了有关功能、性能、限制、目的、质量等方面的所有需求？需求是否可以验证（即是否可以检查软件是否满足了需求）？是否有术语定义一览表？是否标记并定义了在将来也许会变化的需求？各个需求之间是否一致？是否有冲突和矛盾？是否认义了系统所有的输入、输出及其来源？重要为客户或者其他外部接口，是否明拟定义了输入参数和输出参数？是否说明了如何进行系统输入的合法性检查？功能性需求是否覆盖了所有非正常情况的解决？对异常数据产生的结果是否作了精确的描述？是否充足定义了关于人机界面的需求？在不同情况下，是否规定了系统的响应时间？界面需求是否使软硬件系统具有兼容性？是否有对相关日记做明确规定？以满足稽核相关的需要。针对开发过程中的需求变更，以上需求验证点同样合用，并同时评估需求变更给当前项目的设计和开发带来的风险，涉及架构、安全、进度等方面，以便项目经理进行计划调整和安排。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、模块遵循高内聚、低耦合的原则？9、是否每一部分的设计都可以追溯到需求说明书，接口规格说明书、或其他产品文档？10、对所继承下来的那些特别和不常用的特性对目前设计的影响是否进行了分析？11、需求规格评审中不完整的需求是否都已经解决?12、设计是否考虑了检错和恢复措施？（例如：输入检查，数据错误后如何恢复）13、是否考虑了异常情况？14、是否完全准确描述了所有的犯错情况？15、设计是否可以满足所有系统集成方面的规定？3.3工具及环境1.概要设计文档及其评审文档需check-in到svn中。2.概要设计过程中的问题跟踪需记录。4系统实现4.1过