一个比较模糊的概念,也说不出来个具体,没有特别明显的想法。因为用户与开发者思维的不一致,用户很难将他的意思很清晰的传达给开发者。不论是系统软件,还是应用软件,或者手机app,通常这种情况下,开发者也只能借助些工具,例如:AxureRP图形界面工具,Word文档配合插图等方式,按照开发者的理解设计为原型系统,再同客户进行多次的探讨。开发过程中,一定要在系统的早期就尽可能的降低问题域,使系统逐渐明朗。你这个问题也不怎么好回答,也没有个全面的回答,几个或者十几个百个人共同研发出来的,用户要单个人弄透,软件跟音乐一样,都是一通百通的
软件工程的复杂性是指什么? A程序复杂B问题复杂C控制复杂D数据复杂,这是一道选择题,求助啊
A
软件复杂性是指理解和处理软件的难易程度,包括程序复杂性和文档复杂性,软件复杂性主要体现在程序的复杂性中。
参考资料:《软件工程》(齐治昌主审,钱乐秋等编著)
软件的复杂性表现在哪些方方面啊
规模:即总共的指令数,或源程序行数。
难度:通常由程序中出现的操作数的数目所决定的量来表示。
结构:通常用于程序结构有关的度量来表示。
智能度:即算法的难易程度。
软件复杂性有哪几类?软件复杂性度量模型应遵循哪些基本原则
软件复杂性有哪几类?软件复杂性度量模型应遵循哪些基本原则?
解答: K.Magel从六个方面描述软件复杂性: ① 理解程序的难度;
② 改错及维护程序的难度; ③ 向他人解释程序的难度; ④ 按指定方法修改程序的难度; ⑤ 根据设计文档编写程序的工作量; ⑥ 执行程序时需要资源的程度。
软件复杂性度量模型应遵循的基本原则:
⑴ 软件复杂性与程序大小的关系不是线性的; ⑵ 控制结构复杂的程序较复杂; ⑶ 数据结构复杂的程序较复杂; ⑷ 转向语句使用不当的程序较复杂;
⑸ 循环结构比选择结构复杂,选择结构又比顺序结构复杂;
⑹ 语句、数据、子程序和模块在程序中的次序对软件复杂性都有影响; ⑺ 全程变量、非局部变量较多时程序较复杂; ⑻ 参数按地址传递比按值传递更复杂; ⑼ 函数副作用比显式参数传递更难以琢磨;
⑽ 具有不同作用的变量共用一个名字时较难理解; ⑾ 模块间或过程间联系密切的程序较复杂; ⑿ 嵌套深度越深程序越复杂。
软件复杂性有哪几类?软件复杂性度量模型应遵循哪些基本原则?
K.Magel从六个方面描述软件复杂性:
① 理解程序的难度;② 改错及维护程序的难度;③ 向他人解释程序的难度;④ 按指定方法修改程序的难度;⑤ 根据设计文档编写程序的工作量;⑥ 执行程序时需要资源的程度。
软件复杂性度量模型应遵循的基本原则:
(1)软件复杂性与程序大小的关系不是线性的;(2)控制结构复杂的程序较复杂;(3)数据结构复杂的程序较复杂;(4)转向语句使用不当的程序较复杂;(5)循环结构比选择结构复杂,选择结构又比顺序结构复杂;(6)语句、数据、子程序和模块在程序中的次序对软件复杂性都有影响;(7)全程变量、非局部变量较多时程序较复杂;(8)参数按地址传递比按值传递更复杂;(9)函数副作用比显式参数传递更难以琢磨;(10)具有不同作用的变量共用一个名字时较难理解;(11)模块间或过程间联系密切的程序较复杂;(12)嵌套深度越深程序越复杂。
最典型的两种程序复杂性度量的方法中,McCabe环路复杂性度量就是针对基本原则(2)制定的度量模型;Halstead度量是针对程序中操作符和操作数的出现频度而制定的度量模型。
对软件测试的复杂性进行归纳分析
软件测试的复杂性与经济性
人们常常以为,开发一个程序是困难的,测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作,稍有不慎就会顾此失彼,发生不应有的疏漏。
不论是黑盒测试方法还是白盒测试方法,由于测试情况数量巨大,都不可能进行彻底的测试。所谓彻底测试,就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试,贯穿程序的独立路径数是天文数字,但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解:“程序测试只能证明错误的存在,但不能证明错误不存在”。
在实际测试中,穷举测试工作量太大,实践上行不通,这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成测试。为了降低测试成本,选择测试用例时应注意遵守“经济性”的原则。第一,要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级;第二,要认真研究测试策略,以便能使用尽可能少的测试用例,发现尽可能多的程序错误。掌握好测试量是至关重要的,一位有经验的软件开发管理人员在谈到软件测试时曾这样说过:“不充分的测试是愚蠢的,而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险,过度测试则会浪费许多宝贵的资源。
测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外,还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下:
①、系统的目的
系统的目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。一台在boeing 757上的系统应该比一个用于公共图书馆中检索资料的系统需要更多的测试。一个用来控制密封燃气管道的系统应该比一个与有毒爆炸物品无关的系统有更高的可信度。一个安全关键软件的开发组比一个游戏软件开发组要有苛刻得多的查找错误方面的要求。
②、潜在的用户数量
一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。一个在全世界范围内有几千个用户的系统肯定比一个只在办公室中运行的有两三个用户的系统需要更多的测试。如果不能使用的话,前一个系统的经济影响肯定比后一个系统大。除此而外,在分配处理错误的时候,所花的代价的差别也很大。如果在内部系统中发现了一个严重的错误,在处理错误的时候的费用就相对少一些,如果要处理一个遍布全世界的错误就需要花费相当大的财力和精力。
③、信息的价值
在考虑测试的必要性时,还需要将系统中所包含的信息的价值考虑在内,一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统,但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑,投入与经济价值相对应的时间和金钱去进行测试。
④、开发机构
一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多,因此,对于不同的开发机构来说,所需要的测试的必要性也就截然的不同。
然而,那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的,在许多情况下,机构的管理部门并不能真正地理解开发一个高质量的系统的好处。
⑤、测试的时机
测试量会随时间的推移发生改变。在一个竟争很激烈的市场里,争取时间可能是制胜的关键,开始可能不会在测试上花多少时间,但几年后如果市场分配格局已经建立起来了,那么产品的质量就变得更重要了,测试量就要加大。测试量应该针对合适的目标进行调整。
参考资料:http://www.jingheng.com/info_3.html
软件工程有那些本质特性
软件工程的本质特性和基本原理
本质特性:
1,软件工程关注于大型程序的构造;
2,软件工程的中心课题是控制复杂性;
——许多软件的复杂性主要不是由问题的内在复杂性造成的,而是由必须处理的大量细节造成的。
3,软件经常化;
4,开发软件的效率非常重要;
5,和谐地合作是开发软件的关键;
6,软件必须有效地支持它的用户;
7,在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品。
基本原理:
1,用分阶段的生命周期计划严格管理;
2,坚持进行阶段评审;
3,实行严格的产品控制;
4,采用现代程序设计的技术;
5,结果应能清楚地审查;
6,开发小组的人员应该少而精;
——人数为N时,可能的通信路径有N(N-1)/2条。
7,承认不断改进软件工程实践的必要性。
为什么说软件开发过程是一个复杂过程
软件开发过程一般分成三类:主要过程类、支持过程类和组织过程类:
1、主要过程类
供各主要当事方(如需方、供方、开发者、运行者和维护者)在参与或完成软件产品开发、运行或维护时使用。
2.支持过程类
支持过程类中的过程对基本过程类中的过程提供支持。被支持的过程根据需要采用一些支持性过程,并与开过程结合,帮助软件项目获得成功记良好的产品指令。
3.组织过程类
此类过程用来建立和实施一种基础结构,并且不断改进该基础结构的过程。基础结构由一些相关的过程和人员组成。
软件开发把软件过程放在中心地位来看待,关注的核心是开发过程,并涉及相关的其他过程。
转载请注明出处51数据库 » 什么是软件复杂性 什么是软件的复杂性
亖呉?盀