软件工程课件之第1章-软件工程学概述(第6版)(张海潘编著)

为什么要学习这门课程正确理解和认识“软件”的概念及其特点软件是PC的灵魂掌握软件工程的原则、方法和思想来系统地开发软件，尤其是复杂、庞大软件的开发从程序员到软件工程师了解和接触各种软件开发技术和工具软件工程是软件技术和管理人员必备的课程软件开发与人才需求现有模式小作坊的、一人身兼多职英雄式的软件开发生产模式大规模的软件生产，专业化分工越来越细，团队合作开发对人才的要求除精通开发技术外更需要软件工程意识和团队合作精神教程软件工程导论（第6版）张海藩等编著清华大学出版社教学内容软件工程概述（第1章）可行性研究（第2章）需求分析（第3章）系统设计（第5章）详细设计（第6章）系统实现（第7章）系统维护（第8章）教学内容面向对象方法学引论（第9章）面向对象分析（第10章）面向对象设计（第11章）面向对象实现（第12章）软件项目管理（第13章）资源/UML软件工程组织/希赛/中国最大的开发者技术社区——《程序员》刊物官方网站/赛迪教育——信息产业部电子教育与考试中心唯一指定软考远程辅导平台/软件测试网软件工程概述内容软件的定义和特点软件危机概况、原因和消除途径软件工程介绍概况、基本原理、软件工程方法学软件生命周期软件过程瀑布模型、快速原型模型、增量模型、螺旋模型等软件软件=程序?

《IEEEStandardGlossaryofSoftwareEngineeringTerminology》计算机程序、规程以及运行计算机系统可能需要的相关文档和数据。程序：在运行时，能提供所希望的功能和性能的指令序列。数据：使程序能够正确运行的数据结构文档：描述程序研发过程、方法及使用的文档软件中的文档促进对软件的开发,管理和维护；便于各种人员(用户,开发人员)的交流软件本质特性复杂性软件在规模上可能比任何由人类创造的其他实体都要复杂，复杂性是软件的本质特征软件的复杂形是必要属性大量的组合状态丰富的结构和相互依赖性良好的接口用以封装内部的复杂性开发问题也会增加复杂性高效率的代码通常是复杂的重用通用化的组件意味着复杂的状态连接复杂的代码难以维护，导致设计上的更复杂软件本质特性复杂性Windows95有1000万行代码Windows2000有5000万行代码Exchange2000和Windows2000开发人员结构软件本质特性一致性软件必须遵从人为的惯例并适应已有的技术和系统软件必须遵循各种接口、协议和标准有些情况下，兼容性是软件开发的目标软件需要随接口的不同而改变，随时间的推移而变化，而这些变化是不同的人设计的结果。许多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。软件本质特性可变性软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等，后者持续不断地变化着，这些变化无情地强迫着软件随之变化。所有成功的软件都会发生变更！当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件；功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。软件本质特性可变性软件退化软件本质特性不可见性软件是不可见的和无法可视化的软件的客观存在不具有空间的形体特征定义“需要做什么”成为软件开发的根本问题人们一直试图使用不同的技术进行软件可视化控制流程、数据流、依赖关系、UML、……这些技术仍然无法给出准确的、完整的描述软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。软件分类按工作方式划分实时处理软件分时软件交互式软件批处理软件软件分类按功能划分系统软件与计算机硬件紧密配合在一起，使计算机系统各个部件、相关的软件和数据协调、高效地工作的软件支撑软件能协助用户开发软件的工具性软件，其中包括帮助程序人员开发软件产品的工具，也包括帮助管理人员控制开发的进程的工具应用软件：在特定领域内开发，为特定目的服务的一类软件软件分类按规模（人力、时间、源程序行数）划分软件分类按用途通用软件面向市场公开销售的独立运行系统。例如：操作系统、数据库管理系统、字处理软件等。定制软件由客户委托，在合同约束下开发的软件例如：网上书店、图书管理系统、空中交通管理系统等。软件的发展计算机软件发展的三个时期程序设计阶段（60年代中期之前）硬件通用，软件专用；程序规模小，编写者和使用者为同一人（同组人）。程序系统阶段（60年代中期-70年代中期）出现“软件作坊”、产品软件；“个体化”开发方法。软件工程阶段（70年代中期之后）软件开发成为一门新兴的工程学科——软件工程。软件的发展各阶段特点软件危机概念软件危机指的使软件开发和维护过程中遇到的一系列严重问题，包含两方面的问题：如何开发软件，怎样满足对软件的日益增长的需求如何维护数量不断膨胀的已有软件软件危机软件危机的主要表现对软件开发成本和进度的估计不准确产品不符合用户的要求软件质量不高、可靠性差软件常常不可维护、错误难以改正缺乏适当的文档资料软件成本占系统总成本的比例逐年上升软件开发速度跟不上计算机发展速度软件危机软件危机-开发成本高软件危机软件技术进步落后于需求增长软件危机产生软件危机的主要原因客观：软件本身特点逻辑部件，难以控制质量规模庞大，结构复杂主观：不正确的开发方法，落后的开发工具忽视需求分析错误认为：软件开发=程序编写轻视软件维护软件危机解决软件危机的途径技术措施使用更好的软件开发方法和开发工具组织管理措施软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。软件工程指导计算机软件开发和维护的一门科学。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和技术方法结合起来，以经济地开发出高质量的软件并有效维护。产生1968年,北大西洋公约组织(NATO),召开的有关计算机软件会议上正式提出“软件工程”术语。[IEEE1993年]定义软件工程（SoftwareEngineer）软件工程本质特性关注大型程序构造中心课题：简化复杂性变动成本控制提高开发效率和谐开发软件必须有效支持用户功能、性能和可用性开发者和使用者来自不同文化背景连接着的角色

软件工程的基本原理软件工程的原则和信条100多条B.W.Boehm的7条基本原理

软件工程的基本原理用分阶段的生命周期计划严格管理经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。Boehm认为，在软件的整个生命周期中应制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

软件工程的基本原理坚持进行阶段评审大部分错误是在编码之前造成的错误发现与改正得越晚，所需付出的代价越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程的错误

软件工程的基本原理实行严格的产品控制在软件开发过程中不要随意改变需求，因为改变某项需求往往需要付出较高的代价，但在实践中用户往往会提出需求变更，因此需要采取科学的产品控制技术。目前主要实行基准配置管理：基准配置是指经过阶段评审后的软件配置成分，如各个阶段产生的文档或程序代码。对涉及基准配置的修改，必须经过严格的评审，通过后才能实施修改。

软件工程的基本原理采用现代程序设计技术实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。80年代及之前：结构化分析、设计技术90年代：面向对象分析、设计技术

软件工程的基本原理结果应能清楚地审查软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，使所得的结果能够清楚地审查

软件工程的基本原理开发小组的人员应该少而精开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。开发小组人员数目的增加，使相互交流复杂、费用增加。

软件工程的基本原理承认不断改进软件工程实践的必要性遵循前6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但不能保证赶上时代前进的步伐。积极主动采纳新的软件技术，且不断总结经验。软件工程方法学软件工程生命周期中采用的一整套技术方法的集合传统方法学面向对象方法学软件工程的三要素过程（Process）支持软件生命周期的所有活动方法（Method）为完成软件生命周期的一系列活动提供“怎么做”的技术工具（Tool）为“方法”提供一系列自动、半自动的软件支撑环境传统方法学采用结构化技术完成软件开发的各项任务并使用适当的软件工具或环境来支持技术的运用把生命周期划分为若干个阶段，然后分阶段完成，前一阶段的技术标准是后一阶段的开始并分阶段审查结果面向对象方法学既面向数据又面向行为的方法学把对象作为融合数据和操作的统一软件构件所有对象都划分类，类定义数据和操作按父类子类关系，组成层次结构对象间发送消息软件生命周期软件从提出需求开始直到该软件报废为止的整个时期。软件定义问题定义、可行性研究、需求分析软件开发系统设计总体设计、详细设计系统实现编码、单元测试综合测试软件维护软件生命周期问题定义做什么，问题性质、目标、规模可行性研究是否值得，是否能做需求分析->规格说明书(Specification)明确细致的确定做什么系统逻辑模型数据流图数据字典简要算法软件生命周期概要设计几种可能的方案和架构模块化详细设计模块的细化功能描述数据结构软件生命周期编码与单元测试综合测试集成测试按软件结构把模块组装测试按规格说明书测试，由用户验收维护改正性适应性，修改适应环境完善性，功能完善预防性软件过程为了获得高质量软件所需完成的一系列任务框架，规定了完成各项任务的步骤描述为了开发高质量的软件，什么人在什么时候做什么事以及怎样做。使用资源将输入转化为输出的活动所构成的系统软件开发过程应该明确定义以下元素：过程中所执行的活动及其顺序关系。每一个活动的内容和步骤。团队人员的工作和职责。软件过程模型–瀑布模型特点顺序性和依赖性推迟实现不要急着写代码阶段性评审质量保证缺陷用户对系统的认识在开发阶段仅来自文档无法处理用户的模糊需求软件过程模型–快速原型模型特点线性顺序开发，无反馈软件过程模型–增量模型优点：能较短时间内提交可完成部分工作的产品；可以使用户有充裕的时间学习和适应新产品。文档系统：字处理，文法检测，页面排版分步完善软件过程模型–增量模型并发程度高，集成风险更大软件过程模型–螺旋模型特点可把它看作在每个阶段之前都增加风险分析的快速原型模型。软件过程模型–螺旋模型软件过程模型–螺旋模型螺旋模型优点以风险驱动开发过程，强调可选方案和约束条件从而支持软件的重用。关注于早期错误的消除，将软件质量作为特殊目标融入产品开发之中。螺旋模型缺点要求许多客户接受和相信风险分析并做出相关反应是不容易的，往往适应于内部的大规模软件开发。需要软件开发人员具备风险分析和评估的经验，否则将会带来更大的风险。软件过程模型–喷泉模型特点典型的面向对象软件开发过程模型之一圆圈代表各个阶段互相交叠，他准确反映了各个行为之间的交叠。某个阶段内的箭头代表那个阶段内的迭代维护圆圈较小，代表使用面向对象的范型时，维护的工作量减少了软件过程模型–喷泉模型喷泉模型优点具有更多的增量和迭代性质，生存期的各个阶段可以相互重迭和多次反复在项目的整个生存期中还可以嵌入子生存期采用面向对象方法实现的这种在概念上和表示方法上的一致性保证了开发活动间的无缝过渡喷泉模型缺点面向对象范例要求经常对开发活动进行迭代，这就有可能造成在使用喷泉模型的开发过程过于无序。Rational统一过程RUP（RationalUnifiedProcess）软件开发经验迭代式开发->容纳需求变更/减少风险管理需求->使用用例和脚本使用基于构件的体系结构->功能清晰的模块和子系统可视化建模->模型可为文字、图形、数学表达式验证软件质量->质量评估内建在贯穿于整个开发过程的、由全体成员参与的所有活动中控制软件变更->控制、跟踪、监控修改Rational统一过程初始精化构建移交初始精化1精化2构建1构建2构建3移交1移交2环境工作流业务建模需求分析与设计实现测试部署项目管理阶段配置与变更管理Rational统一过程1.业务建模：描述了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。主要角色：业务流程分析员、业务设计员、业务模型复审员主要工件：业务模型（包括业务用例模型和业务对象模型）2.需求：描述系统应该做什么，即捕获需求，并使开发人员和用户就这一需求描述达成共识。主要角色：系统分析员、用户界面设计员、需求复审员主要工件：用例模型和用户界面模型Rational统一过程3.分析设计：将需求转化成对未来系统的设计，为系统开发一个健壮的结构，并调整设计使其与实现环境相匹配，优化其性能。主要角色：架构设计师、架构复审员