项目组软件开发行为规范仅供信息化部使用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.针对开发任务的分解,需要参照单人单任务在两天以内完成的标准。5.开发过程中,单元测试通过的代码需要及时check-in到svn。6.代码进入系统测试前需进行评审,可以是集中评审或者交叉评审的方式。评审内容包括基本编码规范、基本逻辑、日志规范、出错处理等。7.单元测试的覆盖率需在80%以上。具体的单元测试要点如下:对所测模块的数据进行测试。检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。设计测试用例查找由于不正确的计算(包括算法错、表达式符号表示不正确、运算精度不够等)、不正确的比较或不正常的控制流(包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等)而导致的错误。检查模块有没有对预见错误的条件设计比较完善的错误处理功能,保证其逻辑上的正确性。边界检查,注意设计数据、控制中刚好等于、大于或小于确定的比较值的用例。8.开发过程中,需进行持续化构建,保证check-in的代码质量。9.项目中引进的新技术需经过统一评审。5测试5.1过程要求在系统交付给测试组进行测试前,开发人员需在内部进行第一轮功能测试。测试过程中需保持测试代码的准确性和测试环境的独立性。具体测试内容包含但不限于以下几方面:1.功能测试。对照需求文档中的功能点,对系统的功能进行测试验证,确保系统完全满足需求文档中的要求。2.平台兼容性测试。在不同的浏览器、硬件配置环境下进行测试,主要浏览器包括Firefox,safari,IE,chrome。针对移动端,需涵盖三个主流操作系统,iOS,Android和WindowsMobile。硬件兼容性则包括不同的智能终端,PC,MAC,IPAD等其他机型的不同分辨率下的兼容性测试。3.不同网络环境下测试。针对移动端的应用,验证不同网络环境下,终端应用功能与性能方面是否正常(数据业务是否会中断,业务模块是否出现异常)。网络环境包含:4G信号,3G信号,2G强信号。6开发计划6.1过程要求软件开发是一项复杂、长期的系统工程,为保证开发能够顺利地进行实施,必须要制定科学、合理、切实可行的实施计划,制定严格的时间进度表,明确各个环节实施的时间,以指导和控制项目的全面实施。在系统实现过程中,需遵循以下规范:1.软件项目计划必须以产品/软件的需求规格为基础。当发生需求更改时,必须修订软件开发计划。2.对于软件项目计划中各项工作产品和工作任务,必须进行规模和工作量的软件估计,并在软件项目计划文档中记录估计的方法和估计数据3.对某项工作产品和任务的软件,同时采用两种或以上的方法进行估计,以避免一种方法的偏差4.尽量采用历史经验数据进行软件估计5.在“软件开发计划”中须包括项目管理活动的计划6.在“软件开发计划”包括人员的培训计划7.在“软件开发计划”中应考虑软件项目进行风险分析与评估,可能存在的风险领域含:需求的不明确和变更、外部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等,造成的计划变更。8.在开发活动中,必须按照项目跟踪与监控计划和体制,对照“软件开发计划”,跟踪项目开发的实际结果和性能。当实际结果和“软件项目计划”发生偏离时,必须进行分析,根据分析结果标明纠正措施。必要的情况下,要及时修订“软件项目计划”9.在软件项目跟踪监控活动中,必须定期进行总结和评审,撰写开发状态报告。根据项目的特点,报告的周期可以为周、双周、月。7数据安全7.1过程要求21世纪是一个信息爆炸的时代,数据是信息的主要载体,数据安全保证了信息的可用性。而数据备份作为保证数据安全的方法之一,则显得尤为重要。数据安全不仅在防范计算机病毒、系统漏洞中有体现,更多的还有代码安全,数据库防脱库及数据库备份安全。在系统实现过程中,需遵循以下规范:1.加强开发人员安全意识培训,近年来的一系列企业泄密事件的发生,根本原因还在于安全意识的严重缺失,加强安全意识的培训刻不容缓2.定时检测各应用服务的系统漏洞,软件漏洞3.需求代码加密机制,预防源码泄露带来的数据安全隐患4.建立数据备份机制,每天定时备份数据库数据,源码数据。5.当源码数据有异常时,应隔离相关异常源码,而不是立即删除。力图寻求异常缘由,修复潜在威胁。6.开发人员在编写代码或上传源码前应对源码有充分的测试,保证源码对数据影响的准确性。7.建立源码发布机制,确保源码安全