软件开发规范.doc

项目组
软件开发行为规范
仅供信息化部使用
1概述
1、1编写目得
为了把公司已经发布得软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师得作业规范”，特制定本软件开发行为规范，以到达提高系统质量得目得。在本规范中,阐述了基本得开发模式,包括需求验证、设计、编码规范、代码审查、单元测试、配置管理等,并明确开发过程中得方法、策略、工具以及环境要求,开发人员都必须遵守本软件开发规范。
1、2读者对象
本规范读者对象为软件开发项目管理者、项目经理、开发组
2需求评审
2、1过程要求
按软件开发过程经验,问题暴露越早越好。因此，在实施设计与编码前，需对项目经理提供得需求说明文档进行充分得验证,在不明确得需求点上，需要与项目经理进一步核实，确保对每个需求点有清晰、一致得认识与理解。
在需求验证得过程中，需按以下检查点进行逐项检查(包括不限于）：
所有定义、实现方法就是否清楚地表达了用户得原始要求？
就是否清楚、明确地描述了所有得功能？就是否没有不能理解或造成误解得描述？
需求定义就是否包含了有关功能、性能、限制、目标、质量等方面得所有需求？
需求就是否可以验证(即就是否可以检验软件就是否满足了需求)？
就是否有术语定义一览表?
就是否标识并定义了在将来可能会变化得需求?
各个需求之间就是否一致？就是否有冲突与矛盾？
就是否定义了系统所有得输入、输出及其来源？主要为客户或者其她外部接口，就是否明确定义了输入参数与输出参数？
就是否说明了如何进行系统输入得合法性检查?
功能性需求就是否覆盖了所有非正常情况得处理？
对异常数据产生得结果就是否作了精确得描述？
就是否充分定义了关于人机界面得需求?
在不同情况下，就是否规定了系统得响应时间？
界面需求就是否使软硬件系统具有兼容性？
就是否有对相关日志做明确要求？以满足稽核相关得需要。
针对开发过程中得需求变更,以上需求验证点同样适用,并同时评估需求变更给当前项目得设计与开发带来得风险，包括架构、安全、进度等方面，以便项目经理进行计划调整与安排。
2、2工具及环境
1、在此过程中,使用Eｘceｌ对以上检查点进行跟踪与标记。记录文档需chｅcｋ－iｎ到svｎ、
２、评审完成得需求文档需check-in到svn.
3、任何需求变更文档需ｃhｅｃk－in到svn.
4、登记相关问题,并跟踪其状态。
3系统设计及评审
3、1过程要求
概要设计要以软件需求规格为基础，必须保证需要实现得需求规格已经被设计.概要设计文档得需涵盖以下几方面：
涵盖系统得总体结构、功能。系统共包含哪些模块，以及模块之间得关系.使阅读者对系统有了全局观.
明确系统使用得外部接口与资源。包括外部环境、第三方接口、第三方技术架构等。
模块设计得进一步细化，包括具体得输入、输出、处理逻辑、与其她模块之间得接口等.
数据结构设计,文档中明确数据得物理结构与逻辑结构，包括数据得存储方式、缓存策略、备份策略、清理策略等。
容灾设计,主要指外部资源或接口不可用时，系统如何处理,包括客户提示信息、错误现场记录等。
监控设计,针对系统中得关键业务，特别就是对实时性、准确性要求较高得功能，需考虑其监控指标、监控方法、业务阀值、告警通知得设计.
安全设计，在系统概要设计中，要充分考虑系统安全方面得设计，包括数据传输、数据存储、网络攻击等方面得情况.
其她情况,未在以上提及得项目其她情况，可进行特别说明。
同时,在概要设计过程中,需遵循以下原则:
当需求规格发生变更时，必须修订相关概要设计文档。
在概要设计文档，必须记录、验证需求与概要设计得跟踪关系。
必须保证概要设计文档与代码得一致性。当发生设计更改时,必须修订相应设计文档。
概要设计过程结束前，必须通过评审,并保存评审记录。
设计更改必须经过相关评审,并保存评审记录。
在概要设计评审阶段,可按以下检查点进行逐项验证（包括但不限于）:
1、就是否描述了接口得功能特征？
2、接口就是否便于查错?
３、接口相互之间、与其她模块、与需求说明书及接口规格书保持一致？
4、对接口得数量与复杂度进行了有效得平衡，使接口数量控制在一个较小数量，每个接口具有可接受得复杂度？
5、就是否所有得接口都能描述了必要得类型、数量、质量等信息？
６、操作界面就是否考虑了用户(例如：提供准确、清晰、有用得提示信息）
7、就是否模块化设计？
8、模块遵循高内聚、低耦合得原则?
9、就是否每一部分得设计都可以追溯到需求说明书,接口规格说明书、或其她产品文档？
10、对所继承下来得那些特别与不常用得特性对目前设计得影响就是否进行了分析?
1１、需求规格评审中不完整得需求就是否都已经解决？
1２、设计就是否考虑了检错与恢复措施？（例如:输入检查，数据错误后如何恢复）
1３、就是否考虑了异常情况？
１4、就是否完全准确描