软件工程-2_软件工程技术

2、软件工程基本理论

计算机软件已经成为一种驱动力

进行商业活动的引擎;\r现代科学研究和工程问题解决的基础;\r区分现代产品和服务的关键因素;\r现代社会中不可缺少的。\r应用于:\r 交通、医药、通讯、军事、娱乐、\r 办公……

我国软件产业的发展历程

二十世纪七八十年代:第一次浪潮,1982年,诞生了中国第一个软件的专门主管机关:国家科委(现科技部)中国软件技术开发中心。一项庞大的“软件发展计划”也就势出炉。然而,就在印度开始启动的1985年,原本先行一步的中国,随着国家科委领导的更替,一度轰轰烈烈的软件计划却紧急刹车。中国软件发展史上的“第一次浪潮”匆匆结束。

我国软件产业的发展历程

80年代未期,计算机在中国的迅速普及拉动了众多应用软件的兴起,中国软件业进入“第二次浪潮”。WPS、Richwin、 “网络蚂蚁”、 “超级解霸”等,是这个时代的流行话题。在1989年以前,我们出现了一批商业性软件公司,有做字处理工具的、做出口的。当时我们的出口是与印度竞争的,基本不相上下。但是,在90年代这个全球软件开始转向产业化的关键时期,我们没有跟上。而90年代初,在地球的另一面,一群软件“恐龙”已然长成。也是从这个时期开始,微软、CA、SAP、IBM等一批国外软件商陆续进入中国,而且享受着比本土企业更多的优惠政策。

我国软件产业的发展历程

2000年,中国第一个软件优惠政策出台,中国软件的“第三次浪潮”开始。\r2003年以后至今,中国成长了一批有一定实力的软件企业,拥有了部分知识产权的软件产品,但仅限于部分行业应用。

我国软件产业的现状

软件产业\r发展的三个方向

操作系统

应用软件

系统集成

国内目前的状况是应用软件以及系统集成公司比较多,软件产品主要集中在一些管理软件、财务软件等基于数据库应用的软件、教育软件、杀毒软件及一些中文平台的开发上,而在利润丰厚、应用广泛的基础软件如操作系统、数据库管理软件等,基本上无所作为。

软件人才体系的构造

在国内,根据统计,我国大约有五千多家软件企业,而已经有的十六万软件从业人员,远远不能满足中国软件产业发展的需要。专家和权威机构预测,未来五年全国软件开发人才的缺口将达80万。软件人才的缺乏,已经成为制约现阶段我国软件产业发展的主要问题。

我国软件人才的现状\r—缺乏

在软件行业,处在顶层的是少数高级科研开发人员和高层管理人员,中间层是系统分析员等,处在金字塔基层支撑着整座金字塔的是大量的软件开发人员、程序员。基层人才和中高层人才的结构比例大致遵循80/20原则。软件产业和传统产业一样,其发展需要有大量的产业工人即基础软件人才来支撑,大量的软件开发人员、程序员,是软件产业持续发展的基础。

合理地构造人才体系

程序员\r软件开发员

系统分析员

高层\r管理员

国内软件企业的人才结构

目前我国的计算机软件人才培养主要集中在高等院校的计算机专业及电子电信等相关专业学历教育。受过高等教育的大学毕业生进入到企业后是不甘心也不应该只成为写程序的软件开发人员,他们在企业经过一到两年的软件开发实践,就会自觉或者不自觉地向系统分析员、项目经理发展,成为中间层次的人才。\r 在我国的软件企业中,人才主要是集中在这一个层次,因为缺少基础的软件开发人员,还使得中间层次的人才很难再向高层科技开发人才发展。

国内软件企业的人才结构

软件工程师的基本素质和必备知识

具有软件工程的概念;良好的团队作业思想 \r 英语阅读和写作能力; 掌握数据库知识\r 良好的编码能力;强烈的求知欲望和进取心\r 了解和掌握IT行业的发展动态

软件工程师如何进一步提高自己

研究计算机软件体系结构\r 提高多种操作系统下开发的能力\r 提高软件质量控制能力\r 提高综合知识能力

良好的团队作业思想

随着软件项目规模越来越大,仅仅依靠个人力量已经无法完成工作,因此,现代软件企业越来越重视团队精神。一般来讲,软件企业中的程序员可以分为两种,一种是对编程工具很熟,能力很强,把编码编得很简洁高效,但却缺乏规范和合作的观念;另一种编程不一定很快,但是很规范,个人能力不一定很强,但合作意识很好。第二种人更加适合现代软件企业发展的潮流。对于基础软件工程师来说,他们在企业中的角色决定了他们必须具有良好的规范意识和团队精神。

较强的英语阅读和写作能力

程序世界的主导语言是英文,编写程序开发文档和开发工具帮助文件离不开英文,了解业界的最新动向、阅读技术文章离不开英文,就是与世界各地编程高手交流、发布帮助请求同样离不开英文。作为基础软件工程师,具有一定的英语基础对于提升自身的学习和工作能力极有帮助。

掌握数据库知识

信息是以数据为中心的,因此与数据库的交互在所有软件中都是必不可少的,了解数据库操作和编程是软件工程师需要具备的基本素质之一。\r目前常用的网络数据库软件有Oracle、DB2、SYBASE、SQL Server等。

良好的编码能力

基础软件工程师的一个重要职责是把用户的需求功能用某种计算机语言予以实现。编码能力直接决定了项目开发的效率。这就要求软件工程师至少精通一门编程语言,同时良好的编程习惯也是必须的,提高代码效率、提高代码的可维护性都是编程过程中需要注意的。

强烈的求知欲望和进取心

软件业是一个不断变化和不断创新的行业,面对层出不穷的新技术,软件人才的求知欲和进取心就显得尤为重要,它是在这个激烈竞争的行业中立足的基本条件。

了解和掌握IT行业的发展动态

作为一名软件工程师,了解IT行业的发展动态,有助于确定自己继续学习的方向,有利于提高自己的能力;同时通过接受新的软件设计思想和软件开发技术,可以使开发效率更高,同时也保证自己在软件设计领域不致于落伍。

具有软件工程的概念

基础软件工程师处于软件企业人才金字塔的底层,是整个人才结构的基础,虽然他们从事的工作相对于系统分析师和高级程序员要单纯一些,但是他们是整个软件工程中重要的一环,因此,基础软件工程师同样要具有软件工程的概念。从项目需求分析开始到安装调试完毕,基础软件工程师都必须能清楚地理解和把握这些过程,并能胜任各种环节的具体工作,这样的能力正好符合了当前企业对基础软件工程师的全面要求。

研究计算机软件体系结构

软件体系结构表示了一个软件系统的高层结构,主要特点有:\r1)软件系统结构是一个高层次上的抽象,它并不涉及具体的系统结构(比如B/S还是C/S),也不关心具体的实现;\r2)软件体系结构必须支持系统所要求的功能,在设计软件体系结构的时候,必须考虑系统的动态行为;\r3)在设计软件体系结构的时候,必须考虑现有系统的兼容性、安全性和可靠性,同时还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。

提高多种操作系统下开发的能力

UNIX\rWINDOWS\rLINUX

目前,随着软件规模的越来越大,许多应用软件的开发不仅仅局限于一个开发平台,这就要求软件工程师必须具备多平台开发的能力。目前主流的开发平台有:

需要说明的是:随着各大软件、硬件厂商支持LINUX,使得LINUX操作系统在近几年得到了迅速的发展;\r国内许多软件厂商纷纷投入大量人力、财力开发中文LINUX操作系统,并初见成效。

提高软件质量控制能力

学习软件工程思想;\r对已经完成的软件项目进行得失、成败的分析总结;\r学习ISO9000-3或CMM软件质量控制体系知识。

目前我国软件企业存在的最大问题是软件质量控制能力较弱、软件开发进度控制较差。所以如果软件工程师希望自己能够得到提高,就必须提高对软件质量的控制和管理能力。

提高综合知识能力

现在的软件开发不仅需要丰富的软件知识,在某些时候网络知识、硬件知识也是必不可少的;\r综合知识的能力还体现在对行业事务处理(主要指在开发应用软件中)的理解;\r能够接受先进的设计方法;\r如果希望自己能在管理上提高一步,还需要具有一定的管理能力。

软件 — 软件的发展

早期\r面向批处理\r有限的分布\r自定义软件

第二阶段\r多用户\r实时\r数据库\r软件产品

第三阶段\r分布式系统\r嵌入“智能”\r低成本硬件\r消费者的影响

第四阶段\r强大的桌面系统\r面向对象技术\r专家系统\r人工神经网络\r并行计算\r网路计算机\r

1950

1960

1970

1980

1990

2000

应用软件\r体系结构发展

软件 — 定义

软件是\r能够完成预定功能和性能的可执行的指令(计算机程序);\r使得程序能够适当地操作信息的数据结构;\r描述程序的操作和使用的文档。

现在,被普遍接受的软件的定义是:

\r 软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分,它包括程序(program)、相关数据(data)及其说明文档(document)。\r

软件 — 软件特征

软件是由开发或工程化而形成的,而不是传统意义上的制造产生的。\r软件不会“磨损”\r大多数软件是自定的,而不是通过已有的构件组装而来的。

软件 — 软件特征

软件是一种逻辑实体,具有抽象性\r软件没有明显的制造过程\r软件在使用过程中,没有磨损、老化的问题 \r软件对硬件和环境有着不同程度的依赖性 \r软件的开发至今尚未完全摆脱手工作坊式的开发方式,生产效率低 \r软件是复杂的,而且以后会更加复杂 \r软件的成本相当昂贵 \r大多数软件是自定的,而不是通过已有的构件组装而来的\r软件工作牵涉到很多社会因素

硬件的故障率曲线(浴缸曲线)

软件的故障率曲线(理想情况下)

软件的故障率曲线(实际情况下)

软件 — 软件构件

可复用构件的使用使得工程师能够集中精力\r于设计中真正有创造性的部分。\r在硬件中,构件复用是工程化的必然结果。\r在软件中,它还仅仅是在小范围内取得一些应用。

软件 — 软件构件

可复用性(Reusability)是高质量软件构件的一个重要特征,一个软件构件应该被设计和实现为能够在多个不同程序中复用。\r科学计算子程序库\r数据以及应用这些数据的处理过程\r\r

软件 — 软件应用

系统软件\r实时软件\r商业软件\r工程和科学计算软件\r嵌入式软件\r个人计算机软件\r人工智能软件

软件危机和软件工程

软件危机的表现\r 开发成本难以控制,进度不可预计;\r 软件系统的质量和可靠性很差,难以满意;\r 软件文档相当缺乏,软件系统不可维护;\r 软件开发生产率很低,软件产品供不应求。\r 软件产品成本十分昂贵。

磨合调整

磨损用坏

t

失效率

硬、软件产品失效率曲线

流行软件系统工作量分析

例: Windows95有1000万行代码\r Windows2000有5000万行代码\r\rExchange2000和 Windows2000开发人员结构

软件危机

“软件危机” 是1958年在NATO会议上作为一个正式的议题被提出来 \r软件项目不成功的例子比比即是:\r1999 年 10 月,耗资 1.25 亿美元的 NASA 的火星气象卫星失踪,据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中,有些数据使用英制,它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器,那个任务也失败了,原因不明。

软件危机

美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量,最多时有1000人投入开发工作,写出了近100万行源程序。......据统计,这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。......\r 这个项目的负责人F. D. Brooks事后总结了他在组织开发过程中的沉痛教训时说:“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎,越是挣扎,陷得越深,最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭,......一批批程序员被迫在泥潭中拼命挣扎,......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。

软件危机

1999 年 8 月,在一个大型的商业高速数据网络里,软件的缺陷影响了 70000 个商业用户,时间长达八天。在受到影响的客户中,有美国最大的远期交易电子贸易系统,该系统中断服务长达一周 \r1998 年 4 月,美国的一个重要的数据通讯网络出现了长达 24 小时的故障,使大部分美国的信用卡管理系统交易受到影响。受到影响的还一些大银行、零售商、和政府的数据系统。最后查出也是软件故障所致。

软件危机

据报道,1997年8月,美国一家最主要的消费信用卡报告公司的新网站刚开启两天,就因为软件问题而关闭了。这个新站点允许浏览者直接访问,只收取很少的费用就可以查询自己的信用卡使用情况。但是,最初的用户所看到的是别人的账单,而不是他们自己的。发怒的顾客使这件事流传全国。最后问题被归结为:“ … 未曾预料到的大量的客户需求,再加上导致把文件送到错误的计算机的软件毛病。” \r美国航空公司失败的机票预订系统CONFIRM\r美国机动车协会新泽西分部的4GL灾难;\r几乎摧毁了客户关系的NCR库房管理系统\r……

软件危机

一些数据:\r大约70%的软件开发项目超出了估算的时间,大型项目平均超出计划交付时间20%到50%,90%以上的软件项目开发费用超出预算,并且项目越大,超出项目计划的程度越高\r美国政府审计局:只有不到2%的合同定购软件在发布时具有可用性——98%以上的项目都失败了

软件危机

一种看法\r“两难境地(Crunch Mode)”:处于两难境地的项目面临无法达到最初目标的威胁(费用、进度表、功能性等),而项目团队努力想跨越困境。\r“我们正处于两难境地,在半夜之前是不会回家”\r“死亡行军(Death March)”:用来描述其进度表几乎不可能完成的项目。\r“这是一个死亡行军项目,我希望自己不要参与进去”

软件危机

软件危机的另一种看法\r“人类只能够在第二级追求中获得成功,比如说,成为百万富翁或者总理,赢得战争,飞跃同温层或者登陆月球。第一级追求,不可避免地要涉及到努力去理解生命的意义以及努力去转化这种理解,这就不可避免地会导致失败感的产生。拿破仑、邱吉尔、罗斯福式的人物可以感受自己的成功感,但苏格拉底式的人物永远不会有这种感觉。对生命意义的理解永远是遥不可及的事情。”——美国播音员Malcolm Muggeridge

软件危机

软件项目超出费用和进度表目标普遍存在的原因是:目标本身完全是错误的。\r为什么有那么多人喊着软件危机呢?因为有利可图:\r某些经销商叫喊危机是为了卖出他们声称能够提供对策的产品或者服务;某些研究者叫喊危机是为了获得他们声称同样将提供对策的研究项目的经费;某些学术界人士叫喊危机是为了促使人们接受并阅读他们提出对策的专业论文。\r——《software runaways》

软件危机

更准确的说法:慢性痛苦(chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan\r尽管忍受痛苦,但是软件依然在我们这个世界起着越来越重要的作用,但是如果能够医治痛苦,那么软件业将发展得更加健康。\r如何医治这种软件业的慢性痛苦?

产生软件危机的原因(软件开发人员的错误观点)

“有一个对目标的概括描述就足以着手编写程序了,许多细节可以在以后再补充”\r“所谓软件开发就是编写程序并设法使它运行”\r“用户对软件的要求不断变化,然而软件是柔软而灵活的,可以轻易地改动”\r“软件投入生产性运行以后需要的维护工作并不多,而且维护是一件很容易做的简单工作”

软件危机产生的原因

软件本身的特点: \r -- 软件是一种逻辑实体,而不是具体的物理实体,具有高度的抽象性;\r -- 软件是一个逻辑上复杂而规模上庞大的系统,涉及技术、管理等多方面的问题;\r -- 软件的生产方式与硬件明显不同:产品的质量控制在设计和制造阶段的不同;产品的生产方式不同;设计和制造阶段的资金和人力投入、 技术复杂度不同;\r -- 软件的运行和维护阶段,没有传统意义上的机械磨损、老化问题;\r -- 软件与硬件有关,对软件有可移植性的要求;\r -- 软件工作涉及许多社会因素。\r对软件开发与维护存在许多错误认识和做法:忽视软件需求分析的重要性;对软件与程序的概念不清;轻视软件维护。 \r软件开发与维护的方法不正确:对系统需求没有清楚和准确的认识就进入开发阶段,忽视对软件开发过程的管理;……

软件危机 — 介绍

软件危机包含两方面问题:\r如何开发软件,以满足不断增长,日趋复杂的需求;\r如何维护数量不断膨胀的软件产品。\r\rSoftware depression (软件萧条)\rSoftware affliction (软件困扰) \r“慢性的苦恼”

软件危机 — 介绍 (cont.)

软件危机主要有以下表现: \r对软件开发成本和进度的估计常常不准确。开发成本超出预算,实际进度比预定计划一再拖延的现象并不罕见。 \r用户对“已完成”系统不满意的现象经常发生。 \r软件产品的质量往往靠不住。Bug一大堆,Patch一个接一个。 \r软件的可维护程度非常之低。 \r软件通常没有适当的文档资料。 \r软件的成本不断提高。 \r软件开发生产率的提高赶不上硬件的发展和人们需求的增长。

软件危机 — 软件危机的原因

软件危机的原因\r一方面是与软件本身的特点有关\r另一方面是由软件开发和维护的方法不正确有关

软件开发工作量分配比例

40% ~ 50%

10% ~ 20%

引入同一变化付出的代价随时间变化的趋势

早 中 后

变化出现的时期

高\r\r\r中\r\r\r低

代价

引入同一变化付出的代价随时间变化的趋势

费用分配比例

\r

55%~70%

软件危机和软件工程

软件的定义(Boehm):软件是程序以及开发使用和维护程序需要的所有文档。

引入同一变动付出的代价随时间变化的趋势

改正一个问题的估计费用(美元)

改正一个问题的估计工作量(人·天)

20

200

1000

2000

0.05

0.5

2.5

5.0

RA

SD

DD

CD

IT

ST

RT

Bell 实验室统计结果(US)

软件产品需要分阶段的定义、设计和开发,严格的产品质量控制,完整的文档记录。

50

60

70

80

90

硬件

软件

软件危机 — 消除软件危机的途径

对计算机软件有一个正确的认识\r (软件≠程序)\r必须充分认识到软件开发不是某种个体劳动的神秘技巧,而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。\r推广使用在实践中总结出来的开发软件的成功技术和方法。\r开发和使用更好的软件工具。

解决软件危机的途径

\r 软件开发是一种组织严密、管理严格、各类人员协同配合共同完成的工程项目。 \r 研究和推广成功的软件开发技术和方法。\r 开发和使用好的软件工具。 \r 基本概念: \r 软件生命周期:软件所经历的定义、开发、使用和维护直到废弃所经历的时期。\r 程序设计环境:源程序编辑,编译或解释,链接,调试和运行工具的集合。\r 软件工程环境:软件定义,设计和实现,测试和维护等各个阶段所使用的软件工具的集合。

Beyond Time, Cost and Quality

\r\r

时间

Software Engineering \r