软件设计和开发控制程序(软件设计).docx

上传人:李司机 文档编号:6203098 上传时间:2023-10-04 格式:DOCX 页数:9 大小:28.37KB
返回 下载 相关 举报
软件设计和开发控制程序(软件设计).docx_第1页
第1页 / 共9页
软件设计和开发控制程序(软件设计).docx_第2页
第2页 / 共9页
软件设计和开发控制程序(软件设计).docx_第3页
第3页 / 共9页
软件设计和开发控制程序(软件设计).docx_第4页
第4页 / 共9页
软件设计和开发控制程序(软件设计).docx_第5页
第5页 / 共9页
点击查看更多>>
资源描述

《软件设计和开发控制程序(软件设计).docx》由会员分享,可在线阅读,更多相关《软件设计和开发控制程序(软件设计).docx(9页珍藏版)》请在三一办公上搜索。

1、软件设计和开发控制程序1目的与适用范围本程序规定了软件设计和开发的控制要求及质量职责。本程序用于本公司的软件设计和开发。2术语和定义配置:配置是指一个软件产品在生存周期的各个阶段所产生的各个形式(机器可读或人工可读)和各种版本的文档、程序及其数据的集合,该集合随着开发工作的进展而不断变化。配置项:为了配置管理目的而作为一个单元来看待的软件成分,或它们的集合体(软件项及开发文档都称为配置项)。开发库:指在软件生存周期的某一个阶段期间,存放与该阶段软件开发有关的计算机可读信息和人工可读信息的库。受控库:指在软件生存周期的某一个阶段结束时,存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息

2、和人工可读信息的库。配置管理就是对受控库中的各个软件项进行管理,因此受控库也叫做配置管理库。产品库:指在软件生存周期的部署与系统测试阶段结束后,存放最终产品而后交付给用户运行或在现场安装软件库。软件项:是指组成最终产品的源代码、中间文件、目标运行代码,构成安装程序的源代码、中间文件、目标运行代码以及产品的联机帮助说明文件(源代码包括程序代码、头文件、资源文件等)。3职责3.1 技术部负责软件设计和开发的策划、输入、输出、评审、验证、确认和更改。3.2其他各部门负责所需资源的提供、测试、技术支持等。3.3 软件设计人员应按质量控制要求,认真设计软件,保证设计质量,软件文档应按要求编制,以保证成套

3、性。并加强后期维护质量,负责软件的优化、升级和扩充。3.4 评审人员对评审结果的正确性、有效性负责。3.5技术部经理对整个设计过程进行审核监督。3. 6技术总监对软件设计和开发的控制负领导责任并对设计确认进行批准。4程序4. 4.1技术总监任命项目负责人。5. 1.1技术部设计人员负责编制有关项目设计输入和设计输出文件。4. 1.2项目负责人对软件项目设计的全过程进行管理,并协调和处理软件项目设计过程中的一切事务。4. 2系统设计4.2. 1制定设计开发计划书项目负责人根据合同、“技术协议”和用户需求,组织人员编制设计开发计划书。计划书应包括以下内容:a)项目描述;b)资源的描述和分配;C)项

4、目阶段的划分;d)估计工作量,安排进度计划;4.2.2编制质量计划a)项目负责人在项目策划阶段根据项目的规模、目标、开发周期等具体情况,组织人员编制质量计划。b)质量计划应包括以下的内容: 项目的质量目标; 质量保证活动的职责与权限; 项目开发过程中采取的质量保证措施。4.2.3编制配置管理计划a)配置管理计划具体规定了在项目开发过程中应执行的配置管理的职责、活动和要求。项目的配置管理计划由项目负责人在开发策划阶段编制,由技术总监审批后执行。b)配置管理计划应包括以下内容: 明确配置管理人员; 基线的建立及划分时机; 各阶段需管理的配置项;配置管理使用的工具、技术和方法;适用的标准、惯例和约定

5、;配置项标识方法;各种配置项的更改控制方法;4. 2.4编制测试计划项目负责人组织人员编制测试计划,根据项目的具体情况,从单元测试、组装测试、系统测试、业务测试、验收测试以及一些专项测试中选择至少两种,并尽量保证这两种测试活动不完全是由相同的人员完成的。5. 2.5特别情况3人以下的项目,项目负责人可以按上述各计划的要求,把项目策划活动中应当形成的设计开发计划书、质量计划与测试计划合并成一个计划,仍称为设计开发计划书。6. 3需求分析7. 3.1确定需求分析人员在完成项目策划后,项目负责人指定人员组成需求分析小组,并委任负责人。8. 3.2需求分析实施需求分析小组进行用户需求分析工作,主要了解

6、以下内容:a)用户业务与项目有关的部分;b)用户的工作流程;C)用户的相关部门及职责;d)使用人员的技术水平;e)用户原有系统的现状;f)用户对项目交付成果的期望和具体要求。4.3.3编制需求规格说明书在充分了解用户需求的基础上,需求分析小组编写需求规格说明书(详见需求规格说明书模板,该模板规定了需求规格说明书的内容和要求),编写时可根据具体的项目情况进行调整。必要时,可在有关的章节中引述其它资料作为附录。4.3.4需求评审为保证需求定义的正确性、完整性和清晰性,应对需求规格说明书进行评审,评审主要考虑以下准则:a)客户或潜在客户需要的可追溯性;b)与客户或潜在客户需要的一致性;C)可测试性;

7、d)系统(子系统)设计的可行性;e)操作和维护的可行性。4.3.5需求管理需求规格说明书经评审后,按配置管理程序进行管理;需求规格说明书的修改与变更,应按照4.10更改控制执行。4.4开发设计4.4.1设计原则设计工作应遵循以下原则:a)全面地反映需求规格说明书的各项要求;b)采用适合本项目的系统化的设计方法和模型;C)便于编码实现、测试、维护和使用;d)适当考虑以后的重用性、扩展性和可移植性。4.4.2制订项目开发计划项目负责人根据项目的具体情况选择合适的设计方法和模型,并按照项目的复杂程度决定设计的详细程度,形成项目开发计划。项目开发计划应包括以下内容:a)参与人员及其职责与权限;b)设计

8、工作进度安排;C)采用的设计方法与模型、设计的详细程度以及具体要求;d)设计输出要求。4.4.3编写概要设计设计输出形成概要设计,内容包括:系统软硬件环境、技术性能要求、系统结构、处理流程、数据结构、接口、模块划分、用户界面、关键算法等。项目负责人根据项目自身的要求,必要时编写开发规范,明确项目过程中的约定。4.4.4设计评审设计完成后,项目负责人组织对设计结果进行评审,形成设计评审报告。评审要点:a)设计方案是否满足需求分析结果中的各项要求;b)设计方法和采用标准是否适宜;C)设计方案是否满足质量要求;d)设计方案实现所需投入的人日;e)设计方案的主要优、缺点。4.4.5设计控制与更改评审通

9、过的概要设计纳入配置管理,按配置管理程序进行管理;概要设计的修改与变更,按照4.10更改控制的要求执行。4.5编码实现4.5.1工作准备项目组成员熟悉需求规格说明书和概要设计。4.5.2编码控制项目组成员编码时应严格遵守4.4开发设计或项目组的内部约定,项目负责人或指定专人负责对项目组成员的代码进行抽查,对于违反4.4开发设计的应责令其重新编写,并在周报中记录。4.5.3测试在编码过程中,项目组成员应按照4.6测试和确认以及测试计划的要求进行同步测试,对于发现的错误及时改正。4.5.4用户手册在开发设计过程之后、测试过程执行前完成用户手册的编写,主要内容:a)手册中用到的术语介绍;b)软件安装

10、:详细说明安装软件需要的软、硬件及网络环境,以及安装方法和步骤;c)功能描述:建议采用总分式,即首先总体描述软件产品的功能及其功能划分,再详细描述各个功能。d)应用图表和文字两种方式表述功能图、关系图和操作步骤,对每个输入域、输出域分别解释说明。e)软件产品中用到的功能键的介绍;f)如有需要,特别指出容易出错的操作,说明原因及后果。4.5.5配置管理配置管理负责人按配置管理程序的要求控制各种输出结果。4.6测试和确认规范4.6.1制订测试方案在测试之前,由项目负责人根据测试计划的要求,组织人员编制相应的测试方案,测试方案应包括以下内容:a)测试目的;b)所需人员及相应培训要求;c)测试环境、工

11、具和测试软件;d)测试用例、测试数据和预期的结果。4.6.2单元测试a)项目开发实现过程中,每个程序单元(程序单元的划分视具体开发工具而定,一般定为函数或子程序级)编码调试通过后,要及时进行单元测试。b)单元测试由单元开发者自己进行,使用白盒测试方法,根据程序单元的控制流程,争取达到分支覆盖。对于交互式运行的产品,不便于进行自动测试的,可以采用功能测试的方法进行。4.6.3组装测试a)编码开发完成,项目组内部应进行组装测试。b)组装测试由项目负责人策划并组织实施。组装测试着重对各功能模块之间的接口进行测试,验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法,即个人开发的

12、软件应由其他的项目组成员进行测试。C)组装测试过程应填写测试报告。4.6.4系统测试a)在项目开发完成之后,应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价,以验证系统是否满足规定的需要。b)系统测试由项目负责人策划并组织实施,系统测试过程应形成测试报告。4.6.5业务测试a)在组装测试与系统测试结束后,均可由最终用户或测试人员对系统进行测试。业务测试着重测试业务流程,功能、用户界面等方面。b)项目负责人负责组织相关人员制定测试方案和测试用例,并进行测试。C)测试的结果应形成测试报告。4.6.6验收测试a)在产品交付和用户验收之前,通过验收测试来确认在规

13、定的使用环境下整个产品的运行情况是否满足规定的要求。b)在产品交付之前,由指定的验收负责人组织制定测试方案和测试用例,主持验收。4.6.7测试问题的处理a)对测试中发现的问题及处理,应填写测试报告记录问题的现象,问题提出者、判定问题的性质,分析问题产生的原因,确定修改的优先级、记录对问题的维护情况和验收等信息。b)单元测试无需填写测试报告。C)对已纳入配置管理的配置项的更改,按照测试报告进行控制。4 .6.8测试总结报告在组装测试、系统测试、业务测试和验收测试等完成后,由测试负责人填写测试报告,对测试过程进行总结,并给出测试结论。5 .7设计质量的控制软件设计人员、评审人员在设计评审测试中要保

14、证软件设计质量符合以下要求:(1)正确性:软件的功能能正确、完整地实现需求规格说明书中的要求。(2)可靠性:软件在给予的硬件、软件支持下具有正常工作的能力,以及具有在异常条件下(如输入非法数据、用户操作出错等)继续运行的能力。(3)可维护性:软件进行修改的方便程度,包括一致性、可及性、自说明性、软件结构可扩充性、可更改性,运行过程给出提示并有相应文档。(4)可移植性:软件具有从一个环境(组织环境、硬件环境、软件环境)到另一个环境运行的能力。(5)资源特性:软件执行规定的功能所占内存容量少,占用软件资源和外部设备少,且时间短,消耗的材料和需用操作人员的时间少,通常要保证有20%的余量。(6)时间

15、特性:在规定的和其他必要条件下执行规定的功能的时间或执行这一功能所占用资源的时间最短,要求处理时间的占用有20%的余量。(7)易使用性:软件操作简单,人机通讯方便。(8)安全性:计算机软件中重要的数据资料必须有安全保护措施,具有防盗取的能力。4.8软件质量评审控制(1)软件设计过程中要设立或指定软件质量的检查、评审、测试人员,以做到及时发现问题及时解决问题。(2)应视软件的重要程度及应用范围组织进行评审。评审由技术部组织。(3)各类评审均应由与设计无直接关系的人员进行,并对评审的结果形成记录。(4)软件设计各阶段评审 软件需求规格说明书评审:对软件需求规格说明书进行评审,以保证需求规格说明书中

16、列出的要求是合理且适当的。 软件概要设计评审:对软件概要设计进行评审,以保证软件结构、模块划分、主要算法和接口关系的合理性。 软件详细设计评审:对软件详细设计说明进行评审,以保证模块功能的正确性,控制结构、数据结构和算法的合理性,以及设计的程序与要求的一致性。 软件测试评审:对软件测试计划、方法和测试报告进行评审,以保证测试内容和范围的正确性,测试结果评价的准确性。4.9软件的验收要求软件验收前,必须完成软件的强度测试,满足系统余量要求,并达到验收的错误限制及错误修补限制要求。4.10更改控制处于配置管理下的配置项的更改活动及维护过程中对软件/硬件产品的更改。4.10.1更改申请及审批a)开发

17、文档,如需求规格说明书、概要设计等的更改,需填写配置变更申请表,由项目负责人审批后才能进行改动。修改完成后,应按4.3需求分析或4.4开发设计的要求重新进行评审。b)代码更改,如果该种更改将引起对设计或需求分析阶段的回溯,应执行4.10.1更改申请及审批a)条的规定。如果是对程序接口做更改、或是更改会引起其它部门的协同工作,则应当填写配置变更申请表,并由项目控制主管或项目负责人审批后进行4.10.2更改执行项目组成员按配置变更申请表进行更改。对软件代码的更改,除了要填写配置变更申请表外,还应以程序注释、附件或是管理工具等形式进行标识。配置审核、变更过程中涉及到的相关问题及记录均应以单据的形式记

18、录下来。如:配置审核报告、配置变更和问题登录表、配置问题报告单、配置状态统计报告等。4.10.3更改验证更改后,对被更改的配置项以及可能受影响的配置项进行测试验证,确认其有效性,并做好记录。4.10.4受控库的更改对于受控库的修改,按配置管理程序的规定执行。4. 10.5更改标识更改完成并经过测试验证后,被更改的配置项重新纳入,仍按配置管理程序管理。4.11项目文档控制4.11.1 在软件的不同生存周期,需编制不同的文档,以保证软件文档的成套性。各阶段产生的项目文档包括:文字性输出结果(称为开发文档)和开发过程中所形成的各类质量记录。a)文字性输出结果(称为开发文档):描述所有开发活动的计划和

19、进展文档;描述一个具体软件/硬件产品的产品文档;提供给顾客的文档;维护文档;其它文档。b)开发过程中所形成的各类质量记录:各种评审报告;测试记录;验收记录;更改记录;维护记录;其它记述产质量量活动的记录。4. 12.2文档的编制及记录的填写a)开发文档的编写按照相关文件的规定要求进行。对于文件中给出了格式与要求(模板)的文档,如顾客无特殊要求时,编写人员原则上应按规定的格式和要求进行编写,文档封面使用*项目文档封面。无特定格式的文档建议采用*项目文档封面模板格式。b)质量记录应按有关要求及格式及时填写。记录可采用电子文档或纸质两种形式,但应保持两者的一致性。质量记录的填写应清晰、简明,填写及时

20、完整、准确,不得随意涂改。5. 12.3文档和记录的标识项目文档的记录标识,统一由技术部统一分配。6. 12.4文档的控制和更改项目文档的控制按照配置管理程序的规定执行;纳入配置管理的开发文档的更改须按4.10更改控制的规定进行。7. 12.5文档的归档与保存项目文档在项目实施过程中由项目负责人指定人员负责收集管理。结项后由项目负责人负责组织以上文档的整理。8. 12.6文档借阅项目文档归档后的借阅按照公司的有关规定执行。9. 13文档的签署要求软件文档的审核与批准,可根据软件重要程度,由不同级别的人员签署。签署人要对签署文档的技术全面负责,文档在批准人签署之前应进行审查,经签署后的文档方可归档。5相关文件10. 1配置管理程序10.2 GBT8567计算机软件文档编制规范10.3 GBT9386计算机软件测试文档编制规范10.4 GBT12504计算机软件质量保证计划规范6相关记录10.5 设计开发计划书10.6 质量计划10.7 配置管理计划10.8 测试计划10.9 需求规格说明书10.10 目开发计划10.11 要设计10.12 计评审报告10.13 户手册10.14 测试方案10.15 测试报告5. 12配置变更申请表5.13 配置审核报告5.14 配置变更和问题登录表5.15 配置变更和问题登录表5.16配置状态统计报告

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号