收藏 分销(赏)

软件开发统一标准化工作作业流程.doc

上传人:w****g 文档编号:2805807 上传时间:2024-06-06 格式:DOC 页数:23 大小:429.54KB
下载 相关 举报
软件开发统一标准化工作作业流程.doc_第1页
第1页 / 共23页
软件开发统一标准化工作作业流程.doc_第2页
第2页 / 共23页
软件开发统一标准化工作作业流程.doc_第3页
第3页 / 共23页
软件开发统一标准化工作作业流程.doc_第4页
第4页 / 共23页
软件开发统一标准化工作作业流程.doc_第5页
第5页 / 共23页
点击查看更多>>
资源描述

1、目录1引言31.1编写目的31.2适用范围31.3定义31.4流程图32需求调研42.1概述42.2需求调研42.3注意事项43可行性分析54需求分析54.1概述54.2产物/成果64.3需求分析任务64.4需求分析方法64.4.1原型化64.5需求报告74.6划分需求的优先级74.7评审需求文档和原型75系统设计75.1概述85.2产物/成果85.3产品设计85.3.1概述85.3.2流程图95.4软件设计95.4.1概述95.4.2流程图95.4.3概要设计95.4.3.1数据库系统设计105.4.4详细设计116软件开发116.1建立项目开发团队116.2实施项目开发测试116.3工作内

2、容126.4产物/成果127项目测试137.1软件测试阶段137.2概述137.3流程137.4软件测试准备137.5软件测试执行148内部验收148.1文档准备148.2内部验收测试148.3内部评审149项目试运行与验收159.1验收前的准备159.2用户测试159.3用户确认1510项目维护1510.1错性维护1510.2完善性维护1511需求变更流程1611.1目的1611.2适用范围1611.3作业流程1711.4流程描述1711.4.1内部项目1811.4.2外部项目1811.5提交需求变更1811.6审核评审1811.6.1工作内容1811.6.2相关角色1911.7反馈1912

3、附录2012.1附录1软件需求说明书2012.2附录2概要设计说明书2012.3附录3数据库设计说明书2012.4附录4详细设计说明书2012.5附录5用户使用手册2012.6附录6软件测试说明2012.7附录7项目开发计划2012.8附录8软件测试计划2012.9附录9软件测试方案2012.10附录10测试用例文档2012.11附录11缺陷报告2012.12附录12软件测试报告2012.13附录13需求变更申请表20软件开发原则化工作流程1 引言1.1 编写目阐明编写这份软件开发原则化工作流程目,指出预期读者。1.2 合用范畴互联网开发中心所有项目。1.3 定义列出本文献中用到专门术语定义、

4、外文首字母组词原词组。1.4 流程图需求调研系统设计软件开发软件测试内部验收客户验收系统维护需求分析阶段概要设计阶段详细设计阶段系统编码阶段系统测试阶段集成测试阶段系统测试阶段项目管理过程评审过程软件监督与审核过程软件配备管理过程软件需求管理过程变更控制过规程文档控制规程文档开发与管理规范项 目 流 程项目开发各阶段过程管理思想需求分析2 需求调研2.1 概述需求调研对于一种应用软件开发来说,是一种系统开发开始阶段,需求调研质量对于一种应用软件来说,是一种极其重要阶段,它质量在一定限度上来说决定了一种软件交付成果。如何从客户中听取顾客需求、分析顾客需求就成为调研人员最重要任务。 2.2 需求调

5、研总体而言,需求调研可按照业务流程、业务规则、表单数据、贯穿系统关系四个方向来进行调研。l 业务规则各个流程、功能点等事项办理,都会有有关约束或条件,那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象普通为操作员。 l 表单数据对各个功能点业务数据、数据项、表单格式、查询条件以及其他有关数据进行明确分析调研。调研对象普通为操作员。 l 贯穿系统关系各个模块或科室之间数据互换、传递以及数据共享等,需要咱们调研人员与各个模块或科室有关负责人进行多方沟通,拟定一种多方满意需求调研成果。 2.3 注意事项l 调研过程中,顾客说不久,不也许等咱们所有记录之后,再讲下一种问题。因而

6、,只能在笔记本上速记,有时只能记录1、2个核心字。因而,每天调研结束之后,当天晚上必要整顿当天调研状况,写成一份调研日记。整顿当天调研记录时,还要整顿出待明确问题,下一次再找机会与顾客再沟通、确认。l 调研各个阶段,必要出具有关文档或文献,例如调研筹划、流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 l 所有疑问必要等到明确答复,不能浮现互相矛盾、似是而非需求。需精确理解客户解说,如果有问题先做记录,之后将整顿问题向客户询问,得到明确成果。需求必要是客户接受和确认,不能有臆测需求。l 要合理安排好时间和进度。有时候客户尚有自己要做事情,不一定能及时相应。因此必要提前预

7、约好时间,保证整个需求调研进度。 l 能积极引导客户。当客户浮现疑虑,而调研人员能明白且能做好客户想要东西时候,调研人员能及时积极引导客户,详细解说咱们所懂得东西,并能让客户接受与确认。l 如遇公司有有关原型或产品,调研人员需先详细理解公司有关原型和产品,依照成品,找出本地化差别化需求。3 可行性分析这个阶段要回答核心问题:“对于上一种阶段所拟定问题有行得通解决办法吗?”为了回答这个问题,系统分析员需要进行一次大大压缩和简化了系统分析和设计过程,也就是在较抽象高层次上进行分析和设计过程。可行性研究应当比较简短,这个阶段任务不是详细解决问题,而是研究问题范畴,摸索这个问题与否值得去解,与否有可行

8、解决办法。在问题定义阶段提出对工程目的和规模报告普通比较含糊。可行性研究阶段应当导出系统高层逻辑模型(通惯用数据流图表达),并且在此基本上更精确、更详细地拟定工程规模和目的。然后分析员更精确地预计系统成本和效益,对建议系统进行仔细成本效益分析是这个阶段重要任务之一。可行性研究成果是使用部门负责人做出与否继续进行这项工程决定重要根据,普通说来,只有投资也许获得较大效益那些工程项目才值得继续进行下去。可行性研究后来那些阶段将需要投入更多人力物力。及时中断不值得投资工程项目,可以避免更大挥霍。 4 需求分析4.1 概述这个阶段任务依然不是详细地解决问题,而是精确地拟定“为理解决这个问题,目的系统必要

9、做什么”,重要是拟定目的系统必要具备哪些功能。 顾客理解她们所面对问题,懂得必要做什么,但是普通不能完整精确地表达出她们规定,更不懂得如何运用计算机解决她们问题;软件开发人员懂得如何使用软件实现人们规定,但是对特定顾客详细规定并不完全清晰。因而系统分析员在需求分析阶段必要和顾客密切配合,充分交流信息,以得出通过顾客确认系统逻辑模型。通惯用数据流图、数据字典和简要算法描述表达系统逻辑模型。在需求分析阶段拟定系统逻辑模型是后来设计和实现目的系统基本,因而必要精确完整地体现顾客规定。系统分析员普通都是计算机软件专家,技术专家普通都喜欢不久着手进行详细设计,然而,一旦分析员开始谈论程序设计细节,就会脱

10、离顾客,使她们不能继续提出她们规定和建议。较件工程使用构造分析设计办法为每个阶段都规定了特定结束原则,需求分析阶段必要提供完整精确系统逻辑模型,通过顾客确认之后才干进入下一种阶段,这就可以有效地防止和克服急于着手进行详细设计倾向。需求分析是软件工程中一种重要环节。是关乎软件开发成败重要因素。当前软件项目中返工开销几乎占了总开发一半,而导致返工重要因素是需求分析不明确。从而引起软件开发中某些列更改。这些更改也许导致挥霍大量资源、软件项目无法准时完毕等严重问题,因此需求分析是软件设计和实现基本,是软件项目迈向成功重中之重。4.2 产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Produc

11、t M)开发团队TTL/Developer)测试团队(Test Lead /Tester)需求阶段活动:1、建立CQ/QC中项目目录;2、在SVN中建立项目目录;1、分析项目所需资源,风险等2、预估项目周期产出:1、项目筹划(大体时间规划)活动:1、收集整顿需求产出:1、需求阐明书参加:1、需求分析2、环境分析参加:1、需求分析2、环境分析4.3 需求分析任务简言之,需求分析任务就是解决“做什么”问题,就是依照需求调研,全面理解顾客各项规定并精确表达所接受顾客需求。4.4 需求分析办法4.4.1 原型化原型就是软件一种初期可运营版本,它实现了目的系统某些或所有功能。原型化办法就是尽量快地建造一

12、种粗糙系统,这系统实现了目的系统某些或者所有功能,但是这个系统也许在可靠性,界面和谐性或其她方面上存在缺陷。建造这样一种系统目是为了考察某一方面可行性,如算法可行性,技术可行性,或考察与否满足顾客需求等。如,为了考察与否满足顾客需求,可以用某些软件工具迅速建造一种原型系统,这个系统只是一种界面,然后听取顾客意见改进这个原型。后来目的系统就在原型系统基本上开发。原型重要有三种类型:l 摸索型目是要弄清晰对目的系统规定,拟定所但愿特性,并探讨各种方案可行性。l 实验型用于大规模开发和实现前,考核方案与否适当,规格阐明与否可靠。l 进化型目不在于改进规格阐明,而是将系统建造得易于变化,在改进原型过程

13、中,逐渐将原型进化成最后系统。在使用原型办法是有两种不同方略。l 废弃方略先建造一种功能简朴并且质量规定不高模型系统,针对这个系统重复进行修改,形成比较好思想,据此设计出比较完整,精确,一致,可靠最后系统。系统构建完毕后,本来模型系统被废弃不用。摸索型和实验型属于这种方略。l 追加方略先构造一种功能简朴并且质量规定不高模型系统,最为最后系统核心,然后通过不断地扩充修改,逐渐追加新规定,发展成为最后系统。进化型属于这种方略。4.5 需求报告需求报告及软件需求阐明书,作用在于便于顾客、开发人员进行理解和交流,反映出顾客问题构造,可以作为软件开发工作基本和根据,并作为确认测试和验收根据。通过从客户那

14、里获得所有信息进行整顿,以区别业务需求及规范、功能需求、质量目的、解决办法和其她信息。通过这些分析,形成一份软件需求阐明书 ,此份阐明书使开发人员和客户之间针对要开发产品内容达到合同。客户需要评审此文档,以保证内容精确完整表达其需求。一份高质量“需求阐明书”有助于开发人员开发出真正需要产品。输出:软件需求阐明书,格式参照 附录1软件需求阐明书4.6 划分需求优先级绝大多数项目没有足够时间或者资源实现功能性每个细节。决定哪些特性是必要,哪些是重要,是需求开发重要某些,这只能由客户负责设定需求优先级,由于开发者不也许按照客户观点决定需求优先级。开发人员将为拟定优先级提供关于每个需求耗费和风险信息。

15、在时间和资源限制下,关于所需特性能否完毕或者完毕多少,开发人员必要给出意见。4.7 评审需求文档和原型客户评审需求文档,是给分析人员带来反馈信息一种机会。如果客户人为编写“需求分析报告”不够准去,就有必要尽早告知分析人员并为改进提供建议。更好办法是先为产品开发一种原型。这样客户就能提供更有价值反馈信息给开发人员,是她们更好理解需求。原型并非是一种实际应用产品,但开发人员能将其转化、扩充成功能齐全系统。5 系统设计制定项目筹划软件项目筹划是一种用来协调所有其她筹划,以指引项目执行和控制可操作文献。它体现了对客户需求理解,是开展项目活动基本,也是软件项目跟踪与监控根据。拟定开发过程依照软件项目和项

16、目组实际状况,建立起一种稳定、可控软件开发过程模型,并按照该过程来进行软件开发。加强过程控制过程控制重要涉及过程管理、变更控制和配备管理。5.1 概述此阶段重要是依照需求分析成果,对整个软件系统进行设计,如系统框架设计,数据库设计等等。5.2 产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Product M)开发团队TTL/Developer)测试团队(Test Lead /Tester)设计阶段活动:1、监控项目进度,2、组织安排本阶段评审1、任务分解,责任到人2、细化项目筹划产出:1、 项目筹划(详细到各功能)参加:1、系统功能设计产出:1、 界面原型活动:1、系统功能技术设计2

17、、数据库设计产出:1、 系统功能技术设计2、 数据库设计阐明书活动:1、组织测试筹划评审产出:1、项目测试预计测试筹划书5.3 产品设计5.3.1 概述产品设计是专业技术人员依照软件项目需求分析成果来对整个软件系统进行定制、开发、设计一种过程。5.3.2 流程图5.4 软件设计5.4.1 概述软件设计阶段重要工作可分为软件概要设计、详细设计两个分阶段。对于复杂限度不高、规模较小或核心性级别较低软件,可将概要设计和详细设计合并为一种阶段执行。5.4.2 流程图5.4.3 概要设计在概要设计阶段,项目组应依照软件总体框架、软件模型和软件工程实现规定,提出软件设计办法,建立软件总体构造,划分功能模块

18、(软件部件),拟定总体构造和部件间关系,定义各个软件功能模块功能、数据接口和控制接口,设计全局数据库/数据构造,规定设计限制,编写概要设计阐明,由研究室或项目组负责人审批。对于复杂软件,研究室或项目组应组织对软件概要设计进行评审,以保证软件构造、全局数据构造、重要算法、模块划分、接口关系和软件模型合理性、对的性、完整性,与软件需求一致性。项目组应保持评审成果及任何必要办法记录。输出:软件概要设计阐明书(概要设计某些),格式参照 附录2软件概要设计阐明书5.4.3.1 数据库系统设计此数据库设计可单独成册,特别对大型数据库应用系统,即有一种单独数据库设计阐明书。输出:数据库设计阐明书,格式参照

19、附录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 数据库逻辑构造阐明数据库概念模式向逻辑模式转换所采用办法论及工具,完毕数据库概念模式向逻辑模式转换。 详细列出所使

20、用数据构造中每个数据项、记录和文献标记、定义、长度及它们之间互有关系。此节内容为数据库设计重要某些。5.4.3.1.2.4 物理构造设计 列出所使用数据构造中每个数据项存储规定、访问办法、存取单位和存取物理关系等。建立系统程序员视图,涉及: 数据在内存中安排,涉及对索引区、缓冲区设计; 所使用外存设备及外存空间组织,涉及索引区、数据块组织与划分;访问数据方式办法。5.4.3.1.2.5 数据库安全阐明数据共享方式,如何保证数据安全性及保密性。5.4.3.1.2.6 数据字典编写详细数据字典。 对数据库设计中涉及到各种项目,如数据项、记录、系、文卷模式、子模式等普通要建立起数据字典,以阐明它们标

21、记符、同义名及关于信息5.4.4 详细设计在详细设计阶段,项目组应对概要设计中产生软件部件进行办法和过程描述,对程序单元内部细节(算法模型、数据构造、详细接口信息等)进行设计,为源代码提供必要阐明,并编写软件详细设计阐明,由研究室或项目组负责人审批。详细设计过程中开始编制软件测试筹划草稿。研究室或项目组应组织对详细设计阐明进行评审(顾客参加),以保证程序单元功能、控制构造、数据构造和算法模型对的性、合理性,程序单元接口明确性、一致性。项目组应保持评审成果及任何必要办法记录。输出:软件详细设计阐明书(详细设计某些)格式参照 附录4软件详细设计阐明书6 软件开发6.1 建立项目开发团队根据业务需求

22、开发任务书中,对项目完毕时间、费用规定,确认项目开发团队人员数量,明确项目经理,建立以项目经理为项目负责人开发团队。团队组建完毕后,项目经理组织团队人员进行交流学习和互相熟悉,阐明项目任务、目的、规模、人员构成、规章制度和行为准则,个人岗位和责任,建立团队与外界初步联系及互有关系,确立团队权限,建立团队绩效管理机制,争取公司各方面支持,依照团员特点分派职责,收集关于项目信息。6.2 实行项目开发测试根据公司软件项目设计开发制度规定和软件项目管理规范,按照需求实现方案为项目详细开发做好准备。 技术人员在项目实现方案框架下 依照项目实际规定准备好开发环境和测试环境; 程序员编写程序代码,测试人员设

23、计测试方案和应用案例; 是对需求实现功能阐明书和测试筹划、测试案例进行评审; 撰写测试问题报告,改正软件Bug; 按照规定定期提交有关项目管理信息资料。6.3 工作内容软件实现阶段重要工作是依照软件设计成果,进行软件代码编制、调试、代码审查和程序单元测试,验证程序单元与设计阐明一致性。本阶段代码审查和单元测试应以开发人员自查自测为主。实现过程中应规定编码实现规则、编程语言、数据构造、命名商定和注释规则等并遵守这些规则;尽量使用辅助设计工具;尽量地重用已有软件实现规范、实现办法、代码片段、数据构造、原则函数等。进行规范化编程,采用统一编码风格;实现过程中应全面考虑软件测试工作;充分地考虑到软件可

24、维护性。软件实现过程中,项目组应组织程序调试、代码自查和程序单元自测,重要涉及对软件各功能模块编码对的性、程序设计准则符合性、程序单元测试过程与成果合理性和对的性以及测试辅助程序合理性和充分性进行审查和验证,以保证交付测试软件与软件设计阐明完全符合。与外部存在多系统交联时,需要组织或参加联合调试实验,以验证接口对的性。软件实现阶段应开始编写顾客使用手册和软件测试阐明文档。输出:1、顾客使用手册,格式参照 附录5顾客使用手册2、软件测试阐明,格式参照 附录6软件测试阐明6.4 产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Product M)开发团队TTL/Developer)测试团队

25、(Test Lead /Tester)开发阶段活动:1、监控项目进度2、调节人员安排3、跟踪解决技术难点产出:1、项目筹划(更新进度)活动:1、详细功能开发产出:1、功能单元代码活动:1、编写测试用例和.自动化脚本组织测试用例评审产出:1、测试用例2、自动化脚本单元测试阶段活动:1、监控项目进度2、踪解决问题列表产出:1、项目筹划(更新进度)2、项目进度报告活动: 1、组织代码走查2、单元测试产出: 1、功能单元代码2、单元测试报告7 项目测试7.1 软件测试阶段7.2 概述软件错误是不可避免,因此必要通过严格测试。通过对本软件测试,尽量发现软件中错误,借以减少系统内部各模块逻辑,功能上缺陷和

26、错误,保证每个单元能对的地实现其预期功能。检测和排除子系统(或系统)构造或相应程序构造上错误,使所有系统单元配合适当,整体性能和功能完整。并且使组装好软件功能与需求保持一致。7.3 流程7.4 软件测试准备测试组从软件需求分析阶段开始介入,对需求进行分析,风险分析,测试范畴等等。即开始编制软件测试筹划,在软件概要设计、详细设计和编程实现过程中逐渐完善,最后形成软件测试筹划,并组织测试筹划评审。软件测试筹划完毕后开始编写有关测试方案,编写测试用例,搭建测试环境。测试用例完毕后进行评审,冒烟测试用例覆盖率必要达到100%,系统测试用例达到95%,输出:1)软件测试筹划,格式参照 附录8软件测试筹划

27、;2)软件测试阐明(含测试用例和测试程序),格式参照 附录6软件测试阐明;3)软件测试方案,格式参照 附录9软件测试方案;4)测试用例文档,格式参照 附录10测试用例文档;7.5 软件测试执行测试人员根据测试用例进行软件测试,对发现错误进入缺陷管理流程,并进行回归测试以验证修改对的性。测试结束后,测试人员应编写缺陷报告,及软件测试报告。在测试阶段后期,组织软件测试报告评审,重要对软件测试办法、测试过程和测试成果有效性和对的性进行审查和评价。项目组应保持评审成果及任何必要办法记录。输出:缺陷报告,格式参照 附录11缺陷报告;软件测试报告,格式参照 附录12软件测试报告。8 内部验收项目完毕集成测

28、试和系统测试后进行项目内部验收,重要有三个环节:8.1 文档准备项目经理提交内部验收筹划、项目开发总结报告、产品发布清单;财务主管提交项目财务预算报告。8.2 内部验收测试内部验收测试测试内容与办法虽然与系统测试基本相似,但应站在顾客验收角度进行,由于它是试运营基本,通过这一步,为顾客验收作充分准备。8.3 内部评审对提交所有文档及测试成果进行内部评审,完毕项目开发总结报告。9 项目试运营与验收试运营与顾客验收阶段重要任务是,使所有工作产品得到顾客确认。重要工作有:9.1 验收前准备项目经理负责检查产品完整性,涉及文档、介质和中间产品等,以保证现场实行成功;负责应用软件现场安装调试,完毕安装调

29、试总结报告;负责制定顾客验收筹划,并得到客户确认。9.2 顾客测试顾客进行验收测试和系统试运营,进行文档和系统移送。9.3 顾客确认项目经理负责与客户协调,协助顾客进行项目验收,形成顾客验收报告。10 项目维护10.1 错性维护由于前期测试不也许暴露软件系统中所有潜在和隐含错误,诊断和改正这些错误过程。10.2 完善性维护在软件正常使用过程中,顾客还会不断地提出新需求,为了满足顾客新需求而增长软件功能活动称为完善性维护。如果需求变更很大,那完善性维护将转变为软件新版本开发。系统维护宗旨就是提高客户对软件产品满意度。保证系统正常运营是系统维护主线目。11 需求变更流程11.1 目指引项目部、软件

30、部、质量部、测试部对产品软件变更需求(简称CR)进行控制和管理,规范相应作业流程,详细地定义了各流程环节中状态、角色和动作。明确流程中各角色职责规范软件缺陷变更过程11.2 合用范畴所有项目软件变更需求控制管理。11.3 作业流程11.4 流程描述1项目需求拟定,项目筹划确认后。在项目任何阶段,如有任何需求变动发起。2判断与否有必要做需求变更?3如拟定需要需求变更,评估与否对项目既有设计或实既有影响?4如果有影响:暂停设计或实现,考虑新需求,重新需求分析,设计,实现,修改项目筹划。5如果没有影响:评估新需求与否紧急?需要加入当前项目,或在下一项目实现?6如果加入当前项目:增长新需求工作量,更新

31、项目筹划。7如果在下一项目实现:在下一项目开始前,收集所有可加入下一项目需求变更。在下一项目范畴内考虑。11.4.1 内部项目顾客提出需求-项目组对问题进行分析(不明确问题要进行确认,区别问题优先级和解决方案)-提交变更申请表(包括预计和筹划)-高层领导决策-审批通过-依照项目筹划执行。内部项目普通需求控制权在高层领导中,有时候不一定关注成本,偏重于系统产生价值,对顾客并且重要关注实用和易用性上。项目经理或团队重要侧重分析顾客需求合理性。11.4.2 外部项目顾客提出需求-项目组对问题进行分析(过滤需求与否合理、与否在本版本来做、能否放到二期、需求必要性等)-与客户讨价还价(把不合理需求、不必

32、要在本期实现功能推掉)-必要要实现需求-提交需求变更申请(初步筹划和解决方案)-高层领导决策-详细分析需求和解决方案-评估工作量-设定筹划-客户签字确认-依照项目筹划执行。外部项目一方面应当考虑是公司投入成本和获取收益,例如变更会给公司增长合同额或后期市场拓展机会和对产皮提炼(有项目是项目型产品)。如果上述条件不满足,则首要考虑是如何推掉需求。11.5 提交需求变更编写要尽量详细,并通过客户、高层经理和项目组内部人员承认。例如测试人员对测试工作量要参加评估,开发人员对开发工作量要进行评估。数据来源基于基层,保证数据精确性。同步补充一点变更带来质控工作量也应当纳入到变更需求表中,例如也许设计项目

33、总结和数据记录工作量。客户提交问题要做好详细记录,保证有据可查,对问题要进行面对面确认,避免含糊其词顾客需求。对确认成果进行记录。输出:需求变更申请表,格式参照 附录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.10 附录10测试用例文档12.11 附录11缺陷报告12.12 附录12软件测试报告12.13 附录13需求变更申请表

展开阅读全文
相似文档                                   自信AI助手自信AI助手
猜你喜欢                                   自信AI导航自信AI导航
搜索标签

当前位置:首页 > 品牌综合 > 行业标准/行业规范

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服