{管理信息化信息化知识}软件工程1)

《{管理信息化信息化知识}软件工程1)》由会员分享，可在线阅读，更多相关《{管理信息化信息化知识}软件工程1)（76页珍藏版）》请在金锄头文库上搜索。

1、软 件 工 程Software Engineering,主讲：wangzhen E-mail : 电话： 86798113,1,软件工程 软件业是决定21世纪国际竞争地位的战略性产业，是信息时代的朝阳产业。 1.软件产业是信息产业的核心，是国际竞争的焦点和战略制高点。 2. 软件关系到国家政治、经济和社会的安全及民族文化的发扬光大。 3. 发展软件产业对优化我国产业结构、提高经济运行质量具有极其重要的作用。 4.软件是国民经济建设中诸多关键技术的基础。,2,软件工程 近二十年来计算机软件已经成为现代科学研究和解决工程问题的基础，以及管理部门、生产部门、服务行业中的关键因素，渗透到了各个领域，成

2、为当今世界不可缺少的一部分。 展望二十一世纪，软件仍将成为驱动任何事情, 从基础教育到遗传工程取得新进展的动力。 学习研究工程化的软件开发方法，使开发过程更加规范，是我们学习的目标和动力。,3,软 件 工 程,软件工程导论（第四版） 张海藩 清华大学出版社（2003）,教 材,4,软 件 工 程, 实用软件工程 （第二版） 郑人杰 殷人昆 陶永雷 清华大学出版社（1996）, 软件工程 -实践者的研究方法（英译版 第五版） Roger S. Pressman 机械工业出版社,参考书目,5,软 件 工 程,课程评分方法 大作业 30% + 期末考试 70% = 总评 100% 其它作业仅供参考。

3、可通过e-mail递交 考勤仅供参考，若抽查3次缺勤，总成绩不及格,6,学生管理系统StudentMis,学生管理系统针对的用户是学校学生管理部门。相应的需求有： 能够存储一定数量的学生信息,并方便有效的进行相应的学生数据操作和管理，主要包括：,大作业,7,学籍管理 学生基本信息的导入、录入、删除及修改。 学生辅助信息(综合测评、奖励、处分等)的录入、删除及修改。 学生贷款管理（录入、删除及修改。查询） 学生保险管理（录入、删除及修改。查询） 学生就业管理（录入、删除及修改。查询） 学生勤工助学管理（录入、删除及修改。查询） 学生各种信息的多关键字检索查询。,8,能够对需要的统计结果提供打印输

4、出。 能够提供一定的安全机制，提供数据信息授权访问，防止随意删改，同时提供信息备份的服务。,可选题目： - 商业管理系统的分析、设计与实现 - 教务管理系统的分析、设计与实现 - 订票管理系统的分析、设计与实现 可以自选题目,但需要教师认可,9,应提交的文档,软件需求规格说明书 软件设计规格说明书 用户安装及使用手册 系统测试计划 演示程序 其它,10,软 件 工 程,目的 体验软件工程各阶段的主要工作，特别注意吸取教训； 学会与他人合作，培养团队精神，单干户将得不到成绩。,分组：班长组织 每组6-8人，选一个组长。 组长负责：组织、分工、安排进度、作业提交等。 作业提交: 每组一个, 但必须

5、注明分工.,11,0. 软件概论 什么是软件 软件的分类 软件的发展 1. 软件危机 软件危机的表现 软件危机的原因 2. 软件工程 软件工程 软件工程的目的和要求,第一章 软件工程学概述,12,软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合 程序是按事先设计的功能和性能要求执行的指令序列 数据是使程序能正常操纵信息的数据结构 文档是与程序开发，维护和使用有关的图文材料,0. 软件概论,13,软件的特点,软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性 软件的生产与硬件不同，在它的开发过程中没有明显的制造过程 在软件的运行和使用期间，没有硬件那样

6、的机械磨损，老化问题,0.软件概论,14,0.软件概论,15,软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性 软件的开发至今尚未完全摆脱手工艺的开发方式 软件本身是复杂的 实际问题的复杂性 程序逻辑结构的复杂性 软件成本相当昂贵 相当多的软件工作涉及到社会因素,0.软件概论,16,0.软件概论,17,软件的分类,按软件的功能进行划分： 系统软件 使计算机系统各个部件、相关软件和数据协调、高效地工作的软件,0.软件概论,操作系统 数据库管理系统 设备驱动程序 通信处理程序等,18,支撑软件 协助用户开发软件的工具软件,0.软件概论,文本编辑程序 文件格式化程序 磁盘向磁

7、带进行数据传输的程序 程序库系统 支持需求分析、设计、实现、测试和支持管理的软件,19,应用软件,0.软件概论,商业数据处理软件 工程与科学计算软件 计算机辅助设计制造软件 系统仿真软件 智能产品嵌入软件 医疗、制药软件 事务管理、办公自动化软件 计算机辅助教学软件,20,按软件规模进行划分： 类别 参加人员数 研制期限 源程序行数 微型 1 14周 0.5k,0.软件概论,小型 1 16月 1k2k 数值计算或数据处理. 通常没有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。,中型 25 12年 5k50k 应用程序和系统程序。软件人员之

8、间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。系统的软件工程方法是完全必要的。,21,大型 520 23年 50k100k 编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。,0.软件概论,甚大型 1001000 45年 1M(=1024k) 若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发

9、工作是不可想象的。,极大型 20005000 510年 1M10M 军事指挥、弹道导弹防御系统。 只是对软件工程技术依赖的程度不同而已。,22,1.软件危机 （Software Crisis),在60年代中期以前: 个体化软件开发方法. 用户 程序员（编写者=使用者），无文档资料,在60年代中期-70年代中期: 软件作坊，产品软件. 个体化软件开发方法.,软件危机： 在计算机软件开发、维护过程中所遇到的一系列严重问题。,23,1.软件危机,例: 美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近10

10、0万行源程序。.据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。.,在程序运行时发现的错误，必须设法改正,用户有新的需求，必须相应地修改程序,硬件或OS的更新，通常需要相应地修改程序,24,1.软件危机,这个项目的负责人F. D. Brooks事后总结了他在组织开发过程中的沉痛教训时说：“.正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。.程序设计工作正像这样一个泥潭，.一批批程序员被迫在泥潭中拼命挣扎，.谁也没有料到问题竟会陷入这样的困境.”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。,

11、Software Crisis !,25,1.软件危机, 项目没有被很好地理解；计划不周，最终导致进度拖延、成本超支。,软件危机的表现：,计划很难制定致使经费预算常常突破：由于缺乏软件开发的经验 ，主观盲目地制定计划，执行起来和实际情况有很大差距；对于工作量估计不准确，进度计划无法遵循，开发工作完成的期限一拖再拖。已经拖延了的项目，为了加快进度而增加人力，反而更加延误了时间。,项目没有被很好地理解：“闭门造车”。需求在开发的初期阶段提得不够明确, 或是未能得到确切的表达。软件人员和用户又未能及时交换意见，使得一些问题不能及时解决，造成开发后期矛盾的集中暴露。然而这时问题既难于分析，也难于挽回。

12、,26,1.软件危机, 没有充分的文档资料(documentation),“软件” 程序，人与人的交流比写程序困难得多。, 软件可靠性(reliability)缺少度量的标准，质量无法保证。 如何保证软件产品的质量，是非常复杂困难的问题。特别对于规模庞大的软件，如：航天.,27,1.软件危机, 软件难以维护(maintainability) 不易升级(evolvability),开发过程没有统一的、公认的方法论和规范指导，加之不重视文字资料工作，资料很不完整；忽视每个人与其他人的接口部分，发现了问题修修补补，这样的软件很难维护。,(5) 未能充分做好检测工作(test) 在运行中暴露出大量的问

13、题，轻者影响系统的正常工作，重者发生事故，甚至造成生命财产的重大损失。,28,软件危机产生的原因：,软件自身的特点 (2) 在开发和维护过程中，采用了错误的方法和技术 早期的个体化开发特点 急于求成，仓促上阵 我们认为的问题=用户要解决的问题？ 认为软件=编程、运行；轻视软件维护 编程工作量10-20% 软件维护工作量55-70% 没有软件生命周期概念,1.软件危机,29,软件开发过程中，引入同一变动付出的代价随时间变化趋势,1.软件危机,30,改正一个问题需付出的代价,需 求 分 析,结构设计,详细设计,编码,集成测试,系统测试,现场,改正一个问题的估计费用,改正一个问题估计的工作量,20,

14、200,2000,1000,5.0,2.5,0.05,0.5,(美元),(人天),31,对软件的常见误解,用户的误解 开发人员的误解 管理者的误解,1.软件危机,32,误解 先对软件需求做一般的说明，以后再逐步明确就可以了. 需求本身就是不断变化的，软件容易改变可以很快调整适应这种变化.,现实 软件需求不明确是造成软件开发费用增加和延时交货的主要原因. 软件开发费用随着开发阶段的后移而大大增加.,1x,1.5-6x,60-100 x,软件开发 费用,设计阶段,开发阶段,维护阶段,用户的误解,1.软件危机,33,开发人员的误解,误解 一旦程序开发完毕工作正常，我的任务就完成了 在程序工作之前，无

15、法顾及软件的质量问题. 对于一个成功的项目来说，唯一能够提供的就是可以工作的程序.,现实 一个软件的50%-70% 的工作量耗在软件交付使用以后. 对于某些错误软件审查比软件测试更加有效. 一个完整的软件要包括程序、各种文件和各种数据.,1.软件危机,34,管理者的误解,误解 书上已经有各种软件开发的标准，拿来用就是了. 已经有足够的软件开发工具可供使用. 一旦项目的程序员不够可以随时增加.,现实 书上是有各种软件开发的标准，但不是过时就是不适用. 软件工具不是一拿来就能用的. “项目后期增加程序员会使项目的完成更加推后. - Brooks,1.软件危机,35,按工程化的原则和方法组织软件开发

16、是软件开发的一个主要出路。 50年代到60年代时，程序设计曾经被看做是一种任人发挥创造才能的技术领域。写出的程序通篇充满了程序技巧，这些程序很难被别人看懂。然而随着计算机的广泛使用，人们逐渐抛弃了这种观点。对于稍大的、并需要较长时间为许多人使用的程序，人们要求这些程序容易看懂、容易使用，并且容易修改和扩充。多个软件人员分工合作、共同完成；只有在项目的总体要求和技术规范的约束下充分发挥和施展。,解决问题的出路,1.软件危机,36,1.软件危机, Better management Different team organizations Better languages 每个阶段结束前完成文档审查, 及早改正错误。,特 点,61,2. 原型模型（快速成型模型）,建造/修改 原型,用户测试 运行原型,听取用 户意见,原型范型,2.软件工程,62,采用原型模型的