软件开发统一标准化工作作业流程.docx
《软件开发统一标准化工作作业流程.docx》由会员分享，可在线阅读，更多相关《软件开发统一标准化工作作业流程.docx（21页珍藏版）》请在冰点文库上搜索。
软件开发统一标准化工作作业流程
软件开发原则化工作流程
1引言
1.1编写目
阐明编写这份软件开发原则化工作流程目，指出预期读者。
1.2合用范畴
互联网开发中心所有项目。
1.3定义
列出本文献中用到专门术语定义、外文首字母组词原词组。
1.4流程图
需求调研
系统设计
软件开发
软件测试
内部验收
客户验收
系统维护
需求分析阶段
概要设计阶段
详细设计阶段
系统编码阶段
系统测试阶段
集成测试阶段
系统测试阶段
项目管理过程
评审过程
软件监督与审核过程
软件配备管理过程
软件需求管理过程
变更控制过规程
文档控制规程
文档开发与管理规范
项目流程
项目开发各阶段
过程管理思想
需求分析
2需求调研
2.1概述
需求调研对于一种应用软件开发来说，是一种系统开发开始阶段，需求调研质量对于一种应用软件来说，是一种极其重要阶段，它质量在一定限度上来说决定了一种软件交付成果。
如何从客户中听取顾客需求、分析顾客需求就成为调研人员最重要任务。
2.2需求调研
总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统关系四个方向来进行调研。
●业务规则
各个流程、功能点等事项办理，都会有有关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。
调研对象普通为操作员。
●表单数据
对各个功能点业务数据、数据项、表单格式、查询条件以及其他有关数据进行明确分析调研。
调研对象普通为操作员。
●贯穿系统关系
各个模块或科室之间数据互换、传递以及数据共享等，需要咱们调研人员与各个模块或科室有关负责人进行多方沟通，拟定一种多方满意需求调研成果。
2.3注意事项
●调研过程中，顾客说不久，不也许等咱们所有记录之后，再讲下一种问题。
因而，只能在笔记本上速记，有时只能记录1、2个核心字。
因而，每天调研结束之后，当天晚上必要整顿当天调研状况，写成一份调研日记。
整顿当天调研记录时，还要整顿出待明确问题，下一次再找机会与顾客再沟通、确认。
●调研各个阶段，必要出具有关文档或文献，例如调研筹划、流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。
●所有疑问必要等到明确答复，不能浮现互相矛盾、似是而非需求。
需精确理解客户解说，如果有问题先做记录，之后将整顿问题向客户询问，得到明确成果。
需求必要是客户接受和确认，不能有臆测需求。
●要合理安排好时间和进度。
有时候客户尚有自己要做事情，不一定能及时相应。
因此必要提前预约好时间，保证整个需求调研进度。
●能积极引导客户。
当客户浮现疑虑，而调研人员能明白且能做好客户想要东西时候，调研人员能及时积极引导客户，详细解说咱们所懂得东西，并能让客户接受与确认。
●如遇公司有有关原型或产品，调研人员需先详细理解公司有关原型和产品，依照成品，找出本地化差别化需求。
3可行性分析
这个阶段要回答核心问题：
“对于上一种阶段所拟定问题有行得通解决办法吗？
”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了系统分析和设计过程，也就是在较抽象高层次上进行分析和设计过程。
可行性研究应当比较简短，这个阶段任务不是详细解决问题，而是研究问题范畴，摸索这个问题与否值得去解，与否有可行解决办法。
在问题定义阶段提出对工程目的和规模报告普通比较含糊。
可行性研究阶段应当导出系统高层逻辑模型（通惯用数据流图表达），并且在此基本上更精确、更详细地拟定工程规模和目的。
然后分析员更精确地预计系统成本和效益，对建议系统进行仔细成本／效益分析是这个阶段重要任务之一。
可行性研究成果是使用部门负责人做出与否继续进行这项工程决定重要根据，普通说来，只有投资也许获得较大效益那些工程项目才值得继续进行下去。
可行性研究后来那些阶段将需要投入更多人力物力。
及时中断不值得投资工程项目，可以避免更大挥霍。
4需求分析
4.1概述
这个阶段任务依然不是详细地解决问题，而是精确地拟定“为理解决这个问题，目的系统必要做什么”，重要是拟定目的系统必要具备哪些功能。
顾客理解她们所面对问题，懂得必要做什么，但是普通不能完整精确地表达出她们规定，更不懂得如何运用计算机解决她们问题；软件开发人员懂得如何使用软件实现人们规定，但是对特定顾客详细规定并不完全清晰。
因而系统分析员在需求分析阶段必要和顾客密切配合，充分交流信息，以得出通过顾客确认系统逻辑模型。
通惯用数据流图、数据字典和简要算法描述表达系统逻辑模型。
在需求分析阶段拟定系统逻辑模型是后来设计和实现目的系统基本，因而必要精确完整地体现顾客规定。
系统分析员普通都是计算机软件专家，技术专家普通都喜欢不久着手进行详细设计，然而，一旦分析员开始谈论程序设计细节，就会脱离顾客，使她们不能继续提出她们规定和建议。
较件工程使用构造分析设计办法为每个阶段都规定了特定结束原则，需求分析阶段必要提供完整精确系统逻辑模型，通过顾客确认之后才干进入下一种阶段，这就可以有效地防止和克服急于着手进行详细设计倾向。
需求分析是软件工程中一种重要环节。
是关乎软件开发成败重要因素。
当前软件项目中返工开销几乎占了总开发一半，而导致返工重要因素是需求分析不明确。
从而引起软件开发中某些列更改。
这些更改也许导致挥霍大量资源、软件项目无法准时完毕等严重问题，因此需求分析是软件设计和实现基本，是软件项目迈向成功重中之重。
4.2产物/成果
项目阶段/角色
项目经理
产品团队
（BA/BAS/ProductM）
开发团队
TTL/Developer）
测试团队
（TestLead/Tester）
需求阶段
活动：
1、建立CQ/QC中项目目录；
2、在SVN中建立项目目录；
1、分析项目所需资源，风险等
2、预估项目周期
产出：
1、项目筹划（大体时间规划）
活动：
1、收集整顿需求
产出：
1、需求阐明书
参加：
1、需求分析
2、环境分析
参加：
1、需求分析
2、环境分析
4.3需求分析任务
简言之，需求分析任务就是解决“做什么”问题，就是依照需求调研，全面理解顾客各项规定并精确表达所接受顾客需求。
4.4需求分析办法
4.4.1原型化
原型就是软件一种初期可运营版本，它实现了目的系统某些或所有功能。
原型化办法就是尽量快地建造一种粗糙系统，这系统实现了目的系统某些或者所有功能，但是这个系统也许在可靠性，界面和谐性或其她方面上存在缺陷。
建造这样一种系统目是为了考察某一方面可行性，如算法可行性，技术可行性，或考察与否满足顾客需求等。
如，为了考察与否满足顾客需求，可以用某些软件工具迅速建造一种原型系统，这个系统只是一种界面，然后听取顾客意见改进这个原型。
后来目的系统就在原型系统基本上开发。
原型重要有三种类型：
●摸索型
目是要弄清晰对目的系统规定，拟定所但愿特性，并探讨各种方案可行性。
●实验型
用于大规模开发和实现前，考核方案与否适当，规格阐明与否可靠。
●进化型
目不在于改进规格阐明，而是将系统建造得易于变化，在改进原型过程中，逐渐将原型进化成最后系统。
在使用原型办法是有两种不同方略。
●废弃方略
先建造一种功能简朴并且质量规定不高模型系统，针对这个系统重复进行修改，形成比较好思想，据此设计出比较完整，精确，一致，可靠最后系统。
系统构建完毕后，本来模型系统被废弃不用。
摸索型和实验型属于这种方略。
●追加方略
先构造一种功能简朴并且质量规定不高模型系统，最为最后系统核心，然后通过不断地扩充修改，逐渐追加新规定，发展成为最后系统。
进化型属于这种方略。
4.5需求报告
需求报告及软件需求阐明书，作用在于便于顾客、开发人员进行理解和交流，反映出顾客问题构造，可以作为软件开发工作基本和根据，并作为确认测试和验收根据。
通过从客户那里获得所有信息进行整顿，以区别业务需求及规范、功能需求、质量目的、解决办法和其她信息。
通过这些分析，形成一份《软件需求阐明书》，此份阐明书使开发人员和客户之间针对要开发产品内容达到合同。
客户需要评审此文档，以保证内容精确完整表达其需求。
一份高质量“需求阐明书”有助于开发人员开发出真正需要产品。
输出：
《软件需求阐明书》，格式参照附录1《软件需求阐明书》
4.6划分需求优先级
绝大多数项目没有足够时间或者资源实现功能性每个细节。
决定哪些特性是必要，哪些是重要，是需求开发重要某些，这只能由客户负责设定需求优先级，由于开发者不也许按照客户观点决定需求优先级。
开发人员将为拟定优先级提供关于每个需求耗费和风险信息。
在时间和资源限制下，关于所需特性能否完毕或者完毕多少，开发人员必要给出意见。
4.7评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息一种机会。
如果客户人为编写“需求分析报告”不够准去，就有必要尽早告知分析人员并为改进提供建议。
更好办法是先为产品开发一种原型。
这样客户就能提供更有价值反馈信息给开发人员，是她们更好理解需求。
原型并非是一种实际应用产品，但开发人员能将其转化、扩充成功能齐全系统。
5系统设计
制定项目筹划
软件项目筹划是一种用来协调所有其她筹划，以指引项目执行和控制可操作文献。
它体现了对客户需求理解，是开展项目活动基本，也是软件项目跟踪与监控根据。
拟定开发过程
依照软件项目和项目组实际状况，建立起一种稳定、可控软件开发过程模型，并按照该过程来进行软件开发。
加强过程控制
过程控制重要涉及过程管理、变更控制和配备管理。
5.1概述
此阶段重要是依照需求分析成果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
5.2产物/成果
项目阶段/角色
项目经理
产品团队
（BA/BAS/ProductM）
开发团队
TTL/Developer）
测试团队
（TestLead/Tester）
设计阶段
活动：
1、监控项目进度，
2、组织安排本阶段评审
1、任务分解，责任到人
2、细化项目筹划
产出：
1、项目筹划（详细到各功能）
参加：
1、系统功能设计
产出：
1、界面原型
活动：
1、系统功能技术设计
2、数据库设计
产出：
1、系统功能技术设计
2、数据库设计阐明书
活动：
1、组织测试筹划评审
产出：
1、项目测试预计测试筹划书
5.3产品设计
5.3.1概述
产品设计是专业技术人员依照软件项目需求分析成果来对整个软件系统进行定制、开发、设计一种过程。
5.3.2流程图
5.4软件设计
5.4.1概述
软件设计阶段重要工作可分为软件概要设计、详细设计两个分阶段。
对于复杂限度不高、规模较小或核心性级别较低软件，可将概要设计和详细设计合并为一种阶段执行。
5.4.2流程图
5.4.3概要设计
在概要设计阶段，项目组应依照软件总体框架、软件模型和软件工程实现规定，提出软件设计办法，建立软件总体构造，划分功能模块（软件部件），拟定总体构造和部件间关系，定义各个软件功能模块功能、数据接口和控制接口，设计全局数据库/数据构造，规定设计限制，编写《概要设计阐明》，由研究室或项目组负责人审批。
对于复杂软件，研究室或项目组应组织对软件概要设计进行评审，以保证软件构造、全局数据构造、重要算法、模块划分、接口关系和软件模型合理性、对的性、完整性，与软件需求一致性。
项目组应保持评审成果及任何必要办法记录。
输出：
《软件概要设计阐明书》（概要设计某些）,格式参照附录2《软件概要设计阐明书》
5.4.3.1数据库系统设计
此数据库设计可单独成册，特别对大型数据库应用系统，即有一种单独《数据库设计阐明书》。
输出：
《数据库设计阐明书》,格式参照附录3《数据库设计阐明书》
5.4.3.1.1信息模型设计
拟定系统信息类型（实体或视图），拟定系统信息实体属性、核心字及实体之间联系，详细描述数据库和构造设计，数据元素及属性定义，数据关系模式，数据约束和限制。
5.4.3.1.2数据库设计
5.4.3.1.2.1设计根据
阐明数据被访问频度和流量，最大数据存储量，数据增长量，存储时间等数据库设计根据。
5.4.3.1.2.2数据库种类及特点
阐明系统内应用数据库种类、各自特点、数量及如何实现互联，数据如何传递。
5.4.3.1.2.3数据库逻辑构造
阐明数据库概念模式向逻辑模式转换所采用办法论及工具，完毕数据库概念模式向逻辑模式转换。
详细列出所使用数据构造中每个数据项、记录和文献标记、定义、长度及它们之间互有关系。
此节内容为数据库设计重要某些。
5.4.3.1.2.4物理构造设计
列出所使用数据构造中每个数据项存储规定、访问办法、存取单位和存取物理关系等。
建立系统程序员视图，涉及：
数据在内存中安排，涉及对索引区、缓冲区设计；所使用外存设备及外存空间组织，涉及索引区、数据块组织与划分；访问数据方式办法。
5.4.3.1.2.5数据库安全
阐明数据共享方式，如何保证数据安全性及保密性。
5.4.3.1.2.6数据字典
编写详细数据字典。
对数据库设计中涉及到各种项目，如数据项、记录、系、文卷模式、子模式等普通要建立起数据字典，以阐明它们标记符、同义名及关于信息
5.4.4详细设计
在详细设计阶段，项目组应对概要设计中产生软件部件进行办法和过程描述，对程序单元内部细节（算法模型、数据构造、详细接口信息等）进行设计，为源代码提供必要阐明，并编写《软件详细设计阐明》，由研究室或项目组负责人审批。
详细设计过程中开始编制《软件测试筹划》草稿。
研究室或项目组应组织对详细设计阐明进行评审（顾客参加），以保证程序单元功能、控制构造、数据构造和算法模型对的性、合理性，程序单元接口明确性、一致性。
项目组应保持评审成果及任何必要办法记录。
输出：
《软件详细设计阐明书》（详细设计某些）格式参照附录4《软件详细设计阐明书》
6软件开发
6.1建立项目开发团队
根据业务需求开发任务书中，对项目完毕时间、费用规定，确认项目开发团队人员数量，明确项目经理，建立以项目经理为项目负责人开发团队。
团队组建完毕后，项目经理组织团队人员进行交流学习和互相熟悉，阐明项目任务、目的、规模、人员构成、规章制度和行为准则，个人岗位和责任，建立团队与外界初步联系及互有关系，确立团队权限，建立团队绩效管理机制，争取公司各方面支持，依照团员特点分派职责，收集关于项目信息。
6.2实行项目开发测试
根据公司软件项目设计开发制度规定和软件项目管理规范，按照需求实现方案为项目详细开发做好准备。
1技术人员在项目实现方案框架下
2依照项目实际规定准备好开发环境和测试环境;
3程序员编写程序代码，测试人员设计测试方案和应用案例;
4是对需求实现功能阐明书和测试筹划、测试案例进行评审;
5撰写测试问题报告，改正软件Bug;
6按照规定定期提交有关项目管理信息资料。
6.3工作内容
软件实现阶段重要工作是依照软件设计成果，进行软件代码编制、调试、代码审查和程序单元测试，验证程序单元与设计阐明一致性。
本阶段代码审查和单元测试应以开发人员自查自测为主。
实现过程中应规定编码实现规则、编程语言、数据构造、命名商定和注释规则等并遵守这些规则；尽量使用辅助设计工具；尽量地重用已有软件实现规范、实现办法、代码片段、数据构造、原则函数等。
进行规范化编程，采用统一编码风格；实现过程中应全面考虑软件测试工作；充分地考虑到软件可维护性。
软件实现过程中，项目组应组织程序调试、代码自查和程序单元自测，重要涉及对软件各功能模块编码对的性、程序设计准则符合性、程序单元测试过程与成果合理性和对的性以及测试辅助程序合理性和充分性进行审查和验证，以保证交付测试软件与软件设计阐明完全符合。
与外部存在多系统交联时，需要组织或参加联合调试实验，以验证接口对的性。
软件实现阶段应开始编写《顾客使用手册》和《软件测试阐明》文档。
输出：
1、《顾客使用手册》，格式参照附录5《顾客使用手册》
2、《软件测试阐明》，格式参照附录6《软件测试阐明》
6.4产物/成果
项目阶段/角色
项目经理
产品团队
（BA/BAS/ProductM）
开发团队
TTL/Developer）
测试团队
（TestLead/Tester）
开发阶段
活动：
1、监控项目进度
2、调节人员安排
3、跟踪解决技术难点
产出：
1、项目筹划（更新进度）
活动：
1、详细功能开发
产出：
1、功能单元代码
活动：
1、编写测试用例
和.自动化脚本
组织测试用例评审
产出：
1、测试用例
2、自动化脚本
单元测试阶段
活动：
1、监控项目进度
2、踪解决问题列表
产出：
1、项目筹划（更新进度）
2、项目进度报告
活动：
1、组织代码走查
2、单元测试
产出：
1、功能单元代码
2、单元测试报告
7项目测试
7.1软件测试阶段
7.2概述
软件错误是不可避免，因此必要通过严格测试。
通过对本软件测试，尽量发现软件中错误，借以减少系统内部各模块逻辑，功能上缺陷和错误，保证每个单元能对的地实现其预期功能。
检测和排除子系统（或系统）构造或相应程序构造上错误，使所有系统单元配合适当，整体性能和功能完整。
并且使组装好软件功能与需求保持一致。
7.3流程
7.4软件测试准备
测试组从软件需求分析阶段开始介入，对需求进行分析，风险分析，测试范畴等等。
即开始编制软件测试筹划，在软件概要设计、详细设计和编程实现过程中逐渐完善，最后形成《软件测试筹划》，并组织测试筹划评审。
软件测试筹划完毕后开始编写有关测试方案，编写测试用例，搭建测试环境。
测试用例完毕后进行评审，冒烟测试用例覆盖率必要达到100%，系统测试用例达到95%，
输出：
1）《软件测试筹划》，格式参照附录8《软件测试筹划》；
2）《软件测试阐明》（含测试用例和测试程序），格式参照附录6《软件测试阐明》；
3）《软件测试方案》，格式参照附录9《软件测试方案》；
4）《测试用例文档》，格式参照附录10《测试用例文档》；
7.5软件测试执行
测试人员根据《测试用例》进行软件测试，对发现错误进入缺陷管理流程，并进行回归测试以验证修改对的性。
测试结束后，测试人员应编写《缺陷报告》，及《软件测试报告》。
在测试阶段后期，组织《软件测试报告》评审，重要对软件测试办法、测试过程和测试成果有效性和对的性进行审查和评价。
项目组应保持评审成果及任何必要办法记录。
输出：
《缺陷报告》，格式参照附录11《缺陷报告》；
《软件测试报告》，格式参照附录12《软件测试报告》。
8内部验收
项目完毕集成测试和系统测试后进行项目内部验收，重要有三个环节：
8.1文档准备
项目经理提交内部验收筹划、项目开发总结报告、产品发布清单；财务主管提交项目财务预算报告。
8.2内部验收测试
内部验收测试测试内容与办法虽然与系统测试基本相似，但应站在顾客验收角度进行，由于它是试运营基本，通过这一步，为顾客验收作充分准备。
8.3内部评审
对提交所有文档及测试成果进行内部评审，完毕项目开发总结报告。
9项目试运营与验收
试运营与顾客验收阶段重要任务是，使所有工作产品得到顾客确认。
重要工作有：
9.1验收前准备
项目经理负责检查产品完整性，涉及文档、介质和中间产品等，以保证现场实行成功；负责应用软件现场安装调试，完毕安装调试总结报告；负责制定顾客验收筹划，并得到客户确认。
9.2顾客测试
顾客进行验收测试和系统试运营，进行文档和系统移送。
9.3顾客确认
项目经理负责与客户协调，协助顾客进行项目验收，形成顾客验收报告。
10项目维护
10.1错性维护
由于前期测试不也许暴露软件系统中所有潜在和隐含错误，诊断和改正这些错误过程。
10.2完善性维护
在软件正常使用过程中，顾客还会不断地提出新需求，为了满足顾客新需求而增长软件功能活动称为完善性维护。
如果需求变更很大，那完善性维护将转变为软件新版本开发。
系统维护宗旨就是提高客户对软件产品满意度。
保证系统正常运营是系统维护主线目。
11需求变更流程
11.1目
指引项目部、软件部、质量部、测试部对产品软件变更需求（简称CR）进行控制和管理，规范相应作业流程, 详细地定义了各流程环节中状态、角色和动作。
明确流程中各角色职责
规范软件缺陷变更过程
11.2合用范畴
所有项目软件变更需求控制管理。
11.3作业流程
11.4流程描述
1．项目需求拟定，项目筹划确认后。
在项目任何阶段，如有任何需求变动发起。
2．判断与否有必要做需求变更？
3．如拟定需要需求变更，评估与否对项目既有设计或实既有影响？
4．如果有影响：
暂停设计或实现，考虑新需求，重新需求分析，设计，实现，修改项目筹划。
5．如果没有影响：
评估新需求与否紧急？
需要加入当前项目，或在下一项目实现？
6．如果加入当前项目：
增长新需求工作量，更新项目筹划。
7．如果在下一项目实现：
在下一项目开始前，收集所有可加入下一项目需求变更。
在下一项目范畴内考虑。
11.4.1内部项目
顾客提出需求-》项目组对问题进行分析（不明确问题要进行确认，区别问题优先级和解决方案）-》提交变更申请表（包括预计和筹划）-》高层领导决策-》审批通过-》依照项目筹划执行 。
内部项目普通需求控制权在高层领导中，有时候不一定关注成本，偏重于系统产生价值，对顾客并且重要关注实用和易用性上。
项目经理或团队重要侧重分析顾客需求合理性。
11.4.2外部项目
顾客提出需求-》项目组对问题进行分析（过滤需求与否合理、与否在本版本来做、能否放到二期、需求必要性等）-》与客户讨价还价（把不合理需求、不必要在本期实现功能推掉）-》必要要实现需求-》提交需求变更申请（初步筹划和解决方案）-》高层领导决策-》详细分析需求和解决方案-》评估工作量-》设定筹划-》客户签字确认-》依照项目筹划执行。
外部项目一方面应当考虑是公司投入成本和获取收益，例如变更会给公司增长合同额或后期市场拓展机会和对产皮提炼（有项目是项目型产品）。
如果上述条件不满足，则首要考虑是如何推掉需求。
11.5提交需求变更
编写要尽量详细，并通过客户、高层经理和项目组内部人员承认。
例如测试人员对测试工作量要参加评估，开发人员对开发工作量要进行评估。
数据来源基于基层，保证数据精确性。
同步补充一点变更带来质控工作量也应当纳入到变更需求表中，例如也许设计项目总结和数据记录工作量。
客户提交问题要做好详细记录，保证有据可查，对问题要进行面对面确认，避免含糊其词顾客需求。
对确认成果进行记录。
输出：
《需求变更申请表》，格式参照附录13《需求变更申请表》》；
11.6审核评审
11.6.1工作内容
评审组织者组织有关评审者对需求表进行评审。
评审者提出评审意见，组织者汇总所有评审意见，并通过开会讨论方式决定对需求表最后评审意见。
11.6.2有关角色
发起者：
需求表发起者。
评审组织者：
公司领导、部门领导，特别是策划部领导。
评审者：
公司领导、部门领导、发起者等其她人员。
11.7反馈
产品经理按评审结论修改相应需求条目，并发布需求版本。
12附录
12.1附录1《软件需求阐明书》
12.2附录2《概要设计阐明书》
12.3附录3《数据库设计阐明书》
12.4附录4《详细设计阐明书》
12.5附录5《顾客使用手册》
12.6附录6《软件测试阐明》
12.7附录7《项目开发筹划》
12.8附录8《软件测试筹划》
12.9附录9《软件测试方案》
12
升级会员 