软件的需求问题
软件的发展
20世纪50年代,软件以机器为中心,主要内容为指令码、汇编语言、BIOS、批量事务处理、计算性任务等
20世纪60年代,软件以应用为中心,主要内容为3GL、OOL、OS、VirtualMachine、基本业务处理、应用处理等
1968年北大洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”这个名词。软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题:
开发成本超出预期,实际进度比预定计划一再拖延用户对“已完成”系统不满意的现象经常发生软件产品的质量往往靠不住。Bug一大堆,Patch一个接一个软件的可维护程度非常之低软件通常没有适当的文档资料软件的成本不断提高软件开发生产率的提高赶不上硬件的发展和人们需求的增长
概括来说,软件危机包含两方面问题:
如何开发软件,以满足不断增长,日趋复杂的需求如何维护数量不断膨胀的软件产品
解决方案:软件工程
应用系统化的、学科化的、定量的方法,来开发、运行和维护软件,即将工程应用到软件对1中各种方法的研究
20世纪90年代,软件以企业为中心,主要内容为4GL、CBD、Middleware、EAI、BPR、ERP等
从20世纪60年代到今天软件的发展之路可以被总结为如下几个关键点:
个人为主的作坊式英雄主义时代面向复杂问题,实现大型软件可预测和提高软件可靠性的工程化开始阶段初步的基于组件要素工厂化生产阶段基于互联网和大数据技术新型开放软件开发平台
当前软件自主化面临的机遇与问题
当前主要的自主软件发展领域:
云计算大数据区块链人工智能工业互联网
我们最急需发展的领域:
工业软件操作系统
软件生产状况调查
StandishGroup199调查了365家公司的8380个项目
成功项目:在预期的时间之内,在预算的成本之下完成预期的所有功能问题项目:已经完成,软件产品能够正常工作,但在生产中或者超支,或者超期,或者时间的功能不全失败项目:因无法进行而被中途撤销,或者最终产品无法提交使用
调查得出以下结论:
大公司开发项目的平均成本是232万美元,中等公司是131万美元,小型公司是44万美元大约31%的项目在完成之前被取消,57%的项目成本是原来预算的189%大公司9%按预算交付,小公司16%按预算交付
用户参与 | 15.9% |
高层管理支持 | 13.9% |
清晰的需求说明 | 13.0% |
正确的项目计划 | 9.6% |
切合实际的期望 | 8.2% |
细化的项目里程碑 | 7.7% |
员工能力 | 7.2% |
主人翁精神 | 5.3% |
清晰的目标和前景 | 2.9% |
努力工作 | 2.4% |
其他 | 13.9% |
缺少用户输入 | 12.8% |
不完整的需求说明 | 12.3% |
需求变化 | 11.8% |
缺乏高层管理支持 | 7.5% |
技术能力不足 | 7.0% |
缺乏资源 | 6.4% |
不切实际的期望 | 5.9% |
目标不清晰 | 5.3% |
不现实的时间要求 | 4.3% |
新技术的影响 | 3.7% |
其他 | 23.0% |
不完整的需求说明 | 13.1% |
缺少用户输入 | 12.4% |
缺乏资源 | 10.6% |
不切实际的期望 | 9.9% |
缺乏高层管理支持 | 9.3% |
需求变化 | 8.7% |
缺乏计划 | 8.1% |
额外的无用功能 | 7.5% |
缺乏IT管理 | 6.2% |
技术能力不足 | 4.3% |
其他 | 9.9% |
需求因素包括:
用户参与高层管理支持清晰的需求说明切合实际的期望清晰的目标和前景需求变化额外的无用功能
综合来看,需求因素:
对成功项目的影响指数为59%对问题项目的影响指数为56%对失败项目的影响指数为60.9%
ESPITI199
欧洲软件协会ESI欧洲软件过程改进培训计划项目ESPITI17个国家的超过3800个组织
需求问题的典型案例
PROMSRISPTAURUS,199未能协调不一致的需求(不一致需求的管理问题)LASDS,199社会服务领域糟糕的需求分析(需求不清晰)ATC,1998-200缺乏健壮的需求规格说明(需求没有搞清楚就匆忙开始工作)
近期的软件失效案例:
2004年4月,东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消一笔输错指令的交易,导致该公司蒙受了近5亿美元的损失;故障原因之对操作人员的错误行为的预期不充分2008年6月30日,北京奥运门票系统在提交使用的当天即发生瘫痪;原因之一是对系统用户数的预测不足
需求问题的原因分析
应用软件的模拟特性
软件的三种类型:
软件的分析活动:
软件模拟性的实践调查
CapersJones[Capers1996]在调查了几百个公司之后发现超过75%的企业在需求处理环节存在不足。2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现[Nikula2000]:在以30分为标准线的情况下,75%的公司竟然在10分以下。Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程[Hofmann2001]。Juristo等人在对欧洲的150多名RE实践者进行调查后发现,在需求处理的诸多技术当中,需求获取和冲突协商的技术没有得到充分的应用[Juristo2002]。研究也发现当软件生产面临时间、市场等其他压力时,漠视“模拟”特性的情况就更为严重[Lubars199Francisco2003]
需求问题的技术原因分析
需求错误的高代价性:
需求工程
需求工程是软件工程的一个分支
需求工程的基本活动:
需求工程与系统工程:
需求工程特性:
必要性软件开发是这样一个工程问题:利用通用的计算机结构,构建一个有用的软件系统来满足人们的某些目的计算机应用于现实世界的广泛性新的问题和新的解决方案定义问题就是需求工程的任务重要性容易忽略需求工程重要性的地方问题广为人知:电梯调度、书管理问题小而简单,出错也无所谓FrederickBrooks[Brooks1987]:开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其他软件系统的接口。同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对他进行修改也极为困难复杂性处理范围广泛:涉及世界和计算机世界涉及诸多参与方:客户、用户、领域专家、需求工程师、软件开发者、系统维护者等处理内容多样:功能需求、非功能需求、环境及其约束处理活动互相交织:需求开发的各项活动虽然在理论上具有顺序处理的特性,但在实际执行过程中往往是迭代和互相交织的处理结果要求苛刻:正确性、完整性和一致性
需求工程师
知识要求
软件技术:尤其是软件建模与分析技术认知学和社会学等方面的知识认知心理学人类学社会学语言学哲学知识掌握涉众的信仰与理念分析在现实中观察到的各种现象
技能要求
专业技能:需求工程的相关知识分析技能:抽象能力、整合能力、系统化思想交流技能:交谈和提问的技巧、倾听的技巧观察技能建模技能写作技能:文档组织能力、语言驾驭能力创新技能:发现连用户都没有意识到的潜在需求协调能力
小结
从20世纪60年代末期软件工程产生起,需求分析就一直是软件开发的重要主题20世纪90年代的调查状况表明,单纯的需求分析已经不能很好的解决软件生产中的“需求”问题应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程需求工程是软件工程当中一项重要和复杂的活动,需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动
如果有兴趣了解更多相关内容,欢迎来我的个人网站看看:瞳孔的个人空间
文章为作者独立观点,不代表 股票程序化软件自动交易接口观点