CH1软件工程课件

软件工程学概述计算机系任洪敏HmRen@2009.9.1信息管理与信息系统软件工程软件工程导论（第五版）张海藩清华大学出版社（2007）教材2软件工程

实用软件工程（第四版）郑人杰殷人昆陶永雷清华大学出版社（1996）

软件工程-实践者的研究方法（英文版第八版）RogerS.Pressman机械工业出版社参考书目3软件工程SoftwareEngineeringLaboratoryProjectHomeDesignandImprovementSystemTheHomeDesignandImprovementSystem,HDIS,isintendedtointegrateandunifyallactivitiesrelatedtoconstructionandimprovementsofhomes.Constructinganewhomeorrenovatinganexistinghomecanrequireahighnumberofinteractionswithnumerousindividuals,companies,andstores.ThepurposeofHDISistoutilizecomputingtechnologyinapositivewaytoenhance,facilitate,andpromotethisactivity.5软件工程计划：工作内容①ContractorManagement②HomeOwnerManagement③ArchitecturalManagement④InteriorDesigner⑤LandscapeManagement⑥Schedule&SupplierManagement

FundingManagement

LandOfficeManagement6《图书管理系统》《图书管理系统》针对的用户是中型图书室，藏书的种类包括中、英、俄、德、日文书籍和期刊，读者的数量和来源仅限于本单位职工及通过馆际互借认可的读者。相应的需求有：能够存储一定数量的图书信息,并方便有效的进行相应的书籍数据操作和管理，这主要包括：7

读者信息的登记、删除及修改。读者资料的统计与查询。能够对需要的统计结果提供打印输出。能够提供一定的安全机制，提供数据信息授权访问，防止随意删改，同时提供信息备份的服务。9鼓励项目移动互联网项目李开复：创新工作室10信息管理与信息系统应提交的文档软件需求规格说明书软件设计规格说明书系统测试报告书演示程序11软件工程目的体验软件工程各阶段的主要工作，特别注意吸取教训；

学会与他人合作，培养团队精神，单干户将得不到成绩。现在开始：构想、分组行动起来！第一次进度要求：1周分组，班长发到我处，指明组长13Late1950’s:§1.软件危机（SoftwareCrisis)Intheearlydays:

“Software”=“Placeasequenceofinstructionstogethertogetthecomputertodosomethinguseful”.UserComputerComputerbecamecheaperandmorecommonHighlevellanguageswereinventedProgrammerUserComputereasier14Early1960s:Veryfewlargesoftwareprojectsweredonebysomeexperts.HackerMiddletolate1960s:Trulylargesoftwaresystemswereattempted.例:美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。Cracker15一些数据：大约70％的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20％到50％，90％以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高美国政府审计局：只有不到2％的合同定购软件在发布时具有可用性——98％以上的项目都失败了17yet,SuccessHasntComeEasily31%53%16%SuccessfullyChallengedCanceled软件危机相关术语“两难境地（CrunchMode）”：处于两难境地的项目面临着无法达到最初目标的威胁（费用、进度表、功能性等等），而项目团队在努力想要跨越该困境。“我们正处于两难境地，在半夜之前是不会回家的”“死亡行军（DeathMarch）”：用来描述其进度表几乎不可能完成的项目。“这是一个死亡行军项目，我希望自己不要参与进去”19更准确的说法：慢性痛苦（chronicaffliction)SuggestedbyProf.DanielTiechrow,UniversityofMichigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。如何医治这种软件业的慢性痛苦？21§1.软件危机⑴项目没有被很好地理解；计划不周，最终导致进度拖延。例1.Inthelate1960s,abright-eyedyoungengineer*waschosento“write”acomputerprogramforanautomatedmanufacturingapplication.Thereasonforhisselectionwassimple.Hewastheonlypersoninhistechnicalgroupwhohadattendedacomputerprogrammingseminar.Heknewthein’sandout’sofassemblerlanguageandFortran,butnothingaboutsoftwareengineeringandevenlessaboutprojectschedulingandtracking.问题出在哪里？22Hisbossgavehimtheappropriatemanualsandaverbaldescriptionofwhathadtobedone.Hewasinformedthattheprojectmustbecompletedintwomonths.Hereadthemanuals,consideredhisapproach,andbeganwritingcode.Aftertwoweeks,thebosscalledhimintohisofficeandaskedhowthingsweregoing.“Reallygreat,”saidtheyoungengineerwithyouthfulenthusiasm,“ThiswasmuchsimplerthanIthought.I’m

probablycloseto75percentfinished.”Thebosssmiled.“That’sreallyterrific,”hesaid.Hethentoldtheyoungengineertokeepupthegoodworkandplantomeetagaininaweek’stime.23§1.软件危机例2：

Intheearly1980s,theUnitedStates’InternalRevenueService(IRS)hiredSperryCorporationtobuildanautomatedfederalincometaxformprocessingsystem.AccordingtotheWashingtonPost,the“systemhasprovedinadequatetotheworkload,costnearlytwicewhatwasexpectedandmustbereplacedsoon”(Sawyer1985).In1985,anextra$90millionwasneededtoenhancetheoriginal$103millionworthofSperryequipment.Inaddition,becausetheproblempreventedtheIRSfromreturningrefundstotaxpayersbythedeadline,theIRSwasforcedtopay$40.2millionininterestand$22.3millioninovertimewagesforitsemployeeswhoweretryingtocatchup.25§1.软件危机In1996,thesituationhadnotimproved.TheLosAngelesTimesreportedonMarch29thattherewasstillnomasterplanforthemodernizationofIRScomputers,onlyasix-thousandtechnicaldocument.CongressmanJimLightfootcalledtheproject“a$4-billionfiascothatisflounderingbecauseofinadequateplanning”(Vartabedian1996).Myth:Ifwegetbehindschedule,wecanaddmoreprogrammersandcatchup.Reality:Softwaredevelopmentisnotamechanisticprocesslikemanufacturing.InthewordsofBrooks,“addingpeopletoalatesoftwareprojectmakesitlater.”26

1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。原因是FORTRAN程序：

DO5I=1，3

误写为：DO5I=1.3

1967年苏联“联盟一号”载人宇宙飞船在返航时，由于软件忽略一个小数点，在进入大气层时因打不开降落伞而烧毁。29§1.软件危机⑷软件难以维护(maintainability)不易升级evolvability)Myth:Oncewewritetheprogramandgetittowork,ourjobisdone.Reality:Someoneoncesaidthat“thesooneryoubegin‘writingcode’,thelongerit’lltakeyoutogetdone.”Industrydataindicatethatbetween50and70percentofalleffortexpendedonaprogramwillbeexpendedafteritisdeliveredtothecustomerforthefirsttime.30§1.软件危机

BettermanagementDifferentteamorganizationsBetterlanguages&toolsUniformcodingconventions

必须意识到：“软件”编程，它有自己的生命周期(lifecycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。“软件工程”(SoftwareEngineering)NATOConference,Garmisch,Germany,1968.解决问题的想法：312软件的概念软件的概念：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列。数据是使程序能正常操作所需的数据结构；文档是与程序开发，维护和使用有关的图文材料。322.1软件特点软件的特点：

软件的生产与硬件不同，它没有明显的制造过程。硬件在制造过程中进行质量控制，软件在开发过程中进行质量控制。软件是一种逻辑实体，不是具体的物理实体,具有抽象性.软件的运行和使用期间，没有硬件那样的机械磨损和老化问题，但存在软件退化问题。332.1软件的特点(续)软件的开发和运行常常受到计算机系统的限制，不同程度依赖计算机系统。软件移植的问题。软件的开发至今尚未完全摆脱手工艺的开发方式。软件本身的复杂性。软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。软件成本相当昂贵。软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，它的成本是比较高的。相当多的软件工作涉及到社会因素。许多软件的开发和运行涉及机构、体制及管理方式等问题，甚至涉及到人的观念和人们的心理。它直接影响到项目的成败

342.2软件的分类软件的分类：按照功能划分：系统软件、支撑软件、应用软件按照规模划分：微型、小型、中型、大型、甚大型、极大型按照工作方式划分：实时处理软件、分时软件、交互式软件、批处理软件按照服务对象划分：项目软件、产品软件按照使用频度划分：使用一次、一年一次、一天一次、频繁使用按照失效影响划分：高可靠性软件、一般可靠性软件35计算机软件经历了三个发展阶段：程序设计阶段，约为50至60年代程序系统阶段，约为60至70年代软件工程阶段，约为70年代以后计算机软件发展三个时期及其特点：参见下表。表注：软件语言包括需求定义语言、软件功能语言、软件设计语言、程序设计语言。36软件发展阶段(续)特点

时期程序设计程序系统软件工程软件所指程序程序及说明书程序、文档、数据程序设计语言汇编、机器语言高级语言软件语言软件工作范围程序编写包括设计和测试软件生成期需求人员程序设计者本人少数用户市场用户开发组织个人开发小组开发小组、开发机构软件规模小型中小型大中小型质量决定因素个人程序技术小组技术水平管理水平开发技术和手段子程序、程序库结构化程序设计工程化开发方法、CASE、数据库维护人员程序设计者开发小组专职维护人员硬件特征价高、速度、容量、可靠性差降价、速度、容量、可靠性提高高速、大容量、微型化、网络化软件特征完全不受重视软件不能满足需求，出现软件危机有进步，未突破性进展，价高，未完全摆脱危机时期特点37软件发展的根本变化数十年来根本的变化：人们对软件有了新的认识。50年代到60年代时，程序设计曾经被看做是一种任人发挥创造才能的技术领域。程序的写法可以不受任何约束。随着计算机的广泛使用，人们要求这些程序容易看懂、容易使用，并且容易修改和扩充。于是，程序便从个人按自己意图创造的“艺术品”转变为能被广大用户接受的工程化产品。软件的需求是软件发展的动力。早期的程序开发者只是为了满足自己的需要，这种自给自足的生产方式仍然是其低级阶段的表现。进入软件工程阶段以后，软件开发的成果具有社会属性，它要在市场中流通以满足广大用户的需要，软件开发者和用户的分工和责任也是十分清楚的软件工作的范围从只考虑程序的编写扩展到涉及整个软件生存周期，包括制定计划、需求分析、软件设计、软件实现、软件测试和软件维护。383软件工程定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修复软件的系统方法FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法工程：系统、规范、可度量39软件工程的定义软件工程是一类求解软件的工程，它应用计算机科学，数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高质量，降低成本的目的。其中计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本以及确定权衡，管理科学用于计划、资源、质量、成本等管理。软件工程是一门指导计算机软件开发和维护的工程学科。40软件工程的产生和发展软件工程的发展已经历了四个重要阶段：4、第四代软件工程—构件工程3、第三代软件工程—过程工程2、第二代软件工程—对象工程1、第一代软件工程—传统的软件工程411.1.1软件程的产生和发展软件工程的发展已经历了四个重要阶段：1、第一代软件工程—传统的软件工程2、第二代软件工程—对象工程3、第三代软件工程—过程工程4、第四代软件工程—构件工程

60年代末到70年代为了克服“软件危机”(Softwarecrisis)提出“软件工程”的名词,将软件开发纳入工程化的轨道，基本形成软件工程的概念、框架、技术和方法。称为传统的软件工程。421.1.1软件工程的产生和发展1.1.1软件工程的产生和发展软件工程的发展已经历了四个重要阶段：1、第一代软件工程—传统的软件工程2、第二代软件工程—对象工程3、第三代软件工程—过程工程4、第四代软件工程—构件工程80年代中到90年代，面向对象的方法与技术得到发展，研究的重点转移到面向对象的分析与设计，演化为一种完整的软件开发方法和系统的技术体系，称为对象工程。431.1.1软件工程的产生和发展1.1.1软件工程的产生和发展软件工程的发展已经历了四个重要阶段：1、第一代软件工程—传统的软件工程2、第二代软件工程—对象工程3、第三代软件工程—过程工程4、第四代软件工程—构件工程80年代中开始，人们在软件开发的实践过程中认识到：提高软件生产率，保证软件质量的关键是“软件过程”，是软件开发和维护中的管理和支持能力，逐步形成软件过程工程。441.1.1软件工程的产生和发展1.1.1软件工程的产生和发展软件工程的发展已经历了四个重要阶段：1、第一代软件工程—传统的软件工程2、第二代软件工程—对象工程3、第三代软件工程—过程工程4、第四代软件工程—构件工程90起年代，基于构件（Component）的开发方法取得重要进展，软件系统的开发可通过使用现成的可复用构件组装完成，而无需从头开始构造，以此达到提高效率和质量，降低成本的目的。称为构件工程。45软件工程本质特性软件工程关注大型复杂程序构造软件工程的中心课题是控制复杂性软件经常变化：keepingsoftwaresoft软件开发的效率非常重要和谐合作是软件开发的关键软件必须有效地支持它的用户软件工程相关的知识和文化背景的分离46软件工程管理的基本原理用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制[基准配置管理]采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性47软件工程技术的基本原理抽象:

抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层细化的办法控制软件开发过程的复杂性。信息隐蔽:

将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。使用者只能通过模块接口访问模块中封装的数据。模块化:

模块是程序中逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。局部化:

要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于控制解的复杂性。48软件工程技术的基本原理(续）确定性:软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。这有助于人们之间在交流时不会产生误解、遗漏，保证整个开发工作协调一致。一致性:

整个软件系统（包括程序、文档和数据）的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。完备性:

软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。可验证性:

开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。49软件工程研究的内容软件开发一整套技术方法的集合软件工程方法学包括三个要素：方法、工具和过程。软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。50toolmethodprocedureQualityfocusSoftwareengineeringlayers软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。计算机辅助软件工程(CASE)将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。52生命开发方法学结构化方法：结构化分析、结构化设计、结构化编码过程：划分阶段、依此进行、技术和管理复审、文档驱动工具：大量辅助工具简单、有条不紊、广泛应用不适合：规模庞大、需求模糊和变化、维护困难53面向对象方法学面向对象技术：面向对象分析、面向对象设计、面向对象编码（OO的思想)过程：主动地多次反复迭代的演化过程。工具:VS、ROSE易于理解、易于复用、易于维护54计算机系统工程基于计算机的系统和其元素55计算机系统工程软件：计算机程序、数据结构、相关文档硬件：计算设备（如CPU，存储器）和外部机电设备（如传感器、马达等）人：硬件和软件的用户数据库：一个大型的有组织的信息集合文档：手册、表格和其它用以描述系统使用和操作的信息过程：定义每一种系统元素的特定使用步骤，或系统驻留的过程性环境56SoftwareandsystemsengineeringTheproportionofsoftwareinsystemsisincreasing.Software-drivengeneralpurposeelectronicsisreplacingspecial-purposesystemsProblemsofsystemsengineeringaresimilarto

problemsofsoftwareengineeringSoftwareis(unfortunately)seenasaproblem

insystemsengineering.Manylargesystemprojectshavebeendelayedbecauseofsoftwareproblems574软件生命周期正如同任何事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。我们称其为计算机软件的生存周期。生命周期的三个时期:软件定义、软件开发、软件维护58软件生命周期（续）问题定义：“要解决的问题是什么”简要写出问题性质、工程目标、工程规模的书面报告可行性研究：“该问题有可行的解决办法吗？”高层、压缩和简化的系统分析和设计过程研究问题的范围、值得吗、行吗需求分析：“目标系统必须做什么”系统的逻辑模型需求规格说明书59软件生命周期（续）总体设计：“概括地说，系统怎样实现？”设计和分析多种方案，推荐方案和其计划系统的体系结构详细设计：“系统具体怎样实现？”程序的详细规格说明，编码的蓝图确定模块的算法和数据结构60软件生命周期（续）编码和单元测试：编码程序模块测试该模块综合测试集成测试验收测试系统分析61软件生命周期（续）软件维护改正性维护完善性维护适应性维护预防性维护没有一个四海皆准的统一的过程62问题定义编码需求分析设计可行性研究运行与维护测试开发时期运行时期计划时期(目标与范围说明书)(可行性论证论告)(维护报告)(测试报告)(程序)(设计文档)(需求说明书)瀑布模型图1.3瀑布模型1.3软件生存期63软件过程——生命周期模型瀑布模型64图1-3软件生存周期工作量分配65图1-4开发期工作量分配66软件过程——生命周期模型快速原形模型快速原形规格说明设计实现系统维护67软件过程——生命周期模型增量模型定义概要需求把需求分配给增量设计系统结构开发系统增量验证增量组装增量验证系统系统不完全最终系统68软件过程——生命周期模型增量模型需求分析规格说明系统设计实现集成实现集成需求分析规格说明系统设计实现集成实现集成需求分析规格说明系统设计实现集成实现集成构件n构件2构件169增量模型(incrementalmodel)增量模型是一种非整体开发的模型。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。70

螺旋模型

对于大型软件，只开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：1.确定目标、方案和限制条件；2.评估方案、标识风险和解决风险；3.开发确认产品；4.计划下一周期工作。螺旋模型71软件过程——生命周期模型喷泉模型重复演进各阶段间无明显界限72统一过程概述Rational公司的RUP发展而来的一套软件工程方法，是目前最有效的软件开发过程模型。基于构件的用UML制定软件系统所有蓝图突出特点：用例驱动、架构优先、迭代和增量过程四个阶段：初始、细化、构造、移交强调开发过程五个核心工作流：需求捕获、分析、设计、实现、测试73RUP工作流与阶段74在RUP中，项目生命周期被划分为四个阶段：

（1）初始阶段（Inception）

（2）细化阶段（Elaboration）

（3）构造阶段（Construction）

（4）交付阶段（Transition）每个阶段开始时都有特定的目标，结束时有里程碑。在每个阶段中存在一个或多个迭代。在每个迭代中，可以有多个工作流。2统一过程四个工作阶段75获取需求需求分析具体描述优化程序验证维护调整知识库/专家系统智能模型76SoftwareMyths(1)ManagementMyths（管理神话）Managerswithsoftwareresponsibility,likemanagersinmostdisciplines,areoftenunderpressuretomaintainbudgets,keepschedulesfromslipping（松弛）,andimprovequality.Likeadrowningpersonwhograspsatastraw（抓住稻草的要淹死的人）,asoftwaremanageroftengraspsatbeliefinasoftwaremyth,ifthatbeliefwilllessenthepressure(eventemporarily).77ManagementMythsMyth:Wealreadyhaveabookthat’sfullofstandardsandproceduresforbuildingsoftware,won’tthatprovidemypeoplewitheverythingtheyneedtoknow?Reality:Thebookofstandardsmayverywellexist,butisitused?Aresoftwarepractitionersawareofitsexistence?Doesitreflectmodernsoftwareengineeringpractice?Isitcomplete?Isitstreamlinedtoimprovetimetodeliverywhilestillmaintainingafocusonquality?Inmanycases,theanswertoallofthesequestionsis“no”.78ManagementMythsMyth:Mypeoplehavestate-of-the-artsoftwaredevelopmenttools,afterall,webuythemthenewestcomputers.Reality:Ittakesmuchmorethanthelatestmodelmainframe,workstationorPCtodohigh-qualitysoftwaredevelopment.Computer-aidedsoftwareengineeringtoolsaremoreimportantthanhardwareforachievinggoodqualityandproductivity,yetthemajorityofsoftwaredevelopersstilldonotusethemeffectively.79ManagementMythsMyth:Ifwegetbehindschedule,wecanaddmoreprogrammersandcatchup(sometimescalledtheMongolianhordeconcept)Reality:Softwaredevelopmentisnotamechanisticprocesslikemanufacturing.InthewordsofBrooks:Addingpeopletoalatesoftwareprojectmakesitlater.80ManagementMythsMyth:IfIdecidetooutsourcethesoftwareprojecttoathirdparty,Icanjustrelaxandletthatfirmbuildit.Reality:Ifanorganizationdoesnotunderstandhowtomanageandcontrolsoftwareprojectsinternally,itwillinvariablystrugglewhenitoutsourcessoftwareprojects.81SoftwareMyths(2)CustomermythsAcustomerwhorequestscomputersoftwaremaybeapersonatthenextdesk,atechnicalgroupdownthehall,themarketing/salesdepartment,oranoutsidecompanythathasrequestedsoftwareundercontract.Inmanycases,thecustomerbelievesmythsaboutsoftwarebecausesoftwaremanagersandpractitionersdolittletocorrectmisinformation.Mythsleadtofalseexpectations(bythecustomer)andultimately,dissatisfactionwiththedeveloper.82CustomermythsMyth:Ageneralstatementofobjectivesissufficienttobeginwri