[精选]软件的发展

《[精选]软件的发展》由会员分享，可在线阅读，更多相关《[精选]软件的发展（38页珍藏版）》请在金锄头文库上搜索。

1、Software Modeling and AnalysisChapter 2: Requirements Engineering-An Introduction,Er-Yu Ding 2007-11 Software Institute of NJU,软件的发展,Software Crisis,When software grows from machine-centric to application centric, software crisis happened 1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(software cris

2、is)这个名词。 软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题 开发成本超出预算，实际进度比预定计划一再拖延。 用户对“已完成”系统不满意的现象经常发生。 件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。 件的可维护程度非常之低。 软件通常没有适当的文档资料。 软件的成本不断提高。 软件开发生产率的提高赶不上硬件的发展和人们需求的增长,Software Engineering,概括来说，软件危机包含两方面问题：一、如何开发软件，以满足不断增长，日趋复杂的需求；二、如何维护数量不断膨胀的软件产品。 Software Engineering is proposed

3、 to deal with Software Crisis IEEE definition (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) the study of approaches as in (1).,软件的发展,Standish Group 1995,365家

4、公司的8380个项目,Software Problems,大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元 大约31的项目在完成之前被取消，52.7的项目成本是原来预算的189% 大公司9%按预算交付，小公司16%按预算交付,-Standish Group,1995,Standish Group 1995,Standish Group 1995,Standish Group 1995,Standish Group 1995,需求因素 用户参与（用户输入） 高层管理支持 清晰的需求说明 切合实际的期望 清晰的目标和前景 需求变化 额外的无用功能 综

5、合来看，需求因素 对成功项目的影响指数为53.9 对问题项目的影响指数为55.6 对失败项目的影响指数为60.9,ESPITI，1996,欧洲软件协会ESI 欧洲软件过程改进培训计划项目ESPITI 17个国家的超过3800个组织,Concrete examples of failed projects,PROMS（演出权益协会）,11M,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周 RISP（西萨克斯地区信息系统计划）, 43M ,1990,缺少清晰的项目范围定义 TAURUS(伦敦股票交易), 75M(1.4B), 1993,未能协调不一致的需求 LASDS(

6、伦敦救护车服务派遣系统), 1992,社会服务领域糟糕的需求分析 ATC(空中交通控制系统), 1.8B,1998-2001,缺乏健壮的需求规格说明,People think requirements is main troubles,“There is little doubt that project requirements are the single biggest cause of trouble on the software project front. Study after study has found that, where there is a failure, re

7、quirements problems are usually at the heart of the matter.” GLAS98 as much as 90% of subsequent troubles can be traced back to erroneous original specifications. BRUC89,需求原因探究软件模拟性,需求原因探究软件模拟性,需求原因探究软件模拟性,对应用型软件的“模拟”特性理解不透彻或应用不坚决的问题 Capers JonesCapers1996在调查了几百个公司之后发现超过75的企业在需求处理环节存在不足。 2000年Nikula

8、等人在对芬兰的中小型公司进行需求处理实践情况评价时发现Nikula2000：在以30分为标准线的情况下，75%的公司竟然在10分以下。 Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程Hofmann2001。 在进行需求分析时，人们对软件本身特性投入很大精力的同时，对本也应投入很大精力的问题背景和应用环境却常常关注不足。 Juristo 等人在对欧洲的150多名RE实践者进行调查后发现，在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用Juristo 2002。 研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为

9、严重Lubars1993，Francisco2003,需求原因探究技术因素,非技术性和社会性因素 组织机构文化、社会背景、商业目标、利益协商 关注软件系统和现实之间的互动效应 软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视 解决方案和具体应用环境相关的 不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等 单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的 面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商,需求原因探究技术因素,结构化分析和面向对象分析具有一定的先

10、天缺陷 编程 设计分析 设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功 但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实,面向对象分析的问题,对象的概念不同,面向对象分析的问题,对象的选择和运用不同 设计的首要目的是构造高质量的软件 需求分析的首要目的是理解现实，其次才是建立一个完整、一致的软件规格说明 描述的角度不同 设计描述的目的是说明“软件按照正确的方式工作”，即要求说明软件“做什么”（What）和“怎么做”（How） 分析描述的目的是说

11、明“软件做了正确的工作”，侧重于说明软件“做什么”（What）和“为什么做”（Why,面向对象分析的问题,描述的内容不同,需求原因探究技术因素,以“企业”为中心的软件反映了软件规模日益扩大 一方面提高了需求处理中非技术性和社会性因素的影响比重 另一方面也进一步放大了传统技术在需求处理阶段的不适应性,需求原因探究技术因素,需求错误的修复代价对比,So, RE is needed and is very important,the most crucial activity INCE89 The most important phase by far BRUC89 the most critica

12、l and problem-prone area HOOP82 RE is at the start; - it forms the foundations,需求工程,是软件工程的一个分支 它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束 同时它也关注以上因素和准确的软件行为规格说明之间的联系 关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系,需求工程,基本活动,需求工程与系统工程,需求工程与系统工程,1981年，Barry Boehm Boehm1981发现项目费用的6和时间的9-12被消耗在需求阶段。 在20年之后，随着需求工程的发展，Hofm

13、ann2001发现项目对需求工程的投入也加大了许多：项目工作的15.7和时间的38.6被用于进行需求工程 NASA (U.S. National Aeronautics and Space Administration )提供的数据显示 Young2002：当在需求工程当中投入项目总成本的8-14时，可以极大的降低项目的超支率。,需求工程的必要性,软件开发是这样一个工程问题 利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的 计算机应用于现实世界的广泛性 新的问题和新的解决方案 定义问题就是需求工程的任务,需求工程的重要性,Frederick BrooksBrooks1987

14、“开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。”,容易忽略需求工程重要性的地方,问题广为人知 电梯调度、图书管理 问题小而简单 出错也无所谓,需求工程的复杂性,处理范围广泛 现实世界和计算机世界 涉及诸多参与方 客户、用户、领域专家、需求工程师、软件开发者、系统维护者等 处理内容多样 功能需求、非功能需求 、环境及其约束 处理活动互相交织 需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往

15、是迭代和互相交织的 处理结果要求苛刻 正确性、完整性和一致性,需求工程师需要具备的知识,软件技术（尤其是软件建模与分析技术） 认知学和社会学等方面的知识 认知心理学 人类学 社会学 语言学 哲学知识 掌握涉众的信仰与理念（认识论） 分析在现实中观察到的各种现象（现象学）,需求工程师需要具备的技能,专业技能 需求工程的相关知识 分析技能 抽象能力 整合能力 系统化思想 交流技能 交谈和提问的技巧 倾听的技巧,需求工程师需要具备的技能,观察技能 建模技能 写作技能 文档组织能力 语言驾驭能力 创新技能 发现连用户都没有意识到的潜在需求 协调能力,Conclusions,需求问题 需求问题原因分析

16、需求工程 需求工程与系统工程 需求工程的特性 必要性 重要性 复杂性 需求工程师需要具备的知识和能力,9、静夜四无邻，荒居旧业贫。21.5.3121.5.31Monday, May 31, 2021 10、雨中黄叶树，灯下白头人。21:18:2721:18:2721:185/31/2021 9:18:27 PM 11、以我独沈久，愧君相见频。21.5.3121:18:2721:18May-2131-May-21 12、故人江海别，几度隔山川。21:18:2721:18:2721:18Monday, May 31, 2021 13、乍见翻疑梦，相悲各问年。21.5.3121.5.3121:18:2721:18:27May 31, 2021 14、他乡生白发，旧国见青山。2021年5月31日星期一下午9时18分27秒21:18:2721.5.31 15、比不了得就不比，得不到的就不要。2021年5月下午9时18分21.5.3121:18May 31, 2021 16、行动出成果，工作出财富。2021年5月31日星期一9时18分27秒21:18:2731 May 2021 17、做前，能够环