软件开发流程规范意见指导书

软件开发流程标准意见指导书V1.1编制人：XXXX名目\l“_TOC_250036“概述 3\l“_TOC_250035“目标 3\l“_TOC_250034“适用范围 3\l“_TOC_250033“术语 3\l“_TOC_250032“文档治理 3\l“_TOC_250031“可行性与打算争论阶段 3\l“_TOC_250030“需求分析阶段 3\l“_TOC_250029“设计阶段 4\l“_TOC_250028“实现阶段 4\l“_TOC_250027“测试阶段 5\l“_TOC_250026“运行与维护阶段 5\l“_TOC_250025“版本治理 5\l“_TOC_250024“版本库选择 5\l“_TOC_250023“版本库使用 5\l“_TOC_250022“先更，再提交 6\l“_TOC_250021“多提交 6\l“_TOC_250020“一次提交对应一个规律问题 6\l“_TOC_250019“不要提交编译不通过的代码 6\l“_TOC_250018“提交时必需书写明晰的标注 7\l“_TOC_250017“各提交类型使用相对应的前缀 7\l“_TOC_250016“不提交本地自动生成的文件 7\l“_TOC_250015“不提交自己不明白的代码 7\l“_TOC_250014“慎用锁定功能 7\l“_TOC_250013“使用TAG功能为release版本做标记 8\l“_TOC_250012“版本库备份 8\l“_TOC_250011“完全备份 8\l“_TOC_250010“增量备份 8\l“_TOC_250009“同步版本库 8\l“_TOC_250008“测试治理 9\l“_TOC_250007“治理工具 9测试原则 9\l“_TOC_250006“开发技术治理 9\l“_TOC_250005“开发工具治理 9\l“_TOC_250004“需求变更治理 9\l“_TOC_250003“需求变更分级 9需求变更预防 .\l“_TOC_250002“需求变更原则 .\l“_TOC_250001“工程干系人治理 2\l“_TOC_250000“工程上线流程治理 .概述目标命周期风险，依据《国家税务总局应用系统信息安全审核标准〔试行相关要求，结合江苏省国家税务局应用系统开发治理实际状况，制定本指南。适用范围测试验收阶段、部署上线阶段的安全工作要求及主要内容。发全过程的安全治理。术语文档治理13各阶段需要编写不同文件，各文件的主要内容要求见下：可行性与打算争论阶段争论报告》的编制。作出的安排记载下来，以便依据本打算开展和检查本工程的开发工作。需求分析阶段软件需求说明书的编制是为了使用户和软件开发者双方对对功能的规定对性能的规定等。于被处理数据的描述和数据采集要求的技术信息。〔或潜在用户能够了解该软件的用途，并且能够确定在什么状况下，如何使用它。设计阶段数据构造设计和出错处理设计等，为程序的具体设计供给根底。〔每个模块或子程序要设计说明书。全部标识、规律构造和物理构造作出具体的设计规定。的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。实现阶段模块开发卷宗〔开头编写：模块开发卷宗是在模块开发过程中逐步编写出信息。过程和有关学问，包括操作方法的细节。测试阶段测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、觉察及分析写成文件加以记载。阅历，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。运行与维护阶段开发进度月报的编制目的是准时向有关治理部门汇报工程开发的进展和情本指南认为在文件编制工作中允许确定的灵敏性，并不是13种文件每种都必需编写。版本治理版本库选择RCS、共同开发同一个工程，共用资源的目的。apache有利弊，用户可以自行选择。svn2FSFS(BDBFSFS版本库使用先更，再提交译并且自己测试之后，慎重地提交。SVN多提交UI面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能bug候，每修改掉一个bugbug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。一次提交对应一个规律问题个模块。保不会由于你的上传导致无法回退。不要提交编译不通过的代码在签出代码之后能够在统一的环境中进展编译。提交时必需书写明晰的标注工程组在使用SVN工程组其他成员在看到标注后不用具体看代码就能了解你所做的修改。各提交类型使用相对应的前缀删除某个文件 -:增加文件 +:修改文件 *:解决BUG,需要加上fixbug：BUGID不提交本地自动生成的文件Thumbs.db，工程编译生成的临时文件.obj,.class别人在更后就可能与本地的环境冲突从而影响大家的工作。不提交自己不明白的代码代码在提交入SVN慎用锁定功能才适当的承受锁定操作。TAGreleaseReleaseTag永久是相应公布分ReleaseTag“REL-”前缀加上版本号。版本库备份subversion份方式：完全备份，增量备份和同步版本库。完全备份将会造马备份的结果不够准确，失去备份的作用，为此xubversion供给了“svnadminhotcopy“的命令，可以防止此类问题。增量备份着每次subversion提交的变化，然后在需要恢复时能够回到最的可用状态。同步版本库〔但似乎只是单向的我们可以用来实现版本库的备份或镜像。选用何种备份策略可依据工程大小、简洁度及版本治理人员技术打算。测试治理治理工具JIRAAtlassian域。15011519,000测试流程开发技术治理开发工具治理需求变更治理变更。需求变更分级一级需求〔或变更〕是关键性的需求，这种需求假设不满足，意味着整个工程“Urgent”debug不加以满足，的工程内容无法提交或连续，所以是“Necessary”。一般模块关键性的根底组件，属于这个级别。三级需求是后续重要的需求，假设不被满足会令整体工程工作的价值下降，“Needed”。一般性的重大的有价值的全模块开发，属于这个级别。四级需求“Better”次。五级需求客户的的一种个人喜好而已，定级为“Maybe”。的描述一样，做与不做是“Maybe”。需求变更预防过程中。站在全局角度的需求变更治理，需要承受综合变更把握的方法。〔1〕 工程启动阶段的变更预防对于任何软件工程，需求变更都无可避开，也无从躲避，只能乐观应对。无谓的牺牲。并非要刻意赚取客户的钱财，而是不能让客户养成常常变更的习惯。〔2〕成功的软件工程和失败工程的区分就在于整个工程开发过程是否可控。风险和修改基准文件。把握需求渐变需要留意以下几点：确这一条：需求变，软件开发的投人也要变。够慎重地对待需求的变更。小的需求变更也要经过正规的需求治理流程，否则会积少成多。有任何效果。由于需求的变化是永恒的，并非需求写细了，它就不会变化了。〔3〕、工程收尾阶段的总结总结，以至于同样的问题反复消灭。结工作包括工程中事先识别的风险和没有预料到而发生的变