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

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

《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.分析设计：将需求转化成对未来系统的设计，为系统开发一个健壮的结构，并调整设计使其与实现环境相匹配，优化其性能。主要角色：架构设计师、架构复审员、设计员、数据库设计员、设计复审员主要工件：设计模型和可选的分析模型4.实施：以层次化的子系统形式化地定义代码的组织结构；以构件的形式实现类和对象；将开发出的构件作为单元进行测试；将各实施人员（或团队)完成的结果集成到可执行系统中。主要角色：架构设计员、实施员、集成员、代码复审员主要工件：实施模型Rational统一过程5.测试:检验对象间的交互作用，验证软件中所有构件是否正确集成，检验所有需求是否被正确的实现，识别、确认缺陷并确保在软件部署之前将缺陷解决。主要角色:测试设计员、测试员主要工件:测试模型和测试结果6.部署:成功地生成产品版本并将软件分发给最终用户主要角色:部署经理、实施人员、技术文档编写员、培训开发员主要工件:产品的一个版本和文档培训资料Rational统一过程7.配置和变更管理:描述了如何在多个成员组成的项目中控制大量的产品，并提供了相应准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本变更主要角色:配置经理、变更控制经理、集成员主要工件:配置管理计划、变更请求、项目存储库和工作区8.项目管理:平衡竞争的目标、管理风险并克服各种约束，从而成功交付使用户满意的产品主要角色:项目经理、项目复审员主要工件:商业理由、迭代计划、风险管理计划、质量保证计划及象样的评估文档9.环境:向软件开发组织提供软件开发的环境，包括过程和工具主要角色:过程工程师、工具专家主要工件:工作流程指南和工具、工具指南RUP生命周期4阶段初始阶段（Inception)：建立业务用例和确定项目的范围－生命周期目标里程碑主要项目干系人对系统的范围达成一致意见；对是否已经获得正确的需求集达成一致意见，并且对这些需求的理解是共同的；对成本/进度估算、优先级、风险和开发流程达成一致意见；已经确定所有风险并且有针对每个风险的风险降低策略RUP生命周期4阶段精化阶段（Elaboration)：建立稳定的架构、编制项目计划和淘汰项目中风险最高的元素－生命周期架构里程碑产品前景和需求是稳定的；架构是稳定的；可执行原型表明已经找到了主要的风险元素，并且已得到妥善解决；构建阶段的迭代计划足够详细和真实，可以保证工作继续进行；构建阶段的迭代计划有可靠的估算支持；所有项目干系人一致认为，如果在当前架构环境中执行当前计划来开发完整的系统，则当前的前景可以实现；实际的资源耗费与计划的耗费相比是可以接受的。

RUP生命周期4阶段构建阶段（Construction)：所有构件和应用程序功能被开发并集成为产品，所有的功能被详尽地测试－最初操作性能里程碑该产品发布版已经足够稳定和成熟，可部署在用户群中；所有项目干系人已准备好将产品发布到用户群；实际的资源耗费与计划相比仍可以接受。移交阶段（Transition)：将软件产品交付给用户群体－产品发布里程碑用户满意；实际的资源耗费与计划的耗费相比可以接受对比与螺旋模型相比相似:重复一系列组成系统生命周期的循环差异:RUP给出了每个阶段内的若干次迭代过程完成后交付的增量的具体要求，即

四个阶段的里程碑RUP详细阐述了不同阶段的不同迭代过程经历的九大核心工作流程中活动内容的重点和强度不同RUP提供了对每次迭代过程中不同核心工作流程活动的并行化支持优点:用于指导需求不明确、不稳定的项目开发时具有更强的可操作性。与瀑布模型相比，优点:RUP将成本风险进一步降低为获得一次增量所需的费用RUP进一步降低了产品不能按计划投放市场的风险RUP使项目开发更能适应项目需求的变化敏捷过程具有高效、快速响应变化的开发过程。敏捷过程的价值观个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划极限编程敏捷过程中最著名的一种,指把好的开发实践运用到极致,多应用于软件需求模糊的场合。

极限编程客户作为开发团队的成员使用用户素材短交付周期（每两周完成一次迭代)验收测试结对编程测试驱动开发集体所有（程序代码属于整个开发小组，每个成员都有修改代码的权利，都对全部代码负责)极限编程可持续的开发速度（周工作时间不超过40小时，连续加班不超过两周)开放的工作空间及时调整计划简单的设计重构使用隐喻（隐喻是把整个系统联系在一起的全局视图，描述系统如何运做，如何把新功能加入到系统中)敏捷过程与RUP敏捷过程的总体特征是针对商业环境下通常具有有限资源和有限时间约束的小型项目，提出了一些独具特色的、操作性较强的解决方案;RUP是理想开发环境下软件过程的一种完美的模式，但对商业环境具有有限资源和有限时间约束的项目没有给出具体完整的配置方案。

微软过程Microsoft公司自己独特的软件开发过程，综合了RUP和XP的许多优点，是对众多成功项目的开发经验的正确总结MSF的过程模型来自两个方面：微软开发应用程序的过程；一些有效的、公认的过程模型；详细论述参见《微软软件开发解决方案框架》（第二版)，麦中凡、陶伟编著，北京航空航天大学出版社微软过程准则项目计划应该兼顾未来的不确定因素用有效的风险管理来减少不确定的因素经常生成过渡版本并快速地测试软件来提高产品的稳定性及可预测性采用快速循环、递进的开发过程用创造性的工作来平衡产品特性和产品成本项目进度表应该具有较高的稳定性和权威性使用小型项目组并发地完成开发工作在项目早期把软件配置项基线化使用原型验证概念,对项目进行早期论证把零缺陷作为追求的目标里程碑评审会强调改进工作,避免相互指责微软软件生命周期微软软件生命周期构思阶段－前景/范围认可里程碑主要工作:确定产品目