软件工程导论 —— 张海藩

软件工程导论——张海藩 重庆三峡学院数计学院刘福明 E-mail：fm_l@sina.com

课程的性质与任务 本课程是计算机科学与技术专业的专业课程之一，它也是计算机学科中一个新兴的并且充满活力的研究领域。软件工程的重要性在于它对贯穿系统生存期的软件开发，实现以及维护的系统化研究。本课程重点讲授计算机软件开发的全过程以及贯穿全过程的各阶段中所采用的技术、方法和工具。前一部分的内容介绍传统的结构化分析和设计方法，后一部分的内容介绍九十年代开始出现的面向对象软件工程的研究。通过本课程的学习，要求学生能够掌握这两种不同风格的方法学，并有意识地按照软件工程规范指导软件系统开发实践。

参考资料 书籍： 1.《软件工程》（原书第6版）Ian Sommerville著，程成等译机械工业出版社 2.《基于项目的软件工程:面向对象方法》（影印版）(美)斯蒂尔勒、勒布朗著，高等教育出版社 3.《软件工程》齐治昌等著高等教育出版社 4.《软件开发指南》何培民著　清华大学出版社 5.《Object_Oriented Analysis》(Second Edition).Peter Cord and Edward Yourdon. Yourdon Press. 6. 《Object_Oriented Design》.Peter Cord and Edward Yourdon. Yourdon Press.

参考资料 网站： 1.http://www.csdn.net/ 2.http://www.uml.org.cn/ UML软件工程组织 3.http://se.csai.cn/ 软件工程专家网 4.http://www.chambers.com.au/webintro.htm 提供在线课程 5. http://c2.com/ppr/ 一个讲开发模式的网站 6. http://www.sdmagazine.com/ 一本杂志, 很多软工方面的文章. 作者都是软工界的名流（Software Development Online） 7. http://www.chambers.com.au/webintro.htm 提供一些在线教程（C&A‘s Software Engineering Web ）

要求 1.课堂要求 2.实验+大作业（模拟软件开发） 3.考核：平时+模拟软件开发（+期末考试）

第一章软件工程学概述 在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。自20世纪60年代末期以来，人们为克服“软件危机”在这一领域做了大量工作，逐渐形成了系统的软件开发理论、技术和方法，它们在软件开发实践中发挥了重要作用。软件工程(Software Engineering，简称为SE) 是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科，它是计算机学科中一个年轻并且充满活力的研究领域，涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。

第一章软件工程学概述 软件工程这一概念，主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO（北大西洋公约组织）会议上。自这一概念提出以来，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究，从而逐渐形成了一门新兴的工程学科――计算机软件工程学（简称为软件工程）。

第一章软件工程学概述 今天，现代科学技术将人类带入了信息社会，计算机软件扮演着十分重要的角色，软件工程已成为信息社会高技术竞争的关键领域之一。软件工程学主要研究如何运用工程学的原理、技术和方法来组织和管理软件生产，以确保软件产品的高质量和高生产率。软件工程研究的对象主要是大型软件的定义、开发、使用和维护。本学科研究的内容为：软件开发和维护的理论、方法、技术、标准，以及计算机辅助工具和环境。主要包括：软件质量保证和质量评价；软件研制和维护的方法、工具、文档；用户界面的设计以及软件管理等。学科起源：软件危机。

1.1 软件危机 软件危机：在计算机软件开发和维护过程中所遇到的一系列严重问题。一个软件产品的开发往往需要投入大量的人力和物力，因无法预先准确地估计它的经费、进度等，而导致预算大大超支，进度大大延期；另外，软件开发人员在进行开发时也往往不能充分满足用户期望；质量不能保证；可维护性差等等现象。 60年代中期以后，计算机硬件技术日益进步，计算的存贮容量、运算速度和可靠性明显提高，生产硬件的成本不断降低。计算机价格的下跌为它的广泛应用创造了极好的条件。在这种形势下，迫切要求计算机软件也能与之相适应。因而，一些开发大型软件系统的要求提了出来。然而软件技术的进步一直未能满足形势发展的需要，在大型软件的开发过程中出现了复杂程度高、研制周期长、正确性难以保证的三大难题。遇到的问题找不到解决办法，致使问题堆积起来，形成了人们难以控制的局面，出现了所谓的“软件危机” 。

1.1 软件危机 最为突出的例子是美国IBM公司于1963年～1966年开发的IBM360系列机的操作系统。该软件系统花了大约5000人一年的工作量，最多时，有1000人投入开发工作，写出近100万行的源程序。尽管投入了这么多的人力和物力，得到的结果却极其糟糕。据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。可想而知，这样的软件质量糟到了什么地步。 IBM360操作系统的历史教训已成为软件开发项目中的典型事例被记入历史史册。

1.1 软件危机 如果开发的软件隐含错误，可靠性得不到保证，那么在运行过程中很可能对整个系统造成十分严重的后果，轻则影响到系统的正常工作，重则导致整个系统的瘫痪，乃至造成无可挽回的恶性事故。如，银行的存款可能被化为乌有，甚至弄成赤字；工厂的产品全部报废，导致工厂破产。 1963年，美国用于控制火星探测器的计算机软件中的一个“，”号被误写为“·”，而致使飞往火星的探测器发生爆炸，造成高达数亿美元的损失。

1.1 软件危机 1.1.1 软件危机的介绍软件危机(Software Crisis) 是计算机软件在它的开发和维护过程中所遇到的一系列严重问题。概括地说，主要包含两方面的问题： 1.如何开发软件，怎样满足对软件日益增长的需求； 2.如何维护数量不断膨胀的已有软件。

1.1 软件危机 软件危机的主要表现： 1. 对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了开发组织的信誉。为赶进度和节约成本所采取的权宜之计往往又损害了软件产品的质量，从而不可避免地引起用户的不满。 2. 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员常常在对用户需求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就仓促上阵匆忙着手编写程序。软件开发人员和用户之间的交流往往很不充分，“闭门造车”必然导致最终产品不符合用户实际需要。 3. 软件产品的质量常常靠不住。软件可靠性和质量保证的确切定量概念刚刚出现，软件质量保证技术（审查、复审和测试）还没有坚持不懈地应用到软件开发的全过程中，这些都会导致软件产品发生质量问题。

1.1 软件危机 4. 软件常常是不可维护的。程序中的错误很难改正，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需求在原有程序中增加新的功能。 5. 软件通常没有适当的文档资料。软件不仅是程序，还应该有一整套文档资料。这些文档资料是在软件开发过程中产生出来的，而且应该是“最新的”（与代码完全一致）。缺乏文档必然给软件的开发和维护带来许多严重的困难和问题。 6. 软件成本在计算机系统总成本中所占比例逐年上升。随着微电子技术的进步和生产自动化程度的提高，硬件成本逐年下降，然而软件开发需要大量的人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而逐年上升。美国在1995年的调查表明，软件成本大约已占计算机系统总成本的90%。 7.软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

1.1 软件危机 1.1.2 产生软件危机的原因一方面与软件本身的特点有关。 1.软件是一种逻辑部件，开发时缺乏“可见性”，因此管理和控制软件开发过程相当困难。此外，由于它是逻辑产品，所以不会被“用坏”，也就是说，如果运行中出现错误，这个错误必然是在开发中存在的。因此，软件的维护通常需要改正或修改原来的设计，这就使得软件较难维护。 2.软件的规模庞大，而且程序复杂度将随着程序规模的增加而呈指数上升。

1.1 软件危机 另一方面与软件开发和维护的方法不正确有关。主要表现为：忽视软件需求分析的重要性。对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一；忽略了软件与程序的关系。一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期，通常称其为软件的生命周期；程序只是软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分；作好软件定义时期的工作，是降低软件成本，提高软件质量的关键；轻视软件维护。维护是极端艰巨复杂的工作，需要花费很大代价。统计数据表明，实际上用于软件维护的费用占软件总费用的55%～79%。

1.1 软件危机 1.1.3 消除软件危机的途径首先应该对计算机软件及软件开发有一个正确的认识。软件是程序、数据及相关文档的完整集合（1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必须的数据。）；软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目；其次，应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法；应该开发和使用更好的软件工具，利用工具来辅助我们开发软件。总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织和管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

1.1 软件危机 软件危机使得人们开始对软件及其特性进行更深一步的研究，人们改变了早期对软件的不正确看法。早期那些被认为是优秀的程序常常很难被别人看懂，通篇充满了程序技巧。现在人们普遍认为优秀的程序除了功能正确，性能优良之外，还应该容易看懂、容易使用、容易修改和扩充。

1.2 软件工程 1.2.1 软件工程的介绍软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言，它借鉴了传统工程的原则和方法，以求高效地开发高质量软件。其中应用了计算机科学、数学和管理科学。计算机科学和数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量和成本的管理。人们曾经给软件工程下过很多定义，书中给出了两个较典型的定义。 1968年在第一届NATO会议上曾经给出了一个早期的定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效的运行的软件，而建立和使用完善的工程原理”。 1993年IEEE进一步给出了更全面更具体的定义：“软件工程是：（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；（2）研究（1）中提到的途径。”

1.2 软件工程 软件工程的本质特征。 1.软件工程关注于大型程序的构造； 2.软件工程的中心课题是控制复杂性 3.软件经常变化 4.开发软件的效率非常重要 5.和谐的合作是开发软件的关键 6.软件必须有效地支持它的用户 7.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.2 软件工程 软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。 (1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

1.2 软件工程 (2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

1.2 软件工程 (3)软件工程的原则：指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。有以下四项基本原则：第一，选取适宜开发范型。该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。第二，采用合适的设计方法。在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

1.2 软件工程 第三，提供高质量的工程支持。“工欲善其事，必先利其器”。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。第四，重视开发过程的管理。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。

1.2 软件工程 1.2.2软件工程的基本原理自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW公司多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。 Boehm 认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。

1.2 软件工程 1.用分阶段的生命周期计划严格管理　　这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

1.2 软件工程 2.坚持进行阶段评审　　统计结果显示：大部分错误是在编码之前造成的，大约占63%; 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。 3.实行严格的产品控制　　开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求，也就是要采用变动控制，又叫基准配置管理：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

1.2 软件工程 4.采纳现代程序设计技术　　从六、七十年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。 5.结果应能清楚地审查软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

1.2 软件工程 6.开发小组的人员应少而精　　开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。　　这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。 7.承认不断改进软件工程实践的必要性不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

1.2 软件工程 1.2.3 软件工程方法学方法学：在软件生命周期全过程中使用的一整套技术方法的集合。软件工程方法学包含3个要素：方法、工具和过程。方法是完成软件开发的各项任务的技术手段；工具是人类在开发软件的活动中智力和体力的扩展和延伸，是为运用方法而提供的自动的或半自动的软件工程支撑环境；过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。目前使用最广的软件工程方法学是传统的方法学和面向对象方法学。

1.2 软件工程 1.传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的应用。这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。传统方法学降低了整个软件开发工程的难度；保证了软件的质量，提高了软件的可维护性。

1.2 软件工程 2.面向对象方法学面向对象方法学的主要出发点和基本原则是尽量模拟人类习惯的思维方式，使开发软件的方法和过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间（也称为问题域）与实现解法的解空间（也称为求解域）在结构上尽可能一致。 OO（Object Oriented）是一种思想，一种方法。它以数据或信息为主线，把数据和处理相结合。OO方法把客观世界存在的一切事物都看成是对象，它把对象看作为由数据及可以施加在这些数据上操作所构成的统一体。 OO=Objects+Classes+Inheritance+Communication with Message

1.3 软件生命周期 软件生命周期由软件定义、软件开发和运行维护3个时期组成。软件定义时期确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程总目标应该采用的策略及系统必须完成的功能；估计完成该项功能需要的资源和成本，并且制定工程进度表。通常进一步划分为3个阶段：问题定义、可行性研究和需求分析；软件开发时期具体设计和实现前一时期定义的软件。由4个阶段组成：总体设计、详细设计、编码和单元测试、综合测试；软件维护的主要任务就是使软件持久地满足用户的需要。 1.问题定义 5.详细设计 2.可行性研究 6.编码和单元测试 3.需求分析 7.综合测试 4.总体设计 8.软件维护参见书P12～14

1.4 软件过程 过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。为获得高质量的软件产品，软件过程必须科学、有效。科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。通常，一个任务集合包括一组软件过程任务、里程碑和应该交付的产品（软件配置成分）。通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。模型是为了理解事物而对事物做出的一种抽象，它忽略了不必要的细节，是事物的一种抽象形式，一个规划，一个程式。模型是一种思考工具，利用这种工具可以把知识规范地表示出来。

1.4 软件过程 1.4.1 瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品。如下图：

1.4 软件过程 优点： a.强调开发的阶段性； b.强调早期计划及需求调查；　　 c.强调产品测试。缺点：　　 a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化； b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；　　 c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。

1.4 软件过程 1.4.2 快速原型模型原型模型又称演化模型，主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。

1.4 软件过程

1.4 软件过程 1.4.3 增量模型与迭代模型软件开发不是一蹴而就，其过程犹如雕琢一件工艺品，由无形到有形、由粗到细，很难一次就能开发出功能完善、强大的一个版本，而往往是分阶段进行，一个版本接一个版本的发布。软件开发分阶段可以通过两种模型来描述，即增量模型和迭代模型。增量模型：描述软件产品的不同阶段是按产品所具有的功能进行划分，先开发主要功能或用户最需要的功能，然后，随着时间推进，不断增加新的辅助功能或次要功能，最终开发出一个强大的、功能完善的、高质量的、稳定的产品。迭代模型：描述软件产品的不同阶段是按产品深度或细化的程度来划分。先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需求的全部功能。然后，随着时间推进，不断细化已有的功能或完善已有功能，这个过程好像是一个迭代的过程。最终的目标是一致的，也是为了实现一个强大的、功能完善的、高质量的、稳定的产品。

1.4 软件过程

1.4 软件过程 1.4.4 螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消。如右图。

1.4 软件过程 优点： a.强调严格的全过程风险管理。 b.强调各开发阶段的质量。 c.提供机会检讨项目是否有价值继续下去。缺点：引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员，资金，和时间的投入。

1.4 软件过程 喷泉模型fountain model 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

1.4 软件过程 敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

1.4 软件过程 敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：人和交互重于过程和工具。可以工作的软件重于求全责备的文档。客户协作重于合同谈判。随时应对变化重于循规蹈矩。其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

1.4 软件过程 极限编程(XP)是敏捷方法中最箸名的一个。 Extreme Programming（极限编程，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

1.4 软件过程 XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

1.4 软件过程 “Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。 1、极限的工作环境 2、极限的需求 3、极限的设计 4、极限的编程 5、极限的测试

1.4 软件过程 统一软件过程 RUP（Rational Unified Process，统一软件开发过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模板以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

1.4 软件过程 RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。

软件工程导论 —— 张海藩

软件工程导论 —— 张海藩

Presentation Transcript