软件危机与软件工程培训教程.pptx

《软件危机与软件工程培训教程.pptx》由会员分享，可在线阅读，更多相关《软件危机与软件工程培训教程.pptx（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、张小洪Dr. Zhang，Xiaohong2006, FallSchool of Software Engineering, Chongqing University1n 张小洪 qEmail: qTEL：15923238399（小灵通）q办公地点：重庆大学A区主楼1003室n研究方向：q软件工程、机器视觉与数据挖掘等2n软件工程概述n过程模型n需求分析与分析建模n软件设计原则n软件体系结构设计n软件测试n软件维护n可行性分析n面向对象分析与设计3 软件工程软件工程 -实践者的研究方法实践者的研究方法（英文版（英文版 第五版）第五版） Roger S. Pressman 机械工业出版社机械工业

2、出版社4软件工程导论（第三版） 张海藩 清华大学出版社（1997）56n软件的特点n软件的分类n软件工程产生的背景：软件危机与神话n软件工程的概念n软件工程现状7 计算机软件已经成为一种驱动力。它是进行商业决策的引擎；它是现代科学研究和工程问题寻求解答的基础；它也是鉴别现代产品和服务的关键因素。它被嵌入在各种类型的系统中：交通、医疗、电信、军事、工业生产过程、娱乐、办公、难以穷举。软件在现代社会中确实是必不可少的。而且我们进入21世纪，软件将成为从基础教育到基因工程的所有领域新进展的驱动器。8910111213141516 1 14周 0.5k 1 16月 1k2k 数值计算或数据处理,通常没

3、有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。 25 12年 5k50k 软件人员之间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。应用程序和系统程序。系统的软件工程方法是完全必要的。17 520 23年年 50k100k 编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。实行严

4、格的审查是绝对必要的。 1001000 45年年 1M(=1000k) 若干个子项目，每一个子项目都是一个大型软件。子项目之间具有若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发工作是不可想象的。题没有软件工程方法的支持，它的开发工作是不可想象的。 20005000 510年年 1M10M 军事指挥、弹道导弹防御系

5、统。军事指挥、弹道导弹防御系统。 只是对软件工程技术依赖的程度不同而已。只是对软件工程技术依赖的程度不同而已。1819n 202122Late 1950s:In the early days: “Software” = “Place a sequence of instructions together to get the computer to do something useful”.User ComputerComputer became cheaper and more commonHigh level languages were inventedProgrammerUser Co

6、mputereasier23Early 1960s: Very few large software projects were done by some experts.Middle to late 1960s: Truly large software systems were attempted.After 1968: Software Engineering24n软件在社会上扮演了双重角色q它本身是一种产品n将计算机硬件的计算能力发挥出来n同时，它也是一种传递产品的工具q软件传递了我们这个时代最重要的产品： 信息25n70年代和80年代q“新的工业革命”q“工业社会将转变为信息社会”q

7、（大批量生产带来的产品过剩）n90年代q“知识的民主化将改变旧的权力结构”n21世纪q“无所不在的信息”26 美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。.据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。.这个项目的负责人这个项目的负责人F. D. BrooksF. D. Brooks事后总结了他在组织开发过程中的沉事后总结了他在组织开发过程中的沉痛教训时说：痛教训时说：“.“.正像一只逃亡的野兽落到泥潭中做垂死的挣扎，正像一只逃亡的野

8、兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。.程序设计工程序设计工作正像这样一个泥潭，作正像这样一个泥潭，.一批批程序员被迫在泥潭中拼命挣一批批程序员被迫在泥潭中拼命挣扎，扎，.谁也没有料到问题竟会陷入这样的困境谁也没有料到问题竟会陷入这样的困境.”.”。IBM360IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。操作系统的历史教训成为软件开发项目的典型事例为人们所记取。Software Crisis !27 项目没有被很好地理解；计划不周，最终导致进度拖延。例例 在在20世纪世纪60年代后期，一位热情

9、的年青工程师受命为一个自动年代后期，一位热情的年青工程师受命为一个自动化制造应用项目化制造应用项目“编写编写”计算机程序。选择他的理由非常简单，因为在整计算机程序。选择他的理由非常简单，因为在整个技术小组中他是唯一参加过计算机编程培训的人。这位工程师对汇编个技术小组中他是唯一参加过计算机编程培训的人。这位工程师对汇编语言的语言的IN和和OUT指令以及指令以及Fortran语言有所了解，但是却根本不懂软件语言有所了解，但是却根本不懂软件工程，更不要说项目进度安排和跟踪了。工程，更不要说项目进度安排和跟踪了。他的老板给了他一大堆相关的手册，以及需要做些什么的口头描述。年他的老板给了他一大堆相关的手

10、册，以及需要做些什么的口头描述。年轻人被告知该项目必须在两个月之内完成。轻人被告知该项目必须在两个月之内完成。他阅读了这些手册，想好了解决方法，就开始编写代码。两周后，老板他阅读了这些手册，想好了解决方法，就开始编写代码。两周后，老板将他叫到办公室询问项目进展情况。将他叫到办公室询问项目进展情况。问题出在哪里？问题出在哪里？28“非常好非常好”工程师以年轻人的热情回答道，工程师以年轻人的热情回答道，“这个项目远比我想像这个项目远比我想像的简单。我差不多已经完成了的简单。我差不多已经完成了75%的任务。的任务。老板笑了，说道：老板笑了，说道：“真是太棒了真是太棒了”然后他嘱咐年轻人继续努力工作，

11、然后他嘱咐年轻人继续努力工作，准备好一周后再汇报一次工作进度。准备好一周后再汇报一次工作进度。一周后老板将年轻人叫到办公室，问他说：一周后老板将年轻人叫到办公室，问他说：“现在进度如何？现在进度如何？”“一切顺利一切顺利”年轻人回答说，年轻人回答说，“但是我遇到了一些小麻烦。我会排但是我遇到了一些小麻烦。我会排除这些困难，很快就可以回到正轨上来。除这些困难，很快就可以回到正轨上来。”“你觉得在最后期限之前能否完成？你觉得在最后期限之前能否完成？”老板问道。老板问道。“没有问题没有问题”工程师答道。工程师答道。“我差不多已经完成了我差不多已经完成了90%”如果读者在软件领域中工作过几年，你一定可

12、以将这个故事写完。如果读者在软件领域中工作过几年，你一定可以将这个故事写完。毫不奇怪，年轻工程师在整个项目工期内始终停留在毫不奇怪，年轻工程师在整个项目工期内始终停留在90%的进度上，的进度上，（在别人的帮助下）直到交付期限之后一个月才做完（在别人的帮助下）直到交付期限之后一个月才做完29 没有充分的文档资料没有充分的文档资料(documentation) 人与人的人与人的交流交流比写程序困难得多。比写程序困难得多。Managers evaluate, track progress, .Programmers communicate to each otherMaintainers 30 软件

13、可靠性软件可靠性(reliability)缺少度量的标准，质量无法保证。缺少度量的标准，质量无法保证。 如何保证软件产品的质量，是非常复杂困难的问题。如何保证软件产品的质量，是非常复杂困难的问题。特别对于规模庞大的软件，如：特别对于规模庞大的软件，如：.The software supporting the American space shuttle consists of 3 million lines of code, including computers on the ground controlling the launch and the flight; there were o

14、ne hundred thousand lines of code in the shuttle itself in 1985.President Reagans proposed Strategic Defense Initiative (SDI) is estimated to require 10 to 100 million lines of code. Many computer scientists and software engineers continue to believe there is no way to write and test the software to

15、 guarantee adequate reliability.31 软件难以维护软件难以维护(maintainability) 不易升级不易升级(evolvability)32n负责软件的管理者像大多数其他行业的管理者一样，都有巨大的压力，要维持预算、保持进度，还要提高质量。就像溺水者抓住一根救命稻草，软件管理者常常抓住软件神话不放，这些神话能够缓解其压力的话（哪怕是暂时的）。n神话1：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有它们需要知道的信息吗？n现实：不错，关于标准的书籍已经存在，但真正使用它们了吗？软件实践者知道它们的存在吗？它们是否反映了现代软件工程实践

16、？它们完备吗？它们对在保持关注质量的情况下改善交付时间是简便有效的吗？很多情况下，这些问题的答案是否定的。33n神话2：我们已经有了很多很好的软件开发工具，而且，我们为它们最新的的计算机。n现实：计算机辅助软件工程（CASE）工具与硬件相对而言对于获得高质量和高生产率更为重要。n神话3：如果我们已经落后于计划，可以增加更多的程序员赶上进度。n现实：给一个已经延迟的软件项目增加人手只会使其更加延迟。n神话4：如果我决定向第三方外包软件项目，我可以放松并让承包公司去建造它。n现实：如果一个机构不了解如何在内部管理和控制软件项目，当它外包软件项目时将总是处于挣扎的境地。34n在许多情况下，客户相信关

17、于软件的神话，因为负责软件开发的管理者和开发人员很少去纠正客户的错误理解。导致客户过高的期望值，并最终引起对开发人员的不满意。n神话1：有了对目标的一般性描述就足以开始写程序了，我们可以以后再补充细节。n现实：糟糕的系统定义是软件项目失败的主要原因。关于信息领域、功能、行为、性能、接口、设计约束及确认标准的形式化的、详细的描述是必要的。这些内容只有通过客户和开发者之间彻底地交流后才能确定。n神话2：软件需求确实是经常变更的，但这些变更能够很容易地满足，因为软件是灵活的。n现实：软件需求确实是变更的，但这些变更产生的影响会随着其被引入的时间而不同的。35n在软件的早期阶段，程序设计被看成是一门艺

18、术。n神话1：一旦我们写出了程序并使其正常运行，我们的工作就结束了。n现实：越早开始写代码，就要花越长的时间才能完成它。研究表明在一鼐软件上所投入的60%到80%的工作量是花费在软件第一次交付客户之后。n神话2：在程序真正运行之前，没有办法评估其质量。n现实：从项目一开始就可以应用的最有效的软件质量保证机制之一是正式的技术评审。n神话3：一个成功项目唯一应该提交的就是运行程序。n现实：运行程序仅是软件配置的一部分，软件配置包括很多东西。n神话4：软件工程将使我们创建大量的、不必要的文档，并总是延缓我们的进度。n现实：软件工程并不是为创建文档，而了创建质量。36n人们对软件生产提出了许多疑问：q

19、为什么需要那么长的时间才能完成软件开发。q为什么开发成本如此高q为什么我们不能在把软件提交客户之前就发现所有的错误q为什么在软件开发过程总是难以度量其进展n造成以上问题的原因主要是：q软件行业发展的速度太快，对经验总结不足q人们对自身处理能力的认识不清n解决的方法：q多实践，积累成功和失败的案例q总结、思考、提取经验q建立软件的模型和模式37 Better management Different team organizations(组织组织) Better languages & tools Uniform coding conventions (规范规范) 必须意识到：必须意识到：“软件

20、软件” 编程，它有自己的编程，它有自己的生命周期生命周期 (life cycle)。大型软件系统的开发与其它工程项目如建。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。造桥梁、制造飞机、轮船等的开发是同理的。“软件工程软件工程”(Software Engineering)NATO(北大西洋公约组织北大西洋公约组织) Conference , Garmisch , Germany , 1968.解决问题的想法：解决问题的想法：383940 用分阶段的生命周期计划严格管理 项目概要计划项目概要计划 里程碑计划里程碑计划 项目控制计划项目控制计划 产品控制产品控制计划计

21、划 验证计划验证计划 运行维护计划运行维护计划 坚持进行阶段评审 实行严格的产品控制基准配置管理(Baseline configuration management) 开发小组的成员应该少而精开发小组的成员应该少而精1+1 2 采用现代程序设计技术采用现代程序设计技术 结果应能清楚地审查结果应能清楚地审查 set standards 承认不断改进软件工程实践的必要性承认不断改进软件工程实践的必要性41n我国软件业的规模q目前，我国从事软件开发、研制、销售、维护和服务的软件企业有2000家左右，加上兼营的企业，总数大约有10000多家，其中具有自主软件研发能力的软件企业约5700家，已经通过双软

22、认定的有2300余家，从事软件销售、维护和服务的企业5000多家。在这里面，营业规模超过一亿元的软件企业达到100家以上，超过5亿元的达到18家，超过10亿元的达到12家。42n2001年，世界软件产品市场销售额超过1865亿美元，我国当年的销售额为285亿元人民币，只占世界市场不到2的份额。 n国内软件市场有限的份额中大部分为国外软件厂商所瓜分，国内所开发的软件产品仅占小部分。 43n2001年我国软件销售总额963亿美元，软件企业约5000家，从业人员29万。n2001年印度软件销售总额1023亿美元，软件企业约6000家，从业人员40万。 n2001年我国软件的出口额仅为7.2亿美元，2

23、000年与1999年分别为4亿美元及2.5亿美元。 n印度在软件出口方面，则一直保持高速的增长。1990年印度软件出口只有5000万美元，1999年就达到了39亿美元，2000年达到了62亿美元，而2001年印度软件出口额为778亿美元，已经占到了印度全部出口总额的10.5。44n我国软件业发展不理想的原因除了政策和盗版外，最大的问题是我国绝大多数软件企业对其软件开发工作过程缺乏有效的管理和控制。多数软件企业开发和生产基本上处于“技术少标准、开发缺规范、生产无检验、质量无保证”的状态。在这方面印度软件业的发展能够给我们以启发。45n印度软件业能够这么迅速地发展起来，除了有政府支持、英语程度、人

24、才储备等原因外，最重要的是从标准化与产品流程入手，重视管理。n印度的软件开发管理的特点是流程重于项目，流程管理人员独立于研发部门，专门检查研发部门的开发流程是不是按照既定流程走，如果流程不对，项目肯定就此停止。另外，所谓的项目经理一般都是从编码人员升上来的，至少有四年以上的经验，而公司所有的东西（包括草稿）都有文档，其详细文档要求达到只有这个文档就可以编码的程度。 46n于是，印度软件公司开发出来的软件整个体系架构非常清晰，而且相当稳定。 由于印度企业不是靠一两个软件英雄搞研发，而是靠一大批软件技术人员的分工协作，所以，他们必须注重标准化，注重开发的流程管理，以与国际接口。 47n目前印度软件公司中有170家公司获得ISO9000质量标准认证，是世界上获得质量认证软件企业最多的国家。在得到卡内基梅隆大学软件工程学会最高级别的全球23家计算机软件公司中，有15家是印度公司。48n信息主管n未来的高级软件人才n高级软件工程师 （Sr. Software Engineer）n开发团队技术负责人 (Team Leader)n系统工程师 （System Engineer）n项目经理 (Project Manager)n软件开发机构技术主官 （CTO）n 49n软件的特点n软件工程产生的背景及其本质含义50